程序员躲开管理岗，Coding Agent 又把他推了回去
Addy Osmani 把管理 Coding Agent 的高杠杆经验摊开：先给验收标准，再谈并发；两次纠偏失败就重置；别把代码审查做成盖章。更扎心的是，很多工程师已经在做管理，只是头衔还没跟上。
Addy Osmani 写了篇长文，主题很直接：你的 Coding Agent 把你变成了经理。
很多工程师走纯技术路线，就是为了不写周报、不开长会、不管人。结果用上 Coding Agent 的第一天，工作内容就变了：选任务、写背景、定验收标准、审代码变更、决定哪些能上线。键盘敲得少了，管理动作多了。Addy 的说法是，工程师的核心工作从亲自写代码，变成让好代码发生。
对不写代码的读者，可以把 Coding Agent 理解成能读代码库、改文件、跑命令、开合并请求的 AI 工具。它动手很快，但不会读心，也不会替你承担上线风险。所以管理动作变得关键：任务要交代清楚，验收要能自动跑，审查要真的看懂。
Addy 把高杠杆经验压在五条上，另外补了几条给长任务和并发用的规则。原文链接放在文末。
最高杠杆：给 Agent 一个自检闭环
最值钱的一条是让 Agent 自己验证工作。给它测试用例、构建命令、代码规范，或者截图验收标准，让它跑、看失败、自己修。没有自检护栏的人，最后会变成系统的瓶颈：Agent 说“看起来完成了”，你只能自己当人肉测试机。
Addy 文章里提到，Claude Code 最佳实践文档给了一个例子：把 /team dashboard 的 p95 加载时间压到 2 秒内，面向 10k+ 成员的组织；约束是不改 schema；不碰 UI；检查脚本是 scripts/perf/team.sh，要展示前后数字。任务目标、约束、不做什么、验收方式都写清楚，Agent 才有机会自己闭环。
Claude Code 里还有几种收紧验证的方式。可以用 /goal 让另一个模型在每轮后检查条件，适合长时间后台任务。Stop hook 可以卡住回合，直到 typecheck 通过。 /code-review 会把 diff 交给没看过当前对话的新子 agent 审查。思路不复杂：让验证动作自动化，把人的注意力留给判断。
有开发者回复说，五条里最值钱的就是自验证脚本：派任务不附测试用例和验收标准，Agent 交上来的东西还得自己重验一遍，等于白派活。
两次纠偏失败，按 Esc 重置
看到模型走偏，立刻按 Esc 叫停。如果连续纠偏两次，模型还是理解不了，不要开第三次辩论。清空会话，重写更清晰的提示词。第三次纠错往往只是在给充满噪音的历史上下文添乱。
这条对普通用户也成立。跟 AI 绕了三轮还在原地，通常不是它突然变笨，是前面的上下文已经脏了。重新开一局，把目标、约束、验收标准写清楚，比继续争论便宜。
调度税：同时跑五个 Agent 不是五倍产出
同时跑的 Agent 不是越多越好。超过三五个之后，每一个新增的智能体都在指数级掠夺你的审查注意力。Addy 把这叫 orchestration tax，调度税。多数日子他跑四五个后台 agent 和几个本地会话，有些天已经太多。
解法不是盯得更紧，而是把监控交给自评估、目标检查和带新上下文的审查者，把人的注意力留给架构决策。没有集中视图和通知，只靠轮询，很快会被会话淹没。
审查代码也不能变成盖章。测试全绿、命名合理、文件看起来正常，不代表你理解了逻辑。不理解逻辑就批准，审查动作还在，认知已经投降。Addy 举了个自己的例子：让 Agent 研究竞品缺口并写本地 PR，他读了研究、扫了代码，差点推送一堆增加复杂度却收益很小的变更。工作派出去了，判断也差点一起派出去。
把纠错变成制度记忆
同一个错误在不同任务里出现两次以上，就该写进 CLAUDE.md，或者封装成专属 Skill。把个人脑子里的纠偏，变成所有智能体都能继承的系统规范。CLAUDE.md 要保持简短，适合放这些内容：怎么验证、代码里哪些区域容易误导、仓库里不存在的决策、已经纠正过两次的事情。
有网友说，管 Agent 和管人一样，缺的常常是验收标准，指令反而没那么稀缺。给子 Agent 固定角色，先对着 spec 辩论，人只看争论有没有打到真风险。把判断力写进流程，比再加一条提示词有用。
软建议和硬约束要分开
提示词、CLAUDE.md、Skill 是请求，模型可以考虑后决定怎么做。Hook、Deny Rules 才是要求，必须执行。多数情况下，让 Agent 看真实代码后自己判断。只有“永远不要改生成的客户端”“必须跑 license-header 脚本”这类不能弯的事，才上硬约束。
Addy 还提醒，旧习惯该退休了。全大写指令、think harder、don't be lazy，在当前模型上容易导致过度执行和过度加班。过度流程是新的微观管理。
先计划，再让 Agent 动手
先进入计划模式，把计划迭代对，再委派编码。计划对了，模型常常能一次做完。大任务可以开第二个会话，像资深工程师那样做设计评审，重点看底层假设。
拆任务也要避免重叠。Claude Code 的 /batch 可以把大机械改动拆成 5 到 30 个任务，在独立 worktree 执行，每个任务开一个 PR。人只需要检查切片有没有重叠，共享接口有没有先落地。五个 Agent 接重叠任务，不会带来五倍产出，只会带来一个五作者合并冲突。
长任务要设计成不需要你守着
部署自主任务前，先定义完成标准、自验证机制、边界、护栏和人工审批点。别在睡前启动一个没有停止条件的长任务，第二天醒来发现模型整夜在错误前提上工作。
要回答的问题很管理：它知道什么叫完成吗？它有验证机制吗？边界在哪？回合数或花费上限是多少？输出落在哪，谁批准不可逆操作？先拿三个文件试点，看前几次运行，再放手。
规模上去的应该是验证，不是注意力
Agent 数量要跟检查能力一起扩。PR 周期时间、返工频率、回滚次数，这些比“AI 写了多少代码”更有用。衡量合并 PR 数量，就要同时看 revert 和 rework。
Addy 也承认管理类比有边界。管人更难，技能不会反向迁移。Agent 返工几乎免费，可以同时做两三个技术方案对比。Agent 没有经验，只有笔记本，记忆不自动传给同事。Agent 更愿意听话，人也更容易过度信任它。人类团队仍然重要，别花一天管 Agent，把建设团队的时间挤没了。
程序员不必想当经理。但用好 Coding Agent 的工程师，大概率会在日常开发里学会管理：给上下文，定完成标准，做检查点，审关键变更，决定不做什么。头衔可能没有，管理动作已经全套。
Addy Osmani 原文：https://x.com/i/article/2118901185377964033
发布时间: 2026-11-09 01:27