← #806

工程师为了不从历史中学习什么都干得出来

文章摘要

作者 David Horn（2026 年 8 月 15 日），副标题一句话就把论点说尽：「先是我们重新发明了统计学，然后是金融学，现在我们在重新发明项目管理，并把它叫做 agentic orchestration。」

缘起很具体：他在一篇讲「理解力才是新瓶颈」（Geoffrey Litt，2026 年 7 月）的 HN 帖子下成了热评第一，语气比他本意更刻薄了些——他基本上是在做那个「一直如此（always has been）」的表情包；但当天他又看到另一篇上了首页的《与 AI 协作更像领导而不是写代码》，这让他担心这正在变成一种趋势。工程师们正在形成一种（大体正确的）直觉：管理多个 agent 很像管理工程团队。于是他忍不住要抱怨他认为工程师最恶劣的习惯：没人读那本该死的手册。

他的证据链是三个历史案例。第一个是数据科学：工程师花了数年建立一套技术和诊断方法的基线，那是一个新领域令人兴奋的时期——「只不过它不是新领域，它是取了个更酷名字的统计学」。真正推动领域前进的人当然知道这一点，他相信那时的想法是「观测数据够多，概率就趋于确定」，这就是 Big Data 梗的来源；统计学家通常不会用 Big Table 或写 MapReduce，但他并不相信当年他看到的那些人里多数知道数学那部分是旧的。他引了《50 Years of Data Science》（这篇论文在学术界注意到了同样现象）和 Nate Silver 那句「我认为数据科学家是统计学家的性感化说法」——后者当年触发了一批数据科学从业者写文章生气。第二个是加密货币：他引 Matt Levine 的观察，说 crypto 基本上把金融史速通了一遍，结果有时有趣、但常常滑稽且灾难性。第三个是他插进来的一句冷幽默：「我们甚至重新发明了公交站」（链接到斯坦福日报那篇讲硅谷不小心重新发明城市公交的报道）。

然后他把动机分成两类。有效的理由：对那些早于现代软件、因而显得晦涩的机构化领域的不信任；以及从第一性原理出发学习，有时确实能带来对该学科更深的理解并发现新的效率。不太站得住的理由：把某个东西包装成新颖未被发现的，能赚很多钱，还顺便让自己听起来聪明前沿——「没人会为『正确地应用一门被充分理解的学科』去募一轮资金」；以及那句「这能有多难？」

正是后一类动机让他动笔，因为读那些「如何管理你的 agent」的评论文章时，他能看清这一切的走向：从没认真对待过 TDD 或 PRD 的工程师，正在发现他们必须提前定义每一个行为，以免 AI 猜错、造出错的东西；曾经抱怨自己那位不懂技术的工程经理从不真正了解事情如何运作的工程师，正在意识到自己也懒得读 AI 产出的一万行 PR。突然之间，瀑布流成了该做的事。但他推测工程师大概不会叫它瀑布流或项目管理，而会起一个更性感的名字并伴随大量被重新发明的知识——也许叫回旧名字就等于承认那些管理者是对的；也许他们已经不知道瀑布流是什么了，因为它被正面提及已是很久以前的事。他怀疑大多数人不知道 Winston Royce 是谁、也没读过他的论文：「就连工程师们拒绝的那套流程，他们也是在没真正理解的情况下拒绝的。话说回来，项目管理的入门指南也确实上不了 HN 首页。」

他的核心归约是：agentic orchestration 就是项目管理。 确保需求被良好地文档化；确保那些需求真的是最该做的事，以免浪费宝贵的 token 和时间；划出清晰的工作车道；用流程确保产出的制品满足全部标准；而且 agent 跑得越久，就越需要它们沿途产出定期的进度汇报——「这个仪式有个名字，而工程师们已经为它的时长、该谁参加、乃至它是否值得他们的时间争论了十五年。」

文章末尾是一份书单，每本都附了他的理由：《Making Things Happen》和《PMBOK Guide》——字面意义上的项目管理手册，封面看着像只会在大学书店里出现的东西；《人月神话》——名单里大家最可能听说过的一本，讲沟通开销随人头数呈平方增长，字里行间读出来就是你要同时开十个 agent 会遇到的挑战；《Managing the Development of Large Software Systems》（Royce 那篇）——描述了大多数 AI coder 现在正在做的那种瀑布流、为什么它不好、以及该怎么做，只有 12 页 PDF，在网上难找得恼人但值得；《High Output Management》——他承认自己还没读，但背书够多所以还是列上，可能是最不直接适用、却最有解读空间的一本；《目标》（The Goal）——讲优化非瓶颈会发生什么，是最早那批「理解力才是新瓶颈」的书之一，约束理论的出处。

HN 评论精华

这条帖子 177 分、108 条评论。讨论的真实走向和标题只有部分重合：最长的两条支线一是「软件开发者到底算不算工程师」的老争论（并一路下探到基督城 CTV 大楼倒塌、格伦费尔塔火灾里工程师究竟有无法律后果），二是从一句「其他行业慢是因为边际成本不为零」引出的关于 3D 打印能否取代铸造的高质量制造业讨论。真正回应作者论点的评论不多但很精准。

Avicebron 抓住那句「把东西包装成新颖的能赚大钱」说这就是问题的症结，很像用 VC 补贴打穿一个市场直到它死掉再取而代之的策略。sscaryterry 接一句「VC 补贴已经不够了，现在得靠 IPO 续命」，singpolyma3 补充说 IPO 及后续增发根本不是临时补贴，「那可以一直撑到经济死掉」。an0malous 用一句「作为一名 MCP 工程师，你怎敢如此」精准嘲讽了这个现象，r_lee 回「哈哈得把这头衔写进简历」。
wat10000 提出了作者名单上漏掉的、也是他自己最主要的理由：造东西很有趣，重新发明也很有趣，那是他遇到钉子时最自然会伸手去拿的锤子——未必是最好的选择，但人生就是这样。fragmede 说「找到一个东西、用它、发现它很烂、然后做一个自己的更好版本，是完全自然的本能」，wat10000 精确地补了一刀：「是的，但我们常常跳过前三步，直接进入做自己版本那一步。」DangitBobby 说他在每一篇抱怨软件重造者的帖子下都会解释这一点：「凭什么六七十年代的人可以独享所有乐趣？」——迄今徒劳无功。nojokepoke 补了作者漏掉的另一个动机：「巨大的自我」——他不明白为什么每个软件工程师都觉得自己是上帝的礼物、能从第一性原理推导出一切；他认为在软件行业这尤其严重，因为平庸的回报实在太惊人了。
对作者论点最有分量的反驳来自 Areading314：核心观点（与 agent 协作只是既有流程的某种变体）是错的——管理 agent 与 EM 和项目管理确有相似，但还有一大堆别的维度，比如 token 用量、避免 drift、大规模下的并发成功率、prompting 的变化、测试、评估，更别提「这些 agent 是零常识、极度字面化解读、极度啰嗦的超智能程序员」。demibabs 支持这个立场：「能列出两个东西有很多相似之处，并不意味着它们在实践中真的那么相似——这就是预测未来极其困难的原因。」但 preg_match 逐条回击并且相当有说服力：token 用量就是时间和人力成本；drift 在人身上也会发生，当一个人被摊得太薄又缺少 check-in 时——「这正是我们有站会的原因，为了避免 drift」；prompting 就是管理；零常识加极度字面化解读加啰嗦？「那听起来就像一个可能在谱系上的普通工程师」；「啰嗦这条你赢了，人不会那样；不过人会搞过度复杂，当那让他们觉得自己聪明的时候」。
mpyne 给出了最细致的批判性支持：他几乎完全同意这篇文章，唯一不同意的是不该字面照搬瀑布流或 PMBOK。他手上有 Royce 原论文（收在 Lewis 编的《Ideas that Created the Future: Classic Papers of Computer Science》里），并指出 Royce 的论文谈的是任何有用系统都需要字面上数千页的文档——「祝你好运把这个塞进 1M 上下文窗口 :P」；他认为敏捷方法一直都允许你划定 scope、检查进度、给清晰需求和测试用例，而 LLM 快到你不需要走全套瀑布（真走了反而可能反效果）。他还把这个论点的谱系往前推：「不能放任你的 coder 想干什么干什么然后期待正确结果」甚至早于 Brooks，可以一路追到关于巴贝奇计算机器的记载——当时英国政治家问它输入错误时是否还能给出正确答案，「答案当年和今天一样：当然不会，期待别的结果是愚蠢」。
bluehatbrit 提供了实践者视角，也是全场最贴合作者论点的证言：他是一支约 20 人工程团队的 hands-on 工程负责人，过去六个月一直试图让团队理解这一点；上周五的 coffee hour 上大家对他采用的工作流「一脸困惑」——对他这个当过一段时间管理者的人来说这些做法很自然，但对从没走过管理路径的人来说非常陌生。他强调不是说自己的工作流更优，只是极其不同：实质上就是重度依赖 PRD、限制 agent 之间的通信之类。Fordec 追问细节并提出自己的判断：限制 agent 间通信对任何没有把敏捷正统教条整个咽下去的人来说是显然的——上下文切换（在 agent、人或任何对象之间）都需要重新加载上下文的爬坡时间，总是更慢更贵，「而且没有任何 agent 会获得长期训练，在 1M 上下文窗口里不会」。psunavy03 反驳说「正确做 Lean 和 Agile 的首要原则之一就是限制 WIP、尽量避免上下文切换」，bluefirebrand 一句话点破：「大多数组织并没有在正确地做敏捷。」andrekandre 描述了常见现实：只是实施了 scrum 就交差，同时业务按有营销截止日的季度项目运转，于是变成「scrum + 瀑布」反复循环。Fordec 补了一个具体的组织失败案例：他们的「敏捷实践者」（真实职位名）把这件事推到一个任务里接下来四张工单被拆成四段各一小时的工作、发给四个不同的人，不管上下文和技能匹配，而两年前那是一个人拥有并在一天内做完的事——WIP 指标上被最小化了，但总人时翻倍；运营总监靠这个 WIP 指标升职，一半团队因沟通负担增加和缺乏所有权而离职。他推测有些人正以同样方式做 agentic 开发：把工作在 agent 之间切得太碎，给每个 agent 新的上下文和预先计划，而其实一个 session 在同一个上下文窗口里就能把整个问题做完。
bthornbury 一句话确认了作者的核心预言：「『突然之间，瀑布流成了该做的事』——和我的经验吻合。大概 90% 的工作就是 spec。只不过不再是花几周做调研，而是像几小时和一个 agent 谈出来。」
slopinthebag 提出了对整个「管理」类比的根本质疑：agent 不是人，是代码生成机器；管理的一部分是委派并信任下属的产出而无需自己逐一核查，但如果你在「管理」一个 agent，这怎么可能？你没法在 LLM 搞砸时让它担责。「还是说人们真的在纯 yolo、连生成的代码是否正确都不验证？我知道这是个梗，但在真有后果的地方，人们真的在照着这个梗做吗？」
collinmcnulty 引出制造业支线：他完全预期软件业将无法从（几乎）所有其他行业学到「当你的边际成本不再为零时该如何运作」；让他抓狂的是软件圈有多少人以为其他行业慢是因为「他们没我们聪明」，而不是因为一个铸件要几个月才能做出来，所以最好一次就做对。kristianc 引他建筑业朋友的话：「混凝土橡皮擦很贵。」这条线随后展开成一场颇为专业的辩论：random3 主张 SLS/增材制造正在改变游戏（举 Formlabs 新推的 8 万美元工业级机器优于 50 万美元替代品、Tesla 和乌克兰在用、Divergent 在洛杉矶打印汽车引擎并融资 2.9 亿美元、SpaceX 和印度 Skyroot 打印火箭引擎），而 buildsjets 以真实项目数据反驳：他设计过一个约 16”x8”x10” 的航空零件，需要 12 件以内时用 AlSi10Mg 粉末床熔融（PBF）最便宜，但因 3D 打印铝的机械性能较低要付 25% 的重量代价；12 到 50 件之间最便宜的是用 3D 打印做蜡模再用 A356 做传统熔模铸造；超过 50 件则投永久闭式模具最省——「除了原型和极低量产，增材在真实制造里基本是彻底失败，完全没兑现任何宏大承诺」；他还纠正对方把 FDM（塑料工艺）与替代金属铸造混为一谈。
spicyjpeg 给这条线补了一个软件业自己的历史：不久之前，软件业相当大一块确实要面对压 CD、印包装、赶假期档期发到零售商的现实；「把一个半成品直接发给终端用户、还收钱、并承诺它会慢慢变好（但前提是你能在此期间融到足够 VC）——这是个相对新的发明」。louthy 用亲历补充：90 年代到 2000 年代初在游戏业，把游戏送过索尼测试难得离谱，因为黑盘一旦刻出来就没有更新的办法，「第一版就必须一次到位」。
「软件工程师算不算工程师」支线里最值得记的是 arthurjj 提供的数据点：几年前有位软件工程师问过一批化工/土木/机械工程师，多数「真正的」工程师认为软件工程师算（引 Hillel Wayne 的《Are We Really Engineers?》）。robocat 给出了最有力的解构：这是个稻草人论证，因为大多数工程师也不是工程师——绝大多数工程师对自己的烂活没有后果，认证也不是防止坏工程师的万灵药；他举了看机械工程师设计塑料垃圾、电子工程师设计不工作的电路、岩土工程师按小时收费编造过度规格的例子，并以基督城地震中一栋大楼倒塌为例说明即使有恶劣设计失误，工程师也常常安然无事。defrost 补上了这个案例的完整细节：CTV 大楼号称按 80 年代初规范建造，是非延性钢筋混凝土结构；皇家委员会调查发现官方结构设计公司（Alan Reay Consultants）、实际做设计的工程师（David Harding）与现场施工的「工程师」（Gerald Shirtcliff）之间缺乏沟通，而 Gerald Shirtcliff 的工程学位是伪造的；尽管如此大楼通过了验收并屹立 25 年，倒塌前一年还在两次地震后通过了两次额外检查。警方想以过失杀人起诉 Harding 和 Reay，基督城皇家检察官认为证据充分，但副总检察长认为难以证明「若无这些已识别的设计错误，CTV 大楼就不会倒塌」。robocat 的结论是认证和法律都是无牙的，真正需要的是对不负责任的管理者和责任人施加严厉刑责，公司也不该躲在有限责任后面，「认证是给替罪羊用的」。
几条精炼的短评：FrankWilhoit 说作者引 Brooks 证明沟通摩擦随人头平方增长，但指数根本不需要恰好或接近 2，1+ε 就已经是致命的，这与 Coase 的天花板密切相关。LorenPechtel：「没人因为拒绝新玩意而获得奖赏，即使那个新玩意应该被拒绝——就像科学论文严重偏向不报告零结果。」eadwu 给出了一个结构性解释：这不是工程师独有的问题，而是内嵌在当今体系里——做一个博学者难得离谱，你不可能不重新发明一个你根本不知道其存在的东西；而软件恰好能嵌进所有其他领域，这让它成为一个「非常好」的、用来获取那些早已在别的领域以别的名字被发明过的概念的底座（他称之为「现代盗版博学者」）。dwheeler 一句叹息：「大多数人类都会为了不从历史中学习而无所不为，工程师只是一个例子。」saltysalt 更短：「另见：人。」skydhash 提出了作者的盲区：《人月神话》和《Making Things Happen》处理的是团队层面的管理侧，《程序员修炼之道》是个人层面，「但这篇文章忽略了真正的工程那一侧——你得跟一堆原语搏斗，把它们组装成能产生价值的东西，而且要以划算的方式；这部分总是被挥挥手带过」。elktown 补了一个他最近观察到的恶习：「把自己原有的宠物方法论硬挂到 AI 热潮的车上，当成某种个人平反的狂欢。」satvikpendem 则给这场元讨论定了性：「一个关于一条 HN 评论所引发的文章的评论区。我们还能再递归下去。」