Codex 提示词写法：让任务目标、范围和验收标准更清楚

适用场景

这篇手册适合想减少 Codex 误解、误改和来回返工的用户。无论你用 Codex App、CLI 还是 IDE Extension，任务提示词的质量都会直接影响结果。

OpenAI 官方文档强调，给 Codex 的任务应尽量明确目标和约束。你不需要写复杂模板，但需要把关键上下文讲清楚。

步骤 1：用一句话写清楚目标

先告诉 Codex 你真正要完成什么。

不够清楚的写法：

优化文章页。

更好的写法：

请优化文章详情页的阅读体验：增加左侧文档目录、保留现有设计风格，并确保移动端不遮挡正文。

目标越具体，Codex 越不容易把任务扩展到无关方向。

步骤 2：写清楚范围

如果你知道相关目录或文件，直接写出来。

示例：

主要修改范围：
- src/app/manual
- src/components/manual-sidebar.tsx
- content/manual

不要修改 news 和 tutorials 的现有 URL。

范围说明有两个作用：帮助 Codex 更快定位代码，也能减少它改到无关模块。

步骤 3：写清楚限制条件

限制条件应该具体、可执行。

适合写进提示词的限制：

• 不要生成概念图或占位图。
• 保持现有 Tailwind 设计系统。
• 不要引入新的 UI 框架。
• 不要修改文章 slug。
• 先不要提交 Git。
• 只做方案分析，不改文件。

示例：

如果没有官方软件截图，文章可以无图发布。不要使用 AI 生成示意图、抽象封面或非 Codex 产品截图。

这类限制比“注意专业一点”更容易执行。

步骤 4：给出验收标准

验收标准能让 Codex 知道任务什么时候算完成。

示例：

验收标准：
- /manual 页面能展示全部已发布手册。
- 手册详情页左侧显示目录并高亮当前文章。
- sitemap、rss 和站内搜索包含 manual 内容。
- 运行 lint 和 next build 通过。

如果是内容任务，也可以写：

每篇文章必须包含 title、description、date、updated、category、tags、source、status。

步骤 5：复杂任务先让 Codex 只读分析

如果你担心 Codex 改得太快，可以先要求它不要动文件。

示例：

请先不要修改代码。先阅读当前实现，告诉我你会改哪些文件、为什么改、有哪些风险。

确认方向后，再继续：

按刚才的方案继续实现，并在完成后运行 lint 和 build。

这种两段式工作流很适合架构调整、内容迁移和发布前检查。

步骤 6：把长期规则放进 AGENTS.md

不要每次都重复项目固定规则。长期有效的规则应写进 AGENTS.md。

适合放进 AGENTS.md：

• 内容目录规范。
• frontmatter 必填字段。
• 设计系统要求。
• 验证命令。
• 不允许修改的目录。

当前任务提示词只需要写本次目标和临时限制。

常见错误

不要只说“帮我完善一下”。Codex 会需要猜测完善方向。

不要把多个互不相关的任务塞进一个提示词。最好拆成独立任务。

不要省略“不要做什么”。如果某些行为不可接受，要明确写出来。

不要只要求“高质量”，而不说明怎样验证质量。

小结

好的 Codex 提示词通常包含五件事：目标、范围、限制、验收标准和验证方式。复杂任务先只读分析，确认后再修改；长期规则沉淀到 AGENTS.md。这样 Codex 更像稳定协作者，而不是凭感觉行动的自动补全工具。