从工程师到工程经理，再到编码 Agent 的经理

你刚让终端里的编码 agent 改完一个 handler，测试全绿，diff 看着也对。可你说不清这次改动里哪一部分是你的判断，哪一部分是它的猜测——因为你只写了两句话，它写了六十行。

Nick Cosentino 在 2026 年 10 月写的 From Software Engineer to Engineering Manager: Starting Well 讲的是一次人际角色转换：从写代码的人变成让别人写出代码的人。他给了九条上任原则，最后落在一句话上——不要表演「经理人格」，要理解职责、建立工作关系、让团队把活干成。

把这九条拿到编码 agent 上，会发现它们不是同一类东西。其中五条的底层动作是「把隐性知识写成显式约束」，所以对人还是对 agent 都成立；三条的底层动作是「建立关系」，而 agent 没有可以被建立关系的对象，只能换机制；还有一条在 agent 场景里风险正好反过来。

下面逐条对照。原文的经验归属 Nick Cosentino，映射和判断属于本文。

核心结论

管理人的时候，你的产出是让别人做出决定；管理 agent 的时候，你的产出是让「对不对」这件事可以被检查。

前者靠关系，后者靠机制。混用会出两种典型故障：把 agent 当同事，于是省略验收标准，得到一堆「almost right」的代码；或者把 agent 当工具，于是省略取舍，得到一堆没人能维护的 diff。

一、被反转的那一条：你和产出的关系

Nick 说工程经理上任后最难的部分是：你花一天帮人推进、梳理依赖、做一个优先级决定，然后看着空空的 commit 历史，怀疑自己到底做了什么。他的判断是影响转移到了团队的成功上，而且不能把工程师的成果据为己有。

用上编码 agent 之后，这件事的形态变了，但困惑没消失：

管理人的版本：commit 历史空了，你不知道自己做了什么。
管理 agent 的版本：commit 历史每天都是满的，你还是不知道自己做了什么。

第一个问题的原因是贡献和结果之间的连接变远了。第二个问题的原因是连接很近，但你无法确认结果是否正确。Stack Overflow 2025 年对 49,000 多名开发者的调查把一个数字放在这里：信任 AI 输出准确性的比例从上年的 40% 掉到 29%，66% 的人说自己在花更多时间修「看着差不多对」的 AI 代码。

原文里有一句限制条件值得单独拿出来：不要把职责（accountability）和无限的权力（authority）混为一谈。 这句话在 agent 场景里不是打折扣，而是被放大了——因为 agent 不能被问责。

Claude Code 的子 agent 文档把这件事写成了产品行为：任何 agent 发来的消息都不构成你对一个待批权限提示的批准，任何 agent 消息也无法修改子 agent 的权限设置、CLAUDE.md 或配置，只有权限系统或你自己的消息能授予批准。换句话说，责任链在运行时是断开的，终止点只有你。

这就是「工程师的经理」和「agent 的经理」最硬的区别：前者能把功劳分给团队；后者的决定无处可转。

二、能直接搬过来的五条

这五条的底层动作都是把隐性知识变成显式约束，所以对象是人还是 agent 不影响它的有效性。

先搞清楚岗位，别抄别人的日程

Nick 说工程管理在不同组织里不是一回事，小型创业公司可能期望一个动手的技术经理，另一个组织可能要求这个人把大部分时间用在支持人和跨团队协调上。别人的日历不能当你的岗位说明书。

换成 agent，对应的动作是：别抄别人的 prompt 和规则文件。 别人分享的 AGENTS.md 是他们对自己仓库验收标准的压缩，里面隐含了他们能接受什么、不接受什么。你复制过来，得到的是一份你不知道边界在哪的契约。

模仿只会放大「almost right」这个问题。Stack Overflow 的调查里排在第一位的挫败——45% 的人选它——就是「AI 给的方案差不多对，但就是不对」，而且这种错误往往比完全错误更难查。

所以先写清这份岗位说明的四个字段，再谈规则文件怎么组织：

你负责的结果是什么（可观察的行为，不是文件列表）
必须遵守的既有约定（构建、测试、命名、错误格式）
哪些决定需要停下来升级（改 schema、加依赖、动认证）
明确不做的事

先了解团队，再想着展示领导力

Nick 提醒新经理不要急着做一个显眼的改动来证明自己属于这里。他的理由是操作性的：一次改很多东西，你就没法知道哪一项起了作用。

这条几乎可以逐字搬到 agent 上，而且理由更硬。规则文件、hook、prompt 模板都是混淆变量：你一次往 CLAUDE.md 里加五条规则，然后就无法判断到底是哪条让结果变好了。

原文建议的起手式在 agent 场景里同样适用：哪些反复出现的问题在拖慢工作、哪些东西是有效的应该保留、一个「有意义的改进」长什么样。改完只留一个变量，你才拿得到反馈。

保留技术判断，但别让自己成为默认实现者

Nick 区分了三种「跳进去写代码」的情况：你的贡献确实有用、你因为写代码比处理管理问题舒服而接管、以及团队存在反复出现的知识或所有权缺口。他说这三种当下看起来很像，长期后果完全不同。

用上 agent 之后，这个陷阱换了一件衣服。默认实现者变成了默认审查者。

Simon Willison 在并行编码 agent 里给过一个判断：真正的瓶颈不是生成代码，而是审查代码。Addy Osmani 在 Your AI coding agents need a manager 里把同一件事讲成管理问题——你不再是在和单个 agent 结对，你在跑一个小团队。

于是那三种情况也换了说法：

你在验证一条真实风险（有用）
你在用审查逃避写验收标准（舒服但错位）
因为没人写得清验收标准，所以只能你自己看 diff（真正的信号）

第三种是唯一需要你停下来处理的。它说明缺的不是你的注意力，是这个仓库缺一份能被检查的契约。

协调优先级，而不是把每个请求都转发

Nick 说经理经常从多个方向收到请求，每个相关方都有理由说明自己的事重要，但容量不会因此变多。你的贡献不是把某个人的名字排到下一个请求旁边，而是让取舍显式：哪件事要变、谁需要同意、什么后果需要被理解。

Agent 让「可以做」变得便宜，所以请求只会变多。Addy Osmani 从管理学借了两个动作放在这里，原文里也有对应物：

WIP 限制：写下同一时刻允许的并行 agent 数量上限。审查带宽是固定的，超过它的并行度只会把队列变成堆积。
停止条件：任务开始前先写下什么情况下停。这对应 Nick 说的「把请求的重要性、它相对于其他工作的时机、以及改变当前计划的代价分开看」。

这两件事都不需要新工具，只需要在开工前写一行字。

别成为团队的永久减震器

Nick 说替团队挡掉不必要的打扰是有用的，但成为唯一一个知道如何吸收所有打扰的人，是另一回事。他给了三个值得追查的信号：只有你掌握上下文所以决定要等你、你反复解决同一个问题但没人学到、因为优先级不清所以请求会打断团队。

这一条在 agent 上成立，但意图要修正一半。Nick 的目标是减少不必要的依赖，方法是让团队自己长出判断力。用 agent 的时候，有一类依赖是你故意要保留的：架构边界、安全与隐私相关的决定、产品意图。这些不是你该交出去的上下文，而是你必须继续持有的判断。

所以正确的动作是分开两类：

该消除的依赖：能写进规则文件或验收标准的重复动作
该保留的依赖：写不进去、只能由人负责的决定

混在一起看，就会出现「什么都让 agent 做」和「什么都不敢让 agent 做」这两种极端。

三、必须换掉机制的三条

这三条的底层动作是建立关系——信任、个体关注、对话。Agent 没有可以被建立关系的对象，所以照搬会得到一堆没有执行力的仪式。

赢得信任 → 设计验证

Nick 说头衔不会自动产生信任。人需要搞清楚你会怎么和他们共事：事情不顺时你会不会听、他们能不能反对你、你会不会先理解再决定。他还区分了「征求意见」和「意见已经被关上门之后征求意见」。

Agent 没有「信不信任你」这个状态。你要决定的不是信不信它，而是你愿意在哪一层验证。 这不是修辞上的替换，它改变了工作内容：原来的动作是花时间建立关系，现在的动作是提前规定证据形态。

有意思的是，信任被换掉之后，接替它的东西是运行时的。前面引过的那句文档原话——只有权限系统或你自己的消息能授予批准——就是这种替换的具体形态：不靠关系，靠机制。

原文里还有一个可以直接迁移的信号。「他们能不能反对你」在 agent 上变成了：它有没有一条路可以拒绝或停下来。 在验收标准里写「如果需要改 schema、加依赖或改认证，停下来报告」，就是在给它这条路径。一个从不提出疑问、每次都回「已完成」的 agent，和一个从不说「我做不到」的下属一样，让你失去了最重要的早期信号。

支持每个人，而不是一个想象中的平均员工 → 按任务形状分配能力

Nick 说他早期犯过一个错：给已经做得很好的人更少的刻意关注，因为他默认「他们表现好，我加不了什么价值」。他提醒独立完成任务和有支持可用是两件不同的事。

Agent 没有职业目标，所以「支持个人」不能映射成「关心它的成长」。能映射的是：不同形状的任务适合不同的模型、工具和上下文配置。

这里的「想象中的平均员工」表现为一种具体习惯：用同一套 prompt 模式对待所有模型，然后把差异归因于「模型不行」。

而 Nick 那个「表现好就不用管」的错误，在 agent 上的镜像版本是：把重要任务一直交给最顺手的那一个配置，因为别的你还不熟。结果和管人时一样——你失去了对边界的了解。

唯一和「成长」沾边的东西是跨会话记忆。Claude Code 的上下文窗口文档写明，自动记忆加载的是「它从上一次会话里学到的东西」：构建命令、它注意到的模式、要避免的错误，并且只加载前 200 行或 25KB，以先到者为准。这是有配额的成长。知道配额在哪里，比相信它会自己变聪明更有用——超出配额的部分不会进入下一次会话，除非你把它写进项目规则文件。

让对话有用，但不侵入 → 定下交接报告的格式

Nick 说把一对一放进日历是不够的，对话要能容纳「此刻有用的东西」：有时是反馈，有时是一个难缠的依赖、一个对优先级的担心，或者一个不适合放进团队日常讨论的问题。他也提醒不要索取对方不想分享的信息——两条责任分别是让提出顾虑成为可能，以及响应时不要求不必要的信息。

Agent 没有一对一。这条要换掉的是资源的定义：你的注意力是配额，agent 的上下文也是配额。前面那两条责任的对偶版本是：

让 agent 敢报「我不确定」——这靠提示词里给它留位置，而不是靠语气
你要的交接报告里不要包含你不需要的东西——因为多出来的内容会挤掉真正有用的部分

第三层是上下文配额本身。长会话压缩时，Claude Code 会重新读取最多五个最近修改过的文件，CLAUDE.md 和自动记忆从磁盘重新注入，而按路径生效的规则和子目录里的规则文件会被摘要掉。这意味着「我们讨论过这个约束」不是一句可以依赖的话——约束要么写进项目根目录的规则文件，要么会在压缩后消失。

一个够用的交接报告格式，四行就够：

改了什么：<受影响的行为，不是文件清单>
对应证据：<每条验收标准 -> 哪条测试/命令证明了它>
没覆盖的：<已知的缺口和不确定项>
停止项：<是否触碰了 schema、依赖或认证>

这四行不是为了礼貌。是因为你的审查带宽是瓶颈，而瓶颈的输入质量决定整条链的吞吐。

四、九条原则的对照表

原文原则	管人的动作	管 agent 的动作	类比在哪里断掉
这是一个不同的岗位	接受 commit 历史变空	接受 commit 历史变满但没有验证	责任无处转授，agent 不能被问责
先搞清楚岗位	和上级确认职责与权限边界	写清结果、约定、升级项、不做的事	没有上级可以确认，只能自己定义
先了解团队	问什么有效、什么反复造成摩擦	先读现有规则和构建测试约定，再改	无差别；一次只改一个变量
保留技术判断	别成为默认实现者	别成为默认审查者	陷阱换了衣服，信号换成了「缺契约」
协调优先级	让取舍显式，不转发请求	WIP 上限加停止条件	可以做变得便宜，请求只会更多
别当减震器	减少不必要的依赖	减少重复动作的依赖，保留架构与安全判断	有一类依赖是你故意要留的
赢得信任	让人知道你会听、能被反对	规定证据形态，给 agent 一条停下来的路	没有关系可建立，只能靠机制
支持每个人	按个体需要调整支持方式	按任务形状分配模型与配置	没有成长目标，只有 200 行的记忆配额
让对话有用	一对一，但不索取隐私	固定交接报告格式，管好上下文配额	注意力与上下文都是硬配额

五、常见问题

开始用 agent 之后，我还算工程师吗？ 这个问题和原文里「不写代码怎么知道自己在贡献」是同一个。Nick 的答法是去看你的工作和你团队推进能力之间的连接。放到 agent 上：你今天澄清了哪条验收标准、消除了哪个反复出现的歧义、拒绝了哪条不该做的改动。这些都不是 commit，但它们决定了下一次 commit 是否正确。

Agent 说完成了，但我没时间逐条验证怎么办？ 这正是 WIP 上限存在的理由。并行度超过审查带宽，剩下的部分不是「以后再看」，而是没有人看。把并行数降到你能真正读完 diff 的水平，比任何提示词优化都有效。

我该不该自己写代码？ 原文的回答是「先把角色期望搞清楚」。agent 场景下多一个判据：这件事是不是只有你能写清楚验收标准？如果是，那就别写代码，去写标准；如果不是，动手也没问题。

能不能让一个 agent 管另一个 agent？ 可以，但要知道层级是有上限的。Claude Code 的子 agent 默认最多嵌套三层，同一会话内并发子 agent 默认 20 个，达到上限后新增会被拒绝。这是产品层的边界，不是设计建议——真正的设计问题仍然是每一层的验收标准写在哪。

收尾

Nick 在原文结尾说，你不需要表演一个可辨认的工程经理人格，你需要理解职责、建立工作关系、帮团队把活干成——有些日子会比写代码难以衡量。

用上编码 agent 之后，这句话要加一个补丁。你和「团队」之间的那部分工作，现在只有一半能靠关系完成。关系的部分（信任、个体关注、对话）要换成机制；约束的部分（写清岗位、先读现状、协调优先级、别当瓶颈）可以原样搬过来。 而责任的部分不但搬不过来，还变重了，因为链条的终点只有你一个人。

三个今天就能做完的动作：

写一份仓库岗位说明：负责的结果、必须遵守的约定、需要升级的决定、明确不做的事。控制在两百行以内——这不是风格建议，CLAUDE.md 类文件本身就是有上下文预算的。
确认默认边界：沙箱开着没有、网络通着没有、哪些命令永久拒绝。这些决定了 agent 在你机器上第一次执行命令时实际拥有的权力。
定下交接报告格式和并行上限：四行格式，一个你能真正读完的数字。

做到这三件，你就从「会用 agent 的工程师」变成了「能让 agent 的产出被检查的人」。原文里的那个身份转换，也是从「我做出来的」变成「我让它变得可判断的」。

如果你也在用编码 agent 做日常开发，欢迎关注 Aide Hub。我们会继续分享 AI 助手、开发工具和软件工程实践的一手内容。