能力主线：我的经历如何服务于 AI 产品岗位
四段经历不是并列的"我做过什么"，而是一条层层递进、最终指向 AI 产品落地的主线。
后端工程
银行支付、售票预约系统开发。→ 能判断系统接口、数据流、模型调用与工程可行性，与研发/算法对话有共同语言。
大数据平台
融合大数据平台，统一多业务线离线数据。→ 能做数据口径、指标评估、效果归因与策略迭代。
算法场景（DSP竞价）
广告竞价平台从调研到上线。→ 理解算法推荐、竞价策略与数据驱动决策，知道算法类产品怎么推进。
AI产品落地（主线）
5G消息平台智能客服与模板智能生成。→ 把前三段能力汇成一次完整的 AI 产品从0到1。
核心项目：5G消息平台智能客服与模板智能生成
AI产品化 / 从0到1 · 本次转型的核心主线项目
把"人工做模板 + 关键词客服"升级为"大模型生成 + RAG智能问答 + 人工兜底"
平台原有能力停留在基础消息与关键词匹配阶段。我负责从业务痛点出发，判断哪些环节适合大模型、哪些必须走规则，并把它设计成一条可评估、可迭代的产品链路。
- 我的角色
- AI产品负责人
- 负责范围
- 需求定义 / 方案设计 / Prompt设计 / 效果评估与迭代
- 协同对象
- 算法·研发 / UI / 运营 / 销售
- 时间
- 2021.08 – 至今
用户 A · 企业SaaS客户运营人员
需要反复制作 5G 消息模板，人工制作一个模板需 2–4 小时，产出慢、样式不规范、复用性差。
用户 B · 终端用户（咨询者）
客服依赖关键词匹配，问题稍复杂就答不上来，转人工率高、响应慢，体验断点多。
产品服务路径图
从用户提问到会话归档的完整服务链路，橙框为判断节点，绿框为人工兜底。
用户提问
多渠道接入
意图识别
分类与分流
知识库检索
RAG 语义召回
生成回答
Prompt 约束输出
置信度判断
阈值 + 风险规则
直接回复
高置信自动应答
核心功能模块
六个模块共同支撑"能答、答得准、答不了能兜住、错了能改"。
模板智能生成
用大模型把自然语言需求转成规范模板，支持样式与行业适配，把小时级制作压到分钟级。
智能问答（RAG）
文档清洗 → 语义分块 → 向量化入库 → 语义召回，让答案来自知识库而不是模型"编"。
意图识别与分流
将问题分为知识问答 / 操作请求 / 闲聊 / 投诉四类，不同意图走不同处理链路。
人工接管
置信度低于阈值或命中高风险场景时强制转人工，附上下文摘要，坐席无需重复问一遍。
效果评估
标注测试集做样本评估，覆盖率、接通率、幻觉率按统一口径统计，避免"数字好看说不清"。
bad case 回流
把线上错答结构化分类，分别回流到知识库、检索策略与 Prompt，形成迭代闭环。
用户流程图（含人工接管机制）
大模型不是"全权接管"，而是在明确边界内工作——这是本项目的核心设计原则。
① 用户发起提问
进入智能客服会话，输入自然语言问题。
② 意图识别与分流
模型判断问题类型，分四条链路处理。
③ 知识问答链路：检索 + 生成
从知识库语义召回相关片段，按 Prompt 约束生成回答，要求"有依据才答"。
④ 置信度判断（关键分叉）
结合检索相似度与生成置信度，叠加高风险场景规则。
⑤ 人工接管与归档
坐席处理完成后，会话统一归档；被人工修正的问答进入 bad case 池，反哺知识库与 Prompt。
效果指标与口径卡
上线前先定口径——每个数字都能说清"怎么算出来的"。
指标口径说明
| 指标 | 口径定义 | 数据来源 |
|---|---|---|
| 模板生产效率 | 单个模板从需求到可用的耗时对比（改造前人工制作 vs 改造后生成+微调） | 运营侧制作日志 |
| 智能客服覆盖率 | 命中知识库且被判定为正确回答的会话数 ÷ 总会话数 | 会话日志 + 人工抽检 |
| 人工接通率 | 转人工会话数 ÷ 总会话数（下降 = 更多问题被自动解决） | 客服系统工单 |
| 幻觉率（监控项） | 回答中无知识库依据的会话数 ÷ 回答总数 | 样本评估 + 抽检 |
bad case 回流闭环
不靠感觉调 Prompt，而是把线上问题结构化回收、定向修复、回归验证。
会话归档
全部会话（含转人工）落库，标注是否被人工修正。
四类归因
把错答拆成可定位的原因，而不是笼统的"答得不好"。
定向回流
知识缺失→补知识库；检索失败→调分块与召回策略；生成错误→改 Prompt；意图误判→优化分类样本。
回归验证
修复后在标注测试集上回归，确认不引入新问题再上线。
关键设计决策
产品经理的价值不在"用了大模型"，而在这些判断上。
方法论沉淀
可迁移到其他大模型应用场景的三条原则。
先判断技术边界，再谈产品方案
不是所有场景都适合大模型。先分清哪些环节适合 LLM、哪些适合 RAG、哪些必须走规则，方案才站得住。
指标口径先于效果宣传
上线前先定义每个指标怎么算、数据从哪来，避免出现"数字好看但被追问就说不清"的尴尬。
用 bad case 驱动迭代
把线上问题结构化归因、定向修复、回归验证，比凭感觉反复调 Prompt 更可控、可复用。