AI组织变革真相：部门管人，项目管事

上个月，我们在设计一个数据驱动工作的产品。

逻辑很简单：让重要的数据变化，主动推送给该知道的人。

Demo 做到第十几个版本，功能越来越全，我却越来越不安。因为我发现了一个绕不过去的问题——老板在产品里@了一个下属，让他跟进华南区的收入下滑。但这个下属只有华南区的数据权限，他看不到老板看到的那张全国大盘图。 

那一刻我意识到，我们做的不是一个消息推送功能。

我们撞上了一堵墙：现在的组织结构，本身就不适合信息自由流动。

老板的视角是全局的，下属的视角是局部的。信息要向下流转，权限却不能向下扩散。于是所有协同都必须经过「人工翻译」这道工序：老板看数据 → 开会讲一遍 → 中层理解 → 拆解到小组 → 一线执行 → 再逐级汇报上去。

这套流程在 AI 之前是合理的，因为信息传递本来就慢，大家都慢，所以没人觉得是问题。

但当 AI 已经能在三秒内发现异常、十秒内完成归因、并且直接告诉你该找谁的时候，中间这五道人工传递，就成了整个组织里最刺眼的那段延迟。

现在关于 AI 组织变革的讨论，很容易滑向两个极端。一个是「超级个体」——一个人加一堆 Agent，干掉一个团队；另一个是「组织不需要了」——扁平、自组织、去中心化。

我的看法比较保守：部门、中心、小组这套结构，一个都不会消失。

因为它解决的是这些问题：

• 人属于哪里，谁给他发工资、做绩效、管晋升
• 预算从哪来，资源怎么配
• 专业能力谁负责建设
• 出事了谁承担最终责任
• 合规、风控、审计怎么落地

AI 不会让这些问题消失。任何试图用「AI 时代不需要层级」来回避这些问题的方案，最后都会在第一次事故中被打回原形。

真正需要改变的不是「有没有组织」，而是不能再让所有工作，都沿着组织汇报关系流动。

我倾向于把 AI 时代的组织理解成三层：

一句话概括：组织树管「人」，项目管「事」，AI 管「信息流和工作流」。

过去这三层是揉在一起的——你属于哪个部门，就干那个部门的活，信息也只在那个部门流动。AI 时代要做的，是把它们解耦：一个人可以只属于一个部门，但同时出现在五个项目里，而 AI 持续在这些项目中监测数据、解释变化、分派任务、沉淀知识。

我把这套东西叫做数据驱动的项目制。

注意，重点不在「项目制」——这个词已经被说烂了，敏捷、Scrum、Spotify 模型、OKR，都在讲小团队闭环。重点在前面四个字：数据驱动。

传统项目制的启动方式是「人拍脑袋」：某个领导觉得这里有问题 → 立项 → 找人 → 排期 → 开始干

问题是，立项这个动作本身，依赖有人先发现问题、并且有意愿推动它。现实中会漏掉大量东西：

• 一个客户连续三个月用量下滑，但没人负责盯
• 某条产品线的毛利在慢慢恶化，季度复盘时才发现

这些都不是「没人能解决」，而是没人发现它需要被解决。

数据驱动的项目制，启动方式反过来：数据发生变化 → 系统判断这个变化重要 → 自动形成一个待处理的工作 → 找到该负责的人 → 组成临时协作单元 → 处理完成后归档

项目不再由人立项，而是由数据事件触发。这里面最关键的转变是：组织不再围绕「职能」划分工作，而是围绕「业务对象」和「经营目标」组织工作。

所以我们在设计项目的时候，做了一个很重要的决定：不按部门建项目。

不推荐这样：数据产品中心项目、经营分析小组项目、渠道业务部门项目。

而是这样：

• A产品商机转化

• B客户增长与风险

原因很简单：收入下降这件事，从来不属于某一个部门。它同时涉及销售、产品、交付、财务。你按部门建项目，第一天就得建四个群，然后在四个群里各说一遍。按对象建项目，一个项目就是一个战场，所有相关的人都在里面，看到的是同一份数据。

再补一个细节：按部门建的项目，组织架构一调整就得迁移一次；按业务对象建的项目，只要这个业务还在，项目就一直在。这在实践中省掉的麻烦，比想象的多。

这是我认为最被低估的一点。

我们开了太多「对齐会」。为什么需要对齐？因为每个人手里的信息不一样。销售看自己的报表，产品看自己的看板，财务看自己的口径。三个人说「收入」，指的是三个不同的东西。于是开会的前四十分钟，都在校准「我们说的是不是一回事」。

AI 时代最大的机会，其实不是「AI 帮我写得更快」，而是：让协作的所有人，从一开始就站在同一份可信的上下文里。

什么叫「同一份上下文」？不是「我们都看同一张图」，而是至少包含五层：

1. 同一个业务对象：我们讨论的是同一个客户、同一个产品、同一个渠道
   
   
2. 同一个指标口径：这个「收入」的定义、过滤条件、时间范围是被认证过的
   
   
3. 同一份证据链：这个结论来自哪张表、哪个时间、什么权限范围
   
   
4. 同一段历史：上次这个问题是怎么处理的、结论是什么、有没有效
   
   
5. 同一份进度：谁在跟、到哪一步了、什么时候闭环
   
   

前面三层是「数据可信」，后面两层是「协作可信」。

这也是为什么我们在做产品之前，先花了大量时间做知识库——把术语、指标、规则、流程、常见问题都沉淀成结构化的「原子」。因为没有可信口径，就没有共享上下文；没有共享上下文，AI 生成的每一条结论都得人工复核一遍，那就白干了。

顺便说个我踩过的坑。做知识库最容易犯的错，是只测「AI 回答得像不像」。我们后来定的测评方式是分四层测：问题理解、路由、知识召回、答案生成。因为只测最终答案，你根本不知道错在哪——是路由走错了域，还是召回漏了关键规则，还是生成时把口径写错了。

而且有两条红线必须单独算，不能被平均分掩盖：权限泄漏率必须为 0，核心口径编造率必须为 0。

一个措辞流畅但口径错误的回答，用户满意度往往还不低。这是最危险的情况。用户满意度不等于准确率——这句话我建议每个做 AI 产品的人都贴在显示器上。

传统组织里，工作的分配路径是：人发现问题 → 人判断优先级 → 人找人 → 人干活 → 人汇报。

AI 时代应该是：系统发现变化 → AI 判断重要性 → AI 找到负责人 → AI 先干能干的 → 干不了的交给人 → AI 追踪结果

第一步：让工作自己被发现。这一步的产品化形态，我们叫数据事件引擎，它把指标变化转化成有业务含义的「事件」：阈值突破、同比环比异常、趋势拐点、结构性变化（总量没变但构成变了，这类最容易被漏掉）、目标偏差、对象状态变化、数据质量异常、口径或规则变更。

关键不是「能不能检测出异常」——这个技术上早就不难了。关键是降噪：同类事件合并、重复事件抑制、已知原因自动关联、重要程度分级、长期无人处理的事件升级。

我给自己定的标准是：如果一个项目的消息，用户开始习惯性划过，这个产品就已经死了。

第二步：AI 派活，而不是人派活。这一步最难，难点不在技术，在权限。回到文章开头那个问题：老板@了只有局部权限的下属，怎么办？有三种做法，只有一种是对的。

我们把第三种做法叫权限感知的任务投影。同一个@动作，生成两个权限隔离的上下文。

老板侧看到的：

张三侧看到的：

注意，张三收到的不是老板卡片的裁剪版，而是系统用张三的身份重新查询、重新计算、重新生成的一份内容。

技术上这意味着：AI 生成任务时要传入两个身份——发起人身份决定「谁交办的、任务归属哪个项目」，接收人身份决定「查什么数据、用什么权限」。发起人的权限，绝对不能参与接收人的数据查询。

还有个容易翻车的地方：缓存。如果缓存键只按「项目 + 问题」来做，两个权限不同的人问同一个问题，第二个人就会拿到第一个人的结果。缓存键至少要包含接收人身份、权限范围哈希、行级权限谓词哈希和知识快照版本。

信息可以向下流转，数据权限不会随任务向下扩散。

第三步：AI 干活，人只处理 AI 干不了的。这一步价值密度最高，也最容易被做成噱头。我的分层是这样的：

大部分产品失败在两个地方：要么只做到 L1，用户看完还得自己去别的系统干活；要么直接跳到 L4，让 AI 去做需要担责的事，出一次事就再也没人信了。先把 L1 和 L2 做扎实，比在 L4 上做演示重要得多。

顺便说一个我们内部的观察数据：看板的 AI 入口使用率只有 0.085%，但同期 MCP 调用量涨了 30 倍。这个对比很说明问题——用户不想打开看板再问 AI，用户想直接问 AI。所以「AI 干活」的正确形态，不是在原有工具里加一个 AI 按钮，而是让 AI 成为工作发生的地方。

第四步：搞不定的求助人——这一步最容易被漏掉。我见过太多「AI 自动化」方案，卡在这一步。AI 做不了的时候怎么办？关键不是「降级给人」，而是「降级给人的时候，把上下文完整交出去」。

AI 求助人的时候，必须带上：我做到哪一步了；我为什么做不下去（数据不够、口径不明、需要判断、需要授权）；我的初步判断和置信度；我建议你决定什么；决定之后我可以继续做什么。

如果 AI 只是丢一句「处理失败，请人工介入」，那人还得从零开始理解，这次自动化其实是负收益的。反过来，如果 AI 交出的是「我已经查清 8 个客户，其中 3 个我判断是主要原因，但有 2 个我无法确定是否属于口径变更导致，需要你确认」——这次求助本身就是有价值的交付。

衡量一个 Agent 好不好，不要只看它能自动做多少，还要看它做不了的时候，交接得有多干净。 

这条链路里，人的角色发生了根本变化。

过去一个管理者的核心工作是：收集信息、判断优先级、分派任务、追踪进度、向上汇报。这五件事，AI 都能做，而且做得更快、更全、更一致。

那人做什么？

• 定义什么叫「重要」
• 决定有争议的事
• 承担需要担责的判断
• 处理 AI 处理不了的复杂关系
• 维护那套让 AI 可信的知识和口径

这不是「人被替代」，而是人从「信息中转站」变成「判断者和标准制定者」。

说得更直白一点：AI 时代最没价值的管理动作，就是把上面的信息传递给下面，再把下面的信息汇总给上面。

写到这里，我得说几个还没想透的地方。

1. 绩效怎么算。如果一个人同时在五个项目里，他的绩效由谁评？部门给他打分，但他 70% 的产出在跨部门项目里。这是矩阵组织的老问题，AI 并没有解决它，反而因为项目变多、变短、变动态，让它更复杂了。我目前的想法是：绩效仍归部门，但项目贡献必须可被记录和引用——而这件事恰好是项目天然能做到的，因为所有行动和闭环都留了痕。

2. AI 派的活，谁负责。AI 判断「这件事很重要，应该由张三处理」。如果 AI 判断错了，张三花了三天做了一件不重要的事，责任在谁？我认为必须有明确规则：AI 可以派活，但派活规则必须由人定义、可审计、可申诉。项目Owner 要能看到「AI 派了哪些活、多少被判定为误报」，并据此调整规则。

3. 效率提升了，事情反而更多了。这是最反直觉的一点。AI 让发现问题的成本降到接近于零之后，你会发现问题多到处理不完。过去只能发现 10 个问题，处理 8 个，感觉良好；现在能发现 200 个，还是只能处理 8 个，焦虑感反而上升。所以数据事件引擎必须内置优先级和克制。一个能发现一切的系统，如果不能帮你决定先处理什么，它只是把焦虑规模化了。

4. 组织摩擦不会自动消失。AI 提升的是执行速度，但如果组织里还有一堆审批、排期、跨部门协调，最后的瓶颈会从「干得慢」变成「批得慢」。

组织竞争力 = 人才密度 × AI 杠杆 ÷ 组织摩擦 

AI 只优化了分子。分母不动，总分不会变好，甚至会因为分子变大而让分母的问题更刺眼。

AI 时代的组织变革，不是让人干得更快，而是让工作不再需要人去发现、去传递、去分派。

部门继续管人，项目开始组织工作，AI 负责让信息和任务自己流到该去的地方。而这一切的前提，是有一份所有人都信、AI 也能用的数据和口径。

这也是我这段时间做数据项目、做知识库、做权限投影的真正原因——它们看起来是三个产品功能，其实是同一件事：

为 AI 时代的组织，铺一层可信的、能流动的、能行动的信息底座。

组织形态的变化，从来不是先改组织架构图，而是先改信息怎么流动。信息流动的方式变了，组织形态自然会跟着变。

关注公众号，在对话框回复关键词"落地案例"，您将获取虎嗅智库最新一手优质AI落地案例集～

虎嗅智库：

是围绕 AI 产业落地的「行业判断与共识形成平台」，通过长期运行的案例研究、场景拆解与闭门研讨，帮助产业及企业决策者在 AI 关键选择上看清边界、规避误判、降低试错成本。已沉淀超200份深度研究，覆盖制造、零售、金融、医疗等核心赛道。