很多人使用 ChatGPT 或 Codex 写代码时最常输入的一句话可能是帮我看看这段代码。或者帮我修复这个 Bug。再或者帮我把这个项目优化一下。不能说这些 Prompt 没有用。但如果你真正开始让 Codex 接触完整项目就会发现一个非常明显的问题任务描述越模糊AI 自由发挥的空间越大。而在软件工程里面自由发挥很多时候并不是优点。因为你真正需要的通常是只修这个 Bug 不要改其他功能 不要随便加依赖 不要改变 API 先找到根因 修改以后跑测试这也是我现在使用 ChatGPT、Plus、Pro 和 Codex 时越来越重视的一点Prompt 的核心不是“写得长”而是“边界清楚”。目前 OpenAI 对 Codex 的定位已经明显偏向完整的软件工程 Agent它可以围绕真实代码仓库完成开发、重构、迁移、代码审查等任务Codex CLI 也能够在终端环境中检查代码、编辑文件以及执行命令。所以这篇不讨论什么复杂的 Prompt 理论。直接整理20 个我认为开发者真正用得上的 Codex Prompt基本都可以直接复制然后根据自己的项目稍微修改。一、项目接手先让 Codex 看懂整个仓库这是我认为最值得保存的一条 Prompt。第一次让 Codex 进入一个陌生项目时不要立刻帮我优化这个项目。先让它做 Repository Exploration。Prompt 01快速理解陌生项目先不要修改任何文件。 请系统阅读当前代码仓库并帮助我快速理解这个项目。 重点分析 1. 项目的主要技术栈 2. 程序入口 3. 核心目录分别负责什么 4. 数据库访问方式 5. 用户认证方式 6. API 的组织方式 7. 前端状态管理方式 8. 测试框架和测试目录 9. 构建、Lint、Type Check 命令 10. 项目中最重要的 5 个核心模块。 最后给我输出 - 项目架构概览 - 一次正常请求的数据流 - 最重要的文件 - 新开发者最容易踩坑的地方。 暂时不要修改代码。它适合接手旧项目 开源项目研究 公司历史项目 第一次让 Codex 进入仓库这里最重要的是暂时不要修改代码先建立正确上下文。二、不要直接修 Bug先让它找“根因”很多人遇到 Bug登录失败帮我修。Agent 很可能直接开始改代码。但我们真正想要的是Root Cause AnalysisPrompt 02Bug 根因分析先不要修改代码。 问题 [在这里描述 Bug] 请先调查这个问题的根因。 要求 1. 找到与问题相关的代码路径 2. 从用户操作开始追踪完整执行流程 3. 找出最可能的根因 4. 区分“根因”和“表面现象” 5. 判断是否还有其他地方存在相同问题 6. 给出最小修改方案。 输出格式 Root Cause: 根因是什么 Evidence: 你根据哪些代码判断 Affected Files: 涉及哪些文件 Minimal Fix: 最小修改方案 Risk: 这个修改可能产生什么副作用 暂时不要修改代码。这条非常适合真实项目。因为最怕的情况是Bug A ↓ AI 打补丁 ↓ Bug A 暂时消失 ↓ 真正根因还存在 ↓ 出现 Bug B三、第二阶段才真正让 Codex 修 Bug根因确认以后再执行Prompt 03最小范围修复 Bug根据刚才确认的根因修复这个 Bug。 要求 1. 优先做最小范围修改 2. 不重构无关代码 3. 不改变现有公共 API 4. 不增加新的第三方依赖 5. 保持当前代码风格 6. 为这个 Bug 增加回归测试 7. 运行相关测试 8. 如果测试失败先判断是否由当前修改导致。 完成后告诉我 - 修改了哪些文件 - 每个文件为什么修改 - 增加了哪些测试 - 实际执行了哪些验证命令 - 是否还有剩余风险。这里我最重视一句不重构无关代码因为 AI Coding Agent 很容易修一个 Bug顺手重构半个项目。四、新功能开发不要直接说“帮我实现”例如增加邀请成员功能。听起来非常明确。实际上里面还有很多问题权限 Token 过期时间 重复邀请 并发 已注册用户 未注册用户 撤销邀请所以最好分成 Plan 和 Implement。Prompt 04新功能技术方案我要增加以下功能 [描述你的功能] 暂时不要写代码。 请先阅读项目中相关实现然后给出技术方案。 方案必须包括 1. 当前项目中可以复用哪些模块 2. 需要新增什么 3. 需要修改哪些文件 4. 数据库是否需要改变 5. API 是否需要新增或修改 6. 权限如何控制 7. 异常情况有哪些 8. 并发情况下可能出现什么问题 9. 应该增加哪些测试 10. 是否存在向后兼容风险。 优先选择 最少代码 最少新依赖 最少公共接口变化 最小修改范围 最后给出分步骤 Implementation Plan。 不要实施。Prompt 05按照方案实现功能Plan 没问题以后按照刚才确认的 Implementation Plan 实现功能。 规则 - 不扩大功能范围 - 不修改无关代码 - 优先复用现有工具 - 保持现有 API 风格 - 不增加不必要的依赖 - 所有新的业务逻辑必须有对应测试 - 修改完成后运行相关测试 - 如果项目有 Type Check / Lint也执行相关检查。 不要因为测试失败就直接修改已有测试。 首先判断 是实现有问题 还是测试确实应该改变。 最后输出 Files Changed Tests Added Commands Executed Test Results Remaining Risks这两个 Prompt 配合使用会比帮我实现 XXX稳定很多。五、让 Codex 专门检查 Git Diff我认为这是 AI 编程中一个非常被低估的场景。不是AI 写代码而是AI Review 人写的代码甚至AI Review AI 写的代码OpenAI 当前也把代码审查作为 Codex 的主要工程场景之一。Prompt 06高质量 Git Diff ReviewReview 当前 Git Diff。 先不要修改任何文件。 只关注真正可能影响生产环境的问题 1. Logic Bug 2. Security Issue 3. Race Condition 4. Backwards Compatibility 5. Data Corruption Risk 6. Missing Error Handling 7. Missing Important Tests 8. Performance Regression 不要花大量篇幅讨论 - 命名偏好 - 格式 - 纯审美问题 - 无关紧要的重构建议。 每一个发现必须包含 Severity: Critical / High / Medium / Low File: 具体文件 Problem: 问题是什么 Scenario: 什么情况下会触发 Impact: 可能造成什么后果 Recommended Fix: 建议如何修改 如果没有发现真实问题明确告诉我没有发现 不要为了输出内容而强行寻找问题。最后一句很重要不要为了输出内容而强行寻找问题。六、专门检查安全问题通用 Review 和 Security Review 最好分开。Prompt 07Security Review对当前项目进行安全审查。 暂时不要修改代码。 重点检查 Authentication Authorization SQL Injection Command Injection XSS CSRF SSRF Path Traversal File Upload Rate Limiting Token Handling Password Handling Secrets Exposure Privilege Escalation IDOR 要求 不要只根据理论列安全风险。 必须结合当前代码判断。 每一个问题给出 1. 漏洞位置 2. 触发条件 3. 攻击路径 4. 潜在影响 5. 严重等级 6. 建议修复方式。 如果某一风险已经被现有代码正确防御 也说明现有防御机制在哪里。 先报告不修改。这种 Prompt 的关键在于必须结合当前代码判断否则 AI 很容易给你一份Web 安全十大常见问题百科。七、性能问题不要直接“优化整个项目”这是另一个非常常见的问题。Prompt帮我优化项目性能。范围实在太大。可以改成Prompt 08接口性能分析调查这个接口为什么慢 [接口路径] 先不要修改代码。 从请求入口开始追踪整个执行路径。 重点检查 1. 数据库查询次数 2. 是否存在 N1 3. 是否重复查询相同数据 4. 是否存在不必要的串行操作 5. 外部 API 调用 6. 大量数据转换 7. 不必要的网络请求 8. 缓存使用情况 9. 算法复杂度 10. 是否存在阻塞操作。 最后按照影响排序 P0 P1 P2 给出最可能影响 P95 latency 的三个问题。 不要先重构代码。 先找到真正瓶颈。Prompt 09实施性能优化根据刚才确定的性能瓶颈 只优化优先级最高的问题。 要求 - API 输入输出保持不变 - 不修改数据库 Schema - 暂时不要增加缓存 - 不增加新依赖 - 修改范围尽量小 - 必须保留现有行为。 如果项目存在 Benchmark 或性能测试 运行对应验证。 最后比较 Before After 并说明性能改善来自哪里。这样 Agent 的目标会非常清楚。八、重构代码一定要锁住“行为不变”AI 非常擅长重构。同时也非常容易重构着重构着 把行为也改了所以Prompt 10安全重构 PromptRefactor 以下模块 [模块路径] 目标 提高可读性和可维护性。 严格约束 1. 对外行为完全不变 2. 公共 API 不变 3. 函数输入输出不变 4. 数据库行为不变 5. 错误类型和关键错误信息不变 6. 不添加新功能 7. 不增加第三方依赖 8. 不修改无关模块。 开始之前 先运行现有测试并确认基线。 重构完成之后 再次运行相同测试。 最后展示 Before behavior After behavior Tests before Tests after Files changed重构时最重要的词其实不是Clean而是Behavior Preservation九、数据库 Migration 是非常适合 Agent 的任务例如User 增加 status 字段。不要只让 AI 修改 schema。Prompt 11安全数据库 Migration我要进行以下数据库变更 [描述变更] 先分析现有 Schema 和数据访问代码。 然后设计 migration。 重点考虑 1. 现有数据如何兼容 2. 是否需要默认值 3. NULL 如何处理 4. Migration 是否会锁表 5. 回滚方式 6. 旧版本应用与新 Schema 是否能短暂共存 7. 是否需要分阶段部署 8. 哪些查询需要同步修改。 优先设计 Backwards-Compatible Migration。 先给方案不要直接执行数据库修改。尤其真实生产系统Schema Migration和改 TypeScript interface完全不是一个风险等级。十、让 Codex 自动补测试AI 很适合补测试。但不要写多写点测试。Prompt 12补充有价值的单元测试分析这个模块现有测试覆盖 [模块路径] 不要为了提高 Coverage 数字而机械增加测试。 重点寻找真正重要但尚未覆盖的行为 1. 正常路径 2. 输入边界 3. 空值 4. 非法状态 5. 权限问题 6. 重复请求 7. 并发情况 8. 外部依赖失败 9. 数据库异常 10. 历史 Bug 的回归场景。 先告诉我缺少哪些测试。 按照风险排序。 然后只添加高价值测试。这一条中的关键是不要为了 Coverage 数字而机械增加测试十一、专门让 AI 找“没考虑到的边界条件”开发时间长了会发现Bug 最多的地方通常不是Happy Path而是Edge CasesPrompt 13Edge Case Hunter不要修改代码。 阅读以下功能 [功能或文件] 假设正常路径已经可以工作。 你的任务不是检查正常情况 而是专门寻找 Edge Cases。 从以下角度考虑 - null - empty - zero - negative - duplicate - retry - timeout - concurrency - permission - deleted data - stale data - network failure - partial failure - extremely large input - repeated submission 给出最值得测试的 10 个边界场景。 每个场景说明 Input Expected Behavior Current Behavior Potential Risk这是我非常喜欢的一类 Prompt。十二、前端页面 Bug 也不要只描述“页面不对”Prompt 14React / Next.js 前端 Bug 分析调查以下前端问题 [描述问题] 先不要修改代码。 请追踪 User Action ↓ Component ↓ State ↓ Hook ↓ API Request ↓ Response ↓ State Update ↓ Render 重点检查 1. stale state 2. race condition 3. duplicated request 4. incorrect dependency 5. loading state 6. error state 7. optimistic update 8. component unmount 9. cache invalidation 10. server/client boundary。 找到最可能的根因后 给出最小修改方案。对于 React 项目这种“数据流追踪”往往比帮我看看组件效果更好。十三、TypeScript 项目禁止 AI 用 any 糊弄过去非常经典遇到类型错误。AIconstdata:any...错误没了。问题也被埋起来了。Prompt 15TypeScript 类型修复修复当前 TypeScript 类型错误。 要求 禁止 - 使用 any - 使用 ts-ignore - 使用 ts-nocheck - 删除类型检查 - 无意义的强制类型断言。 优先寻找真正的类型不一致来源。 检查 API response type Database model Shared type Component props Generic Nullable value 目标不是 让 TypeScript 不报错。 目标是 让类型真实反映运行时数据。 修改以后运行 Type Check。这比Fix TypeScript errors靠谱得多。十四、让 Codex 清理技术债但不要让它重写项目Prompt 16Technical Debt Audit对当前项目做一次 Technical Debt Audit。 不要修改代码。 寻找 1. 重复业务逻辑 2. 已废弃代码 3. TODO / FIXME 4. 过度复杂模块 5. 重复数据库查询 6. 绕过类型系统的代码 7. 没有测试保护的关键逻辑 8. 过度耦合 9. 隐式业务规则 10. 高风险 Legacy Code。 按照 Impact × Probability × Fix Cost 进行排序。 只列最值得处理的前 10 项。 不要建议“重写整个系统”。最后一句也是灵魂不要建议重写整个系统。十五、让 AI 判断“这个依赖到底有没有必要”现在很多项目npm install越来越随意。AI 也特别喜欢推荐新库。Prompt 17Dependency Review我要实现 [功能] 在添加任何新的第三方依赖之前 先检查当前项目。 回答 1. 现有依赖是否已经能完成 2. Node / Browser / Framework 原生能力能否完成 3. 自己实现需要多少代码 4. 引入新依赖的收益 5. Bundle Size 影响 6. Maintenance Risk 7. Security Risk 8. Lock-in Risk。 只有当新依赖明显优于现有方案时 才建议添加。 否则优先复用已有能力。十六、让 Codex 帮你拆大型需求假设老板一句话做一个团队权限系统。千万别直接 Implement。Prompt 18大型需求拆解需求 [粘贴完整需求] 不要写代码。 请把这个需求拆成可以独立开发、 独立测试、独立 Review 的任务。 原则 每一个 Task 应尽量 - 修改范围小 - 目标单一 - 可以独立测试 - 可以独立提交 - 尽量减少跨模块依赖。 输出 Phase 1 Task 1 Task 2 Phase 2 Task 3 Task 4 Phase 3 Task 5 每一个 Task 写清楚 Goal Affected Modules Dependencies Tests Risk Definition of Done 最后给出推荐实施顺序。这就是把“大需求”转换成Agent 可以执行的小任务十七、让 Codex 做上线前最后一次检查Prompt 19Pre-Release Review假设当前 Branch 明天就要上线生产环境。 不要修改代码。 对当前 Branch 相比主分支的所有修改 进行一次 Pre-Release Review。 重点检查 1. 数据库 Migration 2. 配置变更 3. Environment Variables 4. Breaking Change 5. Authentication 6. Permission 7. Error Handling 8. Logging 9. Monitoring 10. Rollback 11. Data Compatibility 12. Tests。 最终输出 BLOCKER 上线前必须解决 WARNING 建议解决 SAFE 已经检查没有明显问题 最后回答 从代码角度 你是否建议当前版本进入生产环境 说明原因。这个场景非常适合在 PR 合并前跑一次。十八、最后一个让 Codex 检查“自己刚才写的代码”这是一个非常简单但特别实用的 Prompt。AI 写完以后不要马上结束。再发Prompt 20Self Review重新检查你刚才完成的所有修改。 把自己当成一个没有参与开发的 Senior Engineer。 不要假设刚才的实现是正确的。 重新阅读 - 原始需求 - Implementation Plan - Git Diff - 相关测试。 重点寻找 1. 是否遗漏需求 2. 是否错误理解需求 3. 是否修改了无关代码 4. 是否存在更小的实现方案 5. 是否引入 Bug 6. 是否存在并发问题 7. 是否有安全问题 8. 是否破坏向后兼容 9. 测试是否真的覆盖核心行为 10. 是否存在“测试通过但功能错误”的可能。 先只 Review。 不要立即修改。 如果发现问题 按严重程度告诉我。我经常建议在复杂任务结束时做这一步。因为Implement Mode和Review Mode实际上是两种不同的思考方式。十九、这 20 个 Prompt 背后的共同规律如果仔细观察前面的 Prompt会发现我并没有使用很多所谓的神奇咒语例如你是世界顶级程序员或者你拥有 20 年开发经验真正反复出现的是这些东西Goal Scope Constraints Process Verification Output也就是Goal到底要解决什么问题Scope允许修改什么Constraints不能做什么Process先分析还是直接开发Verification怎么证明完成了Output最终我要看到什么这六个部分比大量形容词重要得多。二十、我现在最常用的万能 Codex Prompt 模板如果上面 20 条你不想全部保存只保存一条可以保存下面这个Task: [描述任务] Goal: [最终希望实现什么] Before Coding: 先阅读相关代码并理解当前实现。 如果任务涉及多个模块 先输出 Implementation Plan。 暂时不要立即修改。 Constraints: - Prefer the smallest reasonable change. - Do not modify unrelated code. - Do not introduce new dependencies unless necessary. - Preserve existing public APIs. - Follow existing project patterns. - Reuse existing utilities whenever possible. Implementation: 按照确认后的方案实现。 Verification: 修改完成后 1. 运行相关测试 2. 运行 Type Check 3. 根据项目情况运行 Lint / Build 4. 修复由当前修改引入的问题。 Review: 重新检查 Git Diff。 重点检查 - logic bugs - security issues - race conditions - backwards compatibility - missing tests Final Report: 告诉我 1. Changed Files 2. What Changed 3. Tests Executed 4. Test Results 5. Remaining Risks然后每次只替换Task和Goal就已经能覆盖大量日常开发场景。二十一、ChatGPT Plus / Pro Codex 真正拉开效率差距的地方很多开发者刚开始使用 ChatGPT 编程时关注的是这个模型会不会写代码后来关注生成的代码准确率高不高但进入 Coding Agent 阶段以后我认为应该增加另外几个问题它是否理解我的仓库它是否知道修改边界它有没有真的运行测试它能否自己检查 Git Diff它有没有破坏原有行为任务失败以后能否继续调查Codex 现在已经不仅存在于单一聊天窗口中而是覆盖 ChatGPT、终端、编辑器以及 Codex App 等开发入口官方也在持续强化多 Agent、代码审查和工程任务执行能力。与此同时Codex 还支持通过AGENTS.md为项目提供持续性的开发指导这意味着很多以前每次都需要重新写进 Prompt 的规则可以进一步沉淀成项目上下文。因此真正值得建立的不是Prompt 收藏夹而是自己的 AI Development Workflow二十二、推荐的实际工作流程我现在更推荐需求 ↓ ChatGPT 分析 ↓ 形成明确 Task ↓ Codex Explore ↓ Codex Plan ↓ 人工检查 Plan ↓ Codex Implement ↓ Codex Test ↓ Codex Review ↓ 人工检查 Git Diff ↓ Commit复杂任务再增加Security Review Performance Review Edge Case Review Pre-Release Review于是 ChatGPT / Codex 就不再只是代码生成器而逐渐成为需求分析 代码搜索 方案设计 开发 测试 Review这一整套工程工作流的一部分。结语如果 2023 年使用 ChatGPT 写代码的核心技巧是学会向 AI 提问。那么到了现在我认为更重要的是学会给 AI 定义任务边界。特别是在 ChatGPT Plus、Pro 和 Codex 这样的工具组合逐渐进入真实开发流程以后Prompt 的价值已经不只是让回答更漂亮而是控制 Agent 行为真正好用的开发 Prompt往往都会告诉 AI你要解决什么你先做什么你不能做什么你可以修改什么你如何证明已经完成如果把这些基本原则建立起来即使没有所谓的“神级 Prompt”日常使用 ChatGPT 和 Codex 的稳定性也会提高很多。最终真正值得积累的也不是1000 条 Prompt而是一套属于自己的ChatGPT Codex AI 编程工作流Prompt 会不断变化。模型会不断升级。Plus、Pro 的具体产品能力和使用方式也可能继续变化。但是软件工程最核心的几个原则不会轻易改变理解问题 ↓ 控制范围 ↓ 最小修改 ↓ 运行验证 ↓ 代码审查 ↓ 再交付当 AI 真正进入软件开发流程之后这些原则反而比以前更重要。 ChatGPT Plus / Pro + Codex 编程实战：20 个开发者可直接复制的高质量 Prompt
很多人使用 ChatGPT 或 Codex 写代码时最常输入的一句话可能是帮我看看这段代码。或者帮我修复这个 Bug。再或者帮我把这个项目优化一下。不能说这些 Prompt 没有用。但如果你真正开始让 Codex 接触完整项目就会发现一个非常明显的问题任务描述越模糊AI 自由发挥的空间越大。而在软件工程里面自由发挥很多时候并不是优点。因为你真正需要的通常是只修这个 Bug 不要改其他功能 不要随便加依赖 不要改变 API 先找到根因 修改以后跑测试这也是我现在使用 ChatGPT、Plus、Pro 和 Codex 时越来越重视的一点Prompt 的核心不是“写得长”而是“边界清楚”。目前 OpenAI 对 Codex 的定位已经明显偏向完整的软件工程 Agent它可以围绕真实代码仓库完成开发、重构、迁移、代码审查等任务Codex CLI 也能够在终端环境中检查代码、编辑文件以及执行命令。所以这篇不讨论什么复杂的 Prompt 理论。直接整理20 个我认为开发者真正用得上的 Codex Prompt基本都可以直接复制然后根据自己的项目稍微修改。一、项目接手先让 Codex 看懂整个仓库这是我认为最值得保存的一条 Prompt。第一次让 Codex 进入一个陌生项目时不要立刻帮我优化这个项目。先让它做 Repository Exploration。Prompt 01快速理解陌生项目先不要修改任何文件。 请系统阅读当前代码仓库并帮助我快速理解这个项目。 重点分析 1. 项目的主要技术栈 2. 程序入口 3. 核心目录分别负责什么 4. 数据库访问方式 5. 用户认证方式 6. API 的组织方式 7. 前端状态管理方式 8. 测试框架和测试目录 9. 构建、Lint、Type Check 命令 10. 项目中最重要的 5 个核心模块。 最后给我输出 - 项目架构概览 - 一次正常请求的数据流 - 最重要的文件 - 新开发者最容易踩坑的地方。 暂时不要修改代码。它适合接手旧项目 开源项目研究 公司历史项目 第一次让 Codex 进入仓库这里最重要的是暂时不要修改代码先建立正确上下文。二、不要直接修 Bug先让它找“根因”很多人遇到 Bug登录失败帮我修。Agent 很可能直接开始改代码。但我们真正想要的是Root Cause AnalysisPrompt 02Bug 根因分析先不要修改代码。 问题 [在这里描述 Bug] 请先调查这个问题的根因。 要求 1. 找到与问题相关的代码路径 2. 从用户操作开始追踪完整执行流程 3. 找出最可能的根因 4. 区分“根因”和“表面现象” 5. 判断是否还有其他地方存在相同问题 6. 给出最小修改方案。 输出格式 Root Cause: 根因是什么 Evidence: 你根据哪些代码判断 Affected Files: 涉及哪些文件 Minimal Fix: 最小修改方案 Risk: 这个修改可能产生什么副作用 暂时不要修改代码。这条非常适合真实项目。因为最怕的情况是Bug A ↓ AI 打补丁 ↓ Bug A 暂时消失 ↓ 真正根因还存在 ↓ 出现 Bug B三、第二阶段才真正让 Codex 修 Bug根因确认以后再执行Prompt 03最小范围修复 Bug根据刚才确认的根因修复这个 Bug。 要求 1. 优先做最小范围修改 2. 不重构无关代码 3. 不改变现有公共 API 4. 不增加新的第三方依赖 5. 保持当前代码风格 6. 为这个 Bug 增加回归测试 7. 运行相关测试 8. 如果测试失败先判断是否由当前修改导致。 完成后告诉我 - 修改了哪些文件 - 每个文件为什么修改 - 增加了哪些测试 - 实际执行了哪些验证命令 - 是否还有剩余风险。这里我最重视一句不重构无关代码因为 AI Coding Agent 很容易修一个 Bug顺手重构半个项目。四、新功能开发不要直接说“帮我实现”例如增加邀请成员功能。听起来非常明确。实际上里面还有很多问题权限 Token 过期时间 重复邀请 并发 已注册用户 未注册用户 撤销邀请所以最好分成 Plan 和 Implement。Prompt 04新功能技术方案我要增加以下功能 [描述你的功能] 暂时不要写代码。 请先阅读项目中相关实现然后给出技术方案。 方案必须包括 1. 当前项目中可以复用哪些模块 2. 需要新增什么 3. 需要修改哪些文件 4. 数据库是否需要改变 5. API 是否需要新增或修改 6. 权限如何控制 7. 异常情况有哪些 8. 并发情况下可能出现什么问题 9. 应该增加哪些测试 10. 是否存在向后兼容风险。 优先选择 最少代码 最少新依赖 最少公共接口变化 最小修改范围 最后给出分步骤 Implementation Plan。 不要实施。Prompt 05按照方案实现功能Plan 没问题以后按照刚才确认的 Implementation Plan 实现功能。 规则 - 不扩大功能范围 - 不修改无关代码 - 优先复用现有工具 - 保持现有 API 风格 - 不增加不必要的依赖 - 所有新的业务逻辑必须有对应测试 - 修改完成后运行相关测试 - 如果项目有 Type Check / Lint也执行相关检查。 不要因为测试失败就直接修改已有测试。 首先判断 是实现有问题 还是测试确实应该改变。 最后输出 Files Changed Tests Added Commands Executed Test Results Remaining Risks这两个 Prompt 配合使用会比帮我实现 XXX稳定很多。五、让 Codex 专门检查 Git Diff我认为这是 AI 编程中一个非常被低估的场景。不是AI 写代码而是AI Review 人写的代码甚至AI Review AI 写的代码OpenAI 当前也把代码审查作为 Codex 的主要工程场景之一。Prompt 06高质量 Git Diff ReviewReview 当前 Git Diff。 先不要修改任何文件。 只关注真正可能影响生产环境的问题 1. Logic Bug 2. Security Issue 3. Race Condition 4. Backwards Compatibility 5. Data Corruption Risk 6. Missing Error Handling 7. Missing Important Tests 8. Performance Regression 不要花大量篇幅讨论 - 命名偏好 - 格式 - 纯审美问题 - 无关紧要的重构建议。 每一个发现必须包含 Severity: Critical / High / Medium / Low File: 具体文件 Problem: 问题是什么 Scenario: 什么情况下会触发 Impact: 可能造成什么后果 Recommended Fix: 建议如何修改 如果没有发现真实问题明确告诉我没有发现 不要为了输出内容而强行寻找问题。最后一句很重要不要为了输出内容而强行寻找问题。六、专门检查安全问题通用 Review 和 Security Review 最好分开。Prompt 07Security Review对当前项目进行安全审查。 暂时不要修改代码。 重点检查 Authentication Authorization SQL Injection Command Injection XSS CSRF SSRF Path Traversal File Upload Rate Limiting Token Handling Password Handling Secrets Exposure Privilege Escalation IDOR 要求 不要只根据理论列安全风险。 必须结合当前代码判断。 每一个问题给出 1. 漏洞位置 2. 触发条件 3. 攻击路径 4. 潜在影响 5. 严重等级 6. 建议修复方式。 如果某一风险已经被现有代码正确防御 也说明现有防御机制在哪里。 先报告不修改。这种 Prompt 的关键在于必须结合当前代码判断否则 AI 很容易给你一份Web 安全十大常见问题百科。七、性能问题不要直接“优化整个项目”这是另一个非常常见的问题。Prompt帮我优化项目性能。范围实在太大。可以改成Prompt 08接口性能分析调查这个接口为什么慢 [接口路径] 先不要修改代码。 从请求入口开始追踪整个执行路径。 重点检查 1. 数据库查询次数 2. 是否存在 N1 3. 是否重复查询相同数据 4. 是否存在不必要的串行操作 5. 外部 API 调用 6. 大量数据转换 7. 不必要的网络请求 8. 缓存使用情况 9. 算法复杂度 10. 是否存在阻塞操作。 最后按照影响排序 P0 P1 P2 给出最可能影响 P95 latency 的三个问题。 不要先重构代码。 先找到真正瓶颈。Prompt 09实施性能优化根据刚才确定的性能瓶颈 只优化优先级最高的问题。 要求 - API 输入输出保持不变 - 不修改数据库 Schema - 暂时不要增加缓存 - 不增加新依赖 - 修改范围尽量小 - 必须保留现有行为。 如果项目存在 Benchmark 或性能测试 运行对应验证。 最后比较 Before After 并说明性能改善来自哪里。这样 Agent 的目标会非常清楚。八、重构代码一定要锁住“行为不变”AI 非常擅长重构。同时也非常容易重构着重构着 把行为也改了所以Prompt 10安全重构 PromptRefactor 以下模块 [模块路径] 目标 提高可读性和可维护性。 严格约束 1. 对外行为完全不变 2. 公共 API 不变 3. 函数输入输出不变 4. 数据库行为不变 5. 错误类型和关键错误信息不变 6. 不添加新功能 7. 不增加第三方依赖 8. 不修改无关模块。 开始之前 先运行现有测试并确认基线。 重构完成之后 再次运行相同测试。 最后展示 Before behavior After behavior Tests before Tests after Files changed重构时最重要的词其实不是Clean而是Behavior Preservation九、数据库 Migration 是非常适合 Agent 的任务例如User 增加 status 字段。不要只让 AI 修改 schema。Prompt 11安全数据库 Migration我要进行以下数据库变更 [描述变更] 先分析现有 Schema 和数据访问代码。 然后设计 migration。 重点考虑 1. 现有数据如何兼容 2. 是否需要默认值 3. NULL 如何处理 4. Migration 是否会锁表 5. 回滚方式 6. 旧版本应用与新 Schema 是否能短暂共存 7. 是否需要分阶段部署 8. 哪些查询需要同步修改。 优先设计 Backwards-Compatible Migration。 先给方案不要直接执行数据库修改。尤其真实生产系统Schema Migration和改 TypeScript interface完全不是一个风险等级。十、让 Codex 自动补测试AI 很适合补测试。但不要写多写点测试。Prompt 12补充有价值的单元测试分析这个模块现有测试覆盖 [模块路径] 不要为了提高 Coverage 数字而机械增加测试。 重点寻找真正重要但尚未覆盖的行为 1. 正常路径 2. 输入边界 3. 空值 4. 非法状态 5. 权限问题 6. 重复请求 7. 并发情况 8. 外部依赖失败 9. 数据库异常 10. 历史 Bug 的回归场景。 先告诉我缺少哪些测试。 按照风险排序。 然后只添加高价值测试。这一条中的关键是不要为了 Coverage 数字而机械增加测试十一、专门让 AI 找“没考虑到的边界条件”开发时间长了会发现Bug 最多的地方通常不是Happy Path而是Edge CasesPrompt 13Edge Case Hunter不要修改代码。 阅读以下功能 [功能或文件] 假设正常路径已经可以工作。 你的任务不是检查正常情况 而是专门寻找 Edge Cases。 从以下角度考虑 - null - empty - zero - negative - duplicate - retry - timeout - concurrency - permission - deleted data - stale data - network failure - partial failure - extremely large input - repeated submission 给出最值得测试的 10 个边界场景。 每个场景说明 Input Expected Behavior Current Behavior Potential Risk这是我非常喜欢的一类 Prompt。十二、前端页面 Bug 也不要只描述“页面不对”Prompt 14React / Next.js 前端 Bug 分析调查以下前端问题 [描述问题] 先不要修改代码。 请追踪 User Action ↓ Component ↓ State ↓ Hook ↓ API Request ↓ Response ↓ State Update ↓ Render 重点检查 1. stale state 2. race condition 3. duplicated request 4. incorrect dependency 5. loading state 6. error state 7. optimistic update 8. component unmount 9. cache invalidation 10. server/client boundary。 找到最可能的根因后 给出最小修改方案。对于 React 项目这种“数据流追踪”往往比帮我看看组件效果更好。十三、TypeScript 项目禁止 AI 用 any 糊弄过去非常经典遇到类型错误。AIconstdata:any...错误没了。问题也被埋起来了。Prompt 15TypeScript 类型修复修复当前 TypeScript 类型错误。 要求 禁止 - 使用 any - 使用 ts-ignore - 使用 ts-nocheck - 删除类型检查 - 无意义的强制类型断言。 优先寻找真正的类型不一致来源。 检查 API response type Database model Shared type Component props Generic Nullable value 目标不是 让 TypeScript 不报错。 目标是 让类型真实反映运行时数据。 修改以后运行 Type Check。这比Fix TypeScript errors靠谱得多。十四、让 Codex 清理技术债但不要让它重写项目Prompt 16Technical Debt Audit对当前项目做一次 Technical Debt Audit。 不要修改代码。 寻找 1. 重复业务逻辑 2. 已废弃代码 3. TODO / FIXME 4. 过度复杂模块 5. 重复数据库查询 6. 绕过类型系统的代码 7. 没有测试保护的关键逻辑 8. 过度耦合 9. 隐式业务规则 10. 高风险 Legacy Code。 按照 Impact × Probability × Fix Cost 进行排序。 只列最值得处理的前 10 项。 不要建议“重写整个系统”。最后一句也是灵魂不要建议重写整个系统。十五、让 AI 判断“这个依赖到底有没有必要”现在很多项目npm install越来越随意。AI 也特别喜欢推荐新库。Prompt 17Dependency Review我要实现 [功能] 在添加任何新的第三方依赖之前 先检查当前项目。 回答 1. 现有依赖是否已经能完成 2. Node / Browser / Framework 原生能力能否完成 3. 自己实现需要多少代码 4. 引入新依赖的收益 5. Bundle Size 影响 6. Maintenance Risk 7. Security Risk 8. Lock-in Risk。 只有当新依赖明显优于现有方案时 才建议添加。 否则优先复用已有能力。十六、让 Codex 帮你拆大型需求假设老板一句话做一个团队权限系统。千万别直接 Implement。Prompt 18大型需求拆解需求 [粘贴完整需求] 不要写代码。 请把这个需求拆成可以独立开发、 独立测试、独立 Review 的任务。 原则 每一个 Task 应尽量 - 修改范围小 - 目标单一 - 可以独立测试 - 可以独立提交 - 尽量减少跨模块依赖。 输出 Phase 1 Task 1 Task 2 Phase 2 Task 3 Task 4 Phase 3 Task 5 每一个 Task 写清楚 Goal Affected Modules Dependencies Tests Risk Definition of Done 最后给出推荐实施顺序。这就是把“大需求”转换成Agent 可以执行的小任务十七、让 Codex 做上线前最后一次检查Prompt 19Pre-Release Review假设当前 Branch 明天就要上线生产环境。 不要修改代码。 对当前 Branch 相比主分支的所有修改 进行一次 Pre-Release Review。 重点检查 1. 数据库 Migration 2. 配置变更 3. Environment Variables 4. Breaking Change 5. Authentication 6. Permission 7. Error Handling 8. Logging 9. Monitoring 10. Rollback 11. Data Compatibility 12. Tests。 最终输出 BLOCKER 上线前必须解决 WARNING 建议解决 SAFE 已经检查没有明显问题 最后回答 从代码角度 你是否建议当前版本进入生产环境 说明原因。这个场景非常适合在 PR 合并前跑一次。十八、最后一个让 Codex 检查“自己刚才写的代码”这是一个非常简单但特别实用的 Prompt。AI 写完以后不要马上结束。再发Prompt 20Self Review重新检查你刚才完成的所有修改。 把自己当成一个没有参与开发的 Senior Engineer。 不要假设刚才的实现是正确的。 重新阅读 - 原始需求 - Implementation Plan - Git Diff - 相关测试。 重点寻找 1. 是否遗漏需求 2. 是否错误理解需求 3. 是否修改了无关代码 4. 是否存在更小的实现方案 5. 是否引入 Bug 6. 是否存在并发问题 7. 是否有安全问题 8. 是否破坏向后兼容 9. 测试是否真的覆盖核心行为 10. 是否存在“测试通过但功能错误”的可能。 先只 Review。 不要立即修改。 如果发现问题 按严重程度告诉我。我经常建议在复杂任务结束时做这一步。因为Implement Mode和Review Mode实际上是两种不同的思考方式。十九、这 20 个 Prompt 背后的共同规律如果仔细观察前面的 Prompt会发现我并没有使用很多所谓的神奇咒语例如你是世界顶级程序员或者你拥有 20 年开发经验真正反复出现的是这些东西Goal Scope Constraints Process Verification Output也就是Goal到底要解决什么问题Scope允许修改什么Constraints不能做什么Process先分析还是直接开发Verification怎么证明完成了Output最终我要看到什么这六个部分比大量形容词重要得多。二十、我现在最常用的万能 Codex Prompt 模板如果上面 20 条你不想全部保存只保存一条可以保存下面这个Task: [描述任务] Goal: [最终希望实现什么] Before Coding: 先阅读相关代码并理解当前实现。 如果任务涉及多个模块 先输出 Implementation Plan。 暂时不要立即修改。 Constraints: - Prefer the smallest reasonable change. - Do not modify unrelated code. - Do not introduce new dependencies unless necessary. - Preserve existing public APIs. - Follow existing project patterns. - Reuse existing utilities whenever possible. Implementation: 按照确认后的方案实现。 Verification: 修改完成后 1. 运行相关测试 2. 运行 Type Check 3. 根据项目情况运行 Lint / Build 4. 修复由当前修改引入的问题。 Review: 重新检查 Git Diff。 重点检查 - logic bugs - security issues - race conditions - backwards compatibility - missing tests Final Report: 告诉我 1. Changed Files 2. What Changed 3. Tests Executed 4. Test Results 5. Remaining Risks然后每次只替换Task和Goal就已经能覆盖大量日常开发场景。二十一、ChatGPT Plus / Pro Codex 真正拉开效率差距的地方很多开发者刚开始使用 ChatGPT 编程时关注的是这个模型会不会写代码后来关注生成的代码准确率高不高但进入 Coding Agent 阶段以后我认为应该增加另外几个问题它是否理解我的仓库它是否知道修改边界它有没有真的运行测试它能否自己检查 Git Diff它有没有破坏原有行为任务失败以后能否继续调查Codex 现在已经不仅存在于单一聊天窗口中而是覆盖 ChatGPT、终端、编辑器以及 Codex App 等开发入口官方也在持续强化多 Agent、代码审查和工程任务执行能力。与此同时Codex 还支持通过AGENTS.md为项目提供持续性的开发指导这意味着很多以前每次都需要重新写进 Prompt 的规则可以进一步沉淀成项目上下文。因此真正值得建立的不是Prompt 收藏夹而是自己的 AI Development Workflow二十二、推荐的实际工作流程我现在更推荐需求 ↓ ChatGPT 分析 ↓ 形成明确 Task ↓ Codex Explore ↓ Codex Plan ↓ 人工检查 Plan ↓ Codex Implement ↓ Codex Test ↓ Codex Review ↓ 人工检查 Git Diff ↓ Commit复杂任务再增加Security Review Performance Review Edge Case Review Pre-Release Review于是 ChatGPT / Codex 就不再只是代码生成器而逐渐成为需求分析 代码搜索 方案设计 开发 测试 Review这一整套工程工作流的一部分。结语如果 2023 年使用 ChatGPT 写代码的核心技巧是学会向 AI 提问。那么到了现在我认为更重要的是学会给 AI 定义任务边界。特别是在 ChatGPT Plus、Pro 和 Codex 这样的工具组合逐渐进入真实开发流程以后Prompt 的价值已经不只是让回答更漂亮而是控制 Agent 行为真正好用的开发 Prompt往往都会告诉 AI你要解决什么你先做什么你不能做什么你可以修改什么你如何证明已经完成如果把这些基本原则建立起来即使没有所谓的“神级 Prompt”日常使用 ChatGPT 和 Codex 的稳定性也会提高很多。最终真正值得积累的也不是1000 条 Prompt而是一套属于自己的ChatGPT Codex AI 编程工作流Prompt 会不断变化。模型会不断升级。Plus、Pro 的具体产品能力和使用方式也可能继续变化。但是软件工程最核心的几个原则不会轻易改变理解问题 ↓ 控制范围 ↓ 最小修改 ↓ 运行验证 ↓ 代码审查 ↓ 再交付当 AI 真正进入软件开发流程之后这些原则反而比以前更重要。