�� AI 办公 | 2026-06-17

当 AI 走入办公室：今日 4 个真实故事

有个笑话，正在变成行业现实。

KPMG，全球最大审计咨询公司之一，2025 年 10 月发布了一份重量级 AI 报告。报告标题响亮，包装精美，一经发布就被当成行业风向标。

然后，GPTZero 把它拆了。

45 条引用，只有 5 条指向真实来源，其余全是 AI 凭空编出来的。UBS 没在用 AI 做那些事，NHS Greater Manchester 没在用 AI 做那些事，伦敦交通局也没在用 AI 做那些事。KPMG 把自家 AI 写出来的假案例，当成真行业经验，卖给了全球企业。

讽刺程度，干这行十几年，没见过比这更精准的。

一、成功案例

【案例 1】行业：能源 | 企业：BP

BP 在全球油气业务里部署的 AI 系统，正在悄悄改变一个最古老、最危险的工作。

钻井 "踢（kick）"—— 井筒内突然的压井溢流，是海上钻井最怕的两个字。BP 现在能做到 90% 的 "踢" 检测率。

不是用了什么神秘新 AI—— 是把 Palantir AIP 嵌进了钻井数据流里，实时分析泵速、泥浆池液位、套管压力，在人工能察觉之前，提前告诉工程师 "这个井可能要出事"。工程师从救火队变成了预防队。

更具体的数据：AWTO 把过去需要数周的井位规划周期压缩到几天；BP 与 Palantir AIP 的合作已经从数据可视化升级到大语言模型驱动的决策支持，平台内置了防止 AI 幻觉的护栏。

BP 上层能源资产数字化程度高，这是他们和那些数据基础薄弱的竞争对手的本质区别。踩过足够多的坑，才知道什么时候该信 AI、什么时候该踩刹车。

【案例 2】行业：电信 | 企业：Nokia

2026 年 6 月 11 日，Nokia 给自己的网络服务平台（NSP）加了一层 "代理 AI 框架"。

翻译成人话：以后电信运营商的网络出了问题，Nokia 的 AI 会先推理一遍，给出 "根因在这里" 的建议，再让工程师去修。不是替代工程师，是让工程师少走弯路。

这套框架的第一个用例叫 "AI 驱动故障排除智能体"—— 接入实时的网络拓扑、协议行为、配置状态，用 AI 推理出最可能的故障路径，然后把复杂问题转化成工程师能看懂的工作流。

官方目标：首次联系解决率提升到 50% 以上；网络事件分类时间压缩到 5 分钟以内；减少重复上门次数 50%。商用落地时间是 2026 年底。

这个 "2026 年底" 很有意思 —— 意味着这不是明天就能大规模铺开的技术。Nokia 的说法是 "渐进式"，让运营商先在小范围试，逐步建立对 AI 判断的信任。这个节奏控制得相当务实。

二、失败案例

【案例 3】行业：专业服务 | 企业：KPMG

KPMG 这件事，最讽刺的地方不是报告撤了。

是这家公司的主营业务之一，就是帮全球企业 "治理 AI 风险"。

GPTZero 发现里面声称 "JR 东日本铁道公司正在用代理 AI 做客户服务"，引用的来源是一份 2019 年的新闻稿 —— 那时候 "代理 AI" 这个词还没被造出来。AI 在没有真实训练数据的情况下，把五年前的旧闻和当下的 AI 叙事硬缝合在一起，创造出了一个根本没发生过的 "行业标杆案例"。

这不是 KPMG 一家的问题。就在同一个月，EY 也撤回了一份含有虚假脚注的研究报告。

KPMG 的失败，本质上是治理失败：一家以 "AI 风险管理专家" 自居的公司，在自己的核心内容生产流程里，没有任何一个环节能发现 AI 在胡说八道。这不是技术问题，是诚信问题。

【案例 4】行业：软件 / 开发者平台 | 企业：GitHub（微软旗下）

2026 年 6 月，一则消息悄悄出现在商业媒体圈：微软确认，正在把 GitHub 的部分流量路由到亚马逊 AWS 的服务器上。

你没看错 —— 微软，让自家 GitHub，用竞争对手亚马逊的云。

原因是：GitHub 上的 AI 编程智能体活动量，超出了平台设计时预估的容量上限。2026 年 5 月，GitHub 已经记录了九次服务降级；到 6 月，可用性指标远低于 99% 的企业级 SLA 标准。

更意味深长的是：同周，一宗针对微软 CEO 和 CFO 的证券集体诉讼递交到法院，原告指控微软对 Azure 容量限制和 Copilot 采用率存在误导性陈述。

GitHub 的失败，是 "速度失控" 的最典型案例：当 AI 编程智能体的需求增速远超所有人预期，平台方、基础设施提供方、企业客户 —— 没有人真正预估到了这股需求有多凶猛。技术跑得太快，基础设施追不上，治理机制更追不上。

三、栏目评论

今天 4 个案例，拼出了一条越看越清晰的规律。

BP 和 Nokia 的成功，有一个共同特征：知道 AI 的边界在哪里。BP 用 AI 做钻井数据推理，Nokia 用 AI 做网络故障推理 —— 两者都是 "AI 给建议，人做决定" 的模式，边界划清楚，价值就来了。

KPMG 的失败和 GitHub/Microsoft 的失败，有一个共同点：速度失控。KPMG 来不及核实 AI 的输出，GitHub 来不及扩大基础设施 —— 都是跑得太快，配套没跟上。

KPMG 的故事最说明问题：当你开始用 AI 生产关于 AI 的知识，你有没有想过，谁来审计 AI 说的 AI 故事？

四、阿杜省思

人的维度

KPMG 那个案例，我印象最深的不是报告被撤。

是 GPTZero 发现这份报告里的参考文献，有一种叫 "vibe citing"（感觉式引用）的模式 —— 参考文献看起来像真的，但你去查的时候发现，标题被篡改了，或者作者和主题对不上。

"人类不会这样犯错，但 AI 会。"

这句话值得所有职场人记住。当你用 AI 生成一份报告，你有没有核对过里面引用的数据？引用的来源？引用的案例？能发现 AI 什么时候在胡说，比会用 AI 更重要。

组织维度

KPMG 和 GitHub 的失败，指向同一个组织病症：AI 的使用速度，超过了组织建立治理框架的速度。

管理层真正该做的：不是宣布 "我们全公司用 AI"，而是先回答三个问题 —— 我们在哪些环节用 AI 做判断，哪些环节用 AI 做执行？AI 的输出，谁来签字负责？我们有没有能力发现 AI 什么时候在胡说？

这三个问题不答清楚，AI 落地就是裸奔 —— 而且，在 KPMG 案例曝光之后，"我们不知道 AI 在说谎" 这个借口，在法庭上、监管机构面前，可能越来越难站住脚了。

本栏逢工作日更新，聚焦真实商业案例，剖析人机协同的成败逻辑。案例均来自公开商业资讯，可溯源可查证。