不是"会用大模型"，是知道一个 AI 功能从设计到能用之间，卡在哪几个具体的地方。
几十款保险产品、上万条 FAQ、两千多条知识切片的知识库从 0 搭起。参与切片规则设计，产出团队通用的切片标准文档。
产品名标准化改写：兼容全称、俗称、错别字与语音转写错误，统一归一到最短别名再送检索。问题分类做意图与专项提示词分层。
保费试算：意图识别 → 多轮对话采集要素 → 调用业务系统接口 → 生成结果链接。让问答从"会说"变成"能办事"。
销售对练：客户标签 → 大模型生成人设 → 实时对话 → 通用与产品双维度 AI 评价。覆盖人设生成、上下文管理、评价生成三条链路。
badcase 归因 → 修复 → 验证的闭环。在固定问题集基线上做量化提升，而不是靠"感觉好像变好了"。
用户点踩 → 自动生成质检任务 → 知识优化 → 下次命中。让知识库自己长大，而不是靠人海不停补。
三件事，都是从模糊的一句话需求，拆到能开发、能验收的程度。
客户的原始需求只有一句话：希望有一个勋章。 原方案是一条主线加四条支线，我做到中途把它推翻了—— 因为那套设计本质在给用户贴定性标签（你是"深度型"还是"广度型"）， 而这批用户是一线销售人员，被系统评价会直接导致他们不用。
重构后的版本从"评价范式"转成"激励范式"： 三条主线（问题深度 / 广度 / 奖励分值）加限定隐藏支线，只奖励不定性。 配套五维能力雷达图，定义 0-10 分计算公式、等级修正系数、四档诊断文案， 以及 AI 综合诊断报告的生成逻辑。再加成长里程碑时间轴与同侪排行榜， 排行榜按机构 / 同岗位 / 全省三个维度做数据隔离。
3 轮客户沟通、2 轮内部评审、十几轮自我推翻，最后落成 79 个功能点、7 个页面的 PRD v3.1。
面向某头部寿险公司一线营销人员的大模型问答平台，覆盖在售与停售共几十款产品。 我负责营销助手端的产品设计：问答架构、Prompt 模板、对练功能、社区模块。
这里面最不起眼但最关键的一件事，是产品名归一化。 真实用户不会打全称，他们打俗称、打简称、打错字、语音转文字还会转错。 我们加了一层改写：把用户问题里所有能识别到的产品指代， 统一替换成最短别名并用方括号包裹，再送去检索。 这一层做完，检索命中率的提升比调模型明显得多。
首批在 1 家分公司试运行，覆盖 100 多名一线人员。
接手这个项目时，所有人的第一反应都是“模型不行”。 但把 badcase 一条一条归因完之后，真正的大头不在生成环节， 而在模型根本没拿到对的知识。检索没命中，后面再强的模型也只能编。
知识库里存的是产品全称，而一线人员在客户面前从来不说全称。 他们说俗称、说简称、打错字，还有很大一部分是语音转文字—— 转错的比例比想象中高很多，而且错得很有规律（同音、近音、方言口音）。
我们加了一层改写：把用户问题里能识别到的产品指代， 统一换成最短别名并用方括号包裹，再送去检索。 方括号不是装饰，它给下游一个明确信号：这几个字是实体，不是普通词。
条款文件不能按字数硬切。保险条款的语义单元是“责任项”， 一个责任项可能只有两行，也可能带三层例外说明。硬切会把“免赔情形”和它修饰的责任切开， 结果就是模型告诉客户“这个赔”，而下一句的免责条款它根本没看到。 这类错在保险业务里不是“答得不好”，是合规风险。
所以我们把切片规则写成了文档，固定下来：以责任项为最小单元， 例外与免责必须随主体一起入片，跨页的责任项手工合并。 这份文档后来成了团队里其他人做知识入库的依据。
一万多条 FAQ，靠人海补是补不完的。我设计了一条闭环： 用户点踩 → 自动生成质检任务 → AI 训练师处理 → 知识优化 → 下次命中。 关键在最后一步：修完要能验证。 很多团队做到“收集反馈”就停了，反馈进了表格就再没人看，那不叫闭环。
对练的底层是四维客户标签生成人设，实时对话用 Redis 管上下文， 对话日志进 ES。但技术不是重点，重点是评价。 如果只给一个总分，用户练一次就不练了——他不知道该改什么。 所以评价拆成通用与产品两个维度，分开给建议。
这个项目里我最意外的一件事
产品名归一化这么“土”的一层，对命中率的提升比换模型、调参数都明显。 它不需要任何前沿技术，需要的是有人愿意去看一万条真实提问。 这让我彻底改了习惯：看指标不行时，先去翻日志，不要先去看模型。
产品智能推荐：8 要素客户画像采集（3 必填 5 选填）→ 推荐智能体 → 1 到 3 套分层方案，附多产品对比表和可以直接用的营销话术。 底层是产品数据模型到实体 / 关系 / 属性三元组抽取，再做知识融合入图库。
同期还做了活动方案自动生成：输入专家资源、工作人员与客户画像， 输出 7 个环节的完整活动流程（含岗位分工）、推荐产品方案与全场景话术，支持导出 PDF。
问答答错了，用户自己能看出来，成本是一次不信任。 推荐推错了，一线人员会拿着错的方案去见客户，成本是一单保单、 甚至一个理赔纠纷。所以推荐这个功能，容错率要比问答低一个量级。
产品之间有一批不容商量的关系：哪两款不能同时投、 哪款必须附加在主险上、哪些人群直接拒保。 这些是二元的，不存在“可能行”。 把它们交给向量相似度去算，等于把硬约束变成了概率——这是掘坑。
所以底层走知识图谱：从产品数据模型抽实体 / 关系 / 属性三元组， 知识融合后入图库。图里的关系可以校验、可以追溯， 出了问题能指到具体哪条边错了。模型只负责表达，不负责判断能不能卖。
最初的设计是 8 个全填。试了一轮之后发现没人愿意填完—— 一线人员是在客户家的沙发上掏出手机用这个工具，不是坐在办公室里。 所以拆成三个必填（影响方案方向的）+ 五个选填（只影响精度的）， 填三个就能出方案，填得多方案更准。
输入专家资源、工作人员与客户画像，输出七个环节的完整活动流程， 每个环节带岗位分工，配推荐产品方案与全场景话术，支持导出 PDF。 这个功能的设计重点不在生成，在“导出 PDF”： 机构经理要拿着这东西开晚会、发微信群。不能导出，就只能在系统里看一眼，用不起来。
这个项目目前的真实状态
还在进行中，没有结果可报。知识图谱部分已经跑通， 但完整链路的推荐准确率还没有稳定基线。我不想把未完成的事写成成绩。
一次失败复盘
一个大模型问答项目，客户的验收标准是问答准确率 95%。 我们从 60% 打到 75%，逐环节重建了意图识别、知识检索、答案生成和兜底策略。 最后没有达到 95%，项目以未达成告终。
我后来想清楚一件事：95% 在这个场景下是不可达的。 几十款产品、上千条知识切片、用户用俗称和错别字自由提问——这是开放域问答， 行业里做得好的团队也在 75% 到 85% 之间。95% 只存在于封闭域小范围问答。
所以真正的失败点不在于我们只做到 75%， 而在于立项那天没有人把"准确率"这三个字拆开： 它怎么定义、分母是哪个问题集、95% 有没有物理可能、达不到怎么算。 需求约束没在开始时对齐，后面所有的努力都在还债。
这是我现在做 AI 产品最先做的一件事：先跟客户一起把指标拆到可验证，再谈方案。 能拒掉一个不可达的承诺，比多做三个功能有用。
在建 · 自己动手
前台负责讲清楚我是谁，后台是一套自己写的轻量 CRM： 线索进来自动分层、跟进状态可推进、每一次沟通都有记录。
因为表格记的是"有人来过"，CRM 记的是"这个人走到哪一步了"。 前者是日志，后者才是资产。
我不是科班出身。本科读的旅游管理，2010 年入行做软件测试， 做了十年测试、六年项目管理，行业一直没离开过保险—— 承保、核保、保全、理赔、代理人行销、营销活动，业务链路基本都走过一遍。
2025 年起我转到 AI 产品。这两年做的事，说白了就一件： 把大模型塞进保险业务的真实缝隙里，然后跟"它答得不对"这件事反复搏斗。 知识切片怎么切、用户把产品名打错了怎么还能检索到、 模型答错之后有没有一条修回来的路——这些细节决定一个 AI 功能是能用，还是只能演示。
之前六年做项目管理，最多同时带 8 个并行项目。那段经历留给我的不是管理头衔， 而是一个习惯：为交付结果负责，而不是为过程好看负责。
本站所有项目内容均已脱敏，不涉及具体客户名称、系统截图与业务数据。
如果你在招 AI 产品经理，或者手上有个大模型项目正卡在"效果不达标"这一步，欢迎找我。我在北京。