为什么软件工厂会失败（或：仅靠工具链工程是不够的）
Hacker News 摘要原标题：Why Software Factories Fail (or: harness engineering is not enough)
这篇文章由 HumanLayer 的创始人 Dex 撰写，深入探讨了 AI 软件工厂（Software Factories）为何会失败，并指出仅靠增加循环或优化工具链（Harness Engineering）是不够的。
软件工厂的现状与幻想
当前业界正在展开一场将 AI 编码投入生产的竞赛。主流观点认为人类是瓶颈，模型已经足够强大，代码应该是免费的，因此目标就是尽可能快地发布更多内容。诸如 StrongDM 等公司甚至尝试建立无人值守的软件工厂，即没有人类阅读或编写代码。
然而现实并不乐观。许多公司因为编码智能体的失误而遭遇停机。有报告指出，自 AI 编码工具普及以来，拉取请求（PR）的评审质量大幅下降，事故数量上升，每个开发人员产生的漏洞也在增加。代码库正以前所未有的速度崩溃。
为什么更多的 Token 无法解决问题
很多人认为如果 AI 编码效果不好，那是因为用户水平不够，需要投入更多 Token，让 AI 进行多轮循环或对抗性评审。作者认为，无论如何优化工具链，都无法解决模型训练层面的根本问题。
目前的模型在解决一次性问题或编写简单的营销网站时表现出色，但在长期维护代码库质量方面却力不从心。维护性的核心在于：能否在不破坏其他部分的情况下修改代码。AI 模型往往无法意识到这种长期的架构债。
模型训练与评估的缺陷
作者通过分析 Claude Code 的成功指出，将模型放在工具链中进行强化学习（RL）确实能提高效率，但这种训练方式存在致命缺陷。
1. 评分标准过于单一：目前的评分标准通常是基于测试是否通过。只要修复了指定的漏洞且没有破坏现有测试，模型就会得到奖励。
2. 缺乏对代码设计的惩罚：为了让测试通过，AI 可能会使用大量的 try-catch 块或者随意的类型转换。这种做法虽然能通过测试，但会破坏类型系统，降低代码的可读性和可维护性。
3. 反馈延迟：测试结果可以在几秒钟内反馈，但糟糕架构带来的代价往往在几周、几个月甚至几年后才会显现。目前还没有能够快速评估代码维护性的指标。
如果模型本身无法区分好代码和坏代码，那么它在强化学习过程中也就无法学会编写高质量的代码。
重新开启人类参与的流程
作者认为，目前的无人值守工厂行不通。当系统崩溃或出现 AI 无法解决的复杂问题时，人类最终不得不去挖掘几个月没读过的、充斥着 AI 垃圾代码的代码库，这种体验极其痛苦。
为了在保证速度的同时不烧毁代码库，人类需要重新回到流程中，并在以下四个阶段发挥杠杆作用：
1. 产品需求（Product Requirements）：明确要解决的问题和成功的标准。与其写冗长的文档，不如先做出粗略的 HTML 原型。
2. 系统架构（System Architecture）：在编写代码前，对服务、端点、模式、队列和存储之间的交互达成一致。使用序列图或数据模型图进行可视化沟通。
3. 程序设计（Program Design）：这是目前最被忽视的一步。在实现之前，先定义代码的形状，包括类型、方法签名、程序布局和调用栈。使用伪代码或调用树来规避 AI 容易犯的低级错误。
4. 垂直切片（Vertical Slices）：不要按照数据库、服务层、接口、前端这种水平顺序构建。应该采用垂直切片的方式，先构建一个能跑通全流程的最小路径，在每一步都进行测试和调整。
结论与建议
三十多分钟的前期规划可以节省数小时的评审时间。作者建议的分布是：
• 约 40% 的简单任务可以由 AI 一次性生成或进行少量反馈。
• 中等任务需要一份简单的计划文档。
• 大型任务则必须严格执行上述四个阶段。
你并不是 PR 太多，而是糟糕的 PR 太多。如果一个 PR 需要 20% 以上的重做，就会对提交者和评审者造成巨大的负担。
最终的建议是：不要盲目追求 10 到 100 倍的增长速度，而应该在了解 AI 局限性的基础上，通过加强规划和评审，安全地实现 2 到 3 倍的效率提升。最重要的是：一定要阅读并理解那些代码。
原文：https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md