为什么企业AI转型的效率提升会遇到瓶颈
编译整理： Matt Paige 采访 GitLab 首任 CIO Manu Narayan 的播客笔记，一份写给企业 AI 落地负责人的读书笔记。
先从一份调查里的矛盾说起
最近 GitLab 发布了一份《AI 问责报告》，覆盖了 1500 名 DevSecOps 从业者。里面有两个数字放在一起看，会让人愣一下：
- 60% 的人说：AI 编码带来的投资回报，超出了他们原本的预期。
- 73% 的人——也就是基本上同一批人——同时表示：他们担心这些 AI 生成的代码，长期维护会有问题。
这两个数字并不矛盾，它其实精准地描述了今天大多数企业 AI 项目的处境：一边跑得比过去都快，一边心里隐隐有点慌，不知道自己在悄悄背上什么样的技术债和管理债。
大部分公司的反应，是继续朝一个方向加码：更快、更多、更多行代码。而这次采访里，Manu Narayan 给出的判断是——这个方向本身就有问题。
Manu Narayan 是谁
GitLab 是一家「软件被生产出来的地方」——NVIDIA、洛克希德·马丁、巴克莱这些公司都在它上面构建自己的产品。这家公司决定，内部的 AI 转型不能挂在 CTO 或者某个业务线下面，得单独设一个高管席位来管。Manu 就是他们请来的第一任 CIO。
他的职责范围很清晰：GitLab 自己怎么用 GitLab，以及从销售到客服的每一位员工，怎么真正从 AI 里拿到杠杆效应，而不是只是「用上了一个新工具」。
如果只靠效率提升，你迟早会撞上一堵靠工程手段翻不过去的「生产力天花板」。一个跑得更快的「AI 前工作流」，本质上还是「AI 前工作流」。真正想突破，只能从第一性原理重新设计整个流程。
下面按八个话题，把这次对话里我认为对企业 AI 负责人最有用的部分展开讲一讲。每一段我都尽量说人话，也保留原播客里的时间戳，方便有兴趣的同事回去听原声。
一、别把「省下 15% 的时间」当成目标
现在很多 AI 项目的 KPI 是这么写的：某个环节效率提升 10%、15%、20%。这当然是好事，但 Manu 明确说，他们不把这个当目标，只把它当基线。
「我们对那些名义上的、增量式的效率提升，其实不太感兴趣。它们当然重要，我们要抓住，让每位员工都用上工具。但我们真正想找的，是那些超额的、非线性的收益。」 —— Manu Narayan（约 18:30）
什么叫「非线性」？ 举两个他们内部的例子：
- 研发侧，通过 Agentic Development，把研发生产力做到 5–10 倍的提升，而不是 15%。
- 客服侧，把「解决一张工单」的时长压缩到原来的几分之一。
衡量指标也跟着变了：不再看「做了多少事」，而是看创新速度和端到端交付周期。
这里有一个前置条件很关键，容易被忽视：他能这么做，是因为高管层一开始就对齐了目标——不是「加个 AI 功能」，而是「整体性地重构工作方式」。
「我们要的不是增量收益，我们要的是整体性的重构。」 —— Manu Narayan（约 43:00）
这份对齐落到组织上，最典型的一步就是：CIO 和 CPO（首席人力官）绑定推进——因为角色演化、AI 素养培训、员工赋能，本质上是人力工作，不是 IT 工作。
这一点和几个月前 PwC 首席 AI 官说的一句话完全对上：
AI 落地的价值 = 80% 业务转型 + 20% 技术。
大多数公司把这个比例搞反了，把 AI 当成 IT 项目做——那基本等于给自己主动设置了一个天花板。
给企业 AI 负责人一个提醒：如果你所在公司的 AI 项目还挂在 IT 部门下面单独考核，那不管做得多好，都很难跳出「效率工具」的定位。
二、AI 推不动，多半不是技术问题，是「人的问题」
Manu 在这里讲了一个我觉得非常本分、非常有人味的观察：
「你会看到一批 AI 有产者 和一批 AI 无产者。前者拥抱了技术、理解它、把它融入工作流；后者没有——但这不是他们的错，本质上是赋能没到位。」 —— Manu Narayan（约 3:55）
他没有用「转型阻力」这种听起来有点居高临下的词，而是承认：公司没教清楚，就不能怪员工没跟上。
他们的组织方案叫 Hub–Spoke–Hub，翻译过来大概是「中心 – 分支 – 中心」的循环结构。分三层：
- 中心（Hub）：一个集中的 AI 团队，负责整体治理、技术选型、平台级建设。
- 分支（Spoke）：每个业务部门都派出一位 AI 转型负责人。这个角色的关键，不是懂 AI，而是懂本部门的工作流、流程和人，能同时和业务、技术两边对话。
- 回到中心：这些负责人在本部门里组建卓越中心（CoE），自下而上收集好的想法，把有规模化潜力的挑出来送回中心，由中心团队统一投资、落地、推广。
「我一直相信那句话——一切政治都是本地的。要驱动有意义的转型，最好的方式，就是贴近那些真正需要被转型的角色和场景。」 —— Manu Narayan（约 5:00）
给企业负责人的启示很简单：AI 无产者需要的不是一份自上而下的红头文件，而是一个坐在他旁边、听得懂他工作的翻译官。 如果你现在的 AI 团队和一线员工中间隔着两三层管理岗，那再好的工具，也只能停在少数人手里。
三、岗位边界正在模糊，新的角色叫「Agent 的经理」
这一段可能是最值得每个从业者认真读的一部分，因为它直接关系到「未来几年我们的岗位会变成什么样」。
Manu 描述了两个层次的变化。
第一层：员工正在变得更「全栈」。
「让人以更全栈的方式工作——端到端地拥有一个完整流程。过去这个流程要 4–5 个人各干一段，现在要大幅扩展一个人的职责范围。这会缩短周期、增强端到端的问责，也去掉了那些拖慢一切的内部交接。」 —— Manu Narayan（约 7:30）
他举了 GitLab 内部 Salesforce 开发的例子：过去要经过 BSA、产品负责人、管理员、开发、QA 等 6–7 个角色接力，现在借助 AI，一个人就能贯穿其中的大多数环节。这不代表其他人失业，而是意味着「专业分工」的粒度在变粗，一个人管的事情范围在变宽。
第二层：管理者的对象，从「任务」变成了「Agent 团队」。
「你会开始关注一支 Agent 团队是怎么协作运转的，你在帮它们做编排。这有点像「Agent 的经理」——而不再是任务的执行者。」 —— Manu Narayan（约 30:45）
很多人担心「AI 会不会取代 human-in-the-loop（人在环中）」。Manu 的回答是：人并没有消失，只是位置上移了。
对比一下：
- 一年前：人类要审查 AI 生成的每一行代码。
- 现在：Agent 在闭环中工作，其他 Agent 监督它们，人类要做的，是决定「关键的判断点应该嵌在哪几个环节」。
举个例子：你可能可以接受 AI 直接生成一份代码评审摘要，但安全扫描环节必须由人签字画押。
「决定检查点放在哪里」——这本身就是一项正在被单拎出来的核心组织能力。 对于产品经理和解决方案负责人来说，这一条尤其值得留意：设计 Agent 工作流的时候，「哪一步该保留人的判断」是一个专业问题，不是随口决定的。
四、Skill 是 AI 在企业里真正规模化的方式
关于 Skill 和 Agent 的区别，Manu 给了我目前听过最干净的一句话：
「Skill 通常是在增强人在做的事；Agent 则是——尽管过程中可能有人在环，但本质上是自主运行的。」 —— Manu Narayan（约 10:30）
「人类调用 vs 自主运行」——这一刀切下去，Skill 和 Agent 各自安放在哪里，就清楚了。
但比定义更重要的是，Manu 讲清楚了为什么 Skill 是企业规模化的关键。
原因很朴素：企业里的「AI 有产者」，其实早就在自己搭一堆好用的 Prompt 和小工作流了。问题是这些东西只活在他们自己的电脑里，没法传给同事。Skill 做的事，就是把这种个人经验固化下来，让它变得可复制、可传递。
「Skill 帮我们把这些能力编码固化下来，这本身很重要。但更关键的是，它让我们能非常轻松地把这项能力扩展给其他角色相似的人。这是一种「不用从头教全部基础」就能赋能的方式。」 —— Manu Narayan（约 11:15）
值得抄作业的具体做法：GitLab 的 Skill 库
他们内部搭了一套 Skill 的「开源仓库 + 官方认证」机制，运行方式大致是这样：
- 任何员工都可以往仓库里提交一个 Skill。
- 有一套评审流程，把好的 Skill 提升为「官方 Skill」。
- 官方 Skill 按「角色画像」分发给对应岗位的人。
- 员工会在别人的 Skill 上二次开发、不断迭代，最优秀的自然浮出来。
这套机制的好处，是同时兼顾了两个方向：
- 自下而上的创造力：好点子来自一线，而不是中央 IT 拍脑袋。
- 自上而下的质量控制：不至于变成一个杂乱无章、没人敢用的百宝箱。
Manu 举了一个非常具体的例子：他们做了一个「客户调研 Skill」，会自动串起内部系统、外部信息源、支持工单，为每一位面向客户的员工生成一份统一的会前简报。任何 CSM、销售、客户成功岗，都可以直接调用。
对企业 AI 平台负责人来说，这里有一条很实用的产品思路：先别急着做 Agent，先把「Skill 的生产–评审–分发–复用」这条链路做扎实。这一层做好了，上面长出来的 Agent 才有稳定的能力底座。
五、「Token 越用越多」不是好指标
最近有个说法很流行，叫 Token Maxing——把「谁烧掉的 Token 最多」当成衡量 AI 用得好不好的指标。Manu 明确不认可这个方向：
「它太容易被游戏化，而背后是有直接成本的。用它作为衡量生产力的手段，本质上是失灵的。」 —— Manu Narayan（约 16:10）
半年前 GitLab 也做过类似的事——统计几个企业 AI 平台的周活用户数。但他们现在已经调整了：Token 数据还盯，只是把它降级为成本管理指标，不再当业绩指标用。
真正衡量效果的，是按角色/画像划分的业务 KPI：
「我们不再只看代码行数这些东西。我们看创新速度、发布节奏、以及交付给终端客户的整个体验，是怎么被改变的。」 —— Manu Narayan（约 16:45）
举例，在客服场景，指标就是那些老掉牙但真实有效的：
- 首次响应时长
- 解决时长
- 一张工单来回沟通的次数
这些指标一点都不酷，但它们直接和客户体验挂钩。用 Manu 自己的话说：「听起来有点土，但其实就这么简单。」
一句话总结：使用量告诉你「人到齐了」，业务 KPI 告诉你「工作真的被改变了」。
他还顺带做了个预测：按模型来切分预算上限，会逐渐成为企业标配——「几乎是不可避免的」。这也说得通，接下来一两年，「AI 的 CFO 时代」会到来，谁的钱花在哪个模型、产出了什么，需要能算得清账。
六、开发端开放，仓库端治理
每个 IT 负责人都要处理同一个矛盾：
- 管得太死，大家会绕开你，用自己的账号偷偷用外部工具，反而更没法治理；
- 放得太开，公司又变成一家上市公司里跑着一堆未治理的 AI 生成代码。
Manu 给的解法是一个架构层面的选择：
「今天很多事发生在客户端——不管你用的是 Codex、Claude 还是开源模型。但你想想「仓库端」发生了什么——那才是你能真正加上保障、治理和护栏的地方，让你对最终交付的东西感到踏实。」 —— Manu Narayan（约 24:30）
翻译成更直白的话：
- 开发人员想怎么用就怎么用——本地用任何工具、任何模型，公司不逐个审批。
- 治理放在代码合并的地方——AI 生成代码的评审、安全漏洞的自动修复、流水线失败的自动处理，都由仓库端的规则来管。
为什么这个思路成立？因为瓶颈已经从「写代码」迁移到了「评审和验证代码」。
根据前面那份 GitLab 报告：85% 的 DevSecOps 从业者说，AI 已经把瓶颈从「写代码」转移到了「评审和验证代码」。 代码之后的整个生命周期，才是现在的主战场——而这一段，恰恰是你在员工个人电脑上治理不了的。
同样的思路也适用于所谓的「影子 AI」（员工绕过公司用外部 AI 工具的现象）：
- 任何人都可以在自己的沙盒里造 Agent；
- 但一旦要接触真实的企业上下文（客户数据、代码库、内部知识），就必须走评审和优化流程才能上线。
Manu 说过一句我觉得该刻下来的话：
「「官方审批、POC 立项、部署一个 vibe-coded 应用」——这些通道的痛苦程度，不能超过用户自己单干。」 —— Manu Narayan（约 41:00）
这基本就是「影子 IT」问题过去 20 年的解决之道，一句话概括：让阳光大道，也成为最省事的那条路。
七、模型能力在贬值，「上下文」在升值
这可能是整场对话里最锋利的一段判断：
「不同前沿 LLM 的能力提升得异常之快，但访问上下文的能力并没有相应提升。」 —— Manu Narayan（约 32:15）
换句话说：模型变强的速度，比你「喂给它」公司信息的速度更快。
于是瓶颈再次迁移——从「模型质量」跳到了「上下文质量」。谁能把公司里那些散落在人脑、聊天记录、工单里的隐性经验，结构化地喂给 AI，谁就赢。
他用客服工程师举了个例子：
所有人都说客服是「AI 已经解决」的场景。但一位资深客服工程师身上，藏着多年未被文档化的经验——客户的部署类型、操作系统版本、以往故障史。这些东西 AI 拿不到，就永远做不到「资深」的水平。
结论很直接：
- 上下文丰富的地方，AI 顺利接手工作。
- 上下文只活在人脑里的地方，人依然赢。
- AI 在你公司能做的边界，本质上是由「你让它能读懂多少东西」决定的。
GitLab 内部的一个动作叫 Orbit（知识图谱）：把代码库、流水线失败、安全扫描、评审评论缝在一起——这样 Agent 只需要消耗更少的 Token，就能产出更准确、更快的结果。
对于国内正在做企业 AI 的团队，这一条给出的启示很清楚：别再盯着换模型了，把功夫花在「上下文管道」上——数据接入、权限打通、知识沉淀、图谱化。 这才是真正的护城河。
八、SaaS 不会「一夜完蛋」，卡住它的是「最后 20%」
最近有一种流行说法叫「SaaS 末日」——认为 Agent 会取代大部分 SaaS。Manu 作为一家 SaaS 公司的 CIO，同时又在内部大量做 vibe-coding，他的回答很值得听：
「你要做出一个 80、90% 完成度的 POC 非常容易，甚至能加一些花哨功能让人喜欢。但剩下那 20%——一旦你要加入基于角色的访问控制、版本管理、可变 vs 不可变记录……这些真正的深度问题，会变成一条极长的尾巴。」 —— Manu Narayan（约 38:10)
记录系统、治理、合规、SOX 控制——这些一样都不能被「随手 vibe-code」掉。 会被替换的，主要是交互界面这一层。
Manu 认为，反而更值得担心的是「Agent 泛滥（agent sprawl）」——每个 Agent 都想从每个系统里拿上下文，很快就会演化成数据主权噩梦。所以 GitLab 主动把选择收敛到少数几个 Agent 平台上，通过 MCP 连接器统一把上下文喂进去。
他还给了一个我觉得几年后会被反复提到的预测：
「我不认为 MCP 就是终极协议。我觉得我们会看到 Agent-to-Agent 通信协议开始出现。」 —— Manu Narayan（约 39:30）
换成场景语言就是：未来是你的 Agent 直接和 SaaS 厂商的 Agent 对话。 这个方向听起来遥远，但从技术演进上看，是很自然的下一步。
四条值得单独收藏的回答
当下最重要的超能力是什么？
「求知欲。你今天获取信息、成为某个领域「伪专家」的能力，是历史上前所未有的。只要你有好奇心，加上一点点智力马力，你几乎可以做任何事。」（约 42:30）
供应商最爱吹嘘、也最被高估的东西？
「很多 AI 供应商本质上只是在卖模型的一层包装……那有点微小的价值。我们真正需要的，是能把活干成的 Agentic 能力。」（约 43:40）
今年花得最值的一笔 AI 钱？
Glean——作为企业内部搜索 + Agent + 知识平台。Manu 称之为「企业知识 LLM」。（约 44:15）
给「AI 之前的自己」一句话建议？
「AI 时代就像活在狗年里。」GitLab 在他上任的 10 个月内，已经把 AI 项目迭代了 3 版。「传统的 RFP 和 POC 那一套已经不 work 了。你现在做的选择，明年可能就不再是对的选择。速度，可能是更重要的指标。」（约 44:50）
最后：把这套 playbook 缩小到个人和小团队
如果你不是在管一家两千人的公司，只是一位独立开发者、或者带着一个小团队的产品经理/解决方案负责人，这一整套经验其实也能优雅地缩小。总结起来大致是三条：
- 抓住增量收益，但真正下功夫去猎取非线性收益。 15% 的效率提升值得要，但不能当成终点。
- 实验放在沙盒里，接触真实系统前，设一道诚实的闸门。 别让「快」变成「乱」。
- 在投入工具层之前，先投入你的上下文层。 你能给 AI 的上下文有多好，AI 帮你做的事就有多好。
但整篇文章真正的主线，还是那个「天花板」的比喻。这里我不加发挥，只把 Manu 的意思用大白话再说一遍：
现在每家公司都在拿到效率提升——它们真实存在，也普遍存在，很快就会成为「入场券」，而不是「差异化优势」。
真正的分水岭，出现在有人开始不再问「我们怎么把这件事做得更快」，
而是开始问：「这个工作流当初为什么会存在？」
一个更快版本的「AI 前工作流」，本质上仍然是「AI 前工作流」。
对做企业 AI 的人来说，这句话值得贴在工位上。