企业 AI 为什么总卡在试点？

As AI and agents take on execution, our own agency expands. The question is whether organizations are built to capture it.

Microsoft, 2026 Work Trend Index Annual Report: “Agents, human agency, and the opportunity for every organization”

这篇文章中的问题也可以和AI 应用创业：从卖工具到卖结果、Model Is Good Enough：2026 年，AI 真正稀缺的是应用而不是更大的模型放在一起阅读，以比较相近的概念如何在不同语境中展开。

上一篇文章写得更宽一点，关心 AI 怎样进入人的日常工作。这一篇把镜头收窄，只看公司内部。

企业里现在常见一幕：员工已经会用 AI 写邮件、查资料、做分析；开发者也会把边界清楚的任务交给 Coding Agent。可一聊到公司层面，结论常常又绕回来：账号开了不少，demo 也做了不少，能把价值、责任和成本算明白的项目并不多。

这不矛盾。一个人换了工具，不等于公司已经换了做事方式。

模型再强，如果只是旧流程旁边多了一个聊天框，通常也只是局部快一点。企业想拿到稳定结果，得把一段工作重新摆清楚：谁提供输入，谁验收，谁处理例外，出了问题找谁，经验之后留在哪里。费工夫的是把这些听上去不太像模型的东西理顺。

所以这里不急着谈企业 AI 的终局。先把一段工作从临时会话变成可以重复交付的系统。从 AI 辅助既有的人类协作做局部提速，到人也成为 AI Native 系统里的一部分，中间还有很长的组织工作。这一篇只先看这段。企业尚且如此，政府和 ToG 的 AI 系统通常只会走得更慢。

企业内部需要看两类证据

讨论企业 AI，我会先把材料分成两类。

一类看组织里的感受和行为：员工有没有使用，管理者有没有示范，组织允不允许试错，绩效和培训有没有跟上。另一类看已经进生产的项目：业务团队是否持续使用，质量、成本、速度或收入有没有变化，出了问题又靠什么恢复。

微软 2026 Work Trend Index 更接近第一类。它结合 Microsoft 365 的匿名生产力信号，以及对 10 个国家 2 万名 AI 用户的调查，关心的是员工开始会用之后，组织有没有跟上。报告里的 Transformation Paradox 很具体：65% 的 AI 用户担心自己跟不上变化；与此同时，45% 的人觉得，与其花时间用 AI 重做工作，不如先完成眼前目标更安全。只有 13% 的人认为，就算短期结果没达成，自己也会因为尝试用 AI 重做工作而得到认可。

这很像许多团队里的处境。公司嘴上鼓励尝试，日常仍奖励旧的交付节奏、旧的审批方式和旧的短期指标。员工不愿意碰一件短期不确定的事，并不奇怪。

斯坦福 Digital Economy Lab 的《The Enterprise AI Playbook》看的是另一端。研究者访谈了 41 家组织的 51 个项目，覆盖 7 个国家和多个行业。入选项目都满足几个条件：系统已经稳定上线，业务团队持续使用至少三个月，结果能够量化，而且还有扩展或复制的可能。

这份报告不适合拿来估计企业 AI 的成功率。它本来就是对成功样本的复盘，研究者也写明了选择偏差和自我报告的限制。它更适合回答另一个问题：那些已经跑进生产环境的项目，除了模型之外还做了哪些事？

两类材料放在一起，企业 AI 的难处就没那么神秘了。员工会用，不代表组织能吸收；模型能完成一段任务，也不代表这段任务已经成了可复用的业务能力。

一段工作进入生产，需要新的边界

想象一个运营同事让模型把用户反馈整理成周报。他复制几段文本，看一眼结果，再贴进文档。这已经很有用。

可公司若希望它每周稳定地跑，问题会一下子冒出来：反馈来自哪些系统？哪些数据不能出公司？模型能看到什么？分类错了谁改？敏感投诉谁接手？周报最后给谁做决策？人工改过的地方要不要留下？下周能不能少犯同一种错？

前者是一段会话。后者才是一段工作。

我把后者叫作“组织吸收”（absorption）。它指的是把一段原来由人完成的工作重新安排好，让它有稳定的输入、明确的分工、可检查的结果，也有能继续改进的反馈。局部的 AI 输出走到这一步，才可能变成可复用的组织能力。

这件事可以拆成六步：

先选任务。 从高频、成本真实、结果能判断的工作开始，不要先从“模型还能做什么”出发。
补全上下文。 模型需要资料、系统状态和业务约束，不能只靠一段孤立的提示词猜。
划清权限。 AI 是起草、建议、自动执行，还是只在例外时把任务交还给人？
写好验收和例外。 什么算完成，什么算失败，谁能覆盖模型结果，出错后怎样恢复？
看交付后的结果。 除了省时，还要看质量、客户体验、风险、收入和积压有没有变化。
留下经验。 把被验证过的规则、人工修订、异常模式和评估结果写进下一轮工作流，不要让它们散在聊天记录里。

图 1：企业 AI 的交付物不是一次模型回答，而是一段可被执行、检查、接管和学习的工作闭环。

模型能直接覆盖的，只是其中一部分。它能理解文本、生成候选、调用工具，有时还能连续执行。输入、权限、验收、例外、回滚和经验沉淀，不会随着模型升级自己补齐。许多项目停在试点，就卡在 demo 与能长期运行的系统之间这段路上。

这也解释了为什么一些 Agent 在 demo 里很惊艳，进公司后却显得笨重。demo 只要证明能不能做。生产环境还得说明在什么条件下做、做错后怎么办、谁负责，以及怎样证明它一直有用。

系统接口常常长成团队接口

这里还漏了一层。康威在 1968 年的文章里提出过一个朴素观察：设计系统的组织，最后往往会产出与自身沟通结构相似的设计。它不是严格的因果定律，也不能拿组织图硬推出系统图。它只是提醒我们，团队之间怎样沟通、谁有决策权、什么事情必须交接，都会慢慢留在系统的模块和接口里。

AI 系统会把这种关系放大。一个生产级系统同时碰业务目标、知识与数据、模型与评测、工具调用、权限、成本和安全。Google Cloud 的 MLOps 指引把持续集成、交付和训练放在同一条工程链路里，处理的也是这些交接怎样连续发生。组织里每多一个模糊的 handoff，系统里往往就多一层接口、审批或等待。

拿客服智能体举例。它若要读客户资料、订单、退款和风控状态，而这四块原本就靠人工审批串起来，智能体通常只会把串行流程搬到工具调用链里：权限反复校验，上下文在不同系统间丢失，异常又回到人工队列。此时先看的未必是 Prompt，而是这条价值流上到底有谁在反复交接，却没有共同 owner。

用康威定律看企业 AI，常会看到几种典型形状。下表是设计推断，不是斯坦福样本里的统计结论：

团队怎样分工	系统容易长成什么样	常见麻烦
数据、算法、应用、安全各自排队协作	每层各有平台或服务，靠跨团队接口拼接	知识库更新慢，权限模型不一致，故障定位要跨好几组人
一个 AI 中台包办所有场景	巨型统一 Agent 或 RAG 平台，业务团队排期接入	平台变成瓶颈，真正的业务差异只能在平台外绕路解决
业务域小队端到端负责，旁边有共享平台	场景可以自己演进，平台提供统一模型、检索、审计和评测能力	自治与复用之间仍有张力，但边界和 owner 更容易说清

康威定律也不能用得太勤。组织里有客服、订单、风控和知识部门，不代表系统就该顺手拆成客服 Agent、订单 Agent、风控 Agent 和知识 Agent。部门图不是多 Agent 架构图。先按任务、上下文和工具边界划出能力，再判断其中哪些步骤真值得独立出来。多 Agent 更适合任务可并行、上下文容易互相污染，或确实需要不同工具和专长的情况。其余场景里，简单、可组合的工作流通常更容易检查和维护。系统可以反映团队的协作关系，但不必把部门交接一比一翻译成 Agent 交接。

微软关于 AI CoE 的指引有相近的意思：AI 能力通常要建在已有的云、数据和治理团队之上，而不是另立一个只负责“做模型”的孤岛。Microsoft AI CoE 指引对开发者来说，这意味着系统里的 owner、输入输出契约、权限边界、SLO、评测和升级路径，最好能和团队真实的协作关系对上。工具调用链一旦又长又脆，可以先看看团队之间是否也有高频、模糊、没人负责的交接。治理也不该只在上线前出现一次。NIST AI RMF 的 Govern 部分把角色、职责和风险管理放在贯穿全程的位置。

项目花钱的地方，常常不在模型调用

斯坦福报告有两组数字很容易被抽成标题：成功项目里，受访者认为最难的问题有 77% 属于变革管理、数据质量和流程重构这类“看不见的成本”；61% 的成功项目在当前成功之前至少经历过一次失败。模型仍然重要，企业也不必把失败当成必经阶段。这些数字提醒人，最后写在 ROI 里的模型费用，往往没把项目消耗的组织工作算进去。数据问题也不等于把所有历史记录清理干净。团队得先决定哪些数据有用、谁能访问、更新和错误怎样追，项目才不会为了追求“理想数据”一直停在原地。

企业很少从理想数据开始。在很多场景里，LLM 本身也成了处理数据的工具。91% 的案例成功处理了非结构化数据，88% 的案例中，LLM 帮助企业打开了原本存在却用不起来的数据资产。过去数据散落在多个系统里，归属不同团队，没人能真正调起来。现在，企业至少多了一种把这些材料抽取、整理并接进工作流的办法。

报告里的匿名物流案例很能说明这一点。发票处理看上去像典型的 AI 任务：读发票、抽字段、匹配订单、录入系统。可项目最开始面对的是多年积累的重复模板、电话邮件扫描件混在一起的输入，以及必须由业务专家不断校正的例外。团队先压缩混乱模板，再安排领域人员复核模型输出，把流程接进 ERP，高层持续清除协作阻力，项目才走到生产。模型当然在里面，但它只是其中一段。

如果架构图里只有 RAG、Agent、工具调用和模型路由，这些工作很容易被留在图外。可它们决定用户会不会信任系统，业务会不会停掉旧流程，数据团队愿不愿意开放接口，法务能不能允许更高价值的用例进入。项目可能有一个能用的原型，却没有一套被组织接纳的做法。

这和经济学里常说的生产率 J 曲线很像。通用技术进公司后，组织得先投入重写流程、训练人员、整理知识、补数据接口、建立治理和评估。短期内投入比收益显眼，等这些东西慢慢稳定，收益才更容易出现。企业当然不该无限期容忍项目没有结果；如果预算只覆盖模型和开发，把其他投入都当成额外摩擦，商业判断从一开始就会失真。

企业 AI 的成本不只有 token、GPU、SaaS 席位和供应商报价。系统还应尽量避免被单一模型绑死，并在合适的地方做模型路由。更大的成本，是把一段工作重新变清楚、接得进去、查得出来、出了问题有人负责。还要算上允许失败的成本：不仅是一次失败造成的硬性损失，也包括团队是否还有机会根据失败继续调整。

项目也会卡在员工不愿意用之外

项目推进慢时，管理者很容易把原因归到一线：不会用、抵触变化、没有积极性。可如果员工已经私下用通用模型写材料、查资料、做初步分析，问题通常不在使用意愿本身。

微软报告里的矛盾很真实。员工知道 AI 重要，却不相信组织会奖励他们为了 AI 去承受短期不确定性。一个人花三天重做交接流程，短期内可能少交一份旧格式周报；若绩效只看周报数量，最稳妥的选择就是别改。

斯坦福的成功案例里，阻力也常常不来自终端用户。Legal、HR、Risk、Compliance 等职能部门更常被受访者提到。这不等于这些部门保守，更不是让项目绕开法务。它们本来就替组织承担风险。团队在最后一刻拿着一个边界模糊的 Agent 去请求批准，得到否决并不奇怪。

更实际的做法，是从一开始就让这些角色参与工作设计。法务和合规定义哪些数据能进、哪些记录要留、哪些动作必须确认；风控判断哪些错误可以补救，哪些必须提前阻断；HR 和业务负责人要回答，被释放出来的时间会流向什么新工作。一线用户也不能只负责点开新工具，他们知道什么结果真的能减轻痛点。

否则就会出现 Shadow AI。员工为了把事情做完，仍走旧流程，同时在旁边用个人工具补效率。个人可能受益，公司却得不到可治理、可审计、可复用的能力。很多公司里，正式供给、治理和真实需求之间差得太远，员工的私下使用就在这个缝隙里长出来。

高层持续清除部门协同的障碍、提供试错空间，已有的平台与基础设施，以及一线员工急着解决的痛点，都会缩短项目从部署到见效的时间。反过来，员工学习新技术、项目反复迭代、准备和清洗数据、处理合规要求，以及补齐流程文档，都会拖慢推进。项目能跑多快，取决于这些条件怎样叠加。

人机分工需要先看工作本身，再看它带来的变化

把工作重构放回人和 Agent 共同参与的语境里。落到团队日常，管理者还要决定任务怎样分配：AI 参与到哪一步，人什么时候接手，最后又由谁承担结果。

先把一件工作拆开，再谈交给谁。搜集资料、整理信息、生成候选、从大量记录里找异常，往往有相对清楚的输入和验收方式，AI 可以多做一些。项目定位、资源取舍、客户承诺、跨团队协调，通常牵扯更多背景信息和判断，负责人应该留在人手里。

错误会带来什么后果，也会改变分工。错了容易发现、容易修正的环节，可以让 AI 先完成；一旦错误会影响客户、资金、合规或品牌，人工复核要放在交付之前，系统也要留下升级和回滚的路。还有些工作看起来流程稳定，实际高度依赖客户历史、团队关系和业务默契。这类背景很难一次说清，不能假设模型已经理解。

产出是否需要独特判断，同样值得问。规范、完整的底稿适合交给 AI 加快；带着公司策略、审美和品牌取向的内容，AI 可以帮忙发散或起草，最后仍要由人改成自己的表达。这样分工，人的时间才会回到判断、沟通和承担后果这些更难外包的地方。

一句“AI 协助写提案”无法指导实际工作。团队需要把流程拆成步骤，分别写清输入从哪里来，AI 能做哪些动作，谁在什么位置复核，什么情况必须升级，以及谁对最终交付负责。人工对结果作出的修改也要留下来：有些是在改事实，有些是在补业务约束，有些来自经验。它们不该随着一次交付结束而消失。

写清这些内容，常规部分才能稳定地交给 AI；例外出现时，团队也知道该由谁接手。分工的难处，是把交接、复核和责任安排到每一个具体步骤里。

分工上线后，调用量和节省了多少分钟只能说明一部分。还要看交付质量有没有变化：结果是否更准确、更适合实际场景，还是把返工留给了下一位同事。也要看省下来的时间去了哪里。如果团队把时间用在用户洞察、判断和关系工作上，效率才会变成业务上的余量；如果大家只是等着检查 AI 的输出，流程可能只是多了一层等待。

最后看一线的感受。人工复核是否越来越轻，还是每次都得大改？例外是否能顺利交给负责人，还是又回到模糊的群聊和临时协调？这些变化比一张漂亮的调用量图更早暴露问题。模型能力、业务条件和团队经验都会变，人机分工也该跟着调整。

先进入生产的，不一定是最智能的任务

企业做 AI 时，很容易按任务看起来聪不聪明排优先级。能写战略报告的模型，似乎应该比会分拣工单的模型更有价值。落地顺序往往相反。

成功项目更常从不那么浪漫的工作开始：高频、重复、积压严重、输入相对清楚、结果能够检查。安全告警分流、发票处理、客服初筛、采购补货、文档归档、知识检索、遗留代码迁移，都有这类特征。它们未必简单，但什么算完成通常说得清楚，错误也更容易控制在可恢复的范围里。

斯坦福的成功样本里，全自主的智能体方案只是一部分。更多项目从常规部分开始，让 AI 处理高量、可恢复的工作，把关键输出和例外留在人工审核范围内。这个观察更适合用来理解落地顺序：输入稳定、结果可检查、错误能补救的任务，更容易先跑进生产；临床文书、对外内容、高风险决策和复杂编码，仍需要更长的协作与审核链路。

自动化程度不该决定优先级。团队可以先把 AI 放进一个边界清楚、验证容易的环节，确认输入、验收、异常处理和回滚都能稳定运转，再考虑是否扩大授权。对 AI 应用开发者来说，很有价值的一项能力，是把业务人员说不清的工作整理成模型能参与、系统能执行、人工能验收的步骤。

软件开发和游戏研发没有跳出这条规律

放到软件开发里，这件事很具体。

Coding Agent 已经能读仓库、改文件、跑命令、做迁移、补测试。可一段代码被生成，不等于一个需求被交付。工程里还有需求边界、依赖系统、测试、CI、代码审查、发布窗口、监控、回滚和线上责任。开发者把写实现交出去以后，更多精力会落到定义验收、识别风险、安排反馈和承担最终变更上。与其一开始追求端到端自动交付，不如先把 Agent 放进测试、审查和回滚都较清楚的步骤。

AI Coding 特别适合模式清楚、验证链完整的改动：批量迁移、接口替换、配置更新、测试补全、已知 bug 的局部修复。它们都有相对明确的 diff、测试和回滚路径。需求还没稳定、架构取舍复杂、跨团队责任模糊的工作，模型再进步也绕不开组织上下文。

DORA 2025 从软件交付角度给了类似提醒：AI 的效果会受团队已有的反馈能力、平台能力和工作方式影响。这项研究只谈软件组织，不能推到所有企业；对做开发工具和工程 Agent 的人来说，它仍然很有用。局部加速不会自动变成整个系统更快，原有流程的缺口也可能被更快地放大。

游戏和内容生产也是这样。假设团队让 AI 生成活动配置或任务文本，生产链路不止是文案好不好看。配置要过 Schema 校验，ID 要存在，奖励要满足规则，任务前置条件不能冲突，敏感内容要能审阅，版本改动要能回滚，最后还要由策划判断节奏、玩家体验和品牌调性。模型能很快给出候选，但候选能不能进项目，要看团队有没有把验证和责任安排好。

模型越能生成和行动，验证、权限、日志、回滚与评估越不能等到上线之后再补。它们本来就是生产力的一部分。

Headcount Reduction 与结语

企业项目真有了生产率收益，管理层还要决定怎么使用这部分能力。斯坦福的成功样本里，减员是最大的单一结果，却不是多数。还有项目选择避免新增招聘、把人转到更高价值的工作，或用同样的人力加快产品路线。

这首先是一道经营选择。公司可以把省下的时间换成更快交付、更高服务水平、更细的客户覆盖，或者更低的人员成本。系统不会替管理层做决定。增长机会、预算压力、产品积压和可转岗的工作，都会影响这条路怎么走。

速度带来的也不只是成本优势。可以把它比作 MOBA 游戏里的移动速度：它不替玩家做决策，却会改变追击、撤退和支援的时机。企业里的效率也是这样。它打开了原来来不及做、做不起或排不上优先级的选择，至于把这部分余量用在什么地方，仍然要由管理层决定。

节省的时间有没有变成业务结果？人被转去做什么？客户得到的服务有没有变好？如果这些问题没有答案，所谓提效很可能只是在局部看上去漂亮。减员只是企业可能选择的一种结果，不是效率收益唯一的去向。企业若把减员放成唯一目标，员工大概率也会拒绝接受 AI，没人想让自己失去工作。

企业 AI 卡在试点，常见原因是公司还没有把模型能做的事接进一段可以验收、有人负责、出了问题能接住、之后还能继续学的工作。

产品从回答问题走到替人做事，跨过的是能力边界。组织要把这种能力接成稳定价值，仍要靠开发、业务、平台和治理团队一起把工作做完。

参考资料

Microsoft Work Trend Index，2026-05-05。
The Enterprise AI Playbook，Elisa Pereira、Alvin Wang Graylin、Erik Brynjolfsson，Stanford Digital Economy Lab，2026-04。
State of AI-assisted Software Development 2025，DORA。
How Do Committees Invent?，Melvin E. Conway，1968。
Google Cloud MLOps 指引。
Anthropic: Building Effective Agents。
NIST AI RMF: Govern。
Microsoft: Establish an AI center of excellence。