Codex 提示设计
我现在怎样给 Codex 写任务：范围、文件、边界与验收
我不追求一条“神 Prompt”。真正稳定的是一份短任务书：要得到什么、先看哪里、什么不能碰、怎样证明完成。
- 个人观察
- 清楚写出不修改范围和验收命令后，Agent 更少做无关重构，也更少追问。
- 已核实
- OpenAI 的 Codex prompting 指南强调工具、持续性、验证和输出控制；仓库级 AGENTS.md 适合保存重复规则。
- 适用边界
- 模板不能替代需求判断。未知根因的诊断任务仍需要允许探索。
先看结论
- 目标写结果，不写空泛动作。
- 给文件入口和禁止修改范围，减少无边界探索。
- 把完成标准写成可运行命令和可观察行为。
五行任务书
- 01目标
- 02上下文
- 03边界
- 04验收
- 05节奏
一份任务只保留一个主结果
“优化这个项目”会迫使 Agent 自己发明优先级。我会改成可以交付的结果，例如“让博客文章在五种语言下静态生成，并进入 sitemap”。相关的 metadata、schema 和内链属于同一个结果；另一个产品功能不混进来。
如果任务确实很大，我先写已批准的规格或计划，再让 Agent 执行。这样探索发生在设计阶段，实施阶段围绕一个边界前进。
给入口，也给禁区
列出最可能相关的文件、现有 helper 和必须沿用的框架，让 Agent 有正确起点。同时写清不能部署、不能改动其他 app、不能恢复已退休功能等边界。
入口不是要求 Agent 只读这些文件；它仍可搜索依赖关系。禁区则应当具体到环境、目录或行为，避免“不要乱改”这种无法验收的表达。
把完成改写成证据
“做完”需要被翻译成测试、构建、页面行为和外部动作边界。比如：测试 0 失败、构建退出码 0、Chrome 390px 无横向溢出、文章只有一个 H1、未执行生产部署。
我也会写测试节奏：实现过程中跑必要的针对性检查；所有相关工作完成后再跑完整测试、构建和浏览器验收。这样既保留早期风险反馈，也避免反复产生同一套全量日志。
我常用的五行任务书
下面五项足够覆盖大多数编码任务。它不是必须逐字复制的 Prompt，而是一张检查表。缺少其中一项时，我先判断它是否会让执行方向发生变化。
- 目标：最终用户或系统获得什么结果。
- 上下文：相关路径、现有规范、已批准设计。
- 边界：不能改什么，不能执行哪些外部动作。
- 验收：测试命令与需要观察的页面行为。
- 节奏：何时探索、何时实现、何时统一验证。
rootchen 的提示词观
好的任务书不会让模型少思考，而是让思考集中在真正未知的部分。省下来的不是几个字，而是错误方向上的工具调用和返工。