别从“做个助手”开始：企业 AI 场景的六种工作原型

从多个实际应用中看见同一种工作变化

把多个实际应用展示并排观察，表面差异往往很大：有的帮助人找到材料，有的解释业务状态，有的生成正式内容，还有的把结果送入后续流程。行业、界面与数据形态各不相同，真正可迁移的却不是某个页面，而是信息怎样变成判断、判断怎样进入行动。

应用展示的价值因此不在提供一份照抄清单，而在让企业跨过行业标签，抽象出检索、诊断、比较、生产、编排与学习等工作模式。只有先看见模式，团队才能判断哪些技术与治理基础可以复用，哪些业务对象、规则和责任必须重新设计。

回到企业内部，战略会结束后，各部门常会提交一长串 AI 需求：知识助手、销售助手、合同机器人、自动周报、预测平台。名称看起来不同，背后却混合了多种工作模式。若仍按部门清单管理，技术团队无法比较准备度，业务团队也说不清成功后哪一步工作会改变。

企业于是要么选择最容易演示的聊天问答，要么试图建设一个覆盖所有部门的通用平台。前者容易停在新鲜感，后者在业务对象、权限和规则尚未厘清时扩大范围。真正缺少的不是创意，而是一套把不同应用还原成工作机制的方法。

本文的核心观点是：企业 AI 场景应按它改变工作的方式来分类，而不是按部门或技术名称分类。 当场景被还原为对象、语境、输出、动作和反馈，企业才能识别哪些能力可以共用，哪些责任必须留在具体流程中。

场景为什么会在提案阶段被说得过于简单

业务部门通常描述可见界面：“我想问一句就得到答案”“系统自动帮我处理”。但一句答案可能要求识别客户、读取合同、计算风险、比较政策并发起审批。界面简单不代表后台和治理简单。

技术部门则容易按模型能力描述：“能做 RAG”“能调用 Agent”“能接工作流”。这些能力说明怎样实现，却没有说明为什么值得实现。相同检索技术用于员工制度查询和合同义务判断，后果、权限与验收完全不同。

此外，场景清单往往没有业务所有者。需求人期待技术团队交付，技术团队期待业务提供知识，安全团队最后才介入。没有人拥有从当前流程到业务结果的整条变化，POC 通过后也无人维护。

“企业 AI 六种工作原型”

以下六种原型不是产品菜单。一个场景可以组合多种，但应先确定主原型，避免一开始吞下整条价值链。

原型一：检索定位。 从受控知识中找到适用信息，例如定位某项制度、项目资料或设备手册。分析单位是问题与知识条目，关键语境是版本、适用范围和权限，输出应保留来源。它适合减少寻找时间，却不能因为找到一段文字就替代专业判断。

原型二：解释诊断。 围绕订单、设备事件、客户请求等对象连接数据与历史，解释发生了什么、可能由什么造成。输出是证据、假设和待确认项。它的难点是对象关系、时间和对照，而不是生成一段总结。

原型三：方案比较。 在明确目标与约束下，生成或评估可选方案。例如对供应风险比较加急、替代和调整承诺的影响。系统可以计算和组织权衡，业务负责人仍拥有选择，重要假设必须可修改。

原型四：内容生产。 根据企业语境生成合同草案、客户回复、项目报告或操作说明。价值来自减少重复表达并保持口径。输出在进入正式记录或对外发送前，需要按风险复核；风格流畅不等于事实正确。

原型五：流程编排。 识别状态、创建任务、路由审批、更新系统，让跨角色工作连续推进。这里的核心是权限、幂等、异常恢复和责任交接。AI 可以判断下一步建议，但不能绕过现有控制。

原型六：反馈学习。 从行动结果、例外、人工覆盖和客户反馈中发现规则或知识需要怎样调整。它让系统从一次使用变成持续改进，但前提是结果可记录、因果不过度推断、维护者确实处理反馈。

六种原型可以形成递进，也可以独立存在。内部制度查询可能只需要检索；复杂现场服务可能组合诊断、方案与编排；内容生产也不必自动接入执行。组合越多，价值潜力与治理责任都会上升。

用“场景五问”把原型落到业务

确定原型后，再用“场景五问”检查它是否值得进入 POC。

第一问，工作对象是什么？ 不能只说“运营数据”，要说订单、合同义务、设备事件或客户请求。对象决定数据关系、状态和结果记录。

第二问，谁在什么时点作出什么决定或动作？ 明确使用者、批准者和最晚行动窗口。若输出无人负责，场景仍是信息展示。

第三问，可靠完成需要哪些语境？ 列出数据、知识、规则、历史与权限，并标注所有者和新鲜度。准备度不是“有数据”，而是数据能否对应对象并支持判断。

第四问，错误会怎样被发现和恢复？ 低风险草稿可以人工修改；高风险执行必须有审批、审计、撤回和升级。错误不可见的场景不适合贸然自动化。

第五问，结果怎样回到下一轮？ 记录建议采纳、动作完成、业务结果和例外原因。若结果不可观察，就很难证明价值或改进系统。

五问的输出是一张场景卡，企业可以据此比较频率、等待成本、语境准备度、行动可达性、风险与学习能力，而不是比较谁的演示更炫。

从场景地图到第一批验证

第一步由转型负责人组织跨部门访谈，但要求每个需求以真实流程叙述：触发了什么、现在谁处理、在哪些系统间移动、哪里等待、怎样结束。业务流程所有者签认问题，技术与治理角色只补充实现和边界。

第二步把需求映射到六种原型，拆开过大的组合。例如“智能合同助手”可以拆为条款检索、差异解释、修改方案和审批编排。先选择最能验证核心风险的一段，而不是从端到端自动化开始。

第三步建立场景组合。优先选择业务所有权明确、发生频率足够、语境能够获得、动作相对可逆且结果可观察的场景，同时保留少量高价值但需要先治理数据或知识的候选。输出应包含“不做什么”及理由。

第四步为每个入选场景定义 POC。输入使用经过授权的真实结构，输出接近实际工作，成功检查点同时包含质量、时间、人工负担、权限和行动。领域专家负责判断，IT 负责连接，安全负责边界，一线人员负责验证可用性。

第五步提炼可复用能力。对象身份、权限、知识版本、任务接口和反馈记录可能跨场景共用；具体审批、阈值和责任仍归业务流程。复用基础，不强行统一业务差异，才能避免每个项目重造，也避免一个平台承载所有规则。

六种原型各自的边界

检索失败常来自旧版本和权限，而非搜索不够强；诊断失败常把相关性说成原因；方案比较可能遗漏不可量化约束；内容生产容易以语言质量掩盖事实问题；流程编排会放大一个错误动作；反馈学习则可能把一次干预后的结果误当稳定规律。

还要警惕“场景数量”成为转型指标。几十个浅层助手不一定比一条真正进入流程的应用更有价值。若一项工作低频、规则未形成共识、错误后果极高或结果无法观察，先改善流程与信息基础，可能比上 AI 更合理。

先判断工作怎样改变，再决定建设什么

面对一项场景提案，先不要问它属于哪个部门或要使用哪种模型，而要问它主要改变六种原型中的哪一种工作。主原型说不清，往往意味着对象、责任与结果仍混在一起；主原型清楚后，再用场景五问检查语境、风险和反馈。第一批场景宁可少，也要让某一种工作变化在真实流程中闭合，因为可复用能力只能从闭合的路径中提炼，而不能从功能清单中推测。

Luminent 使用工作原型时，会据此区分可共用的技术基础与不可外包的场景责任，再用五问限制设计范围，防止部门清单重新膨胀成彼此孤立的助手集合。