怎样让 Codex 自己做必要检查

你前面说得很对。

真实使用里，很多时候不是你手动去跑检查，而是 Codex 自己会做一些必要检查，或者你明确要求它做检查并汇报结果。

所以这一篇不讲“你该敲哪些命令”，而讲更符合实际的一件事：

怎么让 Codex 自己根据项目情况做必要检查，然后把结果讲清楚。

前置教程：让 Codex 完成任务验收
如果你还没有建立“任务完成后要看检查结果”的意识，先完成前置教程，再回到本篇。

依据来源：OpenAI Codex 官方手册中关于任务执行、验证、审批、结果汇报和最小必要工作流的说明。

本篇目标

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

不再自己先入为主地指定错误检查方式。
让 Codex 先判断当前项目适合什么检查。
让 Codex 运行最小必要检查，而不是全家桶。
让 Codex 说明哪些检查做了、哪些没做。
在检查失败时让它先分析，再决定要不要修。

先理解一个原则

不是每个任务都必须跑完整构建、完整测试、完整 lint。

正确思路是：

让 Codex 判断本次任务最小需要验证什么。

比如：

只改 README，通常不需要构建
只改首页文案，可能只需要看 diff，必要时再做最小构建
只改一个接口逻辑，可能需要跑相关测试或最小编译检查

所以重点是“必要检查”，不是“检查越多越专业”。

第 1 步：先让 Codex 判断当前项目有哪些检查方式

把下面这段发给 Codex：

请先只读判断当前项目适合哪些检查方式。

要求：
1. 不要修改文件。
2. 只根据项目结构、脚本和配置判断。
3. 如果能判断，请区分构建、测试、lint、类型检查或其他检查。
4. 如果不能判断，请明确写不确定。

请按下面格式输出：

## 项目可用检查
- 构建检查：
- 测试检查：
- lint 或格式检查：
- 其他可能检查：

## 本次任务的最小必要检查
- 如果只是小范围改动，你建议做什么：
- 为什么：

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

这一步的目的，是让 Codex 先做判断，不是让它立刻开跑。

第 2 步：发任务时，把“请你自行做必要检查”写进去

你可以这样说：

请完成这次任务，并在完成后自行做最小必要检查。

要求：
1. 先完成任务本身。
2. 完成后请根据当前项目实际情况，选择最小必要检查。
3. 不要为了显得完整就运行无关检查。
4. 如果某项检查没有运行，请说明原因。
5. 如果检查失败，请先分析是否由本次修改引入。

最后请按下面格式汇报：

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

## 检查情况
- 你运行了什么检查：
- 每项检查的结果：
- 哪些检查没有运行，原因是什么：

## 结论
- 本次任务是否基本完成：
- 是否建议我进入下一步：

这段话比你直接指定某个命令更稳，因为它更贴近真实项目差异。

第 3 步：什么叫“最小必要检查”

给你几个非常实用的判断例子。

场景 1：只改 README

通常最小必要检查就是：

Git 状态
diff

一般不需要构建。

场景 2：只改静态页面文案

常见最小必要检查是：

Git 状态
diff
如果项目构建很轻，可以补一次最小构建

场景 3：只修一个明显前端小 Bug

常见最小必要检查是：

Git 状态
diff
项目已有的最小构建或类型检查

场景 4：改后端接口逻辑

常见最小必要检查是：

Git 状态
diff
相关测试、最小编译或项目已有后端检查

重点不是你背命令，而是你让 Codex 按项目实际来判断。

第 4 步：如果 Codex 没主动检查，怎么补一句

很简单，直接补：

请不要只说“已完成”。
请根据当前项目情况自行完成最小必要检查，并把结果用中文告诉我。

如果你想再明确一点：

请至少检查 Git 状态和 diff。
如果当前项目存在明显的最小构建、测试或 lint 检查，请判断是否需要运行，并说明理由。

第 5 步：如果 Codex 跑了检查，你应该看什么

你不用盯着技术细节，先看这 5 件事：

它有没有说清楚运行了什么。
它有没有说清楚结果是通过还是失败。
它有没有把未运行项的原因讲清楚。
它有没有把本次任务和历史问题分开。
它有没有给出下一步建议。

第 6 步：如果检查失败，正确追问方式是什么

不要上来就说：

全部修掉

正确说法是：

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

请先分析：
1. 失败的是哪一项检查。
2. 关键错误是什么。
3. 这个问题是否由本次修改引入。
4. 如果是本次修改引入，请给出最小修复方案。
5. 如果不是本次修改引入，请明确告诉我不要在本任务里顺手修。

这句非常重要。

第 7 步：一份非常实用的通用提示词

请完成当前任务。

完成后请不要只给结果，还请你自行做必要检查。

要求：
1. 请先根据当前项目情况判断本次任务的最小必要检查。
2. 不要为了显得完整而运行明显无关的检查。
3. 至少检查 Git 状态和 diff。
4. 如果你判断需要运行构建、测试、lint 或其他检查，请说明为什么。
5. 如果你没有运行某项检查，请说明原因。
6. 如果检查失败，请先分析失败原因和是否由本次修改引入，不要直接扩大修复范围。

最后请按下面格式汇报：

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

## 检查情况
- 运行了哪些检查：
- 每项检查的结果：
- 没运行哪些检查，原因是什么：

## 风险和建议
- 是否存在超出任务范围的改动：
- 是否建议继续下一步：
- 还需要我人工确认什么：

第 8 步：什么情况下你应该少让它检查一点

这些场景通常不需要重检查：

只改文档
只改一句文案
只改教程内容
只做非常局部的静态文本修正

这时候你重点看：

文件范围
diff
是否改对

而不是强迫它每次都跑大检查。

第 9 步：什么情况下你应该要求它更认真检查

这些场景就该更严一点：

改了接口逻辑
改了表单提交流程
改了登录权限
改了构建配置
改了共享组件

因为这些东西影响面更大。

下一步该看什么

建议接着看：

这样“让它做检查”这件事，就能和“范围控制”“提交前收尾”连成一整套。