← #802

为什么「软件工厂」会失败（或：harness 工程还不够）

文章摘要

HumanLayer 的 Dex Horthy（dhorthy）写了一篇长文，论证「关灯式软件工厂」——让 AI agent 在无人审查的情况下写代码——为什么会失败。他的核心主张不是模型不够聪明，而是：当前的模型无法长期维持代码库的质量，无论你把 harness（工具形状、prompt、循环）优化到什么程度。

第一层论证是约束问题。模型在解决孤立问题上表现出色，但缺乏做出「保护可维护性」的架构决策的能力。他的关键句是：现有的评测体系里「侵蚀代码库可维护性没有任何惩罚」，这就允许模型不断给出制造长期债务的快速技术修补。

第二层是为什么 benchmark 会误导。SWE-bench 这类标准评测把成功定义为 15 分钟任务内的二元通过/失败，而架构问题是在数周到数月的尺度上复合累积的——目前没有任何 benchmark 在测这个时间尺度。这就在「模型被优化去做什么」和「生产系统真正需要什么」之间撕开了一道口子。

第三层是 RL 训练的鸿沟。强化学习可以把模型优化到立刻通过测试，但无法有效惩罚那些代价在很久之后才浮现的决策。他写道：「测试在几秒内给你反馈，而糟糕架构的代价函数是以周、月甚至年来衡量的。」

第四层是真实世界证据。Faros AI 的报告显示，从 2026 年 1 月起出现了可测量的劣化：PR 评审质量下降（评论数 +25%）、每个 PR 的事故率上升 242.7%、每个开发者的 bug 数 +54%——时间上与 AI 编程的大规模普及吻合。他还引入了「shotgun surgery」这个代码坏味道（改一个组件需要在系统各处零散修改）、以及一个更刺人的观察：过去需要多年才形成的 brownfield 遗留代码库，现在 AI 写出的代码在 3-6 个月内就会变成那样。

他给出的替代方案是「开灯式」（lights-on）：不取消人类审查，而是把人的介入放在四个战略性阶段——产品评审（澄清要造什么、成功标准是什么）、系统架构（组件如何交互、schema 长什么样）、程序设计（定义类型、签名、调用栈）、垂直切片（逐个功能实现、持续测试）。他的取舍是明确的：用前置的 30 分钟规划换回后续数小时的审查时间，安全地拿到 2-3 倍速度，而不是去追求那种会引入灾难性风险的 10-100 倍。结论是拥抱约束而不是否认它：模型对生成代码真的有用，但架构决策上需要人的引导。

HN 评论精华

_doctor_love（最高赞）：他先补上了文章作者查不到的信息——文中提到的 StrongDM「黑灯工厂」实验后续，用一次老式 Google 搜索就找到了（diffusion.io）。但他的核心分歧是：「用 LLM 写好代码，这不是技能问题，是投入/懒惰/严谨度的问题。」要让 LLM 编程走得顺，需要更多严谨、更多纪律、更多工程上的硬骨头。「用 AI 拿到最好结果的团队，本来就是高纪律、高卫生度的团队。」他还给了一个 ML 视角的论证：AI 作用于数据，代码就是数据，如果你的代码烂，再牛的模型也无法产出和「起点是好代码」同等的结果——这个原理在 AI/ML 圈从上世纪就众所周知。他进一步认为，做 spec-driven development 而不认真研究形式化验证的人一定会落空，因为「prompt 根本不足以把编程 agent 引导到所需的精度」。
dhorthy（作者回复）：两点都「强烈同意」，但都不认为充分——「即使形式化验证也有它的局限。」关于数据他补充了一个技术点：RL 数据的形状和过去 25 年驱动 AI/ML 创新的 SFT 数据不同，那里还有巨大的创新空间（ImageNet 说到底只是手工标注的答案对）。至于「不是技能问题是懒惰问题」，他觉得这是语义之争：「『skill issue』的意思本来就是『你没投入努力、没去学那些技巧』。」
edot（对「有咨询公司成立说明实验挺成功」的反驳）：「你把这个信号读反了。软件公司在产品无法自立时才提供咨询。参见 Palantir、Salesforce。它们是成功的公司，但不是成功的产品——产品需要被销售工程师和咨询顾问实例化、维护、定制成几乎不再是这家公司产品的东西。」
jaytaylor（StrongDM AI Lab 三人组之一，来澄清）：文章把他们的 Weather Report 描述成「稀疏更新」有点负面，但他们的更新频率取决于「什么时候在某个相关维度上发现有意义的改进」，自二月上线以来平均每月一次。dhorthy 请他们做一个 5-6 个月的回顾，jaytaylor 说新文章在写，整体展望依然乐观：「几乎所有软件问题都能被 Factory Techniques 的组合攻克，更强的模型效果更好。」
rglynn（引出了本帖最长的一条讨论支线）：他觉得整件事里最突出的是 PR 评审这个环节。理想世界里 PR 读起来清晰、评审是享受，但现实是能做的有限。他吐槽的是 UX：他一直讨厌 GitHub 的 PR 页面，通常是拉分支下来用编辑器看 diff。他举 Linear 的例子——一个连代码评审领域都不在的公司做出的基础 PR 评审功能已经比 GitHub 强：用小模型看 PR，按主题给文件变更分组，加点注释，按重要性排序（schema 变更 > openapi spec）。「评审者和提交者什么都没做，心智负担就已经大幅下降了。」
4lx87（本帖最有争议的评论）：「用代码评审来卡集成是徒劳的。我（和很多其他工程师）已经把它自动化了。我的 agent 会响应评审请求，以我的身份做评审。公司强制人类评审的政策是徒劳的。」他认为所有押注代码评审的平台都注定失败，应该评审的是「实际工作的软件」，需要的是能让任何提议的变更即时可演示的系统。「软件生产的未来更像 Replit，而不是 GitHub。」
20k（最直接的反击）：「这也叫做当一个糟糕的工程师。如果公司强制人类评审而有人故意用 LLM 绕过，我会当场开掉这个人。」人类评审的理由是：1）让你理解在发生什么，而不是让 LLM 理解，这样别人才能问你问题；2）LLM 其实并不擅长代码评审。「炫耀自己不做本职工作很奇怪。听起来你可以被一个 Python 脚本替代，那你带来什么价值？」
necovek（系统性反驳「组织只把评审当抓 bug 手段」）：他列出了 LLM 之前组织看重代码评审的多重目的——在多人之间分享某块代码的知识、在评审双方之间分享工程知识、保证长期可维护性、保证可读性、在变更变得不可逆之前抓住架构/方向性遗漏（比如大规模破坏性的 DB schema 变更）、保证变更小而自包含且尽可能可回滚、做基础手工 QA、做完整系统的集成测试……然后才是「在进生产前抓 bug」。
roncesvalles（本帖最被引用的定义）：「软件工程师的角色首先是对软件系统的所有权，其次才是修改它们或开发新的。」软件开发是一项持续的运营性事业，像打理一座花园，而不是像设计一个 logo 那样的一次性任务。系统需要照料，需要有人知道它们怎么运作。他还补了一个推论：企业的很多规则和政策唯一的存在位置就是软件本身——很少有一整套完整文档说「这是一切的运作方式」，你想知道某件事怎么运作，就得去问工程师，他会去代码库里看然后告诉你。
DaiPlusPlus：如果要压缩成一个词，「我们做代码评审是为了评估『品味』（taste）」。他说 Claude 现在会很乐意接下一个 Jira ticket、写计划/spec、写测试、实现功能、验证测试通过、处理静态分析问题、推分支、提 PR——如果程序能跑就算「正确」，那似乎没什么可评审的了，「但我一直在拒绝这些 PR，因为这些 agent 还是『就是不懂』。」
jeremyjh：整篇文章讲的就是这样工作代码库会随时间劣化。如果他们是对的，PR 会越来越难开发、QA 会需要越来越多轮次，最终代码会变得无法挽救，而且可能在任何人注意到问题之前就已经到了那一步。「这不是必然的命运，但它看起来相当可能，而且是个严重的风险。」
satvikpendem（贯穿全帖的乐观派）：「赌的是模型变好的速度快于代码变坏的速度。看起来到目前为止这个赌是对的，Fable 已经能写出比我和大多数人平均水平更好的代码。」
dhorthy（对上述最关键的一次澄清）：「问题不是『模型能不能让代码变好』——而是『在完全无人看管的情况下，它们会不会随时间把你的代码库变成 slop』。」他引用自己脚注里的话：当然你可以让高推理档的模型做出精彩的重构，但你必须告诉它去做；而要能告诉它去做，你必须对自己的代码库理解到知道它需要被重构。「我们这里讨论的正是为什么关灯不行。」他还补了一句：「Rebuild sqlite from spec 有着我批评过的所有其他 benchmark 的同样问题——模型一开始就知道整个问题，永远不需要在自己为了走捷径通过而堆出的那堆 slop 上迭代。」
fishtoaster（时间线上的质疑）：文章说「2025 年 7 月我们全面关灯」——但现在不是普遍接受模型在 2025 年秋到 2026 年春经历了一次阶跃式的有用性提升吗？「任何来自那个时间段之前的『agent 能做什么/不能做什么』的经验，可能对现代已经不太相关了。」
2001zhaozhao（部分同意上条）：他读文章和作者的产品网站时也有这种印象，很多内容像卡在 2025 年。比如「长上下文不是答案」那篇他觉得不准确：他的体验里 Opus 4.6 及之后在长上下文上非常可靠，70-90 万 token 时他感觉不到智能下降——虽然成本效率极差，但确实能用。
hansvm（反驳）：他在 Opus 4.6 上能剧烈感受到长上下文的智能下降，「对任何精细且冗长的东西都几乎不可用。」他后来给出了一个更精确的用法区分：长上下文适合综合（「这是一天的生产日志，什么坏了？」），不适合分步执行。Terretta 同意：「用于综合。一口气读完然后归纳，或者规划该怎么办。不用于步骤。」
onion2k（关于「最好的团队怎么做 PR 评审」）：他们不做。他们在做变更的过程中就讨论变更（软件设计和架构），把所有会变成鸡毛蒜皮的东西全部自动化（lint、格式化），并严格遵守「不许弄坏 build」的规则（配上大量自动检查和测试来证明这一点），还确保有健壮的回滚流程。「一旦你做到这些，PR 流程就没意义了。它从来抓不到任何有用的东西。团队可以互相信任、不需要那道门。」
kkapelon（反驳上条）：手工 PR 评审能抓到 LLM 目前会漏的东西——重复代码、缺单元测试、引入安全问题，这些都不会弄坏 build。「而且测试本身是无用的，除非你有个聪明的系统能在不带变更的情况下跑新测试、看它挂掉。我今天看到的大多数团队都是让 LLM 连着变更一起写测试，没有任何保证测试真的守住了那个功能。」他后面还补充：架构问题、向后兼容性破坏（一个正确的修复破坏了所有现有用户的配置）——今天所有静态分析和安全扫描工具都抓不到这些，「所以 LLM 前后都需要人在那里。」
danpalmer（PR 可读性的根本诊断）：PR 评审之所以痛苦，是因为工程师常常没有为它优化自己的代码撰写方式；而 agent 生成代码的 PR 评审更痛苦，因为 agent 在「为评审而撰写」上非常差。这是合理的——评审过程并不体现在最终的代码产物里，而那才是它们被训练的对象。「Agent 产出的变更总是远大于单步应有的规模，而且经常碰到不相关的代码，对该不该包含判断很差。」他后来透露自己在 Google 的 monorepo 里做过 PR/CL 生成的 skill：「一个好的 PR 会给读者讲一个故事，让他们对结果有信心。那意味着了解读者和他们的思考方式，而这是 LLM 非常不擅长的。」
preg_match：agent 有一件事特别烦人——它们生成极长极详细的注释。听起来对评审有好处，但「注释永远不是意图或权衡，永远是『是什么』，而紧接着的代码又把这个重复了一遍。注释应该是简短精炼的『为什么』。」
viccis：他的同事分成两派——一派提 PR 时如果他有严重疑虑，那是因为双方在某个概念上根本分歧、需要坐下来聊；另一派提 PR 时他有严重疑虑，是因为很明显他们在提 PR 之前从没看过 LLM 的输出。后者还会把他的评论丢进 LLM 会话，然后用一堆 Claude 风格的问题列表回他。「我坚信没有理由雇用后一群人。」
sevenseacat：「前几天我收到两个 15,000 行的 PR，来自同一个人。我目前正在无视它们。」
tcoff91：「PR 在 agent 出现之前就已经很难评审了，但现在真的很糟，因为要评审的数量变多了。」他后面补了一句黑色幽默的应对策略：「我记得清楚谁的 PR 可以信任、谁的 PR 大概是 slop，并据此分配时间。Slop 商人得到 slop 评审——我直接把我的 clanker 指向他们的 PR，让它批判性评审，通常能找出一大堆问题。」
jpollock：还有合规理由——SOX 要求第二方进行代码评审。如果评审是自动化的，开发流程就不合规，代价可能迅速变得昂贵。dboreham 吐槽这些 SOX 强制的第二次评审 99% 是纯表演，bandrami 则辩护说它像机场安检的表演性——虽然是「给人看的」，但这场表演本身很重要，它让整类攻击变得显著不可行，就像街角站一个穿制服的警察能显著减少街头犯罪，即使这个警察从不和任何人互动。
AIorNot：「等一下，这些不是『软件工厂』，这些是串在一起的 AI 鲁布·戈德堡机械。」他觉得荒谬的是人们写这类文章、制定这类标准，好像这是某种有多年研究和经验支撑的工程标准。「AI 和 AI 工程还是非常早期，工程团队需要针对自己的质量指标去实验、去看什么有效，而不只是鹦鹉学舌『标准和方法论』。」dhorthy 回应说他的主要目标恰恰是把当下「agentic 软件工厂」的炒作放进「我们其实已经用鲁布·戈德堡方式做软件部署很久了」这个历史语境里。
dhorthy（一个他希望被更多讨论的点）：确定性系统在评估质量上要好得多（测试、linter、圈复杂度等），「但我们对代码可维护性没有这样一个系统，至少没有一个被广泛接受或采用的。」