工程师躲过管人，没躲过管 Agent

Addy Osmani 写了篇《Your Coding agents made you a manager》。Viking 读完后的判断很直接：工程师的日常正在向管理靠。有人原本选 IC 路线，就是为了离代码近一点，少开会，少被日历切碎。现在日历没满，任务队列先满了。

有网友在评论区总结得更损：质疑经理，理解经理，成为经理。

每天和 Agent 待在一起，你就在管理

Addy 的核心判断是，如果一个人整天和 coding agent 一起工作，他已经在做管理了：选任务、写指令、委派、跟进、评估结果、决定什么能上线。把 Agent 用出差距的人，未必是 prompt 写得最花的人，往往是更早学会管理的人。

这里说的管理，指通过让其他人的工作顺利来产出好结果。它不要求你变成日历塞满会议的那种经理。Addy 也没有说 Agent 能替代经理或同事。

他有一句话很扎心：你对坏经理的每一条抱怨，都是和 Agent 协作时的 bug report。交接含糊、上下文缺失、预期变来变去，这些老问题在 Agent 这里一个不少。区别在于，过去你是接活的人，现在你成了派活的人。

先给 Agent 一个能检查自己的办法

Addy 把这条放在最前面。最好的实践，是给 Agent 一个验证工作的机制，比如测试套件、构建、linter、截图，并且让它把结果当证据拿出来。反模式是看到“看起来完成了”就点头。这样你会变成 Agent 的测试套件，所有错误都堆在那里，等你有空才发现。

有经验的经理不靠读完全部代码来确认团队干得好，他们靠护栏：CI、代码审查、仪表盘、值班。没有护栏的经理，一个季度内就会变成瓶颈。Agent 也一样。它会在工作看起来完成时停下。没有验证，“看起来完成”就是它唯一的验收标准。

Claude Code 的文档写得更直白：给 Claude 一个能跑出 pass 或 fail 的检查。测试、构建退出码、linter、对比 fixture 的脚本、浏览器截图都行。仓库里已经有这类检查时，CLAUDE.md 里最有用的那一行就是运行它的命令。

可以放进工作流的方式有几种：在 prompt 里要求跑完认证测试再继续；用 /goal 设一个条件，让独立模型每轮检查；用 Stop hook 卡住回合，typecheck 不过就不让结束；或者用 /code-review 把 diff 交给一个没看过对话的新 subagent 审。作者不批自己的 PR，Agent 写的代码也一样。

这里有个细节值得记住：让审查者“找问题”，它总能找到。让它“找影响正确性的问题，跳过风格”，它才会收敛。好经理要反馈时也这样，范围越清楚，返工越少。

AGTP 的推文把这类做法叫 harness engineering：与其只改 prompt，不如在 Agent 周围搭一整套系统。这个说法和 Addy 的文章能对上。重点从“选哪个模型”转向“怎么让 Agent 可靠”。

讲清楚 Agent 看不到的东西

Addy 建议，给 Agent 一份它自己看仓库看不出来的摘要：任务目标、为什么重要、约束、范围外的事情、成功标准。反模式是丢一句任务，真实预期留在自己脑子里；或者把 Agent 读代码就能发现的东西写一大堆。

他举了个例子。把“让 dashboard 更快”改写成：让 10k+ 成员组织的 /team dashboard p95 加载时间低于 2 秒。为什么：企业管理员每天打开，慢加载是最大的支持工单来源。约束：不改 schema，保持 API 响应结构。范围外：UI 改动，整页缓存。检查：运行 scripts/perf/team.sh，给出前后数字。

这背后的管理概念，军队叫 commander's intent，Netflix 叫 context, not control。用普通用户能理解的话说，你告诉对方要打成什么结果，边界在哪，别把每一步都攥在手里。

如果还没想清楚任务，Addy 给了一个很实用的办法：让 Agent 反过来 interview 你，直到它能写出 spec，把 spec 存成文件，再开一个新会话照着做。这个 spec 后面还能拿来审查。

同一个修正出现两次，就该沉淀

Addy 的建议是，同一个东西纠正超过一次，就写进团队的 CLAUDE.md，或者做成共享 skill。过一段时间再检查，新模型是否已经不需要这些纠正。反模式是每个会话都手动改一遍，或者依赖只存在于自己机器上的隐知识。

CLAUDE.md 要保持短。适合放进去的内容包括：怎么验证，精确命令；代码里容易误导的地方；仓库里没有的决策；已经纠正过两次的事情。

这条对普通读者也好理解。Agent 没有在团队里待过，它不知道上次会议为什么否掉一个方案，也不知道部署流程藏在谁脑子里。把这些写下来，等于给下一次会话省掉重新摸索。

默认让它决定，只硬性约束不能弯的

Addy 引了 Andy Grove 的 task-relevant maturity：监督程度应该看这个人在具体任务上的历史表现，不看他整体能力强不强。放到 Agent 上，大部分时候应该让它自己判断，只有少数必须永远发生或永远不能发生的事，才用 hook、deny rule、managed settings 硬性执行。

Claude Code 文档把这件事拆得很清楚。prompt、CLAUDE.md、skills 属于非确定性指令，模型会读，会考虑，通常照做，但没有保证。hook、deny rule、managed settings 属于确定性规则，由 harness 每次执行，不管模型怎么想。

反模式是满屏大写规则、给偏好加 hook、新模型早就学会的东西还留着老习惯。Addy 写了一句很准：对 Agent 来说，过度流程就是新的微观管理。

先计划，再让它写

Addy 建议在 Agent 开始编码前先定好计划，读计划时看底层假设，把任务切成不重叠的并行工作。反模式是多个 Agent 同时做重叠任务，下午花时间解决合并冲突和重复决策。

好流程是先进入 plan mode，把计划迭代到合适，再委派编码。计划足够好时，模型经常能一次建完。大任务可以开第二个会话，让另一个会话像 staff engineer 那样看计划，做设计审查。设计审查是发现走错方向最便宜的地方。

早点纠偏，快速重开

Addy 的建议是看第一分钟，发现 Agent 跑偏就纠正。如果已经纠正失败两次，开新会话，写更好的 prompt。反模式是第三次、第四次接着补，补的是请求本身。

这个类比很 manager。一个有能力的人连续做错同一件事，问题可能在上游：指令、上下文、范围。Agent 版本更直接。偏了就按 Esc。两次没纠正过来，清会话，把学到的教训写进新 prompt。第三次纠正大多只是让模型反复读更多失败记录。

/rewind 这类能力还在改变试错成本。回滚便宜，就可以先试更大胆的方案，不行再退回来。好经理对员工也这样，错误可逆时，给人一点空间。

任务可以委派，判断不行

Addy 把边界划得很清楚：Agent 做工作，人决定重要的事，产品判断、安全边界、什么上线。每一个 diff 都当成自己会被 paged 的改动来看。反模式是测试绿了、命名看着合理，就批准一个很大的 diff。那不叫代码审查，叫代码追认。

他在文中承认自己差点掉进去。让 Agent 研究竞品缺口，写本地 PR 补缺口。他读了研究，扫了代码，差点推出去一批给用户增加复杂度、收益很小的改动。工作委派出去了，决策也差点一起委派出去。600 行 diff，命名合理，测试绿，点通过太容易。

更合理的分工是：Agent 做样式、lint、评审后的跟进、常见 bug、单元测试；人负责安全边界、合规、产品决策。协调也一样。Agent 可以跟踪交接，竞争性需求之间怎么选，还是要人来定。

人不必待在每个改动的内循环里。要守住的是外循环：约束是什么，输出到底读多少，保留什么证据，什么必须人工签字。改动尽量小，审查的单位就是理解的单位。

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

Addy 给无人值守任务列了五个问题：它知道完成是什么样吗？它有自检机制吗？边界是什么？什么能让它停？输出到哪里，谁批准？

这五个问题，和好经理给资深工程师一个项目然后去度假前会问的，几乎一样。目标条件、spec 文件、一个必须变绿的失败测试；测试套件、Stop hook、审查步骤；权限控制、sandbox、worktree、只允许推的分支；回合上限或花费上限；PR 或总结，以及不可逆操作的人工批准。

扩展 Agent 数量时，验证能力要跟着扩，注意力不要跟着扩。Addy 提到一个 orchestration tax：过了最初几个 Agent，每多一个都要更多注意力。多数日子他跑四五个后台 Agent 和几个本地会话，有些天已经太多。监控更多救不了扩展，只有让系统自己监控自己，人才有空做决定。

衡量系统，别只衡量活动。PR 周期时间、新人 ramp up 时间、revert 和返工频率，比“AI 写了多少比例代码”更有意义。Grove 的 countermeasure 规则也适用：你量合并 PR 数，就同时量回滚和返工。

AGTP 还提到一个双退款案例：Agent A 把退款交给 Agent B，B 的 API 调用成功，但在回报前超时，A 重试。没有幂等键，客户收到两次退款。两个 Agent 各自的评估都通过，bug 只存在于交互里。这类问题说明验证不能只看单个 Agent 是否“跑完”，还要看系统边界和重试语义。

决定不做什么

Addy 说，经理最重要的词常常是 no。到了 Agent 这里，说 no 更难。开工几乎免费，午饭前就能把每个看起来可行的想法扔进 PR。然后团队得到一堆需要 review、安全审查、支持和维护的 PR。审查和验证成了稀缺资源。

老问题现在更重要：谁要这个？怎么衡量成功？什么时候停？如果构建便宜，难的问题从“能不能做”变成“该不该做”。

这个类比在哪里断掉

Addy 没有把 Agent 说成初级开发者的平替。他列了边界：管人更难，技能不会反向迁移；返工几乎免费，可以让人和 Agent 同时做两三个方案比较；Agent 没有经验，只有笔记本，自动记忆只记在一台机器上；Agent 更急于同意，人容易过度信任，可以要求它反驳自己的答案；你只有一种 Agent 原型，而且每隔几个月就随模型更新变化；初级开发者的基本功训练还得人来做；人类团队仍然重要，别管 Agent 管到把建设团队的时间挤没。

不需要头衔

Addy 的结尾很平静。好 staff engineer 一直做这些事：写设计文档，设上下文，认真 review，让周围的人更好。Agent 让所有工程师第一天就能练这些，反馈以分钟计，错误可撤销。工作正在从写代码，变成让好代码有理由被写出来。

不想当经理没问题。用好 Agent 的工程师，路上都得学会管理。

可以先试几个动作：每个任务都配一个能跑的检查；告诉 Agent 它看不到的东西；写代码前先聊计划；同一个修正出现两次就记进 CLAUDE.md；两次纠正失败就重开会话；审 diff 时假设自己会为它被叫起来。