Agent 时代，人人都是管理者

Addy Osmani 把工程管理经验与 Claude Code 的使用实践放在一起，讨论写代码之外正在转移到开发者身上的工作，以下是全文翻译。

管理 Agent 所需的技能，和管理团队所需的技能差不多。而且，你不必先当上经理才能学会这些。

如果你整天都在和编程 Agent 打交道，那你其实已经在做管理了。你不断挑选任务、编写指令、分派工作、跟进进度、评估结果，再决定哪些东西可以交付。最能发挥 Agent 价值的工程师，未必最擅长提示词工程。他们往往是在有意或无意之间，学会了怎样管理。

这个说法可能不太讨喜。许多我欣赏的工程师选择个人贡献者（IC）路线，就是为了离具体工作近一点。他们见过朋友当上经理，然后整个人都被日历上的会议吞没。但我不是劝你成为那样的经理。我在这里说的“管理”有一个明确含义：让其他执行者更好地工作，从而得到好的结果。我当然也不是说，Agent 能取代经理或同事。

你对糟糕管理者的每一句抱怨，都可以当作一份与 Agent 协作时的缺陷报告。想想工作交接。如果你遇到过糟糕的交接，可能收到过含糊不清的要求、缺失的背景，或不断变化的预期。对 IC 来说，好消息是，你已经在交接的接收端待了很多年，或许很清楚一次好的交接是什么样。

我以前写过，你的编程 Agent 需要一位管理者；也写过委派工作时一个不易察觉的风险——认知让渡。这篇文章把优秀工程管理者的做法，与我们在使用和开发 Claude Code 时学到的经验放在一起比较。各节大致按影响大小排列，最值得优先养成的习惯放在最前面。

让它有办法检查自己的工作

最佳实践： 给 Agent 提供验证工作的办法，例如测试套件、构建或截图，并让它拿出结果作为证据。

反模式： 把“看起来做完了”当作确认。这样一来，所有验证都得由你来做，你成了 Agent 的测试套件。

问一位经验丰富的管理者，为什么不必逐一看完所有东西，也能对团队的工作质量有信心，他们会谈到护栏：CI、代码评审、监控看板、值班机制等等。缺少经验、没有建立护栏的管理者，最后会亲自检查一切，不到一个季度就成了瓶颈。Agent 也是如此。正如 Claude Code 最佳实践指南所说，Agent 会在工作看起来完成时停下来。如果没有验证，“看起来做完了”就是它唯一的验证方式。给它提供验证机制，它就能完成工作、运行检查、看到失败，再自行修正。对于 UI 修改，这可以意味着真正用浏览器打开页面，反复调整，直到功能正常、外观也合适。

验证机制几乎可以是任何东西，只要能给出明确的通过或失败结果：测试、构建退出码、代码检查器、差异比较脚本，以及截图。指南指出，执行这些验证的命令，是最值得写进 CLAUDE.md 的一行内容。CLAUDE.md 是 Agent 每次会话开始时都会读取的指令文件。有了验证机制，就可以用下面这些方式把它放进工作流：

• 直接要求。“完成后运行身份验证测试，继续处理，直到测试通过。”
• 设定目标。使用 /goal 时，另一个模型会在每轮结束后检查条件。这对长时间的后台工作尤其有用。
• 强制执行。Stop hook 可以在类型检查通过之前，阻止这一轮结束。
• 安排评审。/code-review 会把 diff 发给一个没看过当前对话的新子 Agent 进行评审，就像代码作者不能批准自己的 PR 一样。

你甚至可以控制评审的范围。让它找问题，它总能找出些什么；但如果要求它只找正确性问题、忽略风格，它也会照做。优秀管理者也是这样学会征求反馈的。Claude Code 工具箱的大部分功能，都在收紧这个闭环。Skills、hooks、子 Agent 和 MCP 的作用，都是弥合执行与验证之间的距离，让你的注意力只留给 Agent 无法验证的事情。有经验的工程管理者做的也是这件事。

把背景交代清楚

最佳实践： 清楚说明 Agent 无法通过查看仓库得知的信息，包括任务目标、为什么重要、约束、不在范围内的事项，以及成功标准。

反模式： 只丢下一句话，真正的预期却都装在你脑子里；或者在任务说明里塞满 Agent 读代码就能发现的事情。

有效的管理者会清楚描述期望的结果、约束和目标。他们说明这项工作应该达成什么，同时给执行者留出决定如何完成的空间。在军队里，这叫“指挥官意图”。在 Netflix，这叫“提供背景，而非控制”。

与 Agent 协作的难处在于，很难知道它究竟缺了哪些背景。编程 Agent 接到任务后的第一件事，就是读你的代码。现在的模型能很快理解目录结构、约定和测试设置，速度远快于你把这些逐一讲清楚。

动笔之前，先想想 Agent 能自己弄明白什么。如果它可以从代码里读到，而且确实会去读，就不必再说。把文字留给仓库里没有的部分：例如一次会议的决定、某个人部署时遵循的内部流程、这项工作为什么重要，以及这一次怎样才算完成。

拿“让看板快一点”这个含糊的任务来说，我们可以把它改写成下面的提示词。数字仅作示例。

提示词中文对照：

对于成员数超过1万的组织，把 /team 看板的 p95 加载时间降到2秒以内。

原因：企业管理员每天都会打开它，加载缓慢是他们反馈最多的支持问题。

约束：不修改数据库 schema，保持 API 响应结构。

不在范围内：UI 修改、缓存整个页面。

检查：运行 scripts/perf/team.sh，展示修改前后的数据。

Get p95 load time for the /team dashboard under 2s for orgs with 10k+ members.

Why: enterprise admins open it daily, and slow loads are their top support ticket.

Constraints: no schema changes; keep the API response shape.

Out of scope: UI changes; caching the whole page.
Check: run scripts/perf/team.sh and show before and after numbers.

不必每个任务都这么做。如果是在探索，写一个笼统的提示词完全没问题，之后再逐步细化。如果还没准备好写提示词，可以先让 Agent 不断向你提问，直到它足以写出规格说明；把说明存成文件，再开一个新会话，让 Agent 据此实现。后续评审时，也可以拿这份说明来对照。

你可能还需要让 Agent 能访问其他工具，例如问题跟踪系统、错误监控看板或团队聊天工具。把它当作一位刚加入团队的新同事。如果是它已经熟悉的 CLI 工具，比如 gh，往往不必额外说明。

让每次纠正都能积累下来

最佳实践： 同一个问题纠正不止一次，就把它写进团队的 CLAUDE.md，或者做成共享 skill。之后还要看看，新模型是否已经减少了这些纠正的必要。

反模式： 每次会话都手动纠正同一件事，或者依赖只存在于自己机器上的隐性知识。

最能用好 CLAUDE.md 的团队，会比较经常地更新它，记录那些值得避免的错误。有些团队甚至会在代码评审中提及 @claude，把反馈变成长期约定。CLAUDE.md 要保持简洁，适合写进去的内容包括：

• 如何验证某件事，包括准确的命令。
• 代码中容易误导人的地方。
• 仓库里没有记录的决定。
• 任何已经纠正过两次的事情。

这些都体现了书面信息的积累效应。人员换团队、模型换版本之后，信息仍然能留下来。

让它作判断只强制不可妥协的事

最佳实践： 默认让 Agent 自己决定，只有少数必须始终执行或绝不能发生的事情，才用硬性机制约束，例如 hooks 和 deny rules。

反模式： 用全大写写规则、为可选偏好设置 hook，或者新模型早已不需要了，却仍沿用旧模型时代的习惯。

安迪·格鲁夫在《高产出管理》中把这叫作“任务相关成熟度”：监督程度应取决于一个人在某项具体任务上的表现记录，而不是他的整体能力。

给新任管理者的一条老建议，说的也是同一件事：给执行者比你感到舒服的程度再多一点自主空间，同时做好支持，并要求他们对结果负责。

Claude Code 把这一区别明确了下来：提示词、CLAUDE.md 和 skills 是模型可以考虑、选择执行的请求；hooks、deny rules 和托管设置，则是始终强制执行的要求。大多数时候，你希望由 Agent 来判断。看过实际代码之后，模型往往比你预先设定的一条规则，更有条件判断某项指导是否适用。把强制机制用于硬要求，例如“绝不能编辑生成的客户端”或“始终运行许可证头脚本”。具体来说，新开的终端和 VS Code 会话会以 auto 模式启动，其中的分类器会过滤掉部署生产环境、强制推送覆盖他人工作等不安全行为。

指南的建议有两面。如果你不断强调 CLAUDE.md 中的一行要求，Agent 仍然没做到，那它应该变成 hook。如果某个 hook 表达的只是偏好，而非硬性要求，就该去掉它，让 Agent 自己判断。这就像团队决定停用一个已经没有价值的流程。换了新模型，也要做相应调整。指南列出了一些可以放下的习惯：全大写指令、“再深入思考”（现在推理强度已经是一个设置），以及“别偷懒”。对当前模型来说，这些往往只会带来过度执行的规则和多余工作。与 Agent 协作时，过多流程成了新的微观管理。

先规划再动手

最佳实践： Agent 开始编码之前，先把计划沟通一致，检查背后的假设，再把工作拆成互不重叠、可以并行的任务。

反模式： 让多个 Agent 同时处理相互重叠的任务，然后花一下午解决合并冲突和重复决策。

一个好用的流程是先进入 plan 模式，反复调整，直到计划合适，再把编码工作交出去。有了好计划，模型往往一遍就能完成实现。对于较大的任务，可以另开一个会话，让它像资深骨干工程师那样审视计划。这相当于设计评审，也是以最低成本发现方向错误的时机。检查计划时，要留意背后的假设——放在一对一沟通里，就是问一句：“你对什么还没有把握？”

任务拆分也越来越多地交给了 Agent。Claude Code 的 /batch 会把一次大规模机械性修改拆成5到30项任务，展示计划，再到不同的 worktree，也就是同一仓库的不同工作副本中执行，并为每项任务创建一个 PR。你不再需要亲自拆分工作，只要检查各块有没有重叠，确保共享接口先落地。否则，就可能得到一种假的并行：五个 Agent 接下相互重叠的任务，带来的不是五倍产出，而是一场有五位作者参与的合并冲突。

尽早纠偏及时重来

最佳实践： 留意最初一分钟，及时引导 Agent。发现偏离方向就纠正。如果已经有两次纠正没有奏效，就用更好的提示词开一个新会话。

反模式： 不去修改原始请求，而是继续进行第三次、第四次纠正。

有经验的管理者知道，如果一个有能力的执行者接连做偏，问题可能出在更上游：指令、背景或任务范围。Agent 这里的做法更直接：发现方向不对，马上按 Esc。如果两次纠正都失败，就清空会话，吸收教训，写一个更好的提示词。第三次纠正，往往只是在增加模型必须反复读取、处理的信息，其中还包括前面失败的尝试。

低成本回退也在改变做事方式。/rewind 可以把代码和对话退回更早的位置，让你以较低风险先尝试更大胆的方案。优秀管理者对待员工也是如此：如果撤销错误的成本很低，就让他们大胆试试。事后再复盘，适用的话，就把修正办法归纳进 CLAUDE.md。

可以交出任务不能交出判断

最佳实践： Agent 执行工作，重要的决定由你来做：产品取舍、安全边界，以及什么可以交付。审查每一份 diff 时，都要像出了问题会半夜把你叫起来一样认真。

反模式： 测试全绿、命名看着合理，就批准一大份 diff。这不叫代码评审，只是在给代码盖章。

没有哪位管理者能说“这是我的下属交付的，不是我交付的”。你运行的每个 Agent 也是一样。我自己也掉进过这个坑。我让一个 Agent 研究我们与竞品之间的差距，再在本地写出弥补差距的 PR。我读了研究，粗略扫过代码，差一点就推送了一些收益不大、却会增加用户使用复杂度的修改。我把工作交了出去，差一点连决定也一起交了出去。这种坑很容易踩：600行 diff，命名看着合理，测试全绿，于是批准。

这样分配任务比较合理：把代码风格、lint、评审后的修改、常见 bug 和单元测试交给 Agent，把安全边界、合规和产品决定留给人。

协调工作也是一样。Agent 可以跟踪交接，但在相互竞争的请求之间作取舍、让相关人员真正作出承诺，仍然是人的工作。

你不必参与每次修改的内循环。你必须掌握的是外循环：约束是什么、实际读了多少产出、保留哪些证据，以及哪些事情必须有人签字同意。同时，把修改保持在小范围内，因为一次评审能有效覆盖的范围，取决于你一次能理解多少。

设计不需要你盯着的运行方式

最佳实践： 部署自主任务之前，先定义完成标准、自我验证方式、边界、护栏，以及人工批准环节。

反模式： 临睡前启动一个长时间运行的进程，既没说清怎样算完成，也没设停止条件，第二天醒来才发现模型围绕一个错误前提忙了一整夜。

隔级管理者并不直接管理每一位工程师的具体工作，而是管理目标、护栏、检查点和负责人。AI Agent 也在沿着类似的方向发展。它们已经会把部分任务分给子 Agent，也可以按计划、在 CI 失败后或新 PR 创建后自主运行。前沿方向是能够自行启动、自我验证的自治系统，只有需要作决定时，才请求人介入。

你的角色从控制会话，变成设计工作闭环。设计一次无人值守运行时，要问自己的五个问题，与优秀管理者把项目交给高级工程师、然后休假之前会问的问题一样：

• 它知道怎样才算完成吗？可以是目标条件、规格文件，或一项必须从失败变成通过的测试。
• 它有自我验证机制吗？例如测试套件、Stop hook，或者评审步骤。
• 它的边界在哪里？例如权限控制、沙箱、worktree，或唯一允许推送的分支。
• 它有哪些护栏？例如轮数上限或支出上限。
• 它在哪里输出结果，由谁批准？例如提交一个 PR 或一份摘要，不可逆操作则由人批准。

指南还提到两个管理者也会认同的好习惯：先试点，例如先让批处理跑三个文件，调整提示词，再处理其余文件；任何新工作流，最初几次运行都要看着，之后再决定是否可以无人值守。可以把这看作试用期。

扩大验证能力而非注意力投入

最佳实践： 检查机制、目标和全新上下文的评审者，能接过多少监看工作，就扩大到多大规模；衡量质量，也衡量吞吐。

反模式： 开启超出自己认真评审能力的会话数量，并用 AI 写了多少代码来衡量成功。

管理者很快就会知道自己的管理幅度。直属下属超过某个数量后，每个人得到的关注都会减少，质量也会下降。Agent 也是如此。我把它称为“编排税”：越过最初几个 Agent 之后，每增加一个，需要的注意力会比前一个更多。大多数时候，我会运行四五个后台 Agent，再加几个本地会话。有些日子，就连这个数量也太多了。

管理许多会话，靠的不是注意力格外集中，而是把大部分监看交给自我评估、目标机制和新上下文的评审者，自己把注意力留给决策。用通知代替轮询、集中查看后台任务，也有帮助。Agent 数量的扩大，不能靠你盯得更多，只能靠它们需要你盯得更少。然后，衡量整个系统，而不是忙碌程度。有用的指标包括 PR 的流转时间、新员工上手时间，以及回退或返工频率。AI 所写代码的占比不是一个有用的目标，因为你追求的是质量和可靠性。格鲁夫关于“指标要有制衡指标”的原则同样适用：衡量合并了多少 PR，就也要衡量回退和返工。

决定哪些东西不该做

最佳实践： 问清楚谁需要它、怎样知道它奏效，以及什么情况会让你停下来，同时限制正在进行的任务（WIP）数量。

反模式： 反正开发便宜，就把每个看似合理的想法都变成 PR。你会得到一个杂物抽屉，里面的东西都需要团队评审、保障安全和维护。

管理者最重要的一个字，往往是“不”。有了 Agent，说“不”更难了。启动工作几乎没有成本，随便一个看起来说得通的想法，都能在午饭前变成 PR。但你随之得到的，是一堆需要团队评审、保障安全、支持和维护的 PR。现在稀缺的是评审与验证资源。

事实上，那些传统的管理问题，如今比过去更重要：是谁提的需求？如何衡量成功？怎样知道该停了？如果开发很便宜，难的问题就不再是“能不能”，而是“该不该”。

这个类比也有不适用的地方

最佳实践： 借鉴管理方面的好做法，但要考虑 Agent 的不同之处：返工便宜、很容易表示同意，以及每次模型更新都会变化的能力。

反模式： 认为 Agent 就像一个初级开发者；或者以为自己能运行五个 Agent，就已经准备好管理五个人。

这个类比有用，却不完美。最擅长这种协作的人，也清楚它在哪些地方不成立：

• 管理人更难，这些技能也不能直接反向迁移。运行过五个 Agent，不代表你已经准备好管理五个人。激励、冲突、职业发展，以及耗时数月建立信任，都找不到对应的 Agent 版本。
• 返工几乎没有成本。你可以向 Agent 提出一些不会向真人提出的要求。技术讨论在白板前陷入争论时，Agent 可以把两三个方案都实现出来，再让你比较。
• Agent 没有经历，只有一本笔记。自动记忆只会在一台机器上记录笔记，不会自动传到队友的会话里。这不等于你在职业生涯中积累的经验与判断，你需要把这些教训写下来，让整个团队都能用。
• Agent 热心而自信。让一位优秀工程师做错误的事，他们会提出异议；Agent 更可能照办，而你又容易过度信任它们。沃顿商学院关于认知让渡的研究中，参与者大多数时候都会接受 AI 给出的错误答案，而且变得更有信心。可以让 Agent 反驳自己的回答，以此对抗这种过度自信。
• 你的 Agent 只有同一种能力类型，而且每隔几个月就会改变。人的团队有多样的技能和长处，你的 Agent 却有着相同的优点和缺点，并且这些会随每次模型发布而变化。
• 你仍然得培养初级开发者。Agent 接手那些原本供新人学习基本功的入门工作后，作为管理者，你必须有意识地为新人创造练习机会。
• 人的团队仍然重要。有时你可能花了一整天管理 Agent，却没意识到，建设一支有凝聚力的团队所需的时间，已经被挤掉了。别这样。

不必先有管理者的头衔

最佳实践： 把精力放在让好软件真正做出来：交代背景、定义完成，以及认真评审。

反模式： 一边运行着任务交代不清、无人检查的 Agent，一边按代码行数给自己打分。

优秀的资深骨干工程师一直都在这样做。他们写设计文档、交代背景、认真评审，让周围的人做得更好。Agent 让所有工程师从第一天起就能做这些事，也给你上了一堂管理速成课。你在几分钟内就能得到反馈，不必等上几个季度；自己的错误，也可以撤销。这份工作的重心，正从亲手写代码，变成促成好代码被写出来。

没有谁生来就是优秀的管理者，也没有谁生来就是优秀的工程师。积累技能的方法和过去一样，靠练习。只是有了 Agent，练习变便宜了。

试试这些做法：

• 每项任务都要有它能运行的检查，并要求它拿出证据。
• 告诉 Agent 它看不到的东西，省去它自己能看到的部分。
• 写代码之前，先把计划谈清楚。
• 同一件事纠正过两次？记进 CLAUDE.md。重复出现的工作流？做成 skills。
• 两次纠正都失败？重新开始，换一种方式写提示词。
• 审查 diff 时，就当出了问题会把你叫起来处理。

你不必想当经理。但那些能与 Agent 合作得很好的工程师，会在这个过程中学会管理。

参考链接

• your coding agents need a manager：https://addyosmani.com/blog/coding-agents-manager/
• cognitive surrender：https://addyosmani.com/blog/cognitive-surrender/
• Claude Code best-practices guide：https://code.claude.com/docs/en/best-practices