Agent 写完的代码没人读过：出事时你该潜多深

CI 挂了。这不该发生——作者 Adrian Quiroga 已经把 agent 工作流调到自己会惊讶的程度：他的 agent 提交的分支几乎不可能带着失败的测试。是 CI 抖动，还是环境问题？

结果是 SonarQube 在对 App.tsx 报圈复杂度。这个检查项他很久没见过了。

那个文件大约 30 行，其中 15 行每一行就是一个完整组件——是 Codex 决定这样写的。这本身还好，跑一遍格式化就完了。但那解释不了复杂度告警：那些组件每一个都相当有内容，展示逻辑和业务逻辑都很多。换成以前的自己，会仔细重构成可读的形状；而 Codex 并不在意"整个组件挤在一行里"，更不在意复杂度——它已经在这个文件上愉快而稳定地迭代了好几个功能。

CI 工具报了个问题，可能对也可能错。但这是真实系统，所以他必须下水。格式化之后，他逐个检查组件和逻辑：Codex 在边界情况的覆盖上确实超出了普通开发者的水平，也确实有点过度设计——但都对，复杂度是被业务需求撑起来的。于是他让 Codex 去把 SonarQube 弄满意；Codex 重构、拆成 10 个文件，CI 过了，东西上线。

这次解决得很快。但他补了一句：你可以想象它本来会糟得多——毕竟这是他从没读过的代码。

而这正是行业正在走的方向：拥有一个软件系统，将越来越少取决于你亲手写过它；真正重要的是"刚好够"——够到能判断哪里不对，以及愿意也有能力在需要的时候潜到需要那么深。

一、潜水机器人，与金块

想象你在一条船上（船的类型由你决定），你的工作是从海底捞金块。

直到不久之前，你想要那袋金子，就得自己跳下去、游到底、四处看看、把包装满。在清澈的浅水里这很容易，但你可以想象它会多快变难。随着浅水的矿挖完，你和同行们造出各种机械和工具，去更深、更危险的水域开采。大部分时候这行得通：你和团队仔细装配、维护、轮换这些机器，并不断亲自下潜到海底的作业点维持它运转。你偶尔会听说某处矿难——有时是水压，有时是事故，有时是操作者的无能。

麻烦在于，这是个地质活动极其频繁的世界：海床一直在变，一些矿枯了，新的矿在别处长出来。

好消息是：最近几年出现了越来越精巧的潜水机器人（divebots）。你只要告诉它去哪儿建，它就潜下去，只在上来汇报进度、交金块时浮出水面。于是你可以躺在甲板上放松，唯一需要操心的是船能装多少金子。

这是乐观派阵营。

直到……

"等你的潜水机器人潜得太深、迷路了你就知道了。""哈哈，你的潜水机器人带回来的东西看着像金子，其实是发亮的章鱼屎。"

随着机器人越来越多，恐怖故事也越来越多：机器人迷路、忘了自己要建什么；机器人建出复杂到它自己都维护不了的怪物，然后被下一代机器人丢弃。所有海底作业从精心设计的大教堂，变成了到处是暗道和潜伏怪物的杂乱豪宅。你离作业越远，失败就越壮观。

这是怀疑派阵营。

二、这里是怪物出没的地方

软件工程行业（他怀疑很快还有很多其他行业）正在经历上面这个剧本的某个版本。你可能已经知道自己更像怀疑派还是乐观派，即使还没决定要站哪边。

传统智慧是：要开发和维护一个不平凡的系统，你需要在脑子里有一个像样的工作模型。这点恐怕很少有人反对。而在软件工程里，你通过直接和代码打交道获得这个模型。多年、几十年的写和读，给了你理解自己所负责系统所需的知识和工具。每一次生产事故、每一次深夜调试、每一次成功发布，都给你"拥有"一个系统所需的视角。

在这篇文章的语境里，拥有（ownership）的意思是：东西坏了，被叫起来的人是你。

而 agent（潜水机器人）把这一切翻了过来。

机器人产出东西的速度远快于任何人吸收的速度。在过去复杂的系统里，你可以假定代码曾经经过某个人的手；现在这个前提不再成立。 有经验的从业者可以管理一支机器人舰队，以空前的规模造软件——这些操作者懂手艺，把可观的经验带进架构和管理，做出过去需要一整个团队才能建的系统。

但这暴露了行业最大的挑战：我们怎么培养下一代工程师？

在这件事上，乐观派和怀疑派在极端处的答案截然相反：

• 一边（同样有名望的声音）：要维持对这些系统的控制，只能逐行读机器人写的代码。你必须能手写出来，必须能解释每一段代码在做什么、在应用上下文里处在什么位置。
• 另一边（同样有名望的声音）：别费劲看代码了。 把精力放在想清楚要建什么，别管怎么建——模型会处理。

他认为这两种都不对。

事实是：今天的高级工程师学东西的方式——手写代码、无止境的调试、生产事故——对今天的初级工程师不是一条可行路径。 说清楚点：不是经济上可行。公司几乎不可能愿意出钱养一个初级工程师好几年，就为了让他"学会手工做这件事"。那是一厢情愿。

另一种常被拿出来的建议是"确保你理解 agent 写下的每一行""和高级工程师结对""做仔细的代码评审"——同样是一厢情愿，除了少数几个团队以外。他半开玩笑：如果你认为整个行业会采用这些做法，我这有座桥想卖给你。

三、下水之前，先问：你需要的是一张什么地图

要找到一条能让人达到某种熟练度的可行路径，得先看清"拥有一个不平凡的系统"到底意味着什么。

想想你常见的架构师/技术负责人/CTO 是怎么工作的：他们要在脑子里有一个系统的模型，一张海图。真正的问题是——要多细的粒度？

想象一个一百万行的遗留代码库，多年来被很多人写过、扩过，CTO 可能也写过其中一部分。现在出了生产事故，你是那个倒霉的 SRE，凌晨两点一边排查一边收着不同时区发来的愤怒消息。你需要一张什么样的图？

你需要一张高层的、拉远的全系统地图，加上"刚好够"的知识：知道该往哪里潜、怪物住在哪里；并且能在任何陌生代码库里跳进去、搞清发生了什么、推一个热修、然后在事故报告里把经过讲清楚。

注意，这不是对全系统的细节知识。我们管理复杂系统的唯一方式就是不断堆抽象层。每一层让我们能再往上搭一点，但无论你手里是哪张图，都要记住：一层套一层的抽象，而没有人真的理解所有层。

"I wrote module X and know it inside out"和"I have an appropriate model of the system abstractions and can dive into any module and fix it when it breaks"——这两者之间有巨大的差别。手写代码给你的是前者；而系统的所有者、那个被叫起来的人，需要的是后者。

所以这张图怎么建出来？一个从没亲手捞过金块的人，凭什么能跳进陌生的水域，去修机器人搞出的烂摊子？

四、三根柱子：基础、广度、按需下潜

第一根：基础（fundamentals）。

复杂系统里最阴险的失败是安静的失败：东西大体还能用，但哪里不对劲。也许突然变慢了，也许错误率上去了，也许大多数时候完美但每第 19 次就失败。还没到凌晨两点把你叫起来的地步，但足够让你觉得不对。

作为系统的所有者，你必须理解这个系统的失败模式。作为行业，我们有教人识别和推理这类失败的工具：基础。好消息是，我们几十年来一直在教那些不太情愿的计算机专业学生这些东西——数据结构与算法、网络、并发、分布式系统等等。也不一定非要正规教育，这些主题你自己都能读、都能学。

举个最简单的例子（高级工程师请包涵）：你派潜水机器人下潜 2 米捞金块，它 4 秒回来，一切正常。下一次下潜 4 米，这次花了 16 秒。奇怪。再下一次 16 米，256 秒。你懂这个画面了——显然哪里不对。在计算机科学里这叫平方复杂度，而认出它最好的方式，是知道这套理论、知道"有这种东西存在"。

第二根：广度（breadth）。

他合作过的大多数成功的工程师和工程领导，都能就几乎任何话题聊上几句，技术或非技术都行。他们可能是某些方面的专家，但最让人印象深刻的是：能从不同学科里抽出看似不相关的概念、编织起来解决问题。

这就是那张高层海图。 是它告诉你某些海域比别处更危险，是它让你能说"我们从这儿下水"。注意：不是每个领域都要专家级，只是刚好够知道出问题该去查什么——那些给你的远航当浮标的点。

有人问过他："广度怎么教？开一门什么都讲的概览课？"他当时没有好答案。后来想了想，他觉得这玩意教不了。没有一门"万物 101"可以选。能做的只是鼓励人去读、去探、保持好奇，尽可能多地吸收；记住那些奇怪的故障、那些"我靠"的瞬间，并思考它们跟你的工作有什么关系。经验越多，越要有意识地把日常经历和工作连起来。他说自己都记不清有多少次，是多年前在某个不相干项目里学到的一点点知识，突然回来救了场。

这份经验和广度会复利，但它必须被维护。

第三根：按需下潜（just-in-time depth）。

这是"愿意并且能够跳进任何一个问题、把它搞明白"的能力：哪怕是在没有海图的水域，哪怕得钻进笼子里跟鲨鱼一起游一会儿，哪怕得把团队叫上、开那艘正经的大潜艇、潜过巨型鱿鱼去看看系统到底哪里坏了。

这是"为了把事做完，愿意学任何需要学的东西"。也是那种谦逊：知道某次下潜超出你的能力，需要找人帮忙。不是每次下潜都能一个人完成，也不是每次下潜都值得做。

几个月前，他在做自己的 agent 编排器，遇到 agent 和子 agent 的稳定性与生命周期 bug。他知道他想让它们干什么，但造出这玩意的机器人当初干得比较随意，于是所有 bug 一起回家。他盯着屏幕看 agent 一小时内第 n 次崩溃，几次让机器人自己修自己的烂摊子都失败之后——突然想起多年前读过的一本 Kubernetes 的书（"是的我是个极客"），"level-triggered state machine"（电平触发的状态机）这几个字直接拍在他脸上。

于是他下去了，比他原本打算的更深，甚至一路潜到"level-triggered"在电子工程里的起源；他带着自己的机器人一起下去，把核心架构从地基重做。之后它就一直稳如磐石。

这次成功的重写，主要靠两件事：他碰巧记得多年前读到的一点东西，以及他愿意跳下去、学任何需要学的东西。

五、不再是 T 型人才

所以：你从一张高层海图（系统）开始，并明白它一路到海底都是层层抽象。而因为所有抽象都会漏，你作为系统所有者的工作，就是知道该往哪儿潜、潜多深。

这已经不是"通才 vs 专才"，甚至不是那个神话般的 T 型人才了。

图：原文的四类技能形状——专才（一根深柱）、通才（一条宽而浅的带）、T 型（宽带上加一根深柱）、所有者（宽带上有许多深浅不一的窄潜，最深那根标橙、末端是一艘小潜艇）。

新的建造方式需要一个能向未知深处下潜的通才，一个"压力下快速学习者"——不是简历上那种注水的说法。你是真的要在跟海怪搏斗的同时快速学会东西。

他面试过很多人。当候选人在简历里写"快速学习者"时，他喜欢问：讲一次你必须快速学会一个复杂系统的经历，你是怎么做的？

你的答案会是什么？

六、未来的所有者

基础可以学，广度可以攒，而按需下潜可以练。这三根柱子，就是一个人扩大自己"所有权份额"的方式。

也许你从浅水开始，把机器人放下去；你有扎实的基础、还过得去的广度，那就去建点东西——只是要在东西坏掉时，准备好穿上潜水服跟怪物一起游泳。

未来那些庞大的海底采矿作业由谁负责？没人知道。但他愿意赌：会是那些能同时挥动上面三根柱子的人。会是那种把一台旧收音机拆开又修好的孩子——他对收音机一无所知，只是想听音乐，哪怕装回去之后多出几颗螺丝。

七、我们的整理：把"该潜多深"变成可检查的五问

原文给的是心智模型，缺的是判据。我们把它的三根柱子落到日常可操作的位置，再回答几个它没有正面回答的问题。

一、三根柱子怎么在日常里练

（表格为我们整理，非原文内容。）

二、ownership 自检五问（十分钟内答不出，就说明你还不是 owner）

1. 这个系统最可能从哪里坏？说出三个具体的点，不要"都不好说"。
2. 坏了先看什么？指标、日志、还是某张表？
3. 回滚路径是什么？多快能回？回滚会不会丢数据？
4. 这个系统依赖谁的不变量？谁在替我们守它？
5. 最近的改动里，哪一处没人真正读过？（这一问最像原文。）

前四问是从"你是被叫起来的人"这个定义反推出来的；第五问是他这篇文章的核心——你没读过的东西，会以最贵的方式教你读它。

三、原文回避了的两个问题，我们给个答案

• "广度教不了"怎么办？ 原文说只能鼓励好奇。工程上可以更硬一点：把复盘做成资产。每次事故写三段（现象、真正的原因、如果重来我会先查什么），按时间轴存成可检索的库；新人入职先读 20 篇。这样广度不靠个人运气，而靠组织记忆。
• 初级工程师没有"手写"这条路怎么办？ 评论区已经有人给出更好的方案：在沙箱里故意埋故障，让新人去修 agent 写的代码——这恰好是"按需下潜"的可控练习。再配一条硬约束：新人第一个季度必须独立完成一次"陌生代码定位"（只定位不修改），并由 owner 复核他的推理路径。

四、评论区四个问题的摘要

• Kartik：level-triggered 很适合 agent 生命周期——只要每一轮都比较"应该在跑什么"和"实际在跑什么"，子 agent 崩了也不会因为退出事件丢失而被漏掉。他问：重构的时候，"期望状态"是放在 agent 能读的文件里，还是只在编排器内部？
• 另一位：SonarQube 那个故事说明，有用的技能是发现不对，不是写出修复。他建议把"探测器"显式化并与 agent 解耦：复杂度预算、依赖 diff 告警、关键模块的变异测试、以及一份 agent 改边界时必须更新的架构决策文件。他还问：是不是该让新人在沙箱里 debug 带种子的故障？
• Abhinav：问一个具体的小练习——怎么让新人在不是自己写的代码里练"找到正确的模块"？
• WIO：最扎心的一条——你之所以下水，是因为 CI 报警了。那么当没有任何报警、agent 的代码在悄悄腐烂时，触发点在哪？

最后这条正是这套框架的最大缺口：三根柱子能让你在被通知之后兜住系统，但它不负责通知你。原文的"安静失败"那一节其实已经埋了答案的一半——安静失败要靠主动的度量去发现，而不是靠等一个报错。

站内几条接得上的线

• AI 时代职业护城河：三种模式、工作流与判断力——同一件事的另一种切法：什么该交给 AI、什么必须自己上手。
• Claude Code 团队怎么做代码评审：7 层防线——当"逐行读"不成立时，用机制替代阅读。
• 50 个 Agent 建文明：GPT 像蜂群，Claude 像议会——多 agent 协作会自发长出层级与官僚制，和本文说的"机器人建出自己维护不了的东西"是同一个现象的两种观察。

五条边界

• 这是第一人称经验文，不是研究。 一个 SonarQube 告警、一次架构重写，样本是 1。原文也没有任何量化数据支撑"初级工程师不可行"这个判断。
• "经济上不可行"是论点，不是测量。 值得认真对待，但要说清它没有被验证：也许某些公司的培养成本结构会不同。
• 隐喻会被类比带着走。 潜水、海怪、金块这套说法很有说服力，也因此容易让人忽略反例：很多系统的问题根本不是"深海"，而是"根本没人在看水位"。
• "owner"在这里是窄定义。 原文明确把它定义成"坏了被叫起来的人"。在分工细的组织里，这个角色可能叫 SRE、可能叫值班工程师，而不是技术负责人。
• 三根柱子不是招聘标准。 原文结尾的"拆收音机的孩子"很动人，但它描述的是动机，不是能力证据。把它当筛人标准，会筛出很多只会拆东西的人。

来源：Adrian Quiroga,《Here Be Monsters: What Do You Still Need to Know When Agents Do the Work?》, blog.adrq.dev, 2026-10-27（页面显示 10-29 更新），约 15 分钟阅读。原文链接：https://blog.adrq.dev/here-be-monsters-what-do-you-still-need-to-know-when-agents-do-the-work。三根柱子、潜水机器人隐喻、Kubernetes 与 level-triggered 的案例、面试问题均为原文内容；四类技能形状图为原文配图（已转存站内）；三根柱子那张表、"自检五问"、"两个回避的问题"、评论区摘要与五条边界为我们整理。

本文由汇智网编译整理，转载请注明出处。

这是「AI 编程 / Vibe Coding」专题的一部分。完整地图见：AI 编程 / Vibe Coding 完全指南