AI 改完代码，先一格一格读 DIFF：30 秒的慢功夫，省下半天的 firefighting

上次 AI 帮我清理一批定时脚本，它说"全部改好，逻辑等价"。我信了，让它直接提交。当晚线上告警：三个脚本里有两条日志被静默吞掉了——它把带 `-f` 的 stderr 重定向顺手"统一"掉了。回滚、排查、订正，一共花掉四十分钟。从那以后我固定一个习惯：**AI 改完代码，先一格一格读 DIFF，再谈下一步。**

什么时候必须一格一格读

四类场景，DIFF 越大越不能快读——不是越大越要大意，而是越大越不能大意：

- 让 AI 顺手重构、清理"还没用上的代码"。删掉的行往往比新增的行危险，尤其是 `except: pass`、防御性 `mkdir -p`、看着没用其实是给下游兼容留的变量。

- AI 替你做了一道"风格统一"。注释格式、日志级别、环境变量前缀，这些"美学改动"最爱和真改动缠在一处，让你第一眼看不出哪行动了脑子、哪行只是换了皮肤。

- 涉及权限、密码路径、shell 展开、并发锁和跨文件契约的改动。这类改动"看起来没问题"的概率不是零，而是"填表时对不上再去翻账单"级别的麻烦。

- 你要把改动交给别人 review，或者自己合进共享仓库。此时 DIFF 里混合了 AI 的判断和你的判断，读者分不出哪块要重点看。

什么时候不用这么读

- 只格式化：跑了 `prettier`、`black`，顺序没动，扫一眼确认没多没少就行。

- 只加一个测试文件：不碰现有逻辑时，点几下就能过。

- AI 只填模板：改的是文件名、大小写、字符串这类确定词，肉眼十秒确认。

这些场景值得省时间，但省的方式不是"不读"，而是"快速扫 + 行数对账"。

30 秒慢功夫怎么做

1. 先 `git status` 确认文件清单和 AI 说改的一致。多出来的文件比漏掉的文件更可疑——文件清单本身就是第一层 DIFF。

2. `git diff --stat` 扫总量。新增 5 行、改了 80 行这种"净删型"改动，重点看删。

3. 一格一格读，读的顺序按疑心排：权限与敏感字段 > 控制流（if/else/循环）> 边界（空输入、空数组、越界）> 字符串与日志 > 其余上下文。

4. 读完过一遍关切口：改动接上下游了吗？调用方那行没改，被改的函数签名却变了。**AI 最擅长的就是改对眼前那行，忘了前面一步。**

5. 本地跑一遍 CI 清单：lint → 测试 → 启服务；顶不住可以只跑 `npm test`，但"编译通过"和"本地绿"是两回事。

6. 最后才是提交。commit message 里写清"做了什么 + 为什么"，AI 风格只写"updated code"的那种，直接打回。

检查清单（贴在终端侧边栏）

- [ ] 改动文件清单 = AI 声称清单，无多无漏

- [ ] 删掉的每一行都解释得清为什么可以删

- [ ] `except` / `||` / `??` 里的默默兜底没被"优化"掉

- [ ] 权限、路径、环境变量没被改名或改位置

- [ ] 中英混排、编码没动（别用 `BOM` 坑自己）

- [ ] 本地 lint + test 绿；CI 下来再过一遍

- [ ] commit message 写明理由，不是 `update` / `fix bug` / `chore`

坑速记

| 坑 | 怎么踩 | 怎么避 |

|---|---|---|

| "还得等我再装个包" | 本地 `npm install` 没跑，CI 绿了本地就挂 | 提交前 `npm ci && npm test`，别信编辑器小绿点 |

| 把 `useEffect` 依赖交给 AI | `eslint-disable` 加了三处，一年的隐性坑 | `eslint --fix` 能解的可自动解，不能解的人工过 |

| `git diff` 看一半就 push | 改到 workspace 命中 `.gitignore`，AI 悄悄挪了路径 | 提交前 `git status` + `git diff --stat` 再看一次 |

| AI 替你把 if/else 并重称优化 | 视觉行数少了，网络 ordering 变了，重试逻辑乱跳 | 看到"看起来更紧凑"就停一秒：真的等价吗？ |

为什么不把这套交给自动化

自动化防的是语法和类型，防不了语义。上面这些坑里，只有 lint 能拦住一两项，其余都靠人读。预算三十秒不贵——贵的是后面两小时你一边打补丁一边骂它"谁让你动它的"的连带火光。

一句话

AI 改完代码，先一格一格读 DIFF；三十秒能拦下的大部分事故，不需要你发明任何新的流程。