麦肯锡2025 AI报告解读：工作流重设计与EBIT归因

简介：这份麦肯锡2025年3月发布的《The state of AI》调查报告，聚焦生成式AI如何推动企业重塑组织架构并兑现商业价值，适合企业高管、AI项目经理与战略规划人员阅读。内容基于最新全球调研，指出CEO对AI治理的监督与工作流程的根本性重设计，是产生财务影响的关键变量；年营收5亿美元以上的大型企业推进更快，在AI人才招聘与员工再培训上更为积极，并已把生成式AI嵌入营销、销售、产品开发与服务运营等业务职能。报告同时梳理了与生成式AI相关的风险类型与缓释做法，还给出建立专门推动团队、定期沟通AI价值、高层深度参与等可借鉴实践，并提示多数企业的整体利润尚未出现显著变化，但收入增长与成本下降已有迹象。资源包内为1份PDF文件，约5.31MB，结构完整便于通读与检索。目前已有345人学习。

1. 把生成式 AI 落地全权交给 IT 部门，是这份报告点名的失败配方

麦肯锡 2025 年 3 月这份《The state of AI: How organizations are rewiring to capture value》，调研了 1491 名来自不同层级的管理者（2024 年 7 月 16—31 日），结论并不温和：超过四分之三的组织至少在一个业务职能里用上了 AI，但真正把生成式 AI 变成利润表上数字的，是少数把组织结构一起改掉的公司。报告里最扎眼的一组数字是——28% 的受访者表示自家 CEO 直接监督 AI 治理，17% 由董事会监督，而 CEO 亲自盯治理这件事，与自评的 EBIT 影响相关性最高，在年收入 5 亿美元以上的大企业里尤其明显。

更值得琢磨的是权重排序：在测试过的 25 个属性中，「重新设计工作流」对生成式 AI 产生 EBIT 影响的作用最大，但目前只有 21% 的受访者说自家组织已经彻底重塑了至少一部分工作流。也就是说，绝大多数团队卡在「工具跑起来了、流程没动」这一段。

这份报告适合三类人：正在为大模型部署找 ROI 口径的业务负责人、负责 AI 治理与风险管理的合规与技术管理者，以及要把报告结论转成内部方案的项目经理。接下来的几章，我会把它拆成可查询的数据表、可复现的权重算法和可打分的自检脚本。

2. 把 Exhibit 数据抽成可查询表：调研口径、字段与 SQLite 落库

报告本身是 PDF，图里的百分比没法直接过滤、排序、做交叉分析，所以第一步是把它变成能写 SQL 的表。这一步做扎实，后面所有结论才有可追溯的来源。

2.1 先对齐调研口径，再谈字段

口径不清就直接建模，是最常见的第一类坑。这份调研的因变量是「生成式 AI 对组织 EBIT 的影响」自评值，自变量是 25 个属性，其中包含 12 条采纳与扩展最佳实践（0/1 变量）、AI 治理监督人（类别变量）、集中度（三分类）、输出复核比例（分箱变量）。落库前先按下面这张表统一命名，避免后面 JOIN 时字段对不上。

注意：Exhibit 2 的分箱合计是 101%，属于四舍五入误差，做加权平均时按原始分箱中位数取值，别直接当成连续变量求均值。

2.2 用 pdfplumber 抽出表格并做归一化

报告里的图是带网格线的矢量表格，lines策略比默认的文本策略稳得多。抽完必须人工核对行序，因为图例文字经常被识别成一列。

import pdfplumber import pandas as pd PDF = "mckinsey-state-of-ai-2025.pdf" def parse_exhibit1(page_no: int) -> pd.DataFrame: """抽取集中度三分类表：行=分布方式，列=治理要素""" with pdfplumber.open(PDF) as pdf: page = pdf.pages[page_no] table = page.extract_table({ "vertical_strategy": "lines", # 依赖表格边框线，抗文字干扰 "horizontal_strategy": "lines", "intersection_tolerance": 5, # 细网格线交叉容差，pdfplumber 常用默认是 3 }) rows = ["fully_distributed", "hybrid", "fully_centralized"] cols = ["risk_compliance", "data_governance", "ai_strategy", "ai_roadmap", "tech_talent", "adoption"] df = pd.DataFrame(table, columns=cols, index=rows) return df.apply(pd.to_numeric, errors="coerce") # 非数字单元格置 NaN，便于人工排查 central = parse_exhibit1(3) print(central)

intersection_tolerance调大会把相邻单元格合并，调小会漏掉细线，5 是这类咨询报告常见的可用值。归一化环节的关键动作是校验每列求和：central.sum(axis=0)应该接近 100，偏离超过 2 个点说明行序或列序错了，回去比对原图。

2.3 落库到 SQLite，做分组交叉查询

结构化之后就能回答报告正文没直接给出的问题，比如「大企业里 CEO 监督治理的比例反而更低」这个反直觉现象。

import sqlite3 conn = sqlite3.connect("ai_survey.db") df.to_sql("survey_responses", conn, if_exists="replace", index=False) # 建索引：后面按规模、治理监督人、是否重塑流程三个维度反复分组 conn.executescript(""" CREATE INDEX IF NOT EXISTS idx_size ON survey_responses(revenue_usd_m); CREATE INDEX IF NOT EXISTS idx_gov ON survey_responses(ceo_oversees_governance); """)

-- 收入规模 × CEO 是否监督治理 × 是否重塑工作流，三交叉看 EBIT 自评均值 SELECT CASE WHEN revenue_usd_m >= 500 THEN 'large' ELSE 'small' END AS size_bucket, ceo_oversees_governance, workflow_redesigned, COUNT(*) AS n, ROUND(AVG(ebit_impact), 2) AS avg_ebit_impact FROM survey_responses WHERE uses_ai = 1 GROUP BY 1, 2, 3 HAVING COUNT(*) >= 20 -- 样本太少的分组不参与解读 ORDER BY 1, 2, 3;

HAVING COUNT(*) >= 20是必须的：报告本身就提醒过，分到 5 亿美元以上企业这一层之后样本会明显变薄，交叉再交叉容易掉进个位数样本。CASE WHEN把连续的收入字段离散化，是为了和报告原文的分组口径一致，别自己另设阈值，否则结论没法跟原报告对照。

3. 工作流重设计与 EBIT 归因：25 个属性的相对权重怎么算

报告原文用的是 Johnson 相对权重回归，R² 约 0.20。这个数字不高，但正因如此才更该理解它的边界——它解释的是「哪些属性在统计学上贡献大」，不是因果结论。

3.1 为什么不用普通回归系数排序

25 个属性之间高度相关：有专职推动团队的，往往也有清晰的路线图和 KPI 追踪；有高层亲自用 AI 的，通常也做了角色化培训。普通最小二乘在这种共线性下，系数会因为变量间的共同方差被互相抵消，甚至出现负号，排序完全不可信。相对权重做的事就是把每个变量的总贡献拆成「独立贡献 + 与其他变量共享的贡献」，再做归一化，得到的百分比是可以横向比较的。

3.2 用 Python 复现 Johnson 相对权重

原理是把标准化后的自变量矩阵做特征分解，投影到一组两两正交的主成分上，再对因变量回归。每个变量的相对权重等于它在各个主成分上的方差份额乘以对应回归系数的平方和。

import numpy as np import pandas as pd from sklearn.linear_model import LinearRegression from sklearn.preprocessing import StandardScaler def johnson_relative_weights(X: pd.DataFrame, y: pd.Series) -> pd.Series: """返回各属性对 EBIT 自评的相对权重（百分比，合计 100）""" Xs = StandardScaler().fit_transform(X) yv = StandardScaler().fit_transform(y.values.reshape(-1, 1)).ravel() R = np.corrcoef(Xs, rowvar=False) # 自变量相关矩阵 d, V = np.linalg.eigh(R) d = np.clip(d, 1e-8, None) # 共线性会导致特征值趋近 0，截断防爆炸 Z = Xs @ V @ np.diag(d ** -0.5) # 正交化预测矩阵，列间相关为 0、方差为 1 coef = LinearRegression(fit_intercept=False).fit(Z, yv).coef_ lam = (V ** 2) * d # lam[i, j]：变量 i 在第 j 个成分上的方差份额 rw = lam @ (coef ** 2) return (pd.Series(rw / rw.sum() * 100, index=X.columns) .sort_values(ascending=False).round(2)) # 复现报告口径：用自建问卷数据（一行一家企业）跑一遍 ranking = johnson_relative_weights(X=survey_features, y=survey_responses["ebit_impact"]) print(ranking.head(10))

np.clip(d, 1e-8, None)是这段代码里最不能省的一行。问卷里若有两条实践永远同时为 1，相关矩阵奇异，特征值会出现极小值甚至负数，d ** -0.5直接产生 NaN 或天文数字。截断之后权重仍然稳定，但你需要回头把这两条实践合并或者删掉一条。

3.3 参数口径：把问卷选项变成数值

编码方式直接决定排序结果。12 条最佳实践保持 0/1，有序变量保留原始序次，多选类别变量必须拆成一列一个 0/1。

跑完排序先做一次健全性检查：把「工作流重塑」这一条单独放进模型，看它的相对权重是否稳定排在前三。如果排到十名开外，八成是编码错了——报告里它的权重是第一。排序出来的前五项，就是内部推动会上最该拿来当议程的东西；排在末位的实践不是不重要，而是在统计意义上与 EBIT 自评的关联弱，别拿它去说服 CFO。

4. AI 治理集中度与风险缓解清单：五个要素怎么配权责

报告 Exhibit 1 给出的集中度数据很实用，因为它把「AI 治理」这个大词拆成了六个可分配权责的要素，每个要素该集中还是该分散，答案并不一样。

4.1 六个要素的集中度基线

数据很清楚：风险与合规、数据治理这两项，多数组织交给卓越中心一类的集中机构；技术人才和解决方案采纳则以混合模式为主，一部分资源集中在平台侧，一部分散在业务单元。还有一个容易被忽略的反差——年收入低于 5 亿美元的组织，比大企业更倾向于把这些要素完全集中。小公司资源少，集中是理性选择；大企业业务单元多，全集中反而会变成瓶颈。

需要注意的是，这六个百分比不是「应该达到的目标值」，而是横向基线。你自己的方案如果和基线差 20 个点以上，要么有明确理由，要么就是权责没想清楚。

4.2 用代码校验 RACI 的唯一责任人

治理矩阵最常见的失效方式是同一件事挂两个 A（Accountable），出事时互相推。把矩阵写成代码，让校验自动化。

import pandas as pd raci = pd.DataFrame( [ # 要素, CEO, 董事会, 数据治理委员会, 业务单元, IT/平台团队, 外部审计 ["AI 治理政策与流程", "A", "C", "R", "I", "C", "I"], ["风险与合规", "I", "A", "R", "C", "C", "C"], ["数据治理", "I", "C", "A", "R", "R", "I"], ["AI 战略", "A", "C", "C", "R", "C", "I"], ["技术人才", "I", "I", "C", "A", "R", "I"], ["解决方案采纳", "I", "I", "I", "A", "R", "I"], ], columns=["要素", "CEO", "董事会", "数据治理委员会", "业务单元", "IT/平台团队", "外部审计"], ) def check_unique_accountable(df: pd.DataFrame) -> pd.DataFrame: """每个要素必须恰好一个 A，否则治理责任会互相推诿""" a_counts = (df == "A").sum(axis=1) bad = a_counts[a_counts != 1] return pd.DataFrame({"要素": bad.index, "A 的数量": bad.values}) problems = check_unique_accountable(raci) print(problems if not problems.empty else "RACI 校验通过")

矩阵本身要按你公司的实际委员会名称改列，但校验逻辑不变。两个参数值得留意：一是「董事会」列在报告里对应 17% 的组织，如果你的董事会没有技术背景，先放 C 而不是 A；二是「数据治理委员会」在风险与合规行里是 R，与数据治理行的 A 不同，这个交叉是刻意的，数据和风险的边界不能混。

4.3 风险缓解与输出复核比例的配置

报告 Exhibit 2 的数据值得直接抄进你的质检策略：27% 的组织复核全部生成内容，而 30% 的组织只复核 20% 及以下。这两个数字几乎一样大，说明行业里根本没有统一答案，复核比例必须按场景分级。同时，风险缓解力度在提升的集中在三类：不准确性、网络安全、知识产权侵权——这三类也是受访者最常报告已造成负面后果的。大企业在网络安全和隐私风险上的缓解力度明显高于小企业，但在准确性和可解释性上并没有更积极，这个落差值得自查。

复核比例不是越高越好。全量复核会把效率收益全部吃掉，正确的做法是按内容面向的对象分档，把 100% 复核留给客户可见和涉及个人权益的两类。

5. 12 条最佳实践的打分脚本与验证口径

报告列出的 12 条采纳与扩展最佳实践，本质是一张成熟度清单，但清单不能直接当评分卡用——条目之间重要性有差异。把权重显式写进配置，再让脚本算出缺口，才能拿去开会。

import pandas as pd # 权重依据第 3 章的相对权重排序调整，嵌入流程与 KPI 追踪权重最高 WEIGHTS = { "dedicated_team": 1.0, # 专职推动团队（PMO / 转型办公室） "internal_comms": 0.5, # 定期沟通价值，建立势能 "senior_role_model": 1.0, # 高层带头使用 "embedded_in_process": 1.5, # 嵌入业务流程，改一线操作界面 "role_based_training": 1.0, # 按角色分层的能力培训 "employee_trust": 1.0, # 员工信任机制（源头可查、抑制错误） "feedback_loop": 1.0, # 效果反馈与迭代机制 "roadmap": 1.0, # 分阶段推广路线图 "change_story": 0.5, # 变革叙事 "kpi_tracking": 1.5, # 明确 KPI，打通采纳与 ROI "incentives": 0.5, # 与采纳挂钩的激励 "customer_trust": 1.0, # 客户信任机制（合规透明、数据使用） } def score(answers: dict) -> pd.DataFrame: """answers: 实践名 -> 0/1；返回加权得分与缺口排序""" assert set(answers) == set(WEIGHTS), "自检项与权重表必须一一对应" max_score = sum(WEIGHTS.values()) rows = [ {"实践": k, "权重": WEIGHTS[k], "现状": v, "差距": round(WEIGHTS[k] * (1 - v), 2)} for k, v in answers.items() ] df = pd.DataFrame(rows).sort_values("差距", ascending=False) df.attrs["加权得分率"] = round( sum(WEIGHTS[k] * v for k, v in answers.items()) / max_score * 100, 1) return df result = score({"dedicated_team": 1, "embedded_in_process": 0, "kpi_tracking": 0, "roadmap": 1, "change_story": 1, "internal_comms": 1, "senior_role_model": 0, "role_based_training": 0, "employee_trust": 0, "feedback_loop": 0, "incentives": 0, "customer_trust": 0}) print(result.head(5), result.attrs["加权得分率"])

assert那行别删：权重表和自检项数量不一致时，得分率会被静默算错，这种错在汇报现场很难解释。缺口排序按「权重 × 未达成」计算，天然把高权重项的缺失顶到前面。

验证口径要分三层。第一层是自评一致性：同一个业务单元让业务负责人和 IT 负责人各填一遍，两条结果差异超过 20 分，说明双方对「嵌入流程」的理解根本不同，先对齐定义再谈打分。第二层是抽样复核：按第 4 章的分级表抽出 5% 的生成内容回看，如果复核结论与自评分方向相反，以抽样结果为准。第三层是 KPI 落库，把采纳率、单流程节省工时、返工率三张表按月快照进同一张宽表，用GROUP BY month, business_unit看趋势拐点。

权重表先按业务单元各跑一遍再合并——差异最大的那两三个单元，通常就是工作流重设计的起点。

本文还有配套的精品资源，点击获取