超兔一体云｜AI深入企业业务的第四态：我们为什么不做虚拟员工|上下文|代码|企业业务|算法|翻译|虚拟员工|调用|超兔一体云

当所有人都在追逐Agent和虚拟员工时，超兔选择了一条更务实、更落地的路——SCN场景认知节点。这不是保守，而是我们对企业软件本质的深刻理解。

"AI不替你工作，AI懂你的工作。"—— 超兔一体云AI设计哲学

大模型进入企业应用两年多，业界形成了三种主流模式：嵌入式增强（Embedding）、副驾驶对话（Copilot）、自主智能体（Agent）。但在超兔一体云的实际开发中，我们发现这三条路都有各自的硬伤——真正能让AI跑进业务主线的，是第四种模式。

这篇文章，我们想讲讲超兔为什么选择这条少有人走的路，以及我们在一体云产品中是怎么落地的。

超兔立场：我们不做"挂在CRM外面的聊天机器人"

从2024年底启动AI功能规划开始，我们测试了几乎所有主流方案：从最开始接一个通用大模型做侧边栏聊天，到尝试用Agent框架做"AI销售助理"，最后发现一个残酷的事实——这些方案在Demo里看起来都很炫，但销售真实用起来的时候，要么不需要，要么不敢用，要么用不起来。

这不是模型能力的问题，这是架构设计的问题。

一、前三种态的困境：为什么Demo好看但不好用

我们先复盘一下业界已经形成共识的三种AI嵌入模式，以及它们在架构层面的根本问题。

Embedding 嵌入式

AI在后台默默优化，用户完全无感

业务方看不到AI价值，投入产出算不清楚，最后变成"技术部门自嗨"

Copilot 副驾驶

侧边栏聊天框，需要用户主动发起对话

改变工作习惯阻力极大，用完即走，最后沦为高级聊天框，没人用

Agent 智能体

AI自主规划、自主调用工具

自主性太高意味着不可控，企业不敢让它碰核心业务数据，永远停在Demo阶段

1.1 四种模式的架构对比

从系统架构层面看，这四种模式的本质区别在于：AI到底是在业务管线外面，还是嵌在管线里面。

SCN：用户操作 → 业务管线 ↕ AI认知节点 → 确定性执行

AI嵌在管线内部

麦肯锡2025年AI报告持续强调一个事实：真正获得收益的企业，不是接了一个最先进的模型，而是完成了流程重构、治理机制和组织能力建设。微软2025 Work Trend Index也指出，AI的价值来自人、Agent与流程的重新组合，而非单点工具替换。

翻译成大白话就是：AI在业务系统外面接个聊天框，是进不了业务主线的。

二、第四态：SCN场景认知节点

超兔一体云选择的第四种模式，我们叫它SCN（Scenario Cognitive Node，场景认知节点）。

2.1 从一个最真实的销售场景说起

一个销售跟了三个月的单终于出结果了——赢单了，或者丢单了。销售经理要求做复盘。

传统做法是：销售翻聊天记录、翻行动日志、翻报价邮件，花半小时到一小时整理复盘报告。而且容易遗漏关键节点，归因偏差也大（赢了是我厉害，丢了是价格问题）。

如果用Agent做呢？你给它一个目标"帮我复盘这个商机"，它需要自己规划：先查行动记录、再查需求、再查报价、再查竞品……但每个企业的表结构不同、字段语义不同、业务流程不同，Agent很容易跑偏，而且自主调用API可能触发权限问题。

如果用Copilot做呢？销售需要打开对话窗口，手动描述："我这个单丢了，客户选了竞品，价格比我们低15%……"——但CRM里已经有这些数据了，为什么还要人再说一遍？

超兔做法：系统自己判断"该复盘了"

在超兔一体云里，这个过程是这样的：业务系统自己检测到商机状态变成了"成功"或"失败"，自动拉取这个商机的7张子表数据（行动记录、详细需求、解决方案、报价、竞品、销售费用、伙伴），组装成干净的上下文送到AI认知节点，AI理解这些数据后生成一份结构化复盘报告，以打字机效果渲染到业务面板上。

销售看完觉得没问题，点一下"保存"，报告就写入CRM成为永久可追溯的资产。

整个过程：没有对话、没有自主规划、没有工具调用的不确定性——AI只做一件事：理解业务数据，生成认知结论。

2.2 SCN的定义

SCN是一种将LLM认知能力嵌入企业业务流程的架构模式：

在确定性业务管线中设置认知节点，由业务代码控制何时触发AI、传入什么上下文，AI在节点处完成理解/判断/生成任务后，结果回归确定性管线继续执行。

2.3 超兔一体云的SCN架构

说起来抽象，看架构就清楚了。

SCN分为五层：

核心理念：刚柔并济——确定性代码做骨架，LLM认知做关节。

2.4 SCN触发判断流程

SCN不是什么操作都触发AI，而是由确定性代码精确控制触发时机。以商机复盘为例，触发逻辑如下：

商机状态变更

读取当前商机完整数据

判断：新状态是否为"赢单"或"丢单"？

否 → 不触发AI，正常流程继续

是 → 继续

判定为赢单/丢单

判断：7天内已复盘过？

是 → 跳过，避免重复生成

否 → 进入SCN认知管线

2.5 SCN完整时序

从用户操作到结果回写，SCN的完整交互流程分为六个阶段：

阶段一：同步更新

销售点击"赢单"按钮 → 业务系统更新商机状态 → 状态更新成功

业务系统返回："状态已更新，AI复盘生成中…"

阶段二：异步触发

业务系统异步触发SCN管线 → 数据层启动

阶段三：数据采集

数据层向CRM数据库拉取7张子表数据 → 返回聚合数据

数据层内部处理：截断、脱敏、格式化

阶段四：AI处理

数据层将干净上下文Prompt送至AI认知层

AI认知层进行LLM认知 + 流式处理

AI通过SSE流式返回复盘报告

阶段五：渲染

业务系统接收流式数据，以打字机效果渲染到业务面板

阶段六：保存（用户确认）

销售点击"保存复盘" → 业务系统字段校验 → 写入行动记录表+复盘关联表+AI日志 → 持久化成功

2.6 上下文组装流水线

SCN的核心工程难点之一是：如何把业务数据组装成LLM能理解、且不会产生幻觉的上下文。超兔设计了一套标准化的数据预处理流水线：

STEP 1 原始业务数据（多表关联）→ STEP 2 字段过滤（只传相关字段）→ STEP 3 数据字典映射（枚举值翻译）→ STEP 4 长文本截断（Token控制）→ STEP 5 脱敏处理（手机号/金额）→ STEP 6 结构化Prompt（角色+任务+数据+格式）

javascript// SCN上下文组装伪代码示意async function buildSCNContext(scenario, businessId) { // 1. 根据场景定义确定需要采集哪些表和字段 const tables = scenarioConfig[scenario].tables; // 2. 并行采集多表数据 const rawData = await fetchRelatedTables(businessId, tables); // 3. 数据字典实时映射（每个企业枚举值不同） const dict = await loadDataDict(tenantId); const mapped = applyDictionary(rawData, dict); // 4. 截断、脱敏、格式化 let clean = truncate(mapped, MAX_TOKENS); clean = desensitize(clean, ['phone', 'idCard']); clean = formatForLLM(clean); // 5. 组装最终Prompt return renderPrompt(scenario, clean);}

三、超兔一体云的SCN落地实践

截至2026年Q3，我们在超兔一体云的CRM跟单场景中，落地了三类SCN认知节点，覆盖了销售每天都在做的高频场景。

认知节点 A · 语言→结构：AI语音创建数据

销售拜访完客户，按一下录音键口述："今天去了梦蝶科技，见了张总，聊了监控系统需求，预算大概50万，竞品是海康，下周二再去演示方案。"

系统自动识别客户名称、匹配商机、提取行动类型、识别日期、拆分多表记录（行动记录+需求记录+竞品记录），然后以卡片形式预览给销售确认。销售改两个字点保存，直接写入CRM的对应数据表。

认知节点 B · 上下文→建议：智能下一步

销售打开某个客户或商机，系统根据当前跟单状态自动给出建议：新商机建议确认需求、有报价三天没反馈建议跟进、竞品出现了建议做差异化方案、超过平均周期没下单建议激活、赢单了建议触发复盘、丢单了建议触发复盘。

关键设计： 分支判断由确定性代码完成（不是AI猜），AI只在每个分支点生成具体的建议话术和理由。这样流程绝对可控，建议内容又有AI的灵活性。

认知节点 C · 数据→结论：赢单/丢单复盘

商机出结果后自动触发复盘：赢单提取可复制的成功因子，丢单做客观归因分析并给出改进建议。

数据洞察 · 纯算法（不用AI）：购买习惯分析

历史购买习惯（订单+回款趋势）、产品购买习惯（复购周期+预警），这些我们全部用纯代码聚合计算，不调大模型。图表可视化、环比同比、阈值预警——这些确定性工作，代码比AI做得更快更准更便宜。

超兔原则： 刚柔并济。确定性算法做骨架，LLM认知做关节。

3.1 赢单/丢单双Bot架构

复盘场景有一个特殊的工程设计：赢单和丢单我们用了两套完全独立的COZE智能体。因为赢单复盘和丢单复盘的分析框架、关注点、输出结构完全不同，硬塞给一个Bot会导致Prompt臃肿、输出质量下降。

3.2 结果校验与回写流程

AI生成的内容不能直接写入数据库。SCN在回写层设计了严格的校验机制，确保AI输出的每一个字段都符合业务规则：

AI返回结构化结果（JSON）

JSON Schema格式校验

判断：格式是否合法？

否 → 自动重试1次（调整温度参数）→ 仍失败则降级为纯人工录入

是 → 继续

业务规则校验（枚举值/外键/必填项）

渲染为可编辑卡片，用户预览确认

判断：用户是否确认？

修改/取消 → 用户编辑后手动保存

确认保存 → 开启事务，写入多张表 + 记录AI生成日志

四、SCN vs 主流模式：全景对比

为什么我们笃定SCN是企业AI更务实的路线？看这张对比表就清楚了：

超兔选择SCN的核心理由：三个"不敢"，SCN都能解

企业客户上AI有三个真实顾虑：

不敢上线——Agent自主性太高，出问题追责困难。SCN方案里业务代码控制流程，AI只在节点做认知，失败了大不了这一条AI不生效，不影响业务主线。

不敢用——改变工作习惯阻力大。SCN不需要用户主动对话，AI输出直接嵌入业务面板，销售该看客户看客户，该做复盘做复盘，AI就在那里默默帮你干活。

不敢投——ROI算不清。SCN选的全是高频场景，录音录单、下一步建议、赢丢单复盘，每天都用，省了多少时间、多赢了多少单，账算得过来。

五、SCN的三个"不"：超兔的AI开发哲学

经过这一年多的实践，我们总结了超兔做企业AI的三个原则。

不造机器人

不试图让AI像人一样思考和行动。我们给业务系统装大脑，不雇一个会犯错的"AI实习生"。

不做聊天框

不做需要用户主动点开才能用的侧边栏助手。AI应该在你需要的时候自然出现在业务面板上。

不追求替代人

AI增强人，不替代人。最终的判断权、确认权、决策权永远在人手里，AI只负责把"需要想一想"的那部分做了。

六、SCN落地实施指南

如果你们也在做企业产品的AI功能，超兔团队的经验是：

6.1 选场景先问三个问题

高频吗？ 销售每天/每周都做的事，才值得投入开发。一个月用一次的功能，再炫也不值得。

需要非结构化理解吗？ 听人话、读文字、做判断——这类纯代码搞不定的，才需要LLM。能用SQL算出来的，就别调大模型。

结果可验证吗？ 人能确认对错、系统能校验字段合法性。AI生成的东西必须有兜底，不能直接写进数据库。

6.2 实施节奏建议

别一上来就做大而全的AI平台。超兔推荐三阶段路径：

第一阶段：单点打透。 选一个最高频、最痛的单点场景打透。我们选的是语音创建数据——这个场景痛点最明确、节省时间最直观、销售感受最明显。验证用户是否真的愿意用、效果是否能量化。

产出：1个可用SCN节点 + 触发/数据/调用/校验/回写最小闭环

第二阶段：场景复制。 复制到2-3个相邻场景，沉淀通用组件：上下文组装器、字段校验器、卡片渲染器、SSE流式输出组件，建立Prompt模板库和场景配置中心。

产出：3-5个SCN节点 + SCN通用中间件 + 场景配置化能力

第三阶段：认知组网。 认知节点之间联动，数据洞察面板串联，一个节点的输出成为另一个节点的输入，形成完整的AI认知链路。例如：语音录入→自动识别下一步建议→赢单自动触发复盘→复盘沉淀为团队知识。

产出：SCN节点网络 + 数据洞察闭环 + 业务知识飞轮

6.3 SCN场景配置抽象

当SCN节点超过3个以后，应该把场景定义抽象为配置化，而不是每个场景写一套代码。一个标准的SCN场景配置结构如下：

typescript// SCN场景配置标准结构interface SCNScenario { scenarioId: string; // 场景唯一标识 trigger: { event: string; // 触发事件名 condition: string; // 触发条件表达式 debounce?: number; // 防抖时间（毫秒） }; data: { tables: TableQuery[]; // 需要采集的表和字段 dictFields: string[]; // 需要数据字典映射的字段 truncate?: number; // 长文本截断长度 }; ai: { botId: string; // COZE Bot ID promptTemplate: string; // Prompt模板 stream: boolean; // 是否流式输出 temperature?: number; // 温度参数 }; output: { schema: JSONSchema; // 输出格式校验 renderAs: 'card' | 'panel' | 'toast'; // 渲染方式 writeback?: { // 回写配置（可选） targetTable: string; fieldMapping: Record; requireConfirm: boolean; }; };}

不是用一个炫酷的AI助手替代人，而是在销售每天都在用的高频场景里，让AI默默把"需要人脑理解但人脑不擅长"的那部分做了。