AI写代码速度暴涨300%，但你的代码库正在变成一坨定时炸弹，你敢不敢关灯让它自己跑？
AI编程助手让代码产出爆炸，但软件质量正在雪崩。Faros AI报告显示事故率飙升242%，PR审查质量跌入谷底。关灯工厂、强化学习、代码可维护性、SWE-bench测试集，这些概念正在撕裂开发团队。你以为在加速，其实在给自己挖坟。为什么AI能秒解编程题却搞不定代码设计？为什么模型越强，代码越烂？
这篇文章从1968年的软件工厂讲到2026年的AI工厂，拆解强化学习如何训练出只会做题不会设计的代码生成器，告诉你为什么关灯工厂注定翻车，以及如何在AI时代保住代码质量不崩盘。
代码工厂画饼史：从1968年画到今天
1968年北约开了一场会，那帮人第一次喊出“软件工程”这四个字。同一场会，他们也在琢磨怎么搞“软件工厂”——把写代码这事儿流水线化，像造汽车一样造软件。那会儿他们想的是，把人的脑力劳动拆成标准化步骤，输入需求，输出代码，中间别出岔子。
五十年过去了，软件工厂这个梦一直没死。2022年那会儿，典型的软件工厂长什么样？产品经理拍脑袋定需求，工程师从Jira或者Linear上薅一张票，吭哧吭哧写代码，跑测试，提Pull Request，等人审查，改bug，再提，再审查，最后上线。上线之后加监控，半夜三点被报警电话叫醒，爬起来修bug，第二天用户接着提新需求。这套流程里有好几个循环：需求→开发→审查→上线→监控→反馈→再需求。每个循环都有人的手在里头扒拉，慢是慢了点，但至少有人兜底。
2022年之后AI杀进来了，软件工厂突然变得性感了。Ramp、Stripe、WorkOS、Brex这帮公司争先恐后地秀肌肉，说他们75%的代码都是AI写的，他们管这玩意儿叫“代理工厂”。原来的流程图里，“工程师写代码”这一步被换成了“AI代理写代码”——你扔一个需求进去，AI自己搭环境、读代码、改文件、跑测试，最后吐出来一个PR。
这看起来美得很。但注意了，AI写代码从几个小时压缩到几分钟，审查代码的人可没提速，还是那几个小时甚至几天。于是他们又往里塞AI代码审查，AI回归测试，让AI自己给自己挑刺儿。还不够快？那就把人类审查员整个踹出去，这就是所谓的“关灯工厂”——人类不读代码，人类不写代码，全交给AI，出了事故AI自己修，修完了AI自己审，审完了AI自己上线。多完美的闭环。
StrongDM就是这么干的，Dan Shapiro还给这事儿分了五个等级，从“辣鸡自动补全”一路升到“关灯工厂”。
Simon Willison也帮着吹了一波。
你问成果如何？StrongDM那个工厂的“天气报告”从今年二月到六月就挤了几滴牙膏，跟便秘似的。七月二十三号他们在Hacker News上冒了个泡，说“可能很快会有正式更新”。你品品这个“可能很快”是什么意思。
数据打脸现场：事故暴增242%
Faros AI出了份报告，把脸打得啪啪响。自从今年一月二月大家都捡起AI编程工具，PR审查质量直接跳水。评论数多了25%，评论长度涨了22.7%，更有31.3%的PR连审都不审就直接合并了。没审就合，出了事儿谁背锅？
事故率涨了多少？每个PR对应的事故数暴增242.7%，月度事故总数涨了57.9%，每个开发者的bug量涨了54%。你可能会说，这报告只是相关性，不是因果。对，我承认这不是实锤。但你摸着良心说，你见过哪个项目用了AI之后代码质量肉眼可见地变好了？你心里那杆秤偏没偏，你自己清楚。
Faros这份数据跟我的体感完全对得上。我去年夏天也上头过，逢人就吹“上下文工程”怎么怎么牛，我的视频在YouTube上攒了快一百万播放。但吹得越狠，摔得越惨。我这大半年天天在代码堆里打滚，发现那些光环底下全是屎山。
关灯工厂翻车实录：我自己就是那个傻逼
去年七月，我们公司脑子一热，决定全盘关灯。
任务描述扔进去，AI自己拆票，自己写代码，自己提PR，我们不看代码，只点合并。刚开始几天，爽啊。开发速度快得像开了挂，感觉明天就能把整个互联网重写一遍。
然后出事儿了。
一个看起来平平无奇的bug，AI死都修不好。你换提示词，你换工作流，你给它喂更多上下文，你把代码库里所有相关文件全塞给它，它在十种不同的姿势里反复横跳，就是修不对。
最后你只能自己撸起袖子，捡起那本你三个月没翻开过的代码库，硬着头皮往里钻。那代码写的，跟屎壳郎推粪球似的，滚哪儿算哪儿，完全没有章法。
第一次翻车我忍了，安慰自己“速度快就是好，代价可以接受”。
到了十一月份第三次翻车，我跟我合伙人看着那堆代码，一致同意：重写比修bug快。我俩在VS Code里蹲了两个星期——连Cursor都没开，纯手撸——把那坨烂摊子重新铺了一遍。
两个星期全手动，你告诉我这是加速？
这故事我不是来卖惨的，我是想说：灯一关，你连自己怎么死的都不知道。
模型不会维护代码，只会制造屎山
为什么AI能把代码越写越烂？这事儿得从根儿上刨。
你随手写个小工具，或者搭个营销官网，现在的模型确实比去年强太多了。但你要是让它在一个已经跑了三五年的代码库里加功能、修bug、重构模块，它照样把代码搅成一锅粥。这不叫退步，这叫“从未进步过”。
我说的“可维护性”不是什么玄学，就是Martin Fowler说的那个“霰弹式修改”——你想改一个地方，结果发现得同时改十一个文件，改了还不敢保证哪儿会炸。当你打开一个文件准备加一行代码，结果发现加不进去，因为这一行会牵动二十个别的文件，你才意识到，你之前让AI闭眼写的那些代码，正在用这种方式向你讨债。
为什么模型学不会维护代码？这得从它们怎么被训练出来的说起。Claude Code为什么能赢？不是因为提示词写得花，而是因为Anthropic在训练模型的时候，直接把模型扔进了它要用的工具环境里做强化学习。普通的CLI代理，比如aider、cline、codebuff，都只能靠工程师手动调工具定义，调提示词。但Anthropic不一样，它们能改模型本身的权重，让模型在真实的命令行环境里反复试错，试对了加分，试错了扣分，最后模型学会了怎么正确地调用读文件、写文件、grep、bash这些工具。
这个思路没毛病，问题出在“打分”这一步。
跑通测试≠写好代码，AI的分数游戏
强化学习的打分机制长这样：你让AI去修一个issue，它改完之后跑测试，测试通过得1分，不通过得0分。就这么粗暴。拿SWE-bench Multilingual这个数据集来说，里面每个任务都是从开源项目里扒出来的真实issue，比如Redis、jq、Django。模型拿到代码库和bug报告，自己写补丁，然后在一个沙盒里跑测试——必须把原来能跑的测试继续跑通（PASS_TO_PASS），还得把新加的测试也跑通（FAIL_TO_PASS），这俩条件都满足才算过关。
我随便拎一个例子给你看。fastlane这个Ruby项目里有个issue，zip命令里对两个可选参数直接调用了.empty?方法，只要用户没传这俩参数，程序当场崩。人类的修复方案就两行代码，给那俩参数设个默认空数组。就这么简单。
模型呢？它只要能写出让测试通过的代码，不管代码写得再丑再恶心，一样得1分。它会不会在文件里埋三层try catch？会不会乱转类型让类型系统形同虚设？会不会复制粘贴重复代码导致后面改一个地方要动十个文件？这些事，当前所有基准测试都不扣分。
我下面贴两段真实代码你们感受一下。
第一段，它用try catch把JSON.parse包起来，捕获异常之后直接返回null，上层代码拿到null继续往下传，鬼知道最后在哪个犄角旮旯爆出个undefined is not an object。
第二段，它用as any强行绕过TypeScript的类型检查，等于把编译器给你发的护甲全扒光了。
你让AI跑基准测试，它给你得满分。你让AI维护一个正经项目，它给你把地基全掏空。这就是基准测试和真实世界的差距。测试反馈秒级返回，可维护性的代价是周级、月级甚至年级才能体现出来的。一个坏的架构决策，当时看起来毫发无伤，三个月后某个新人打开那个文件想改一行代码，发现改不了，然后他加了个workaround，workaround又引发了另一个bug，bug修了又引入新bug。这个过程没法回溯，没法归因，没法反向传播到当初那个AI写下的第一行烂代码。
新测试在努力，但远水不解近渴
当然有很多聪明人在想办法解决这个问题。SWE-Marathon搞了四百个小时的大任务，比如“把整个Excel的所有功能克隆一遍”，而且它的奖励通道是复合的，不是简单的零和一。DeepSWE专门挑那些真实世界没人实现过的超大任务，确保训练集里绝对没有答案，解决数据污染问题。Cognition公司的Frontier Code则玩了个更花的——它让模型写测试，然后检验这些测试在原始代码上会不会失败，如果会失败说明测试是真的，这叫变异测试。他们还拿一个裁判模型来给代码diff打分，看代码质量合不合格。
这些方向都对，但你说它们能彻底解决可维护性问题吗？我持保留态度。你想啊，如果一个模型能准确地判断代码好坏，它为什么不一上来就写好代码呢？判断质量和生成质量本质上是一个能力。RL需要的是又快又可靠的奖励信号，可维护性目前就没有这样的信号源。
说白了，现在所有前沿基准测试都在慢吞吞地进步，但我不信它们能在短期内教会模型怎么写干净代码。你让我把整个代码库押在这些测试上，我睡不着觉。
灯重新打开，人回来坐镇
既然裁判只能是人，那就把灯重新打开，把代码审查那一步请回来。
但不是走回老路，让AI写一坨几千行的代码，然后人蹲在屏幕前痛苦地一行一行审。我们要做的，是把审查的压力往前推——在AI敲键盘之前，人和人先对齐。
怎么对齐？四个阶段：产品评审、系统架构、程序设计、纵向切片。
产品评审阶段，咱们别扯那些虚头巴脑的技术术语，先把问题定死——用户到底痛在哪儿，做出来之后怎么衡量成功。最好直接撸一个粗糙的HTML原型，三张图片比三千个字管用。如果连原型都定不下来，那就去做技术可行性研究，别在脑补中浪费时间。
系统架构阶段，画序列图，定API契约，把数据表结构敲死。别让AI从一张空白画布上瞎蒙。Mermaid图有时候会给你一种“我们已经对齐了”的错觉，但它能挡住很多模型乱发挥的臭毛病。
程序设计阶段，这个最容易被忽略但最重要。不是画架构图，是写伪代码——把关键函数的类型签名、方法签名、调用栈画出来。比如你要改一个控制流，用diff语法标清楚哪行是新增的，哪行是删掉的。把文件树的变化列出来，新增了哪些文件，修改了哪些文件。把这些“形状”提前摆好，AI就不会在实现的时候乱拐弯。
纵向切片这步最反直觉。AI喜欢水平切——先撸数据库迁移，再撸服务层，再撸API，最后撸前端。结果就是你在整个开发周期里都摸不到一个能跑的东西。正确做法是，先从中间切一刀，比如先写API契约并返回模拟数据，用curl测通；然后写前端消费模拟数据，在浏览器里迭代；然后才把服务层接进来；最后才加数据库。每走一步，你都摸到能跑的东西，每走一步你都审一两百行代码，发现方向偏了立刻掰回来。
这四步走完，AI动手写代码的时候，给你的PR质量完全不一样。一个干净的PR，你滑过每个文件都觉得顺畅，代码整洁，符合你之前讨论的所有决策。一个脏的PR，你每翻一页都想骂人。实际上AI一次性生成的PR，粗略估计有50%都需要返工。而50%返工意味着什么？意味着你花在审查上的时间，至少是写代码时间的等量甚至更多。
但如果你花三十分钟在这四步规划上，审查时间能从三个小时压缩到二十分钟。这笔账你自己算。
你现在的问题不是PR太多，而是烂PR太多
你觉得自己每天面对几百个PR忙不过来？错了。你的问题是几百个PR里大部分都是屎。好PR是享受，烂PR是折磨。
AI时代之前，烂PR已经够多了。但AI让烂PR的生产速度暴涨了一个数量级。你如果什么都不管，让AI闭眼生成闭眼合并，那你就是在给自己挖一个永远爬不出来的坑。
我的建议是：不要总想着一百倍加速。拥抱约束，承认模型有短板，用人的智慧去补那个短板。在约束里优化流程，你能做到的是两倍到三倍的稳定提速，而不是十倍的加速度然后撞墙。
写在最后
这篇东西从头到尾就一个核心：关灯工厂走不通，至少在现在的技术条件下走不通。
模型做题能力强，但维护能力弱。
基准测试测不出可维护性，RL也训不出来。
能当裁判的只有人。
所以把人放回流程里，把审查放回流程里，但别让审查变成酷刑。用产品评审、架构设计、程序设计和纵向切片，把审查压力前置，让AI在你划定的赛道里跑，别让它自己开路。
你别跟我说“等GPT-7出来就全解决了”。GPT-7出来之前你的代码库已经炸了。远水解不了近渴，你要的是现在就能用的策略。
模型擅长什么，不擅长什么，你得心里有数。拥抱这个约束，在两到三倍的提速区间里找平衡，别做梦百倍加速。
我过去这一年踩过的坑，你就不用再踩一遍了。
你代码库的屎山，不是AI写的，是你同意让AI闭眼写的。