一、项目背景

我们服务的一家某 SaaS 企业，主营面向中小商户的经营管理 SaaS，付费客户约数千家。这个项目里最痛的点很朴素：续费基本靠客户成功（CS）经理人工盯盘，谁快到期了、谁用得少了、谁投诉多了，全凭人肉经验和每周例会"报数"。客户行为散落在登录系统、功能埋点、工单系统、账单系统、客服会话里，彼此口径不统一，所谓的"健康度"在管理层那里其实说不清——有人看活跃账号数，有人看工单量，有人看付费金额，谁也说服不了谁。

更麻烦的是流失没有预警。等到客户不续费、发来解约邮件，往往已经晚了：活跃度其实两个月前就掉下来了，但没有任何机制把这些信号聚起来、算出来、推给 CS。我们当时接到的目标很明确：用一个能落地的工程方案，把"客户健不健康"从玄学变成可量化、可归因、可干预的指标，并且要和既有的业务系统（而不是另起炉灶）打通。

我们采用的 AI 私有化底座，把大模型推理、向量检索和编排能力下沉到客户自己的机房，配合 AI 网关做统一的模型接入、路由与计量，让这套健康度系统既能跑批处理、又能接实时事件，还不会因为模型调用失控而拖垮主线业务。

二、落地场景

落地时我们把场景拆成四块，每一块都紧贴现有的业务系统而不是旁路：

1. 多源行为汇聚。我们把登录日志、功能埋点、工单、账单、客服会话通过消息队列接入，统一在 AI 网关的接入层做协议归一化，落到一张"客户行为宽表"。这一步不追求一步到位，先解决"有"和"口径一致"。

2. 健康度评分。基于宽表，我们做了一套分层评分：底层是行为频度与深度指标，中层是业务价值指标（付费、增购意向），顶层用大模型做语义层的风险判断（比如工单情绪、客服会话里的流失信号）。评分结果写回客户主数据，CS 在原有 CRM 里就能看到。

3. 流失预警与干预建议。当健康度跌破阈值，系统生成预警单，并由大模型给出可解释的干预建议（该打什么电话、推什么内容、有没有增购机会）。这里用网关的编排层做了"小模型先分类、大模型再精答"的两段式，控制成本。

4. CS 协同闭环。预警单进入 CS 的工作流，处理动作（联系、方案、结果）回填，形成"预警—干预—结果"的闭环数据，又反哺评分模型迭代。

三、关键技术挑战与解决思路

挑战一：多源行为汇聚与口径。登录系统记的是"会话"，埋点记的是"事件"，工单记的是"工单"，时间粒度、主键、定义全不一样。我们的做法是在接入层之后加一层"行为标准化"ETL，把所有源统一成 (customer_id, event_type, ts, payload) 的事件流，再按天/周聚合为宽表。关键是先和业务方对齐每个指标的定义，写进一份口径文档，代码只是落地。这套工程跑在我们采用的 AI 私有化底座的向量与批处理资源上，事件侧用消息队列削峰。

挑战二：健康度评分建模。纯规则容易误杀（比如客户季节性停用），纯模型又黑箱。我们用了"规则基线 + 大模型语义"的混合：规则算硬指标（登录衰减、核心功能停用、工单升级），大模型只负责从客服会话、工单文本里抽"软信号"并给出风险叙述。模型输出强制要求带理由字段，便于 CS 复核。

挑战三：流失预警与归因。预警最大的坑是"准了但说不清为什么"，CS 不买账。我们要求模型每次预警必须输出 top-3 归因因子，并在网关的计量层记录每次调用的 token 与延迟，方便我们回看哪类归因最常被 CS 采纳，反向优化提示词。

挑战四：干预建议与 CS 闭环。建议如果脱离 CS 实际工作流就会被无视。我们把建议直接生成 CS 可执行的"下一步动作卡"，并和 CRM 的状态机绑定；未处理的预警单会升级提醒，保证闭环。这里借用了网关的限流熔断，避免批量生成建议时打爆模型实例。

案例片段（已脱敏）：健康度评分与预警的配置片段（来自某 SaaS 企业落地环境的评分规则 YAML）。

# health_score_rules.yaml（脱敏示意）
weights:
  login_decay_7d:   0.25   # 近7日登录衰减
  core_feature_off: 0.30   # 核心功能连续停用天数
  ticket_escalation: 0.15  # 工单升级次数
  llm_risk_signal:  0.30   # 大模型从会话/工单抽取的风险分
thresholds:
  warn: 60      # 触发预警单
  critical: 40  # 升级至主管
llm:
  model_route: "cs-risk-small -> cs-risk-large"  # 网关编排：小模型分类后大模型精答
  require_reason: true   # 强制输出 top-3 归因

四、效果数据（可量化、脱敏）

上线约一个季度后，我们拉了脱敏后的对照数据（干预组 vs 未干预的历史对照组）：

• 流失预警准确率：在"预警后 30 天内流失"的标签上，模型预警的准确率由人工盯盘的约 55% 提升至约 82%，误报率约降至原来的一半。
• 续费提升：被纳入预警干预流程的高危客户，续费转化率较历史同口径提升约 11 个百分点。
• 健康度覆盖客户：健康度评分从原来只覆盖约 30% 的重点客户，扩展到全量付费客户的约 95%，CS 不再只看"大客户"。
• 人工盯盘工时下降：CS 经理每周用于整理客户状态、手工拉数的工时，约从 8 小时降至 2.5 小时，省下的时间用于实际触达。

案例片段（已脱敏）：某客户预警日志片段（字段已脱敏）。

[2026-03-12 09:14] WARN health_engine cid=C10231 score=41 critical
  reasons: [core_feature_off=12d, llm_risk="多次提及竞品对比", ticket_escalation=2]
  route: cs-risk-small->cs-risk-large cost=320tok/1.8s
  action: 生成干预卡 -> 分配CS=王工 -> 建议: 安排续费复盘电话

五、可复用经验总结

经验一：健康度先于干预。我们踩过的坑是上来就做"自动干预"，结果因为健康度本身没对齐，干预越多错得越离谱。正确顺序是先把"客户健不健康"定义清楚、口径对齐、跑通评分，再谈干预。健康度是一套组织共识，不是算法。

经验二：预警必须可归因。CS 不缺告警，缺的是"为什么是我现在要动这个客户"。每次预警带 top-3 归因、每次建议带可执行的下一步动作卡，采纳率和处理效率才上得去。把大模型当"带理由的评分组件"用，而不是黑箱预言机。

经验三（补充）：把 AI 能力当基础设施而非外挂。通过 AI 网关统一接入、路由、计量，健康度系统既能复用底座算力，又不会因模型抖动影响主线业务，限流信号还能反向驱动底座弹性扩缩容，这是混合架构真正省心的地方。