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

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

什么时候必须一格一格读

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

让 AI 顺手重构、清理"还没用上的代码"。删掉的行往往比新增的行危险，尤其是 except: pass、防御性 mkdir -p、看着没用其实是给下游兼容留的变量。
AI 替你做了一道"风格统一"。注释格式、日志级别、环境变量前缀，这些"美学改动"最爱和真改动缠在一处，让你第一眼看不出哪行动了脑子、哪行只是换了皮肤。
涉及权限、密码路径、shell 展开、并发锁和跨文件契约的改动。这类改动"看起来没问题"的概率不是零，而是"填表时对不上再去翻账单"级别的麻烦。
你要把改动交给别人 review，或者自己合进共享仓库。此时 DIFF 里混合了 AI 的判断和你的判断，读者分不出哪块要重点看。

什么时候不用这么读

只格式化：跑了 prettier、black，顺序没动，扫一眼确认没多没少就行。
只加一个测试文件：不碰现有逻辑时，点几下就能过。
AI 只填模板：改的是文件名、大小写、字符串这类确定词，肉眼十秒确认。

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

30 秒慢功夫怎么做

先 git status 确认文件清单和 AI 说改的一致。多出来的文件比漏掉的文件更可疑——文件清单本身就是第一层 DIFF。
git diff --stat 扫总量。新增 5 行、改了 80 行这种"净删型"改动，重点看删。
一格一格读，读的顺序按疑心排：权限与敏感字段 > 控制流（if/else/循环）> 边界（空输入、空数组、越界）> 字符串与日志 > 其余上下文。
读完过一遍关切口：改动接上下游了吗？调用方那行没改，被改的函数签名却变了。AI 最擅长的就是改对眼前那行，忘了前面一步。
本地跑一遍 CI 清单：lint → 测试 → 启服务；顶不住可以只跑 npm test，但"编译通过"和"本地绿"是两回事。
最后才是提交。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；三十秒能拦下的大部分事故，不需要你发明任何新的流程。