# 个人变强了，团队也会变强吗？

个人用 AI 的提效很容易被看见。材料写得更快，代码改得更快，图片和 Demo 也来得更快。

团队层面的变化没这么直接。组织不按截图和录屏结算，它关心的是需求有没有少偏、决策有没有更准、返工有没有减少、上线以后有没有少出事故。一个人多生成了几份东西，只是多了几个输入。团队能不能消化，还是另一回事。

第一篇里我说过，产物增加很容易被误读成能力增长。到了组织里，这个误读会放大。个人觉得自己轻松了，团队可能只是多了几份需要阅读、判断和兜底的材料。

## 团队怕的是包装过的误判

产品经理的工作很适合观察这件事。

一个老练的 PM 有时只会写很短的需求。两行 JIRA，一个截图，配一句“这个入口要在支付失败后露出来”。外行看会觉得粗糙，但熟悉业务的人知道，这句话背后已经过滤掉了很多噪音。他知道用户卡在哪个页面，知道客服最近在处理什么投诉，也知道研发这周能动哪里、不能动哪里。

AI 介入后，同一个想法可以很快被扩成一份完整 PRD。背景、目标、用户故事、验收条件，全都有。会议上看起来准备充分，甚至让人不好意思再追问“你这个判断从哪里来”。

麻烦就在这里。原来一句话里没有说清的用户场景，扩写以后会被包装得像已经存在。原本该在会上被拆开的假设，进入文档以后获得了一层格式上的可信度。研发读了半天，发现真正有用的约束只有三句；测试照着验收条件写 case，写到一半才发现关键状态没有定义；上线前客服又补了一句，“这个问题只发生在企业微信入口，不是所有支付失败”。

AI 没有消灭沟通成本。它可能只是把成本从写文档的人那里，转给了读文档、实现和测试的人。

这类成本很隐蔽。写的人会觉得自己效率高了，因为他确实少花了时间。团队有没有更快，取决于那些被转移出去的判断成本有没有被计算进去。

## 有些组织并不急着变快

还有一个更难听的问题：这个组织真的想提效吗？

很多流程慢，原因不在写邮件，也不在会议纪要整理得太慢。它慢，是因为它承担了别的功能。审批在分散责任，复核在制造缓冲，多个部门都要签字，是为了让每个人都有机会表达“这事我看过”。

这不一定合理，但它可能让一个组织以某种脆弱的方式继续运转。

如果一个职能本来就是历史遗留结构，AI 只能让它更快地产生材料、更快地转发消息、更快地完成表单。它无法替这个部门回答自己为什么存在，也无法替管理者决定哪些责任应该被重新切开。

所以组织提效的起点不是“每个人都去用 AI”。更早的问题是：我们到底希望哪件事变快？这件事变快以后，谁会受益，谁会承担新的风险？

这个问题不舒服，但绕不过去。

## 目标、工作流和数据要先接上

AI 在团队里最稳的用法，通常发生在已经被认可的工作里。

客服团队要提高的核心指标，是问题有没有被正确分流，升级路径有没有缩短，用户下一次还会不会因为同一件事再来一次。销售团队需要的也不只是客户摘要，而是线索判断后有没有稳定的下一步动作，谁跟进，什么时候跟，结果写回哪里。

研发团队更明显。AI 生成代码只是一个环节。需求偏差有没有减少，diff 是否容易审查，测试失败能不能更早暴露，才更接近团队效率。

到了这个层面，AI 不能停在个人桌面上。它要进入一个清楚的工作流：输入从哪里来，哪些信息可信，哪些动作可以自动做，哪些结果必须有人确认，失败以后谁来恢复。

这就是第二篇里说的复杂性归属。普通用户不该维护一套 Agent 工作流，但团队如果想把 AI 放进生产，就必须有人维护。复杂性总要有人接住。

## 把 AI 塞进岗位格子，会压窄它

很多组织谈 AI 时，会下意识把它放进岗位表里：AI 产品经理，AI 分析师，AI 助理，AI 客服。

这个想法很自然。我们习惯用岗位理解工作，也习惯用“替代某个人”来计算收益。但 AI 更适合被看成一套横跨岗位的信息处理和执行能力。它连接数据，记录状态，提醒异常，在合适的位置把控制权交给人。

人的角色也会跟着变。

未来很多岗位会更像前线部署工程师。这里的工程师不限于写代码的人，而是那些能把一线问题翻译成可运行规则的人。他们知道哪些信息还在人的经验里，哪些数据字段一直不干净，哪些权限可以交给机器，哪些判断必须留给人。

如果借用铁匠铺的比喻，AI 不太像另一个铁匠。它更像机床和控制系统。人不再每一下都挥锤，但要懂材料、懂工艺、懂机器什么时候给出了不能接受的结果。

这个变化比“某个岗位被替代”更深，也更难管理。

## 组织重构要慢一点

既然 AI 更像系统，很多人会很自然地想画一张新流程图，把组织从头改一遍。

这个冲动很危险。

一个已经跑了很多年的组织，里面一定有大量看起来不合理的地方。有些重复确认确实低效，但它可能在分散风险；有些老员工的价值不在岗位说明里，而在他知道哪个客户不能按标准流程处理；有些报表没人爱看，但它让两个团队在吵架前有一份共同材料。

这些东西未必都该保留。问题是，外部改造者很难一眼分清哪个是赘肉，哪个是韧带。

AI 擅长加快显性的工作，尤其是文字、整理、分类和流转。它不自动理解那些藏在人际关系、历史债务和灰色责任里的结构。只看表面效率，很容易把组织里维持稳定的冗余一起删掉。

更稳的做法是局部试验。先选一个目标清楚、责任清楚、结果可检查的流程，让 AI 进去跑一小段。看速度有没有变快，错误有没有转移，人的判断是不是还留在该留的位置。跑稳了，再扩大权限。

公司不是代码仓库。组织改造也没有一次测试全绿就万事大吉的时刻。

## 个人变强只是材料

个人变强当然有价值。团队里多一些会用 AI 的人，总比没人会好。

但个人能力只是材料。它要变成团队能力，至少要过几道关：

1. 个人产物服务的是团队目标，不只是个人成就感。
2. 团队知道自己要让哪件事变快，或者哪类错误变少。
3. 输入、判断、动作和结果能被写进工作流，出了问题有人能恢复。
4. 成本和收益放在同一张账上看，而不是只统计某个人省了多少时间。

这些关过不了，AI 会让团队获得更多材料、更多方案、更多看起来合理的判断，也带来更多需要消化的工作。

这也是为什么程序员和类程序员的创作者会变得重要。他们的价值不只在写代码，而在把个人桌面上的能力包装成团队能吸收的工作方式。下一篇要讨论的，就是谁来做这件事。