大三学生的一句困惑，最近两天在AI编程圈被反复转发。
10月4日，知乎新开了一个问题：「AI写的代码能跑但没人敢动，接手的人该怎么检查？」题主写道"最近几个项目都是AI辅助写的，功能跑起来都正常，但要改的时候没人敢动"，他自己也说不清哪一段是模型臆造的边界条件。知乎
到10月5日，这个问题下面已经聚了至少三份回答，有人给流程，有人给断言方法，有人直接提出先让AI对项目做一次全面评估、输出架构图再逐段排查。问题是新的，但这个问题背后站着的人群一点都不新。知乎
把知乎上几个同方向问题的数据摆在一起（采集于2026年10月5日）：
知乎问题 | 浏览量 | 评论区热度 |
|---|---|---|
现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗？ | 约169.8万 | 9月中旬还在出新回答 |
为什么越是维护过老系统的程序员，越不敢让AI直接改代码？ | 约17.8万 | 54条评论 |
AI写出来的代码越来越多，未来的软件会不会变得「没人真正看得懂」？ | 约14.7万 | 持续有人作答 |
AI生成的代码会出错吗？需要人工审查吗？ | 约2.8万 | 46条评论 |
AI写代码，你还在自己review吗，如何保证正确性？ | 约1.8万 | 36条评论 |
五个问题加起来超过207万次浏览，提问角度各不相同——新手怕改坏、老手不敢让AI碰、旁观者担心整个行业的代码库——但指向的是同一件事：瓶颈已经从"写"挪到了"看懂、敢审、能维护"。
这不是某个人的矫情，是这波AI编程红利走到兑付日期的声音。
一、海外把这事做成了方法论：PR瓶颈，三层刹车
有意思的是，几乎同一时间，海外把这个问题讲成了一套完整方法。
10月5日，B站出现了Matt Pocock在AI Engineer Paris 2026演讲《Fixing the PR Bottleneck》的中文字幕版（约45分钟）。这位以TypeScript教学和aihero.dev闻名的讲者，开场判断很直接：智能体能轻松创建拉取请求，却未必能轻松创建值得审查的拉取请求。代码产出变快之后，真正的瓶颈落到了审查和合并环节。哔哩哔哩
他给的不是口号，是三层刹车，演讲章节列得清清楚楚：
自动检查（便宜，但会骗人）——他专门用了几分钟讲"三类会失真的测试"：测试全绿不等于代码可信，有些断言只是验证了"我们知道要验证的东西"。
自动审查——用深模块改善测试、建立统一设计语言，把"实现审查"和"规范审查"分开做。
人工审查——审查者发现问题应直接提交修复而不是留言扯皮；给人看的PR要小、要带图表说明改动；用复盘把每一次人工审查变成"减少下一次重复工作"的投资。
演讲发布当天，B站就已经有教程区UP主把他那套mattpocock/skills仓库拆到v1.3版本——/implement-spec、/pr、/retro三个技能从in-progress转正进Engineering目录，implement-spec用agent编排sub-agent实现整个spec，/pr专门生成方便人工审查的拉取请求。哔哩哔哩
也就是说，"生成快、审查堵"在海外头部实践者那里已经从吐槽升级成了工具备忘录。而国内社区这边，同样的焦虑还停留在"到底该怎么检查"的提问阶段——这中间的差距，本身就是这篇内容要补的信息差。
二、"没人敢动"的真正机制：技术债开始复利
为什么大家突然都不敢动了？知乎7月一篇被反复提到的专栏（作者杨彪）给出了目前我看到的最好解释：以前改一个陌生模块，你必须先理解它——读代码、翻提交记录、问模块负责人、过评审。这些摩擦很烦，但它强制了"理解在前"。现在一句Prompt，Agent几千行改动，测试全绿，PR描述比人写得还完整。实现速度提上去了，复杂度并没有消失——它只是从"写代码之前必须理解"，变成了"出问题之后再理解"。知乎
更麻烦的是后面这个链条：一个Agent为了完成需求，在错误的层加了一段兼容逻辑；测试通过，功能上线，没人发现问题；下一个Agent读到这段代码，会把它当成现有架构的一部分继续扩展——错误由此获得了合法性。再往后，新的Agent还会为它补测试、写文档、生成"为什么系统应该这样设计"的说明。
一句话总结这个机制：技术债过去只是欠钱，现在还能自动复利。
数据侧也不是只有体感。GitHub上分析了2.11亿行代码变更的GitClear报告，从2024年初就被国内技术博主接力传播（爱可可、宝玉xp、AIGC非著名程序员等都转述过），方向高度一致：代码重复率显著上升，重构活动大幅下降，AI提交让"复制粘贴式代码"越来越多。2025年Stack Overflow调查显示84%的专业开发者已在使用或计划使用AI工具，Google、微软也都披露过AI已撰写超过20%的新代码——产量上去了，但"局部正确、整体失控"的存量正在变厚。知乎
高浏览回答里那些具体的"症状描述"，比数据更让人对号入座：
“AI会用极其优雅的代码结构，去包装一个完全错误的业务假设”——这句出自169.8万浏览问题下的高赞回答。知乎
“bare except、pass、未指定编码的open()调用、大量重复但略有差异的函数块——不会立刻崩溃，但六个月后维护者要花3到4倍的调试成本排雷。”
维护过老系统的那位高赞答主说得更直白：做过复杂系统、对系统可靠性敏感的程序员自然不怎么信任AI，因为它太擅长装专家了。知乎
还有一个容易被忽略的细节，来自一位重度用户的复盘：“因为不是自己写的，遗忘概率还上升”——AI写的代码不仅别人不敢动——写它的人自己三个月后也不敢动。知乎
三、先替你去噪：这几个流传的数字，哪些要打折
这个题目下情绪很多，数字更多。按ZDM的老规矩，把证据强度分开摆：
可以直接引用的： EU《产品责任指令》(EU) 2024/2853真实存在，软件被正式纳入"产品"范畴；按社区转述的口径，2026年12月生效后，若AI生成的代码导致数据损坏或系统故障，企业将面临严格责任，不能再拿"AI自动写的"当免责抗辩。这条法规是今年内就要生效的硬时间窗，不是传闻。知乎
方向可信、数字要标注口径的： GitClear"重复率飙升81%、重构暴跌74%"这组数字在中文社区流传甚广，但它出自GitClear不同年度报告，基期和定义（按变更行占比）有过调整，2024年1月最早传播时的口径和2025年版本并不完全相同。结论是"重复上升、重构下降"这个趋势，多家报告方向一致；具体百分比建议当作量级参考，别当精确事实用。
单一来源、谨慎转发的： 有知乎回答提到"一篇2026年arXiv研究在6299个仓库中识别出48.4万个AI引入的技术债问题，其中22.7%在最新版本中仍然存在"——换算出来就是"近四分之一的AI屎山没人敢动"。这个数字我只在转述里看到，没有交叉验证，当强印象用可以，当论据用不够格。 同样，“最好的AI review工具，采纳率也不到人类的三分之一”（1.8万浏览问题下的回答）属于单点经验，不是社区共识。知乎知乎
值得盯但还没成气候的： 《麻省理工科技评论》中文号9月底转发了一篇《处理AI Coding留下的烂摊子，正成为一片新的蓝海市场》，讲"Vibe Coding清理服务"（Vibe Coding Cleanup as a Service）正在成为新接单门类。现在还是叙事阶段——但它说明了一件事：当"生成"免费了，"收拾"就开始定价。微博
四、行动清单：别等到半年后给自己的代码"上香"
把上面海外方法论和国内高赞答案筛完，按你在这个局里的位置，能带走的东西其实是三套。
如果你是那个"用AI写完不敢动"的人（新手/vibe coding玩家）：
接手或修改之前，先看边界清单而不是代码本身——新问题上高赞答案的顺序值得抄：先过权限、生产数据、对外调用这三类，AI最容易"合规地"走过去。知乎
把现状固化成可执行断言：用最小用例覆盖正常路径和几条异常路径，跑通了，你才证明了"现状就是这样"，后面所有修改都有护栏；
让AI逐条解释代码给你听，解释不清楚的段落按"模型臆造"处理，单独标记；
学一下Matt Pocock的PR习惯：小步提交、带图表说明意图、每次人工审查后写一行复盘——这些是给三个月后的你自己留路标。
如果你是接手AI代码的那位"倒霉同事"：
先别急着重构。老系统维护者那条54评论的答案核心就一句：AI的问题不是写不出大神代码，是不能稳定交货，你的任务不是欣赏它，是给它上约束——限制修改半径，改认证就别顺手重构数据库，跨边界必须重新评审；
把"它编译得过、测试全绿"从通过理由降级为起点，追问"系统还是不是原来的系统"：错误码格式统一吗？同一个概念有没有三套定义？
如果你是小团队里那个要按下合并键的人：
立一条规矩：谁合并，谁负责解释；解释不清，就不该合并。"Agent是这么写的"不能成为答案；
主动奖励删除代码。Agent天生倾向新增——新增最容易"看起来完成了工作"，不奖励删除，代码库只会单向膨胀；
审查的着眼点要从单个PR升级到整个库的持续健康：依赖漏洞、严重度分布、哪些模块已经没人看得懂，这些以前靠事故告诉你，现在得靠工具在合并前告诉你。
还要把成本账算进来：36氪9月那篇实测的结论是，即使使用同一个模型，不同智能体框架也可能让编码成本成倍拉开。而10月5日B站刚有人拿10个提示词去核对网传的省额度清单，结论是额度的大头在"对话轮数×每轮重读的上下文"——审查返工的每一轮，都是在烧钱。36氪哔哩哔哩
最后是12月前要完成的一件合规动作：把AI参与生成的代码纳入版本留痕与责任链，别等到EU新规和它在国内供应链的传导效应上了谈判桌才补作业。
五、往后看什么
这个题还没有终局，接下来三个信号值得持续盯：
今年12月EU产品责任指令落地后，第一批"AI代码事故归责"案例会不会出现、怎么判——那会直接改写"谁合并谁解释"这条规矩的力度；
AI审查类工具的公开基准会不会补上交叉验证的数字——目前"AI review AI"的可信度还停留在个人吐槽层面。这个赛道本身已经不缺钱：36氪8月的报道标题就是"AI代码审查赛道，跑出一个108亿独角兽"，把代码审查、分流、理解、防护统统算作这门生意。更早一篇2025年的行业梳理写道，"当AI开始查AI"的新分支赛道已经获得包括Accel、a16z等美国顶级风投的关注与投资，CodeRabbit、Graphite都是被点名的玩家。36氪36氪
开源社区那道防线会不会向企业内溢：知名Python项目集合Jazzband因无法承受AI生成的垃圾PR和问题单洪流被迫关闭，Godot维护者把甄别AI"slop"称为令人精疲力竭的工作，curl创始人则直接取消了漏洞赏金计划。这些事件在中文技术圈被反复转述，当"防AI投稿"变成开源项目标配，企业内部仓库的AI代码准入大概率紧随其后。知乎
回到开头那个大三学生的问题。"能跑"和"能维护"从来是两种能力：前者AI已经能帮你做到80分，后者目前它还给不了——它甚至会让三个月后的你，也变成"不敢动的人"之一。
这波AI编程真正该抄的作业，不是哪家模型代码写得好，而是Matt Pocock那三层刹车、知乎高赞那三步断言法，加上你自己给代码库立的那条合并规矩。 生成越顺，越要记得给自己留一个敢按下的撤销键。
