200年前的蒸汽机工人，其实早就预言了今天程序员的命运。

春春欲动

200年前的蒸汽机工人，其实早就预言了今天程序员的命运。


最近看到一篇很有意思的文章，作者在读 OpenAI 关于“线束工程”（Harness Engineering）的博客时，突然意识到一件事：这个模式他见过，不止一次，而是三次。

这三次跨越了两百多年，但本质上讲的是同一个故事。

1、第一次：瓦特的离心调速器

故事要从 1780 年代说起。那时候蒸汽机刚开始普及，但有个麻烦事：需要有个工人一直站在旁边，盯着机器的转速，手动调节阀门。转快了就关小点，转慢了就开大点。这活儿累人，还需要经验和注意力。

后来詹姆斯·瓦特发明了离心调速器。这东西的原理很简单：两个重球随着机器旋转，转得快了，球就甩得高，带动阀门关小；转得慢了，球就落下来，阀门自动开大。整个过程不需要人干预。

那个站在旁边调阀门的工人消失了吗？没有。他的工作变了：从手动调阀门变成了设计和维护这个调速器。

2、第二次：Kubernetes 的控制器

时间快进到现代。如果你接触过云计算，可能听说过 Kubernetes 这个东西。它的核心思想也是类似的。

你告诉系统一个“期望状态”：我要三个副本，用这个镜像，分配这么多资源。然后系统里有个控制器会不停地观察“实际状态”。一旦发现不一致，比如某个服务崩溃了，控制器就自动修复：重启服务、调整副本数量、回滚有问题的部署。

工程师的工作又变了：从手动重启服务变成了编写系统自动执行的规则。

3、第三次：AI 写代码

现在轮到第三次了。OpenAI 在博客里描述了一种新的工作方式：工程师不再自己写代码，而是设计环境、构建反馈循环、制定架构约束，然后让 AI 代理来写代码。

五个月时间，一百万行代码，没有一行是人手写的。他们把这叫做“线束工程”。

作者说，每次看到这个模式，都是因为有人造出了足够强大的传感器和执行器，能够在那个层面上闭合反馈循环。

瓦特的调速器能感知转速，能调节阀门。Kubernetes 的控制器能感知服务状态，能重启和扩容。而大语言模型能感知代码质量，能重构模块、重新设计接口、改写测试套件。

这就是控制论的本质。1948 年，数学家诺伯特·维纳给它起了个名字：Cybernetics，来自希腊语κυβερνήτης，意思是“舵手”。你不再亲手转动阀门，你只需要掌舵。

4、闭环是必要的，但还不够

但是，光有闭环还不够。瓦特的调速器需要调校，Kubernetes 的控制器需要正确的配置，而让 AI 在你的代码库上工作，需要提供更难的东西。

让基础的反馈循环运转起来，这只是起点。测试要能让 AI 运行，CI 要能输出可解析的结果，错误信息要能指向修复方向。Anthropic 的研究员 Carlini 演示过这一点：他让 16 个并行的 AI 代理构建了一个 C 编译器，用的提示词简单到令人尴尬，但测试基础设施设计得非常精心。他说：“我的大部分精力都花在设计 Claude 周围的环境上，测试、环境、反馈。”

更难的问题是用你系统特有的知识来校准传感器和执行器。这是大多数人卡住的地方，也是他们责怪 AI 的地方。

“它总是做错事。它不理解我们的代码库。”这个诊断几乎总是错的。AI 失败不是因为能力不足，而是因为它需要的知识，也就是对你的系统来说什么是“好”，你的架构鼓励哪些模式、避免哪些模式，这些知识都锁在你脑子里，你没有把它们外化出来。

AI 不会通过渗透学习。如果你不把规则写下来，它在第一百次运行时犯的错误和第一次一模一样。

5、把判断变成机器可读的

真正的工作是把你的判断变成机器可读的。写架构文档，描述实际的分层和依赖方向。写自定义的代码检查工具，把修复说明嵌入进去。写黄金原则，编码你团队的品味。

OpenAI 发现了同样的问题：他们一开始每周五要花 20% 的时间清理“AI 垃圾”，直到他们把标准编码进线束本身。

这些实践，文档、自动化测试、明确的架构决策、快速的反馈循环，其实一直都是正确的。过去三十年写的每一本工程书都推荐它们。大多数人跳过它们，因为跳过的代价是缓慢而分散的：质量逐渐下降，入职很痛苦，技术债务悄悄累积。

但 AI 工程让这个代价变得极端了。跳过文档，AI 就会忽略你的约定，不是在一个 PR 上，而是在每一个 PR 上，以机器的速度，全天候运行。跳过测试，反馈循环根本闭合不了。跳过架构约束，偏移的速度比你修复的速度还快。

这里有个陷阱：如果 AI 不知道什么是“干净”，你就没法用 AI 来清理混乱。没有校准，制造问题的机器也解决不了问题。

这些实践没有变，忽略它们的惩罚变得无法承受了。

6、生成和验证的不对称

作者提到了一个计算机科学里的经典问题：P vs NP。简单说就是，生成一个正确的解决方案，比验证一个解决方案是否正确，要难得多。

这个不对称指向了未来的方向。你不需要在实现上超过机器，你需要在评估上超过它：明确什么是“正确”，识别输出哪里不对，判断方向是否对头。

这让我想起很多工作的变化轨迹。以前的摄影师需要精通暗房技术，知道怎么冲洗胶片、调整曝光。现在的摄影师更多的是在构图、光线、情绪上下功夫，技术处理交给了软件。技能的重心从“怎么做”转移到了“做什么”和“做得好不好”。

设计瓦特调速器的工人没有回去转阀门。不是因为他们不会，而是因为那样做已经没有意义了。

7、这对我们意味着什么

这个故事给人的感觉很复杂。一方面，它确实让人有点不安。当机器能做越来越多的事情，人的位置在哪里？另一方面，它又揭示了一个更深层的真相。

每一次技术进步，人的工作都在往上移一层。从手动操作到设计规则，从执行任务到制定标准，从写代码到定义什么是好代码。这个过程不是替代，更像是解放。

但这种解放有个前提：你得能把脑子里的知识、经验、判断，用某种方式表达出来，让机器能理解。这其实是一种更高级的能力。

很多时候我们觉得自己“懂”，但真要说清楚为什么这样好、那样不好，就说不出来了。这种隐性知识在人和人之间可以通过长期合作慢慢传递，但机器不会通过观察学习，你必须把它明确化。

这也解释了为什么有些人能很好地和 AI 协作，有些人却觉得 AI 总是“不听话”。差别往往不在 AI 本身，而在于你有没有能力把自己的标准清晰地表达出来。

从这个角度看，文档、测试、规范这些东西，以前可能是“最好有”，现在变成了“必须有”。不是因为它们本身变了，而是因为不做的后果从慢性病变成了急症。

还有一点值得注意。作者说，你不需要在实现上超过机器，你需要在评估上超过它。这其实是在说，未来的核心竞争力可能不是“做”，而是“判断”。

判断什么是好的，什么是对的，什么符合更大的目标。这种能力机器可能永远学不会，或者说，只能从你这里学。

8、掌舵的人

回到那个希腊词：κυβερνήτης，舵手。

舵手不需要划桨，不需要扬帆，甚至不需要知道风是怎么吹的。舵手需要知道的是：要去哪里，现在在哪里，怎么调整方向。

从瓦特的调速器到 Kubernetes，再到 AI 写代码，这个模式重复了三次。每一次，人的角色都从“操作者”变成了“设计者”，从“执行者”变成了“掌舵者”。

技术在变，但有些东西没变。你需要知道目标是什么，你需要能判断结果好不好，你需要能把这些判断标准清晰地表达出来。

这可能就是未来工作的样子。不是人和机器竞争谁做得快，而是人定义什么值得做，机器负责做出来，然后人判断做得对不对。

循环闭合的地方，就是重要决策发生的地方。而那个地方，现在依然需要人。

##