AI 实施高管指南
原文:An Executive’s Guide to Implementing AI 作者:Natalia Quintero 日期:2026-06-01
如果你只能记住一件事,那就是这个循环:
亲自上手 → 指派 AI 冠军 → 选定一个痛苦流程 → 打磨到 95% → 放大有效成果
亲自上手。 在指挥别人使用之前,自己先用。弄清楚你的公司能访问什么、政策允许什么、实际摩擦在哪里。如果你过去 30 天里没亲手用 AI 搭过东西,就从这里开始。
指派 AI 冠军。 挑选有余力的执行者。给他们受保护的时间(每月至少两天)、明确的任务授权和能力支持。他们的责任,是把流程从“演示里跑得通”推进到“生产环境里跑得通”。
选定一个痛苦流程。 让你的冠军们自己挑。他们最清楚什么工作最繁琐、最值得自动化。从高频、数据丰富、收窄到一周内可测的事情入手。你不需要做完整的流程盘点。
打磨到 95%。 80% 的自动化是演示。真正的自动化需要标杆示例、结构化评估(evals)、人工审核节点,以及一个在模型更新时负责维护的明确责任人。当你手上有一个可靠运行 90-95% 的技能时,你才真正从 AI 中获取了价值。
放大有效成果。 这是冠军角色的关键所在。做成果展示,用经过验证的流程培训相邻团队。砍掉没用的,放大有用的。一个看得见的胜利,就能在整个组织里制造拉力。
本指南将把这个循环展开成一个面向高管的 60 天计划,附带检查清单和评估标准,均源于 Every 与数十家顶尖公司的咨询实践。
AI 实施高管指南
今年早些时候,我坐在一家健康科技公司首席运营官对面,听她说出了一个许多高管心中有、却鲜有人说出口的问题。
“我们的基层员工很可能天生就更熟悉这项技术,”她说,“而我们得确保自己不被抛下。说这话让我觉得自己像只恐龙,但这是事实。”
类似的坦白在我们的高管培训课上屡见不鲜:即便正在主导 AI 相关的规划决策,领导者们自己并没有直接用 AI 处理过复杂任务。他们知道自己“应该”花更多时间学习工具,但就是迟迟没有真正投入。这完全可以理解——高管实在太忙了。但我们在课程中反复观察到的是:没有亲手摸过的领导者,对 AI 的实际机遇与挑战其实并没有真正的体感。那位健康科技高管的坦承,开启了一场关键的对话:一套协调一致的全公司 AI 实施方法,必须从高管自身的 AI 熟练度开始——但也不能止步于此。
这是我们在每一项咨询业务中都看到的现象。过去两年间,我们培训了数千人,来自多家公司——包括《纽约时报》、Ripple、Headway 和 Thumbtack,以及管理着超千亿美元资产的投资机构。我们做了工作坊,也观察了六个月后的变化。AI 在工作场所的使用如今已非常普及,但要真正建立起能兑现财务收益的组织能力,完全是另一回事。
麦肯锡 <a href=“https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai” rel=“noopener noreferrer” target=“_blank”>将 AI 高绩效者 定义为那些既从 AI 中获得了显著价值,又实现了超 5% 息税前利润影响的企业。这些公司从根本上重新设计工作流程的可能性是其他公司的近三倍,但仍是少数——在被调研的近 2000 家企业中,仅有 6% 达到了成功标准。
当然,没有任何外部公司能替你把 AI 植入你的企业。但我们能提供一套建设持久组织能力的行动手册:领导者亲自使用工具、赋能合适的冠军、一个痛苦流程一个痛苦流程地,在团队中建立起对“优秀是什么样子”的肌肉记忆。读完本指南,你将再也没有借口不成为那 6% 中的一员。
驾驭 AI 采纳的三波浪潮
短短三年间,AI 已经从表演花活,进化到能完成一整天的人类工作量。
2022 年,模型只能回答基础问题——那大约是四秒钟的人类工作。到 2023 年中,GPT-4 已能处理约六分钟的人类工作。到 2024 年底,o1-preview 开始攻克小时级的任务。而到 2025 年底,Claude Opus 跨入了 10 小时以上人类任务的门槛。这一进展是指数级的,也一次次地改写了“AI 实施”对企业的含义。
以下是 ChatGPT 发布以来 AI 采纳的三个大致阶段:
- 许可证阶段(2022 年底至 2024 年初): 公司购买 ChatGPT 企业版、Claude 和微软 Copilot 的许可证,希望能提升员工生产力。部分员工在使用这些工具撰写邮件、总结文档和研究资料时发现了价值,但收益参差不齐,且都是个人层面的。
- 提示词阶段(2024 年初至 2025 年中): 公司开设提示词培训、建内部提示词库、编写资源文档,并鼓励团队用自定义 GPT 做实验。这些举措确实让 AI 不再只是个人玩玩,但很少带来持久的组织变革——自定义 GPT 和提示词库往往没有维护者,也没有评估结果的方法。
- 实施阶段(2025 年中至今): 继 2025 年 2 月以研究预览形式推出之后,Claude Code 推动了企业采纳进入当前新阶段:从基于聊天的 AI 和提示词库,转向可被配置为在定义约束下完成更长时间、多步骤任务的 AI 智能体(AI agents)。提示词库正在让位于技能库(skills libraries):即可复用的工作流,配有指令、示例、参考资料、脚本、评估标准和明确的责任人。突然间,非技术人员也可以在 Claude Cowork 这类工具中搭出复杂的自动化流程;AI 实施不再只是工程师的专属。
该图表将每次模型发布与其可可靠完成的软件任务复杂度对应,按同样任务所需的人类时间衡量。(来源:METR,一家独立研究机构,评估 AI 模型在实际任务上的能力。)
这张 METR 的图表展示了技术已经走了多远,但我们看到的是,许多正在实施 AI 的组织并没能跟上这场剧变。AI 采纳的瓶颈已经从模型能力转移到了组织能力。在我们这边,我们已经根本上改造了培训内容,以支持高管和团队迎接这个新时代。例如,我们已经把提示词相关的培训课重新设计成搭建智能体、技能和可被维护、可被测试的工作流的动手工作坊。我们正在与高管一起建设这种组织肌肉,把原始模型能力转化为可靠、可复现的流程。
我们知道这正在发挥作用。我们合作过的一家投资机构,现在通过 Copilot Cowork 在组织内运行着 100 多个智能体。在一家电商客户那里,Claude 的 Opus 模型完成了此前需要一周时间的财务差异分析。在与我们合作之后,一家私募股权公司决定聘请全职 AI 冠军来持续推进他们的 AI 实施进程。
以下是我们总结的、同样能带你和你公司迈入下一个时代的五个步骤:
第一步:亲自上手
AI 实施始于高管自身的熟练度。这并不意味着高管得变成日常的 AI 构建者。重要的是,你必须在工具上花足够多的时间,去理解你要求团队做的事到底意味着什么。在我们合作的一家大型媒体与数据公司里,我们看到,负责评审内部 AI 项目的高管们自己从未亲手搭建过任何东西。他们此前所有的 AI 项目都失败了。他们很容易去设想一个人工智能体能为业务做什么。但要真正搞清楚 AI 搭建到底涉及哪些东西,则要难得多:智能体需要什么数据、能接入哪些系统、可能在哪个环节出错、需要多少人工审核,以及在第一个演示跑通之后,由谁来持续维护它。
亲手去做
在我们的高管培训课里,我们推动领导者超越仅仅把 AI 当作聊天界面,要求他们亲自搭建一个自定义技能、智能体或自动化流程。这一练习会迅速暴露所有决定 AI 能否为特定工作流创造价值的实际约束。
一旦你作为高管开始自己动手搭建,讨论就会从空洞的热情转向实际的问题:哪些连接器需要开通,哪些数据可以访问,现有 IT 政策是否与公司的 AI 雄心匹配。
理解 IT 与安全团队的角色和视角,是 AI 熟练度的关键组成部分。目标不是绕过护栏;受监管的公司完全可能有充分的理由限制文件上传、阻止某些工具或限定哪些数据可以传入模型。但作为领导者,你需要与 IT 和安全团队保持持续对话,摸清有哪些工具可用、它们如何连接、哪些数据可以在哪里流动,以及公司正在做出怎样的权衡。如果你从未在这些约束下做过搭建,你可能会把由此导致的低采纳率误读为员工的抵触情绪,而不是访问权限的问题。
定义你的卓越标准
亲手实操还会暴露一件事:领导者到底能不能说清楚“好工作”长什么样。在一次高管培训中,我们与一位需要为董事会准备指标的领导者合作。这项工作需要从 Snowflake 中提取数据,而且每个季度要花很多个小时。
表面上,这看起来是 AI 技能的完美应用场景。但当团队开始搭建时,另一个问题浮出水面:这位高管无法清晰表达“优秀”的标准是什么。
一个技能(skill)是一组可复用的能力,用来定义智能体如何执行任务;要可靠地复现一个工作流,它需要指令、示例、参考资料,以及一张关于什么是好输出、什么是坏输出的清晰图景。当然,对人的要求也是一样的。如果你无法向你的幕僚长解释清楚你的卓越标准,那你肯定也很难向一个 AI 系统解释清楚。
这就是为什么作为领导者,你比自己想象的更有条件用好 AI。高绩效的管理者已经懂得如何定方向、分资源、立标准和判断一项工作是否足够好。高管不必拥有所有答案。但你确实需要足够的 AI 熟练度,去提出那些能帮你决定 AI 在你公司战略中应处什么位置的问题:
- AI 在我们的公司里能“看见”什么?
- 它能做什么?
- 约束条件在哪里?
- 哪些流程痛苦到值得优先处理?
- 谁来维护我们构建的系统?
- 我们怎么知道它们是否在起作用?
第二步:指派 AI 冠军
一旦你理解了 AI 能做什么、不能做什么,高管的下一步就是将项目的所有权指派给具体的人——也就是我们所说的 AI 冠军(AI champions)。
冠军负责将一个项目从最初的想法带到达成:他们对工作流进行实验和迭代,教会别人成功的样子,并在整个组织内为 AI 实施争取支持。他们的工作是决定什么该做、什么该维护、什么该改进、什么该砍掉。
冠军通常具备三种特质:好奇心、以人为本的思维模式,以及做这件事的权力和时间。作为领导者,你的工作就是选出最合适的人。在我们的咨询工作中,我们会训练这些冠军,帮助他们推动各自部门的 AI 采纳。
找到会提问的人
AI 冠军不需要是组织里技术最强的人。他们不必是工程师,也不必有多年的 AI 使用经验。
但他们必须是充满好奇心的人。优秀的冠军会不停地问问题,追问流程是如何运作的,并渴望理解不同任务和职能的“卓越是什么样的”。
真正有好奇心的人,也往往更愿意向同事和 AI 寻求帮助——我们相信这种能力将定义下一个工作时代。成功的 AI 冠军把 AI 当作一个合作伙伴,而不是一个一次性的魔法按钮。而 AI 也更偏爱那些愿意承认自己不知道什么、能拆解问题、提出更好问题、持续迭代直到得出有用成果的人。
优秀的冠军关心人
最优秀的 AI 冠军也深知,AI 实施归根结底是一个“人”的问题——而且他们在意自己的同事。
AI 冠军要搭建和维护工具,但他们同样要帮助同事改变工作方式。要做好这件事,冠军需要理解所在职能部门的痛点。他们需要知道哪些任务最消耗时间、哪些流程最让人抓狂、哪些交接环节最容易产生错误。这就是为什么最强的冠军往往是那个最贴近所解决问题流程的人——例如,一个清楚知道活动分析卡在哪里的营销人员,或一个懂工单分类的客户支持主管。
他们也需要是出色的沟通者。当一个技能或工作流准备好推广时,冠军必须向团队其他成员解释清楚,收集反馈,并帮助大家理解如何使用它。
给冠军时间和权力
冠军需要被授予做出决策的权力,以及能够落地执行的时间。这正是许多 AI 项目失败的地方。高管们找出有热情的人,叫他们在日常工作的“额外”时间帮忙搞 AI。结果就是:这项工作被挤到晚上,在忙季被搁置,有时干脆直接放弃。如果把企业 AI 实施定位成一个非正式兼职项目,那是注定行不通的。
冠军需要的是受保护的时间——根据我们的经验,每个月至少两天——和一份明确的任务授权。他们应该对自己领域内的少量工作流负责,并拥有足够的权力来决定这些工作流如何记录文档、如何测试和如何维护。当他们需要 IT、安全、领导层或其他部门的支持时,也应该有一个清晰的上报路径。
当然,具体架构会有所不同。大公司可能需要一种“大使模型”,冠军分布在各主要职能部门。中型公司则可能每个团队需要一两名部门冠军。对私募股权或控股公司来说,更有效的模式可能是设一个能在公司和被投企业间流动的专职研究员。
简而言之,一个 AI 冠军的职责应包括:
- 在自己领域内维护 1-3 条工作流
- 维护这些工作流的文档
- 搭建或管理评估集
- 收集团队反馈
- 在工具、模型或流程变化时更新技能
- 报告节省的时间、提升的质量或减少的错误
- 拥有做这些事情的受保护时间
第三步:选定一个痛苦流程
当你有冠军之后,就是时候选出要首先攻克的工作流了。大多数高管恰恰在这里犯下一个让整个进程脱轨的错误:他们从公司里最大、最显眼的问题入手。
我们看到过高管想自动化董事会汇报材料的制作、想重建项目管理体系,或者想创建一个能解决跨多个系统、牵扯多部门的棘手智能体。但即使是有经验的 AI 搭建者,也常常犯下一开始摊子太大这个错误。在 Every 内部,我们团队最早的本能之一,就是为咨询业务自动化项目管理——那是一个宽泛、混乱、涉及多人、多系统和多方决策的工作流。
但 AI 实施更有效的方式,恰恰是克制住一口气吃掉“整个身体”的冲动。相反,从工作流的一条动脉开始——这个拼图中一个足够痛苦但又可以收窄的部分,在建立信任之前先对它进行测试和改进,然后再从那里往外扩展。好的候选工作流往往并不光鲜——比如给客服工单分类,或总结供应商更新——但它们足够高频,能成为非常有价值的实验场。如果你的冠军选对了,你完全可以信赖他们去找到那个最痛的切入点。他们自己可能就有亲身体验。
要在一份不错的候选池里锁定最优工作流,可按以下标准打分:
频率: 这件事是每天、每周还是每月发生?
痛苦程度: 它消耗多少时间,制造多少挫败感或错误?
数据可用性: 所需信息是否已经数字化且可访问?
风险: 如果 AI 搞错了,会怎样?
所有权: 目前是谁在手工做这件事?
评估清晰度: 我们能否判断输出是否正确?
维护负担: 这个工作流需要多久更新一次?
第四步:打磨到 95%
一旦选定了你的第一个工作流(或者说你的冠军在你认可下选定了它),就是时候开始搭建了。无论它是一个对前 20 张工单分类准确的客服流程,还是一个捕捉到一次涨价或新安全要求的供应商更新摘要,从零到“有点东西”的跃迁,确实会让人感到如魔法般神奇。
但通常的情况是,他们只搭建出了一个演示(demo),而不是一个可以真正推广的可用产品。把这个 demo 变成一个团队可以信赖的工具——从 60% 推进到 95%——需要多得多的工作:示例、评估、反馈、人工审核和维护。而冠军和高管们必须协同努力才能达成这一点。
设定产品标准
高管在这里的角色是充当“品味制定者”:设定一个有用工作流的标准,明确人工审核应安插在哪个环节,并决定公司愿意为这个成果投入多少时间。然后,冠军们用这些标准去搭建。他们收集示例和评估指标来测试工作流输出,并收集反馈来打磨最终产品。
“自动化”是个谬误
打磨到 95% 也意味着,要接受这样一个现实:任何 AI 工作流都是一个永无止境的过程。模型会更新。公司流程会变化。团队标准会改变。新的边缘案例会出现。上个月还管用的技能,这个月可能就需要调整。这就是评估——一种结构化测试 AI 是否在正确完成工作的方法——该登场的地方。
不妨把 AI 智能体想象成一个你正在上手培训的员工,而不是一台会永远自己运转的机器。你要给它指令、给它看例子、纠正它的错误、澄清卓越的标准。随着时间推移,它会越来越有用,但前提是它被管理得当。
对每个工作流,创建一个简单的表格,并回答以下问题:
- 这个工作流应该用什么样的真实示例来测试?
- AI 智能体当前的输出是什么?
- 期望的输出是什么?
- 它在犯什么错误?
- 错误的原因是什么?
- 是否需要修改提示词或技能?
- 重新测试的结果如何?
- 是否需要人工审核?
- 谁负责维护这个工作流?
- 工具的审核频率是多少?
第五步:放大有效成果
下一步听起来很简单,但你会惊讶于有多少高管在这上面犯错,那就是:只放大有效的成果。这从资源配置角度很重要,对内部推广也同样关键。虽然许多高管的出发点是全公司范围的指令——“大家都要开始用 AI”——但更好的路径,是通过选出对的冠军、对的工作流、对的标准来培育一个看得见的胜利,并从这个胜利开始建设。
当一个团队体验到 AI 工作流真正解决了某个痛苦的实际问题,AI 就不再是一个抽象的生产力承诺,而成为一个实用的解决方案。这种体验会在整个组织内制造拉力,其他团队会开始主动问:我们这里能用它解决什么?
但“放大”并不意味着把同一个工作流复制得到处都是。大多数工作流是部门特定的。比如,对财务管用的东西未必对市场部管用,对客服管用的东西也不见得适合产品团队。当你手里有了一个成功案例,作为领导者,你的职责是决定它应该继续留在部门内使用、升级为共享技能,还是被停用裁撤。
但无论如何,你的第一个成功工作流都可以为公司留下可复用的组件:它建立起了如何描述流程、如何记录标准、如何定义好输出的一套实践。这些做法是可以被任何团队采用的。
在放大一个工作流之前,先问:
- 它解决了一个真实的痛点吗?
- 它是否经过真实案例的测试?
- 是否有明确的责任人?
- 是否有审核流程?
- 风险是否被充分理解?
- 团队是否能解释何时以及如何使用它?
- 是否有持续改进的反馈闭环?
- 是应该升级为共享技能、保留在团队内部,还是直接砍掉?
一个由领导者驱动的 AI 实施 60 天计划
第 1–2 周:亲自上手
作为高管,你应当投入时间去亲手用 AI 工具搭建,并摸清公司的访问权限、数据连接器和安全约束。把 IT 和安全团队拉到会议室,问问题,以便你理解 AI 实施与安全之间的权衡取舍。
第 3–4 周:指派冠军并选定工作流
在每个相关职能部门选出冠军,给他们清晰的任务授权和受保护的时间,要求他们识别出一份备选的痛点工作流清单。
第 5–7 周:搭建与评估
与你的冠军们协作,选定一个工作流作为切入点,搭建为一个技能、智能体或自动化流程:定义好输出、建立评估集、测试工作流并识别它的错误模式。
第 8–9 周:放大或砍掉
如果工作流有效,就培训团队其他人使用它。然后指导冠军们为相邻团队做一次成果展示,以帮助决定这个工作流是应该成为共享技能库的一部分,还是留在部门内使用。最终拍板是放大还是叫停,然后转向下一个工作流。
到 60 天结束时,你不太可能已经改造了整家公司。但你会拥有一些极其宝贵的东西:至少一个由训练有素的冠军搭建出来的可靠工作流、一个已经接受它的团队,以及一套可重复的、用于放大未来 AI 工作的流程。(你会惊讶于这有多罕见。大多数公司手上有一堆提示词、工具和自动化,但它们并没有真正解决问题。)
我们学到的事
成功的 AI 实施没有简单的捷径。没有哪个单一工具或模型能解决每个公司的问题,也没有任何外部公司能替你完成 AI 实施。
从带领我们咨询业务的经历中,我能深刻体会走完这套实施流程需要投入多少时间与承诺。今年一月,我花了超 100 小时与我们的内部 AI 冠军——一位前出工程师(FDE)紧密合作,来定义我们自己的 AI 采纳路径。现在,我花 10-15% 的时间维护现有技能、给智能体和这位前出工程师提供反馈,以及决定在哪里应用 AI、团队应当为这些工具分配多少时间。
我们如今拥有了一套业务部门真正依赖的技能库,以及一个能顶一个全职员工工作量的智能体,承担着项目管理、销售运营和交付的工作。对我们来说,这笔投资是值得的。
前面提到的那家健康科技公司,也亲身验证了这一点。我们刚开始与他们合作时,他们还在摸索如何使用 Claude Code。而如今,这家公司正在构建一套为自己员工工作方式量身定制的内部 AI 基础设施。他们正是通过我们的五步法,建立起了组织能力,走到了这一步。
作为高管,带头建设这种系统是你的职责所在。现在你已经拥有了启动所需的一切,所以是时候了:去学习工具,去赋能对的冠军,去识别对的痛点,以及——最重要的——去动手搭建。
核心启示: AI 采纳的瓶颈已从模型能力转移到组织能力;高管的亲身实操、为执行者赋权与护时、以及用“窄而痛”的流程打透 95% 再放大的循环,是企业从 6% 的 AI 高绩效阵营中胜出的唯一可重复路径。
An Executive’s Guide to Implementing AI 的发芽报告
材料核心
这篇指南提出,AI实施的瓶颈已从模型能力转向组织能力,并给出了一个五步循环:高管亲自上手建立认知、指派有时间的AI推动者、选择一个痛点工作流、构建到95%可靠度、最后规模化已验证的成功。核心理念是拒绝空中楼阁式的AI战略,转而用“一个痛苦工作流”的务实路径来积累组织肌肉。
发芽 01:当“恐龙高管”成为瓶颈——认知鸿沟不是态度问题,是系统失灵
种子
材料开篇那位健康科技公司COO的坦白——“我感觉自己像只恐龙”——揭示了一个远比“高管不学习”更深刻的结构性问题:组织层级天然地将决策权与操作流分离。高管负责制定AI战略,却不碰工具;基层员工精通工具,却没有资源与权限将其制度化。这并非个人态度问题,而是一个经典的“知识-实践缺口”系统失灵。解决它需要的不是自上而下的学习动员令,而是一个能让认知从操作层反向渗透到决策层的制度设计。
这个问题在技术管理史上早有先例。1980年代,美国制造业在面对日本精益生产的挑战时,曾大规模引入统计过程控制等质量工具。MIT的研究者在《改变世界的机器》一书中发现了一个规律:那些转型最成功的工厂,其高管团队都有一条不成文的规矩——必须亲自参与一个完整的“改善周”,站在生产线旁重新设计一个工位。福特公司在推行六西格玛时,要求所有高级副总裁通过绿带认证,亲自完成两个改进项目。这种“强制返厂进修”的逻辑,不是为了把高管变成一线工人,而是为了让他们在制定质量标准时,能够理解一个指标从设计到落地之间到底要经历多少微小的判断和博弈。
回到AI实施的语境,材料中描述的高管“构建技能”的练习,本质上就是现代版的“改善周”。那位无法为董事会报告定义“优秀”标准的高管,暴露出的问题是只有战略意图,没有操作定义。而这恰恰是AI系统最苛刻的要求——它不像人类下属那样能“领会领导意图”,它需要的是精确到边界条件的标准。如果高管自己说不清“好”长什么样,那就不是AI不行,而是组织原本就没有把自己的隐性知识显性化。在这个意义上,AI实施非但不是技术的入侵,反而成了一面照出组织管理真实水平的镜子。
Aha 瞬间
“AI不会取代高管,但会无情地曝光那些从未真正定义过‘好工作长什么样’的领导者。”
发芽 02:95%的暴力——为什么把可靠性从80%提到95%是AI实施中最残酷的认知战
种子
材料提出了一个在AI实施讨论中极为罕见但极其诚实的主张:“自动化到80%是演示,真正的自动化需要达到90-95%的可靠度。”这15个百分点的差距,不是渐进式的优化,而是一次从“玩具”到“工具”的认知跃迁。它要求组织接受一个残酷的现实:AI实施中最耗费精力的事情,不是做出第一版令人惊艳的输出,而是一遍遍地处理那些无聊的、重复的、丑陋的边界案例。
这种现象在软件工程史上有深刻的对应物。1975年,IBM的软件工程师弗雷德·布鲁克斯在经典著作《人月神话》中写下了一句至今仍在编程界流传的格言:“构建一个软件系统花费的时间中,三分之一用于计划,六分之一用于编码,一半用于测试和修复缺陷。”这个比例后来被无数项目验证过——最容易的部分是让程序“动起来”,最困难的部分是让它在所有条件下都不出错。微软Windows操作系统的开发史就是一个例证:每一个版本的发布,绝大多数开发资源并非投入在用户可见的新功能上,而是投在驱动兼容性、边缘硬件配置和难以复现的崩溃故障上。
AI工作流的构建遵循同样的逻辑。材料里建议的评估表——每次测试的真实输出是什么、期望输出是什么、错误原因是什么、是否需要修改提示或技能——本质上就是一套AI时代的回归测试框架。当模型更新时、当公司流程变化时、当新的边缘案例出现时,这个被驯服到95%可靠度的技能会不断被重新测试。这意味着,选择AI实施意味着选择永久的维护承诺。那些只看到“一天自动化一周工作”的煽动性标题的组织,往往忽略了那“一周工作”背后需要另外一周来构建评估集、做人工审查、处理模型漂移。
更深一层看,95%这个数字本身就是一场组织谈判。对于客服调侃分类,95%可能意味着每20个用户中有一个被错误地冷落或激怒,这个代价管理层是否愿意承担?对于财务分析,95%可能意味着一个重要数字每季度被错误计算一次,法律团队和审计师是否能接受这种风险水平?材料中要求高管回答“出错会怎样”这个问题,实际上是在要求他们把隐藏在流程后面的人工风险暴露到AI的聚光灯下。对于很多组织来说,人类犯错是“意外”,而AI犯错更容易被感知为“事故”——这种不对称的问责标准,往往是被低估的AI实施障碍。
Aha 瞬间
“把AI从80分提升到95分,不是在优化一个工具,而是在为整个组织重新分配‘谁将承担错误’的痛苦。”
发芽 03:AI推动者的真正角色——不是技术先锋,而是组织记忆的制度化容器
种子
材料定义AI推动者时不走寻常路:他们不必是工程师,不必使用AI多年,甚至不必是最懂技术的人。他们需要三个品质:好奇心、以人为中心的思维,以及时间和权限。这种定义暗示着一个被严重低估的真相——企业AI采纳的主要障碍不是技术门槛,而是没有人去承担“把好想法变成有人维护的日常流程”所需要的组织工作。推动者角色真正的功能,是成为一块足够能承载组织记忆、却又足够灵活能容纳持续变化的制度容器。
这个角色的设计在管理学上并不新鲜,但在AI领域常被遗忘。20世纪初,当“科学管理”运动席卷美国工厂时,弗雷德里克·泰勒设立的正是类似角色——其职能不是操作机器,而是观察操作、记录最佳实践、训练其他工人、持续改进流程。丰田后来把这个逻辑升级为“主任工程师”制度,每个整车开发项目都有一位具备跨职能协调权的技术领袖,其权力不来自职级,而来自对产品全貌的深层理解和长期的跨部门信任。
AI推动者的角色承担了类似的制度功能。材料强调推动者需要“记录文档”“维护评估集”“收集反馈”“在工具、模型或流程变化时更新技能”——这些行为表面上看是项目管理,本质上却是在为组织创建一种新的资产类别:可复用、可测试、可移交、可扩展的工作流能力。这种资产不同于传统的软件代码,因为它包含的不是计算机指令,而是对“这个任务到底是怎么回事”的描述、示范和评审标准。当一位AI推动者离职时,其真正危险的损失不是对工具的热悉,而是那些尚未写成评估集的隐性判断——比如“财务分析的第三个数字在夏季波动较大应暂时忽略”这样的事。
更深层的意义在于,推动者角色的设立,实际上是组织在向自己承认一个事实:AI不是能买来即插即用的软件许可证,而是一种需要内部培养的判断力。材料中描述的“放映会”和“跨团队培训”机制,就是试图把推动者身上的个人判断转化为团队甚至公司层面的组织记忆。在这个过程中,推动者越来越像一个活的“知识翻译器”——把战术痛苦(“这个任务好烦”)翻译成可测试的技能,再把这个技能的边界和逻辑翻译给其他团队。这个角色可能最终成为数字时代最被低估的管理职位。
Aha 瞬间
“当一个AI推动者离开一家公司,他真正带走的不一定是技术秘密,而更可能是几十条尚未写入评估集的、关于‘这个工作到底该怎么干’的隐形直觉。”
你的思考空间
- 如果你的组织中根本没有“非工程师的专人负责维护某个自动化流程”的制度前例,引入AI推动者这个角色之前,你需要先解决哪些组织习惯的问题?
- 文中提到高管需要亲自试用以理解“摩擦感”,但高管的时间是组织中最稀缺的资源。如果只能选一个具体任务亲自完成,什么样的任务最能暴露AI实施的真正断层?
- 当AI工作流从95%开始随时间退化时,谁应该负责发现这种退化?谁有权决定停止使用一个曾经有效但如今不再可靠的技能?这个决策权归属本身,是否反映了公司对AI风险的实际态度?
- 在将“从80%提升到95%”的资源投入一个工作流之前,组织如何诚实地评估:人类手工完成这个任务时,真实的可靠性到底是多少?