Simon Willison最近发了一则只有三句话的短博客,却把一句挺扎心的话摆在台面上:逐行审查代码,从来就不是验证一次代码改动是否正确的最好办法。
这话放在AI编码智能体(Claude Code、Cursor这类能自己写大段代码的工具)满天飞的当下,不是随口一说。Willison这半年一直在写同一件事:代码生成已经不再是瓶颈,人类能不能看懂、能不能验证,才是新的卡点。他8月14日上过一个播客,8月19日又写了一篇关于"概念完整性"的文章,这条note更像是那条思路的一句总结陈词。
不逐行看,那看什么
问题来了:如果不逐行审查,到底该验证什么?
Willison在播客里给过一份挺具体的清单。他认为,靠谱的验证至少要包含五件事:让智能体真的把代码跑起来;要求有一段"如果实现被还原就必然失败"的自动化测试;留下截图、日志、预览部署这类具体证据;确保有人能讲清楚这个改动到底做了什么;最后检查这段代码跟整个系统的架构是不是长得像一家人。
他给"能不能交付"定的标准也很直白:能不能向别人解释这次改动。解释不清楚,就还没到能上线的地步。这比"测试全绿"要求更高——测试可以造假,解释造不了假。
（下图是这份清单的五个环节，从左到右基本对应一次改动从"跑起来"到"能交付"的过程。）
行业已经把这套体系做厚了
Willison说的是个人操作层面的经验,行业其实已经在往同一个方向铺基础设施,只是分工不一样。
GitHub的CI和CodeQL可以设成合并前的硬门槛——测试不过、安全检查有超标发现,PR就是合不了,这跟"人盯着看"是两码事,是机器守门。Docker最新的sandbox安全文档也提醒得很直白:普通容器隔离不等于真正的强隔离,如果直接把工作区挂给智能体,它理论上能改Git hooks、CI配置这些"裁判文件"本身,防护需要靠微VM隔离、网络策略、凭证代理这几层叠加。
有一个容易被搞混的点得说清楚:SWE-bench这类基准测的是智能体能不能在特定仓库里解决issue,它是能力评测,不是生产验收工具。拿基准分数当"这段代码能上线"的证明,是张冠李戴。
低风险改动配轻量CI就够,中风险要加静态分析和沙箱隔离,高风险则需要人工复核加灰度发布——这是一套按风险分级、深度递增的验证栈,而不是一刀切的自动化替代人工。
自动化不是免罪金牌
这里有个容易被忽略的坑:测试全绿不等于代码正确。智能体完全可能写出弱测试,或者悄悄改动测试本身去配合实现,把"绿灯"刷出来。这恰好印证了Willison的判断——只看代码本身不够,但换成只看测试结果,一样不够。
- 风险.自动化验证把"审查代码"变成了"审查证据链",证据链一样可以被污染,人的判断依然是最后一道闸。
孟子那句"尽信书,则不如无书"放在这儿正合适。测试、CI、沙箱都是"书",信过头,一样会被带偏。
谁该现在动手
这套完整的验证栈——CI门禁、沙箱隔离、mutation testing、灰度发布——搭起来是要花钱花人力的。对有专职DevOps和安全团队的公司,这是把验证成本前置、变成基础设施投入,长期划算。
对个人开发者和小团队,搭不起整套栈很正常,但至少可以把Willison那五步清单当最低配版:让智能体自己跑一遍、写一个会失败的测试、留一份日志或截图、自己能讲清楚改了什么。这几步不需要额外工具,只需要多问一句"你凭什么说这段代码是对的"。
逐行看代码从来不是终点,现在更不该是唯一手段。真正该问的是:证据够不够、能不能讲清楚——这比读代码本身,更接近验证的本质。