九成客户选AI？飞书这次赌对了组织落地

看完这个分享，我其实一直有个困惑想请教：飞书这种“让AI理解权限、串联工作流”的做法，对企业的数据治理要求是不是特别高？我接触过一些传统制造业客户，他们连最基本的流程文档都是散的，更别提把生产数据清洗到能被AI调用的程度了。这种情况下，强行上AI会不会反而把数据孤岛问题暴露得更彻底？

另外，你提到那个AI应用成熟度模型，我特别想多了解一下——它具体是怎么划分阶段的？比如是从“单点提效”到“流程嵌入”再到“组织重构”？因为我在想，如果企业连第一阶段都没跑通，比如员工连基本的AI对话工具都用不熟练，飞书是怎么帮他们跳过这个坎的？北汽福田那个案例，是直接从生产流程入手的，还是先做了全员AI培训？

还有个小疑问：九成新增客户同时采购AI产品，这个比例会不会是因为飞书把AI功能和基础协作功能打包成套餐了？我见过有些SaaS厂商用“捆绑销售”来推新功能，如果企业为了用飞书协作不得不买AI，那这个数据含金量可能得打个折扣。当然，如果真是客户主动选择，那确实说明AI落地找到了正确路径。期待你的更多实战细节。

飞书的AI成熟度模型确实切中了要害，权限管理和数据打通才是企业级AI落地的真正瓶颈。不过有个问题想探讨：当AI深度嵌入生产流程后，权限模型本身是否也需要动态适应？比如北汽福田那个场景，如果AI根据上下文自动调整工单优先级，会不会和现有的静态权限体系产生冲突？

看到这个帖子，我特别有共鸣。作为一名在AI工程化一线摸爬滚打了几年的老兵，我经历过从大模型刚火起来时大家疯狂做demo，到现在客户真正要求“落地出效益”的全过程。你提到的飞书这个数据和观点，我觉得切中了当前企业AI落地的几个核心命门，但也有些地方我想展开聊聊，结合我自己的踩坑经历和思考。

先说结论：我完全同意你关于“最后一公里”的判断，但“九成客户选AI”这个数字背后，可能隐藏着比表面更复杂的真相。飞书的逻辑是对的，但它的“赌”并不全在技术，而是在于它试图用一套封闭生态去解决一个开放世界的组织问题——这既是它的优势，也是它的天花板。

先从我自己的一个真实案例说起吧。去年我们给一家中型制造企业做AI项目，他们的需求很明确：用大模型处理售后工单。听起来很简单对吧？但实际一上手，就发现根本跑不通。为什么？因为他们的售后流程涉及到ERP、CRM、MES三套系统，每套系统权限不同。一个售后工单进来，需要先看客户级别（CRM权限），再看设备型号（MES权限），最后决定是否触发退换货（ERP权限）。我们一开始天真地以为，只要把大模型接上API就行。结果呢？大模型根本不知道哪个员工能看到哪个客户的数据。你让一个普通售后客服的AI助手去查VIP客户的合同细节，权限立刻炸裂。更麻烦的是，不同系统的权限模型不一样：CRM是角色+数据级权限，MES是机构+岗位权限，ERP是组织架构+功能权限。我们当时尝试用向量数据库做权限过滤，但向量检索本身是模糊的，你告诉模型“不要查超过你权限的数据”，模型理解不了“超过”这个词在具体业务语境下的边界。最后我们只能退而求其次，在模型前面加了一个硬编码的规则引擎，把权限判断写死。结果就是：每次业务部门调整权限，我们就要改代码。项目最后勉强上线，但维护成本极高。

这个案例直接对应你帖子里的核心观点：AI理解权限、串联工作流、沉淀知识，这三件事缺一不可。飞书能做到，是因为它本身就是一个封闭的权限和控制体系。飞书的权限模型（如文档权限、应用权限、组织架构权限）是天然扁平且统一管理的。当AI助手要读取一个文档时，它可以直接调用飞书API判断当前用户是否有“阅读”权限，而无需自己再做一套权限映射。这就像在一个高度管制的园区里建自动驾驶——路况简单，规则明确。但现实中的企业，往往是多个园区拼起来的，每个园区的规则都不一样。飞书这套逻辑，在企业内部全部使用飞书全家桶时，确实能跑得极其丝滑。但如果企业有自研系统、有老旧的ERP、有外部的SaaS工具，飞书的AI就成了“园区内的自动驾驶”，出不了园区。

关于权限泄露的问题，你问得很关键。我参与过几个金融行业的AI项目，对数据安全极其敏感。飞书的做法，据我了解，是采用了一种“权限继承+上下文隔离”的方案。具体来说，AI模型本身不直接拥有数据访问权限，它只是一个“代理”。每次模型回答用户问题时，它实际上是在飞书的环境中发起一个请求，这个请求会携带用户的身份令牌。飞书的权限中心会判断这个令牌是否有权访问相关数据。如果用户没有权限，模型拿到的数据就是空的。听起来很安全？但问题出在“推理链路”上。比如，用户问“帮我分析一下这个季度的销售趋势”，模型可能为了回答这个问题，需要先读取销售总监的周报，但用户只有普通销售权限。如果模型在推理过程中，不小心把总监周报中的一句话带入了回答，即使最终输出时做了过滤，但推理过程本身已经接触了敏感数据。更麻烦的是，大模型的“幻觉”可能让模型自己编造权限——比如模型认为某个数据应该存在，但实际上用户看不到，模型会尝试用其他数据“补全”，这就可能间接泄露组织架构或人员关系。飞书目前的做法是严格限制模型只能访问经过显式授权的API，并且禁止模型自行搜索。但说实话，只要模型有“理解”能力，就永远存在“越狱”的风险。这一点，所有做企业AI的团队都得有心理准备，没有100%的安全，只有通过审计日志和异常检测来事后追溯。

你帖子最后抛出的问题——AI落地最大障碍是技术还是组织变革——我倾向于认为，在2025年的当下，技术障碍已经不再是第一位的，组织变革才是，但这个“组织变革”的内涵可能和大家想的有点不一样。很多人以为组织变革就是“老板放权”，但实际落地中，我遇到的最大障碍是“部门墙和数据主权”。举个例子，我们给一家大型零售集团做AI导购。技术上说，把商品库、用户画像、订单数据喂给大模型，没有任何难度。但真正卡住的是：商品部认为商品数据是他们的核心资产，不愿开放给AI团队；用户画像属于市场部，但他们怕泄露用户隐私；订单数据属于销售部，他们怕AI分析出不好的业绩。三个部门互相推诿，最后AI模型只能拿到过期的、不完整的商品信息。你猜怎么着？模型给出的推荐结果极其糟糕，大家反过来骂AI不行。所以，所谓的组织变革，很多时候不是老板不授权，而是中层管理者不愿意分享数据。飞书的做法，其实是把“数据主权”收归到平台层面——所有数据都在飞书里，权限由企业统一管理。这确实能打破部门墙，但代价是：企业必须接受飞书成为它的“操作系统”。这对于中小企业是福音，但对于大型企业，尤其是已经存在多个IT系统、有大量历史数据的企业，迁移成本极高。

再聊聊飞书那个“AI应用成熟度模型”。我看完之后觉得，它本质上是在定义一种“AI能力阶梯”。从最底层的“提效工具”（比如AI写周报、AI总结会议），到中间的“业务流程嵌入”（比如AI自动触发工单、AI审核合同），再到顶层的“组织智能”（比如AI预测项目风险、AI建议组织架构调整）。这个模型本身是合理的，但我要泼一盆冷水：很多企业连第一层都没做好，就急着想上第三层。我见过一个企业，想让AI自动生成所有部门的工作周报，结果因为飞书上的周报格式不统一，有的用文档，有的用表格，有的干脆就是聊天记录，AI根本没法统一处理。最后他们花了两周时间，把所有周报模板标准化。这个“标准化”的过程，其实就是组织变革——要求所有人按统一格式写周报。飞书的AI能力再强，也架不住企业自己的管理混乱。所以，成熟度模型的真正意义，不是技术升级，而是倒逼企业先做“管理标准化”。飞书赌的，其实是企业愿意为了用AI而先把自己内部理顺。

北汽福田那个制造场景案例，我仔细研究过。它之所以能跑通，是因为制造场景本身是高度结构化的——工单、设备状态、物料清单都是标准化的数据。AI要做的，是理解这些数据之间的逻辑关系，并在需要时触发动作。这让我想起我们曾经给一个物流仓库做的AI调度系统。仓库里有几十台AGV小车，每台小车负责不同区域的货物搬运。传统做法是写死调度算法，但遇到突发情况（比如某台小车故障、某个区域爆仓）就抓瞎。我们用大模型做动态调度，但遇到一个坑：大模型不理解“时间窗口”的概念。比如，它可能建议让一台小车绕路去取货，但忽略了这台小车必须在10分钟内完成当前任务才能接下一个。后来我们给模型加了一个“约束求解器”，把时间窗口、路径长度、电量这些条件作为硬规则，让模型在规则内做优化。这才跑通。这个经验映射到飞书场景里：当AI看懂生产流程、自动触发工单时，它背后一定有一个“规则引擎”或“工作流引擎”在兜底，AI只是做“软决策”，执行层面还是靠硬逻辑。飞书能做到这一点，是因为它本身就有非常成熟的工作流引擎（多维表格、审批流、自动化规则）。AI只是在这个引擎上加了一层自然语言接口。所以，飞书AI的本质不是“让AI替代工作流”，而是“让AI更好地触发工作流”。这个区别很关键——前者是替代人，后者是辅助人。

最后，关于你提到的“倒逼其他办公软件AI原生化”，我完全同意，但我觉得这个过程会非常痛苦。飞书的优势在于，它从一开始就把AI作为基础设施来构建，而不是作为插件。比如它的“智能伙伴”可以直接在文档、会议、聊天、多维表格里调用，数据天然打通。而其他办公软件，比如某W、某Docs，它们的架构是“应用+数据”，应用之间数据是隔离的。要让AI跨应用理解数据，就必须先做数据中台。这相当于要推翻重来。但反过来，飞书的劣势也很明显：一旦企业不用飞书，这套AI能力就毫无价值。所以，未来的办公软件市场，可能会走向两个极端：要么是像飞书这样封闭但高效的全家桶，要么是像Slack+Notion+Zapier这样开放但需要自己拼装的乐高式方案。前者适合追求极致效率、愿意接受标准化的企业；后者适合追求灵活性、有强大IT团队的企业。没有绝对的好坏。

说到底，飞书这次“赌”的，不仅仅是AI技术本身，而是它对企业管理痛点的洞察：大多数企业，其实并不需要最先进的AI，它们需要的是最“听话”的AI——这个AI能理解它们的权限、遵守它们的流程、沉淀它们的知识。飞书恰好提供了一个“听话”的容器。但它能不能成为企业AI落地的标准答案，还要看它能否在“封闭”和“开放”之间找到平衡。如果它一直坚持全家桶，那么它服务的永远只是那些愿意被它“绑架”的企业。而那些“不听话”的企业，可能才是真正的蓝海——它们需要的是能融入现有IT生态的、模块化的AI能力。这也许是下一个战场。

回到你最后的问题：技术还是组织变革？我的答案是：两者都不是，是“技术+组织+数据的三角匹配”。技术再强，组织不支持，数据不干净，都是白搭。飞书聪明的地方在于，它把“组织”和“数据”都管起来了，只留给技术一个可控的接口。这让AI落地的成功率大幅提升，但也让这种成功变得“不可复制”。所以，如果你问我，我会说：飞书的逻辑是对的，但它只适合一种特定的企业类型——那些愿意为了效率而放弃部分灵活性的企业。而对于大多数企业来说，AI落地的真正挑战，不是选不选飞书，而是先想清楚：你愿意为了AI，改变多少你现有的“组织习惯”？这才是最拷问灵魂的问题。

这分析挺到位的，飞书这波确实把AI落地的痛点抓得准——权限和数据打通才是真门槛，而不是模型本身。不过你说的“有点怀疑”后面是啥？我倒是好奇他们那个成熟度模型具体怎么量化，会不会又变成新的PPT指标？北汽福田那个案例要是能公开更多细节就好了，比如AI触发工单后实际减少了多少人工干预。

这个观察挺到点上的。飞书这波确实不是在玩概念，九成客户选AI这个数据如果属实，说明企业市场对AI的接受度已经过了那个“试试看”的阶段，开始真金白银往里投了。我比较在意的是你提到的“数据孤岛和权限混乱”问题，这其实是大多数企业做AI落地时最大的隐形坑——模型再强，喂进去的是脏数据、乱权限，输出就是灾难。飞书能把AI和组织权限、工作流绑在一起，等于给AI装上了“企业级滤镜”，让它知道什么能看、什么能碰、什么该触发，这个思路比单纯接个API深得多。

不过你帖子最后好像没写完，我猜你怀疑的是规模化复制的问题？北汽福田这种制造业场景确实有代表性，但飞书的AI成熟度模型在不同行业里落地时，行业know-how的差异会不会让这个模型变得太重？比如金融合规和快消零售对权限、流程的颗粒度要求完全不同，飞书能不能在保持底层统一的同时，给各行业留足够的定制空间？另外，我比较好奇他们那个AI应用成熟度模型具体怎么划分阶段的——是像CMMI那样按能力域打分，还是更偏向于业务价值维度？这个如果能有详细的白皮书，对技术选型会很有参考价值。

数据孤岛和权限混乱这个点太真实了，我接触过的公司十有八九都卡在这步——模型再强，喂不进去业务数据就是白搭。飞书那个成熟度模型确实比单纯吹参数实用，但好奇它怎么解决不同部门间历史数据格式不统一的问题？毕竟光让AI看懂生产流程，就得先清洗一堆Excel和旧系统日志吧。

你说到点子上了，特别是“数据孤岛和权限混乱让AI变瞎子”这点，我太有共鸣了。我们公司之前上了一套AI工具，结果连基础的角色权限都没打通，AI生成的报表根本没法直接给不同部门看，还得人工二次处理，反而更累。飞书这次把AI理解权限、串联工作流当成核心卖点，确实比那些只拼对话能力的AI工具务实得多。

那个AI应用成熟度模型我也研究了一下，感觉它其实是在逼企业重新梳理自己的组织逻辑。AI落地卡壳，很多时候不是技术不行，是业务部门连自己有哪些数据、流程怎么跑都说不清。像北汽福田那种案例，AI能看懂生产流程自动触发工单，这背后肯定要先做大量的流程标准化和知识沉淀，这活儿本身就不轻松。

不过我也有一点疑惑——飞书这么搞，会不会对企业的IT能力要求太高了？很多传统制造业连ERP都用得磕磕绊绊，突然要他们用AI管权限、串流程，会不会出现“理想很丰满，现实很骨感”的情况？你接触的案例里，有没有那种IT基础薄弱但靠飞书AI硬推成功的？我想听听实际落地的坑和应对办法。