这是一家做工业耗材分销的中型企业，三十多个销售、一万两千多个活跃客户，CRM 用的是一套五年前采购的本地化部署系统。他们找来时的诉求很具体：销售每天要花两个多小时整理跟进记录、判断哪些客户该催单、给客户写回访话术，这些事能不能交给 AI。但他们有一条死线——不许换 CRM。系统里五年的数据、和 ERP 打通的接口、销售已经形成肌肉记忆的操作习惯，都不能动。
这条约束在一开始看起来像是限制，后来证明它其实是这个项目能在六周内跑通的关键原因。我们没有把 LLM 嵌进 CRM，而是把它做成了一层挂在 CRM 旁边的旁路服务。CRM 仍然是那个 CRM，数据库结构一行没改，销售的操作界面也几乎没变。LLM 通过 CRM 自带的 API 读数据、把生成结果写回特定字段，仅此而已。
这篇文章记录这六周里我们怎么分阶段推进，以及中间撞到的几个具体的工程问题——字段映射、上下文窗口、人工兜底。这些坑不大，但每一个不处理都会让项目在第三周左右卡住。
§ 01为什么是旁路，不是嵌入
客户最初的想象是「把 AI 做进 CRM 里」——在 CRM 的客户详情页上多一个 AI 助手面板。这个想象不算错，但它会把一个六周的项目变成一个六个月的项目。原因是：任何对 CRM 界面和数据库的改动，都要经过 CRM 原厂的二次开发授权、要重新走他们的测试回归、要担心下次系统升级时改动被覆盖。客户这套 CRM 的原厂二次开发报价，单是评估就要四周。
所以我们提了另一个方案：LLM 服务完全独立部署，只通过 CRM 已经开放的标准 API 双向通信。读取走 API 的查询接口，写回走 API 的更新接口，写到三个我们和客户一起新建的自定义字段里——「AI 跟进建议」「AI 催单优先级」「AI 回访草稿」。CRM 原厂那边只需要做一件事：开三个自定义字段，半天工作量。
这个选择带来一个额外的好处，我们当时没料到，后来发现它很重要——旁路服务是可拆卸的。如果哪天客户觉得 AI 建议不准、想关掉，只要停掉旁路服务即可，CRM 立刻回到接入前的状态，没有任何残留。这种「随时可退出」的安全感，是说服一个保守的传统行业客户最有效的东西。
「能让客户安心签字的，不是 AI 多聪明，是这套东西随时拆得掉。」
— 现场记录 · 第 1 周§ 02第 1-2 周：字段映射比想象中麻烦
前两周的核心工作是字段映射——也就是搞清楚 CRM 里的哪些字段，要喂给 LLM 当上下文。听起来简单，做起来全是细节。这家客户的 CRM 用了五年，字段早已失控：一个叫「备注」的文本字段，被不同销售当成跟进记录、当成报价历史、当成客户脾气描述，三种用法混在一起；客户的「行业」字段是个下拉选项，但有近三成客户选的是「其他」，真实行业写在另一个自由文本字段里。
这意味着我们不能简单地「把所有字段塞给 LLM」。我们做了一轮数据体检，把全部六十多个字段分成三类：结构化可信字段（客户名称、成交金额、最近下单日期这类有约束的字段）、半结构化字段（需要清洗规则才能用的，比如那个混乱的「备注」）、噪声字段（历史遗留、长期空着、或者填得完全不可信的，直接不喂）。
最后真正进入 LLM 上下文的，只有十九个字段。这个筛选过程花了整整一周半，比客户预期的久。但如果跳过这步，后面 LLM 生成的跟进建议会大量引用那些不可信的噪声数据，看起来像模像样，实际全是幻觉——这种错误一旦让销售碰上一次，整个项目的信任就崩了。
§ 03第 3-4 周：上下文窗口与成本的拉扯
第三周开始接 LLM。第一个撞上的现实问题是上下文窗口。一个老客户五年里可能积累了上百条跟进记录，全量塞进去，单次请求的 token 数会非常可观——不是技术上做不到，是成本算下来不划算。这家客户一万两千个活跃客户，如果每天为每个有跟进动作的客户都做一次全量请求，每月的模型调用费会逼近他们能接受的上限。
我们的处理是分两层。第一层，不是每次都调 LLM——只有当客户状态发生实质变化（新增跟进、临近回访周期、订单异常）时才触发，静默客户不消耗 token。第二层，跟进记录做摘要压缩：把超过二十条的历史记录，先用一个便宜的小模型压成一段三百字以内的客户画像摘要，再连同最近五条原始记录一起喂给主模型。这样既保留了近期细节，又不丢失长期背景。
Tab. 01 — 同一套 LLM 旁路服务 · 调用策略优化前后 · 数据脱敏
这里要说明的是，优化后「触发后五分钟内」并不是体验降级。销售并不需要 AI 实时响应——他打开一个客户准备跟进时，那条建议早在状态变化时就已经生成好、写回字段里了。真正影响体验的不是延迟，是建议在他需要的时候已经在那里。把实时性这个伪需求去掉，成本立刻降了一个数量级。
§ 04第 5 周：人工兜底不是补丁，是设计的一部分
第五周做的事，是给 LLM 的每一条输出都设计一个人工兜底通道。我们的原则很硬：LLM 生成的内容，永远是「建议」，永远不自动执行。AI 判断某个客户该催单，它不会真去发消息，只是在「AI 催单优先级」字段标个高，由销售自己决定。AI 写好了回访话术，它写进「AI 回访草稿」字段，销售可以一字不改地用，也可以改，也可以完全不用。
这不是因为我们不信任模型，而是因为这套设计同时解决了三个问题。一是责任边界清晰——出了问题是销售的判断，不是 AI 的越权，客户的管理层对这一点非常在意。二是给了模型一个持续改进的信号源——销售改了多少、怎么改的，全都被记录下来，成了我们调优提示词最真实的反馈。三是降低了上线阻力——销售不会觉得 AI 要取代自己，因为最终拍板的始终是他。
我们专门看过第五周到第六周之间销售对 AI 回访草稿的采纳数据：完全不改直接用的约占四成，小幅修改的约占四成五，弃用重写的约一成五。那一成五的弃用案例，我们逐条复盘，发现大多集中在几个特定行业的客户上——那些行业的沟通话术有很强的圈内黑话，通用模型确实写不好。于是我们针对这几个行业补了专门的提示词样例，第二个月弃用率就降到了一成以下。
§ 05第 6 周：交付的不只是系统，是一份操作手册
最后一周，技术上其实已经没有大事了。我们花在两件事上：一是和客户的 IT 对接人一起过一遍运维细节——服务怎么重启、模型调用报警怎么看、字段对应关系存在哪；二是给销售团队写一份很短的操作说明，核心就一句话——AI 写在那三个字段里的东西是给你参考的，信不信、用不用，你说了算。
我们没有做一场盛大的培训。这套旁路服务的设计目标本来就是「不改变销售的操作习惯」，所以销售要学的东西极少——多看三个字段而已。一份两页纸的说明，比一场两小时的培训更有用，因为它能被随时翻回去看。
这个项目最终六周交付，按周计费。回头看，能压在六周里跑通，关键不在于我们做得多快，而在于一开始就把范围划得足够窄——不碰 CRM 本体、不追求实时、不让 AI 自动执行、不做花哨界面。把这四件「不做」确定下来，剩下的六周就只是按部就班的工程。
很多 CRM 接 AI 的项目做不下去，不是因为 LLM 不够强，而是因为一开始就想做太多。旁路、可拆卸、人工兜底——这三个词，是我们现在做任何「老系统接 LLM」项目的默认起点。