堵住一个窟窿，又捅开一个更大的——这不是段子，是知乎用户"老久"9月初复盘的一次P0线上事故：后端同学用AI复制了一段旧活动代码、改参数生成新活动，上线急、测试也急，只测了新账号。结果老玩家领不到活动奖励，客服群瞬间炸锅；紧急修复还是用AI改的，改完上线，新玩家可以重复领取。用AI修AI的bug，修出一个新bug。知乎
从7月到10月，同一个话题在知乎反复冒头：“AI生成的代码上线造成事故，责任该如何划分”（7月）、“用AI生成的代码出了线上事故，责任到底算谁的”（9月）；"程序员的代码大多数是AI生成的，后面会成为屎山吗"下面，一条回答拿到1897赞、168万次围观；"现在90%代码是AI写的，调试和阅读时间增加了120%"的回答挂着124条评论。而就在10月2日今天，一个新的热题"用AI编程写完功能后，你们会如何检查代码，才不至于上线后返工"刚被答爆，高赞回答第一句就是泼冷水：在你决定让AI接管项目代码之前，就该做好"问题非要等到炸了才能发现"的准备。这股浪潮的底色，GitHub官方Octoverse 2025报告已经给出：八成的新注册开发者，第一周就用上了AI辅助写代码。知乎知乎GitHub官方博客
这篇想讲清楚一件事：AI编程的返工账单，不靠"看得更仔细"来付，靠的是"谁提前把验证建起来"。
新屎山长得并不像屎山
过去十年，程序员说的屎山是缩进乱七八糟、变量名叫a1b2、一个函数一万行。按这个标准，AI写的代码简直是艺术品：语法极其规整、缩进完美、命名规范，还贴心加上英文注释——光看当前这个文件，你挑不出任何毛病。
但工程灾难从来不是因为缩进难看。真正的灾难是技术债的无序积累：模块边界混乱、重复实现业务逻辑、隐式依赖全局状态、错误处理被强行吞掉。有知乎答主管这叫"理解债务"：AI恰恰在制造这类深层结构性灾难上，效率高得惊人。GitHub官方Octoverse 2025报告给了一条更具体的曲线：CodeQL扫出的GitHub Actions常见漏洞，2022—2024年几乎为零，2025年直接突破两万个；报告还点名，Broken Access Control已超过注入攻击成为最常见的CodeQL告警、涉及15万多个仓库、同比增长172%，其中很大一部分就来自配置错误的CI/CD权限和跳过关键鉴权检查的AI生成脚手架——新代码涌进来的速度有多快，漏洞混进来的速度就有多快。知乎GitHub官方博客
他讲过一个真实案例：团队做订单状态流转重构，一个工作不到两年的同学把需求文档喂给高级智能体，几百行代码几分钟生成，单元测试全绿，自己点了几下页面正常，提了MR；审查导师看代码规整、注释齐全，跑了主流程没问题就批了。三个星期后线上出现订单状态错乱——用户明明付了款，特定并发场景下状态被重置回待支付，触发了库存释放。排查时他愣住了：AI为了让单元测试通过，极其聪明地在缓存层做了一套复杂的异步补偿机制，逻辑自洽、还用上了高级并发设计模式，单看那个类写得相当精妙。但公司技术规范明文要求：涉及资金状态的核心订单流转必须强依赖数据库事务一致性，不允许在应用层做缓存状态补偿。AI根本不知道这条历史规矩。修复的代价：重新梳理上游支付网关回调链路、排查这套缓存机制污染了多少在途订单、把华丽但违背架构原则的代码全部删掉，按原规范重写一遍带悲观锁的数据库操作。知乎
DBinary在今天的回答里把话挑得更明：AI生成的代码大部分情况下都是对的，问题恰恰出在这个"大多数都对"——你决定用AI接管项目的时候，就该按这个预期来。靠装一堆skill、写更详细的spec、走SDD/TDD流程，本质上是给70年代的瀑布模型换了一层皮：demo工程里工作得不错，工程一上规模，“你说的和你得到的根本不是一回事”。知乎
一句话总结这层的坑：你review时看到的是"AI改了哪些地方"，看不到的是"AI不知道什么"——它不知道你们公司的历史规矩，不知道老账号的数据结构长什么样，它的世界里只有代码，没有玩家。
时间没有消失，只是搬了家
那位"开发时间缩小90%、调试和阅读时间增加120%"的知乎用户唐林，还描述了另一个循环：流程越来越复杂时，功能A的bug改了以后出现B的bug，以此循环。这条回答之所以能被顶到前排，是因为每个让AI大规模接管过代码的人都认这个账。
把调试成本拆开看就明白了：排查一个bug的完整时间等于复现问题、定位问题、重建上下文、编写修复、回归验证五个环节之和。AI确实能把"编写修复代码"压到几秒钟，但它把"重建上下文"和"回归验证"拉得更长。传统开发里老员工写了一坨烂代码，虽然乱，但写的人心里有张地图，回去修bug能迅速加载当时的上下文。AI接管之后，开发者看到界面能动、测试跑通就直接合并，对系统没有任何心智模型。几个月后报警响了，原作者打开代码骂"这到底是谁写的逻辑"，查了版本记录才发现是自己三个月前按回车键接受的AI方案。AI时代调试的返工，很多时候不是改代码，是先把自己当年没弄懂的东西重新弄懂一遍。知乎
更微妙的是review这关。你review AI一次性吐出来的几百行代码，效果约等于没review——它最擅长的事就是"看起来没问题"：语法工整、注释齐全，你扫一眼觉得挺好，业务逻辑的坑全藏在水面下面。知乎
AI审AI，不是救星
看到这儿你可能会想：人review不过来，让AI来review AI写的代码呢？老久在事故复盘里给出的判断很扎心：最好的AI review工具，采纳率也不到人类的三分之一；最差的，基本等于说废话。原因不难理解——AI review擅长代码风格、防御性编程建议这类表面问题，业务逻辑的正确性它看不懂，因为它不知道"老玩家领不到奖励"是个问题。知乎
行业里的折中方案是"换个AI来审"：Greptile团队主张review agent要和coding agent分开，用不同的模型、不同的上下文做review，至少多一个视角——但记住，这层只是辅助，不是保险栓。让写代码的AI自己review自己，就像让被告当自己的法官。知乎
开源项目已经在把这条线写成明文规则。2026年8月，Rust项目的编译器、标准库、类型系统、rustdoc、bootstrap五个团队采纳了LLM使用新规，一句话概括：可以用AI思考、审查、翻译，唯独不能替它创造。新规明确，LLM的审查结果不能代替人工审查，更不能仅因为AI给出了结论就据此合并或拒绝一个改动；审查机器人必须用独立、明确标记的账号运行，不想看AI生成内容的审阅者可以直接拒审。相比之下，Zig走的是全面禁止路线——禁AI代码、禁AI改写转述，连翻译、头脑风暴、找bug都不行。一个遵守成本高、一个判断成本高，Rust和Zig这张对照表，恰好是当前全行业划线难的两面。36氪
工具层面也有可参考的信号：开源项目Rigour在AI agent每次写文件时自动触发quality gates——AST级分析、检测AI编造的不存在的依赖包、检测代码drift，他们审计过一个18万star的项目，几秒内检出2080个违规；另一个叫Vibe Coding Checklist的项目总结了AI代码的四类常见坑：UI看起来完整但逻辑是stub、API key写在前端、依赖包根本不存在、所有路径都假设happy path。这些问题肉眼很难找全，但自动化检查可以。知乎
责任那笔账目前还是糊涂账。知乎题主写的场景就是现实本身：出了事故，“写的人说是AI生成的，审查的人说是AI说没问题，提需求的说需求没写清”。没人认账，不是因为谁坏，而是因为这条链上没人真正签过字。
四层防线：把账单拦在上线之前
老久团队事故后的工作流值得直接抄作业：AI写代码→AI同时生成测试用例（人工补充边界场景）→跑全量测试→静态分析→CI流水线→独立AI review做第一道筛选→人类只看业务逻辑和架构。拆开是四层：
第一层，测试驱动，但得测对地方。那场事故的根因不是缺review，是缺一条"老账号领取活动奖励"的测试用例——有这条用例，第一轮bug在测试阶段就挂了。让AI写代码的同时让AI写测试用例，但测哪些场景（新账号、老账号、边界、异常路径）必须人来定。测试挂了就是挂了，没有商量余地。
第二层，类型系统和静态分析。TypeScript、Rust的所有权系统、Python type hints加mypy——AI生成的代码经常类型不匹配、空值没处理，一跑静态分析就露馅，这些在编译阶段就能挡掉一大类问题。
第三层，CI/CD流水线。每次提交自动跑全量测试、lint、安全扫描，这层不讲感情：不管代码谁写的，不通过就合不进去。他们事故后加的第一条CI规则就是"活动相关代码必须跑完整回归测试，不能skip"。
第四层，人类review换重心。不再逐行找语法错误，只看"这个场景想全了没有、老账号会不会有问题、和旧功能兼容吗"。人的价值不在找语法错误，在于知道有哪些场景该测。
一句话把这层讲透：review是社交行为，正确性靠验证体系。AI只是把问题变得更迫切了——它生成代码的速度远超你review的速度，而且它生成的代码看起来总是"像对的"。与其追着AI的屁股一行行review，不如把时间花在搭验证体系上。知乎
不同段位，各拿各的方案
个人项目、vibe coding党：代码不上生产、坑只伤自己，最低成本做两件事就够了——让AI同步生成测试用例，合并前跑一遍Vibe Coding Checklist四条（stub逻辑、前端密钥、假依赖、happy path）。返工疼，但不致命。
在职开发、碰生产环境的中间层：钱、状态机、权限这类核心路径别让AI全代写——可以让它帮你review，但不能让它完全帮你写。DBinary那个绘画比喻很准：念咒能把出图质量念到80分，要挑战90分，仍然得自己拿笔。另外把公司架构红线（事务一致性、禁用应用层补偿这类"历史规矩"）写进rules或上下文，AI不知道规矩，是最大的事故来源。知乎
带团队、上规模：别指望给每个人配一个AI review工具，要配的是验证流水线。同时警惕"方法论幻觉"——今天热榜高赞里吵得最凶的分歧就在这：一派说写好spec、装好skill就能高枕无忧，另一派（DBinary们）说过度规划在工程上一戳就破，AI时代更该信"边做边改+验证兜底"，而不是塞更多车轱辘话skill。
反证也得摆上桌
别以为全网都在唱衰。知乎用户"最最遥远的路"经历两次AI代码引发的线上事故、差点丢工作之后，选择退回手写核心代码，AI只用来写测试用例和脚本——这是幻灭派。但同一个问题下也有认真算账的：按实际使用和社区反馈估计，AI对普通编码的替代率大概三成，整体提效20%—50%，架构复杂或性能敏感的核心代码仍需要人高度介入。两种声音并不矛盾：账单是真的，数字也有语境——返工成本付多少，取决于你上生产的是"普通代码"还是"核心路径"。知乎
接下来盯什么
产业侧，字节跳动技术副总裁洪定坤在火山引擎Force大会上罕见坦诚地讲了AI Coding踩过的坑，被博主总结成"7条反常识结论"在微博传了一轮——大厂实践大概率是下一轮方法论的源头，可以盯着他们怎么定义"AI生成、人类审查"的边界。基准侧，Epoch AI的MirrorCode基准测试印证了一个开发者81天、2600次提交用Claude复刻Bash的经历：3000个测试全过了，但几行小修补要耗费数小时，大架构重构直接畏缩不前；顶级模型在重构中型项目时成功率能到64%，单次尝试的成本却高达2600美元，而且极度依赖已有测试用例来纠偏——AI的短板（长程任务、跨模块一致性）恰好就是返工账单开出来的地方。把逐目标得分摊开看更扎心：四个模型平均64%、20%、16%、10%，越是大项目，0分格子越多。微博微博
证据覆盖到这里，结论也只下到这里：AI让写代码这件事便宜了，但没有让"对"这件事便宜。用AI用得越狠，你越得把自己当成签字的人，而不是读稿的人。至少，先给老账号留一条测试用例。
