一个团队每个迭代的测试都全绿，合起来才发现，几个服务之间的约定根本没写进任何一条测试里。这种事通常要等半年才被发现。
AI 编程把「局部正确」做得太好了。它一次只看见上下文里的那几个文件，改一个去重逻辑、换一个重试请求号、按老约定兜底，每一处都说得通。
比如一个服务按请求号去重，另一个服务重试时换了新号，第三个服务收到「券已用」就按原价继续——三份代码放在一起也不冲突，文本层面甚至不会产生一行 merge conflict。
可行为已经变了。测试全绿，用户却多付了钱。
Fowler 在 2011 年把这类问题叫「语义冲突」：文本没冲突，行为冲突。AI 让冲突变多，因为它改得快、看得窄。它只在那几页里做到最好，至于和系统其余部分的约定，既不知道，也没人写下来。Martin Fowler哔哩哔哩
测试为什么还是绿的？因为测试只验证写测试的人当时想到的事。约定是口头的、跨团队的、散在群聊里的，落不进任何一条断言。
一项 Cursor 研究（arXiv 2511.04427）发现，采用后开发速度显著提升，但很短暂；静态分析警告和代码复杂度却持续上升，并成为后来拖慢速度的主因。先快后慢，账单晚几个月才到。arXiv
但别急着把锅全甩给 AI。
另一项 151 人、95% 是职业开发者的对照实验（arXiv 2507.00788）里，AI 辅助写出的功能，交给另一批人不用 AI 继续演进，完成时间和代码质量都没有显著差异。arXiv
第一阶段，AI 把完成时间中位数缩短了 30.7%；至少在这个任务范围内，没看到系统性的可维护性恶化。arXiv
两项研究不矛盾：一个看的是真实开源项目的长期演化，一个看的是受控任务里的短期接手。
它们共同说明，问题不在「AI 写的代码能不能读」，而在「有没有人真的懂它为什么这么写」。
Lehman 在上世纪就总结过，系统会越改越复杂，除非专门投力气去对抗。
Naur 则说，程序真正的样子是活在人心里的那套理论。
沿着这个思路，AI 可以把代码写出来，但那套理论可能从头到尾没在任何人脑子里存在过。写和懂，第一次被拆开了。
所以，PR 全绿只能证明「这一小块按我们记得的规则跑通了」，证明不了系统还健康。
要补的也不是更厚的测试，而是三件很土的事。
每个迭代固定一个人看全局，看依赖图往哪长、哪些边界被越过。
把「降复杂度」写进预算——改得越快，留得越多。
交接时让接手的人讲一遍关键的「为什么」，讲不清就不算交完，讲清了就写回代码旁边。AI 每次会话都是新人。
绿色是局部信号，不是健康证明。系统烂掉的时候，测试通常还是绿的。
