一次 Codex 任务的完整闭环
一次 Codex 任务的完整闭环
Section titled “一次 Codex 任务的完整闭环”很多人用 Codex,问题不在“不会提问”,而在于每次只做了中间一段。
常见断点是:
- 只会说需求,不会限范围
- 只会让它改,不会让它先读项目
- 只看它说“改好了”,不看结果
- 改完就结束,不做验收
所以这一篇不再讲单个技巧,而是把一次任务完整串起来。
前置教程:20 分钟快速上手
如果你还没有跑通过一次最小练习,先完成前置教程,再回到本篇。
依据来源:OpenAI Codex 官方手册中关于任务上下文、范围限制、检查、结果汇报和工作流示例的说明。
跟着本篇做完后,你应该能掌握一套稳定顺序:
- 先定义任务目标。
- 再补上下文。
- 再限制范围。
- 再让 Codex 动手。
- 再看它的修改结果。
- 再让它做必要检查。
- 最后判断能不能进入下一步。
先记住这 7 步
Section titled “先记住这 7 步”以后你做大多数 Codex 任务,都可以套这个顺序:
1. 讲清任务目标2. 补项目背景3. 限制修改范围4. 约定不确定时先问5. 要求完成后汇报6. 看检查结果7. 决定接受、继续修,还是暂停这就是闭环。
第 1 步:任务目标必须写成“完成后会怎样”
Section titled “第 1 步:任务目标必须写成“完成后会怎样””不要只说:
帮我优化首页要写成:
请把首页主按钮文案从“开始”改成“从 0 开始学习”。你说得越像“最终状态”,Codex 越容易做对。
第 2 步:补背景,但只补有用背景
Section titled “第 2 步:补背景,但只补有用背景”背景不是越多越好,而是让它少猜。
例如:
这是一个 Astro 静态教程站。当前任务只想调整首页主按钮文案,不调整布局,不重写组件。或者:
这是一个 Vue 页面。问题只出现在登录按钮点击后的提示文案,不涉及后端接口改动。第 3 步:把范围讲死
Section titled “第 3 步:把范围讲死”这一点非常关键。
你要明确:
- 优先改哪个文件
- 最多允许改到哪里
- 什么绝对不能动
例如:
修改范围:1. 优先只改 src/pages/index.astro。2. 如果必须改其他文件,请先说明原因。3. 不要修改样式系统、构建配置和依赖。第 4 步:告诉它不确定时先问
Section titled “第 4 步:告诉它不确定时先问”这一句可以大幅降低乱改概率。
直接写:
如果你不确定入口文件、影响范围或需要修改多个文件,请先停下来告诉我,不要猜。这句最好成为你的固定动作。
第 5 步:要求它完成后按固定格式汇报
Section titled “第 5 步:要求它完成后按固定格式汇报”别让它自由发挥。
你可以固定要求:
完成后请按下面格式回复:
## 修改摘要- 修改了什么:- 修改了哪些文件:
## 检查结果- 做了哪些检查:- 哪些通过:- 哪些没有检查:
## 风险提示- 是否有超出范围的改动:- 是否还需要我人工确认:这一步会让你后面特别省心。
第 6 步:一个完整提示词长什么样
Section titled “第 6 步:一个完整提示词长什么样”下面给你一份通用闭环模板:
请完成一个 Codex 任务。
## 任务目标请把首页主按钮文案从“开始”改成“从 0 开始学习”。
## 背景这是一个 Astro 静态教程站。当前任务只调整首页文案,不调整布局和视觉风格。
## 修改范围1. 优先只修改首页相关文件。2. 如果必须修改其他文件,请先说明原因。3. 不要修改构建配置、依赖、样式系统和无关页面。
## 禁止事项1. 不要安装依赖。2. 不要提交 Git。3. 不要顺手优化其他模块。
## 不确定时如果你不确定入口文件、需要改多个文件,或发现影响范围超出预期,请先停下来问我。
## 完成后请这样汇报### 修改摘要- 修改了什么:- 修改了哪些文件:
### 检查结果- Git 状态:- diff 大意:- 是否存在超出范围的改动:
### 风险提示- 还需要我人工确认什么:这就是一个基本完整、能直接执行的闭环提示词。
第 7 步:任务发出后,你重点看什么
Section titled “第 7 步:任务发出后,你重点看什么”你不要盯着它每一步读了哪个文件,而是看这 5 件事:
- 它有没有理解对任务目标。
- 它有没有遵守范围。
- 它有没有在不确定时先问。
- 它有没有把修改结果讲清楚。
- 它有没有说明还剩什么风险。
第 8 步:闭环里最容易丢的三步
Section titled “第 8 步:闭环里最容易丢的三步”最容易丢的,是“范围”
Section titled “最容易丢的,是“范围””很多人目标写得很清楚,但没写范围,结果 Codex 直接多改一片。
第二容易丢的,是“检查”
Section titled “第二容易丢的,是“检查””它改完了,不代表闭环完成了。你还得知道:
- 改了哪些文件
- 有没有超范围
- 有没有明显问题
第三容易丢的,是“停下来问”
Section titled “第三容易丢的,是“停下来问””如果你没提前约定,Codex 很可能会为了完成任务自己做很多判断。
第 9 步:闭环完成后,你怎么判断这次任务算不算做完
Section titled “第 9 步:闭环完成后,你怎么判断这次任务算不算做完”只要下面 6 条成立,这次任务基本就算闭环了:
- 原始目标已经实现。
- 修改范围没有失控。
- 它解释了改动结果。
- 它说明了检查情况。
- 它说明了剩余风险。
- 你知道接下来是继续、暂停还是进入提交前检查。
一个最实用的习惯
Section titled “一个最实用的习惯”以后你每次开新任务前,先自己过一遍这四句:
我要它改什么?它只能改哪里?它不确定时该怎么办?它做完后要怎么向我汇报?如果这四句你都能答出来,这次任务大概率会稳很多。
下一步该看什么
Section titled “下一步该看什么”建议接着看:
这三篇会把闭环里的“范围控制”和“检查收尾”两块继续压实。