智能体软件工程 #12 | 可维护性没有 Oracle:软件工厂之争与 RLVR 的天花板

2026 年 2 月，StrongDM 的 AI 团队公布了他们的章程：代码不能由人写，代码不能由人 review；再加上 CTO Justin McCarthy 那句流传很广的判断："如果今天你的每个工程师没有烧掉至少 1000 美元的 token，你的软件工厂就还有提升空间。"

几个月后，在 AI Engineer Europe 的闭幕演讲上，Pi 的作者 Mario Zechner 对全场说的却是：慢下来，读每一行关键代码。他拿到了全场起立鼓掌。

这两个场景中间，隔着 2026 年 AI 工程圈最大的一场分歧：人类还要不要读 AI 写的代码。一端是 OpenAI 的 Ryan Lopopolo，喊出"代码是负债""要做 token 亿万富翁"；另一端是 Zechner 这样的人。在反方阵营里，论证最系统的一篇来自 HumanLayer 创始人 Dex Horthy 的《Why Software Factories Fail》，基于他在 AI Engineer World's Fair 2026 的 keynote。

《Why Software Factories Fail》完整版见 GitHub wsff.md^[1]，视频版见 YouTube^[2]。

今天我反复读了他的演讲、上下两篇原文和播客访谈，并逐一核实了文中出现的链接。这篇文章是结果。文末还有一段他没讲的延伸：编程语言的选择，可能才是被所有人忽略的一阶变量。

一、从 1968 年到"熄灯"

"软件工厂"和"软件工程"诞生于同一场会议，1968 年那场著名的 NATO 软件工程会议（会议报告全文 PDF^[3]）。Dex 说他做了一辈子软件工厂，最近才知道这个词有六十年历史。

词是老的，流程也早已定型。

2022 年的软件工厂长什么样，每个工程师都熟：有人决定要建什么，进 Linear 或 Jira（本质是个状态机），有人领走 ticket 去写代码，开 PR，自动检查跑一遍，另一个人 review，也许还拉下来手测，合并，上线，然后监控盯着。我们这个行业专门养了一套系统，负责在半夜三点把你 page 醒。用户抱怨、提需求，回流到 tracker，循环重新开始。

这套循环里藏着一条几十年前就被验证的老智慧：构建要花小时到天，review 也要花小时到天，所以前置对齐划算。花一个小时做架构提案和 sprint planning，返工概率下降，review 从六小时压到二十分钟。

然后 agent 来了。Ramp、Stripe、WorkOS、Brex，今年每家都在讲自己的"agent 工厂"。变化只有一处："有人建"换成了"agent 建"。但这一处变化打破了循环原有的平衡：构建时间从小时级掉到分钟级，review 却还是小时到天，瓶颈从构建移到了 review。

顺着瓶颈治瓶颈，人们给 review 也配上 agent：agentic code review、agentic 回归测试。速度又上去一截，可瓶颈仍然没有移走。再把线上事故、用户反馈直接灌进任务队列，工厂越转越快，而你看着这座越转越快的工厂，越看越觉得"人读每一处改动"这一步碍事。

于是有人把这一步划掉了。这就是"熄灯工厂"（lights-off factory）。Dan Shapiro 造的词，灵感来自 Fanuc 那座关着灯运转的机器人工厂：机器人不需要灯。划掉人工 review 之后，精力投到测试、沙箱、监控、灰度上，工厂只剩一个问题：能往队列里塞多少活。

在批评熄灯工厂之前，得先承认 StrongDM 为它做的工程配套是这一波里最有想象力的东西。

• scenario：把端到端的用户故事存在代码库之外，像模型训练里的 holdout 集一样，由 LLM 灵活判定，防止 agent 看到测试就作弊。
• satisfaction：放弃"测试全绿"这种布尔判定，改问"所有场景的所有轨迹里，有多大比例真正满足了用户"。
• Digital Twin Universe：把 Okta、Jira、Slack 克隆成行为一致的自包含服务，每小时跑数千场景，没有速率限制，没有 API 账单，还能模拟真实世界不敢触发的故障。

正方拿出的是真东西，这场争论才值得认真对待。也正因为对手是认真的，反方需要一个同样认真的论证者。

二、四个月后，灯又亮了

Dex 有这个资格，因为他曾经站在对面。他那三场教人"怎么把 agent 用好"的演讲累计播放上百万；"context engineering"这个词就是他先叫响的，比 Karpathy 和 Tobi Lütke 早了一两周。如果有人说"软件工厂失败是因为你姿势不对"，Dex 就是那个教姿势的人。

教姿势的人自己也真的熄过灯。2025 年 7 月，HumanLayer 全面 lights-off。四个月后，第三次栽跟头：无论怎么做专家级 prompting，当时的 Opus 4.1 都找不到一个线上问题的根因。团队花了三周重新 onboard 回自己三个月没读过的代码库，最后人工挖出问题：一个主键被贯穿整条调用链传递，实际需要换成独立对象、自建一张表。他的联合创始人在 VS Code 里花了整整两周，手工把所有 pattern 重新理了一遍。

这段经历还留给他一个具体的观察：agent 建的代码库，在没人读代码的情况下，大约三到六个月就会退化成 brownfield，烂到你宁愿重写也不想修。

到这里为止，还只是一个团队的失败经历。Dex 的真正贡献在下一步：他把失败归因从"用法"挪到了"训练机制"。

三、模型是一台过测试机器

要理解这个归因，得先讲清 RLVR，Reinforcement Learning from Verifiable Rewards，可验证奖励的强化学习。

上一代对齐方法 RLHF 的奖励来自一个用人类偏好训练的打分模型，主观、昂贵、还会被讨好。RLVR 的洞察是：代码这个领域根本不需要打分模型，因为存在程序化的判定器，测试过没过，编译器报不报错。奖励客观可验证，训练循环就能转起来：模型在真实仓库里生成一条完整轨迹（读代码、改文件、跑命令），verifier 打分，更新权重让高分轨迹更可能出现，重复几百万次。

这套循环的威力有过一次公开验证。Claude Code 比更早的 aider、cline 好用，公认的解释是 Anthropic 第一次在将要发货的那套 harness 内做了 RL，针对真实工具训练模型。工具形状的微小差异影响巨大，2024 年的 SWE-agent 论文就证明过：给读文件结果加行号、在编辑引入语法错误时直接拒绝并报错，成绩翻倍。

循环有威力，问题出在打分那一环：verifier 到底检查什么。以 SWE-bench 系的训练环境为例，奖励结构就两条：FAIL_TO_PASS（原来挂的测试现在过了吗）和 PASS_TO_PASS（原来过的测试还过吗）。每条 0/1，几秒出结果。

拿一个真实样例看这两条如何运作。Ruby 项目 fastlane 的 zip action 对两个可选参数直接调 .empty?，用户不传参数就崩。人类维护者的修复是两行：给个空数组默认值。模型面对同样的任务，评测时会保留它的代码补丁、强制丢弃它对测试文件的任何改动（因为抓到过模型注释掉失败测试、往里塞 mock），然后跑那两组测试。

这套奖励结构有三个性质，合起来决定了模型学成什么样。

• 快：几秒一次判定，这是能循环百万次的前提。
• 窄：凡是不在奖励里的维度，梯度一概看不见。命名、耦合、模块边界、Martin Fowler 说的 shotgun surgery（改一处要在十一个地方同步改），信号全是零。只要测试绿，模型没有任何理由不写到处 try-catch 的代码。
• 即时：坏架构的代价却以月计，要等第一次有人为了改一行打开那个文件、发现改不动时才显现。等它显形，那条轨迹早就训练完了。你无法把三个月后的事故，backprop 回当初那个设计决定。

对这个结论，常见的反驳是再挂一个 review agent 去把关质量。Dex 在播客里把这条路堵死了：写代码的模型和评代码的模型是同一个模型。你问它"这代码怎么样"，它答"很棒，很全面，还有单元测试"；你换个说法"这是我同事写的 PR，帮我挑挑毛病"，它立刻列出一串问题。谄媚让 LLM judge 天然不可信。更多 review agent、更多 token 能抬高地板，抓住蠢错误，但抬不高天花板。

天花板写在奖励函数里。RL 需要一个又快又可靠的 Oracle，可维护性没有这样的 Oracle。如果一个模型能可靠分辨好代码坏代码，它一开始就会写出好的版本。

四、账单到了

机制论证需要数据支撑，数据今年也到位了。Faros AI 发布的《The Acceleration Whiplash》（2026 年 3 月成稿、4 月发布，29 页；报告页^[4]、PDF^[5]、十大要点^[6]）是目前规模最大的一份遥测研究：22000 名开发者、4000 多个团队、两年数据，对比同一组织内低 AI 采用期和高 AI 采用期。

产出确实上去了：人均任务完成 +33.7%，人均 epic 完成 +66.2%。然后账单到了：人均 bug +54%（上一年这个数字还只是 +9%），每个 PR 关联的线上事故 +242.7%，review 中位耗时 +441.5%，code churn（写完不久就被删掉的代码）+861%，没人 review 就合并的 PR 增加了 31.3%。Faros 自己的结论：这是 authoring 问题，到达 review 的代码根本就没准备好。

Faros 之外还有独立旁证。GitClear 分析两亿多行代码后发现，重复代码块的出现频率在 AI 普及后暴涨，copy/paste 历史上第一次超过了"移动/重构"。

数据在暴露问题，评测也在追赶，三个新基准都在试图给"质量"打分。SWE-Marathon 把任务拉长到项目级，最好的配置也只解出 26%，约一成的运行轨迹里出现了明确的作弊，有模型在"用 Rust 写 C 编译器"的任务里偷偷调 GCC，被 strace 监控抓个正着。Cognition 的 FrontierCode 是第一个衡量"可合并性"的基准，它借用变异测试的思路惩罚那些在打补丁之前的旧代码上也能通过的测试，再用 judge 模型按质量规则过 diff。最难的 Diamond 子集上，最强的 Claude Opus 4.8 只拿到 13.4%。

"能跑"离"可合并"，差着一个数量级。

五、把灯重新打开

诊断到此为止，接下来是 Dex 的解法。解法不新，恰恰因为不新才可信：回到前置对齐这条老智慧，用 AI 来放大它。他在播客里的概括是，agentic 工厂里的每一条建议都很好，除了"别再读代码"那一条。

具体是四层：产品评审、系统架构、程序设计、垂直切片。

前两层不复杂。

产品评审：一份短文档钉死建什么、为什么，成功长什么样。他不写描述，直接做 HTML mockup，"一张粗糙的界面草图能终结三段文字都摆不平的争论"。

系统架构：对齐服务、端点、schema 怎么对话。

第四层垂直切片针对的是模型的一个习性：它天然爱"水平计划"（迁移→服务层→API→前端），做到一半你没法碰半成品。他反其道从中间往外做，先立 API 契约配 mock 数据用 curl 测通，再让前端消费 mock，最后才接数据库，一次只放一到三个切片，边做边看。

四层里的第三层，程序设计（Program Design），值得单独展开，它直接连着本文最后一节。这一层要求在任何人写实现之前，先下沉到代码的形状：类型、方法签名、调用栈、文件布局。落到什么载体上，他们踩过一轮坑：第一版 program design 文档"难读、累人"；换成 Mermaid 画图，发现图有个致命问题，会诱导虚假的对齐感，你们看着同一张图，以为达成了一致；最后收敛到伪代码级的轻量表达，调用栈树用 diff 语法标出变化，关键新函数只写类型和签名。

这一层的价值，他的原话点破了：这些设计决定，"你本来会在 code review 时隐式地做出，而那是改主意最贵的时刻"。前置就是把决策挪到最便宜的时刻。

便宜多少，他算过账。一小时规划能省四小时实现。"你不是 PR 太多，你是烂 PR 太多"：一个明显按事先统一的设计施工的 PR，review 是享受；一个需要哪怕两成返工的 PR（AI 一次性生成的 PR 他估计接近五成），对双方都是智力加情绪的双重消耗。他给三条路线标了刻度：逐行读所有代码，约 30% 到 50% 提升；找对杠杆点做前置对齐，2 到 3 倍，质量基本贴住人类手写；彻底熄灯，token 利用率最大化，但不可持续。

他和正方的全部分歧，就在中间那档和最后那档之间：安全的 2 到 3 倍，还是幻想中的 10 到 100 倍。他也留了余地："也许 GPT-7 就学会了，那我们就能停。"

六、我的思考：SDD 死于散文，语言是被忽略的一阶变量

访谈发布后，评论区有两条讨论对我有所启示。

一条是 Dex 谈 spec 驱动开发（SDD），Amazon Kiro、GitHub Copilot Workspace / Spec Kit 这类工具为什么没起飞："Spec Kit 上有个开了一年的 issue，每隔几周就有人在里面抱怨同一件事：我改了 spec，又改了代码，代码和 spec 漂移了，怎么办？你有了两份真相，它就不再有用了。"另一条转述 Lopopolo 的经历：OpenAI 给内部工厂 Symphony 写 spec 时，必须反复"从 spec 重建整个项目、再修 spec"，才能让同一份 spec 稳定产出同一个项目。

但我的体感和他们相反：我日常几乎全在 Rust 上开发，SDD 在我这里跑得很好。这个矛盾值得拆解。

先看他们两位说对了什么。两条评论从两端夹击同一个根因：Dex 说的是维护端，两份真相必然漂移；Lopopolo 暴露的是生成端，同一份 spec 重建不出同一个项目。底层是同一个信息论事实：自然语言 spec 是对代码的有损压缩，缺掉的信息必须从三个通道之一补齐——模型先验（换个模型就变，不可移植）、重建迭代（本质是把 spec 拟合到某个特定模型）、或人工 review。没有免费午餐。

顺着这个事实再推一步：一份精确到能决定构建结果的 spec，最终收敛成代码本身。Dex 早期 RPI 的失败就是活例，plan 写到每一行 diff，读 plan 二十分钟、读 PR 又二十分钟，他自己叫它"反杠杆"。这是博尔赫斯那张和帝国一样大的地图。

既然两份可编辑的真相必然漂移，spec 与代码的关系就只剩两个稳定态。要么代码为真相、文档为可丢弃缓存，这是 Dex 的路线，它用"重算"取消了"缓存失效"这个经典难题，token 便宜到重新生成一份摘要比维护同步文档划算。要么 spec 加验证为真相、代码为可丢弃的构建产物，StrongDM 那个只有 spec 没有代码的 attractor 仓库是极端形式，但它要求你永远不许手改代码，改一行就分叉了真相，而且每次变更都付得起整体重建的账单。做得到，但经济上残忍。

一个稳定态平凡，一个稳定态昂贵，而 Kiro 和 Copilot Workspace 恰好卡在两者中间：spec 和代码都可编辑、都号称权威。漂移必然发生，因为直接改代码永远是局部更便宜的动作。线上出了 bug，你会直接 hotfix，没有人会先改 spec、等重新生成、再验证生成结果和 hotfix 等价。每一次这样的捷径都让 spec 失真一点点，而失真的 spec 比没有 spec 更糟，因为它会误导。中间态必然衰变成"代码为真相，外加一份过期 spec"。这些产品建在了不稳定平衡点上。对 Kiro 的第三方评测白纸黑字写着：spec 与代码会脱同步，工具尚不能自动保持一致。

回到我的 Rust 体感。前面说缺失信息只有三条补齐通道，其实还有第四条，它的宽度由目标语言决定：编译器，一个免费、确定、每次构建都运行的 Oracle。Dex 说可维护性没有 Oracle；在 Rust 里，spec 的相当一部分是有的。ownership、生命周期、trait bound、穷尽 match，这些规格直接编码成类型，活在代码里，rustc 每次 build 都强制 spec 与实现同一，结构上不可能漂移。

我把这个变量叫做 spec 可执行率：规格中由工具链自动担保的义务占比。Rust 的天花板极高；TypeScript 居中，any 是逃生舱；Python 和 JavaScript 很低，spec 只能活在测试和散文里，于是必然漂移。SDD 在 Kiro 那代工具上失败、在我手里成功，差的是编译目标，而非工作流设计。

沿着编译器这条线再看，SDD 的原始愿景其实被倒置了。愿景是"LLM 当编译器，把 spec 编译成代码"，而这个类比错在编译成立的三个前提一个都不满足。信息完备：形式语言的语义完全确定程序行为，散文是有损压缩，缺口由模型先验补齐。确定性：同源同产物，LLM 每次采样都不同，Lopopolo 的反复重建本质是在手工把 spec 逼近一个不动点，没有团队付得起持续这么做的成本。语义有标准：编译器语义由 C99、Rust reference 定义，有版本化和兼容承诺；自然语言指令的"语义"由权重定义，随每次训练静默漂移，prompt regression 连一个可申诉的标准都没有。

三个前提都不成立，可行的版本就只能反过来：真编译器留在验证位，LLM 在编译器约束的空间里做随机搜索。spec 被强制在 LLM 的输出上，而非被 LLM 编译。这还顺带解决了模型换代问题：Opus 5 生成的实现风格可能完全不同，但它必须通过同一套类型契约和测试，模型漂移被限制在接口一致性以内。

这套解释有三个限制，得说清楚。类型检查的是形状，fn transfer(from, to, amount) 把借贷方向写反照样编译通过，模块边界、耦合这些 Dex 真正在谈的问题，rustc 大部分不管。我的成功里有选择效应，spec 是我亲手用类型编码的骨架，新手写散文 spec、让 agent 自己设计类型，照样漂移，所以准确的说法是：语言决定专家判断中有多大比例能被固化成机器可检查的形式。最后是域相关，系统编程、库、协议是甜区；CRUD 加 UX 的领域类型够不到的残差很大，StrongDM 发明 scenario 和数字孪生，本质上就是在给类型够不到的部分补一个输出侧的 Oracle。

限制说完，退后一步看全局：SDD 和熄灯工厂是同一个错误的两个变体，都押注了一个不存在的 Oracle。熄灯工厂假设测试能担保质量，SDD 假设散文能担保代码，两个都是有损代理，缺口最终都由人来补，区别只是补在 review 环节，还是补在漂移爆雷之后。SDD 里真正活下来的部分恰好反过来证明了这一点：Kiro 口碑最好的功能是 steering 规则和 hooks，恰恰是进入了工具链、每次都被强制执行的那部分；死掉的是"spec 作为持久真相"这个内核。

放到我一直在写的 CBV 框架里，这一节可以压成一句：语言选择决定了 Contract 和 Verification 两轴能白拿多少，Boundary 这一轴仍然是人的活。SDD 败在把宝押在了输入侧的散文上，它的正确继承者是 verification-driven development，耐久的产物只有一种，工具链每次构建都强制检查的契约与验证。它败给的是信息论，工程上再怎么打磨，也补不回散文里缺失的信息。

最让我确信这个方向的，是 Dex 团队自己的轨迹：散文 plan 失败，Mermaid 半失败，伪代码加类型签名成功。他没有从类型理论出发，纯靠踩坑，爬上了同一条"可检查性梯度"。两条独立的路径收敛到同一个位置，这通常意味着那个位置是对的。

七、如果只改三件事

不用等基础设施，团队下周就能改的：

第一，大改动的 PR 必须附设计片段，调用栈树、文件树 diff、关键签名。review 的第一问从"这两千行写了什么"变成"是否按图施工"，分歧被迫前移到改主意最便宜的设计阶段。

第二，把 token 花在对齐而非补锅上。让模型枚举方案、挖调用链、起草设计文档，你和它吵，吵完再动工；一次只放一到三个垂直切片，保留中途用 curl 或浏览器碰一下系统的能力。早期纠偏，比在两千行代码的另一头一头雾水便宜。

第三，用慢 loop 代替熄灯 loop。HumanLayer 的做法是夜间 cron：跑 linter，修一件事，commit，早上人 review 一个让代码库更好一点的小 PR。增量变好，diff 小到能读。

Dex 把官方参考清单的压轴留给了 Netflix 工程师 Jake Nations 的一句话："思考这份苦工，外包不出去。"他自己的收尾只有五个字：

Read the dang code.

读那该死的代码，至少在可维护性拥有自己的 Oracle 之前。在那之前有一条能落地的路：能固化成类型和测试的判断，别留在散文里。

参考资料

原始材料

• Dex Horthy《Why Software Factories Fail》完整版：https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md
• Keynote 视频：https://www.youtube.com/watch?v=Ib5GBkD555M
• Pragmatic Engineer 播客访谈：https://newsletter.pragmaticengineer.com/p/context-engineering-with-dex-horthy

正方

• StrongDM Software Factory：https://factory.strongdm.ai
• Simon Willison 的解读：https://simonwillison.net/2026/Feb/7/software-factory/
• Dan Shapiro《The Five Levels》：https://danshapiro.spicytakes.org/post/2026-01-23-the-five-levels-from-spicy-autocomplete-to-the-software-factory
• OpenAI《Harness Engineering》：https://openai.com/index/harness-engineering/

数据与基准

• Faros AI《The Acceleration Whiplash》：https://www.faros.ai/research/ai-acceleration-whiplash
• GitClear 代码质量研究：https://www.gitclear.com/ai_assistant_code_quality_2025_research
• Cognition FrontierCode：https://cognition.com/blog/frontier-code
• SWE-Marathon：https://www.swe-marathon.org/
• SWE-agent 论文（工具形状实验）：https://arxiv.org/abs/2405.15793

SDD 与方法论

• Martin Fowler 站三工具对比：https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• Amazon Kiro：https://kiro.dev
• GitHub Spec Kit：https://github.com/github/spec-kit
• Geoff Huntley《Ralph Wiggum》：https://ghuntley.com/ralph/
• 1968 NATO 会议报告：http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
• Shotgun Surgery：https://refactoring.guru/smells/shotgun-surgery