AI 转型是指组织有意识地重新设计决策方式与工作执行方式,使 AI 成为其中的核心组成部分。针对精简团队的实用 AI 转型策略,从一个反复出现的工作流入手:对其进行梳理,选定一个边界清晰的生产任务,明确责任归属与人工审核机制,以影子模式运行,衡量业务价值,并仅在质量与管控阈值稳定达标后再行扩展。
| 阶段 | 需要做出的决策 | 责任人 | 推进所需的证据 |
|---|---|---|---|
| 1. 梳理 | 哪些反复出现的工作流耗费时间或导致决策延误? | 运营负责人 | 包含频率、工作量、输入、输出及痛点的工作流清单 |
| 2. 选定 | 哪项任务有价值、边界清晰、可审核且可逆? | 业务负责人 | 一个具名用户和明确输出的生产候选项 |
| 3. 基准 | 当前流程的成本与绩效水平如何? | 工作流操作员 | 当前工作量、人力投入、耗时、缺陷、返工及下游结果 |
| 4. 契约 | AI 可以读取、决策、写入哪些内容,绝对不能做什么? | 业务负责人 | 经批准的操作契约、权限、审核节点及停止条件 |
| 5. 影子测试 | 输出结果是否能在不影响实际工作的情况下通过验收? | 领域审核员 | 满足约定验收阈值的代表性并行运行记录 |
| 6. 发布 | 在受控生产条件下,该工作流是否能创造价值? | 业务负责人 | 已验收的输出、干预时间、运行成本、故障情况及用户采用率 |
| 7. 扩展或停止 | 结果是否具备足够的可重复性,可以纳入常规运营? | 执行发起人 | 正向净收益、稳定的管控机制、责任人及维护中的操作规程 |

图 1. 仅在前一阶段产出可审核证据后,方可推进至下一阶段。
AI 转型对精简团队意味着什么
对于精简团队而言,AI 转型意味着某个反复出现的工作单元,因 AI 成为流程的一部分,其方法、管控、责任归属和经济模型随之改变。首要目标是建立一个具有可验证输出、明确责任人和安全停止机制的生产工作流。
IBM 对 AI 转型的定义更为宏观,涵盖将 AI 引入运营、产品和服务的全过程。工作流层面的定义,使十人团队的首个决策具有可检验性。新开一个聊天账号达不到这一标准;而一个每周进行的增长复盘——汇聚数据来源、标记追踪缺口、起草分析报告,并等待责任人审批解读结论——则符合这一标准。
AI 转型与数字化转型的区别
数字化转型通过软件让信息和流程变得可访问。AI 则在此基础上,为这些数字化流程引入概率判断、内容生成和自适应能力,从而改变了管控问题的本质。
| 数字化转型 | AI 转型 |
|---|---|
| 将纸质或手动流程迁移至数字系统 | 重新设计流程内部由谁或由什么来执行判断 |
| 通常遵循明确规则,输出结果可预期 | 相同的工作流形态可能产生不同的输出结果 |
| 验证系统是否执行了指定逻辑 | 验证输出质量、证据、权限及异常处理 |
| 培训人员使用新界面 | 改变决策权、审核工作、升级机制及责任归属 |
AI 数字化转型这一表述通常用于描述两者的交叉地带。顺序依然至关重要。如果数据来源无法安全访问、输出结果没有责任人,或者没有人能说清楚正确结果是什么样的,那么引入 AI 只会暴露这些问题,而非解决它们。
对于精简团队而言,实际目标是建立一个由明确责任人管理的小型生产工作流组合。麦肯锡当前的 AI 转型宣言提出了类似的战略观点:聚焦少数真正重要的经济价值点,并让业务负责人对结果承担责任。本指南的其余部分将把这一原则转化为可操作的执行序列。
分七个阶段构建 AI 转型策略
精简团队的 AI 转型策略,是将一个工作流依次通过七个证据关卡:梳理、选定、基准、契约、影子测试、有限发布,以及扩展或停止决策。每个关卡都有明确的责任人,并要求提供证据后方可进入下一阶段。顺序至关重要,因为自动化会放大工作流中已有的一切。
将其视为一份以决策关卡为节点的 AI 转型路线图,而非以日历里程碑为节点。根据工作流的重要程度和现有证据的质量,每个阶段可能需要数天乃至数周时间。
1. 梳理工作流,而非 AI 创意
从一周的实际工作入手,而非从模型功能列表出发。请每位操作员列举那些反复出现、跨工具流转、在队列中等待,或最终产出同类成果的工作。
每个工作流记录一行:
| 字段 | 问题 |
|---|---|
| 触发条件 | 什么启动了这项工作:计划安排、外部事件,还是某个人? |
| 数据来源 | 哪些系统包含完成该工作所需的信息? |
| 决策节点 | 在哪些环节需要人工进行解读、优先级判断或选择? |
| 输出 | 什么样的完成成果或系统变更标志着任务结束? |
| 频率 | 该工作多久发生一次,工作量的波动幅度如何? |
| 当前工作量 | 处理一个案例需要多少主动工作时间和等待时间? |
| 例外情况 | 哪些案例会偏离正常路径,原因是什么? |
| 后果 | 工作延误或出错会带来什么影响? |
人们往往将工作描述为"很忙",直到有人问起"如果有魔法棒,你最想解决什么"。vm0 关于工作流为何仍是手动执行的研究,通过 22 次访谈记录了这一发现难题。如果你的团队无法列举候选项,可以参考附有具体触发条件、输出和审批节点的 AI 智能体示例来识别工作流形态,然后写下你自己的触发条件、数据来源、输出和审批节点。不要照搬一个你并不存在其业务问题的用例。
2. 选定第一个生产用例
第一个工作流应当足够有价值,同时足够安全,便于研究。优先选择输出结果可见、数据来源可访问、重复频率高,且有人能快速判断结果是否正确的工作。
| 选择问题 | 更好的首选候选项 | 较差的首选候选项 |
|---|---|---|
| 审核员能否判断输出是否正确? | 有来源支撑的内部简报 | 开放式战略建议 |
| 操作是否可逆? | 草稿、标签或拟议更新 | 付款、删除或公开发送 |
| 范围是否有边界? | 单一收件箱、时间窗口和输出格式 | "全面改善公司运营" |
| 输入数据是否可获取? | 已连接的、归属明确的记录 | 需要从多个私有存储中复制的数据 |
| 是否反复出现? | 每日、每周或事件驱动的工作 | 没有重复路径的一次性项目 |
收件箱晨间简报示例展示了这种工作流形态。该工作流读取指定的 Gmail 时间窗口,对需要关注的内容进行排序,并发布一条 Slack 简报。其写入范围明确排除了移动、删除、标记、归档、转发或回复邮件等操作。这一边界使输出结果有实用价值,同时保持首次发布的可逆性。
避免将全公司通用助手作为第一个用例。"所有人都可以问任何问题"没有稳定的评判标准,没有固定的审核员,也没有明确的失败节点。它制造了活动,却无法产生证据。
3. 建立当前工作流的基准
在改变流程之前,先对人工流程进行测量。否则,所有改进声明都会变成在结果已知后编造的故事。
针对有代表性的样本,记录以下数据:
- 每周或每月的案例数量
- 每个案例的主动工作分钟数
- 从触发到完成输出的经过时间
- 首次通过率与返工情况
- 例外情况、缺陷及其后果
- 所用系统或外部人力的成本
- 该工作流本应影响的下游业务结果
明确分析单元。如果一个人将整个下午都计入,而另一个人只计算键盘操作时间,"节省的工时"就毫无意义。选择一份完成的报告、一个已处理的收件箱时间窗口、一个已核对的账户,或其他可观察的单元。
不要凭空为速度提升赋予货币价值。如果更快的报告改变了某个决策,请记录这一关联。如果团队只是更早收到了同样的报告,则报告周期时间的变化,并将收入排除在外。
4. 撰写操作契约
当第一个工作流拥有一份契约时,AI 转型策略才真正具备可执行性。这是一份简短的操作文件,而非一本政策手册。
| 契约字段 | 需要做出的决策 |
|---|---|
| 目的 | 该工作流支持哪项业务结果? |
| 责任人 | 谁对结果、预算和延续负责? |
| 操作员 | 谁负责检查运行情况并维护操作规程? |
| 输入 | 可以读取哪些数据来源和时间窗口? |
| 权限 | 哪些操作被允许、被禁止或受时间限制? |
| 输出 | 需要什么格式、目标位置和来源证据? |
| 人工审核 | 谁来审核,在哪个节点,依据哪些标准? |
| 失败阈值 | 哪类缺陷会立即暂停工作流? |
| 升级机制 | 谁来处理未知情况、例外情况或访问受阻? |
| 审计证据 | 输入、操作、决策和审批记录在哪里? |
| 有效期 | 责任人何时重新审批、修订或终止该工作流? |
这一区分在 Zero 中体现得非常具体。工作流是可复用的操作规程,包含其目标、输入、输出、边界和参考资料。自动化则是在手动工作流通过验证后附加触发条件。将这两个决策分开,可以防止计划任务反复触发一个从未通过审核的操作规程。
权限也应写入契约。Zero 的权限模型将成员的连接、智能体的授权,以及该智能体可以请求的具名操作分别管理。授权可以设置时间限制,一个负责准备草稿的工作流可以被拒绝最终发送操作的权限。无论使用何种平台,都需要对以下问题给出等效答案:谁提供了凭证,系统可以用它做什么,以及访问权限可以多快被撤销?

图 2. 操作回路将 AI 执行、管控检查和人工决策分别独立。
5. 以影子模式运行并设定失败阈值
影子模式是指 AI 在不改变实际流程的情况下执行工作流。向其输入已完成的历史案例,或在当前操作员旁边并行运行。将输出结果与同一份验收清单进行对比。
使用具有代表性的输入,包括普通案例、边缘案例、数据缺失情况和来源冲突情况。经过精心打磨的"理想路径"演示几乎无法证明任何问题。
在运行前定义失败类别:
| 失败类别 | 示例 | 建议响应 |
|---|---|---|
| 严重 | 未授权操作、敏感数据泄露、伪造来源、未经批准的对外承诺 | 零容忍;停止运行并在重启前进行调查 |
| 重大 | 遗漏必要项目、解释缺乏支撑、优先级错误、系统更新失败 | 根据业务后果设定最高发生率;超出时暂停扩展 |
| 轻微 | 格式、排序、命名或低影响的遗漏 | 修正操作规程并跟踪复发情况 |
| 数据或系统阻断 | 权限缺失、数据来源不可用、监控中断、记录过期 | 上报为"未知"或"受阻";绝不猜测绕过 |
预算差异说明示例为这一阶段提供了有用的参考模式。解释需要来源证据,账本访问保持只读,未记录的差异则转为私下向责任人提问。该工作流的质量,在于保留"未知"与起草可解释内容同等重要。
6. 在人工审核下向有限生产环境发布
从影子模式过渡到小范围生产切片:一位操作员、一个数据来源、一个客户细分,或一个定期时间窗口。在新路径经历真实例外情况之前,保留旧流程作为备用。
根据操作的后果设定审核节点:
| 操作类型 | 初始审核设计 |
|---|---|
| 只读内部分析 | 试点期间审核每一份输出,稳定通过后转为抽样审核 |
| 草稿或可逆更新 | 在任何人依赖该成果之前审批 |
| 内部状态变更 | 在回滚和异常处理机制得到验证之前,要求确认 |
| 对外、财务、破坏性或具有法律约束力的操作 | 保留执行前的人工审批,并设置独立的最终操作权限 |
只有当审核员有时间、有标准、有权力拒绝时,人工审核才是真正的管控手段。"有人在回路中"是不够的。衡量审核所需时间、哪些内容被修改,以及审核员是否开始不经阅读就直接批准。
添加触发条件时,从窄范围开始。自动化文档建议检查最初几次运行,使用严格的事件过滤器,确认时区,并在调试时禁用自动化。连接器文档也将连接和授权作为独立决策,有助于防止共享工具连接演变为广泛的智能体访问权限。
7. 扩展、修订或停止
扩展意味着该工作流成为常规运营的一部分,拥有维护中的责任人、有据可查的管控机制和可重复的经济案例。这不等于为每位员工购买席位。
满足以下四个条件时方可扩展:
- 业务指标相对基准有所改善。
- 质量和关键风险阈值在代表性生产工作中持续达标。
- 审核和维护工作量没有抵消收益。
- 目标用户采用了新路径,而非继续并行运行手动流程。
当用例仍有价值,但错误集中于可修复的数据来源、指令、权限或交接环节时,进行修订。当结果不佳、采用率持续低迷,或安全运营所需的审核工作量超过工作流节省的工作量时,选择停止。
这正是 AI 运营转型成为自有运营能力的节点。保存经过验证的操作规程,明确保留其触发条件和权限,并仅将真正可迁移的部分复用于下一个工作流。
无需企业级项目的治理机制
精简团队不需要为每个试点设立委员会,但确实需要明确的责任归属。一个人可以身兼多个角色,但各角色应保持可见。
| 角色 | 负责内容 |
|---|---|
| 业务负责人 | 结果、预算、优先级、风险接受,以及扩展或停止决策 |
| 工作流操作员 | 日常运行健康状况、例外情况、操作规程变更及用户反馈 |
| 领域审核员 | 验收标准、抽样输出审核及重大错误分类 |
| 平台或数据负责人 | 访问权限、连接器健康状况、日志记录、数据保留及权限撤销 |
为每个生产工作流维护一份单页清单,包含:责任人、目的、数据来源、权限、审核步骤、模型或服务提供商、当前版本、失败阈值、上次审核日期及终止开关。这足以在事故发生后回答那些令人不安的问题:什么在运行,谁授权的,依据哪条规则,谁叫停了它?
使用成熟的风险框架来检查盲点。自愿性的 NIST AI 风险管理框架涵盖治理、情境映射、风险测量及 AI 全生命周期的风险管理。NIST 的生成式 AI 概况为生成式系统特有的风险提供了额外指导。精简团队可以将这些问题应用于每个工作流,而不必在第一天就尝试建立全公司的管控体系。
关于智能体自主性、审计追踪和凭证边界的深入探讨,请参阅 vm0 关于从副驾驶到同事的转变的指南。本转型指南聚焦于运营责任归属:即使模型、连接器或平台由其他团队提供,业务负责人仍然对结果负责。
如何评估 AI 转型平台
评估 AI 转型平台,应看其在工作流层面能让哪些内容变得可管控、可观察。它应当能够保存操作规程、将触发条件与指令分离、限制工具操作、展示来源证据和运行历史、在关键操作前设置审批,并提供足够的成本和异常数据以支持扩展或停止决策。
功能数量是一个薄弱的采购标准。请供应商演示一个从触发到验收输出的完整真实工作流,包括权限受阻、运行失败、人工拒绝,以及事后可查的证据。
| 采购问题 | 需要请求的证据 | 警示信号 |
|---|---|---|
| 操作规程是否可归属并可修订? | 具名工作流、责任人、当前版本及变更历史 | 逻辑仅存在于某人的提示词或聊天记录中 |
| 访问权限是否可以受限? | 独立的连接、智能体授权、具名操作、有效期及撤销机制 | 连接账户默认授予广泛访问权限 |
| 审核是否可以设置在风险边界处? | 在对外、财务、破坏性或具有约束力的操作之前进行审批 | 审核仅在操作完成后进行 |
| 操作员是否能重建一次运行记录? | 数据来源、请求的操作、输出、错误、时间戳及审批记录 | 只有最终响应可见 |
| 团队是否能衡量一个完成任务的经济效益? | 运行成本、审核时间、例外情况、已验收输出及单元级历史记录 | 定价可见,但工作流经济效益不可见 |
| 责任人是否能停止或回滚? | 终止开关、禁用触发器、撤销访问权限及有据可查的回退方案 | 团队调查期间工作流持续触发 |
平台可以让运营决策具有可执行性和可见性,但无法替代业务负责人提供基准数据、验收标准或停止的意愿。如果一款产品在这些决策做出之前就承诺转型,请将其视为执行工具,而非运营模型。
真正改变工作的变革管理
变革管理在仅仅意味着一封发布邮件和可选培训时,注定会失败。操作员的工作必须切实发生改变。
首先,与当前执行该工作的人共同设计工作流。他们了解未记录在案的数据来源、从外部看似微不足道的例外情况,以及一个看似合理的输出为何仍然无法使用的原因。
其次,用简明语言说明新的工作分工。明确 AI 负责准备什么,操作员负责决策什么,哪些操作仍需审批,以及系统不确定时会发生什么。人们抵制模糊的责任归属,远比抵制一个边界清晰的工具更强烈。
第三,针对失败场景进行培训。向审核员提供包含数据缺失、证据冲突和高后果操作的示例。教会他们检查来源链接和活动日志,而不仅仅是修改文字表述。
最后,当新路径赢得信任后,退役旧路径。更新标准操作规程、会议议程、责任归属图和绩效指标。一个与手动流程并存的生产工作流,会使工作量翻倍,并掩盖采用率是否真实。
将修正视为运营数据。每周按类别审查编辑内容:数据来源问题、指令问题、权限问题、模型局限性,或审核员偏好。只有前四类属于系统变更的范畴。个人风格编辑不应触发新的管控措施。
如何衡量 AI 转型的 ROI
AI 转型的 ROI 是一个工作流变化后的净价值,而非 AI 使用量的多少。对比一个完成单元在变化前后的情况:人力投入、经过时间、通过率、返工、故障、运行成本、审核成本,以及下游业务结果。只有在能够证明关联关系时,才将收入或风险降低纳入计算。
在工作流层面使用以下公式:
月度净收益 = 经验证的人力价值节省 + 有证据的下游价值 + 避免的返工或损失 − AI 运行成本 − 人工审核成本 − 维护成本
将四个层次的证据分别独立:
| 证据层次 | 指标 | 证明的内容 |
|---|---|---|
| 活动 | 运行次数、用户数、模型调用次数、已连接工具 | 系统被使用了 |
| 输出 | 完成率、首次通过率、来源覆盖率、人工编辑次数 | 成果是可用的 |
| 工作流 | 主动工作时间、经过时间、返工、异常处理、单元成本 | 流程发生了改变 |
| 业务 | 收入、留存率、利润率、风险损失、客户响应、决策速度 | 变化影响了预期结果 |

图 3. 使用数据开启证据链;扩展需要工作流和业务层面的结果。
活动数据是诊断性的,而非 ROI。一个工作流可以运行 500 次,却仍然没有创造任何价值。反之,一个月度财务流程可能工作量不大,但如果它能在不削弱管控的前提下减少结账工作量,则具有充分的业务案例。
每周网站分析示例展示了良好的证据习惯:交叉核对两个系统,将追踪中断与用户行为区分开来,并避免在没有实验证据的情况下声称某次上线导致了指标变化。这种严谨性比一个精美的仪表盘更重要。
在单元经济学方面,vm0 关于降低 AI 智能体成本的指南,对模型选择、运行频率、上下文和外部服务进行了分别分析。如果需要分析产品数据,脱敏只读数据库模式展示了精简团队如何在不暴露原始生产内容的情况下保留可关联的运营数据。
在每次审查时做出以下三个决策之一:
- 扩展: 净收益为正,管控稳定,采用率稳定。
- 修订: 结果有价值,但某个数据来源、指令、交接或权限导致反复失败。
- 停止: 价值薄弱、风险不可接受,或审核和维护消耗了全部收益。
运营模型在哪里停滞
在第一个工作流运转之前,就开始构建工作流组合。 一份冗长的路线图看起来很有战略感,却将注意力分散到那些尚未学会如何运营一个生产系统的责任人身上。先完成一个完整的证据循环。
工具拥有了项目。 供应商和内部平台团队可以提供能力,但业务负责人必须拥有基准数据、验收标准和结果。
自动化在操作规程之前到来。 触发条件会放大已有的一切,包括模糊性和错误权限。先手动运行,通过影子模式,再自动化。
基准数据在上线后才被重建。 记忆倾向于新流程。在第一次试点运行之前,记录当前的工作量、工作投入、缺陷和周期时间。
审核流于形式。 审核员批准一切,因为他们没有检查清单,或者看不到数据来源。赋予他们拒绝权,并衡量他们的编辑内容。
未知情况被转化为自信的文字表述。 要求提供证据链接,标记缺失数据,并将未解决的案例路由给责任人。一个正确的"未知"是一次成功的管控。
旧工作流从未终止。 员工完成手动流程,同时在此之上检查 AI 版本。采用率指标和明确的退役决策会揭示这一隐性成本。
常见问题
什么是 AI 转型?
AI 转型是对业务工作流、决策、角色和管控机制的重新设计,使 AI 能够为可衡量的运营结果做出贡献。对于精简团队而言,它从一个有责任人的生产工作流开始,仅在质量、风险、采用率和经济效益得到验证后才进行扩展。
AI 的 7 个阶段是什么?
AI 本身并没有通用的七阶段模型。对于组织 AI 转型而言,一个实用的七阶段序列是:梳理工作流、选定一个用例、建立当前流程基准、撰写操作契约、以影子模式运行、在人工审核下发布,然后扩展、修订或停止。
如何在业务中实施 AI?
选择一个具有可验证输出的反复出现的工作流。建立其当前成本和质量的基准,限制数据访问和权限,定义失败阈值,在人工流程旁边进行测试,然后在有明确责任人的情况下投入生产。更广泛的 AI 采用应以该工作流的证据为依据。
什么是 AI 数字化转型?
AI 数字化转型是指将 AI 驱动的判断、生成或预测能力添加到已经数字化的流程中。数字系统使数据和流程变得可访问;AI 则改变了其中决策和工作的执行方式。这带来了可变的输出、新的审核工作,以及对明确证据和风险管控的需求。
第一步很小:为一个反复出现的工作流命名,明确其责任人、输出,以及系统绝对不能单独执行的操作。Zero 的以结果为先的运营模型通过连接式执行、可复用工作流、独立触发条件和权限管控支持这一路径。转型的主导权,始终属于执行工作的团队。





