工程管理

原文：Your coding agents made you a manager 作者：Addy Osmani（@addyosmani） 原文配图是 Pangram 对这段文字的检测结果截图：人类写作 90%，AI 10%，AI 辅助 0%。跟正文关系不大，附在此处存档。 编程 Agent 用久了，你已经在做管理 管理 agent 的本事，和管理团队的本事基本是一套。你不需要先有个管理者的头衔才能学。 整天和编程 agent 待在一起，你就在管理。选任务、写指令、派活、追问、评估结果、决定什么上线，一天里反复做这些。把 agent 用得最好的工程师，不一定是 prompt engineering 最强的那批，而是学会了管理的那批，有意识或者无意识地。 这话可能不中听。我欣赏的很多工程师选 IC 路线，就是想贴着活干，他们见过朋友当了管理者之后消失在日历里。我不是劝你变成那种管理者。这里的"管理"有具体所指：通过让别人做成事，来产出好结果。我也没说 agent 能替代管理者或同事。 你对烂管理者的每一条抱怨，都是一份和 agent 打交道的 bug 报告。想想任务交接。要是你经历过一次烂交接，大概收到过含糊的需求、缺失的背景，或者中途被反复改预期。好消息是，正因为你被交接了这么多年，你知道一次好的交接长什么样。 下面这些小节大致按杠杆大小排序，最有效的习惯放前面。 先给它一个能自检的办法 做法： 给 agent 一个验证自己工作的机制，测试套件、构建或者截图都行，让它把结果拿给你看，作为证据。 反例： 把"看起来做完了"当作确认。这样验证全落到你身上，你成了 agent 的测试套件。 问一个有经验的管理者，他怎么在不读所有产出物的情况下确信团队在做好活，他会讲护栏：CI、代码评审、看板、on-call。没建护栏的管理者，最后自己验所有东西，一个季度内就成了瓶颈。agent 一样。Claude Code 的最佳实践文档写得很清楚：agent 在工作看起来做完的时候停下。没有验证机制，“看起来做完"就是它唯一的验证。有了验证机制，agent 就能干活、跑验证、看到失败、自己改。UI 改动可以真的在浏览器里打开页面，迭代到能用也好看。 验证机制是什么都行，只要能给出明确的通过或失败。测试、构建退出码、linter、diff 脚本、截图都算。跑验证的那条命令，是 CLAUDE.md 里最值钱的一行——CLAUDE.md 是 agent 每个 session 开头都要读的指令文件。有了机制，往工作流里接的方式有几种： 要求。 让它做完跑 auth 测试，跑到过为止。 目标。 /goal 会让另一个模型在每一轮之后检查条件，长时间后台任务最用得上。 强制。 Stop hook 可以拦住这一轮的结束，直到 typecheck 通过。 送审。 /code-review 把 diff 交给一个没看过你这段对话的新 subagent 评审，就像作者不批自己的 PR。 评审范围可以控制。让它找问题，它总能找到点东西；让它只找正确性问题、忽略风格，它就照做。好管理者也是这样学会提反馈需求的。Claude Code 工具箱里大部分功能都在收紧这个循环。skills、hooks、subagents、MCP 存在的意义，是补上"做事"和"验证做事"之间的缝，让你的注意力只花在 agent 验证不了的地方。有经验的工程管理者做的就是这件事。 ...