乐于分享
好东西不私藏

�� AI 办公 | 2026-06-17

�� 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 在说谎" 这个借口,在法庭上、监管机构面前,可能越来越难站住脚了。

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