你一整天做的，其实是经理的活
一件很常见的事：交代一句「把团队仪表盘弄快点」，Agent 立刻开工，交回来看着是做完了，一跑才发现不对。这一句里没写的东西，全留在你脑子里：快到多少算快，为谁快，数据库能不能动，拿什么交差。Agent 不会追问，接了就干。你指出问题，它改，改完又歪到别处。会话开得越多，你的时间越是花在等它交活和替它验收上。
在 Anthropic 做 Claude Code 的 Addy Osmani 把这件事写成了一篇文章。陪着编程 Agent 过一整天，你反复在做的是挑任务、写说明、派活、跟进、看结果、决定哪些上线，这六个动作和带团队重合。用好 Agent 的人往往已经学会了管，有意无意都一样；提示词写得最花的那批人，在这件事上不一定占便宜。
他知道这话不讨喜。他佩服的很多工程师走一线路线，就是为了离活近一点，也见过朋友当上经理后消失在日程表里。他说的「管」是一件具体的事：让别人把活干好，由此拿到好结果。Agent 也替代不了经理和同事。他还有一句更狠的话：你对坏经理的每一句吐槽，都是一份和 Agent 打交道时的 bug 报告。一线工程师有个便宜可占：你接了这么多年活，挨过含糊的需求、缺背景的交接、中途改口的期望，一次好的交接长什么样，你其实知道。
文章把十条做法按影响力排序，从「给它一条能自己判断过没过的检查」一直排到「决定不做什么」，最后单独说这个比喻在哪里不成立。
第一条：给它一条能自己判过没过的检查
问一个有经验的经理，你不逐行看代码，怎么确信团队干得好？他会说靠护栏：每次提交自动跑的检查、代码审查、仪表盘、轮流值班。没搭护栏的新经理什么都要自己验，一个季度下来，他成了整个团队最堵的那个口子。Agent 一样，它在「看起来做完了」的时候停下。没有检查办法，「看起来做完了」就是它唯一的完成信号，验收全落回你身上，你成了它的测试。
检查办法几乎什么都行，只要能判出过还是没过。测试套件、打包的退出码、linter（自动检查代码风格和常见错误的工具）、把输出和标准答案逐行比对的脚本、一张对着设计稿的截图，都算。改界面的活，可以让它真在浏览器里打开页面，一遍遍改到能用、好看为止。Claude Code 的官方最佳实践把这件事写成一句话：CLAUDE.md 里最有用的那一行，就是跑检查的那条命令。
力度分四档，按你对结果的确定程度往上加。直接在任务里写明「改完跑一遍登录相关的测试，没过就接着改，直到全过」，由它自己判断什么时候算过关。用 /goal 设一个完成条件，每轮结束由另一个模型来判断达标没有，长时间在后台跑的活最用得上。用 Stop hook 强制，检查不过就不许这一轮结束：脚本以退出码 2 退出，类型检查打印到标准错误的内容会回到模型手里，这一轮就结束不了。用 /code-review 把改动交给一个没看过你们对话的新子 Agent 审，像作者不批自己的改动。
审查范围要写清楚。叫它找问题，它总能找出点什么，逐条改完，你会多出一层用不上的抽象和一批为不可能发生的情况写的测试；叫它只找会让功能出错的地方、风格不用管，它就照这个来。好经理找人要反馈也是这么问的。Claude Code 里的 skill（打包好的一套做法）、hook（到点必定执行的自动程序）、子 Agent、MCP（把外部工具接给它的通道），多半都在补「干完活」和「验收」之间那道缝，你只剩它自己验不了的那部分要操心。
第二条：只写它读代码读不到的东西
好经理讲清楚要什么结果、有哪些限制，怎么做留给干活的人。军队把这叫「指挥官意图」，Netflix 叫「给背景，不控制」。
难点在于你很难知道 Agent 缺哪些背景。它接到任何任务，第一件事都是读你的代码，目录怎么分、命名有什么习惯、测试怎么搭，现在的模型摸清这些，比你讲给它听快得多。所以动笔之前先问两句：它能从代码里读到吗？它真的会去读吗？两个答案都是「是」，这句就不用写。
字该花在仓库外面：会上定下的事、某个人脑子里的上线流程、这个任务为什么重要、这一次怎样算完成。一句含糊的「把仪表盘弄快点」，可以改写成五行的说明，下面的数字只是举例。
- 目标：把成员过万的组织里 /team 仪表盘的 p95 加载时间（100 次打开里有 95 次不超过这个时间）压到 2 秒以内。
- 为什么：企业管理员每天都要打开它，加载慢是他们提得最多的工单。
- 约束：不改数据库结构，接口返回的数据格式保持不变。
- 不做：改界面，给整个页面加缓存。
- 验收：跑 scripts/perf/team.sh，把改动前后的数字都给出来。
每一行补的都是它读代码读不出来的东西。目标把「快一点」变成能量的数，p95 盯的是慢的那一头。为什么告诉它这活是为谁做的，两条路都能走时它知道往哪边偏。约束和「不做」是它读代码猜不到的红线。验收就是上一节那条检查命令，加上改动前后的对比。
探索性的活不必这么写，一句泛泛的提示词，边做边调就行。还没想清楚要什么时，反过来让它采访你：先别写代码，一个一个问，直到它能写出完整的需求说明，把这份说明存成文件，再开一个新会话照着做，做完还能拿它来对照验收。别的系统也一样，任务系统、报错看板、团队聊天，像给新同事开账号那样把工具接给它；它本来就会用的 gh 这类命令行工具，不用多交代。
第三条：同一件事纠正两次，就写下来
很多人每开一个新会话，就把同一件事再纠正一遍，或者靠只存在自己电脑上的默契，换个人接手就没了。同一句话被纠正两次，就该写进团队共用的 CLAUDE.md；一套反复要走的流程，就做成大家共用的 skill。Claude Code 官方建议把这类东西写短：CLAUDE.md 的每一行都会在每次任务里分走一点模型的注意力，所以它只该装模型从代码里看不出来的东西。
该写进去的有四类。第一类是怎么验证，具体到测试、类型检查、lint 的命令，以及怎么只跑一个测试文件。第二类是代码里容易让人误会的地方，比如到处都是但新代码不能再抄的旧写法、看着没人用其实在用的目录。第三类是仓库里没有的决定，团队最后选了哪个错误处理封装、上线怎么做、哪些改动要过迁移评审。第四类是你纠正过两次的任何事。
把 CLAUDE.md 用出价值的团队会隔三岔五更新它，把值得防的错误写进去，有的团队在代码审查里直接 @claude，让一条审查意见变成以后都生效的规矩。写下来的东西会累积，人换了组、模型换了代，它还在。反方向的动作也要有：隔段时间回看，新模型已经不用再纠正的那几条，删掉。
第四条：默认让它拿主意，只钉死不能弯的
英特尔前 CEO 格鲁夫在《高产出管理》里讲过「任务相关成熟度」：管多严，看这个人在这一件具体的事上过去做得怎么样，不看他整体有多能干。给新经理的老建议也是这个意思：给人的空间比你觉得舒服的再大一点，同时给他兜底，也让他对结果负责。
Claude Code 把这件事分成两类，说得很明白。提示词、CLAUDE.md、skill 是「请求」，模型会考虑，也可以选择不照做；hook、禁止规则、统一托管的设置是「要求」，一律执行。多数时候该让它自己判断，看着真实代码的模型，常常比你提前定下的规矩更清楚这条规矩在眼前适不适用。
强制留给少数红线，比如「绝不改自动生成的那份客户端」「每次都要跑加版权头的脚本」。新的终端和 VS Code 会话默认在 auto mode（自动模式）下跑，一个分类器会把部署到生产、强推覆盖别人的提交这类危险动作拦下来。
两个方向都能调。某一行 CLAUDE.md 你加重了语气它还是不照做，说明这一行该变成 hook；某个 hook 表达的其实只是偏好，就删掉，改回让它自己决定，像团队退掉一条不再有用的流程。换了新模型也要跟着调。官方那份清单里有一批可以停掉的习惯：全大写的要求、「think harder」（现在努力程度是一个设置项）、「别偷懒」；它们在现在的模型上更容易把规则执行过头，也把活干过头。用过量的流程管 Agent，是新的微观管理。
第五条：先对计划，再让它动手
好用的顺序是先进入计划模式，把计划改到对，再让它写代码。计划对了，模型常常一遍就能建完。大一点的活另开一个会话，让它像资深工程师那样通读计划，这是一次设计评审，也是抓错方向最便宜的地方。看计划时盯隐含假设，换成一对一会问的那句是：「你有什么不确定的？」
拆分也越来越多交给 Agent。/batch 把一处大的机械改动拆成 5 到 30 个任务，先把计划给你看。批准之后，每个任务在各自独立的 worktree（同一仓库的多份检出目录）里执行，并开一个 PR（一份等人审、审过才合进主干的改动）。你只需要查这些切片有没有重叠，以及共享接口是不是先落地。这一层不做，并行是假的。五个 Agent 抢着改重叠的地方，换来的是一次合并冲突，作者有五个。
第六条：偏了就早点拉，拉两次就重开
有经验的经理知道，一个能干的人接连失手，问题多半出在上游：说明、背景或者范围没给对。换到 Agent 身上，这条规矩更硬。开工后第一分钟值得盯着，一旦偏了，立刻按 Esc 打断。
如果已经纠正了两次还没回来，清掉会话，把学到的东西写进新的提示词重开。第三次纠正基本上只是让模型反复重读一堆失败的尝试，包括前面那些纠正。要改的是需求，接着纠正只会把上下文越堆越乱。
便宜的回滚也在改变打法。/rewind 能把代码和对话退回早先某一步，先试更大胆的做法，风险就低了。好经理对人的做法一样，撤销的代价低，就让人去试。事后补一次复盘，能通用的写进 CLAUDE.md。
第七条：活可以交，判断不能交
没有一个经理能说「这是我下属发的，不是我」。你开的每个 Agent 也一样。Osmani 自己也掉进去过：他让一个 Agent 去调研产品和竞品的差距，并写本地 PR 把这些差距补上。他读了调研，扫了代码，差点把一批给用户增加复杂度、收益又很小的改动推上去。活派出去了，判断也差点一起派出去。这个坑很好踩：diff（一处改动的逐行对照）有 600 行，命名看着合理，测试全绿，就批了。那已经不算代码审查，只能算替它盖章。
分派有条线：风格、lint、审查意见的跟进、常见 bug、单元测试，可以整段交给 Agent；安全边界、合规、产品决定留给人。协调也一样，Agent 可以帮你盯交接，几个互相冲突的请求谁先谁后、怎么让人真的答应下来，仍然是人的活。
你不必待在每一个改动里。内圈是它自己改到检查过关，外圈得你拿着：约束是什么，它交回来的东西你到底读多少，留什么证据，什么必须人签字。改动还要小，审查的单位就是理解的单位。
第八条：过夜之前，先回答五个问题
跳级经理（经理的经理）不管每个工程师怎么干活，他管目标、护栏、检查点和下一层主管。Agent 正在走同一条路：它已经把任务的一部分派给子 Agent，也能按计划、CI 失败（每次提交自动跑的那套检查）、新 PR 被打开之后自己跑起来。再往前是自治理的系统，能自己开工、自己验收，只在需要决定的时候叫人。
你的角色从盯会话，变成设计这条循环。放一个不需要你看着的运行之前，先把五件事答完，和一个好经理把项目交给资深工程师、自己出门度假前要想的一样。它得知道什么叫完成：目标条件、一份规格文件，或者一条必须跑绿的测试都算。它得有自检机制，测试套件、Stop hook，或者一道审查步骤。边界要写死在权限控制、沙箱（一个跑坏了也碰不到外面的隔离环境）、worktree，或者只许它推的那一个分支（代码的一条独立支线）上。护栏是轮次上限或花费上限。产出落在一条 PR 或一份总结上，不可逆的动作要人批。
还有两条经理习惯也照搬了。先试跑：让批处理任务只跑三个文件，把提示词调顺，再跑剩下的。新东西的头几次运行要看着，像试用期。
第九条：能开几个 Agent，取决于要你盯的有几个
经理很快就知道自己的管理跨度：能带好的人数有限，直接下属过了某个数，每个人分到的精力都变少，质量往下走。Agent 也一样。Osmani 把它叫编排税：过了头几个，每多一个 Agent，要的注意力比上一个更多。他多数日子跑四到五个后台 Agent，再加几个本地会话，有些日子这已经太多了。
同时开很多会话，靠的是把大部分监控交出去：交给自评，交给目标，交给带着新上下文的审查者，把注意力留给决定。这比单纯靠专注力撑得住。通知代替轮询、后台任务集中在一处看，也能省下不少。Agent 的数量没办法靠盯得更多来扩，只能靠需要盯得更少来扩。
然后量系统，别量热闹。有用的指标是 PR 的周期时间、新人上手时间、回滚和返工的频率。AI 写了多少比例的代码，只说明产量；质量和可靠要靠回滚、返工这类数字来看。格鲁夫讲量一个数就要配一个能拆穿它的数，这里同样：量了合并的 PR 数，就同时量回滚和返工，免得大家为凑数字牺牲质量。
第十条：构建变便宜了，「不做什么」更值钱
经理最重要的一个词常常是「不」。有 Agent 之后这个「不」更难说出口：开工几乎不花钱，午饭前就能把每个想得到的点子塞进一个 PR。代价在后面，一堆 PR 要人看、要过安全、要支持、要长期维护。现在稀缺的是审查和验证。
老的管理问题反而更值钱：谁要的，怎么量成功，什么情况该停。构建便宜的时候，难的问题从「能不能做」变成「该不该做」。同时开工的线路要限数，否则审查会堆成一条永远读不完的队列。
这个比喻在哪里不成立
类比好用，但不完整。真正常用这套做法的人清楚它哪里会断，断的地方有七处。
管人更难，技能不会倒着传。跑过五个 Agent，不等于会带五个人：激励、冲突、职业发展、花几个月建立的信任，在这些 Agent 身上都没有对应物。
返工几乎免费。你可以问 Agent 一些绝不会问人的事：白板上吵不清的技术分歧，让它做两三个版本摆出来比。
Agent 没有经验，只有一个笔记本。自动记忆只记在一台机器上，不进同事的会话；你在职业生涯里攒下的那些判断，得自己写给整个团队。
Agent 又积极又自信。请一位好工程师去做一件错事，他会顶回来；Agent 更可能照做，你也更容易过度信任它。沃顿关于「认知投降」的研究里，参与者多数时候接受了带错的 AI 答案，而且越用越有信心。可以反过来让它论证自己的答案哪里不对。
你只有一种 Agent，而且几个月换一次。人团队里技能和长处各不相同，你的 Agent 强弱都一样，随每次模型发布整体平移。
初级工程师还得你自己带。起步的活被 Agent 接走以后，那些让新人练基本功的机会，要当经理的人刻意造出来。
人团队也仍然重要。有时你管一天 Agent，没意识到已经把搭团队的时间挤掉了。
你不需要那个头衔
好的资深工程师一直是这样干活的：写设计文档、定上下文、认真评审、让身边的人变强。Agent 让所有工程师第一天就能做这些，也等于给你开了一门管理速成课：反馈以分钟计，不用等一个季度，自己的错还能撤回。这份工作越来越少是写代码，越来越多是让好代码有理由被写出来。
没人天生会当经理，也没人天生会当工程师，都是练出来的。有 Agent 之后，练习很便宜。可以直接上手的有六条：
- 每个任务配一条它能跑的检查，然后要证据。
- 说它看不到的，省掉它能看到的。
- 写代码之前，先把计划讲一遍。
- 纠正过两次的事记进 CLAUDE.md，重复的流程做成 skill。
- 两次纠正没回来，就重开并改写提示词。
- 把每个 diff 当成会半夜把你叫起来的那种来审。
你不必想当经理。用好 Agent 的工程师，都会在路上学会管。
