AI 不是员工，但要像员工一样管理（万维钢取向版）

发表于 | 分类于

AI 不是员工，但要像员工一样管理（万维钢取向版）

先说一个反直觉判断：

AI 编程最大的风险，不是 AI 写错代码，而是 AI 写对了代码，但团队变弱了。

这听起来有点怪。AI 都把代码写对了，测试也过了，功能也上线了，团队怎么会变弱？

答案是：因为软件团队真正积累的，从来不只是代码。团队积累的是对系统的理解、对边界的判断、对风险的直觉、对下一步怎么改的能力。

AI 可以很快地给你代码，但它不一定把这些东西留给你。

于是会出现一种很现代的场景：项目进度在前进，代码仓库在变大，功能列表在打勾，仪表盘一片绿色，但人的脑子里对系统的掌控感正在下降。

这就是所谓“理解是新的瓶颈”真正有意思的地方。

表面上看，是 Agent 写代码太快，人类读 diff 太慢。再往下看，是系统变化速度超过了人的 mental model 更新速度。再往下一层，其实是一个管理学问题：

当一个高执行力单位开始高速改变系统，负责人如何避免组织能力被掏空？

所以我现在觉得，讨论 AI 编程，不能只问“人类还要不要看代码”。

这个问题太低了。

真正应该问的是：人类如何管理一个不是员工、却正在制造员工式风险的执行者？

一、别把 AI 只当工具

我们习惯把 AI 叫工具。

这个说法不算错，但已经不够用了。

锤子是工具。搜索引擎是工具。IDE 是工具。工具的特点是：你用它，它不自己推进事情；你停下，它也停下；它不会替你做范围判断，也不会偷偷改架构。

Agent 不一样。

它会读文件、拆任务、写代码、修测试、解释原因、改方案。你让它修一个 bug，它可能顺手重构一个模块；你让它加一个字段，它可能顺便抽象一个服务；你让它迁移页面，它可能写一个脚本、跑一遍、再修一遍。

这已经不是传统工具的工作方式。

但它也不是员工。

员工有组织记忆，有责任感，有长期身份，有职业声誉，有情境理解。一个老员工知道这个字段为什么这么丑，知道某个接口为什么不能动，知道老板嘴里的“简单改一下”其实可能牵动三条业务线。

AI 没有这些东西。

出了问题，你不能让它背绩效；系统变乱，它不会焦虑；它这次会话结束以后，很多当场解释过的上下文就没了。

所以 AI 是一个奇怪的新物种：它不是员工，但它开始制造员工式的管理风险。

它可以形成单点依赖。

它可以让关键判断只存在于一次对话中。

它可以把当下任务完成得很好，却让后续接手的人更难继续。

它可以让你产生一种幻觉：我还在 loop 里，因为每一步都是我点头的。

但如果你已经无法判断它为什么这么做、以后该怎么改、哪些边界被改变了，那你就不是真的在 loop 里。

你只是一个礼貌的审批按钮。

二、管理问题的本质：产出不等于能力

管理里有个基本常识：一个下属完成了任务，不等于组织获得了能力。

比如公司里有个特别能干的人，客户都靠他维护，流程都靠他记住，系统都靠他救火。他在的时候，团队效率极高。老板觉得这人太值了。

直到有一天他请假，大家才发现：客户关系不在 CRM 里，故障处理没有 runbook，关键判断没有文档，新人完全接不上。

这时你才明白：过去那些漂亮产出，有一部分根本没有进入组织能力，只是暂存在这个人的脑子里。

AI 协作也会发生同样的事。

一个 Agent 帮你写完一个功能，如果只有它在对话里解释过“为什么这样设计”，而代码库里没有测试表达约束，没有文档记录边界，没有决策记录说明取舍，没有系统地图更新，那么这个产出就只是进入了仓库，没有进入组织。

仓库保存代码。

组织保存理解。

两者差得很远。

过去，人类亲手写代码，慢是慢，但慢本身有一个副作用：它迫使你理解。你要亲手设计数据结构，亲手调试边界条件，亲手处理状态流转。你在执行过程中顺便建立了系统感。

AI 把这个过程跳过去了。

这当然是进步。没人怀念手工搬砖。但问题是，原来隐藏在“搬砖过程”里的学习，也一起被跳过了。

所以 AI 时代的一个新公式是：

真正的效率 = AI 产出速度 × 组织吸收率。

如果 AI 产出速度提高十倍，但组织吸收率下降到十分之一，最后不一定赚。

你只是把理解成本从今天挪到了未来。

而未来还会收利息。

这个公式有一个好处：它解释了为什么很多人对 AI 编程的体验会分裂。

一个人用 AI 做 side project，爽得不得了。因为他的组织吸收率接近 100%。代码是他要的，系统是他自己的，未来维护也是他自己。他让 AI 写完以后，哪怕文档少一点，他也能凭记忆和直觉接上。

另一个人在大公司的核心系统里用 AI，反而觉得麻烦。因为那里组织吸收率很低。代码库有十年历史，权限有合规约束，字段背后有业务历史，测试不一定覆盖隐含规则，很多边界只有老员工知道。AI 写得越快，吸收压力越大。

所以 AI 编程不是一个“效率提升百分之多少”的均匀问题。

它更像给系统加了一台高速发动机。

如果传动系统很好，发动机越强，车越快。

如果传动系统很差，发动机越强，震动越大。

组织吸收率，就是这套传动系统。

文档、测试、架构边界、决策记录、代码可读性、交接机制、团队共同语言，都是传动系统的一部分。它们平时看起来不像生产力，甚至像负担。直到 AI 把发动机马力突然拉高，你才发现，真正决定速度的不是马力，而是这辆车能不能承受马力。

这也是为什么“理解是新的瓶颈”不是一句文艺感慨，而是一个工程判断。

过去瓶颈在写代码，谁能写，谁就推进项目。

现在瓶颈在吸收变化，谁能把 AI 的高速产出转化成团队可继承的能力，谁才真正提高了效率。

这也是为什么同一套 AI 工具，在不同团队里会像两个完全不同的产品。在一个边界清楚、测试充分、文档能跟上的团队里，它像加速器；在一个隐性规则满天飞、所有判断靠资深员工口传的团队里，它像放大器，把原来的混乱放大得更快。

工具相同，结果不同，差别不在模型，而在组织能不能吃下模型制造的变化。

吃不下，智能越便宜，管理越昂贵。

这就是 AI 编程最反直觉的地方：工具越强，组织越需要基本功。

三、正确代码为什么更危险

很多人担心 AI 写错代码。

这个担心当然合理，但还不够深。

错代码通常有信号。测试失败，构建报错，线上异常，用户投诉，日志不对。它们麻烦，但至少会把问题暴露出来。

真正可怕的是另一类代码：

它是对的。

它能跑。

它通过测试。

它解释起来也合理。

但它引入了一套团队没有吸收的新抽象，改变了一些没人命名的边界，埋下了一些未来才会显影的假设。今天你觉得“省了一天”，三个月后再改这块，突然发现自己不知道从哪里下手。

这就像一个明星员工做出一套很漂亮的 Excel 模型。它能算，结果对，老板满意。但公式藏在十几个 sheet 里，没有注释，没有说明，只有他知道为什么这么连。这个模型越有用，组织越依赖它；组织越依赖它，风险越大。

AI 写出的正确代码，也可能是这样的 Excel。

它不是坏。

它是不可继承。

这就是认知负债。

技术债通常看得见：重复、混乱、慢、难改。认知债更隐蔽。它的外观常常是“进展顺利”。你只有在下一次需要判断、修改、排障、扩展时，才发现团队已经跟丢剧情。

所以 AI 编程里最重要的问题，不是“这段代码有没有 bug”。

而是：这段代码写完以后，我们是否还拥有下一步行动权？

四、理解不是读懂代码，而是保留行动权

“理解代码”这个词，很容易把人带偏。

很多人一听理解，就想到逐行读 diff。这个函数怎么写，那个文件怎么改，变量为什么这么命名。

如果 AI 时代还这样理解“理解”，人类一定会输。

因为人脑不适合追踪无限局部。AI 可以一分钟改十个文件，人类不可能靠读完所有细节来维持控制。

但管理者也不是靠记住所有细节来管理团队。

好的负责人不需要知道下属今天每封邮件怎么写，但他必须知道：

目标是什么。

边界在哪里。

哪些事不能牺牲。

出了问题谁能接手。

下一步要改变方向时，应该动哪里。

所以 AI 时代的理解，要重新定义。

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

理解是“我知道系统为什么变成现在这样，并且我知道下一步如何安全地改变它”。

前者面向过去。

后者面向未来。

这也是为什么人类参与深度不能按代码量分配。

两千行机械迁移，可能只需要看迁移规则和验证证据。二十行状态模型修改，可能必须深究，因为它改变了系统以后怎么生长。

判断参与深度的标准，不是“AI 写了多少”。

而是“这件事未来会不会影响我的判断”。

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

凡是改变轨道，必须深。

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

管理下属，最关键的不是派任务，而是定义授权半径。

“你去买咖啡”是一种授权。

“你去谈一个百万级合同”是另一种授权。

“你可以自己决定折扣，但超过 15% 要回来确认”又是第三种授权。

AI 也一样。

我们不能只说“帮我实现这个功能”。这句话太粗糙。它没有告诉 AI 哪些地方可以自己决定，哪些地方必须回来请示。

于是 AI 会走向两个极端。

一种是被管死：什么都要问，速度没了。

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

所以需要任务分级。

A 类，放心交办。文案、样式、小 bug、补测试、按既有模式加字段。人类只看结果和验证。

B 类，轻审方案。普通功能、小型重构、接口调整。AI 先说目标、影响面、验证方式，人类看方向。

C 类，深度参与。数据模型、权限、安全、支付、并发、迁移、核心状态机。人类先审设计，再让 AI 执行。

D 类，共同驾驶。线上事故、不可逆操作、大规模删除、核心系统重写。AI 只能分步走，每一步都解释状态和下一步。

这不是流程洁癖。

这是授权半径。

管理 AI 的第一步，不是更会写 prompt，而是更会定义：在什么范围内你可以自己跑，碰到什么必须停。

六、别盯过程，要设升级条件

很多人一听“管理 AI”，就会想到监控。

每一步都问，每一段都审，每次改文件都解释。

这不是管理，这是把 AI 的速度打回人类速度。

真正好的管理，不是盯过程，而是设升级条件。

一个下属平时可以自己处理工作，但预算超了要升级，客户改需求要升级，风险超出预期要升级，原方案不可行要升级。

AI 也应该这样。

平时让它快。遇到下面这些事，必须停：

它想扩大任务范围。

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

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

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

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

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

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

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

这些停点，比逐行 review 更重要。

逐行 review 是看已经发生的局部变化。升级条件是在保护系统方向盘。

AI 最大的问题有时不是懒，而是太勤快。它会为了完成目标主动补洞、绕路、抽象、扩大范围。人类要管的不是每个动作，而是它什么时候必须把方向盘交回来。

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

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

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

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

每个稍微重要的 AI 改动，都应该有一份交接说明。它不需要长，但必须回答：

这次系统改变了什么？

为什么选择这种做法？

哪些边界没有动？

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

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

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

如果要回滚，怎么做？

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

diff 告诉你文件怎么变了。

交接说明告诉你系统为什么变成这样。

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

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

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

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

八、系统地图比 explain-diff 更重要

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

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

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

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

但如果往前再走一步，长期项目真正需要的，不是一份份漂亮的解释，而是一张持续更新的系统地图。

这张地图至少回答：

系统核心模块是什么？

业务概念怎么定义？

数据如何流动？

哪些不变量不能破坏？

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

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

故障时如何观察和回滚？

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

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

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

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

这里还有一个简单测试：三十分钟接手测试。

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

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

它只是进入了仓库。

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

传统 code review 审代码。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果高层 loop 也交出去，人就不再是负责人，而只是一个会点确认按钮的人。

十、理解不能外包

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

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

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

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

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

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

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

这就是为什么我不喜欢把 AI 协作描述成“人退出循环”。

更好的说法是：人从低层循环上移到高层循环。

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

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

十一、一套最小制度

说到这里，很容易误会成“又要加流程”。

不需要。

真正好的制度，应该让快的地方更快，让危险的地方自动慢下来。

我觉得最小只需要四件事。

第一，任务前写 Mission Brief。

目标是什么，为什么做，成功标准是什么，哪些东西不做，哪些边界不能碰，验证方式是什么。

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

第二，过程中设升级条件。

平时让 AI 自己跑，但一旦碰到范围、依赖、数据模型、权限、状态、测试失败绕路，就停下来。

第三，结束后写 Handoff Note。

重要任务做完以后，不只说“完成了”，还要留下变化、原因、边界、不变量、验证、风险和回滚方式。

第四，长期更新系统地图。

每次 C 类以上改动，都问一句：架构图、领域模型、不变量、ADR、runbook 有没有需要更新？

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

任务前定边界。

过程中设停点。

结束后做交接。

长期维护地图。

这不是要把 AI 变慢。

这是防止 AI 的快把团队甩下车。

十二、判断一套 AI 工作流好不好

最后给一个判断标准。

不要只看它当次省了多少时间。

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

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

好的 AI 协作应该反过来。

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

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

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

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

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

重点在后半句：管理。

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

管理 AI 也是一样。

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

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

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

参考：