Codex：把失败的 CI 日志贴进去时，怎么限制改动范围

把失败的 CI 日志贴进 Codex，它可能顺手改无关文件换绿。公开工单写过：本要改 8 个文件，结果动了 37 个。提示里先锁允许路径，交付时看 git diff –stat。

要点

• ChatGPT Learn 的 Best practices 建议提示里写 Goal、Context、Constraints 和 Done when。Context 包括哪些文件和目录，以及文档、例子或报错和这次任务有关；Constraints 写标准、架构，以及安全要求和约定；Done when 是完成前必须为真的事，例如测试通过、行为改变，或某个 bug 不再复现。（Best practices）
• 同一页建议把反复奏效的规矩搬进 AGENTS.md，并写清约束、怎样算做完、如何验证。文件要短，先写实际会用到的命令和禁止事项。（Custom instructions with AGENTS.md）
• 官方把 issue 做成可测 PR 的用例要求更硬：先读说明并跑已有基线检查，基线失败就先报告阻碍；范围要写文件或组件边界，也要写明确排除项；只做满足验收标准的最小改动，不要扩大已经谈妥的范围。测试失败后，不要靠删断言或放宽检查换绿。（Turn an issue into a tested pull request）
• Cookbook 把每个阶段写成有范围、非目标、验收标准和验证命令的计划，要求先复现再实施，验证命令必须真实跑过，计划里的命令不能抄成“已经通过”。（Iterating development workflows with Codex）
• 本篇把这些口径落到“贴失败 CI 日志”这一步：先摘失败要点，在提示里声明允许路径和禁止事项，要求先复现再做最小修复，交付时贴 git diff --stat。不要顺手改无关呆警，不要改无关格式，不要为了变绿改测试。后一条站内已有专文，这里只提醒，不重讲分轮提示。（Codex：用测试文件当完成定义，先红后绿再重构）
• 社区里有过范围失控的公开记录。openai/codex 仓库工单 #11985 写：用 codex exec --full-auto 做一次针对 8 个文件的修复，实际改了 37 个文件，其中大量改动与任务无关。官方随后以材料不足关闭，并请补充会话详情。这是公开经验，不是产品保证。（Issue #11985）

正文

场景

CI 红了。你把整段日志贴进 Codex，或 Cursor 里的 Codex，只补一句“修到绿”。它很快回你：测试过了。

你打开 git diff --stat，真正失败的那条测试只动了两处。旁边却多出一串文件。别的目录里的 lint 呆警被清掉了，日志没点名的文件被重新格式化，还有一条精确断言被改成“有值就算过”。绿灯是换来的，范围已经散了。

这是范围失控的示意，不是某次逐字实测日志。日志越长，模型越容易把所有发红的地方都当成这轮任务。

失败回合怎么 rewind、脚本怎么补 --help 和退出码、多文件重构怎么写完成定义，站内各有专文，那些纪律还要用。本篇只攻一件事：日志已经贴进去了，怎么用提示、Constraints 和 AGENTS.md，把改动锁在本次失败相关的文件和测试上。相关旧文见文末来源。

可跟做步骤／可抄工作流

先摘失败要点，不要把整段日志当成任务书

贴日志之前，先自己抽出这几项：失败的 job 名，真正执行的命令，失败的测试或规则名，第一条报错，以及退出码。前面已经绿过的步骤可以丢掉，它们会把信号淹没。

第三方公开指南 Hidden Logic Lab 写过类似经验：只贴失败步骤，从第一条报错接到最终退出码。这不是 OpenAI 官方保证，但和“先给对的 Context”是同一方向。（Fix a failing CI job from the logs）

Best practices 把 Context 解释成：哪些文件、目录、文档、例子或报错和这次任务有关。整段日志常常只会把 Context 变吵。

提示按 Goal、Context、Constraints、Done when 写死边界

Best practices 的默认四件套，正好用来锁范围。Goal 写这次只修哪一次失败，Context 则补上失败要点和允许改的路径。Constraints 要写死：不准顺手清无关呆警，不准改无关格式，也不准为了变绿改测试或放宽断言。Done when 写成，同一条失败命令在本地复现后变绿，并且 git diff --stat 只落在允许路径里。

常驻纪律放进 AGENTS.md。本轮允许改哪些路径、这一次失败对应哪条命令，仍要写在当条提示里。AGENTS.md 管每次都成立的规矩，提示管这一轮的合同。

下面这段是可抄的常驻纪律。测试命令换成你仓库里的真实脚本。

## CI failure fixes stay in scope

- When given a failing CI log, first extract the failing job, command,
  test or rule name, first error, and exit code.
- Reproduce the failure with the focused command before editing.
- Edit only the allowed paths named in the current prompt.
- Do not fix unrelated linter warnings, reformat files the log did not
  name, or change files outside the allowed list.
- Do not delete tests, add skip, or weaken assertions to make CI green.
- Stop with the exact command, exit code, a short excerpt, and
  `git diff --stat`.
- If the failure cannot be reproduced, or the fix would require files
  outside the allowed paths, stop and report. Do not expand scope
  on your own.

本轮任务可以压成下面这类提示，路径和命令按项目替换。

Read AGENTS.md. This turn only fixes ONE CI failure. Do not refactor.

Goal:
Make the failing check below pass, with the smallest change.

Context:
- Failing job: 【job 名】
- Command that failed: 【例如 npm test -- tests/payments/retry.test.ts】
- First error / failing test or rule: 【第一条报错或测试名】
- Allowed paths: 【src/payments/** 和对应测试文件】

Constraints:
- Do not edit files outside the allowed paths.
- Do not fix unrelated linter warnings or pre-existing nits.
- Do not reformat files the log did not name.
- Do not delete, skip, or weaken tests or assertions to get a green job.
- Do not upgrade dependencies unless the log proves a version conflict.

Done when:
1) You first rerun the same command and paste the reproduced failure.
2) You make the smallest fix, rerun the same command, and paste the
   passing excerpt with the exit code.
3) You paste `git diff --stat`. It must only include allowed paths.
If you cannot reproduce the failure, or the fix needs other files, stop
and report. Do not expand the scope yourself.

先复现，再做最小修复

还没在本地用同一条命令把失败跑出来，就不要改产品代码。复现不了，先说明缺什么：是环境不一样，是日志被截断，还是失败来自基础设施。Hidden Logic Lab 也写过，超时或网络一类的 flaky job，可能重跑就绿，不要急着合并一个假修复。这仍是第三方经验。

官方可测 PR 用例把顺序写得很清楚：先确认起点并跑已有检查，基线失败或必要检查跑不了，就先报告阻碍。实施时只做最小改动。收尾要记录命令和结果，以及被测到的提交或工作区状态，还有没跑的检查。未跑过的检查不能写成通过。

交付时看 git diff –stat，你自己再点几下

Codex CLI 能在本地仓库里读文件、改文件，并跑你机器上已有的命令。（Codex CLI）CLI 文档还写了 /permissions：运行前可以查看沙箱和可写根目录，决定它何时能不经询问就改文件或跑命令。具体按钮和斜杠命令，以你客户端现页为准。

模型自称完成后，先看它贴出来的 git diff --stat，再自己跑同一条命令。至少核对这四件事：

1. 允许路径以外有没有文件被改？
2. 有没有顺手修日志没点名的 lint 呆警，或重排无关格式？
3. 测试文件、夹具或快照有没有被改瘦，断言有没有被放宽？为变绿去改测试，这轮就算作废。
4. 报告里的命令和摘录，是观察结果，还是把计划原文抄过来了？

任何一项对不上，不要在已经跑偏的对话里接着“再修一下”。先丢掉超范围的改动，把允许路径写得更窄，再开一轮。

真实用户诀窍／反例

• 诀窍：先摘失败要点，再贴日志。 job 名和命令，以及第一条报错和退出码，比整段控制台输出更有用。
• 诀窍：允许路径和禁止事项写在同一条提示里。 只写“做最小修复”，模型仍可能把相邻呆警当成顺便能做的好事。
• 诀窍：完成证据是命令、退出码，外加 git diff --stat。 口头说“已经绿了”不够。
• 诀窍：常驻纪律放进 AGENTS.md，本轮路径放进提示。 少把每次都成立的规矩反复堆进对话。
• 反例：整段日志加一句“修到绿”。 最常见的结果是无关文件、格式和测试一起被动。
• 反例：为了变绿去改断言、给用例加 skip，或改掉夹具。 官方可测 PR 用例写明，不要靠删断言或放宽检查换绿。分轮怎么把测试文件锁成完成合同，见站内另一篇，这里不重讲。
• 反例：默认模型会守住范围。 工单 #11985 记录过一次 8 个文件的任务改出 37 个文件。官方要求补充会话详情后关闭，它只能当成你必须自己看 diff 的理由。
• 反例：把已归档的 Autofix CI cookbook 整段抄进仓库，当成“贴日志”的标准做法。 官方现页已标明该例归档，并提醒不要照抄那种把密钥和写权限捆在一起的布局。本篇不教自动修 CI 流水线。

适用边界

• 本稿覆盖：在本地用 Codex CLI，或 IDE、Cursor 里的 Codex，把失败的 CI 日志贴进去之后，如何用提示、Constraints 和 AGENTS.md 限制改动范围。不保证某一版本的斜杠命令或按钮文案长期不变，以你客户端现页和 codex --help 为准。
• 不覆盖：失败回合 rewind，以及脚本 --help 与退出码、测试文件分轮提示，还有多文件重构的完成定义。那些题目站内已有专文。
• 不覆盖：把 Codex 接进 GitHub Actions、失败后自动开 PR。官方 Cookbook 有过 Autofix 示例，现页已标归档。本篇只谈把日志贴进去的交互写法。
• 云端是否同等执行提示里的本地命令，以该环境现页为准。生产热修、密钥和部署仍须独立审批。写了 Constraints 也不保证模型绝不越界。git diff --stat 和你自己复跑命令，仍是最后一道门。超时、基础设施或 flaky 失败，未必该用改代码来换绿。