你的编程智能体，让你成了管理者

管理智能体所需的能力，与管理团队所需的能力大致相同。而且，你不必先成为经理，才能学会这些能力。

如果你整天都在与编程智能体打交道，那你就在做管理。你不断挑选任务、编写指令、委派工作、跟进进展、评估结果，并决定哪些成果可以交付。最能发挥智能体价值的工程师，不一定最擅长提示词工程。他们往往是在有意无意之间，学会了如何管理的人。

这个说法可能不太讨喜。我欣赏的许多工程师选择了个人贡献者（IC）这条职业路线，就是因为他们想继续亲手做事。他们见过朋友转做管理后，整个人就被日程表吞没了。但我不是劝你成为那样的经理。我在这里所说的“管理”，有一个具体含义：帮助他人做好工作，从而取得好的结果。我当然也不是说，智能体可以取代经理或同事。

你对糟糕管理者的每一条抱怨，都可以看作与智能体协作时的一份问题报告。想想工作交接：如果你经历过一次糟糕的交接，接到的要求可能含糊不清、缺少背景，或者预期总在变。对 IC 来说，好消息是：这些年你一直在承接别人交来的工作，因此很可能知道，好的交接应该是什么样。

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

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

推荐做法：为智能体提供验证工作的方法，例如测试套件、构建或截图，并要求它拿出结果作为证据。

应避免的做法：把“看起来做完了”当成已经完成的确认。这样一来，所有验证都得由你来做，你自己成了智能体的测试套件。

问一位经验丰富的经理：不逐项查看所有工作，怎么确定团队交付的质量？他们会谈到各种保障机制：持续集成（CI）、代码审查、监控面板、值班响应，等等。没有建立这些机制的新经理，最后往往什么都要亲自验证，不到一个季度就成了瓶颈。智能体也是如此。正如 Claude Code 最佳实践指南所说，智能体会在工作“看起来完成了”时停下。如果没有验证手段，“看起来完成了”就是它唯一的判断依据。有了验证机制，它就可以完成工作、运行检查、发现失败，再自行修正。对于界面改动，这可以意味着真的用浏览器打开页面，反复调整，直到功能正常、外观也符合要求。

验证机制几乎可以是任何东西，只要能给出明确的通过或失败结果。例如测试、构建退出码、代码检查工具、差异比较脚本，以及截图。指南指出，运行这些检查的命令，是你能写进 CLAUDE.md 的最有用的一行内容；这个文件是智能体每次开始会话时读取的指令文件。建立验证机制后，可以通过以下方式把它纳入工作流程：

• 直接提出要求。“完成后运行身份验证测试，并继续修改，直到测试通过。”
• 设定目标。使用 /goal 时，另一个独立模型会在每轮结束后检查完成条件。长时间在后台执行任务时，这尤其有用。
• 强制执行。可以用 Stop 钩子阻止本轮结束，直到类型检查通过。
• 交给独立审查者。/code-review 会把代码差异交给一个新的子智能体审查，它没有看过你们的对话。这就像代码作者不能批准自己的拉取请求（PR）。

你甚至可以限定审查范围。只要你让它找问题，它总能找出点什么；但如果你要求它只找影响正确性的问题、忽略风格，它也会照做。优秀经理学习如何征求反馈，也是如此。Claude Code 工具箱中的大部分功能，都是为了让“做完—验证—修正”的循环更紧密。Skills、钩子、子智能体和 MCP 都在帮助弥合执行与验证之间的差距，让你只需关注智能体无法自行验证的部分。这也正是有经验的工程经理的做法。

把背景和要求交代清楚

推荐做法：简明交代那些智能体无法通过查看代码库得知的信息，包括任务目标、为什么重要、约束条件、不在本次范围内的事项，以及成功标准。

应避免的做法：只丢给它一句任务描述，真正的要求却全留在自己脑子里；或者用它读代码就能发现的信息，把说明写得冗长。

有效的管理者会把期望的结果、约束和目标说清楚。他们说明这项工作应该达成什么，同时让执行者自行决定怎么做。军队把这叫作“指挥官意图”；Netflix 则称之为“提供背景，而非控制”。

与智能体合作的一大难点，是你很难知道它缺少哪些背景。编程智能体接到任务后，首先会读代码。现在的模型非常善于理解目录结构、项目惯例和测试配置，比你用语言把这些说明白快得多。

动笔之前，先想想它能自己弄清什么。如果某件事它从代码里就能读到，而且确实会去读，那你就不必再说。把篇幅留给代码库里没有的内容：例如一次会议的决定、某个人内部使用的部署流程、这项任务为什么重要，以及这一次究竟怎样才算完成。

来看一个例子：怎样把“让仪表盘快一点”这个含糊的任务，改成一条明确的提示词。以下数字仅作示例。

对于成员数超过 10,000 的组织，将 /team 仪表盘的 p95 加载时间降到 2 秒以下。

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

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

不在本次范围内：界面改动；缓存整个页面。
验证：运行 scripts/perf/team.sh，并展示修改前后的数据。

并不是每项任务都要写成这样。如果你还在探索问题，使用宽泛的提示词完全没问题，边推进边细化即可。如果你还没准备好写提示词，可以先让智能体向你提问，直到它能据此写出规格说明；把说明保存成文件，再开一个新会话，让智能体按它实现。之后也可以用这份说明来验收。

你可能还需要让智能体访问其他工具，例如工单系统、错误监控面板或团队聊天。对待它，就像对待团队的新同事。如果是它已经熟悉的命令行工具，比如 gh，通常不需要再教它怎么用。

让每次纠正都积累下来

推荐做法：同一个问题纠正超过一次，就把它记录在团队的 CLAUDE.md 中，或做成共享的 Skill。随着模型更新，也要检查这些纠正是否仍然必要。

应避免的做法：每次会话都手动纠正同样的问题，或者依赖只存在于自己电脑上的隐性经验。

最能发挥 CLAUDE.md 价值的团队，会不时更新这个文件，把那些值得避免重犯的错误和教训记下来。有些团队甚至会在代码审查中提及 @claude，将反馈转成长期遵循的规则。让 CLAUDE.md 保持简洁，适合写入其中的内容包括：

• 如何验证工作，包括确切的命令。
• 代码中容易让人误解的地方。
• 没有记录在代码库中的决定。
• 你已经纠正过两次的问题。

这些都体现了书面记录的累积价值。即使有人换了团队，或者模型换了版本，它们依然能够发挥作用。

让它自行判断，只强制执行不能妥协的要求

推荐做法：默认让智能体自行决定；只有少数必须始终做到、或绝对不能发生的事项，才使用钩子、拒绝规则等强制机制。

应避免的做法：用全大写强调规则，为可选的个人偏好设置钩子，或者新模型早已不需要了，却还沿用旧模型时代的习惯。

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

给新经理的一条老建议说的也是同一件事：给人比你觉得安心的程度再多一点自主空间，同时支持他们，并要求他们对结果负责。

Claude Code 把这种区别明确了下来：提示词、CLAUDE.md 和 Skills 是模型会考虑并选择执行的请求；钩子、拒绝规则和托管设置，则是始终强制执行的要求。大多数情况下，你应该让智能体作判断。很多时候，模型正在查看实际代码，比你事先定下的规则更能判断某条指导是否适用。强制机制应当用来落实硬性要求，例如“绝不修改自动生成的客户端代码”或“始终运行许可证文件头脚本”。尤其是，新建的终端和 VS Code 会话会以自动模式启动，由分类器过滤部署到生产环境、用强制推送覆盖他人工作等不安全行为。

指南的建议有两面。如果你不断强调 CLAUDE.md 中某一行要求，智能体仍然做不到，那就应该把它变成钩子。如果一个钩子表达的只是偏好，而非硬性要求，就应该移除，交由智能体自行决定。这就像团队淘汰一个已经没有用的流程。换用新模型时，也要作相应调整。指南列出了一些可以停止的习惯：全大写指令、“再努力想想”（现在思考投入程度已有专门设置），以及“别偷懒”。对于当前的模型，这些做法往往导致规则执行过头、做太多无谓工作。在与智能体协作时，过度设置流程成了新的微观管理。

先把计划想清楚，再开始实现

推荐做法：在智能体开始编码前，先就计划达成一致；审阅其中隐含的假设，并把任务拆成互不重叠、可以并行的部分。

应避免的做法：让多个智能体同时处理相互重叠的任务，然后花一下午解决合并冲突和重复决策。

一个好的流程是，先进入规划模式，反复调整，直到得到合适的计划，再把编码工作交出去。计划清楚后，模型往往能一次完成实现。对于较大的任务，可以另开一个会话，让它像资深技术专家（Staff Engineer）那样审阅计划。这相当于设计评审，也是发现方向错误成本最低的阶段。审阅计划时，要寻找背后的假设；在一对一交流中，这就相当于问：“你对哪些地方还不确定？”

任务拆分也越来越多地交给智能体完成。Claude Code 的 /batch 可以把一项大规模、机械性的改动拆成 5 到 30 个任务，展示计划，在各自独立的 Git 工作树（worktree，即代码库的独立检出目录）中执行，并分别创建 PR。你不必再亲自拆分，只需检查各部分是否重叠，并确保共享接口先完成合入。否则，所谓并行可能只是假象。五个智能体同时处理重叠的任务，不会带来五倍产出，只会带来一场有五个作者参与的合并冲突。

尽早纠偏，及时重开

推荐做法：留意智能体开始工作后的第一分钟，及时引导。一发现偏离方向，就纠正它。如果已经连续两次纠正失败，就换一个新会话，用更好的提示词重新开始。

应避免的做法：第三次、第四次继续试着纠正智能体，却不修改最初的要求。

有经验的经理知道，一个有能力的人多次没做好，问题可能出在上游的指令、背景信息或任务范围上。对智能体，对应的做法很明确：一旦它偏离方向，就按 Esc。如果已经有两次纠正未奏效，就清空会话，吸取刚才的教训，重新写一条更清楚的提示词。第三次继续纠正，通常只是让模型多了一堆需要反复阅读、重新处理的信息，其中还包括那些失败的尝试。

低成本回退也改变了局面。/rewind 可以把代码和对话恢复到此前某个节点，让你先尝试更大胆的方案，而不用承担太大风险。好的经理对团队成员也是如此：如果犯错后撤回的成本很低，就让他们试试更有雄心的做法。之后再复盘；如果适用，就把修正中可复用的经验写进 CLAUDE.md。

把任务交出去，判断权留在自己手里

推荐做法：智能体执行工作，你决定重要的事情：产品取舍、安全边界，以及哪些改动可以交付。审查每一份代码差异时，都要假定出了问题会由你接到告警、负责处理。

应避免的做法：只因为测试全绿、命名看着合理，就批准大规模改动。这不是代码审查，只是在给代码盖章。

没有哪个经理可以说：“那是我的下属交付的，不是我。”你运行的每个智能体也是如此。我自己就掉进过这个陷阱。我让一个智能体研究我们与竞品之间的差距，并在本地准备相应的 PR 来补齐差距。我读了研究结果，粗略看了代码，差点就推送了那些对用户收益很小、却会增加使用复杂度的改动。我委派了执行工作，也险些把决策一起交了出去。掉进这个陷阱很容易：600 行代码差异，命名看着合理，测试全绿，那就批准吧。

比较合理的分工是：让智能体处理代码风格、静态检查、审查意见的后续修改、常见缺陷和单元测试；安全边界、合规和产品决策则由人负责。

协调工作同样如此。智能体可以跟踪交接情况，但在相互冲突的请求之间作取舍、让相关人员真正作出承诺，仍然是人的工作。

你不必参与每一次改动的具体执行过程，但外围的决策与验收仍然必须由你负责：约束是什么，产出中你实际读了多少，保留哪些证据，哪些事项必须由人批准。还要让每次改动尽量小，因为每次审查覆盖的范围，也决定了你需要一次理解多少内容。

设计一套不需要你盯着的执行流程

推荐做法：启动自主执行的任务前，先定义完成条件、自我验证方式、权限边界、运行限制，以及需要人工批准的环节。

应避免的做法：睡前启动一个长时间运行的任务，却没有定义什么算完成、何时应该停下，第二天才发现模型整夜都在基于错误前提工作。

更高层的管理者不会直接管理每位工程师的具体工作，而是通过目标、保障机制、检查节点和团队负责人来管理。AI 智能体也在走类似的路。它们已经会把部分任务委派给子智能体，还能定时自主运行，或在 CI 失败、新 PR 创建后自动启动。更前沿的方向，是能够自行启动、自行验证，仅在需要决策时才请人介入的自主系统。

你的角色正在从控制每个会话，转向设计整个执行与反馈流程。设计一次无人值守的运行时，需要问自己的五个问题，与优秀经理把项目交给高级工程师、然后去休假之前会问的问题一样：

• 它知道怎样才算完成吗？可以是目标条件、规格说明文件，或者一个必须修到通过的失败测试。
• 它有自我验证机制吗？例如测试套件、Stop 钩子，或审查环节。
• 它的操作边界是什么？例如权限控制、沙箱、工作树，或唯一允许推送的分支。
• 它的运行限制是什么？例如轮数上限或费用上限。
• 它把结果放在哪里，由谁批准？例如 PR 或总结；任何不可逆的操作都要由人批准。

指南还提到两项管理者很熟悉的好习惯：先试点，比如让批处理任务先跑三个文件，调整提示词后再处理剩余文件；对于任何新的工作流程，先观察最初几次运行，再放心让它无人值守。可以把这看成一个试用期。

扩展验证能力，而不是投入更多注意力

推荐做法：只有当检查机制、目标条件和使用全新上下文的审查者能够接手监督时，才相应扩大智能体的使用规模；除了产出数量，也要衡量质量。

应避免的做法：开的会话多到自己无法认真审查，却用 AI 写了多少代码来衡量成功。

经理很快就会发现自己的管理幅度有多大。直属下属超过一定数量后，每个人得到的关注都会减少，质量也会下降。智能体也是一样。我把这叫作“编排税”：超过最初几个智能体后，每多一个，都比前一个更消耗你的注意力。大多数时候，我会运行四五个后台智能体，再加上几个本地会话；有些日子，这样也已经太多了。

管理大量会话，并不是靠超强专注力，而是把大部分监督工作交给自我评估、目标检查和使用全新上下文的审查者，把注意力留给决策。用通知代替反复查询，并集中查看后台任务，也会有帮助。你无法靠盯得更紧来扩大智能体数量，只能让它们更少需要你盯着。

然后，要衡量整个系统，而不是活动量本身。有用的指标包括 PR 从开始到完成的周期、新员工上手所需时间，以及回退或返工的频率。AI 编写代码的比例不是有用的目标，因为你真正追求的是质量与可靠性。格鲁夫所说的“用配套的制衡指标一起衡量”在这里同样适用：如果统计合入的 PR 数量，就也要统计回退和返工。

决定哪些东西不该做

推荐做法：先问谁需要它、怎样知道它有效、什么情况下应该停止，并限制同时进行的工作量（WIP）。

应避免的做法：因为实现成本低，就把每个看似可行的想法都做成 PR。这样只会留下一个杂物抽屉，等着团队去审查、保障安全和维护。

经理最重要的一句话，往往是“不”。有了智能体，说“不”反而更难了。启动一项工作的成本几乎为零，任何看似靠谱的想法，都能在午饭前变成 PR。可随后，你就有了一堆需要团队审查、保障安全、提供支持和长期维护的 PR。如今真正稀缺的是审查和验证资源。

实际上，那些老派的管理问题比过去更加重要了：是谁提出的需求？怎样衡量成功？怎么知道该停下？如果实现很便宜，难题就不再是“能不能做”，而是“该不该做”。

这个类比有哪些不成立的地方

推荐做法：借鉴管理中的好方法，同时考虑智能体的不同之处：返工便宜、容易附和，以及每次模型更新都可能改变的能力强项。

应避免的做法：把智能体等同于初级开发者，或者因为自己能运行五个智能体，就觉得已经准备好管理五个人。

这个类比有用，但并不完美。真正善于这样工作的人，清楚它在哪些地方不成立：

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

你不需要经理这个头衔

推荐做法：把精力放在促成优秀软件的诞生上：交代背景、定义完成标准、认真审查。

应避免的做法：一边运行那些任务说明不足、缺少检查的智能体，一边仍用代码行数来评价自己。

优秀的 Staff Engineer 一直都是这样工作的。他们写设计文档，交代背景，认真审查，并帮助身边的人做得更好。智能体让所有工程师从第一天起就有机会实践这些能力，给你上一堂管理速成课。反馈几分钟就能得到，不必等上几个季度；你犯的错也可以撤回。工作的重心，正在从亲手写代码，转向促成好代码被写出来。

没人天生就是优秀的经理，也没人天生就是优秀的工程师。你仍然要通过练习积累能力，和过去一样。只是有了智能体，练习的成本很低。

可以从这些做法开始：

• 每项任务都要有它能运行的检查，并要求它拿出证据。
• 告诉它那些看不到的信息，能自己看到的就不必赘述。
• 先把计划讨论清楚，再写代码。
• 同一件事纠正过两次？记进 CLAUDE.md。反复使用的工作流程？做成 Skills。
• 两次纠正都失败了？重新开一个会话，换一种方式说清要求。
• 审查代码差异时，要假定出了问题会由你接到告警。

你不必想成为经理。但那些善于使用智能体的工程师，会在这个过程中学会管理。

作者：Addy Osmani
原文标题：Your coding agents made you a manager
原文链接：https://x.com/addyosmani/article/2119332146485891501