工业/工贸CRM的AI实践：一套「先修跑道、再跑车」的确定性工程——从实施顾问调研到客户贴表即走
（平台提示：本文可能是商业推广软文）
背景说明：本文以超兔CRM的一次系统性 AI 落地为蓝本。超兔CRM做 CRM 22 年，系统里有 15 个业务域、74 个模块、480 个能力点。这次改造的对象不是单个功能，而是 SaaS 交付里最重的一段链路——新客上线：42 天、120 次提交，从能力知识图谱、业务模式设计器，到智能客户导入与历史订单导入。文中表名、字段名、接口名、环境标识均已脱敏改写，技术脉络保持原样。
先说结论
演示环境里贴一张表格，模型通常能正确识别字段；接上真实客户数据之后，多数项目会停在落地环节。整理完 42 天的开发记录，我们的判断是：同一套模型接在不同的工程结构上，效果差距很大，决定上限的是跑道，不是模型档位。
跑道由三块确定性资产组成：
- 知识跑道：把系统能力结构化成图谱，让 AI 知道系统有什么、功能之间是什么关系；
- 业务跑道：把客户的业务语义显式化成可推导的模型，让 AI 知道这家客户怎么做生意；
- 执行跑道：一条 run + gate + ledger 的门禁流水线，让 AI 的判决落在确定的执行、对账和回滚上。
投入分布也能说明问题。120 次提交里，直接改提示词、调模型参数的不到十分之一，其余都在修跑道：元数据治理、流水线门禁、幂等账本、读回对账。
下面按开发顺序写：先写失败的开局，再写三块跑道怎么修，最后是一张教训清单和一个可复用的判断框架。
一、战场：为什么是新客上线
对超兔CRM这样的 CRM 厂商来说，客户签单只是开始。把组织架起来、流程配起来、历史客户和订单数据搬进来，客户才算上线。这一段过去靠实施顾问上门培训、代配置、代录数据：成本高、周期长，而且不可复制——一个顾问的经验带不走，一个客户的方法论也给不了下一个客户。
数据现场比演示环境复杂得多：
| 现场特征 | 真实还原 | 传统工具的下场 |
|---|---|---|
| 一客多名 | 营业执照全称、门头简称、销售嘴里的叫法、旧系统代号 | 字面匹配认不出同一家，重复建档 |
| 多人一厂 | 采购、技术、财务、老板娘散落在不同工作表 | 行结构约定一忘就错挂 |
| 字典自造 | 行业写「注塑/冲压/压铸」，等级写「重点保护」 | 系统预置字典接不住，校验直接拒 |
| 格式自由 | 日期七种写法，金额带单位，电话带分机 | 逐行标红，用户回 Excel 改 |
| 台账结构野 | 合并单元格、双行表头、一个文件七八个工作表 | 解析乱，后面全乱 |
查重是生死线：一旦「一客多名」裂成多条记录，报价历史断成几瓣，两个销售各跟各的。这类数据写错，污染的是客户最值钱的资产。
不过导入只是三大堵点之一。项目开局甚至不是从导入开始的，而是从一个被推翻的方案开始。
二、总路线：失败的开局与三阶段演进
2.1 开局教训：全自动生成不被信任
项目最初的做法是：客户接入时，系统自动生成全部初始化方案——行业画像、模块配置、菜单、权限。原型做完，内测就推翻了，原因是用户不认。
复盘时我们确认了一点：用户的认知顺序是先业务后系统。老板先想的是「我先报价还是先签合同」「采购归谁管」，不会从「我要启用哪 14 个模块」开始。跳过业务直接生成系统配置，用户无法判断对错，也就不会点「确定」。
总路线因此定为：先业务后系统，先修路再跑车。120 次提交分三个阶段：
2.2 什么叫「跑道工程」
把这条路线抽象一下：
跑道工程（Runway Engineering）：把 AI 接进业务之前，先把三件事做成确定性资产——系统知识结构化、业务语义显式化、执行链路护栏化。模型能力是常量，跑道质量是变量。
这个说法容易被读成「先做数据治理」。为了让它可检验，我们定了两个标准：判决可追溯（预判与改判轨迹留痕）、输出可对账（写入后读回核对，任何值不允许无终态消失）。下面三节分别展开。
三、知识跑道：把家底拆给 AI 看
AI 要替客户推荐功能、配置流程，前提是知道系统有什么。超兔CRM 22 年积累了 480 个能力点、103 个前置开关、74 个模块，这些知识原本在顾问脑子里和帮助文档里，对 AI 来说并不存在。
3.1 做法与取舍
我们做了三件事：
- 能力锚点全量结构化：从系统全菜单快照导入 480 个能力锚点，每个挂上所属模块、前置开关、菜单路径；
- 手册全文入库：对 20 个来源的官方手册做页内下探，838 篇正文进知识库，图谱的内容边可以从原文溯源；
- 关系显式化：定义 comprises（组成）、derives（衍生）、requires（前置开关）三类边，每条边必须带来源标记。
这三个决策都改过不止一次：
第一，图谱是独立资产，不是功能的附属品。 图谱单向消费系统快照与业务设计器，不反向写入，因此可以独立演进、独立校验，不会被某个功能迭代拖垮。
第二，LLM 抽取的候选边必须人工确认后才入库。 我们用模型从手册里抽了几百条「衍生」「前置」关系，抽取质量看起来不差，但图谱要给下游 AI 消费，一条幻觉边就是一次错误推荐。最终 353 条 LLM 候选边整体暂离主干，主图只保留可溯源的组成与替代关系；审阅清单保留全部条目，确认一条，恢复一条。
第三，宁可图谱小而可信。 主图从五百多个节点收敛到两百多条边，这是阶段一唯一一次主动缩减规模，换来一条规则：图谱里每条边都要能回答「你从哪来」，没有来源的边不进主干。
这条规则后来用在了所有 AI 输出上：判决带置信度、归并带理由、改判留轨迹。没有来源的输出不进下游。
四、业务跑道：让系统先懂业务
第二块跑道解决「不会配置」。业务模式设计器的做法是：用户用业务语言回答四个维度的问题——卖什么、怎么交付、要不要采购、收付款怎么走——系统推导出流程主干、岗位矩阵和最小功能集。
4.1 核心设计：图描述抽象层
我们没有为每种业务组合硬编码一套流程图，而是定义了一层中间描述：业务流程拆成泳道、节点、边三种对象，边分四类关系：
| 关系类型 | 业务语义 | 例子 |
|---|---|---|
| series（串联） | 顺序必经 | 签约 → 交付 |
| parallel（并联） | 并行支线 | 项目 ∥ 商机双通道 |
| optional（可选捷径） | 可跳过 | 项目直报价，商机的可选项 |
| bridge（跨线衔接） | 跨泳道汇合 | 采购入库衔接订单出库 |
每个维度选项只声明自己贡献的图片段，组装器负责合并、去重、按关系类型渲染。四维度组合出近百种业务模式，代码里只有一套组装逻辑。业务配置因此从「选功能」变成「选维度」：用户的每个选择都对应业务含义，而不是系统含义。
这块跑道与知识跑道咬合：设计器推导出的每个流程节点都要在知识图谱里命中锚点，推导不出锚点的节点按描述漂移处理。两块跑道互相校验，AI 拿到的才是「系统有什么」和「客户要什么」的交集。
五、执行跑道：模型只做判决，代码负责一切
第三块跑道是提交量最密集的部分：智能导入。它要接住第一节那张表里的全部情况，而且一次写错就是污染客户资产。
5.1 第一次架构收敛：去掉 Agent
最初方案是 Agent 挂四条工作流，自主规划导入步骤。实测有三个问题：识别慢、步骤序列不可复现、日志无法结构化排查。
导入的核心任务是列对齐、值归并、未识别列判决，属于有限轮次的结构化判决，不需要自主规划。因此我们砍掉 Agent，改成纯工作流直调：每次调用的输入、输出、失败处置全部显式定义。
教训 1：判决、归并、摘要这类任务，自由度越少越稳；开放对话才需要 Agent。 选型的第一问是这个任务需要多少自由度。
5.2 裁决反转：AI 判决优先，代码预判兜底
第二版按直觉设计：代码层做精确匹配和别名库，匹配不上才交给模型。一条反例推翻了它——「负责销售」这一列被别名库硬编码命中到客户电话字段，代码层给出的是高置信的错误，模型没有复核机会。
解法是裁决反转：代码层的所有命中（逐字、别名、模式归一）一律降级为预判，随要素包送模型全场复核；裁决顺序改为模型判决优先，模型漏答或调用失败时回落预判。
反转之后补了三个约束：
- 硬锁：客户全称这类主键字段拒绝模型改判。允许错一列，不允许错主键；
- 零调用快路径：全部列逐字命中主表且无子表字段时，不调用模型；
- 调用预算制：配合「准备后重解析沿用首判」「补字典后本地重算」，常规导入全程 LLM 调用一次封顶。重复调用不仅费钱，同一归并判决两次结果不同还会成为扰动源。
5.3 门禁流水线：run + gate + ledger
订单导入把上述做法固定成注册式流水线，每步由 run（执行）、gate（门禁）、ledger（落账）三个函数组成。八道门禁只放在必须由人决策的位置，其余全自动。
三个设计点：
门禁暂停语义。 引擎遇到门禁返回暂停态，用户处置后从断点续跑，不做弹窗打断。步骤条上因此不是 14 个步骤，而是 8 个可理解的决策点。每道门禁只把一行主结论放在明面，过程信息收进折叠详情：用户卡住的原因多是信息太多，不是逻辑太难。
就地新建客户。 G3 遇到未命中档案的客户行，给出三个选项：挂到存量档案、就地新建、本行不导入。选新建时全称原值入库、简称自动生成、种类落默认值，下游复用既有归并逻辑，不为「新建」单独写分支。
账本逐位记账。 一行台账会展开成一个客户、N 个联系人、一张单、若干明细、一笔回款、一次归属转移；每个原子动作独立记账、独立重试、独立解锁。客户失败删整行，联系人失败沿用已建客户，转移失败不回滚建档。断点续传只补未处置位，重跑不重复建档。
时序图里有三个位置需要盯住：强刷元数据排在判决之前（缓存陈旧是误判来源）；三次暂停都是人的决策点（形态、客户、单据内容）；读回核对在写入之后，写进去不算数，读回来才算数。
5.4 四道护栏
模型输出是概率的，执行链路是确定的，中间隔四道代码护栏：
- JSON 抢救：模型偶发在尾部多输出一个括号，整体解析失败会丢掉一份判决全对、只差一个字符的输出。标准解析失败后做字符串感知的括号配对扫描，截取第一个平衡的 JSON 对象；
- 漏答检测：判决要求逐列覆盖，模型偶尔漏答。拿到结果先校验覆盖完整性，缺列自动重试，上限 2 次；
- 回落预判：重试用尽才回落代码预判，降级后清单变长，流程不停；
- 错误分类：所有失败先分为可自动修复、需人决策、不可修复三类，第三类单独成清单、不阻断整体，任何错误不允许静默吞掉。
四道护栏的共同点是：每条退路都终止在一个确定状态，不停在「不知道」。
六、教训清单
十条，按遇到的顺序：
| # | 教训 | 解法 |
|---|---|---|
| 1 | Agent 循环不是万能解 | 结构化判决用纯工作流，自由度越少越稳 |
| 2 | 模型档位影响判决稳定性 | 降档省下的调用费，会在判决波动上加倍还回来 |
| 3 | 记忆是资产也是负债 | 字面精确命中优先，记忆项单独标注来源 |
| 4 | 缓存会造成误判 | 判决前强刷元数据；静态资源带版本号 |
| 5 | 服务端语义必须实测 | 每个写接口上线前跑一次最小实验 |
| 6 | 隐性约束要能自愈 | 写入失败后学习并固化，下次导入复用 |
| 7 | 回归缺陷先定位引入点 | 逐版本 diff 确认，再动手 |
| 8 | 理解负担来自信息密度 | 主结论留明面，过程收折叠 |
| 9 | 全自动不等于可控 | 决策权只留在需要人拍板的位置 |
| 10 | 自由度要与任务匹配 | 判决、归并、对话分别设计编排 |
七、一个可复用的判断框架
42 天里我们没有换过模型，也没有追新特性，120 次提交几乎都在做同一件事：给概率性的模型修一条确定性的跑道。
评估一个 AI 功能能不能落地，可以先不谈模型，问三个问题：
- AI 懂你的系统吗——能力有没有结构化，输出有没有来源；
- AI 懂这家客户的业务吗——业务语义是显式模型，还是埋在配置表里；
- AI 的输出落得进系统吗——有没有门禁、账本、对账，错了能不能退。
三个问题都有答案，剩下的才是模型调优；有答不上来的，先补跑道。
超兔CRM的下一站是把确认清单做得更短、让映射记忆跨租户复用、把「一客多名」剩下的语义归一做完。先修跑道再跑车的分工不会变：确定的执行交给代码，需要拍板的留给人，两者之间靠账本和对账衔接。
如果你们也在给老系统做 AI 改造，欢迎在评论区聊聊：卡住你们的是模型，还是跑道？
浙公网安备 33010602011771号