AI 不是员工，但要像员工一样管理

发表于 | 分类于

AI 不是员工，但要像员工一样管理

最近我越来越觉得，关于 AI 编程，很多人问错了问题。

大家总在问：“AI 写的代码，人到底要不要看？”

这听起来很合理。Agent 写代码越来越快，diff 越来越长，人类跟不上了。于是我们很自然地陷入一个两难：看得太深，成本太高，AI 的速度被人拖住；看得太浅，人类后面又给不出有用意见，只能沦为一个点确认按钮的人。

但这个问题的陷阱在于，它把人类的位置放错了。

人类不是 AI 的逐行审稿员。人类更像一个负责人。

如果你手下有一个能力很强的人，动作快，执行力强，能独立搞定很多事，你当然不需要知道他每一分钟在干什么。你不应该站在他身后，看他每一封邮件怎么写、每一个表格怎么填、每一行代码怎么敲。那不是管理，那是把下属当成一副更慢的手套来用。

但你也不能完全不理解他在推进什么。

不能他一休假，整个小组就停摆；不能他一离职，没人知道关键系统为什么这么设计；不能他为了完成眼前任务，悄悄把团队带到一个以后谁都指挥不了的方向。

这就是 AI 编程真正的问题。

不是“人要不要读每一行代码”。

而是：当一个非人类执行者开始高速改变系统，人类如何继续保有对系统的指挥权？

一、AI 带来的不是代码风险，而是管理风险

我们太容易把 AI 当工具看。

工具的逻辑很简单：它能不能帮我更快完成任务？能，那就用；不能，那就不用。锤子、搜索引擎、IDE、脚本，都是这个逻辑。

但 Agent 不太一样。它不只是帮你敲几行代码，它会读文件、做判断、拆任务、改方案、修测试、解释原因，有时候还会在你没明说的地方主动补洞。

它还不是员工，因为它没有责任感、组织语境、长期记忆和道德承诺。出了事，不能找它谈绩效；系统烂了，它也不会真的焦虑。

可它已经会制造员工式的管理风险。

它能形成事实上的单点依赖。

它能把关键上下文留在“脑子里”，只不过这个脑子叫临时对话窗口。

它能写出当下正确、长期难以接手的实现。

它能为了完成目标，悄悄改变边界。

它能让负责人产生一种错觉：我还在 loop 里，因为每一步都是我批准的。但实际上，我批准的只是一个我已经无法真正判断的结果。

这就是 Geoffrey Litt 说“理解是新的瓶颈”真正刺中的地方。表层看，是人类吸收代码的速度跟不上 Agent 生成代码的速度。深一层看，是系统变化速度超过了人的 mental model 更新速度。

更深一层看，这是一个管理问题：执行能力被放大以后，组织的理解能力、交接能力、复盘能力、授权能力没有同步放大。

写代码只是表象。

真正被拉开的差距，是“产出速度”和“组织吸收速度”之间的差距。

这句话值得停一下。

组织吸收速度不是一个常见指标，但它可能会变成 AI 时代最关键的工程指标之一。它指的是：一项产出从“某个执行者做完了”，到“团队真的能理解、维护、复用、继续演化它”，中间要花多久。

AI 提高的是前半段速度。

管理要保护的是后半段速度。

如果前半段快了十倍，后半段没有变化，系统里就会堆积大量“已经完成但尚未被组织吸收”的东西。它们看起来像进度，实际上是未来的理解库存。库存越多，后面盘点越痛。

很多团队不是被 AI 写坏的代码拖垮，而是被这些没有被吸收的“半成品理解”慢慢拖慢。

因此，AI 管理的目标不是多交付一点，而是让交付不会变成未来的失忆。

这比任何一次局部提速都更重要，也更难被仪表盘看见。

也更长久。

二、为什么“代码能跑”反而最危险

AI 写错代码并不是最可怕的。

错误代码通常会暴露。测试失败，构建报错，线上行为不对，用户投诉，日志异常。这些都麻烦，但至少它们会把问题推到你面前。

更危险的是另一种东西：AI 写出了正确但不可继承的代码。

它能跑。

测试也过。

解释听起来也顺。

但它引入了一套你没有吸收的抽象，藏了一些你没有意识到的假设，改变了一些你没来得及命名的边界。今天你觉得“挺好，省了我一天”，三个月后你要继续改这块，突然发现自己不知道从哪里下手。

这和管理里最怕的情况很像。

一个明星员工把所有复杂事情都扛了下来，效率很高，大家都舒服。直到有一天他不在，团队才发现：流程不在文档里，判断不在制度里，客户关系不在 CRM 里，关键知识只在那个人的脑子里。

他不是没贡献。

恰恰是因为他太能干，组织反而变弱了。

AI 也会造成这种反常现象。它每次都帮你把事情做掉，但如果它没有把理解留下，团队积累的不是能力，而是依赖。

这就是认知负债最隐蔽的形态。

技术债通常还看得见：重复、混乱、难改、慢。认知债更阴险。它的外观常常是“事情都做完了”。只有当你下一次需要判断、修改、排障、扩展时，你才发现自己已经跟丢了剧情。

所以问题不是“AI 写的东西有没有用”。

问题是：AI 写完以后，我们有没有变得更能继续做下一步？

三、理解不是记住细节，而是保留干预能力

如果把“理解代码”定义成逐行读懂，那 AI 时代的人类一定会输。

因为人脑不适合追踪无限局部。AI 能在很短时间里生成一堆文件、测试、配置、脚本，人类不可能靠逐行阅读维持控制。

但管理者也不是靠记住所有细节来维持控制。

一个好的负责人真正掌握的是这几件事：

目标是什么？

边界在哪里？

哪些事情不能牺牲？

关键判断为什么这么做？

如果出问题，谁能接手？

如果环境变化，系统能不能继续演化？

搬到 AI 编程里，理解也应该重新定义。

理解不是“我知道每个函数怎么写”。

理解是“我知道这个系统为什么变成现在这样，以及下一次要怎么安全地改变它”。

这两者差别很大。

逐行理解面向过去：发生了什么。
系统理解面向未来：我还能怎么干预。

所以人类的理解预算，不应该平均分配给所有代码。一个两千行的机械迁移，可能只要看迁移规则和验证证据。一个二十行的状态模型修改，可能必须深究，因为它会决定未来所有功能怎么生长。

这就是我后来想明白的关键：参与深度应该按未来干预价值分配，而不是按当前代码量分配。

凡是只是在既有轨道上跑的事，可以浅。

凡是改变轨道的事，必须深。

四、给 AI 的不是任务，而是授权半径

管理下属时，真正重要的不是“你去做这件事”，而是“你可以在多大范围内自己做决定”。

这叫授权半径。

AI 协作也一样。

有些事可以放心交办：改文案、补测试、按既有模式加字段、修一个边界清楚的小 bug。人类只需要看结果和验证。

有些事需要轻审方案：普通功能、小型重构、接口调整。AI 可以写，但动手前要先说明目标、影响面和验证方式。

有些事必须深度参与：数据模型、权限、安全、支付、并发、迁移、核心状态机、架构边界。这里人类不能等最后验收，必须先参与设计。

还有些事只能共同驾驶：线上事故、不可逆操作、大规模删除、核心系统重写。AI 可以帮忙分析和执行，但每一步都要解释状态和下一步。

这套分层的意义，不是搞流程。

它是在回答一个管理问题：我允许这个执行者在多大范围内不请示我？

如果没有授权半径，AI 就会在两个方向上出问题。

一种是被管死。所有小事都要请示，速度优势没了。

另一种是被放飞。它把一个小需求做成一套框架，把一个临时例外抽象成长期模式，把一个局部修补变成跨模块改造。

AI 最大的问题有时候不是不够主动，而是太主动。它不会像人一样天然感受到“这块代码背后有组织历史”“这个字段虽然丑但别动”“这个边界不是技术边界，是团队协作边界”。

这些东西必须由人来给。

管理 AI 的第一步，不是更会 prompt，而是更会定义授权半径。

五、不要盯过程，要设升级条件

管理不等于盯人。

一个负责人不该要求下属每十五分钟汇报一次，但他应该要求下属在某些情况下一定要升级。

比如预算超了，要升级。客户改需求了，要升级。风险超出预期了，要升级。原方案不可行了，要升级。

AI 也应该有这样的升级条件。

平时让它快。遇到这些情况，必须停：

它想扩大任务范围。

它想引入新依赖、新框架、新抽象。

它要改数据结构、权限边界、状态模型。

测试失败后，它准备换一个思路绕过去。

改动文件数量明显超出预期。

它发现需求和现有系统冲突。

它开始说“不确定”“可能”“看起来应该”。

它无法说明某个行为为什么安全。

这些停点比逐行审查更重要。

逐行审查是在看已经发生的局部变化。升级条件是在保护系统的方向盘。它让 AI 在正常区间里高速执行，但一旦碰到会改变系统演化方向的事，就把人叫回来。

这也是人类参与深度的平衡点。

不是每一步都深。

而是在该深的地方突然变深。

六、最重要的交付物不是代码，是交接

如果一个下属完成了重要工作，你不会只接受一句“搞定了”。

你还会问：怎么做的？为什么这样做？风险在哪里？后续谁来维护？出了问题怎么回滚？下一次改这块要先看哪里？

AI 完成任务以后，也应该交这些东西。

我现在越来越觉得，AI 时代每个稍微重要的改动，都应该有一份交接说明。它不需要长，但必须回答几件事：

这次系统发生了什么变化？

为什么选择这种做法？

哪些边界没有动？

新增或保持了哪些不变量？

测试证明了什么，没有证明什么？

未来修改这块，入口在哪里？

如果要回滚，怎么做？

这份东西的价值，常常比 diff 大。

diff 告诉你文件怎么变了。交接说明告诉你系统为什么变成这样。

前者是记录，后者是理解。

很多 AI 协作最大的浪费就在这里：Agent 当场解释得很好，人也当场听懂了，但解释留在聊天窗口里。几天后上下文消失，项目里只剩代码。下一次再改，团队又要重新考古。

这等于把组织记忆存在临时对话里。

这不是 AI 的问题，是管理的问题。

一个组织不会允许核心客户资料只存在某个销售的微信聊天记录里，也不应该允许核心技术判断只存在某次 AI 对话里。

AI 的产出只有进入组织记忆，才真正变成组织能力。

七、系统地图比解释 diff 更重要

Geoffrey Litt 提到 explain-diff、小测验、微观世界，我觉得都很有启发。

explain-diff 的价值，是让 AI 不只是甩给你一堆文件变化，而是先讲背景，再建立直觉，再解释代码。

小测验的价值，是防止人类骗自己“我看完了所以我懂了”。

微观世界的价值，是让 AI 不只替你调试，还能搭一个可操作环境，让你亲眼看到系统如何运行。

但如果再往前走一步，我觉得长期项目真正需要的是系统地图。

不是每次改动的一份漂亮解释，而是一张持续更新的地图：

系统的核心模块是什么？

业务概念怎么定义？

数据如何流动？

哪些不变量不能破坏？

重要设计决策为什么这么做？

常见变更路径从哪里开始？

故障时应该如何观察和回滚？

有了地图，人类不需要每次重新理解全部代码。人类只需要理解地图怎么变了。

这就是 AI 时代的工程文档新意义。它不只是给新人看的，也不只是为了合规。它是人类在高速执行面前维持系统感的仪表盘。

没有地图，人类只有两个选择：要么逐行读代码，太慢；要么相信 AI 解释，太轻。

地图提供第三种选择：让 AI 高速改变局部，让人类持续掌握整体。

这里有一个很朴素的检查标准：三十分钟接手测试。

一次重要 AI 改动结束以后，假设这个会话立刻消失，换一个人或另一个 Agent 来接手，他能不能在三十分钟内知道这件事为什么做、做到什么程度、哪里最危险、下一步该看哪里？

如果不能，就说明这次产出还没有真正进入组织。

它只是进入了仓库。

仓库保存代码，组织保存理解。两者差得很远。

很多团队会把“代码已经合并”当成结束点，但在 AI 参与之后，这个结束点太早了。因为 AI 能把代码合并这件事变得非常便宜，而真正昂贵的是：以后的人还能不能继续沿着这条路走。

三十分钟接手测试逼迫我们问一个管理问题：这件事是不是只能由原来的执行者继续解释？

如果答案是是，那就还没有完成。

八、新的 code review，是审世界模型

传统 code review 审代码。

有没有 bug，风格是否一致，性能有没有问题，异常有没有处理，测试有没有覆盖。

这些仍然重要，但已经不够了。

AI 时代更重要的 review，是审 Agent 的世界模型。

它是否真的理解业务目标？

它有没有把偶然需求抽象成永久结构？

它有没有为了通过测试而牺牲系统语义？

它有没有绕过已有边界，只是因为那样更容易完成任务？

它有没有引入团队无法维护的新概念？

它知不知道自己不知道什么？

这类问题，才是人类应该用力的地方。

AI 越强，人类越不应该困在低层实现里。但这不等于人类退出。恰恰相反，人类要上移到更高层的 loop。

低层 loop，写代码、补测试、改格式、跑命令，可以交给 AI。

中层 loop，模块边界、接口语义、状态模型，需要人类校准。

高层 loop，为什么做、什么不能牺牲、系统未来往哪里长，必须留在人手里。

如果高层 loop 也交出去，人就不再是负责人，而只是一个礼貌的审批按钮。

九、为什么理解不能外包

Karpathy 那句话很准：思考可以外包，理解不能外包。

思考可以外包，是因为很多局部推理、方案展开、代码生成、测试补全，AI 都能做得很快。你不必亲自走完每一条路，也不必手敲每一块砖。

但理解不能外包，是因为理解不是一个中间产物。

理解是一种继续行动的能力。

你理解一个系统，不是因为你能背出它的代码，而是因为新情况出现时，你知道该问什么、该怀疑什么、该保护什么、该放弃什么。

AI 可以给你答案，但它不能替你拥有这种“下一步判断力”。

更准确地说，它可以帮你形成理解，但不能替你保有理解。

这就是为什么我不喜欢把 AI 协作描述成“人退出循环”。更好的说法是：人从低层循环上移到高层循环。

人不必亲手执行所有细节，但必须设计目标、边界、升级条件、交接机制和系统地图。

人不必知道 AI 每分钟在做什么，但必须确保 AI 做完以后，组织没有变得更脆弱。

十、真正需要的不是重流程，而是轻制度

一说到管理，很多工程师会本能反感。

这很正常。因为很多所谓管理，确实只是把本来能做事的人拖进流程，把清楚的问题写成文档，把有判断的人压成表格。

所以这里说“像员工一样管理 AI”，不是要给每次 AI 改代码都搞一套庞大审批。恰恰相反，好的制度应该让快的地方更快，让危险的地方自动慢下来。

我觉得最小的一套制度，只需要四个东西。

第一是任务前的 Mission Brief。

不是长文档，只是一小段确认：目标是什么，为什么做，成功标准是什么，哪些东西不做，哪些边界不能碰，验证方式是什么。

这一步的作用，不是让 AI 写作文，而是检查它有没有理解任务。很多错误在这里就能暴露。比如它把“补一个导出按钮”理解成“重做报表模块”，把“修一个权限 bug”理解成“改造权限体系”。越早发现，越便宜。

第二是过程中的升级条件。

AI 平时可以自己跑，但一旦要改范围、引入新依赖、触碰数据模型、绕过测试失败、修改权限边界，就必须停下来。这相当于告诉一个下属：日常决策你自己做，但预算、法律、客户承诺和组织结构这些事，不能擅自决定。

第三是结束后的 Handoff Note。

重要任务做完以后，不要只说“完成了”。要留下这次系统改变了什么、为什么这样改、哪些不变量仍然成立、测试证明了什么、未来要改这块先看哪里。

这不是为了仪式感。它是在把 AI 的临时解释转化成团队的长期记忆。

第四是持续更新系统地图。

很多团队的问题不是没有文档，而是文档和系统已经脱节。AI 参与以后，这个问题会变得更严重，因为系统变化速度更快。所以每次 C 类以上改动，都应该问一句：这次改变是否应该更新架构图、领域模型、不变量、ADR 或 runbook？

这四件事放在一起，才构成真正的“管理 AI”。

任务前定边界，过程中设停点，结束后做交接，长期维护地图。

这不是要把 AI 变慢，而是要防止 AI 的快把团队甩下车。

十一、节奏应该是前面慢，中间快，异常慢，收尾慢

如果用一句话总结 AI 协作的节奏，我会说：

开始时慢一点。

实现时快一点。

异常时慢一点。

结束时慢一点。

开始时慢，是因为任务定义最便宜。目标、边界、不做什么、验证方式，这些东西如果一开始不说清楚，后面所有速度都可能是在加速偏航。

实现时快，是因为这正是 AI 的优势。让它读文件、写代码、补测试、跑命令、修小错、生成迁移脚本。只要还在授权半径内，就不要用人的速度去限制它。

异常时慢，是因为异常通常意味着系统模型发生了冲突。测试失败、需求矛盾、改动扩大、现有架构不支持，这些都不是“让 AI 再试几次”就该糊过去的信号。它们是在提醒人类：这里需要判断。

结束时慢，是因为任务完成不等于组织吸收。代码合进去，只是产出进入仓库。解释、决策、测试证据、回滚方式进入团队记忆，才算产出进入组织能力。

这套节奏比“全程盯着”轻，也比“最后验收”稳。

全程盯着，会毁掉 AI 的速度。

最后验收，会错过最该干预的时刻。

真正的平衡，是让 AI 在正常区间里尽量快，让人类在方向、异常和交接处足够深。

十二、最好的 AI 协作，是团队越来越强

判断一套 AI 工作流好不好，不要只看它当次省了多少时间。

还要看它做完以后，团队有没有变得更强。

如果 AI 每完成一次任务，系统更难理解一点；每生成一批代码，人类更不敢动一点；每解决一个问题，关键判断都留在聊天记录里；每次提速，都换来更多隐性依赖，那这不是进步，是透支。

好的 AI 协作应该反过来。

AI 每完成一次任务，系统地图更清楚一点。

AI 每引入一个改动，边界更明确一点。

AI 每解决一个问题，团队多一份可复用的判断。

AI 每跑得更快，人类对方向的掌控更强，而不是更弱。

所以，“AI 不是员工，但要像员工一样管理”这句话，重点不在拟人化。

重点在后半句：管理。

管理的核心不是监控劳动，而是让劳动成果进入组织能力。

管理 AI 也是一样。

你不必知道它每一分钟在干什么。

但你必须确保：即使这个 Agent 明天消失，换一个模型、换一个人、换一个上下文窗口，你仍然能继续指挥这个系统。

这才是 AI 时代真正的掌控感。

参考：