Free Preview
先试读：不会写代码，也要能看懂 Codex 改了什么
Codex 的产出不能只看总结。总结会说“修复了问题、通过了验证”，但真正能证明它做了什么的是 diff、文件列表、测试结果和 PR 讨论。
你不需要马上学会写代码，但你需要能回答几个基础问题：它改了哪些文件？为什么改？有没有动到禁区？有没有验证？能不能撤回？
这篇能解决什么问题
- 看懂 branch、commit、diff、PR、review、merge 这些基础词。
- 知道不会代码时应该先看文件列表、行为变化和验证证据。
- 知道哪些 Codex 结果不能直接合并。
付费后能看到哪些内容
- Codex 交付物的组成
- PR / Diff / Review 的普通人解释
- 非程序员审 diff 的 5 个动作
- 一张 PR 验收卡
可以先照着试的一句话
请把这个 PR 翻译成普通人能判断的版本：改了哪些文件、用户会看到什么变化、有没有动到高风险区域、验证证据是什么。
试读到这里，你应该先把“能看懂交付物”作为 Codex 入门的底线。
01 · 交付物
Codex 最终交付的不是一句话，而是一组证据
你要审的是证据，不是信心。
一个合格的 Codex 任务完成后，至少应该留下四类东西：文件改动、行为说明、验证结果、剩余风险。只有总结没有证据，不算完成。
文件改动
哪些文件被新增、修改、删除。先看范围有没有失控。
行为说明
用户实际会看到什么变化，功能路径发生了什么改变。
验证结果
测试、构建、页面检查、截图、命令输出或手动路径。
剩余风险
哪些路径没测，哪些地方需要人工确认，哪些风险没有解决。
02 · 基础词
几个必须懂的词：Branch、Commit、Diff、PR、Review、Merge
不用背概念，先把它们当成工作流里的动作。
| 词 | 普通人解释 | 你要关注什么 |
|---|---|---|
| Branch | 一条临时工作线，Codex 可以在这里改，不直接碰主线。 | 这次改动是不是在单独分支里。 |
| Commit | 一次保存下来的改动记录。 | 提交说明是否能解释本次目标。 |
| Diff | 改动前后对比，告诉你哪几行变了。 | 有没有无关改动，是否动到禁区。 |
| PR | 申请把分支改动合并到主线的页面。 | PR 描述、文件列表、检查结果、讨论是否清楚。 |
| Review | 对 PR 的审查，找风险、提问题、要求修改。 | 是不是只表扬，还是指出了具体风险。 |
| Merge | 把 PR 合并进主线。 | 合并是否会触发部署，是否已经完成验证。 |
03 · 审 Diff
不会代码怎么审 diff：先看范围，再看行为，再看证据
非程序员不需要逐行理解所有语法，但必须能判断风险。
1
看文件列表
任务是改文案，却动了登录、支付、数据库、部署文件，直接要求解释。
2
看增删比例
一个小任务改了几百行，通常要警惕顺手重构或范围失控。
3
看用户变化
让 Codex 用普通话解释：用户打开哪个页面会看到什么变化。
4
看验证证据
没有测试、构建、截图、手动路径，就不要接受“已经完成”。
5
看未验证项
成熟的交付会主动说“哪些没验证”，而不是假装全都没问题。
非程序员审 Diff 提示词
我不需要逐行代码解释。请用普通人能判断的方式解释这个 diff：
1. 本次改动的目标是什么
2. 实际改了哪些文件
3. 用户会看到什么变化
4. 是否动到登录、支付、数据库、权限、部署、外部发送
5. 已经做了哪些验证
6. 哪些地方还没验证
7. 你建议我重点看哪 3 处改动04 · 不能合并
什么时候不能合并 Codex 的结果
能生成 PR 不等于能 merge。新手要有拒绝合并的标准。
范围失控
任务很小，但改动文件很多，尤其动到共享脚本或核心配置。
高风险未确认
登录、支付、权限、数据库、部署、外部发送只要被动到，就要人工确认。
没有验证
只说“应该可以”，没有任何可复现证据。
解释含糊
Codex 说不清某个文件为什么改，不要合并。
不懂影响
你无法判断用户路径会发生什么变化，应先要求它翻译业务影响。
合并会自动上线
如果项目合并即部署，检查标准必须更严格。
05 · 让 AI 辅助审查
让 Codex 帮你解释 PR，但不要让它替你负责
Codex 可以帮你降低理解成本，但最终合不合还是人的判断。
PR 解释模板
请解释这个 PR，按下面格式输出：
1. 一句话说明本 PR 想解决什么问题
2. 文件改动清单：每个文件为什么改
3. 用户可见变化
4. 高风险区域检查：登录/支付/权限/数据库/部署/外部发送
5. 验证证据：测试、构建、页面检查、手动路径
6. 未验证项
7. 合并建议：可以合并 / 需要修改 / 不建议合并
8. 如果不建议合并，最小补救动作是什么不要问“这个 PR 可以合吗”
这个问题太粗。更好的问法是：请列出能支持合并的证据、阻止合并的风险、还缺哪些验证。你要看证据，而不是只看结论。
06 · 验收卡
PR 验收卡：合并前逐项检查
把这张卡当作 Codex 交付结果的最低标准。
PR 验收卡
合并前我是否确认：
1. PR 目标和原始任务一致
2. 文件范围没有失控
3. 没有动到禁区，或已人工确认
4. 用户可见变化说得清楚
5. 有验证证据
6. 未验证项已经列出
7. 失败时知道怎么回退
8. 如果合并会自动部署，已经完成线上前检查这一篇的结论
- PR 是合并申请，不是最终上线许可。
- Diff 是事实证据，总结只是辅助说明。
- 不会代码也要看文件范围、行为变化、验证证据和未验证项。
- 合并前必须知道：改了什么、为什么改、怎么验证、怎么撤回。