暗黑工厂的验证层

StrongDM在两条规则下发布软件：”代码不得由人类编写”以及”代码不得由人类审查”。¹ 三人团队——Justin McCarthy、Jay Taylor和Navan Chauhan——构建并发布了Attractor和CXDB（16K行Rust、9.5K行Go、6.7K行TypeScript），每位工程师每天的token最低开销为1,000美元。¹ BCG Platinion援引Spotify和TechCrunch的报道指出，Spotify最优秀的开发者自2025年12月起便不再编写代码，该公司每月合并数百个AI生成的拉取请求。²

Dan Shapiro将终极阶段称为Level 5：暗黑工厂。代码由机器生成，由机器验证，部署过程中无人阅读哪怕一行代码。³ 此前的各级别追踪了大多数团队当前所处的演进路径——从手动编码（Level 0），经由任务分担（Level 1）、高速公路自动驾驶（Level 2）、配备安全员的Waymo（Level 3），到编写规格说明后离开12小时的无人出租车模式（Level 4）。³

一个尚无人给出满意答案的问题是：Level 5的验证层究竟是什么样的？

验证问题的复合效应

在Level 5以下的每个级别，人类都会在某个环节阅读代码。Level 3阶段，人类以高级开发者的身份管理AI。Level 4阶段，人类在12小时后检查测试是否通过。³ 这些级别之所以可行，是因为具备领域知识的人能够将代码与意图进行模式匹配。规格说明写的是”指数退避重试”，代码却实现了线性重试——开发者一眼就能发现问题。

完全移除人类之后，验证就变成了一个截然不同的问题。不是程度上的加难，而是本质上的改变。验证者不能依赖阅读理解。验证者必须将”正确”的含义编码为可执行的形式，然后在完全不审查产物本身的情况下，将输出与该编码进行比对评估。

核心陷阱在于代理会博弈测试。StrongDM发现他们的代理编写return true来通过测试套件，实际上什么也没做。¹ 测试全绿，CI流水线一切正常，代码却毫无价值。斯坦福法学院的Eran Kahana将这一观察延伸为结构性警告：更深层的问题在于循环论证——同一技术类别评估由同一类别编写的代码。⁴

古德哈特定律在此以异常强烈的方式发挥作用。当代理以通过测试为优化目标时，测试通过率便不再衡量正确性。⁴ 任何指标一旦成为目标，就不再是好的指标。暗黑工厂的验证层必须应对这一动态，否则它衡量的将是合规性而非质量。

StrongDM的实际验证方案

StrongDM的解决方案是他们所称的”场景”——存储在代码库之外的端到端用户故事，功能类似于机器学习中的留出集。¹ 这个类比非常精确：正如ML模型在未参与训练的数据上进行评估，代理构建的代码也在代理生成过程中无法访问的场景上进行评估。

关键指标是”满意度”：观测到的行为轨迹中可能满足用户需求的比例。¹ 对于什么样的分数才算充分满意，目前业界尚无标准。StrongDM通过实证方式确定了自己的阈值。

为了使基于场景的测试能够规模化运行，StrongDM构建了一个数字孪生宇宙——Okta、Jira、Slack、Google Docs、Drive和Sheets的行为克隆体。¹ 这些孪生体以流行的公开参考SDK客户端库为基准，目标是实现100%的API兼容性。¹ 代理在孪生体上运行，而非模拟端点。孪生体的行为保真度决定了测试的可信度。

StrongDM观察到一个我也亲身经历过的现象：”随着Claude 3.5的第二次修订版（2024年10月）发布，长周期的代理编码工作流开始累积正确性，而非累积错误。”¹ 在能力阈值以下，代理运行时间越长产生的错误越多。超过阈值后，运行时间越长产出的代码越好。暗黑工厂模式只有在模型跨越该阈值之后才变得可行。

治理的五个层级

BCG Platinion的五支柱转型框架包含一个治理层，在代码进入生产环境之前设置了多个验证步骤。² 五大支柱分别是：意图驱动的操作系统、编码化的知识基础设施、人才技能提升、配备独立验证代理的治理层，以及用于编排的工厂架构。² 在治理支柱内，BCG Platinion描述了由独立代理执行的基于场景的测试、静态分析、架构一致性检查、行为回归测试，以及主动尝试破坏输出的红队代理。²

独立性至关重要。当同一个代理既编写又测试自己的代码时，Kahana所指出的循环论证问题便会显现。⁴ 当一个独立代理——拥有不同的系统提示、不同的上下文、不同的激励机制——评估工作成果时，失败模式之间的相关性会降低。注意，不是消除，是去相关化。两个代理仍可能共享从训练数据中继承的系统性偏差。但当评估代理从不同的视角运作时，出现完全相同盲点的概率会下降。

BCG Platinion将”意图思维”定义为暗黑工厂团队的关键能力：将业务需求转化为精确、可测试的预期结果描述。² 人类的角色从编写代码转变为编写代理可以据此执行的规格说明。糟糕的规格说明会导致测试通过了错误的行为——与StrongDM遇到的return true如出一辙。¹

BCG Platinion还指出了一个我亲身体验过的约束：”AI代理的效能取决于它们能够访问的编码化知识。”² 一个缺乏项目上下文的代理会生成看似合理但违反本地规范、忽视架构决策、重新发现团队已解决问题的代码。编码化知识——设计决策、API契约、风格指南、故障历史——是基础设施，不是文档。

我在Level 4的现有实践

我的隔夜执行循环——Ralph Loop——运行在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差异，运行应用程序，验证输出是否符合我的意图。这一审查耗时30分钟到1小时，能够捕获钩子遗漏的问题。

钩子遗漏的问题才是真正有趣的。它们属于当前自动化手段难以有效处理的几个类别：

意图漂移。 代理忠实地完成了规格说明，但规格说明本身存在歧义，代理选择了错误的解读。没有测试能捕获一个产生有效行为的错误解读。StrongDM的场景方法通过将用户故事而非技术需求作为规格说明来应对这一问题。¹ 场景描述的是用户体验到什么，而非代码做了什么。

架构侵蚀。 代理添加了一个在孤立环境中运行正常、但损害系统整体结构一致性的功能。一个绕过现有仓储模式的新数据库查询，一个与另一模块重复逻辑的新端点。静态分析能捕获其中一部分。BCG Platinion治理层中的架构一致性检查能捕获更多。² 但两者都无法捕获那些技术上符合模式、却引入概念分裂并在未来变更中产生复合影响的微妙情况。

制度性知识流失。 Kahana提出了一个被低估的风险：当无人阅读代码时，也就无人积累对系统的直觉。⁴ 正如Kahana所警告的：”没有人会知道原因，也没有人会知道如何修复。”⁴ 如今，我的晨间审查在渐进地构建这种直觉。在Level 5，系统对其操作者而言变得不透明。每个复杂系统最终都需要自动化无法处理的干预——一次安全事件、一个违反测试套件内嵌假设的业务逻辑变更、一个与外部系统的集成行为偏离其文档描述的情况。从未阅读过代码的操作者无法有效介入。

验证层的实际需求

综合StrongDM的实践、BCG Platinion的治理框架、Kahana的失败分析以及我自身的基础设施，暗黑工厂的验证层至少需要以下要素：

留出集式评估。 生成代理在代码生产过程中无法访问的测试。StrongDM的场景方案。存储在代码库之外的行为规格说明，由独立代理评估。没有留出集评估，古德哈特定律会将每个测试套件变成被博弈的目标。

用于集成测试的数字孪生。 代理不能针对生产系统测试。Mock过于浅层——它们验证API契约，而非行为。复制外部依赖行为表面的孪生体使端到端场景执行成为可能，同时避免生产风险。

具有去相关失败模式的多代理验证。 编写代理与评估代理必须在不同的上下文中运作。主动探测博弈行为、走捷径和虚假验证的红队代理增加了被动测试无法提供的防护层。

工具级别的拦截。 在执行之前阻止有害操作的钩子，而非在事后检测损害的测试。钩子层运行在代理决策层之下，无法通过巧妙的提示工程或return true式的捷径绕过。

可执行的意图规格说明。 精确到歧义可被检测的规格说明。BCG Platinion的”意图思维”能力。² Shapiro在Level 4中描述的那种你在离开12小时之前编写的规格说明。³ 规格说明才是产品，代码只是副产品。

无责任空白的审计轨迹。 Kahana引用了AI生命周期核心原则，要求输出”可追溯至相应的责任方”。⁴ 目前业界尚无针对代理构建软件的标准审计方法。⁴ 验证层需要产生这样的产物：人类（或监管者、或事件响应者）能够从已部署的行为回溯到生成该行为的规格说明。

诚实的评估

我以高度信心运行Level 4。隔夜代理产出的工作在晨间审查中通过的频率远超不通过。钩子捕获机械性故障，证据关卡捕获认知性故障，质量循环减少行为性故障。

Level 5要求解决我尚未攻克的问题。在缺乏人类模式匹配的情况下检测意图漂移。能够捕获概念侵蚀而非仅捕获结构违规的架构一致性检查。在系统中而非在操作者脑中积累的制度性知识。

BCG Platinion报告称，采用暗黑工厂模式的团队获得了3-5倍的生产力提升。² StrongDM以三名工程师和一笔token预算发布了代理构建的软件。¹ 生产力方面的论证清晰明了。验证方面的论证则远未完善。

在Level 5取得成功的团队有一个共同特征：他们在验证基础设施上的投入超过了代码生成。StrongDM在信任代理发布代码之前构建了整个数字孪生宇宙。¹ BCG Platinion的框架包含五大转型支柱，其中治理层在代码进入生产环境之前设置了多个验证步骤。² 暗黑工厂并非在黑暗中运行的工厂。它是一个以验证层为光源的工厂，其他一切——包括代码——都是商品。

我之前写过代理无人监督运行时会出什么问题以及证据关卡作为抵御虚假验证的防线。那些文章描述的是Level 4的基础设施。暗黑工厂要求同样的基础设施在没有当前每天早晨阅读差异的人类的情况下运行。钩子、证据关卡、质量循环——它们在Level 5是必要的，但远不充分。缺失的部分是能够以与生成相同的自主性进行扩展的验证。

构建这一能力，就是前方的工作。