AI 编程真正贵的不是 Token,而是 Review

上周评审一个 PR，标题写得很朴素：优化订单列表导出。

我点进去之前，以为就是加两个字段，最多改一下查询条件。结果 diff 展开以后，代码干净得有点过分：DTO 补了，日志补了，异常也补了，连单测名字都起得挺像回事。

说实话，第一眼我还挺满意。

然后看到一段缓存逻辑，我停了一下。

它把导出条件 hash 了一下，丢进缓存，默认 5 分钟。单看这一段，没毛病，甚至还有点“工程化”。问题是我们这个导出入口有个很土的历史限制：同一个用户，在某些状态切换后，30 秒内看到的数据就可能变。

这个限制没有写在接口注释里，也没有写在需求文档里。它藏在两年前的一次线上事故复盘里。

写 PR 的同事也不一定知道。他可能只是让工具“帮我优化一下导出性能”，然后拿到了一段看起来很顺的代码。

不是烂得很明显的那种。明显的烂代码其实好办，变量名乱、判断条件拧巴、异常到处飞，review 的时候一眼就能揪出来。

麻烦的是那种很体面的代码。

命名舒服，缩进舒服，注释也舒服。你如果当天会开多了，脑子有点钝，很容易就点了 approve。

我不反对用 AI 写代码。小肆自己也天天用。

改类型、补测试骨架、查调用链、写小脚本，这些活让 AI 做，确实舒服。尤其是那种一看就重复、一写就烦的代码，交给它没什么心理负担。

但公司里的代码不是写完就结束。

写完以后，要有人看。看完以后，要有人合。合完以后，要有人盯灰度。灰度出问题，还要有人半夜起来解释为什么。

以前一个人一天提两个 PR，reviewer 还能慢慢看。现在工具一接进来，半天堆三四个小 PR 很正常。每个 PR 都不大，每个 PR 都挺像样，每个 PR 又都藏着一点“你最好再想想”的地方。

这就很烦。

因为 review 不是数行数，也不是看格式。真正耗人的，是你得在脑子里跑一遍业务。

这个字段能不能缓存？

这个异常吞了以后，报警还会不会响？

这个公共方法抽出去以后，隔壁团队会不会顺手也接进来？

这个重试如果打到下游，凌晨流量尖刺会不会把别人也拖下水？

这些问题，AI 可以帮你列，但最后那个“敢不敢合”，还是人来背。

不是所有 AI 代码都危险。很多时候它只是帮人把脏活干了。

但我现在看 PR，会对几个地方比较敏感。

一个是 catch。

以前人写 catch，很多时候是懒，直接 printStackTrace 或者丢个日志就算了。现在 AI 写 catch，反而太“优雅”。它会给你包装一个返回值，补一个友好提示，看起来用户体验很好。

可有些异常本来就不该优雅。

库存扣减失败、支付回调失败、权限校验失败，这些地方如果被包装得太好看，监控可能就安静了。监控一安静，问题就会去用户那边闹。

还有抽象。

AI 特别喜欢把代码收拾得很体面。两个地方长得像，它就想抽；一个策略看着能复用，它就想起个 Strategy；一个判断多了两层，它就开始建 helper。

这事不能说错。

但业务代码很多时候不是数学题。今天像，明天就不像了。你抽得越早，后面改需求的时候越像在拆胶水。

测试也一样。

现在很多 AI 补出来的单测，跑得过，名字也好听，但测的都是“阳光灿烂”的路径。真正容易出事的，往往是重复提交、脏数据、并发回调、老版本客户端传奇怪字段。

这些场景，模型很难自己想到。

这句话可能不太好听，但我现在真是这么用的。

我会让它写初稿，让它帮我查一个陌生模块，让它把一段啰嗦代码压短一点。它给的东西能省时间，这个没必要嘴硬。

但我不会默认它懂我们系统。

尤其是碰到这几种改动，我会让自己慢下来：

这些地方用 AI 没问题。

我现在比较习惯让它在 PR 描述里多写两句：这段代码是怎么生成的，哪些地方我确认过，哪些地方我没把握。

不是为了证明“我没偷懒”。

是为了让 reviewer 少猜一点。

你不说，别人只能从 diff 里猜。猜这件事很累，而且容易猜错。

以前我觉得写代码快是很大的优势。

现在看，快当然还是好事，但没以前那么稀缺了。工具越来越强，大家都能快一点。

真正拉开差距的，反而是你在某个地方停一下。

看到一个缓存，停一下。

看到一个 catch，停一下。

看到一个抽象，停一下。

看到一堆“看起来很完整”的单测，也停一下。

很多线上问题，回头看都不是因为没人会写代码，而是因为当时大家都觉得“应该没事”。

AI 会让这种“应该没事”的代码变多。

所以这段时间我对 AI 编程的态度挺简单：

能用，尽量用。

该快，确实快。

但合代码之前，最好还是问一句：这段如果今晚炸了，我能不能解释清楚？

如果解释不清楚，那就先别急着点 approve。

Token 花多一点少一点，月底看看账单就知道。