你的编程智能体把你变成了管理者

原文出处：由 @addyosmani 发布于 X。

管理智能体所需的技能，差不多就是管理一个团队所需的技能，而你不需要先成为管理者才能学会它们。

如果你整天都在和一个编程智能体打交道，那你就是在做管理。你在一遍又一遍地挑选任务、写指令、委派、跟进、评估结果，并决定什么能上线。从智能体身上获益最多的工程师，未必是最擅长提示词工程的那些人，而是学会了如何管理的那些人——不管他们是有意为之，还是不知不觉。

这个说法可能不太受欢迎。我敬佩的许多工程师之所以选择个人贡献者（IC）的职业路径，是因为他们想贴近实际工作。他们见过朋友当上管理者后，整个人消失在日历里。但我并不是让你去当那样的管理者。我说的"管理"有一个特定含义：通过让他人的工作得以开展，来产出好的结果。我当然也不是说智能体可以替代管理者或同事。

你对糟糕管理者的每一条抱怨，其实都是一份讲"如何与智能体打交道"的缺陷报告。想想交接这件事。如果你经历过一次糟糕的交接，你可能收到过一个让人感觉很含糊的任务请求，它缺少上下文，或者期望不断变化。对个人贡献者（IC）来说，好消息是：既然多年来你一直处在接收交接的那一端，你大概知道一次好的交接应该是什么样。

我之前写过，你的编程智能体需要一位管理者。我也写过委派带来的那种安静风险，即认知投降。本文把优秀工程管理者的做法，与我们在使用和构建 Claude Code 过程中学到的东西做对比。各小节大致按影响力排序，因此杠杆率最高的习惯放在最前面。

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

最佳实践： 给智能体提供一种验证其工作的机制，比如测试套件、构建或截图，并让它把结果展示给你作为凭据。

反模式： 把"看起来做完了"当成确认。这会迫使你承担所有验证工作，让你变成智能体的人肉测试套件。

去问一位有经验的管理者：他如何在不读完所有东西的情况下确信团队在产出好的工作？他会谈防护机制（guardrails）。CI、代码评审、看板、on-call 值班，等等。不搭建防护机制的新手管理者，最终会自己验证每一件事，一个季度之内他们就变成了瓶颈。智能体也是同样的道理。正如 Claude Code 最佳实践指南所解释的，智能体在工作"看起来完成"时就会停下来。如果没有验证，那么"看起来完成了"就是智能体唯一拥有的验证。提供一种验证工作的机制，能让智能体自己完成工作、运行验证器、看到失败，并自行纠正。对于 UI 改动，这可能意味着真的在浏览器里打开那个页面，反复迭代，直到它能正常工作、看起来也顺眼。

验证机制几乎可以是任何东西，只要它能给出明确的通过/失败结果。想想测试、构建退出码、linter、diff 脚本和截图。指南指出，运行这些验证的那条命令，是你能写进 CLAUDE.md 里的最有价值的一行——CLAUDE.md 就是智能体每个会话开始时读取的说明文件。一旦你有了验证机制，下面是一些把它带进工作流的办法：

• 直接要求。"之后跑一遍认证测试，一直跑到达标为止。"
• 设定目标。 用 /goal，一个单独的模型会在每一轮之后运行条件检查，这在做长时间后台工作时最有用。
• 强制执行。 一个 Stop 钩子可以阻止这一轮结束，直到类型检查通过。
• 让它被评审。 /code-review 会把 diff 发给一个新的子智能体（它没看过你的对话）去评审，就像作者不批准自己的 PR 一样。

你甚至可以控制评审的范围。如果你让它找问题，它总能找到点什么。但如果你让它找正确性问题、忽略风格问题，它就会照着做。优秀的管理者也是以这种方式学会如何索要反馈的。Claude Code 工具包里的大部分功能，都是为了让这个闭环更紧：Skills、hooks、子智能体和 MCP 的存在，都是为了弥合"做工作"与"验证工作"之间的落差，让你的注意力只落在智能体验证不了的那些事情上。这正是经验丰富的工程管理者所做的事。

把上下文交代清楚

最佳实践： 清楚地概述智能体无法通过查看仓库得知的信息，包括：任务的目标以及它为什么重要、约束条件、不在范围之内的事项，以及成功标准。

反模式： 只丢一句任务描述，而真实的期望只存在于你脑子里；或者用智能体只要读代码就能发现的内容把说明撑得很长。

高效的管理者会清楚地描述期望的结果、约束和目标。他们会说明这项工作应当达成什么，但把"怎么做到"的自由留给做事的人。在军事上，这被称为"指挥官意图"；在 Netflix，这被称为"上下文，而非控制"。

与智能体合作的难点在于，你很难知道智能体缺了哪些上下文。编程智能体在每个任务里做的第一件事，就是读你的代码。当前的模型非常擅长捕捉你的目录结构、约定和测试配置，速度比你描述它们快得多。

在你写下任何东西之前，先想一想智能体能自己搞清楚什么。如果智能体能在你的代码里读到它，而且它确实会去读，那你就什么都不用说。把话用在仓库里没有的那些部分上——比如某次会议做出的决定、某个人内部的部署流程、这个任务为什么重要，以及这一次"完成"具体意味着什么。

我们拿一个含糊的任务"让看板快一点"为例，把它变成一个提示词。这里的数字只是举例。

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

原因：企业管理员每天都开它，加载慢是他们最常提的支持工单。

约束：不做 schema 变更；保持 API 响应的结构不变。

不在范围内：UI 改动；整页缓存。
检查：运行 scripts/perf/team.sh，并展示改动前后的数字。

你不需要对每个任务都这么做。如果你在做探索性的工作，写一个泛泛的提示词完全没问题，边走边细化就好。如果你还没准备好写提示词，可以让智能体来采访你，直到它能写出规格说明；把这份规格存成文件，然后开一个新会话，让智能体据此动手。之后你还可以用这份规格来做对照评审。

你可能还需要让智能体访问其他工具，比如你的 issue 跟踪系统、错误看板或团队聊天。对待你的智能体，就像对待团队里新来的员工一样。如果它是像 gh 这类智能体本来就熟悉的 CLI 工具，你通常什么都不用说。

让每一次纠正都能累积

最佳实践： 当你对同一件事纠正了不止一次，就把它记录在团队的 CLAUDE.md 里，或者把它变成一个共享技能。随着时间推移，还要检查新模型是否让这些纠正变得不再必要。

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

把 CLAUDE.md 价值最大化的团队会较为频繁地更新它，并把那些值得预防的错误教训写下来。有些团队甚至在代码评审里提及 @claude，把反馈变成长期策略。让 CLAUDE.md 保持简洁。下面是适合写进去的内容类型：

• 如何验证某件事（确切的命令）
• 代码中容易误导人的区域
• 仓库里并不存在的决策
• 任何你纠正过两次的东西

这些都是书面信息具有累积效应的例子。它比人员换团队、模型被替换都活得更久。

让它自己决定，只强制那些不能变通的事

最佳实践： 默认让智能体自己决定，只对极少数"必须总是发生"或"绝不能发生"的事情使用硬性强制手段（例如 hooks、deny 规则）。

反模式： 用全大写字母写规则、为可选的偏好定义钩子，或者在新模型早已超越旧习惯很久之后仍然保留它们。

Andy Grove 在《高产出管理》（High Output Management）中把这称为"任务相关成熟度"：监督的强度应当取决于这个人在这项具体任务上的历史表现，而不是他的整体能力。

一条给新管理者的老建议说的是同一件事：给人们比你感到舒适的程度稍多一点自由度，同时在他们背后支持他们，并让他们承担结果。

Claude Code 把这一点明确化了：提示词、CLAUDE.md 和 skills 是"请求"，模型可以考虑并选择是否执行；hooks、deny 规则和托管设置（managed settings）则是"要求"，始终被强制实施。在大多数情况下，你希望由智能体来做判断。很多时候，模型看着真实代码，比你事先定下的规则更清楚某条准则是否适用。用强制手段来设定硬性要求，比如"绝不编辑生成的客户端"或"始终运行 license-header 脚本"。特别要提的是，新的终端和 VS Code 会话以自动模式启动，其中有一个分类器会过滤掉部署到生产环境、或在别人工作上强制推送这类不安全行为。

指南的建议有两面。如果你加重了 CLAUDE.md 中某一行的分量，而智能体仍然不照做，那它就应该变成一个钩子。如果一个钩子表达的其实是偏好而不是要求，那它就应该被移除，改由智能体自行决断。这就像你的团队决定退役一个不再有用的流程。这也意味着有了新模型时要做出调整。指南保留了一份"你可以停掉的习惯"清单：全大写的指令、"再努力想"（现在努力程度只是一个设置项），以及"别偷懒"。在当前的模型上，这些往往会导致过度强制的规则和过度劳动。和智能体一起工作时，过度流程化就是新的微管理。

动手之前先做计划

最佳实践： 在智能体开始写代码之前，先约定一份计划，读出其中隐藏的假设，并把任务切分成互不重叠的并行工作。

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

这里有个好用的工作流：先进入计划模式（plan mode），反复打磨计划直到它变得正确，然后再把编码委派出去。有了好的计划，模型通常能一次就把它建出来。对于更大的任务，用第二个会话像资深工程师那样把计划过一遍；这是一次设计评审，也是发现走错方向最便宜的时机。评审计划时，要留意其中隐藏的假设（在一对一沟通中，这相当于问："你有什么不确定的地方？"）。

任务分解正越来越多地被委派给智能体。Claude Code 里的 /batch 会拿一个大体机械性的改动，创建 5 到 30 个任务，展示计划，在各自独立的 worktree（仓库的独立检出）里执行它们，并为每一个创建 PR。你不再需要自己拆活儿，只需检查各个切片之间是否重叠，并确保共享接口先落地。否则，你可能得到一种虚假的并行度。五个智能体接手相互重叠的任务，不会换来五倍的产出，只会换来一个涉及五位作者的合并冲突。

及早掌舵，快速重启

最佳实践： 盯住第一分钟并给智能体掌舵。一旦发现它跑偏，就立刻纠正。如果你已经做了两次失败的纠正尝试，就用一个新会话和一个更好的提示词重新开始。

反模式： 在纠正智能体这件事上再加第三次、第四次尝试，而不是去纠正你的请求。

有经验的管理者知道，如果一个有能力的人多次出现失误，问题可能出在上游的指令、上下文或范围。智能体版本的做法很明确：一旦智能体跑偏，就按 Esc。如果你已经做了两次失败的纠正尝试，就清空会话，写下更好的提示词，把你学到的教训纳入进去。对智能体的第三次纠正尝试，大多只是给模型更多需要反复重读、反复处理的信息（包括那些失败的尝试）。

廉价的回滚也在改变游戏规则。/rewind 会把代码和对话回滚到更早的时间点，让"先试一个更有野心的方案"变得风险很低。优秀的管理者对待员工也是如此：如果撤销错误很便宜，就让他们去尝试更有野心的做法。然后在事后做复盘，如果适用，就把修复推广进 CLAUDE.md。

可以委派任务，绝不委派判断

最佳实践： 智能体做工作，你来决定重要的事：产品决策、安全边界、什么能上线。对待每一份 diff，都像你会因为它半夜被叫起来处理事故一样。

反模式： 因为测试是绿的、命名看起来也合理，就批准一大份 diff。这不是代码评审，这是给代码盖章追认。

没有哪个管理者能说"这是我下属上线的，不是我"。你运行的每一个智能体也一样。我自己就掉进过这个陷阱。我让一个智能体去调研与竞争对手之间的差距，并写本地 PR 来补齐这些差距。我读了调研，扫了一眼代码，差一点就去推送那些给用户增加了复杂度、收益却很小的改动。我委派了工作，差一点也把决定一起委派出去了。这个陷阱很容易掉进去：这是一份 600 行的 diff，命名看起来合理，测试是绿的，批准吧。

按这个思路切分任务是合理的：让智能体去做样式、lint、评审的后续跟进、典型 bug 和单元测试，但把安全边界、合规和产品决策留给人。

协调也是同样的道理。智能体可以跟踪交接，但在相互竞争的请求之间做取舍，并让人们真正承诺下来，仍然是人的工作。

你不需要身处每一个改动的内环。你真正需要拥有的是外环：约束是什么、你实际读了产出中的多少、你保留了什么证据，以及哪些事必须由人签字确认。并且保持改动小，因为评审的单位就是理解的单位。

设计一次不需要你在场的运行

最佳实践： 在部署一个自主任务之前，先定义好"完成"、自我验证、边界、防护机制以及人工批准环节。

反模式： 睡前启动一个长时间运行的进程，既没有完成的定义也没有停止点，第二天早上醒来发现模型整夜都建立在一个错误的前提上工作。

跨级管理者（skip-level manager）不管单个工程师的工作，他们管的是目标、防护机制、检查点，以及团队负责人的工作。AI 智能体正沿着相似的轨迹发展。它们已经在把任务的一部分委派给子智能体，并且可以按计划、在 CI 失败后或在新的 pull request 打开后自主运行。更前沿的是自治系统：它们能自主启动、自我验证，只在需要决策时才请求人工介入。

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

• 它知道"完成"长什么样吗？（目标条件、规格文件，或者一个它必须让它变绿的失败测试。）
• 它有自我验证机制吗？（测试套件、Stop 钩子，或评审环节。）
• 它的边界是什么？（权限控制、沙箱、worktree，或者它唯一被允许推送的那个分支。）
• 它的防护机制是什么？（轮次上限或花费上限。）
• 它在哪里产出结果，谁来批准？（一个 PR 或一份总结，以及任何不可逆操作的人工批准。）

指南里还有两个管理者会认作良好实践的习惯：试点（pilot），也就是让一批任务先在三个文件上跑起来，迭代提示词，然后再跑剩下的；以及在你放心让它无人值守之前，先观察任何新东西的头几次运行。把它想成试用期。

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

最佳实践： 只有当检查、目标和全新视角的评审者能够接手"盯着"这件事时，才按同样的速度扩大智能体的使用规模；并且除吞吐量之外，也要衡量质量。

反模式： 打开的会话数量超过你能好好评审的数量，并用"AI 写了多少代码"来衡量成功。

管理者很快就能摸清自己的管理幅度。超过一定数量的直接下属之后，每个人分到的管理者就更少，质量也随之下降。对智能体也是如此。这就是我所说的"编排税"（orchestration tax）：过了最初几个智能体之后，每增加一个智能体，都需要你比上一个更多的注意力。大多数日子我并行跑四五个后台智能体和几个本地会话，有些日子这已经太多了。

管理大量会话，关键不在于特别专注，而在于把大部分监控工作委派给自我评估、目标和带全新上下文的评审者，把注意力留给决策。用通知代替轮询、并对后台任务有一个集中视图，也会有帮助。你不能靠"多监控"来扩展智能体的数量，只能靠"需要监控的更少"。然后去衡量系统，而不是衡量活动量。有用的指标包括 PR 的周期时间、新员工的爬坡时间，以及回滚或返工的频率。衡量"AI 撰写代码的百分比"并不是一个有用的目标，因为你追求的是质量与可靠性。Grove 关于"用反向指标来衡量"的规则在这里适用：如果你衡量合并的 PR 数量，那就同时衡量回滚和返工。

决定不做什么

最佳实践： 问清谁需要它、你如何知道它奏效了、什么会让你停下来，并限制 WIP（并行在制工作）。

反模式： 把每个看起来可行的想法都塞进一个 PR，毕竟构建很便宜。于是你有了一个杂物抽屉，团队还得去评审、加固并维护它。

管理者最常说的、也是最重要的一个词，往往是"不"。有了智能体之后，"说不"变得更难了。启动一件事几乎不花成本，你可以在午饭前把任何一个看起来可行的想法塞进一个 PR。但这样一来，你就有一堆 PR 需要团队去评审、加固、支持和维护。如今，评审和验证才是稀缺资源。

事实上，那些老的管理问题现在比为过去更重要了。是谁提出的需求？我们如何衡量成功？我们怎么知道什么时候该停？如果构建变得很便宜，那么困难的问题就不是"我们能不能做"，而是"我们该不该做"。

类比在哪里失效

最佳实践： 遵循管理上的最佳实践，但要考虑智能体模型上的差异，比如返工几乎免费、它们有多快就同意你，以及会随每次模型发布而变化的强项。

反模式： 认为智能体就像初级开发者，或者认为既然你能带五个智能体，你就准备好了带五个人。

这个类比有用但并不完美，这项工作最优秀的实践者清楚它在哪里不完美：

• 管人更难，而且这些技能不能反向迁移。 你带过五个智能体，并不等于你准备好带五个人。动机、冲突、职业发展，或者长达数月建立起来的信任，这些都没有对应物。
• 返工几乎是免费的。 你可以让智能体做那些你绝不会让人做的事。如果一场技术争论发生在白板前，智能体可以直接做出两三个方案，让你来对比。
• 智能体没有经验，只有一个笔记本。 自动记忆只在一台机器上记录笔记，不会转移到你队友的会话里。它们不是你在职业生涯中积累起来的经验和判断力，而那些教训你需要写下来给整个团队。
• 智能体既急切又自信。 如果你让一位优秀的工程师做一件错事，他会顶回来。智能体更可能照着你要的做，而你也更可能过度信任它们。在沃顿商学院关于"认知投降"的研究中，参与者大多数时候都接受了错误的 AI 答案，而且信心越来越强。你可以通过让智能体反驳自己的答案来对抗这种过度自信。
• 你只有一种智能体原型，而且它每几个月就变一次。 人类团队有各不相同的技能和强项。你所有的智能体拥有相同的强项和弱项，而这些还会随每次模型发布而变化。
• 你仍然得培养你的初级开发者。 当智能体接管了初级开发者用来学基本功的入门活儿，作为管理者，你必须刻意创造这些练习机会。
• 人的团队依然重要。 有时候你会花一整天管理智能体，却没意识到自己已经挤掉了用来打造一个有凝聚力的团队的时间。别这样做。

你不需要那个头衔

最佳实践： 把精力放在让好的软件真正发生上：设定上下文、定义"完成"、做好评审。

反模式： 一边跑着上下文不足、无人检查的智能体，一边用代码行数来评价自己。

优秀的资深工程师一直都是这样做的。他们写设计文档。他们设定上下文。他们做细致的评审。他们让身边的人变得更好。智能体让所有工程师从第一天起就能做到这些。它们给你上了一门管理的速成课。你得到的反馈以分钟计，而不是以季度计。你可以撤销自己的错误。这份工作正越来越不像"写代码"，而更像"成为好代码得以被写出来的那个原因"。

没有人天生就是优秀的管理者（或优秀的工程师）。你建立技能的方式和过去一样，靠练习。但有了智能体，练习很便宜。

试试这些做法：

• 每个任务都需要一个它能运行的检查。要凭据。
• 告诉智能体它看不见的东西，省略它能看见的东西。
• 在写代码之前先把计划聊清楚。
• 同一件事纠正了两次？写进 CLAUDE.md。工作流反复出现？把它变成技能。
• 两次纠正失败？重启，并改写提示词。
• 评审 diff 时，就像你会因为它被叫起来处理事故一样。

你不必非得想当管理者。但在智能体时代做得好的工程师，都会在这一路上学会管理。