从AI重度用户到AI领导者：企业AI champion体系搭建指南

每个组织里都有这样一群人：他们第一时间试用新模型、新产品，主动分享什么有效、什么值得跟进。在很多企业里，这个角色已经被正式化为"AI champion"或"AI大使"计划。据AI Daily Brief播客中Nufar的分享，在她接触过的所有企业AI转型实践中，建立内部champion网络是ROI最高的举措之一——"它从不失败"。

但一个现实困境是：团队里某个成员发现了绝佳的AI用法，展示给两三个人之后，往往就止步于此，无法扩散为整个团队的实践。本文基于Nufar在数十家企业的一线经验，系统拆解AI champion的角色定义、网络搭建方法和核心能力要求。

什么是AI champion：三种角色光谱

Nufar将AI champion定义为：团队中负责推动AI采用和价值实现的人。她用"peer plus one"来形容这个角色——他们做团队的本职工作，但在AI方面领先一步，是团队里最热衷也最有能力使用AI的人。

这个角色在不同公司差异很大，大致分布在一条光谱上：

一端是"大使"（Ambassador）。他们是团队里最好的AI用户，主要职责是驱动采用、展示用例、培训同事，同时能准确传达团队需要什么工具和内部构建。他们的工作方式是"展示我能做什么"，聚焦于同事日常工作中的真实场景，而非理论。

另一端是"内部FDE"（Forward Deployed Engineer）。Nufar将其定义为"坐在业务团队内部的职业构建者"，能从想法一路做到生产上线，涵盖规划、构建和价值实现全流程。其中不少人来自软件和AI背景，但也有大量主题专家通过职业转型，借助当下强大的工具为自己的团队构建解决方案。

中间地带是"大使-构建者"。这是多数公司实际落地的位置——他们为自己和直属团队构建，有明确的能力边界。超出边界时，他们扮演产品经理角色，收集需求并交给供应商或内部团队。

FDE（Forward Deployed Engineer，前置部署工程师） 这一概念最早由Palantir等数据平台公司推广，指被派驻到客户或业务团队内部、直接面对真实业务问题并负责端到端交付的工程师。与传统后台研发不同，FDE不依赖完整的产品需求文档，而是深入业务现场，从问题发现、方案设计到上线运维全程负责，兼具工程能力和业务理解力。在企业AI场景中，"内部FDE"意味着这个人不只是演示AI工具，而是能真正把业务痛点转化为可运行的解决方案，并对最终价值负责。这也是为什么Nufar强调内部FDE需要覆盖规划、构建和价值实现全流程——他们的核心价值不在于技术深度，而在于缩短从业务问题到可用方案之间的距离。

企业侧：搭建champion网络的四个阶段

企业在考虑AI champion计划时，往往会同时面对四个核心问题：谁有构建权限？对普通用户和champion各自的期望是什么？AI如何从一线向上传播？champion如何与中央团队和供应商协作？

阶段一：明确目标与定位

Nufar建议首先回答：建立champion网络到底要达成什么？ 很多公司在这个问题上卡壳。接下来要确定champion在光谱上的位置——是纯粹的大使，还是全栈构建者？

她举了一个例子：某公司在反复思考后意识到，他们真正需要的是让champion成为"漏斗"，把一线用例带给对日常现实"视而不见"的中央团队。这与培养全栈构建者是截然不同的角色定位、培训方案和期望管理。

阶段二：提名合适的人

好的champion需要三个核心信号：没人要求就用AI、同事已经主动来请教、管理者愿意给他们时间为他人做AI工作。第三个条件往往是提名失败的高发区。

此外还需要：无需职权即可影响他人的能力、对业务的深入理解、主动性和好奇心。Nufar特别提醒：champion角色本身就是一种巨大的职业福利，会让这个人在市场上变得极具吸引力，所以要提名真正值得的人。

她列出了四类常见的提名错误：高管自我提名（高管应进入AI委员会而非做champion）、提名最忙的人（没有带宽）、把champion当奖励发放（AI能力不够）、提名刚入职的新人（不了解业务）。

AI委员会（AI Council） 是企业AI治理中常见的一种跨职能决策机构，通常由首席AI官、CTO、合规负责人、业务线代表等组成，负责制定AI战略优先级、审批高风险用例、分配预算和资源、协调各部门间的AI协作。它与champion网络形成互补关系：champion自下而上发现和推动用例，AI委员会自上而下制定方向、边界和资源支持。Nufar之所以建议高管进入AI委员会而非担任champion，是因为高管的核心价值在于决策、资源调配和组织协调，而不是亲自构建或演示AI方案。让高管做champion，既浪费了他们的决策杠杆，也可能因为时间碎片化导致角色履行不到位，反而削弱整个网络的可信度。

阶段三：培训与认证

培训的核心原则是"用他们自己的工作来训练"。Nufar最喜欢的测试很简单：每个champion在培训结束时，拿一个团队的真实用例，展示自己如何构建或推动了它。 能做到就准备好了，做不到就还需要打磨。

培训通常以kickoff或认证仪式收尾，大家充满热情。但真正的考验在认证之后的"第二天"。

阶段四：认证之后的持续运营

Nufar指出，champion计划成败的最大预测因素，就是认证之后的第二天发生了什么。 成功的网络需要两类sponsor：一类来自HR或people团队，负责社区运营和人员侧；另一类懂AI，与首席AI官紧密协作，设定优先级并打通所有champion依赖的内部团队。

她见过的最成功案例中，一家公司由L&D专家和AI专家组成"动态双人组"，持续掌握champion的现状、需求和行业动态。而在每一个"课程很好但从未转化为业务价值"的公司里，缺失的环节都是持续性——没有人负责确保champion被有效使用并持续学习。

一个容易被忽视的动作是：与champion的管理者做一次简短沟通，解释champion知道什么、被期望做什么、如何有效利用他们。很多优秀champion的困境恰恰来自管理者期望不切实际或不知道如何使用他们。

最后，网络必须是活的——允许人进出，有人离开时能顺利交接给团队其他人，新人能清晰地加入。

Champion侧：从想法到生产的完整能力

即使不是官方champion，只是团队里最好的AI用户，这些能力同样适用。Nufar认为champion需要理解AI用例从想法到生产的完整旅程，分为三段：构建前（识别领域内值得解决的问题、了解公司允许的边界）、构建中（从POC到生产）、构建后（部署、价值实现和退役）。

用例识别：先问"该不该做"

Nufar观察到一个普遍现象：很多人在构建之前根本不问"我们该不该做这个"，直接就开始构建了。 需要检查的是：这个问题多久出现一次？价值多大？犯错的代价多高？

她举了一个具体例子：假设某团队每周花数小时整理客户续约摘要。大使型champion会识别这个用例、清晰描述现状成本、说明为什么可解决，然后带着一份干净的请求去找中央团队或供应商，方案就绪后确保团队真正使用并实现价值——他们出现在开端和结尾。大使-构建者会在公司允许的范围内为自己团队构建一个版本，再由其他团队接手产品化。内部FDE则可以全程包办。

技术选型：最简方案优先

当下有一种倾向是"什么都要做成agent"。Nufar的建议相反：从解决问题的最简方案开始。 有时候一个共享的prompt加文件就够用，有时候一个skill是最精简的方式，有时候是自动化流程，只有充分理由时才需要构建完整的agent。

Agent（智能体） 在AI语境中，通常指能够自主感知环境、规划步骤、调用工具并执行多步任务以达成目标的系统，区别于单轮问答或固定流程的自动化脚本。构建一个完整agent往往需要定义工具接口、设计规划逻辑、处理错误恢复、配置记忆和状态管理等，复杂度和维护成本远高于prompt或skill。Skill 则通常指封装好的、可复用的提示词模板或轻量工作流，适合边界清晰、步骤固定的任务。Nufar"最简方案优先"的建议背后是一个务实的权衡：多数业务问题并不需要agent的自主性，一个共享prompt、一个skill或一条自动化流程就能解决，且更容易被非技术同事理解和维护。过早引入agent不仅增加构建负担，还会放大安全和护栏风险。

构建前的核心属性定义

在开始构建前，champion需要写下类似需求文档的核心属性：为谁而做（"所有人"不是好答案——为所有人设计等于没人为之设计）、人们会怎么用（确保它真的会被用，而不是一个没人记得URL的"炫酷vibe coding应用"）、它绝对不能做什么（具体而详细的护栏）、谁检查输出（人在回路中的判断点在哪里）、如何知道它有效（尽早配置测试用例）。

Nufar特别指出，从"绝对不能做什么"开始思考，往往能更清晰地定义"应该做什么"。配置评测用例的过程本身就会暴露边缘情况和评估难度，有时甚至能在构建之前就"杀死"一个无法保证质量的项目。

人在回路（Human-in-the-loop） 是AI系统设计中的一项关键原则，指在自动化流程中保留人类判断和干预的节点，而不是让系统完全自主决策。在企业场景中，人在回路通常体现为：AI生成初稿或建议，由人工审核后再对外使用；或在高风险操作前设置人工确认步骤。Nufar强调"谁检查输出"，本质上是在问：这个AI方案的错误代价由谁承担、在哪个环节被拦截。与之相关的还有护栏（Guardrail），即明确限制AI不能做什么的规则和机制，比如禁止访问某些数据、禁止自动发送对外邮件、禁止做出财务承诺等。从"绝对不能做什么"倒推"应该做什么"，是一种以风险为锚的设计思路，能帮助团队在构建前就识别出无法保证质量或合规的用例，避免投入后才发现方向错误。

为什么这个角色越来越关键

Nufar和主持人Nathaniel都认为，随着agentic coding工具的普及，越来越多非技术背景的人开始用代码解决工作中的问题，这既释放了巨大能量，也带来了安全、护栏和agent"逃逸"等新挑战。

与其因为担心非专业构建者而叫停，不如做好enablement和基础设施，甚至培训更多主题专家——因为他们会聚焦正确的用例。这个角色不是在消失，而是在变得比以往更加关键。

Nathaniel补充了一个重要观点：AI champions的很多playbook并不像其他AI知识那样转瞬即逝。工具每季度都在变，但有些东西恒定不变——你仍然需要合适的人有足够的时间去做这件事，仍然需要决定他们站在大使还是构建者的位置并写下来，仍然需要有人拥有"第二天"。

Nufar最后说："如果你是champion本人，这是公司里最好的座位之一。你看到团队的问题，与团队协作或亲自构建，你了解了构建道路的开头和结尾，而大多数人只知道中间那一段。"