给微信小程序做 AI 客服：思路、落地步骤，以及提示词是怎么改短的
我们是一个医疗方向的小程序。用户进来问的大多不是开放话题，而是「试用怎么开」「怎么退款」「晚上睡不着该看哪一个」。这些话如果都进人工，重复很高；如果把大模型直接嵌进小程序，价格、试用规则和用药建议又容易被说错。
我们要的不是一个通用聊天机器人，而是小程序里的一层文字客服：能答流程，能按用户的困扰指向小程序里已有的产品，并且在不该回答的时候停下来。
一、思路
先把小程序里已经有的三件事分开。文字客服是免费的，用来挡标准化咨询。目标是少打人工电话，不是把每句话都变成推销，也不是做诊断。
然后把一件回复拆成三个人各干一件事。
DeepSeek 只负责把话讲顺。它听得懂「翻来覆去睡不着」，也听得懂「怎么退」。它不保存商品是否上架，也不拿用户的登录态。
AnythingLLM 负责工作区和知识库。运营把说明写成 Markdown，嵌入之后，用户每一句先检索相关段落，再连同系统提示词交给 DeepSeek。对话模型和嵌入模型分开配。DeepSeek 只聊天，文档向量化用 AnythingLLM 自带的嵌入。指错了，文档上传会失败。
小程序后面的 Java 服务负责不该交给模型的部分：谁在说话、危机和索要处方要不要直接返回固定话术、回复里的思考过程要不要剥掉、聊天记录存在哪。小程序只调自己的网关，不看见 AnythingLLM 的地址和密钥。
知识库和提示词也要分开。文档里写事实：产品是什么、退款怎么走、哪种困扰对应哪个产品。提示词里写角色：称谓、长度、何时只推一个产品、何时停止推荐。提示词不要当成文件上传进知识库，否则改一句语气就要把整库重新嵌入。
推荐的思路同样简单。用户说出自己的困扰，同一条回复里先接住，再只提一个主推产品，并告诉他去小程序里看。纯百科问题以科普为主，结尾轻带一句即可。出现需要就医的信号时，只做转介，不再推产品。AI 不写医生推荐记录，也不参与分销。
二、一步步怎么做
第一步，先让模型和知识库跑起来，先不接小程序。
在服务器上用 Docker 跑 AnythingLLM，数据目录挂出来，管理端口只给内网或 SSH 隧道。在设置里把对话模型配成 DeepSeek，我们用的是速度和费用更合适的 flash，而不是更重的 pro。嵌入模型选内置的那一项，保存后不要再频繁更换，换了就要整库重新嵌入。
建一个工作区，例如「客服」。记下它的 slug。这个短名不总是显示在界面上，用开发者 API 列出工作区就能看到。后面 Java 调用时，路径里用的就是这个 slug。
此时可以在工作区里直接打字。没有文档也能聊，但答的是常识，还不是你们的规则。
第二步，把小程序接到 Java，而不是接到 AnythingLLM。
小程序发 POST /api/v1/ai/chat，请求体里只有当前这一句。网关校验登录，生成会话号 xxx-u-{用户ID}，客户端不能自己传。然后请求：
POST {AnythingLLM}/api/v1/workspace/{slug}/chat（自己的接口）
请求体是当前这句话、mode=chat，以及这个会话号。密钥放在服务端配置里。本地开发时，Java 配置的地址要写成你电脑浏览器能打开 AnythingLLM 的那个端口。远程容器内部是 3001，本机隧道如果是 3002，本地就写 3002。
模型成功返回后，去掉思考过程，把用户的问题和助手的回答写入自己的消息表。小程序上的历史只读这张表，分页拉取，不读 AnythingLLM 的历史接口。模型续聊仍靠那个固定会话号。两边不要互相代替：删掉页面上的记录，模型还记得上文；只在网页里删对话，也不等于清掉接口侧的会话。
第三步，写知识库，并真正嵌入。
按主题拆成多份 Markdown，不要丢一个大 PDF。我们拆成了 20 份：平台和品牌、产品总览、各个产品、使用方法、禁忌、FAQ、费用和退款、隐私、科普、就医提示，以及一张「困扰和主推产品」对照表。
对照表是推荐能稳定的原因。没有这张表，模型会一次甩出好几个产品，或者报一串价格。
上传后要移入工作区，再执行保存并嵌入，等文档出现完成标记。系统提示词、编写规范、上传说明不要放进这个工作区。
第四步，把提示词贴进工作区的聊天设置。
打开工作区的 Chat Settings，找到 System Prompt，把完整提示词粘贴进去并保存。这一步和上传文档不是同一件事。
第五步，用固定问法验收，再调检索参数。
Java 只传当前这句话，Temperature、最大长度、检索条数都在工作区里调。起点可以是：Temperature 0.5，不要超过 0.8，否则价格和试用天数容易被编出来；检索条数 3 到 5，条数太大时，模型会把 FAQ 整段抄出来；最大回复长度若能设，放在 512 到 800，用来压住长文。
每次改完，至少问三句：「怎么退款」「最近XXXX」「XXXX能试用吗」（根据自己的业务情况而来）。退款要短，且口径和文档一致；工作区网页和 Java 接口各测一遍，避免网页里调好了、接口走的仍是旧会话。
三、提示词是怎么一轮轮改短的
第一版只写了身份和医疗边界：你是XX（自己的平台）的助手，不做诊断，不开药，不确定就说以小程序或医生为准。这样能把模型从「什么都答」拉回到客服，但回复像公告。用户问怎么退款，它会把知识库里的步骤逐条贴出来；用户说XXX问题，它先讲XXX机制，再列好几个产品；每一轮都重新自我介绍，正文里再重复一遍页脚免责声明。
原因不在 DeepSeek 特别啰嗦，而在提示词只有「要合规」，没有「要像聊天」。RAG 检索到的段落越完整，模型越倾向于原文照搬。
第二轮补了一句风格：默认短，像微信里一位温和的助手，大约 80 到 150 字，先接住用户的原话，同一会话不要每轮自我介绍，知识库用自己的话压缩。语气上用「您」，去掉「亲」、表情和「综上所述」「不在服务范围」这类公文腔。
这一轮观感好了一些，长度仍不稳。同一句「XXXX」，有时一百来字，有时又展开成清单。只写「尽量简短」，模型会把它当成建议。
第三轮改成按场景给硬上限，并配正反例。反例告诉它哪一种结构是错的，正例只给骨架，并写明不要照抄。
退款的反例是罗列五六条步骤。正例是两句话：未使用可在 7 天内申请退款，具体以小程序订单和客服说明为准。
XXX的反例是先讲机制、再列多个产品。正例是：先用一句接住，然后只指向小程序里的产品，试用规则以产品页为准。整段不超过 100 字，禁止第二个产品，禁止没问就报价。
FAQ 和政策不超过 120 字，最多写两三个要点，禁止超过三条的列表。天气、明星这类拒答不超过 80 字：一句拒绝，一句引回自己的产品。如果已经提到就医或紧急电话，就不再推产品。超长时删举例和列表，留下转介和核心答案。
正反例比再写十句「请简短」有用。模型学的是结构：先接住，再给一个动作，然后停。
第四轮把推荐写进提示词，而不是指望它自己从 20 份文档里归纳。规则是：先查对照表。根据问题对应相应产品；已经购买的，引导到购买的产品。用户没问价格，不报全价。知识库里的就医信号出现时，只转介，不提产品和试用。试用天数只有文档里写了才能说，否则一律「以小程序产品页为准」。禁止「一定治愈」。
第五轮是和 Java 对齐，避免两层抢着说话。提示词里写明：危机、明确的精神症状、索要药名剂量和处方，可能根本到不了模型，到了也不要陪聊或评估。怎么减药、能不能代替药物，仍然由模型和知识库回答，口径是不能指导、须遵医嘱。明星和天气可能在服务端就被柔和拒绝。用户只说「好的」「需要」时，24 小时内有过正常回复就接着聊。这样提示词不会再把服务端已经拦住的情况，重新答成一篇科普。
改提示词的顺序可以记成四步：先定不能说什么，再定每类问题最长多少字，然后用一对正反例钉住结构，最后用固定问法看字数和有没有多推产品。只改提示词、不重新嵌入文档；只改文档、不改提示词。两处同时改，就分不清是检索变了还是指令变了。
改完再问那三句。我们联调时，「怎么退款」大约 120 字，带退款口径而不是长列表；「出现平台相关的内容」大约 125 字，出现小程序入口；「XXX产品能试用吗」大约 105 字，没有编出具体试用天数。字数仍略高于 100 的上限时，继续删提示词里的举例，把检索条数降到 3 到 5，而不是把 Temperature 调高。
收束
这条链路里，思路只有一句：模型负责说，知识库负责事实，服务端负责不该说的话。落地时先通 DeepSeek 和工作区，再让小程序只打自己的接口，然后嵌入按主题拆开的文档和一张产品对照表，最后把提示词从「合规公告」改成「按场景限长，并用正反例规定结构」。提示词不求一次写完。每一轮只解决一种坏回复：太长、照抄 FAQ、一次推多个产品，或在该转介时还在推荐。