从 3 个可运行 Demo 到 1 条可执行闭环：保险 AI 工程化复盘（含数据模型与事件流）
很多 AI 项目都会经历同一个阶段：
· 单点功能做出来了；
· 页面也能演示；
· 但业务同学用几次就回到老流程。
我们这次复盘的核心也一样：
问题不是“做不出能力”，而是“能力无法串成闭环”。
项目背景（脱敏）：
· Module1：KYC 自动提取（对话/音频 -> 结构化字段）
· Module2：客户意向评分（四维评分 -> P0/P1/P2/P3）
· Module3：会员权益匹配（活动推荐 + 升级建议）
每个模块都能独立跑，但系统层面有明显断点。
这篇讲工程视角下，我们如何从“模块拼盘”走向“闭环流水线”。
1. 先定位问题：为什么模块可用但系统不可用
1.1 主键不统一，跨模块客户映射不稳定
三个模块各用自己的数据样本和客户标识，导致：
· Module1 的 KYC 结果很难自动触发 Module2 重算；
· Module2 的高意向名单无法自然推给 Module3；
· 同一客户在多个模块像不同实体。
这类问题不显眼，但会持续消耗系统可信度。
1.2 KYC 结果无“版本语义”，无法形成长期认知
KYC 本质是增量更新，不是一次性抽取。
如果结果只停留在本次返回值，不做版本、时间戳、证据索引，系统就没法支持多轮决策。
1.3 输出停留在“分数”，没有转成“动作”
业务不执行“82分”，业务执行的是：
· 什么时候联系；
· 用什么方式；
· 先聊什么。
所以输出结构必须动作化，而不只是指标化。
2. 架构调整：先打通最短闭环
我们没有继续扩功能面，而是先定义最短闭环：
一次沟通
-> KYC更新
-> 意向重算
-> 推荐刷新
-> 生成跟进任务
-> 人工执行并回写
这条链路每天稳定跑，系统才有复利。
3. 数据模型：统一客户档案是核心中台对象
先给一个简化结构：
{
"customer_id": "C10023",
"profile": {
"age": 68,
"region": "上海"
},
"kyc_snapshots": [
{
"version": 4,
"updated_at": "2026-03-05T09:12:01+08:00",
"fields": {
"retirement_income": "8000/月",
"family_structure": "子女异地"
},
"evidence_refs": ["conv_20260305_012#120-145"]
}
],
"intent": {
"score": 79,
"priority": "P1",
"reasons": ["近两次主动询问养老方案"],
"next_action": "48小时内电话跟进"
},
"recommendations": [
{
"type": "activity",
"name": "养老规划沙龙",
"why": "与客户当前关注点匹配"
}
],
"tasks": [
{
"task_id": "T20260305001",
"owner": "sales_01",
"due_at": "2026-03-07T18:00:00+08:00",
"status": "todo"
}
]
}
重点不在字段多少，而在三件事：
· 上下游都围绕 customer_id 对齐；
· 关键结论都能追溯版本与证据；
· 输出天然可转任务。
4. 事件流：让模块从“同步调用”升级为“异步联动”
4.1 事件设计（轻量）
· kyc.updated
· intent.updated
· recommendation.updated
· task.created
4.2 处理流程（伪代码）
def on_kyc_updated(customer_id):
intent = intent_service.recompute(customer_id)
bus.publish("intent.updated", {"customer_id": customer_id, "intent": intent})
def on_intent_updated(event):
cid = event["customer_id"]
intent = event["intent"]
if intent["priority"] in ["P0", "P1"]:
recs = recommendation_service.refresh(cid)
bus.publish("recommendation.updated", {"customer_id": cid, "recs": recs})
def on_recommendation_updated(event):
task = task_service.create_followup_task(
customer_id=event["customer_id"],
recommendations=event["recs"]
)
bus.publish("task.created", task)
即使先用本地队列或数据库轮询实现，也比“页面人工跳转”更稳定。
5. 接口契约升级：从“返回结果”到“返回可执行对象”
5.1 KYC 接口建议
至少返回：
· fields
· confidence
· evidence_refs
· version
5.2 评分接口建议
{
"customer_id": "C10023",
"score": 79,
"priority": "P1",
"top_reasons": ["活动参与频次上升"],
"next_action": {
"channel": "call",
"within_hours": 48,
"talk_points": ["先确认家庭决策角色"]
}
}
5.3 推荐接口建议
除了“推荐什么”，必须给：
· 推荐依据；
· 不推荐依据；
· 当前缺失信息。
否则业务很难真正采纳。
6. 可观测性：闭环稳定运行的最低配置
建议至少做这 6 个指标：
· kyc_field_coverage（KYC字段完整度）
· evidence_coverage（证据覆盖率）
· priority_followup_sla（P0/P1 跟进时效）
· recommendation_adoption_rate（推荐采纳率）
· no_evidence_decision_ratio（无证据关键结论占比）
· cross_module_link_success（跨模块联动成功率）
其中最关键的是：
无证据关键结论占比，这个指标高，系统可信度会快速下滑。
7. 这轮迭代后的经验
7.1 先做闭环，再做上限
一个每天可执行的闭环，价值大于十个偶发可演示能力。
7.2 先做动作语义，再做指标语义
先回答“今天该做什么”，再回答“模型为什么这么判断”。
7.3 先做组织可协同，再做单点最优
在保险这类强协同场景，系统的目标不是“单点最优”，而是“多人协同可复核”。
结语
从工程角度看，Demo 到生产的分水岭不在模型参数，而在这三件事：
· 数据主键是否统一；
· 关键链路是否闭环；
· 结果是否可执行且可追溯。
我们现在还在迭代，但至少已经完成了一次关键转向：
从“做功能”转到“做流程”。
这一步，才是系统真正开始产生业务价值的起点。
