ARTICLE · 1219219
AI越用越多,为什么公司还没赚到钱?
企业 AI · 落地方法与避坑
AI越用越多，为什么公司还没赚到钱？
在企业里推动AI，我经常遇到这样的局面：管理层担心错过机会，团队也很积极，很快就能拿出一批成果。有人用AI写周报，有人搭了客户调研助手，还有人把几个办公系统连接起来，做出了自动化演示。
但到了业务复盘，问题就具体了：销售有没有更及时地跟进客户？原来反复核对的数据，现在能不能直接用？员工省下来的时间，究竟让哪项业务做得更好了？
麦肯锡2026年的调查中，80%的受访者认为AI提高了个人工作效率，37%表示AI对所在企业的利润有正向贡献。[1] 这组数据不能说明其余企业的AI投入都没有价值，但足以提醒我们：个人工作更快，和企业经营改善，是两件需要分别验证的事。
从数字化转型到AI转型，我越来越在意项目上线之后的变化。企业能否获得持续收益，很大程度上取决于它是否愿意围绕AI重新安排工作，并持续修正这套安排。工具怎么用，需要学习；信息交给谁、哪些步骤可以取消、谁负责判断和维护，同样需要有人推动。
01
企业的难题 正在从开始使用转向持续见效
先看企业已经把AI用到了哪里。
图1 员工开始使用AI，与企业将AI用于核心业务，是两个不同的统计指标。[2]
OECD在2024年底调查了七个国家的5,000多家中小企业。约31%的受访企业中，有员工为工作使用生成式AI；在已经使用的企业里，29%将它用于核心业务活动。[2] 两个比例的统计对象不同，但能帮助我们分清：员工开始使用工具，距离企业改变主要业务，还有一段路。
这个起点并不奇怪。写邮件、整理材料、准备汇报，一个人就能尝试，出错后也容易修改。企业不需要一开始就发动流程改造，员工也能从中积累对AI的基本判断。
随着Agent（智能体）进入应用，企业希望它承担更多工作。麦肯锡2025年的调查中，62%的受访者表示所在组织已开始尝试使用Agent。[3] 到2026年，麦肯锡观察到，企业级AI应用进一步扩大，但报告AI对企业利润有正向贡献的受访者比例，仍与上年大致相同。[1]
不同年度的报告不能当作对同一批企业的连续追踪。不过，应用范围扩大、收益仍待验证，已经是企业需要同时面对的现实。我的判断是，接下来拉开差距的，会是企业能否把零散用法接入真正影响业务结果的流程。
这也意味着，推进目标需要调整。初期可以看员工是否愿意用、能否判断结果；当企业开始为跨团队应用投入资源，就应明确要改善哪项业务，以及由谁对改善结果负责。继续只考核使用率，会让团队倾向于增加场景数量，却未必解决最重要的问题。
02
先把业务问题说清楚 再决定接入多少工具
企业一旦希望AI进入业务流程，就会遇到一个诱惑：既然它能调用工具，不如把知识库、日历、CRM都接上，再寻找应用场景。
我接触过一些这样的尝试。原本在表格里三五秒就能完成的操作，被设计成一条复杂工作流；流程看起来完整，配置、核对和维护却都要额外花时间。还有一些企业，前期积极探索AI提效工作流，后来可能因为需求没有想清楚，或团队对改造方向没有达成一致，中止了复杂场景的尝试，重新以知识问答、资料检索等基础应用为主。
退回基础应用未必是坏事。需要复盘的是，企业是否把业务设计和协作不到位造成的失败，归结为“AI不成熟”。如果需求、分工和交付标准都不清楚，即使工具能准确执行每一步，也可能交付不出业务真正需要的结果。
因此，选场景时，我会先请团队描述原来的工作究竟卡在哪里。以客户跟进为例，是查找背景资料太耗时，还是拜访之后没有及时记录约定？是销售不知道下一步做什么，还是知道要做、却总被其他事情打断？这些问题需要的方案不同，不能统一用“做一个销售Agent”概括。
图2 先明确正常交接与异常处理，再确定AI需要调用哪些工具。
只有目标明确以后，才有依据决定AI需要读哪些资料、调用哪些系统、执行哪些动作。如果问题是跟进遗漏，验收重点就应该是销售能否按约定跟进，而不是自动生成了多少条建议。
权限也应随任务逐步开放。可以先让AI读取资料、提出建议，待团队验证结果和异常处理方式后，再允许它执行特定操作。涉及修改客户记录、对外发送消息时，要明确人工确认和出错后的处理方式。这样推进，团队才有机会在可管理的范围内学习，而不必同时承担复杂流程和大量权限带来的不确定性。
03
判断是否提效 要把检查和返工一起算进去
目标说清楚了，也不代表试点一定有效。项目中还有一种常见误差：大家觉得用起来顺手，就默认已经节省了时间。
METR在2025年对16位熟悉自身开源项目的开发者开展随机对照实验，涉及246个任务。参与者事后估计，使用AI让任务耗时减少了20%；实际测量结果却显示，完成时间增加了19%。[4]
图3 使用者的主观感受需要实际测量来核验。两组耗时均以未使用AI的任务耗时为100。[4][5]
这项实验不能用来概括今天所有AI编程工作的效果。METR在2026年的后续更新中，也指出新实验受到选择偏差等因素影响，难以可靠确定当时的提效幅度，并判断更新后的工具可能带来了更多效率提升。[5] 对企业更有用的启发是：使用者的感受，需要用实际任务的记录来核验。
正向结果也要放回任务中理解。一项发表于2025年《经济学季刊》的研究考察了5,172名客服人员，发现部署AI助手后，每小时成功解决的问题数平均增加15%。AI提供实时建议，客服可以修改或忽略，并继续负责客户沟通。[6] 这个场景中，企业能围绕“问题是否得到解决”检验效果，而不是只统计AI生成了多少内容。
因此，我不建议给所有AI项目套一个“节省多少工时”的统一目标。调研助手需要核对事实，自动纪要需要检查遗漏，跨系统流程还要处理异常。这些工作都应计入成本。试点应比较相近任务的完整交付过程，同时检查质量是否下降，以及是否给其他岗位增加了工作。
有些收益也不会立刻表现为利润。新人能否更快达到合格水平，销售是否更少漏掉客户约定，都值得测量。先说明这些变化预计如何影响业务，再持续追踪，企业才有依据决定继续投入、修改方案，还是停止试点。
04
要改善业务结果 就得重新安排整条工作流
核算完整成本之后，企业往往会发现，只让某一个步骤更快，改善空间有限。调研报告提前生成了，如果销售仍要重新查找资料、手工填写系统，后续跟进方式也没有改变，前面节省的时间就可能在后面被消耗掉。
微软云供应链团队的改造，可以把这件事讲得更具体。这支团队要处理相互关联的需求规划、采购、订单交付和物流。需求计划发生变化后，团队需要查明原因，评估供给能力和运输方案。
他们先让供应链专家与工程师一起梳理、简化整条流程，并统一数据来源，让不同Agent依据同一套信息工作。随后，再让Agent参与调查需求变化、分析供给能力，以及比较不同运输方式的成本和时效。涉及更新或取消采购订单时，Agent也只能在规定权限和审批条件内协助执行。
微软披露，改造后，形成一份经人工核验的需求变更解释，平均耗时从五到七天缩短到几小时以内。这是微软对特定工作流的内部测量结果，不能直接当作所有企业都能达到的提效比例。[7]
我认为，这个案例值得借鉴的地方，是团队把查原因、评估方案和后续行动接在了一起。解释更早出来，规划人员就有机会在计划仍在调整时比较方案、识别风险。要获得这样的改善，企业需要同时处理流程、数据和执行权限，单独加快某一步的信息生成还不够。
把视线从微软转向制造业，也能看到围绕完整业务流程展开的改造。世界经济论坛2026年披露，施耐德电气埃尔帕索工厂结合数据工程、工业物联网和AI等方案，改造订单设计、生产、测试和物流环节，准时交付率从61%提高到97%。[8]
图4 改善围绕准时交付这一业务目标展开，结果来自多项技术与流程的共同改造。[8]
这是经过遴选的先进工厂案例，结果来自多项技术与流程的共同改造，不能单独归因于大模型。对普通制造企业更值得借鉴的是，它把改善目标落在了准时交付这项业务结果上。为此，企业必须处理订单、生产与物流之间的信息和协作，不能只优化一份报告的生成速度。
回到客户拜访，这种改造也可以从一条很具体的流程开始。拜访前，AI按照企业的分析框架整理客户背景，销售据此判断要重点了解哪些问题；现场用录音转写辅助记录，销售专注于沟通；结束后，AI从纪要中整理约定、形成待办，再在约定时间提醒跟进。销售核实关键信息，并决定下一步行动。
这条流程的价值，在于前面收集的信息能被后续工作直接使用，原来反复查找、搬运资料的步骤有机会被取消。人的工作也会变化：调研材料不必每次从头整理，销售可以把更多精力用在需求洞察、机会判断和客户沟通上。
所以，企业讨论工作流改造时，既要明确AI新增了什么能力，也要决定原有工作中哪些可以取消、合并或重新分配。如果旧流程一项不少，员工还要额外操作AI、检查输出，工具就很容易成为新的负担。
05
企业内部要有人 把新方法变成日常做法
工作流一旦涉及重新分工，顾问和技术团队就无法独自完成改造。熟悉业务的人需要参与判断，管理者也需要处理职责变化。企业引入FDE这类深入业务现场、参与系统交付的工程师时，同样需要考虑内部由谁配合。以OpenAI的公开岗位说明为例，FDE的职责包含需求发现、系统设计、开发和部署，强调与客户团队共同完成交付。[9]
外部团队可以带来方法和工程能力，企业内部仍需要有人判断：结果是否可用，哪些例外必须由人处理，流程改变后是否增加了同事的负担。否则，一套方案即使交付了，日常使用中遇到的问题也很难及时解决。
图5 外部团队参与交付，企业内部仍需有人负责业务判断与日常改进。
我参与过一家传统制造企业的项目。销售团队经验丰富，不少成员在四十岁上下，过去有人觉得CRM填报是销售之外的额外负担。第一次AI培训后，有一两位同事对减少重复提醒、整理汇报材料很感兴趣，参加了我们组织的销售AI共创坊，尝试用自然语言搭建适合自身业务的小工具。
其中一位同事回公司后，就用工具向名单中的人员逐一发送工作汇报提醒。顾问继续了解他的日常用法，再向销售管理者介绍这些具体变化。之后，企业利用季度总结的机会，组织团队分组共创，围绕六七个现有流程完善方法。
这次项目能确认的是，员工开始上手，团队形成了初步使用共识，长期收益仍需跟踪。但它让我更明确了一点：员工愿不愿意改变，与工具能否解决他眼前的麻烦密切相关。管理层推动AI时，需要让员工参与选择问题、判断效果，给他们用真实任务反复尝试的机会。
因此，我会建议企业先找到一两位懂业务、愿意探索的骨干，让他们与外部团队共同推进试点，再把经过验证的用法带给同事。管理者要为这项工作留出时间，明确业务负责人，并说明调整后的职责和判断权限。不能让少数积极员工长期靠额外加班维护，也不能让他们承担没有被明确授权的责任。
06
先沉淀可复用的方法 再扩大自动化范围
有了内部参与者，企业还需要决定，哪些经验值得沉淀，哪些任务继续保持灵活。
与客户梳理需求时，我通常会让团队列出经常重复的工作，也列出过去半年或一年里特别难处理的大任务。然后一起看：资料来源是否相对固定，处理方法能否复用，交付要求是否清楚，结果是否容易检查。
临时出现的新话题、新创意，往往需要在与AI共创的过程中逐步明确要求。每周汇总固定数据源的周报，或者每次拜访前按统一框架完成的客户调研，则更有条件沉淀成可复用技能，把资料来源、分析框架和输出要求写清楚，供团队反复使用。判断依据不能只有频次；即使每月都做一次，如果每次的目标和方法差异很大，也未必适合直接自动化。
图6 是否适合自动化，要结合方法稳定程度和结果能否核验来判断。
我更建议企业把起步阶段分成两个连续的过程：先让员工在真实任务中熟悉AI，积累合格与不合格的结果；再从中选出方法相对稳定、价值能够验证的部分，改造成团队共同使用的工作流。团队不必在第一次上线时，就把未来所有需求都设计完整，但必须知道由谁维护，以及什么情况下需要调整。
这也决定了AI项目的管理方式。保留阶段性的验收是必要的，验收之后还要定期复盘失败案例，更新资料和规则；每次调整工具或执行权限后，重新检查结果是否可靠。模型、工具和业务都会变化，原来有效的方法也需要重新检查。将这些维护工作纳入日常业务安排，才能避免项目在顾问离开、骨干调岗或资料过期后逐渐失效。
如果现在要启动，我会建议先选一条存在明确业务问题、结果能够检验的流程，记录改造前的耗时与质量，明确哪些工作交给AI、哪些判断由人负责，再用真实任务检验一段时间。有效的部分继续完善，没有改善的部分及时调整；确认能稳定运行后，再扩大使用范围。
我希望企业最终留下的，是一套自己能够判断、修改和维护的工作方法。下一次工具升级，或者业务发生变化时，团队知道该从哪里重新检查，也有能力继续改进。这种能力需要在一个个具体项目中建立，单靠采购和培训，很难一次性交付。
附录
数据口径与原始资料
资料复核截至2026年10月19日。以下仅保留正文引用的资料，列出样本、时间与解读限制。不同调查的比例不能直接相减，也不能拼接成连续趋势。
1 麦肯锡 企业采用与收益
The state of AI in 2026 On the road to ROI，2026年8月25日。调查于2026年5月4日至6月8日进行，涉及97个国家的1,719名受访者，按所在国对全球GDP的贡献加权。
使用边界：企业收益和个人效率均为自报结果。正文所述利润采用报告中的EBIT（息税前利润）口径。对年度变化的表述沿用报告自身的比较，不意味着同一批企业接受了连续追踪。
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
2 OECD 中小企业与行业差异
Generative AI and the SME Workforce New Survey Evidence，2025年11月5日。数据来自2024年底对奥地利、加拿大、德国、爱尔兰、日本、韩国和英国5,000多家中小企业的调查。
使用边界：报告将企业中任何员工为工作使用生成式AI的情况计为使用；核心业务活动占比的统计对象，是已经使用生成式AI的企业。企业自愿参与调查可能带来选择偏差，调查结果不能直接视为中国企业的采用率。
https://www.oecd.org/en/publications/generative-ai-and-the-sme-workforce_2d08b99d-en/full-report/component-4.html
3 麦肯锡 2025年Agent采用调查
The state of AI in 2025 Agents innovation and transformation，2025年11月5日。调查于2025年6月25日至7月29日进行，涉及105个国家的1,993名受访者。
使用边界：“开始尝试使用Agent”包括仍处于实验阶段的企业，不等于已经在全企业规模化应用。正文按年份介绍企业关注点的变化，未将不同调查视为对同一批企业的连续追踪。
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2025
4 METR 开发任务反面实证
Joel Becker等，Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity，2025年研究。实验使用2025年2月至6月期间的工具，涉及16名开发者和246个任务。
使用边界：研究对象是熟悉自身成熟开源项目的开发者，所用工具也属于特定时期的版本。由于样本较小、任务场景特定，不能用这一结果概括今天所有AI编程工作的效果。
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf
5 METR 后续更新
We are Changing our Developer Productivity Experiment Design，2026年2月24日。
使用边界：后续实验受到选择偏差与测时问题影响，不能可靠确定当前提效幅度。正文保留此更新，避免把早期负面结果当成长期不变的结论。
https://metr.org/blog/2026-02-24-uplift-update/
6 客户支持的生产率研究
Erik Brynjolfsson Danielle Li Lindsey Raymond，Generative AI at Work，The Quarterly Journal of Economics，2025年2月在线发表，140卷2期。
使用边界：研究考察了一家企业分批部署早期AI助手的效果。正文采用正式发表版中5,172名客服人员的样本，以及生产率平均提升15%的结果，未混用早期工作论文的数据。论文发表年份不等于实验开展年份；这一结果不能用于推算当前所有客服企业使用AI后的净收益。
https://academic.oup.com/qje/article/140/2/889/7990658
7 微软 自身转型经验
Kathleen Hogan，What we’ve learned from Microsoft’s own AI transformation，微软官方博客，2026年9月17日。
使用边界：供应链结果来自内部分析，只涉及特定工作流及测量期，不能代表全公司或全行业的收益。正文引用这一案例，说明部署AI之前需要完成哪些流程准备，以及如何安排人员协作。
https://blogs.microsoft.com/blog/2026/09/17/what-weve-learned-from-microsofts-own-ai-transformation/
8 世界经济论坛 制造业标杆案例
New Global Lighthouse Sites Demonstrate How AI Is Rewiring Manufacturing and Supply Chains，2026年6月22日。正文引用施耐德电气埃尔帕索工厂的案例。
使用边界：结果来自入选案例披露，属于多项技术及流程变革的共同成果；不是随机对照研究，也无法从中单独计算生成式AI带来的净回报。
https://www.weforum.org/media/new-global-lighthouse-sites-demonstrate-how-ai-is-rewiring-manufacturing-and-supply-chains
9 FDE 的职责参考
OpenAI Forward Deployed Engineer Tokyo 职位说明，检索于2026年10月18日。
使用边界：介绍了这一机构对FDE工程交付和客户协作能力的要求，不是全行业岗位标准，也不是对该岗位效果的研究。
https://openai.com/careers/forward-deployed-engineer-tokyo-tokyo-japan/
