直接答案
提示词的目标不是写得长，而是让范围、约束、证据和决策边界足够明确，使 Codex 能持续校正。
这篇内容解决什么问题
改进 Codex CLI 提示词并拆分复杂编码任务
用五个要素定义任务契约
稳定的工程提示词至少说明目标行为、当前证据、允许范围、必须遵守的约束和验证方式。停止条件同样重要：遇到协议歧义、依赖变更或破坏性操作时，应要求 Codex 先提问。
不要把未经验证的实现方案伪装成需求。提供复现步骤与用户可观察行为，让 Codex先调查现有设计，再选择与仓库一致的实现。
- 目标：哪个用户行为或工程结果需要变化。
- 证据：错误、失败测试、日志或相关文件。
- 范围：允许修改和明确禁止修改的模块。
- 约束：兼容性、依赖、性能、安全与编码规范。
- 验证：必须运行的命令及预期判定方式。
把探索与修改分成两次授权
根因未知时先使用只读沙箱。要求 Codex 定位入口、追踪数据流、复现问题并列出候选方案，确认计划后再启动可写会话。
这种拆分不会保证计划一定正确，但能让人类在文件改变前发现范围误判、协议破坏和缺失信息。
codex -C /path/to/repo -s read-only "复现 issue 中的超时问题，追踪从入口到网络请求的数据流，说明根因和两种修复方案。列出会修改的文件及验证命令，不要改文件。"codex -C /path/to/repo -s workspace-write -a on-request "按已确认的最小方案实现。先补回归测试，只改计划列出的文件；运行相关测试和静态检查，失败时修复根因，不要跳过检查。"按决策边界拆分复杂任务
不要按“前端一半、后端一半”机械切割。更稳妥的拆分顺序是调查事实、确认契约、实现最小纵向路径、补异常路径、验证与审查。每一步都有独立产物和继续条件。
当某一步需要用户选择 API、数据库迁移或新依赖时暂停，不要让模型替业务所有者做不可逆决定。
- 01建立事实定位现有入口、调用链、测试和约束，不修改文件。
- 02确认契约定义输入、输出、错误行为和兼容边界。
- 03最小实现完成一条端到端路径并添加对应测试。
- 04补齐边界处理失败、取消、超时、权限和回滚。
- 05独立复核运行全套必要检查并审阅最终 diff。
提供定位线索，而不是倾倒上下文
明确文件路径、符号名、复现命令和已有范例，能减少无关文件读取。不要一次粘贴整个日志或代码库；先保留最小复现，再允许 Codex按需读取。
长期仓库事实放在 AGENTS.md，专项流程放在 Skill，当前任务的验收标准留在提示词。把所有内容塞进一条提示会增加冲突并消耗上下文。
问题：`src/auth/session.ts` 在 token 刚过期时返回 500，而接口契约要求 401。
复现：运行 `<targeted-test-command>`。
参考：错误映射模式见 `src/api/errors.ts`。
范围：只改 auth 模块与对应测试，不改公共响应结构。
验证：目标测试、auth 测试组、类型检查。
断点：如果必须修改共享错误协议，先说明影响并等待确认。把验证写进同一任务
“修复后告诉我”把质量判断留给自然语言总结。更好的提示会指定 Codex 能运行的检查，并要求展示命令、退出状态和仍未验证的部分。
对于界面任务提供可比较截图，对于数据转换提供固定输入输出，对于并发问题提供压力或竞态测试。验证信号越明确，代理越能自主迭代。
codex -C /path/to/repo "修复目标失败。完成后运行最窄测试、相关模块测试和 git diff --check；若检查失败，继续修复直到通过或遇到需要我决策的阻塞。最终列出每条命令及结果，不要声称未运行的检查已通过。"用短反馈及时纠偏
发现方向偏离时立即停止扩展范围，指出具体不符合项并重申约束。不要在错误方案上连续追加多个新需求。
任务完成后，把重复出现的仓库事实沉淀到 AGENTS.md；不要把某次临时选择永久化。有效提示词来自对真实失败的持续修正。
- 指出哪一个观察或假设错误。
- 要求回到最近一个已验证状态。
- 重新限定文件与接口边界。
- 必要时重新进入只读调查。
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法