怎样看懂 Codex 的 Diff：确认改动没有越界

页面看起来正常，不代表代码改动一定合理。Codex 完成任务后，最值得看的不是总结文字，而是 Git Diff：哪些文件发生变化、哪些行被新增或删除、有没有出现原计划之外的改动。

先看文件清单，再看具体代码

第一遍不要急着逐行阅读，先确认文件范围。一个只要求修改按钮文案的任务，如果同时改了数据库配置、路由或多个公共组件，就需要先问清原因。

• 新增文件是否确有必要；
• 配置文件是否被意外格式化或覆盖；
• 锁文件、大型构建产物是否无关变化；
• 是否改到了用户未授权的模块。

理解加号和减号

Diff 中的新增行通常以加号标记，删除行以减号标记。重点不是哪边更多，而是业务含义是否保持完整。尤其要留意原有校验、权限判断、异常处理和日志是否被删掉。

四类高风险信号

1. 写死敏感信息：密钥、Token、手机号或环境地址进入代码。
2. 扩大权限：为了让功能运行而绕过登录、校验或授权。
3. 吞掉错误：捕获异常后什么也不记录，造成表面成功。
4. 顺手重构：任务之外的大面积改名或结构调整，增加回归面。

把每一块差异对应回需求

阅读时可以问自己：这段修改服务于哪条需求？如果无法对应，要么它是多余改动，要么最初需求遗漏了重要范围。两种情况都值得重新确认。

Diff 之后仍然要运行验证

代码审查能发现逻辑和范围问题，但不能替代执行。完成 Diff 检查后，还要运行语法检查、自动化测试或真实页面操作。对于前端改动，应同时检查桌面端和移动端；对于数据操作，应验证成功、失败和重复提交等分支。

一个实用顺序是：先看状态和文件列表，再阅读核心差异，随后运行验证，最后检查工作区是否还残留临时文件。这样既不会一开始陷入细节，也不会只凭页面效果做判断。