Hacker News 中文摘要

RSS订阅

工程师们会不惜一切代价避免从历史中学习 -- Engineers will do anything to avoid learning from history

原文链接 | HN讨论 | 2026-08-16 08:19:17

文章摘要

文章指出工程师常忽视历史教训，将AI管理类比为领导团队，却不愿阅读手册。作者批评这种习惯，并以数据科学为例，说明所谓新领域实为旧知识换名，强调学习历史的重要性。

文章总结

好的，这是根据您的要求，对原文进行的中文重述：

标题：工程师们为了不学历史，什么都干得出来

工程师们正在形成一种（基本正确的）直觉：管理多个AI智能体就像管理工程团队。这让我很担忧，因为工程师有个最糟糕的习惯：没人愿意读说明书。

这种现象早有先例。数据科学领域就是如此。工程师们花了多年时间建立一套技术基线，仿佛在开拓新领域。但这根本不是新领域，它只是换了个酷名字的统计学。虽然推动领域前进的人明白这一点，但大多数人并不清楚其中的数学原理早已存在。类似地，加密货币领域也重演了金融史，有时有趣，但更多时候是灾难性的。我们甚至重新发明了公交车站。

工程师们这么做有一些合理原因：对现代软件出现之前的传统领域不信任，以及从第一性原理出发学习可能带来更深的理解。但也有不那么正当的理由：把旧东西包装成新颖的能赚钱，以及“这能有多难？”

正是这些不正当的理由促使我写这篇文章。当我读到关于如何管理AI智能体的文章时，我仿佛看到了未来。那些从未认真对待过测试驱动开发或产品需求文档的工程师，现在发现必须提前定义每个行为，否则AI会猜错并构建错误的东西。那些抱怨非技术型工程经理不懂技术的工程师，现在意识到自己根本懒得去读AI生成的万行代码审查。突然之间，瀑布模型成了最佳实践。

但工程师们大概不会称之为瀑布模型或项目管理。他们会给它起个更性感的名字，重新发明一遍轮子。也许用旧名字就等于承认管理者是对的。或者他们根本不知道瀑布模型是什么了，毕竟很久没人正面提过它了。我怀疑大多数人不知道温斯顿·罗伊斯是谁，也没读过他的论文。即使是工程师们拒绝的流程，他们也是在并不真正理解的情况下拒绝的。

然而，项目管理正是智能体编排的全部内容：确保需求文档完善，确保这些需求确实是当前最重要的工作以免浪费宝贵的令牌和时间，创建清晰的工作路径，建立流程以确保产出物符合所有标准。智能体运行时间越长，就越需要它们定期汇报进度。这种仪式有个名字，工程师们已经争论了十五年它的时长、参与者以及是否值得花时间。

所以，我恳请正在思考这些问题的工程师们，为自己和行业省点时间，从历史中学习一些东西。以下是一些我认为很可能适用于AI管理的书籍：

  • 《搞定事情》和《项目管理知识体系指南》：可以说是项目管理的操作手册。
  • 《人月神话》：关于沟通成本如何随人数呈二次方增长，以及启动十个智能体将面临的挑战。
  • 《大型软件系统的开发管理》：描述了大多数AI编码者可能正在做的瀑布模型，为什么它不好，以及该怎么做。这是一份12页的PDF，网上很难找，但值得一读。
  • 《高产出管理》：我还没读过，但在我的书单上。它可能不是最直接适用的，但解读空间最大。
  • 《目标》：关于优化非瓶颈会发生什么。这是“理解是新的瓶颈”这类书的鼻祖，约束理论就来源于此。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 软件工程中的“重新发明”现象

    • 评论指出，软件工程师常因追求新颖性而忽视历史经验，导致重复发明（如“reinventing bus stops”）。
    • 关键引用：
      • “You can make lots of money by making something appear novel and undiscovered...”（Avicebron）
      • “Most HUMANS will do anything to avoid learning from history. Engineers are merely an example.”（dwheeler）

  2. AI代理管理与传统工程管理的差异

    • 部分评论认为，管理AI代理（如LLM）与传统工程管理有本质区别，需关注token使用、漂移避免等新维度。
    • 关键引用：
      • “Managing agents has some similarities with EM... but a whole lot of other dimensions like token use, avoiding drift...”（Areading314）
      • “You can’t exactly hold an LLM responsible if it fucks something up.”（slopinthebag）

  3. 对“工程师”定义的争议

    • 评论批评软件工程师缺乏真正的工程思维（如学习失败经验），并质疑其职业定位。
    • 关键引用：
      • “Actual engineering is all about learning from past failures”（ThrowawayTestr）
      • “Most Software Engineers aren’t Engineers, they’re computer science majors.”（cush）

  4. 管理方法论与AI的适配性

    • 部分评论支持采用瀑布模型或PRD等传统方法管理AI代理，但反对机械照搬。
    • 关键引用：
      • “Suddenly, waterfall is the thing to do... 90% of the work is the spec.”（bthornbury）
      • “I wouldn’t take the advice to follow waterfall or PMBOK literally.”（mpyne）

平衡性总结：
- 支持传统方法者：强调历史教训（如Brooks定律、Coase天花板）和结构化流程（如PRD、瀑布模型）的重要性。
- 反对者：认为AI代理管理需全新框架，传统方法无法应对其独特挑战（如token成本、漂移风险）。
- 中立观点：指出“重新发明”源于认知局限或行业激励（如VC补贴、追求新颖性），而非单纯技术问题。

关键争议点：
- 软件工程师是否应被视为“工程师”？
- AI代理管理能否套用传统工程管理经验？
- 行业是否过度追求“新颖性”而忽视基础原则？