AI 智能体承担开发工作后，工程师还需掌握哪些能力

CI 失败了，这出乎意料。我已经把自己的智能体工作流调校到这样的程度：如果我的某个智能体提交了测试未通过的分支，我反而会感到意外。也许是 CI 偶发故障或环境问题？等等，是 SonarQube 在抱怨 App.tsx？还是我们从 npm 引入了新的可疑依赖之类的？不是。SonarQube 因圈复杂度标记了这个文件。这种问题我已经有一阵子没见过了。

没错。App.tsx 大约有 30 行代码，只不过其中 15 行实际上是完整组件，而 Codex 决定把每个组件都写在一行里。这本身倒没问题，只要通过 prettier 处理一下就完事了。但这解释不了圈复杂度的问题。这些组件每个都相当复杂，包含大量展示逻辑和业务逻辑。过去的我会仔细重构它，并确保代码易读。另一方面，Codex 不在乎完整组件被写在一行里，更重要的是，它也不介意这种复杂度。在开发多个功能的过程中，它一直开心而稳定地迭代着那个文件。

CI 工具标记了一个问题——也许这个问题确实存在，也许并不存在。但这是一个真实运行的系统，所以我必须深入调查。格式化这些文件后，我逐一检查了各个组件和逻辑。Codex 在覆盖边界情况方面是否超出了典型开发者通常会做的程度，又是否有些过度设计？答案是肯定的，但一切都正确。我完全没有意见。所有这些复杂度都是业务需求所必需的。于是我让 Codex 把 SonarQube 哄高兴，它通过重构并将内容拆分到 10 个文件中做到了这一点。CI 通过了；功能上线了。尽管这次具体事件很快得到了解决，但你大概可以想象，它原本可能会糟得多。说到底，那是我此前从未见过的代码。

这就是我们行业将要走向的方向：负责一个软件系统，将不再那么依赖亲手编写过它（或类似系统）；相反，最重要的将是恰好掌握足够的知识，以判断什么时候出了问题，并在需要时愿意且能够深入到必要的程度。

潜水机器人与金块

想象一下，你正坐在一艘船上（船型由你决定），而你的工作是从海底收集小金块。直到不久前，如果你想装满一袋黄金，就得跳进水里，游到海底，四处张望，然后把袋子塞满。如果是在清澈的浅水区，这很容易；但你可以想象，情况很快就会变得困难得多。因此，随着浅水矿区开始枯竭，你和其他工程师建造了各种机械和工具，以便从越来越深、越来越危险的水域开采黄金。多数情况下，这种方式效果很好：你会和团队谨慎地组装、维护并轮换使用这些机械，还会不断潜到海底采矿作业点，维持其运转。时不时，你会听说某个采矿作业发生坍塌，有时是因为巨大的水下压力，有时则是由于事故或操作人员能力不足。挑战在于，这是一个地质活动非常活跃的世界，因此海床一直在变化，一些矿区逐渐枯竭，新的矿区则在不同地方不断出现。

好消息的是！过去几年里，人们开发出了越来越精密的潜水机器人，它们能够潜入海底，自行建立采矿作业。你只要告诉它们在哪里建造，它们就会下潜，只在浮出水面时向你汇报最新进展并带回金块。如今一切都很美好：你可以躺在船上休息，让潜水机器人忙活，而你要操心的只有能在船上装多少黄金。这就是乐观派阵营。

直到……

“等你的潜水机器人潜得太深而迷路吧。”“哈哈，你的潜水机器人带回了一些看起来像黄金的东西，但其实只是闪亮的章鱼粪便。”随着潜水机器人不断增多，你也看到了越来越多的恐怖故事：潜水机器人迷路了，忘记了自己应该建造什么；潜水机器人建造出极其复杂而怪诞的工程，以至于它们自己都难以维持，最终却被下一代潜水机器人弃置。所有水下采矿作业都从精心设计和建造的大教堂，变成了更像是随意拼凑的宅邸，里面藏着秘密通道和潜伏的恐怖事物。你与采矿作业越脱节，失败就越惊人。这就是怀疑者阵营。

此处有怪物

软件工程行业（而且我怀疑很快许多其他行业也会如此）正在经历上述情形的一个版本。你可能已经知道自己更适合被称为怀疑者还是乐观者，即便你仍不确定自己最终想加入哪一阵营。

传统观念是，要开发并维护一个并不简单的系统，你必须对它有一个恰当的工作模型。我认为很少有人会对此提出异议。在软件工程中，你会通过直接处理代码来获得这种工作模型。多年乃至数十年的编写和阅读代码的实践，会让你获得理解自己负责的系统所需的知识和工具。每一次生产事故、每一个深夜调试会话、每一次成功发布。所有这些经历都会给你所需的视角，使你对一个系统拥有主人翁意识。在本文的语境下，主人翁意识是指出了问题时被叫来的人就是你。

智能体（divebots）正在把这一切彻底颠倒过来。Divebots 产出内容的速度远超任何人的消化速度，而在过去复杂系统中，你可以假定代码至少曾经经过人类之手，如今这一假定已不再成立。现在，有经验的从业者可以管理 divebot 集群，并以空前规模创建软件。这些操作员掌握这门技艺，并运用他们丰富的经验来管理和设计大型系统，而过去构建这些系统需要一支团队。但这暴露了我们这个行业可能面临的最大挑战：我们该如何培养下一代工程师？

在两个极端，乐观派和怀疑派对这个问题有着截然不同的答案。一方面，一些颇具公信力的声音认为，要对这些系统保持掌控，唯一办法就是阅读 divebots 生成的每一行代码。要能亲手编写这些代码。要能解释每一段代码的作用，以及它如何与应用的整体语境相契合。另一边，同样颇具公信力的声音则建议干脆不要查看代码。把精力放在思考该构建什么上，而不要管它是如何构建的。模型会处理好这一切。我认为这两种说法都不对。

事实是，如今资深工程师习得技能的方式——例如亲手编写代码、花无数小时调试、经历生产事故等——对于今天的初级工程师而言已经不是一条可行路径。明确地说，它在经济上不可行，也就是说，公司极不可能愿意多年资助初级工程师，让他们“学会亲手完成”。这是痴心妄想。另一种经常被提出的建议是“确保你理解智能体编写的每一行代码”，或者“与资深工程师结对”，又或者“进行细致的代码审查”。同样，除了或许少数几家公司之外，这都只是痴心妄想。如果你认为整个行业都会采用这些做法，我这里有座桥要卖给你。联系我吧。

为了找出一条可行路径，以达到某种程度的精通，我们必须先弄清楚，负责一个并不简单的软件系统究竟意味着什么。想想典型的架构师/负责人/CTO 以及他们的工作方式，就会明白：要想取得成功，他们需要在脑海中建立一个系统模型，一张海图。真正的问题在于粒度达到什么程度？想象一个包含 1-million 行代码的遗留代码库，多年来由许多人编写并扩展。CTO 甚至可能编写过其中一部分。现在想象线上出现了故障，而你是不幸的那个 SRE，正试图在 2AM 解决问题，同时还收到来自不同时区的人的愤怒短信。你需要怎样的系统地图？你需要一张高层次、从远处审视整个系统的地图，而且需要知道刚好足够的信息，以便知道该在哪里深入、怪物在哪里出没；你还需要能够进入任何陌生的代码库，弄清发生了什么，推送热修复，并在事故报告中清楚说明发生的一切。

请注意，这不是对整个系统的详尽了解。我们管理复杂系统的唯一方式，是逐层建立抽象。每一层都让我们能够再构建一些内容，但无论你手中有什么地图，都要记住，从上到下全都是抽象，没有人真正理解所有层级。“我编写了模块 X，并且对它了如指掌”与“我拥有关于系统抽象的恰当模型，能够深入任何模块，并在其发生故障时加以修复”之间，有着天壤之别。手写代码能让我们获得前者，但系统负责人，也就是那个被叫来解决问题的人，需要的是后者。

那么，这幅图究竟是如何构建出来的？如果一个人从未亲手淘过金子，又怎能指望他潜入未知水域，修复 divebots 制造的烂摊子？

基础、广度与即时深度

复杂系统中一些最阴险的故障是静默故障。就是那种系统大体运转正常，但总有些不对劲的地方。也许它突然变慢了，或者错误率升高了，又或者大多数时候运行完美，却每逢第19次尝试就会失败。还没有严重到2AM会把你叫起来响应的程度，但足以让你感觉哪里出了偏差。作为系统的负责人，你需要了解系统的故障模式。作为一个行业，我们有工具可以教人们如何检测并分析这些故障：基础知识。好消息是，几十年来，我们一直在把这些知识教给对此毫不知情的计算机科学专业学生。我说的是数据结构和算法、网络、并发、分布式系统等。这些内容不一定非得来自正规教育，它们都是你可以自行阅读和学习的主题。

为了勾勒一幅简单的图景（如果是资深工程师，请在这里多多包涵），想象一下你派潜水机器人执行一项任务。你身处浅水区，派它下潜2m采集一些金块。它4s就回来了，一切正常。下一次，你让它下潜4m。这一次却花了16s。这很奇怪。下一项任务是下潜16m，用了256s。你明白了。显然有什么地方不对劲。在计算机科学中，这称为平方复杂度，而识别它最好的办法，大概是理解相关理论，并知道这种现象确实存在。

这就引出了主人翁意识的下一个支柱：广度。我合作过的大多数优秀工程师和工程领导者，几乎都能就任何话题展开讨论，无论是否与技术有关。他们可能是某些领域的专家，但最令人印象深刻的是，他们能够调用并串联起来自不同学科、看似毫无关联的概念，并利用这些知识解决问题。这就是水域的高层地图。它能告诉你哪些海域比其他海域更危险。知识的广度让你能够说“就在这里下潜吧”。明确一点，我并不是说要在每一个能想到的领域都具备专家级知识，而是只要知道出现异常时该查找什么即可。这些就是指引海洋探索的浮标。

有人问我：“我们要如何培养广度？开一门涵盖一切的概论课吗？”当时我没有给出令人满意的答案。但后来又深入想了想，我觉得这似乎不是能够通过教学培养的能力。不存在一门你可以选修的“万物101”。我们所能做的，无非是鼓励大家阅读、探索、保持好奇，尽可能多地吸收信息。记住那些离奇的事件、那些“糟了”的时刻，思考它们与你的工作有何联系。随着经验不断增加，有意识地努力把日常经历与工作联系起来。我已经记不清有多少次，多年前参与某个临时项目时学到的那一点知识，在关键时刻挺身而出，挽救了局面。这种经验和广度会不断累积放大，但必须持续维护。

主人翁意识的最后一根支柱，是我所谓的即时深度。这是一种深入钻研任何问题并找出答案的能力与意愿。即使身处未知水域，即使必须钻进潜水笼，与鲨鱼共游一阵，即使必须召集团队，登上那艘像样的大型潜水艇，下潜越过巨型鱿鱼，只为查清系统出了什么毛病。这就是为了完成工作而愿意学习一切所需之物的意愿。它也意味着一种谦逊：知道何时下潜已经超出自己的能力，需要寻求帮助。并非每次下潜都能独自完成；也并非每次下潜都值得进行。

几个月前，我在开发自己的智能体编排器时，智能体和子智能体不断出现稳定性问题和生命周期 bug。我知道自己希望它们做什么，但构建这个系统的潜水机器人做得相当随意，所有 bug 一下子都找上门来。我坐在那里盯着屏幕，看着智能体在一小时内第 n 次崩溃；在几次让潜水机器人收拾自己的烂摊子却未能成功之后，我想起多年前读过的一本 Kubernetes 书籍（没错，我是个书呆子），而“电平触发状态机”这几个字突然浮现在我眼前。于是我进行了一次下潜，比原本计划的还要深，甚至一路追溯到“电平触发”的电气工程起源。我还带上潜水机器人一路同行，从头重新设计了核心架构。从那以后，它一直坚如磐石。这次成功的重写主要得以实现，是因为我恰好记得多年前读过的一些内容，而且愿意一头扎进去，学习完成工作所需的一切。

于是，你从一张海洋（系统）的高层地图入手，并明白它由一层层抽象构成，一直延伸到最底层。既然所有这些抽象都会泄漏，那么作为系统负责人，你要知道该在哪里下潜、下潜多深。这已经不再是通才与专才之分，甚至也不是传说中的 T 型人才。

![](https://cdn.hashnode.com/uploads/covers/69b44e3d6e27dd07d92bbf57/9271e637-61b4-4664-b79c-7d413e2f3e8c.png align="middle")

构建事物的全新方式，需要一个能够深入未知领域的通才，需要成为“压力下的快速学习者”，而不是靠简历包装出来的快速学习者。你真正需要具备的，是一边与海怪搏斗，一边快速学习的能力。这些年来，我面试过许多人；当人们在简历中写上“快速学习者”时，我往往会请他们讲讲一次不得不迅速学会复杂系统的经历：他们是怎么做的？你的答案会是什么？

未来的主人翁

所以，基本功可以习得，广度可以拓展。然而，即时深度可以靠实践磨炼。正是这三根支柱，让一个人能够在系统中承担更多责任。也许你从浅水区起步，把潜水机器人派下潜去。你有扎实的基本功和不错的广度，那就去构建些什么。只是要做好准备：一旦出了问题，就穿上潜水服，与怪物共游。

未来将由谁负责大规模海底采矿作业？没人知道，但我敢打赌，将是那些能够运用上述三大支柱的人。它会是这样一个孩子：他拆开一台旧收音机并将其修好，却对收音机一窍不通，只是出于想听音乐的愿望——即使最后把所有零件装回去时，确实还多出了几颗螺丝。