3.2 提示词调试：让回答带来源、不胡说

工作流跑通后，我最怕看到的回答长这样：用户问能不能开发票，大模型回了一段洋洋洒洒的政策解读，细节全是编的，文档里根本没有。客服组的人看完说，这比答不上来还可怕，因为说得像真的。

提示词调试是整个第三篇里迭代次数最多的环节。和写代码不同，提示词没有编译器帮你抓错，只能靠一批固定问题反复测、对比、打分。它是这本书里最不像工程、最像手艺的部分，但偏偏又是一旦上线就天天面对用户的部分。这一节把我用顺的模板结构、调试方法、幻觉治理清单和版本管理经验分享出来，都是可以直接照做的流程，不涉及任何玄学，也没有什么提示词咒语，所有效果都有对应的对照数据。

提示词模板的五个组成部分

我最后的提示词模板分五块（讲结构，不是逐字原文）。模板不是一次写成的，是每块都被用户骂过之后补上的：先有角色和输出，发现编造才加约束，发现答非所问才规范注入位，发现硬邦邦的回答伤人才补兜底指令。五块的顺序也是踩坑顺序。

五部分里最容易被忽略的是知识注入位和约束的顺序。我的经验是：先约束，再注入，最后说格式。先告诉模型只能依据给定内容回答，再把切片给它，最后规定输出样式。顺序对了，编造的情况明显减少。这个排列是有道理的：模型读到约束时还没有素材，约束会被当作规则记住；先给素材再给约束，素材的细节容易把规则挤掉。

角色设定也别写多。我最初写了一句资深客服专家，结果回答动辄建议您联系我们的专业团队，啰嗦不说还把简单问题复杂化。后来改成简洁的公司客服助手风格，回答才正常起来。角色设定本质是给模型一个说话的框架，框架太夸张，回答必然跟着夸张；框架克制，输出才克制。这和招人一个道理：你把岗位描述写成金牌销售，招来的人张口就是让您体验尊贵服务。

同一个问题，调试前后

提示词调到什么程度算及格？我的方法是固定一批问题，每次改完提示词全部重跑，逐条对比回答。下面是最典型的三条：

对比表打印出来挂在工位上。新客服入职先看这个，知道哪些回答能信、哪些得留心。表格本身也是给客服组看的沟通材料：他们不用懂提示词，但要知道每类典型问题当前的可信边界在哪里。幻觉不可能完全消灭，但可以被压到一个可抽检的水平。

这张表还有一个用途：作为回归基线。每次改完提示词，除了跑固定问题集，还要确认这三条典型问题的回答没有退化。调试前回答好理解、调试后回答可信，这条演进方向一旦倒退（比如又开始编价格），说明改动方向有问题，立即回滚。

幻觉治理清单

治幻觉我没有绝招，只有一份检查清单，每次改完提示词逐条过：

• 引用来源：回答必须标注依据，例如开头写明依据公司文档。带不上来源的回答，本身就是可疑信号，直接进抽检。
• 主动认怂：超出知识范围时，明确回复资料未覆盖，并给出下一步建议（转人工或换个问法），不许硬编。认怂不丢人，编造才丢人。
• 要点式输出：每条回答控制在三到五个要点，每个要点不超两句。模型一旦开始写长句，编造概率明显上升，这几乎是个开关。
• 阈值过滤：检索得分低于阈值的切片不进入提示词，宁可不答也不拿低质量内容冒险。
• 人工抽检：每周抽一批带标记的回答复核，幻觉率作为 5.1 评估指标之一持续跟踪。

清单执行两周后，幻觉率明显下降：以每百条回答计，抽检命中的编造从约二十三条降到五条左右。成本变化不大，因为省下的 token 转化成了更短的回答，更难得的是客服组开始把抽检当成常规动作，而不是心血来潮的抽样任务——这件事后来直接长成了 5.1 评估指标体系的一部分。

清单本身也在演化。运行两个月后加了两条：一条是回答里如果出现具体数字（价格、天数、税率），必须能在切片里逐字找到对应来源，否则不给答——数字幻觉最伤信任，编个毛利率出来用户当真；另一条是回答完成后自检，让模型对照切片快速核对有无超出范围，算力花得不多，但对无中生有的抑制明显。剩下的主要是两类：文档本身有冲突的（新旧两版政策并存），和问题模糊导致切片召错的（问发货问到物流条款）。前者靠 5.2 的知识库清洗解决，后者靠 3.4 的多轮澄清解决。

调试日志与版本管理

提示词改了十几版之后必然会乱：哪一版改了什么、为什么改、效果如何，全靠脑子记肯定不行。我做了两件事。

一是给每版提示词编号并存调试日志，每条记录包含：改了哪一块（五部分中的哪部分）、改动原因（比如某问题幻觉率高或客服反馈语气生硬）、验证问题集的抽检结论、是否替换线上。后来某次回答质量突然下滑，查日志发现是前两天一次随手改动引入的，十分钟就回滚了。没有日志的话，这种回溯根本无从谈起。

二是把提示词和代码一样纳入变更管理：我改完，客服组派一个人用固定问题集跑一遍确认无回归，才替换线上。提示词看起来只是一段文字，但它直接决定产品对用户说的话，不能谁想改就改、什么时候想改就改。固定问题集我也维护了一份，覆盖高频问题、超范围问题、模糊问题和边界问题四类，现在大约四十条。

三是留一份回滚稿。每次替换线上提示词之前，把当前线上版完整备份进归档，连同调试日志一起。线上出事的第一反应不是修，而是先回滚到上一版，止血永远优先于 debug。日志里已经记录了上次的教训，翻一遍心里有底。

这段经历给我一个习惯：提示词一动就跑全集，哪怕只改了一个标点。十几版调试里有三版是改小地方引入大问题的，全集回归一次两分钟，省下的事故处理时间不可估量。

给同事看日志时还有个意外收获：日志本身就是给客服组最好的变更公告。每周例会我把这周的提示词改动和原因过一遍，客服组立刻知道哪些类型的问题回答变好了、哪些仍需他们人工盯，下次再遇到类似问题处理起来心里有底。比起在群里发一条冷冰冰的更新说明，这套机制不知不觉建起了技术侧和业务侧的信任——他们看得见我们在改，也就更愿意提反馈，而反馈正是 5.2 知识库迭代流水线最重要的输入。

固定问题集：调试的地基

靠感觉调提示词必翻车的感觉我太熟了。今天心情好测两条都顺，明天换两条又全崩。所以我先做的不是写提示词，而是攒问题集。

问题集分四类，每类十条左右，共约四十条。第一类是高频问题，从客服过往工单里按频率挑，比如发票、发货、退款这老三样。第二类是超范围问题，知识库肯定没有的，比如下季度有没有新品、能不能找老板通融，专门测兜底。第三类是模糊问题，一句话可以有两种理解，测模型会不会先澄清而不是先瞎猜。第四类是边界问题，和知识沾边但要求文档里没写全的，比如能不能快一点发货，测模型顶不顶得住用户的施压。

问题集是动态的：每周客服组把出现的新问题补进来，答得明显有问题的旧问题单独标记成重点。每次改提示词，全集重跑一遍，把结果归档，和上一版对比哪些类目进步、哪些退步。这套集子还有一个副产品：客服组看着问题集，第一次直观感受到智能体的能力边界画在哪，比口头解释清楚得多。

改提示词的节奏

提示词不是想改就改。我给自己定了两条节奏，上线前和上线后各一条。

上线前是冲刺节奏：一天可以改好几版，每版都全量跑问题集，记录哪类问题变好、哪类变差。这时候追求的是快速逼近及格线，粗糙没关系。

上线后是维护节奏：提示词线上版至少稳定一周才允许动，改动必须有明确的触发原因（客服反馈、抽检发现、知识库变更），并且走评审。我见过太多团队上线后第一天看回答不顺手就改一版，改完引入新问题再改回来，用户成了免费测试员，这种反复对信任的消耗比幻觉本身还大。

一点补充

提示词不是越写越长才好。我在中后期反而做减法：把过长的约束合并，删掉模型本来就能遵守的废话。提示词越长，模型真正注意的边际越弱，维护成本也越高。

大模型本身的选型会影响提示词写法，不同模型对约束的理解服从度不同，换模型往往要重调一遍，这块可以看DeepSeek 工具链。日常写文档、整知识素材时我也会用 AI 辅助提升效率，方法论见Claude Code 指南，但给用户看的提示词一定是我逐字调过的，不复用生成稿——工具调用链路里怎么用 AI 辅助写测试脚本，3.3 那一节也有例子。

延伸阅读

• 笔记知识库：提示词版本多了，知识管理方法论可以借用。
• NAS 家庭服务器：想在本地环境验证提示词与知识库搭配的备选方案。