去年帮朋友的公司做过一个客服聊天机器人，目标很朴素：把产品文档喂给 AI，让它自动回答客户咨询。项目最后上线了，但中间踩的坑足够写一篇文章。下面用问答形式，把这次经历里最值得知道的东西讲清楚——先说好，这篇是"概述"，帮你建立完整的认知地图，具体代码实现是另一个层面的事。
问：2025 年搭一个 AI 聊天机器人，技术路线有几种？
答：主流就三条。第一，直接调大模型 API（如 OpenAI、Claude 的 API），自己写对话逻辑，适合有开发能力的团队；第二，用 RAG（检索增强生成）：把你的文档切成片段存进向量数据库，用户提问时先检索相关片段，再让大模型基于片段回答——这是目前客服、知识库场景的事实标准；第三，微调模型，成本高、见效慢，除非你的场景非常特殊，否则 2025 年基本没人首选这条路。我们最后用的就是 RAG。
问：RAG 听起来很美，实际坑在哪？
答：最大的坑在"知识库"三个字上。我们一开始直接把 200 页产品手册丢进去，结果 AI 答非所问。后来才明白：文档要先清洗——去掉页眉页脚、合并碎片段落、按语义切分，检索质量才上得去。第二个坑是"幻觉"：当知识库里没有答案时，大模型会一本正经地编一个。我们的解法是加一道"置信度门槛"，检索不到相关内容时，老老实实回答"这个问题我不确定，已转人工"，而不是硬编。
问：成本大概什么量级？
答：比很多人想象的便宜。向量数据库有免费 tier，大模型 API 按量计费，一个日活几百人的客服机器人，一个月 API 花费通常就是一顿饭钱。真正的成本是人力：清洗文档、写评测集、持续优化提示词，这些才是大头。想省钱的话，提示词工程是性价比最高的投入，这篇提示词工程入门 值得先看。
问：System Prompt 在机器人里起什么作用？
答：它是机器人的"人设说明书"。我们在系统提示词里写明：你是谁、能回答什么、不能回答什么、不知道时怎么说、不许编造。一个好的系统提示词能解决一半的幻觉问题。具体写法参考这篇 System Prompt 详解。
问：上线前必须做的三件事是什么？
答：第一，准备 50-100 个真实用户问题做评测集，每次改完提示词或知识库都跑一遍，防止改好一个坏一片；第二，做"对抗测试"，故意问知识库里没有的东西，看它会不会编；第三，留好人工接管入口，AI 客服的定位永远是"先挡掉 80% 的重复问题"，而不是"替代人工"。
问：向量数据库怎么选？
答：2025 年选择很多，结论也简单：小项目直接用大模型厂商或云服务自带的向量检索，零运维；数据敏感、想完全自控的，用开源方案自己搭。我们一开始自建，后来发现运维成本比 API 账单还贵，果断切回托管服务。记住：你的核心竞争力是知识库质量，不是数据库运维。
问：评测集具体怎么做？
答：分享我们的做法：从真实客服记录里挑 100 个高频问题，人工写出标准答案。每次改完提示词或知识库，跑一遍评测，统计"答对、答偏、幻觉"三类比例。没有评测集的优化都是玄学——你以为变好了，其实只是运气好。这个习惯，是区分"玩具"和"产品"的分水岭。
问：个人开发者能玩吗？
答：能，而且 2025 年的门槛是历史最低。有不少开源框架把 RAG 流程封装好了，配个 API Key 就能跑起来。建议从"个人知识库问答"这种小场景开始：把自己的笔记、收藏的文章喂进去，做一个"只懂你的 AI"。跑通之后再考虑商业场景。
复盘这次项目，最大的教训就一句话：AI 聊天机器人 20% 是模型，80% 是工程——知识库质量、提示词设计、评测流程，这些"脏活累活"决定了最终体验。模型年年换，这些基本功不会过时。想继续深入，可以看看 DALL·E 3 的提示词技巧 找找提示词的感觉，或者用 Gamma 把项目方案快速做成演示文稿。