你的编码代理把你变成了管理者

Addy Osmani，2026-11-08

管理代理的技能，差不多就是管理团队的技能，而且你不必先当上经理才能学会。 如果你整天都在和编码代理一起工作，那你已经在做管理了。你在反复挑选任务、写指令、委派、跟进、评估结果，并决定什么能上线。从代理身上拿得最多的工程师，不一定是最会写提示词的人。他们是那些学会了如何管理的人，不管是有意还是无意。

这个说法可能不受欢迎。我欣赏的许多工程师选择走个人贡献者（IC）路线，就是为了贴近具体工作。他们看着朋友变成经理，然后消失在日程表里。但我不是在让你变成那种经理。我在一个很具体的意义上使用「管理」：通过让别人把事做成，来得到好结果。我也绝不是说代理可以替代经理或同事。

你对糟糕经理的每一句抱怨，都是一份和代理协作时的缺陷报告。想想交接。如果你经历过糟糕的交接，那可能是需求含糊、缺少上下文，或者期望中途变来变去。对 IC 的好消息是：你已经在交接的接收端待了很多年，也许知道一次好的交接长什么样。

我以前写过，你的编码代理需要一个管理者。我也写过委派里那种安静的风险：认知投降（cognitive surrender）。这篇文章把优秀工程经理的做法，和我们使用并打造 Claude Code 时学到的东西放在一起对比。各节大致按影响力排序，所以杠杆最高的习惯放在最前面。

给它一种检查自己工作的办法

最佳实践：给代理一种验证工作的机制，比如测试套件、构建或截图，并让它把结果拿给你看作为证据。 反模式：把「看起来做完了」当成确认。这会逼你自己做全部验证，变成代理的测试套件。

问一位有经验的经理：他们怎么能在不读完所有东西的情况下，相信团队在产出好的工作？他们会谈到护栏。持续集成、代码审查、看板、值班，等等。不会建护栏的新经理会自己验证所有东西，一个季度之内就会变成瓶颈。代理也一样。正如 Claude Code 最佳实践指南所说，代理会在工作看起来做完时停下来。如果没有验证，「看起来做完了」就是它仅有的验证。提供验证机制，代理就能做完工作、跑验证器、看到失败，然后自己改。对界面改动来说，这可能意味着真的在浏览器里打开页面，迭代到它能用、也看起来对劲为止。

验证机制几乎可以是任何东西，只要它能给出明确的通过/失败结果。比如测试、构建退出码、linter、diff 脚本和截图。指南指出，运行这些验证的那条命令，是你能写进 CLAUDE.md（代理每次会话开始时会读的说明文件）里最有用的一行。有了验证机制之后，你可以这样把它带进工作流：

直接要求。「做完后跑认证相关测试，直到通过为止。」 设一个目标。用 /goal，会有另一个模型在每一轮之后跑条件检查，最适合长时间的后台工作。 强制执行。Stop hook 可以在类型检查通过之前，不让这一轮结束。 让它被审查。/code-review 会把 diff 发给一个没看过你对话的新子代理去做审查，就像作者不会批准自己的 PR。

你甚至可以控制审查的范围。如果你让它找问题，它总能找出点什么。但如果你让它找正确性问题、忽略风格，它也会照做。好的经理学习如何要反馈，也是这个道理。Claude Code 工具箱里的大部分功能，都是为了把这个环收紧。Skills、hooks、子代理和 MCP，都是为了填上「做工作」和「验证工作」之间的缝，好让你只关注代理验证不了的那些事。这正是有经验的工程经理在做的事。

把上下文说清楚

最佳实践：清楚总结代理光检查代码库无法知道的东西，包括：任务目标、为什么重要、约束、不在范围内的事项，以及成功标准。 反模式：只丢下一行任务，真正的期望都在你脑子里；或者把代理读代码就能发现的东西也写进简报里凑篇幅。

有效的经理会把期望结果、约束和目标说清楚。他们讲清楚工作应当达成什么，但把怎么做的自由留给做事的人。军队里这叫指挥官意图。Netflix 称之为「要上下文，不要控制」。

和代理协作的难点在于，你很难知道它缺的是哪一块上下文。编码代理做每个任务时，第一件事就是读你的代码。现在的模型非常擅长比你口述更快地抓住目录结构、惯例和测试安排。

动笔之前，先想代理自己能搞清楚什么。如果它能在代码里读到，而且它真的会去读，你就不必再说。把字花在仓库里没有的部分——比如一次会议决定、某人内部的部署流程、为什么这个任务重要，以及这一次怎样才算做完。

你不必每个任务都这么做。如果是在做探索，写一个笼统的提示完全可以，后面再一点点收紧。如果你还写不出提示，就让代理采访你，直到它能写出规格，把规格存成文件，再开一个新会话按规格去实现。你之后也可以拿这份规格来对照审查。

你可能还需要给代理其他工具的访问权限，比如问题跟踪、错误看板或团队聊天。对待代理，就像对待团队里的新同事。如果它已经知道某个命令行工具，比如 gh，你常常什么都不用交代。

让每一次纠正都能复利

最佳实践：同一件事纠正超过一次，就写进团队的 CLAUDE.md，或做成共享 skill。过一段时间检查更新的模型是否已经减少了这些纠正的必要。 反模式：每个会话都手动改同一件事，或依赖只存在于你自己机器上的隐性知识。

真正把 CLAUDE.md 用好的团队会时不时更新它，并把值得预防的教训写下来。有的团队甚至在代码审查里提到 @claude，把反馈变成长期政策。CLAUDE.md 要保持简短。适合写进去的包括：

如何验证某件事（准确的命令） 代码里容易误导人的地方 仓库里不存在的决策 你已经纠正过两次的任何事

这些都体现了书面信息的复利：它比人员换组和模型被替换都活得更久。

默认让它做决定，只强制那些不能松动的事

最佳实践：默认让代理做决定，只对必须永远发生或永远不能发生的少数事情使用硬性强制（比如 hooks、拒绝规则）。 反模式：用全大写写规则，给可有可无的偏好定义 hook，或在新模型已经长大之后，还守着旧模型时代的习惯。

安迪·格鲁夫在《高产出管理》里把这称作与任务相关的成熟度：监督的力度应当取决于一个人在这项具体任务上的表现历史，而不是总体能力。

给新经理的一句老建议也是这个意思：给人比你觉得舒服的再多一点点自由度，同时支持他们、也让他们负责。

Claude Code 把这一点说得很明白：提示词、CLAUDE.md 和 skills 是模型可以考虑、也可以选择不照做的请求；hooks、拒绝规则和管理设置则是始终会被执行的要求。大多数情况下，你希望由代理来做判断。常常会有这样的情形：模型看着真实代码，比你事先定下的规则更适合判断某条指南是否适用。把强制用在硬性要求上，比如「永远不要改生成出来的客户端」或「永远运行许可证头脚本」。特别是，新的终端和 VS Code 会话会从自动模式启动，里面有一个分类器，会滤掉部署到生产环境或强推覆盖别人工作这类不安全行为。

指南的建议有两面。如果你已经在强调 CLAUDE.md 里的某行，代理却仍然没听进去，那就应该做成 hook。如果一个 hook 表达的是偏好而不是要求，就应该拿掉，改让代理自己做主。这就像团队决定废除一条不再有用的流程。这也意味着换了新模型时要跟着调整。指南里列了一些可以停掉的习惯：全大写指令、「再想深一点」（现在努力程度是一个设置）以及「别偷懒」。对现在的模型来说，这些往往会导致规则过严和过度劳动。在代理这里，流程过多就是新的微观管理。

先计划，再让它动手写

最佳实践：在代理开始写代码之前先就计划达成一致，阅读其中隐含的假设，并把任务切成互不重叠的并行工作。 反模式：让多个代理同时做相互重叠的任务，然后把一下午花在解决合并冲突和重复决策上。

这里的好工作流是：先进入计划模式，把计划迭代到正确为止，再把写代码委派出去。有了好计划，模型常常能一次做完。对更大的任务，用第二个会话像参谋工程师那样审一遍计划；这是设计评审，也是抓住走错方向最便宜的地方。审计划时要看底层假设（在一对一里，这相当于问：「你对什么没有把握？」）。

拆分工作越来越多地也被交给代理。Claude Code 里的 /batch 会把一次大的机械改动拆成 5 到 30 个任务，展示计划，在分开的 worktree（仓库的不同检出）里执行，并为每一个创建 PR。你不再需要自己切分工作，只要检查这些切片有没有重叠，并确保共享接口先落地。没有这一步，你得到的可能只是虚假的并行：五个代理做重叠的任务，不会带来五倍产出，只会带来一份有五个作者的合并冲突。

早点转向，尽快重置

最佳实践：盯住第一分钟，给代理转向。一看到它偏离轨道就纠正。如果已经失败地纠正过两次，就开一个新会话、用更好的提示词重来。 反模式：第三次、第四次去纠正代理，而不是去纠正你的请求。

有经验的经理知道：如果一个能干的人连续失手，问题可能出在上游的指令、上下文或范围上。代理版本说得很明确：它一偏离轨道，就按 Esc。如果已经失败地纠正过两次，清空会话，写一个更好的提示词，把你刚学到的教训加进去。第三次纠正，多半只是给模型更多它必须反复重读、重处理的信息（包括失败的尝试）。

便宜的回滚也在改变局面。/rewind 可以把代码和对话滚回到更早的点，让你先试更大胆的方案变得低风险。好的经理对员工也这样做：如果撤销错误很便宜，就让他们先试大胆的方案。然后做复盘，如果适用，就把修复推广进 CLAUDE.md。

委派任务，永不委派判断

最佳实践：代理做事，你决定重要的事：产品判断、安全边界、什么能上线。对待每一份 diff，都像你会因为它们被半夜叫醒一样。 反模式：因为测试是绿的、名字看起来也合理，就批准很大的 diff。这不是代码审查，这是代码盖章。

没有经理能说「那是我的下属发的，不是我」。对你运行的每一个代理也一样。我自己也掉进过这个陷阱。我让一个代理研究与竞争对手的差距，并写本地 PR 去补上这些差距。我读了研究报告，粗略看了代码，差点就把那些给用户增加复杂度、收益却很小的改动推上去。我委派了工作，也差点委派了决定。这很容易发生：一份 600 行的 diff，名字看起来合理，测试是绿的，批准。

这样拆分任务是说得通的：让代理去做风格、lint、审查后续、常见缺陷和单元测试，但让人来处理安全边界、合规和产品决策。

协调也是一样。代理可以跟踪交接，但在相互竞争的请求之间做决定、并让人真正承诺下来，仍然是人的工作。

你不必处在每一次改动的内环里。你需要掌握的是外环：约束是什么、你实际读了多少输出、你保留什么证据，以及哪些必须由人签字。并且让改动保持小，因为审查的单位就是理解的单位。

设计那种不需要你在场的运行

最佳实践：在部署一个自主任务之前，定义何为完成、自我验证、边界、护栏，以及人的批准。 反模式：睡前启动一个长时间进程，却没有完成定义或停止点，第二天早上发现模型整晚都在一个错误前提上工作。

隔级经理不管理单个工程师的具体工作；他们管理目标、护栏、检查点和负责人。AI 代理正在走上类似的轨迹。它们已经在把任务的一部分委派给子代理，也能按计划、在持续集成失败后或在新的拉取请求打开后自主运行。前沿是能够自己启动、自我验证、只在需要做决定时才叫人的自治系统。

角色从控制会话，转向设计你的循环。设计无人值守运行时要问自己的五个问题，和好经理在把项目交给资深工程师然后去度假之前问的问题是一样的：

它知不知道「做完」长什么样？（目标条件、规格文件，或它必须变绿的失败测试。） 它有没有自我验证机制？（测试套件、Stop hook 或审查步骤。） 它的边界是什么？（权限控制、沙箱、worktree，或它被允许推送的那一个分支。） 它的护栏是什么？（轮次上限或花费上限。） 它把输出放在哪里，谁来批准？（一份 PR 或摘要，以及对任何不可逆动作的人工批准。）

指南里还有两个经理会认作好习惯的做法：先试点，也就是让批处理先在三个文件上跑，迭代提示词，再跑剩下的；以及在信任任何新东西无人值守之前，先看它前面几次运行。把它想成试用期。

扩展验证，而不是扩展注意力

最佳实践：只有当检查、目标和新上下文的审查者能接过监视工作时，才加快增加代理的使用；除了吞吐量，还要测量质量。 反模式：打开的会话比你能好好审查的更多，并用 AI 写了多少代码来衡量成功。

经理很快就会知道自己的管理跨度。超过一定数量的直接下属，每个人分到的经理就会变少，质量也会下降。代理也一样。我称之为编排税：过了最初几个代理之后，每多一个代理，需要你的注意力比上一个更多。大多数日子里我会跑四五个后台代理和几个本地会话，有些日子这就已经太多了。

管理很多会话，靠的不是超级专注，而是把大部分监视交给自我评估、目标和新上下文的审查者，把注意力留给决策。用通知代替轮询、有一个后台任务的集中视图，也会有帮助。你没法靠监视得更多来扩展代理数量，只能靠需要监视得更少。然后衡量系统，而不是衡量活动。有用的指标包括 PR 的周期时间、新员工上手时间，以及回滚或返工的频率。把 AI 写的代码占比当成目标没有用，因为你要的是质量和可靠性。格鲁夫「测量时要有对冲指标」的规则在这里适用：如果你测量合并了多少 PR，那就同时测量回滚和返工。

决定什么不要做

最佳实践：问谁需要它、你怎么知道它奏效了、什么情况下该停，并限制在制品数量。 反模式：反正做起来便宜，就把每个说得通的想法都扔进 PR。你现在会有一个团队必须审查、保护和维护的杂物抽屉。

经理最重要的词常常是「不」。有了代理，更难说不。开始干活几乎不要成本，午饭前你就能把任何说得通的想法做成 PR。但你现在会有一堆团队必须审查、保护、支持和维护的 PR。审查和验证现在才是稀缺资源。

事实上，那些老的管理问题现在比以前更重要。谁提出来的？我们怎么衡量成功？我们怎么知道该停？如果做起来便宜，难的问题就不是「我们能不能」，而是「我们应不应该」。

这个类比在哪里失效

最佳实践：遵循管理的最佳实践，但要考虑代理模型的不同之处，比如返工很便宜、它们很快就会同意，以及能力会随着每次模型发布而变化。 反模式：以为代理就像初级开发者，或者以为你能跑五个代理，就准备好管理五个人了。

这个类比有用，但并不完美，最擅长这件事的人清楚它不完美的地方：

管理人更难，而且这些技能不会反向迁移。你不会因为跑过五个代理，就准备好管理五个人。动机、冲突、职业发展和长达数月的信任建立，都没有对等物。 返工几乎免费。你可以问代理那些你永远不会拿去问人的问题。如果白板前发生了技术争论，代理可以做出两三个方案让你比较。 代理没有经验，只有笔记本。自动记忆只在一台机器上记笔记。它们不会转移到同事的会话里。它们也不是你在职业生涯里积累的经验和判断，你需要把这些教训写下来给整个团队。 代理既积极又自信。如果你让一个好工程师做错事，他们会反驳。代理更可能照你说的去做，而你也更容易过度信任它们。沃顿商学院关于认知投降的研究里，参与者大多数时候接受了有缺陷的 AI 答案，而且变得更加自信。你可以让代理反驳它自己的答案，来对抗这种过度自信。 你只有一种代理原型，而且每隔几个月就会变。人类团队有多样的技能和长处。你所有的代理都有同样的长处和弱点，并且会随着每次模型发布而改变。 你仍然必须培养初级开发者。当代理接管了初级开发者用来学习手艺基础的入门工作时，你必须有意地为他们创造这些练习。作为经理，这是你的责任。 人类团队仍然重要。有时候你会花一整天管理代理，却没意识到你把建设有凝聚力的团队所需的时间挤掉了。别这样做。

你不需要那个头衔

最佳实践：把力气花在让好软件发生上：把上下文说清楚，定义何为完成，并好好审查。 反模式：一边运行着简报不足、未经检查的代理，一边用代码行数评价自己。

优秀的参谋工程师一直就是这样。他们写设计文档。他们把上下文讲清楚。他们做彻底的审查。他们让周围的人变得更好。代理让所有工程师从第一天就能这样做。它们给你上了一堂速成的管理课。你在几分钟而不是几个季度里得到反馈。你可以撤销自己的错误。这份工作正在变得不那么关于把代码写出来，而更关于成为好代码被写出来的原因。

没有人生来就是伟大的经理（或伟大的工程师）。你构建技能的方式和以往一样：通过练习。但有了代理，练习变得便宜。

试一试这些做法：

每个任务都需要一个它能自己跑的检查。把证据要过来。 告诉代理它看不见的东西，省去它能看见的东西。 写代码之前先把计划谈清楚。 同一件事纠正过两次？记进 CLAUDE.md。重复出现的工作流？做成 skill。 两次纠正都失败了？重启并用不同的说法重写提示词。 审查 diff 时，就当自己会因为它被叫醒。 你不必想当经理。但把代理用好的工程师，会在这个过程中学会管理。