让 Codex 完成任务验收

让 Codex 完成任务验收

这一篇不是教你手动敲构建命令。

真实使用 Codex 时，很多任务完成后 Codex 会主动做必要检查，或者至少会告诉你它检查了什么、没检查什么。用户真正要学的是：

任务开始前设定验收标准
-> 任务完成后看懂 Codex 做了哪些检查
-> 如果 Codex 没检查，知道怎么追问
-> 如果检查失败，知道怎么让它收敛修复
-> 最后判断这次任务能不能交付

前置教程：第一次让 Codex 改代码
如果你还没有跑通过一次小范围代码修改，先完成前置教程，再回到本篇。

依据来源：OpenAI Codex 官方手册中关于任务上下文、执行命令、审批、验证和审查 diff 的说明。

本篇目标

跟着本篇做完后，你应该能做到：

1. 在任务开始前告诉 Codex 什么叫“完成”。
2. 要求 Codex 修改后自行做必要验收。
3. 看懂 Codex 最后汇报里的检查项。
4. 判断它有没有跳过检查。
5. 在它漏检时正确追问。
6. 在检查失败时要求它先定位原因，再收敛修复。
7. 判断这次任务是否可以进入提交前检查。

本篇不做什么

本篇不做这些事情：

• 不要求用户自己手动跑一堆命令。
• 不把 npm run build 当成所有项目唯一验收。
• 不要求 Codex 每次都跑完整测试套件。
• 不允许 Codex 为了让检查通过而扩大修改范围。
• 不提交 Git。

本篇训练的是一种能力：

让 Codex 把任务做完，并把验证过程讲清楚。

为什么不能只说“帮我改一下”

如果你只说：

帮我把首页标题改一下。

Codex 可能能改对，但验收就不一定完整。

更好的说法是：

请把首页标题改成“Codex Demo”。

完成后请你自行做必要验收：
1. 检查实际修改了哪些文件。
2. 检查 diff 是否只包含本次任务需要的变化。
3. 如果项目有明显的最小检查命令，请运行最小必要检查。
4. 如果你没有运行检查，请说明原因。
5. 最后用中文告诉我：通过了什么、失败了什么、还需要我人工看什么。

这段话把验收责任提前交代清楚了。

第 1 步：先让 Codex 判断“最小必要验收”

进入项目里的 Codex 后，先不要直接让它继续改。

复制这段：

在继续做任务前，请先只读判断当前项目的最小必要验收方式。

要求：
1. 不要修改文件。
2. 不要安装依赖。
3. 只根据项目文件和已有脚本判断。
4. 如果有 package.json，请查看 scripts。
5. 如果是 Maven 项目，请查看 pom.xml。
6. 如果无法判断，请明确写“不确定”。

请按下面格式输出：

## 项目类型
- 你判断的技术栈：
- 判断依据：

## 可用检查
- 可能的构建命令：
- 可能的测试命令：
- 可能的 lint 命令：
- 哪个是本次小任务的最小必要检查：

## 不能确定的地方
- 请列出不能确定的地方：

你要看的不是命令本身，而是 Codex 有没有基于项目文件做判断。

第 2 步：给任务时把验收写进去

假设你要让 Codex 改一个首页标题，可以这样写：

请完成一个小范围修改任务。

任务目标：
把首页标题改成“Codex Demo”。

范围限制：
1. 先定位相关文件。
2. 尽量只修改必要文件。
3. 不要安装依赖。
4. 不要提交 Git。
5. 如果你发现需要改多个文件，请先说明原因再动手。

验收要求：
1. 修改完成后，请检查 Git 状态和 diff。
2. 请确认是否存在超出任务范围的改动。
3. 请根据项目已有脚本选择最小必要检查。
4. 如果运行了检查，请贴出命令名称、结果和结论。
5. 如果没有运行检查，请说明具体原因。
6. 如果检查失败，先判断失败是否由本次修改引入，不要立刻扩大修复范围。

最后请按下面格式汇报：

## 修改摘要
- 修改了什么：
- 修改了哪些文件：

## 验收过程
- 检查了什么：
- 运行了哪些命令：
- 哪些通过：
- 哪些失败：
- 哪些没有检查，原因是什么：

## 交付判断
- 是否可以进入提交前检查：
- 还需要我人工确认什么：

这段提示词的重点是：你没有命令式地要求它一定跑某个命令，而是让它根据项目选择“最小必要检查”。

第 3 步：看 Codex 的验收汇报

Codex 完成后，先看它最后的汇报。

重点看 5 个地方：

1. 修改了哪些文件。
2. 有没有解释 diff。
3. 运行了哪些检查。
4. 有没有检查失败。
5. 有没有说明未检查原因。

一个比较好的汇报应该像这样：

## 验收过程
- 已检查 git status：只有 src/App.vue 发生变化。
- 已查看 diff：只修改首页标题文案。
- 已运行 npm run build：通过。
- 未运行完整测试：项目没有 test script。

如果它只说：

已完成。

这不够。

第 4 步：如果 Codex 没有检查，怎么追问

不要直接责备，也不要自己急着手动跑。

复制这段：

你刚才的总结里没有说明验收过程。

请补充说明：
1. 你是否检查了 Git 状态。
2. 你是否查看了 diff。
3. 你是否运行了构建、测试或 lint。
4. 如果没有运行，请说明原因。
5. 请根据当前项目脚本判断是否存在最小必要检查。

要求：
- 可以运行必要的只读或检查命令。
- 不要修改文件。
- 不要提交 Git。

这段话会把 Codex 拉回“验收”这件事上。

第 5 步：如果 Codex 跳过检查，怎么判断是否合理

Codex 没运行检查，不一定就是错。

合理原因可能是：

• 项目没有相关脚本。
• 依赖没有安装。
• 当前任务只改了文档。
• 检查命令会耗时很久。
• 检查命令需要外部服务或密钥。
• 当前权限不允许运行。

不合理原因可能是：

• 它忘了。
• 它没有查看项目脚本。
• 它声称检查通过，但没有说检查了什么。
• 它把“我认为没问题”当成了验收。

你可以继续问：

你说没有运行检查。请判断这个跳过是否合理。

要求：
1. 说明你是否查看了项目脚本。
2. 如果有 build/test/lint，但你没运行，请解释原因。
3. 如果跳过合理，请告诉我人工应该确认什么。
4. 如果跳过不合理，请现在运行最小必要检查。

第 6 步：如果检查失败，不要让它乱修

检查失败时，最危险的做法是直接说：

修复所有问题。

这会扩大范围。

正确说法是：

检查失败了。请先不要修改文件。

请先分析：
1. 失败的命令是什么。
2. 失败信息的关键错误是什么。
3. 这个失败是否可能由本次修改引入。
4. 如果不是本次修改引入，请说明依据。
5. 如果是本次修改引入，请给出最小修复方案。

要求：
- 先分析，不要立刻修改。
- 不要修复和本次任务无关的问题。

这一步的目标是先判断“是不是我这次改坏的”。

第 7 步：只修本次任务引入的问题

如果 Codex 判断失败是本次修改引入的，再让它修。

复制这段：

如果你确认这是本次修改引入的问题，请进行最小修复。

要求：
1. 只修复和本次任务直接相关的问题。
2. 不要重构无关代码。
3. 不要修改无关文件。
4. 修复后重新运行同一个失败检查。
5. 最后总结修复前后变化。

如果 Codex 判断失败不是本次修改引入的，不要让它顺手修历史问题。可以记录下来，后面单独开任务。

如果这个失败不是本次修改引入，请不要修复。
请把它记录成“已有问题”，并说明后续应该单独开一个什么任务处理。

第 8 步：让 Codex 给出最终交付判断

任务结束前，让 Codex 给一个明确判断。

复制这段：

请给出本次任务的最终交付判断。

请按下面格式回复：

## 是否完成
- 任务是否完成：
- 是否符合原始目标：

## 修改范围
- 修改了哪些文件：
- 是否有超出范围的改动：

## 验收结果
- 已运行检查：
- 检查结果：
- 未运行检查及原因：

## 风险提示
- 还需要我人工确认什么：
- 是否可以进入提交前检查：

这一步不是形式主义。它能让用户知道任务现在处于哪种状态：

• 可以进入提交前检查。
• 需要继续修复。
• 需要人工确认。
• 需要单独开新任务。

第 9 步：用户怎么验收 Codex 的验收

你不需要完全信任 Codex 的一句话。

你要检查 4 个问题：

1. 它有没有列出具体检查，而不是只说“已验证”。
2. 它有没有说明失败或跳过原因。
3. 它有没有把历史问题和本次问题分开。
4. 它有没有说清楚是否可以进入提交前检查。

如果这 4 个问题都清楚，本次任务就比较稳。

如果不清楚，继续追问，先不要提交。

常见问题

情况 1：Codex 说检查通过，但没说运行了什么

追问：

请明确列出你刚才运行过的检查命令、每个命令的结果，以及你判断通过的依据。

情况 2：Codex 说没有测试

追问：

请说明你是如何判断项目没有测试的。你查看了哪些文件或脚本？

情况 3：Codex 为了通过检查改了很多文件

追问：

你为了通过检查修改了多个文件。请逐个解释这些文件和本次任务的关系。不要继续修改。

情况 4：Codex 把历史问题也修了

追问：

请区分哪些修改是本次任务必需的，哪些是顺手修复的历史问题。不要继续修改。

如果顺手修复太多，建议撤回无关改动，单独开新任务。

验收结果

做到这里，如果满足下面 7 条，就说明本篇完成：

1. 你知道任务开始前要写验收标准。
2. 你知道 Codex 通常会做检查，但用户要会看懂它检查了什么。
3. 你知道 Codex 没检查时怎么追问。
4. 你知道检查失败时先分析，不要直接“修所有问题”。
5. 你知道只修本次任务引入的问题。
6. 你知道如何让 Codex 给出最终交付判断。
7. 你知道什么时候可以进入提交前检查。

本篇你真正学会了什么

你学会的是 Codex 工作流里非常关键的一步：

改完不是结束，验收清楚才算接近完成。

专业的 vibe coding 不是“让 AI 改完就信”，而是让 Codex 自己完成验证，并让用户能判断这份验证是否可信。

下一篇学什么

下一篇看：Git 提交前检查。

那一篇会讲怎么让 Codex 在提交前再次检查 diff、风险、无关文件、提交说明和回滚预案。