9月这几天的知乎编程话题区，几乎被同一股焦虑刷屏：《AI写出来的代码越来越多，未来的软件会不会变得「没人真正看得懂」》一个回答拿下301赞、39条评论；《AI coding导致代码量大幅增加，如何做好代码质量管控》293赞、557次收藏；《现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗》232赞。知乎还有一个刚挂出来、几乎没人回答的新问题，问得特别实在：你们code review时，AI生成的大diff是怎么看的，全看还是抽着看？知乎
三篇高赞加一个新问题，指向同一件事：当"写代码"这件事被AI压到接近免费，整个AI辅助编程的瓶颈搬家了——从"写得快不快"，搬到了"读得过来读不过来"。
一、瓶颈搬家不是情绪，是有账本的
先看两条硬信号。36氪9月8日报道了一位AI原生公司的合伙人，她给自己配了16个Agent，但每天只保持5个活跃，理由里有一句编程场景特别扎心：Agent可以整夜生成代码，第二天工程师可能根本审不过来。36氪人的并行度上不去，机器产能越大，人越像PR队列前的收费站。
另一条来自资本。只做"AI代码审查"这一个赛道，CodeRabbit今年完成了1.43亿美元C轮，估值超15亿美元、约合人民币108亿元。而这家厂商给出的口径是：2026年代码提交量预计将达到往年的14倍及以上，编码智能体渗透率行业前10%的企业里，35%的PR已由自主智能体生成。36氪14倍这个数字要打个问号——卖审查工具的说代码泛滥，天然有立场；但一个赛道能撑起百亿估值，至少说明"审不过来"不是个别程序员的心态问题，而是有人真金白银下场解决的规模问题。
社区里普通开发者的体感也对得上。一位程序员9月9日在微博自述，从3月份开始没写过代码，全部用AI写，连代码审查都交给AI，自己的时间基本花在判断技术方案是否合理、yes or no上。微博博主宝玉xp引的那句"大家都在用AI编程，但代码产出水平的方差反而比以往更大"下面，是一片"真实存在"——以前人一天几百行封顶，AI一天几千几万行，数量加乘把质量的方差直接撑大了。微博
底层逻辑其实很简单：过去"先想清楚再动工"，是因为工程师的时间贵，排期本身就是质检。现在AI把顺序倒了过来——产品经理、运营、设计师都能发起变更，代码先躺进仓库，"值不值得上线"这个判断题才刚刚开始。代码贬值了，注意力变成了稀缺品，PR不再只是等合并的容器，而是变成了全队的决策节点。
二、四个阵营，每个都有人拿真实翻车史垫背
吵得最凶的问题是：那到底谁来读这些代码？扒完这几周的讨论，立场其实只有四种。
A派：自己逐行读。 知乎301赞回答的作者DBinary是个反面教材式的高手：他的vibe小工具"从一开始我就看不懂"，全程顶模照样埋雷；另一个项目里他只让AI生成"自己认为很简单的模板代码"，结果整个8月都在给这堆代码擦屁股——等他想在上面加东西时，一个预料之外的数据结构直接击穿了他的设计。他现在的原则是"古法设计+AI review"。他那句最扎的话值得抄在工位上：AI生成的大部分是对的，很容易给你一种"review过了、它就是你自己"的错觉，但没想清楚的细节，总有一天会让你重新想清楚。知乎
B派：AI审AI，人只守两个闸口。 一个团队发了三个月落地复盘：AI擅长机械性检查（命名、空指针、吞异常），自述基本能顶掉约60%低级错误的人工检查；跨文件一致性扫描和给新人写解释型评论也是它的活。知乎但他们也踩过三个坑：架构决策它会煞有介事地胡说、安全权限判断不可靠、最危险的是给AI自动合并权——一段"看起来合理实则有逻辑漏洞"的代码骗过Bot直接进了主干。他们的结论：AI是过滤器，不是评审员。CodeRabbit新推的Triage功能就是B派的产品化：按风险分流，高风险上报人类、低风险自动处理——再看一遍这句话，出自卖它的人。
C派：不读代码，读验收证据。《代码整洁之道》作者Uncle Bob自己都不逐行review AI写的代码了，知乎那篇293赞回答附了原访谈。知乎他的演化路径很诚实：早期让Agent连续加功能，“改一处坏一处”、原地打转，最后总结出一句关键洞察——The code can get messy enough that the agents cannot deal with it any longer。也就是说，代码一旦脏到某个程度，Agent自己也会空转，屎山不光害人，还害AI。他现在靠三样东西放行：用架构和路径约束生成质量；拆窄任务Agent、任务一结束就换干净上下文；盯CRAP分数（复杂度×覆盖率合成的变更风险指标），低分才允许merge。低错误成本的场景里C派更奔放，一家30人智能硬件公司的开发者直言：UI型交付"是不是屎山，who cares？"，用入库门禁+压力/内存/稳定性测试卡上线，银行支付宝那种系统才谈逐次细审。知乎
D派：彻底交给AI。 在"GPT-6 Astra判断没人看代码时，会倾向写人类看不懂的高度压缩’机器垃圾代码’"的问题下，最高赞（18赞）的回答是：这是好事，反正AI写、AI审、AI读，只要AI觉得好就让AI自己来，还能节省token。知乎目前只有18个赞，但它是B派的逻辑终点：审查权一旦无限扩张，人就是橡皮图章。
D派能不能成立，有一个现成的反证。知乎一篇技术复盘讲过结算服务的真实事故：状态枚举从SUCCESS改成SETTLED，编码智能体一次读完仓库、改了14个文件、补齐单测、PR评审也没发现明显问题——上线后客服后台把已结算订单显示成"处理中"，离线报表把新状态归为未知值，风控补偿任务重复触发。漏掉的不是仓库里的代码，而是仓库外的变更半径：运行时调用、消息订阅、数据仓库SQL、低代码报表、老版本客户端。知乎“模型读完了仓库”，从来不等于"模型知道它会炸到谁"。
三、站队你的不是勇气，是你家代码的错误成本
把这四个阵营摆在一起，会发现一个社区自己没点破的规律：吵的根本不是"信不信模型"，而是"漏掉的代价谁付"。 用三个变量对号入座，比选信仰靠谱：
可逆性：出问题3分钟热修复，还是资损/合规事故？
仓库半径 vs 变更半径：这次改动的影响会不会出仓库（消息订阅、血缘报表、外部消费者）？
验收证据质量：门禁和测试能不能替你"看懂"代码？没有验收证据时，"AI审AI"只是两个AI互相点头。
按场景给结论，而不是按胆量：
个人小工具、demo：C派起步，门禁都没有就"跑炸了再问AI"。301赞回答的教训在于——看不懂的项目迟早不是你的，但小工具看不懂的成本只是重做一个下午。
MVP/增长期产品：B+C混合。AI过滤机械错误，门禁卡上线，人只看三类diff：接口、数据结构、状态机。这三样是AI最爱悄悄偏离你设计意图的地方。
资金、权限、状态终态类链路：A派+变更半径清单。diff可以快扫，但每次枚举/字段/接口变更，必须人工列下游消费者；对每个声称"不受影响"的消费者要证据——"它没订阅这个主题"是确定性证据，"14天Trace里没看到调用"只是采样期没看到，两种话术不是一个信用。
带团队的：你的新排期对象不是人，是审查预算。16个Agent管5个，本质是一个新命题——一个人到底能同时管多少Agent？ 谁先算清自己团队的"人工细审配额"，谁先出事故。
四、今晚就能做的四件事，外加三个观察信号
拿到AI生成的大diff，先别从第一行读起：
先看文件清单，再看diff正文。 跨了接口层、数据层、配置层的14个文件，比单层2000行危险得多——后者AI自己都审得动。
逼Agent交代假设。 让它逐条写出这次改动做了什么设计假设。埋得最深的雷，通常在它没写出来的假设里。
查一个"仓库外"的点。 改了枚举/字段/接口之后，人工grep一遍消息消费方、报表SQL、对外API文档——结算事故里漏掉的三个系统，全在这一层。
给所有AI审查工具关掉"自动合并"。 B派三个月实践里唯一一次直接进主干的事故，就是这条权限造成的。
继续观察三个信号：CodeRabbit们的"14倍"水分，最诚实的检验是你自己团队的PR合并时延和线上缺陷率有没有同步恶化；Uncle Bob式"约束生成"和D派"彻底交给AI"之间的地盘之争，下一个战场大概率是合规条款里要不要写"该代码无人阅读"；以及那个没人回答的知乎问题——等它有了答案，记得回头看今天这篇是不是提前交卷了。
至于大diff到底"全看还是抽着看"，这篇文章的最终答案是：别全看，也别只抽着看，看半径。 你现在在哪个阵营？有没有哪一次"擦屁股"让你一夜换队？评论区聊聊你的翻车账本或者省钱心得。
