一、客服问答库最容易死在"写得很全，但没人用"
很多公司上线客服机器人，第一步是让运营把常见问题写一遍。
结果写了几百条，用户还是答不上。问题不在数量，在写法：每条答案都在"叙述"，而不是"解决"。
二、先分类：四类问题
一、规则类。 退换货政策、发货时间、发票。特点是有标准答案，必须一致。
二、流程类。 怎么下单、怎么改地址。特点是有步骤，需要顺序正确。
三、故障类。 为什么没收到、为什么登录不上。特点是要先定位原因。
四、情绪类。 抱怨、抱怨、抱怨。特点是先接情绪，再给方案。
四类写法完全不同。混在一起写，模型输出的东西就会四不像。
三、每条问答的固定结构
```
用户可能的说法（列3种以上，含错别字）
一句话直接答案
需要时补的判断条件
下一步该怎么做
答不了时转人工的条件
```
最后一项最容易被漏，却是最有价值的一项。
一个好的客服知识库，不是什么都答，而是清楚知道什么时候不该答。
四、让AI参与的两个阶段
阶段一：扩写。 人写核心规则，AI 扩出不同说法。这一步效率很高。
阶段二：找洞。 把真实对话历史交给模型，让它总结"哪些问题在知识库里找不到答案"。这一步比扩写还值钱。
注意：不要让模型直接改政策。政策是人的责任，改错一句就是赔偿风险。
五、效果怎么衡量
不要看"回答了多少条"，看三个指标：
一次解决率、转人工率、风评反馈。
第一个反映准不准，第二个反映边界清不清楚，第三个反映语气有没有问题。
六、一个技术前别漏
问答库要接到页面上，绕不开部署。如果你打算自己搭一个小服务，容器和反代是最少的两件套。
BackendWiki 里有 Docker 与容器化的 32 节课、Nginx 反向代理、还有宝塔面板与 1Panel 的对照，初学者照着搭一遍就能把服务跑起来。它把"从零到一台活着的云服务器"也单独写成了教程，做应用落地时这套东西比写提示词更卡人。
七、一句总结
客服AI的价值不在"像人"，在"不胡说"、"知道停"。
边界写得越清楚，用户反而越信任。