为什么黑灯软件工厂会失败——RLVR 的质量盲区与正确的 AI 编码工作流

📝

HumanLayer CEO Dex Horthy 深度分析：黑灯软件工厂（无人读码无人写码）为何必然失败。RLVR 强化学习只奖励「测试通过」而不惩罚「烂设计」，基准测试无法衡量可维护性。提出了替代方案——产品评审→系统架构→程序设计→垂直切片的四阶段人机协作工作流。

原文：Dex Horthy (HumanLayer CEO)，译/明知山，来源 GitHub advanced-context-engineering-for-coding-agents

我经营着一家叫作 HumanLayer 的公司，致力于研发人类与智能体协作的工具。因此，我下面要说的内容可能会带点主观色彩。

我们都在循环工程的路上了

关于循环工程（Loop Engineering），目前普遍的看法是：多构建一些循环流程。StrongDM 曾撰文介绍他们的「黑灯」软件工厂——在那里，没有人阅读代码，也没有人编写代码。

大致的说法是：你就是瓶颈，模型已经足够好，代码是免费的，抓紧交付就好。

但 Faros AI 的报告显示：自今年一二月份大家陆续用上各类 AI 编码工具以来，PR 的评审质量大幅下滑——评审留言变多、篇幅变长，大量 PR 在没有评审的情况下就被合并，线上故障数量大幅上升，每位开发人员的缺陷数量显著增加。

网上铺天盖地的论调——「使劲堆词元就行了」，核心逻辑是：只要做好充分的 harness 工程设计，就能 10-100 倍效率提升 + 高质量 + 不用再代码评审。

我要努力说服你的是：无论怎样优化硬件设计或提升循环峰值性能，都无法从根本上解决一个本质上属于模型训练的问题。

Claude Code 之所以能在编码智能体中胜出，是因为 Anthropic 首次针对实际部署的工具用 RL（强化学习）训练了模型。但 RLVR（可验证奖励强化学习）流程中有个致命缺陷：

糟糕的设计不会受到惩罚。 SWE-bench 只检查「测试是否通过」，而不管模型是否滥用了 try-catch、偷懒的类型转换、或者埋下了霰弹式手术的维护炸弹。

运行测试可在几秒内给出通过/失败结果——正因如此，RL 才能运行数百万次迭代。但糟糕的架构让我们付出的代价以周、月甚至年为单位衡量。糟糕的设计正是当今基准测试无法评估的一环。

作者以自己公司的亲身经历作证：2025 年 7 月全面进入黑灯工厂模式后，至少遇到一个极度棘手的难题，即使使用了最前沿的提示词和工作流，智能体依旧束手无策。到了 11 月，这类问题第三次出现时，他们干脆决定从头重写——联合创始人花了整整两周用 VS Code 纯手写把所有模式梳理了一遍。

模型无法长期持续提升代码库质量，除非有相当程度的人工干预。

一些努力方向值得关注：

但它们仍无法突破上限——上限就是在 RL 中成功教会模型的东西；而优秀的设计，恰恰是我们目前仍不知如何教会模型的。

作者提出的替代方案——在产品评审、系统架构、程序设计、垂直切片四个阶段中借助 AI：

一份简短的文档，阐明正在构建什么以及为何这么做。用 HTML 原型替代三段文字描述，一锤定音。

确定服务、端点、模式、队列和存储之间的通信方式。大量使用可视化——序列图、契约/端点定义、数据模型。

1
2
3

PUT /api/resources/:slug
request: { destination: string }
response: { resource: Resource }

从架构深入到代码的具体形态：类型、方法签名、程序布局、调用栈。用伪代码做轻量级可视化，用差异语法对比改动。

反对按技术栈分层依次构建（数据库迁移→服务层→API→前端）。主张从中间开始向外扩展：API 契约+模拟数据→前端消费→连接服务层→数据库→业务逻辑→错误处理。每次检查 100-200 行代码，边做边调整。

你可能正一心追求 10-100 倍的开发提速，还试图说服自己代码质量已无关紧要。但其实如果你能接纳这些客观约束，反而能更安全地实现 2-3 倍的提速。

核心建议：充分了解约束条件 → 在约束下优化系统 → 寻找效率杠杆 → 务必审阅代码。

项目	Stars	语言	说明
humanlayer/humanlayer	11,187 ⭐	TypeScript	AI coding agents 协作工具
humanlayer/advanced-context-engineering-for-coding-agents	2,225 ⭐	—	本文原文所在仓库