夜雨聆风过去两年，很多企业对 AI 的投入并不少。
企业知识库建了，AI 助手上线了，Agent 平台也有了。业务部门能看到统一入口，员工能打开聊天窗口，管理层也能在汇报里看到一批 AI 应用和数字员工 Demo。
从表面上看，AI 建设已经启动了。
但真正进入业务现场时，很多企业会遇到另一种感受：Demo 很亮眼，但日常使用率不高；平台越来越完整，但业务部门仍然觉得价值有限；工具越来越多，但很多仍停留在问答、摘要、生成材料这些外围动作。
数字员工的名字越来越多，但真正进入流程、承担岗位责任、改变业务结果的并不多。
这时，团队往往会继续追问技术问题：是不是模型不够强？是不是提示词还不够好？是不是平台能力还不够完整？是不是要再接几个系统？
这些问题当然重要。但更底层的问题可能是：企业一开始就走错了路径。
一、为什么企业会自然选择“平台驱动”
企业做 AI，最容易先想到平台。这是很自然的。
因为平台看得见，入口看得见，能力清单看得见。对于管理层来说，平台是一种可管理的建设对象；对于技术团队来说，平台是一种可交付的工程对象；对于组织来说，平台也更容易被纳入预算、项目和汇报。
于是，很多企业会沿着这样的路径往前走：先建设 AI 平台，再开放给业务部门试用，再寻找一些场景，再做出几个 Demo，最后再想办法推广。
这条路径并不奇怪。传统数字化建设里，我们经常这样做：先建系统，再推动流程上线；先有工具，再让业务使用；先形成能力供给，再组织推广。
但 AI 项目和传统系统建设有一个非常大的不同：AI 的高价值场景，往往不是一开始就清楚写在需求文档里的。
它不是简单地问：“业务要什么功能？”它更像是在问：哪些流程活动重复发生？哪些地方有等待、返工、复制粘贴和反复确认？哪些判断依赖经验，但又可以被结构化表达？哪些岗位动作可以先由 AI 生成草稿，再由人确认？
这些问题，不在平台后台里，也不在会议室白板上。它们在真实业务现场。
二、平台只能提供能力，不能自动创造业务价值
平台的价值，是提供能力供给。它可以提供模型能力、知识检索能力、Agent 编排能力、权限管理能力、接口能力和日志能力。这些都很重要。
但平台本身不能自动告诉你：哪个岗位最需要数字员工，哪个流程活动最值得 AI 承接，哪类输出必须人工复核，哪个异常场景必须升级，哪个指标可以证明业务价值。
这些不是平台能力问题，而是流程事实问题、岗位责任问题和治理边界问题。
很多 AI 项目没有形成业务价值，不是因为它“不能做”，而是因为它“没有位置”。
它能回答问题，但没有进入审批流；它能生成文本，但没有改变交付物的责任链；它能总结材料，但没有嵌入岗位的日常动作；它能调用知识库，但没有承担明确的输入、输出、复核和升级机制。
所以它看起来像 AI，实际却只是一个旁路工具。旁路工具可以提升局部体验，但很难成为高质量数字员工。
因为数字员工不是一个会聊天的入口，也不是一个会生成材料的助手。真正的数字员工，必须进入流程、岗位、责任和治理体系。
它要回答的不是“我能做什么”，而是：我服务谁？我承接哪些活动？我的输入来自哪里？我的输出交给谁？什么情况下必须人工复核？什么情况下必须异常升级？用什么指标评价我的效果？
如果这些问题没有被定义清楚，平台能力再强，也很难自然长出高质量数字员工。
三、两条路径：平台驱动 vs 现场驱动
这里可以把企业 AI 落地分成两条路径。
第一条，是平台驱动路径。它的逻辑是：先建设 AI 平台，再寻找业务场景，再形成 Demo，再尝试推广。
这条路径的风险在于，它容易把 AI 建设理解成能力供给工程。团队会不断问平台有什么能力，却没有足够早地进入现场，去判断哪些真实活动值得被 AI 承接。
第二条，是现场驱动路径。它的逻辑是：先进入真实流程，拆解真实活动，识别 AI 机会，再定义数字员工，并推动它上线运营。
这条路径不是否定平台。恰恰相反，它让平台能力有了真正落点。平台提供能力，现场定义价值。
这张图想表达的核心判断很简单：数字员工的价值，不是从技术平台里长出来的，而是从真实流程活动中发现出来的。
平台驱动路径的问题，不是平台没有价值，而是它经常把价值发现这件事后置了。现场驱动路径的优势，也不是它更“快”，而是它更接近业务价值发生的地方。
四、真实流程活动，才是数字员工的起点
什么叫真实流程活动？不是制度文件里的流程节点，也不只是系统里的审批状态。
真实流程活动，是员工为了完成某个业务目标，在现场实际执行的一组动作、判断、等待、沟通、录入、复核和交接。
比如报价流程里，真正消耗时间的可能不是“生成报价单”这个节点，而是客户需求信息不完整，销售反复追问；方案工程师在多个系统里查历史案例；财务 BP 等待材料齐全后才开始测算；审批材料因为附件缺失被退回；法务对非标条款反复确认。
这些动作看起来很碎，但它们才是数字员工机会最密集的地方。
一个高质量数字员工，通常不是凭空定义出来的，而是从这些真实活动中逐步长出来的。先看见活动，再判断活动价值，再评估数据条件和风险边界，再决定它适合成为一个 Skill、一个 Agent，还是一个真正的数字员工。
如果跳过这一步，直接从“我们要做一个销售数字员工”“我们要做一个财务数字员工”“我们要做一个采购数字员工”开始，项目很容易变成概念先行：名字很完整，责任不清楚；功能很多，流程不嵌入；演示能跑，现场用不起来。
五、高质量数字员工，必须被发现、定义、上线和运营
很多企业会把数字员工理解成一个更高级的 AI 工具。
这会带来一个问题：团队会把注意力放在“它能生成什么”“它能回答什么”“它能调用什么系统”上。
但数字员工真正重要的，不只是能力，而是责任。
一个高质量数字员工，至少要具备几个要素：它有明确的岗位使命；它知道自己服务哪个对象；它有清晰的输入和输出；它知道哪些动作可以自主完成，哪些动作必须人工复核；它有异常升级路径；它有运营指标；它可以被持续迭代。
这就是为什么数字员工不能只从平台能力出发。平台可以提供能力，但不能替你定义岗位使命；模型可以生成答案，但不能替你划清责任边界；Agent 可以执行任务链路，但不天然等于一个可治理、可运营、可考核的数字员工。
数字员工要成立，必须经过一条更完整的路径：从真实流程活动中发现机会，把机会重构成人机协同流程，把一组活动组合成岗位化的 AI 工作单元，用 DEM 定义它的身份、能力、边界、复核和运营指标，再把它推入真实流程，持续观察、复盘和迭代。
这个过程，才是高质量数字员工项目真正要做的事。
六、MCU 为什么从现场开始
MCU 方法论的起点，不是“我要做一个数字员工”。
它的起点是：哪个真实流程值得进入？这个流程里有哪些关键岗位？哪些活动重复发生、价值明确、数据可得、风险可控？哪些活动适合 AI 介入？哪些活动组合起来，才有机会成为数字员工？
所以 MCU 的第一步不是写方案，而是进入现场，建立流程事实底图。
它要把流程地图、岗位地图、系统地图和痛点地图放在一起，让业务、流程、AI 架构和治理视角围绕同一组事实做判断。
只有这样，数字员工项目才不会停留在“平台能做什么”，而会进入“业务真正需要谁来承担什么责任”。
这也是 MCU 与传统 AI 试点最大的区别。MCU 不是为了多做几个漂亮 Demo。MCU 是为了用更短的认知链路，发现、定义、上线和运营高质量数字员工。
结语：先找到价值发生的地方
企业当然需要 AI 平台。没有平台，很多能力无法稳定供给；没有统一治理，数字员工也很难规模化运营。
但平台不是起点。真正的起点，是业务价值发生的地方。
是员工每天实际执行的活动。是流程中的等待、返工、判断、复核和交接。是那些看起来不起眼，却反复消耗组织能力的现场动作。
高质量数字员工不是从平台里长出来的。
它是从真实流程活动中被发现出来、从人机分工中被定义出来、从业务现场中被验证出来、从持续运营中被沉淀出来的。
如果数字员工必须从现场长出来，那么企业就需要一种新的工作机制：它既要懂业务，又要懂流程，还要懂 AI 架构和治理边界。
这就是下一篇要讲的 MCU。
