AI写的代码能跑、测试能过，你却答不上"为什么"
"这个过期时间为什么定30分钟，而不是5分钟或者2小时？"评审会上被问到这句而当场卡壳的人，最近真的不少。代码是AI写的，能跑，测试全绿，可那个数字你没定过，甚至没看过。更扎心的坦白在评论区：上周让AI写了个功能，当时1000来行，优化到第31版已经4500行，跟领导讨论时不知道怎么实现，只能当场问AI。知乎哔哩哔哩
先别急着笑，这不是个人摆烂，是系统性事件。GitHub最新的Octoverse报告显示：2026年9月，平台上超过40%的公开PR，第一稿已经是Agent写的——3月时这个比例还只有17%。代码分析公司GitClear逐行扒了2020到2024年2.11亿行代码变更，发现代码库从以前的"越住越整洁"变成"越堆越乱"：加代码不要钱了，没人再顺手整理底下的。GitHub官方博客知乎
坑在哪？Sonar调查了1100多名开发者，88%说AI代码有坑，而坑排第一的不是"跑不通"——53%的人选了"看起来正确，但不可靠"。这才是要害：人写的烂代码会当场暴露，编译报错、测试爆红；AI写的"几乎对"会潜伏，review能过、测试能过、上线几个月没事，直到某个边界条件把它引爆——那时候，已经没人知道这段代码当初为什么这么写。烂代码你至少恨它，"几乎对"的代码你会信任它。知乎
速度差更残酷。哈佛大学研究者分析企业采用AI编程Agent后的数据：代码产量增加约30%、PR数量增加约23%，但PR从提交到合并的平均时间反而增加了49%；斯坦福、CMU等研究者分析超过19万个PR后发现，每位审查者的工作量大约翻倍。Octoverse的数据同样刺眼：Agent参与的PR里约87%横跨多个文件，而普通PR这个数字只有79%。AI把生成提速十倍，人审代码还是那个手速——这不是效率问题，是数学问题。知乎GitHub官方博客
业内给这起了个新名字：理解债——系统里的代码量，和团队真正能解释的代码量，中间的差距。今年3月那篇《Debt Behind the AI Boom》研究了6275个GitHub仓库、约30.4万个AI编写的提交，识别出约48.5万个代码问题——其中相当一部分不会被后续开发清理，而是长期存活在代码库里。技术债好歹有账本，理解债连账本都没有。早在1985年就有人把话说透：程序真正的产品不是代码，而是活在人脑子里那套"为什么"——为什么这样设计、边界在哪、动了哪会炸哪。AI能量产代码，量产不了"为什么"。连AI辅助开发圈公认玩得最深的Simon Willison，都承认过整段让AI生成功能之后，“我在自己的项目里迷路了”。知乎知乎
但先别急着给AI定罪。发表于《Empirical Software Engineering》的受控实验，151名参与者绝大多数是专业开发者，并没有发现AI辅助开发会系统性地降低后续维护能力。CMU分析3100条从业者讨论，结论一针见血：会review、会测试AI代码的团队全在晒收益，跳过review的团队全在讲事故。同一批工具，两种命运，差别就在生成之后、合并之前那一步你有没有看懂。Claude Code团队自己就是样本：约90%代码由AI编写，6到9月PR翻了一倍多，回滚率反而降了40%以上。因为他们把"读懂代码"外包给了自动化，把人的注意力留给风险和判断。知乎知乎知乎知乎
所以防线其实就五条，不玄：
动手前先把问题收敛。说不清要解决什么、数据从哪来、边界情况、失败了怎么办，就别急着丢给AI。"模糊需求+像样代码"是最危险的组合，你省掉的思考不会消失，只会晚点到、以bug的形式还回来。
讲不出为什么，就不合并。遮掉代码问自己三句：它在解决什么问题？最可能坏在哪？敢不敢在它基础上改需求？有一个答不上，这段代码就还不属于你。
把约定写进仓库。技术栈版本、目录命名、负面清单、验证命令，放进规则文件每次生成一起带上。很多团队写的时候才发现：内部有三套互相打架的做法。
review先扫四个雷。偷偷引入的依赖、空的异常处理、假设输入理想的边界条件、藏在暗处的全局状态——按这四条扫，能拦掉大部分后期麻烦。逐行读不完三千行diff的时候，让AI先过一遍、人只看结论和风险点，是被验证过的分工。
改动别问"怎么改"，先问"谁用到了这个字段"。前者得到局部补丁，后者得到真正需要动的范围；再每季度做一次重复代码扫描——AI是"复制式正确"，同一个逻辑三处各一遍，改规则时你可能只找到两处。
再加一个保底动作：每周留半天关掉助手手写一个小功能。手感三个月不用就会钝，而钝的时候你自己察觉不到——察觉到的那天，往往就是评审会卡壳的那天。知乎
151人的实验和3100条讨论共同指向一个结论：AI压缩的不是你的岗位，是账单寄到的时间。红利属于守住"看懂才合并"这条线的人；不设防的团队，只是用十倍速，堆自己的坟场。
三个月后你那个仓库还能跑。但你自己，还讲得清它吗？
