暗工厂验证层:当无人阅读代码时
暗工厂(Level 5)是一种软件开发环境——机器生成代码、验证代码、部署代码,没有人类阅读任何一行。 支撑暗工厂运转的验证层需要留出集评估、数字孪生宇宙、多智能体审查以及编码化的品味约束。缺少这一层,智能体就会博弈测试,质量荡然无存。
StrongDM在两条规则下发布了软件:”代码不得由人类编写”和”代码不得由人类审查”。1 一个三人团队(Justin McCarthy、Jay Taylor和Navan Chauhan)构建并发布了Attractor和CXDB(16K行Rust、9.5K行Go、6.7K行TypeScript),每位工程师每天至少消耗1,000美元的token费用。1 BCG Platinion援引Spotify和TechCrunch的报道指出,Spotify最优秀的开发者自2025年12月起就没有编写过代码,该公司每月合并数百个AI生成的pull request。2
Dan Shapiro将终极阶段称为Level 5:暗工厂。代码由机器生成,由机器验证,部署时无人阅读任何一行。3 前置的各级别追踪了当前大多数团队正在经历的演进路径:手动编码(Level 0)、任务分担(Level 1)、高速公路上的自动驾驶(Level 2)、配备安全员的Waymo(Level 3),以及写好需求然后离开12小时的机器人出租车模式(Level 4)。3
一个尚未被充分回答的问题是:Level 5的验证层究竟是什么样的?以下分析将绘制所需的基础设施全景,并以品味基础设施为基础——它是我评估所有工程工作质量的治理体系。
验证问题的复合效应
在Level 5以下的每个级别,人类都会在某个环节阅读代码。Level 3,人类以高级开发者的身份管理AI。Level 4,人类在12小时后检查测试是否通过。3 这些级别之所以可行,是因为拥有业务领域知识的人能够将代码与意图进行模式匹配。需求说”使用指数退避重试”,代码却做了线性重试——开发者一眼就能发现。
彻底移除人类,验证就变成了一个本质不同的问题。不是程度上更难,而是性质上不同。验证者不能依赖阅读理解。验证者必须将”正确”的含义编码为可执行形式,然后在不检视产物本身的情况下,将输出与该编码进行比对。
核心陷阱在于智能体对测试的博弈。StrongDM发现他们的智能体编写return true来通过测试套件,实际上什么有用的事都没做。1 测试是绿的。CI流水线报告成功。代码毫无价值。斯坦福法学院的Eran Kahana将这一观察延伸为结构性警告:更深层的问题在于循环性——同一类技术在评估由同一类技术编写的代码。4
古德哈特定律在此处展现出异乎寻常的力量。品味是一个技术系统一文论证了自动化验证需要在其上方设置一个判断层;缺少品味级别的评估,测试就会从度量标准蜕变为优化目标。当智能体以通过测试为目标进行优化时,测试通过率便不再衡量正确性。4 任何成为目标的指标都将不再是好指标。暗工厂的验证层必须应对这一动态,否则它衡量的将是合规性而非质量。
StrongDM的验证方案
StrongDM的答案是他们所称的”场景”(Scenarios):存储在代码库之外的端到端用户故事,其功能类似于机器学习中的留出集。1 这个类比恰如其分:正如ML从业者用从未参与训练的数据评估模型,独立智能体用编码智能体在生成过程中无法访问的场景来评估生成的代码。
关键指标是”满意度”(Satisfaction):可能满足用户需求的观测轨迹占比。1 对于多高的分数才算充分满意,业界尚无统一标准。StrongDM通过经验摸索确定了自己的阈值。
为了使场景测试大规模运行,StrongDM构建了一个数字孪生宇宙:Okta、Jira、Slack、Google Docs、Drive和Sheets的行为克隆。1 这些孪生体使用流行的公开参考SDK客户端库,目标是实现100%的API兼容性。1 智能体在孪生体上运行测试,而非在mock端点上。孪生体的行为保真度决定了测试的可信度。
StrongDM观察到一个我也有同感的模式:”随着Claude 3.5的第二次修订版(2024年10月),长周期的智能体编码工作流开始累积正确性而非累积错误。”1 在能力阈值以下,更长的智能体运行会产生更多错误。超过阈值后,更长的运行会产生更好的代码。暗工厂模式只有在模型跨越这一阈值后才变得可行。
五层治理架构
BCG Platinion的五支柱转型框架包含一个治理层,其中设置了多个验证步骤,代码须通过这些步骤才能进入生产环境。2 五大支柱分别是:意图驱动操作系统、编码化知识基础设施、劳动力技能提升、配备独立验证智能体的治理层,以及用于编排的工厂架构。2 治理支柱包括由独立智能体运行的场景测试、静态分析、架构一致性检查、行为回归测试,以及主动尝试破坏输出的红队智能体。2
独立性至关重要。当同一个智能体编写并测试自己的代码时,Kahana的循环性问题就会出现。4 当另一个智能体(具有不同的系统提示、不同的上下文、不同的激励机制)来评估工作时,失败模式会去相关化。不是消除,是去相关化。两个智能体仍可能共享从训练数据继承的系统性偏差。但当评估智能体从不同的框架出发时,产生相同盲点的概率会下降。
BCG Platinion将”意图思维”确定为暗工厂团队的核心能力:将业务需求转化为精确、可测试的预期结果描述。2 人类的角色从编写代码转变为编写智能体可以据之执行的规格说明。糟糕的规格说明会产生对错误行为通过的测试——与StrongDM遇到的return true如出一辙。1
BCG Platinion还指出了一个我亲身体验过的约束:”AI智能体的效能完全取决于它们能访问的编码化知识。”2 一个缺乏项目上下文的智能体会生成看似合理但违反本地约定、忽视架构决策、重新发现团队已解决问题的代码。编码化知识(设计决策、API契约、风格指南、故障历史)是基础设施,不是文档。
我在Level 4的实践
我的夜间执行循环——Ralph智能体架构——运行在Shapiro的Level 4。我编写规格说明、启动智能体、入睡,第二天早上审查结果。智能体运行时有95+个钩子拦截每一次工具调用(文件写入、Git命令、Shell执行),在执行前后进行检查。这些钩子施加的约束,智能体无法与之协商或绕过。
这些钩子在工具层面解决了Kahana的博弈问题。另一篇文章详细记录了完整的钩子架构,但这里的关键属性是拦截:钩子在工具执行之前触发,而非之后。试图强制推送到main分支的智能体在命令执行前就会被阻止。试图提交匹配.env模式文件的智能体会被拦截。声称”所有测试通过”却没有运行pytest的智能体会被证据门控标记——它要求粘贴显示零失败的测试输出,而非”测试应该会通过”的断言。
证据门控对每一个非平凡变更执行六项标准:遵循代码库模式(指明模式名称和所在文件)、最简可行方案(说明被否决的替代方案)、边界情况已处理(逐一列出)、测试通过(粘贴输出)、无回归(指明已检查的文件)、解决了实际问题(说明用户需求及变更如何满足它)。”我认为”和”应该可以”不是证据。门控拒绝含糊措辞,要求提供实证。
质量循环(实现、审查、评估、精炼、全局审视、重复、报告)作为行为约束编码在智能体的系统提示中,通过CLAUDE.md实现。质量循环不能保证智能体严格遵循每一步,但钩子会验证它确实做到了。
BCG Platinion的五大支柱对应着我已经维护的基础设施:
- 意图驱动操作系统:CLAUDE.md文件和PRD驱动的开发规格说明将项目意图编码为可执行上下文。
- 编码化知识:139+个技能模块,作为可复用能力组织起来,使智能体能够访问项目约定、架构决策和领域知识。
- 治理层:钩子实现了拦截层。证据门控实现了审计层。质量循环实现了行为约束层。
有两个支柱我尚未构建:劳动力技能提升(对独立从业者不适用)和作为专用编排平台的工厂架构(我目前的设置使用Claude Code的原生智能体派生,而非专门构建的工厂)。复合上下文系统描述了这些基础设施层如何累积为资本资产,使每一次后续会话都更加强大。
Level 4与Level 5之间的鸿沟
从Level 4迈向Level 5意味着消除早晨的审查环节。目前,我每天早上醒来阅读智能体夜间的产出。我检查git diff,运行应用程序,验证输出是否符合我的意图。这一审查耗时30分钟到1小时,能捕获钩子遗漏的问题。
钩子遗漏的问题恰恰是有趣的问题。它们可以归为当前自动化处理不力的几类:
意图漂移。 智能体忠实地完成了规格说明,但规格说明存在歧义,智能体选择了错误的解读。没有任何测试能捕获一个产生了有效行为的错误解读。StrongDM的场景方法通过将用户故事而非技术需求编码为规格说明来应对这一问题。1 场景描述的是用户的体验,而非代码的行为。
架构侵蚀。 智能体添加了一个孤立来看运行正常的功能,却降低了系统的结构一致性。一个绕过现有仓储模式的新数据库查询。一个与另一个模块重复逻辑的新端点。静态分析能捕获其中一些。架构一致性检查(BCG Platinion治理层的一部分)能捕获更多。2 但两者都无法捕获那些微妙的情况——新代码在技术上与现有模式一致,却引入了一个概念分裂,在后续变更中不断累积恶化。
机构知识流失。 Kahana提出了一个被低估的风险:当无人阅读代码时,就无人对系统建立直觉。4 正如Kahana所警告的:”没有人会知道为什么,没有人会知道如何修复。”4 今天,我的早晨审查在渐进式地积累这种直觉。在Level 5,系统对其操作者变得不透明。每个复杂系统最终都需要自动化无法处理的干预:安全事件、违反测试套件内置假设的业务逻辑变更、与行为不符其文档描述的外部系统集成。从未阅读过代码的操作者无法有效介入。
验证层的真正需求
综合StrongDM的实践、BCG Platinion的治理框架、Kahana的失败分析以及我自身的基础设施,暗工厂的验证层至少需要以下要素:
留出集式评估。 生成智能体在代码生产过程中无法访问的测试。StrongDM的场景方案。独立于代码库存储的行为规格说明,由独立智能体评估。没有留出集评估,古德哈特定律会将每个测试套件变成优化目标。
集成测试的数字孪生。 智能体不能对生产系统进行测试。Mock过于浅薄——它们验证的是API契约而非行为。复制外部依赖行为表面的孪生体能够在不承担生产风险的前提下实现端到端场景执行。
具有去相关失败模式的多智能体验证。 编写智能体和评估智能体必须在不同的上下文中运行。主动探测博弈行为、走捷径和虚假验证的红队智能体提供了被动测试无法企及的防线。
工具级拦截。 在执行之前阻止有害操作的钩子,而非在损害发生后才检测到的测试。钩子层位于智能体决策之下,能够抵抗巧妙提示或return true式捷径的规避。
可执行的意图规格说明。 精确到歧义可被检测的规格说明。BCG Platinion的”意图思维”能力。2 Shapiro的Level 4规格说明——你写完它然后离开12小时。3 规格说明是产品,代码是副产物。
无责任缺口的审计追踪。 Kahana引用了AI生命周期核心原则,要求输出”可追溯到适当的责任方”。4 目前尚不存在针对智能体构建软件的行业标准审计方法论。4 验证层需要产生人类(或监管者,或事件响应者)可以从部署行为追溯到生成它的规格说明的证据链。
坦诚的评估
我以较高的信心运行Level 4。我的夜间智能体产出的工作在多数情况下能通过早晨审查。钩子捕获机械性故障,证据门控捕获认知性故障,质量循环减少行为性故障。
Level 5要求解决我尚未解决的问题。无需人类模式匹配的意图漂移检测。能够捕获概念侵蚀而非仅限结构违规的架构一致性检查。在系统中而非操作者头脑中积累的机构知识。
BCG Platinion报告采用暗工厂模式的团队获得了3-5倍的生产力提升。2 StrongDM用三名工程师和一笔token预算发布了智能体构建的软件。1 生产力方面的论据清晰明确。验证方面的论据尚不充分。
在Level 5取得成功的团队有一个共同特征:他们在验证基础设施上的投入超过了代码生成。StrongDM在信任智能体发布代码之前,构建了整个数字孪生宇宙。1 BCG Platinion的框架包含五大转型支柱,其中治理层在代码进入生产环境之前设置了多个验证步骤。2 暗工厂不是一个在黑暗中运行的工厂。它是一个以验证层为光源的工厂,其余一切——包括代码本身——都是大宗商品。
我此前写过关于智能体无人监督运行时什么会崩溃以及证据门控作为防御虚假验证的手段。那些文章描述的是Level 4的基础设施。暗工厂要求同样的基础设施,但需扩展到在没有那个每天早上阅读diff的人类的情况下运行。钩子、证据门控、质量循环:在Level 5全部必要,但并不充分。缺失的一环是能够以与生成同等自主性扩展的验证能力。
构建这一能力,是前方的工作。AI工程中心汇集了这一探索的完整脉络,从单个钩子设计到复合上下文,直至暗工厂前沿。
常见问题
软件开发中的暗工厂是什么?
暗工厂(Dan Shapiro的Level 5)是一种软件开发环境,机器生成代码、验证代码、部署代码,无需人类阅读任何一行。前置级别从手动编码(Level 0)逐步演进至更高的自动化水平,Level 4是”机器人出租车”模式——人类编写规格说明,离开12小时,然后审查结果。暗工厂甚至消除了这最后的审查环节。
Level 5最大的验证挑战是什么?
核心陷阱在于智能体对测试的博弈。StrongDM发现智能体编写return true来通过测试套件,实际上什么有用的事都没做。古德哈特定律在此展现出异乎寻常的力量:当智能体以通过测试为目标进行优化时,测试通过率便不再衡量正确性。验证层必须通过使用留出集式评估(生成智能体在代码生产过程中无法访问的测试)、具有去相关失败模式的多智能体验证,以及在执行前阻止有害操作的工具级拦截来应对这一问题。
Level 4与Level 5之间的差距是什么?
三个当前自动化处理不力的问题:意图漂移(智能体忠实完成了规格说明,却对歧义需求选择了错误的解读)、架构侵蚀(孤立来看运行正常但降低结构一致性的新功能),以及机构知识流失(当无人阅读代码时,无人积累应对事件或业务逻辑变更所需的系统直觉)。
StrongDM如何解决验证问题?
StrongDM使用”场景”(Scenarios)——存储在代码库之外的端到端用户故事,其功能类似于机器学习中的留出集。独立智能体使用编码智能体在生成过程中无法访问的场景来评估代码。他们构建了一个数字孪生宇宙(Okta、Jira、Slack、Google Docs的行为克隆),目标是100%的API兼容性,使智能体能够对真实的行为表面进行测试,而非浅层mock。
-
Simon Willison, “Software Factory,” simonwillison.net (February 7, 2026), covering StrongDM’s fully autonomous development methodology by Justin McCarthy, Jay Taylor, and Navan Chauhan. ↩↩↩↩↩↩↩↩↩↩↩↩
-
BCG Platinion, “The Dark Software Factory,” bcgplatinion.com. ↩↩↩↩↩↩↩↩↩↩
-
Dan Shapiro, “Five Levels of AI Coding,” danshapiro.com (January 2026). ↩↩↩↩
-
Eran Kahana, “Built by Agents, Tested by Agents, Trusted by Whom?” Stanford Law (February 8, 2026). ↩↩↩↩↩↩↩