软件工厂为何失效：Harness Engineering不够用
Why Software Factories Fail (or: harness engineering is not enough)
我是 HumanLayer 的创始人，长期关注人机协作工具。当前业界流行一种观点：只要通过 Harness Engineering 编写更多循环，就能实现全自动的 AI 软件工厂，让人类彻底退出代码编写和审查环节。然而，Faros AI 的数据揭示了残酷现实：自广泛采用 AI 编码工具以来，代码审查质量大幅下降，生产事故和 Bug 数量激增。许多人将此归咎于开发者技能不足，认为只要投入更多 Token 就能解决问题。但我认为，这并非技能问题，而是模型训练和评估的根本性缺陷。无论我们如何优化循环或配置 Linter，都无法解决模型生成的低质代码（Slop）问题。真正的出路在于理解软件工厂的演变历史，并在复杂代码库中重新思考人类与 AI 的协作边界，而非盲目追求无人化的‘黑暗工厂’。
我想说服大家的是，无论多少 Harness Engineering 或循环优化，都无法解决这本质上是一个模型训练问题。
HN 评论区
262- sgt101
这挺有意思，但凭什么我们要相信这些？
1) 这哥们儿有前科（他自己都承认了），就是胡编乱造、大吹大擂，然后硬塞给无辜的人。他用那些胡扯的东西已经造成了不少损害，现在又想让我们再次关注。我意思是——这家伙有点疯疯癫癫的。
2) 他的想法好在哪里，完全没有任何证据。他只是在瞎编。
给我个理由。另外，他之前搞的那些垃圾，难道不该被社会孤立并剥夺财富吗？
- sathish316
我称之为“意图 - 实现 - 质量”问题。
软件工厂只要给出一行需求，就能实现任何东西。这一行需求可以是一个完整的应用/产品、史诗级任务、功能、Bug、设计变更或重构。但这些一行式的需求来自人类，他们脑海中有着产品的意图、需求或演进方向。软件工厂能制造出那种能精确反映使用者需求，或体现其对产品/软件演进愿景的“意图”吗？
用任何语言实现代码，都跟给 LLM 生成摘要一样简单。如果编程只是数学，且将需求转化为实现只有一种方式，那么问题就简化为提供或验证生成的意图。但事实是，实现某件事肯定不止一种方式。其中一种方式能带来与系统其余部分协调一致的设计与架构，一种可扩展且能演进的设计与架构，一种当你下次或明天想修改时能轻松记在脑海里的代码，一种能服务百万用户并安全保障百万美元营收的软件。实现方式存在组合爆炸，而“正确”的那一种也取决于人和具体问题。软件工厂当然可以通过生成更多单元测试、集成测试、修复代码违规、生成工作证明（如视频、截图等）来提升质量，但那里……
- fishtoaster
这里有一些好想法和观点，但这一段让我很困惑：
> # 我们尝试过
> 2025 年 7 月，我们全面转向了“熄灯”模式（lights-off）
现在不是已经普遍公认，模型在 2025 年秋季/2026 年春季经历了一次实用性的飞跃吗？我知道在那之后我就能开始把整个功能交给代理（agents）去处理，但在那之前不行。
我觉得，关于“代理能/不能做什么”的任何来自那个时期之前的观点或经验……对现代时代来说可能相关性就不那么高了。文章后面几节确实提到了“但模型肯定从那以后变强了吧”，但随即就一笔带过，完全无视了任何进步。这跟我的体验不符。
- janalsncm
要么你理解你的代码库是如何工作的，要么你就不理解。
Claude 可以为你写代码，但它不能替你理解代码。这部分工作必须按人类的速度进行。
确实存在不需要理解一切的情况，但我认为这是一个更微妙的问题。
即使 Claude 写出了完美的代码，以上所有观点依然成立。
- stillpointlab
看到其他人也经历着跟我完全一样的现实，这让我感到安慰，因为这篇文章里的很多内容都与我自己的经历相符。
这让我想起了最近关于“品味（taste）”的讨论。架构的“质量”可能不像对错那样是客观的，就像时尚没有对错之分一样。感觉我们大家都得把理性交给机器，转而开始钻研美学了。
即使在历史上，我最大的挣扎通常也是在两个几乎等价的选项之间做决定。现在用 LLM 时我更是经常遇到这种情况，因为实现过程不再像以前那样强制我们在这些决定之间留出缓冲。我感觉自己总是在没有明确客观标准的权衡之间不断做“品味”上的判断，这正如这篇文章（以及我的经验）所暗示的那样，即使有了 Fable/GPT-5.6 级别的模型，代码审查依然是必要的，而且同样令人精疲力竭。
在很多情况下，我就像以前审查初级工程师代码时那样：当场做判断。看到“破窗”我就指出来。但看到小问题时，我有时会先放行，记在脑子里，等积累到一定数量的类似小问题时再集中处理。
顺便提个旁枝末节，我想起两家代理出现之前的开发公司。一家决定雇佣 7 位极具才华的工程师，让他们紧密协作。另一家决定外包给 100 名水平中等的工程师，并试图把他们隔离成模块。我认为我们正……
- _pdp_
我对软件工厂喜忧参半！
一方面，我们的核心产品在其规模上根本不适合它们。我们试过，但项目大到每一次变更都需要人工介入。不过，我们确实有 AI 自动化用于轻量级代码重构、编写测试、UI 变更等，而且效果不错。
另一方面，我启动了一些小实验，看看软件工厂能推到什么程度。虽然目前生成的代码没什么惊艳之处，但我很容易想象这在未来如何扩展。也许如果你从一开始就抱着“代码将以此种方式编写”的理念，就能想出适应它的策略和架构。至少这是我现在的想法。
总之，这一切都是开源的，文档在这里：https://relentless.works/ 我不确定我会让这个项目运行多久。我完全没有指明它要去向何方。我不知道接下来会发生什么。这只是一个有趣的实验。
我还有另一个类似的实验，是一个交易代理。我以为它很快就会亏光所有钱。有一段时间，它在亏了一点钱后就没有任何持仓了。我决定不干预，只是观察它的行为。最近它开了一些新仓位，这是一个有趣的发展。它仍在亏钱（约 -3%），但并没有亏光，考虑到当前的市场环境，我会说这其实不算差。这仅仅表明，也许我们有点太急躁了……
- rglynn
对我来说，我们目前整个状态中最突出的事情就是 PR 审查。
是的，在理想世界里，PR 读起来很顺畅，审查起来是一种享受，反映了你们讨论的内容等等。但我们要现实一点；在这方面我们能做的终究有限。
我不确定顶尖团队是如何进行 PR 审查的，从我的角度来看，这很糟糕。我特指 UX。我一直讨厌 Github 的 PR 页面，所以我通常的做法是拉取分支，然后用 $EDITOR 打开 diff 进行审查。
如今，这种糟糕的 UX 真的没有任何借口了。Linear（一家甚至不在代码审查领域的公司）推出了一项基础的 PR 审查功能 [0]，已经比 GH 提供的要好。它很简单：让一个小模型分析 PR，根据主题将文件变更分组，添加一些评论，并按重要性排序（模式变更 > openapi 规范）。
立刻，审查者和请求者什么都不用做，心智负担就大大减轻了。这个功能其实非常基础，我认为显然的下一步是生成可视化内容，专门的产品团队应该有时间去实现它。
很想听听大家的想法：为什么这是错误的方法？或者有没有广泛使用的工具能解决这个问题？又或者为什么这不是我们应该关注的问题？
- gblargg
编译器就是软件工厂。它根据规范（代码）构建可执行文件。