Codex 提示词写得好不好，直接影响它能否像靠谱队友一样理解需求、阅读代码、修改文件并验证结果。下面这篇分享面向刚开始使用 Codex 的开发者，重点讲清楚“怎么说清任务、怎么控制范围、怎么让结果更可审查”。🚀
一、先理解 Codex：它不是普通聊天机器人
使用 Codex 时，很多新手会把它当成“代码问答工具”，只输入一句“帮我优化这个项目”。这类提示词太宽泛，容易导致 Codex 不知道先看哪里、改到什么程度、何时算完成。更合适的思路是把它当成一个可以执行任务的编程助手：你要告诉它目标、上下文、约束和验收标准。OpenAI 的提示词学习资料也强调，好的提示通常包含目标、上下文、输出格式和边界条件，详情可参考 Prompting 官方说明。
二、一个实用提示词结构：目标、背景、限制、完成标准
我最常用的 Codex 提示词模板如下：先说“我要做什么”，再说“相关文件在哪里”，然后说明“不要做什么”，最后写清楚“什么情况算完成”。这个结构看似简单，但能显著减少来回沟通。
示例：请修复登录页在移动端按钮错位的问题。相关文件在 src/pages/Login.tsx 和 src/styles/login.css。不要重构登录流程，不要修改接口调用逻辑。完成标准是：移动端 375px 宽度下按钮居中，桌面端布局不受影响，并说明修改了哪些样式。
这个例子比“帮我修一下登录页样式”更有效，因为它明确了范围、文件、禁止项和验收方式。Codex 在大代码库中尤其需要这些信息，否则它可能花时间探索不相关目录，或者做出超出预期的重构。
三、复杂任务先让 Codex 制定计划 🧭
如果任务涉及多文件修改、架构调整、性能问题或难复现 bug，不建议一上来就让 Codex 直接改代码。更稳妥的做法是先要求它阅读相关文件并输出计划，例如：“先不要修改代码，请阅读相关实现，列出问题判断、修改方案和风险点”。OpenAI 的 Codex 最佳实践中也提到，复杂或模糊任务适合先规划，再执行，可参考 Codex Best Practices。
计划阶段的价值在于暴露误解。比如你想“优化查询速度”，Codex 可能理解为加缓存，也可能理解为改 SQL、建索引或减少渲染次数。让它先给方案，你就能在真正改代码前纠偏，避免生成一堆看似合理但不符合项目方向的修改。
四、给 Codex 足够上下文，但不要一次塞太多
提示词不是越长越好，而是越相关越好。你可以告诉 Codex 关键文件、报错日志、复现步骤、预期行为、实际行为。如果有测试失败信息，直接贴出最小必要日志，而不是把完整 CI 输出全部丢进去。上下文太多会稀释重点，使 Codex 难以判断真正关键的线索。
- 好上下文：失败的测试名称、关键报错、相关文件路径、最近改动范围。
- 弱上下文：“项目跑不起来，你看看”，但没有命令、日志和环境说明。
- 过量上下文：粘贴几千行无关日志，却没有说明期望 Codex 关注哪一段。
五、把“不要做什么”写进提示词
很多 Codex 失控并不是能力问题，而是边界没说清楚。比如你只想修一个 bug，它却顺手重构了目录结构；你只想补测试，它却修改了业务逻辑。解决方法很直接：在提示中加入限制条件。
请只修改测试文件，不要改生产代码。请保持现有 API 兼容，不要引入新依赖。请优先使用项目已有工具和代码风格。
这些限制能帮助 Codex 做出更符合团队预期的选择。尤其在多人协作项目里，最怕的不是代码不能跑，而是改动范围过大，审查成本飙升。
六、让输出可审查，而不是只要“完成了”
编程助手生成的代码仍然需要人审查。因此，提示词里可以要求 Codex 在完成后说明三件事：修改了哪些文件、为什么这样改、如何验证。这样你不需要从 diff 里盲猜意图，也方便写 PR 描述。
- 请列出修改文件和核心改动。
- 请说明是否影响兼容性或性能。
- 请给出已运行或建议运行的测试命令。
如果 Codex 没有实际运行测试，也应该让它明确说明“未运行测试”的原因，而不是默认假设一切正常。这样做能避免把未经验证的结论带入代码审查。
七、我的日常经验：小步快跑，比一次性大改更稳
实践中，我更推荐把大任务拆成几个小任务。例如不要直接说“重构整个订单模块”，而是分为“梳理订单状态流转”“补齐状态测试”“抽取重复校验逻辑”“清理废弃字段”。每一步都让 Codex 产出可审查的 diff，再继续下一步。
这种方法的好处是风险可控。如果某一步方向不对，可以及时回滚或调整提示。对于遗留项目、缺少测试的项目，尤其应该避免让 Codex 一次性修改太多文件。
八、可直接复用的提示词模板 ✍️
请完成以下任务：____。相关背景：____。请重点查看这些文件：____。限制条件：不要____，保持____。完成标准：____。完成后请总结修改内容、潜在风险和验证方式。
如果是排查 bug，可以改成：
请先不要修改代码。请根据以下现象和日志分析可能原因，并列出排查步骤。现象：____。复现步骤：____。相关日志：____。相关文件：____。请指出最可能的问题位置，并在我确认后再给出修改方案。
总结
Codex 提示词的核心不是写得花哨，而是把任务说清楚：目标明确、上下文准确、边界清晰、验收可验证。对于简单任务，可以直接给出修改要求；对于复杂任务，先让它分析和规划；对于团队项目，一定要控制改动范围并要求说明验证方式。把 Codex 当成一位需要上下文和标准的协作开发者，你会更容易得到稳定、可审查、能落地的代码结果。✅
