客户问：“你们这个方案能查订单吗？”数字人回答“支持”，工作人员却发现，它引用的是另一款方案的介绍。资料没有凭空捏造，但用错了对象，照样会误导客户。
这是一种值得提前测试的情况：企业把产品手册、销售PPT和售后文档上传后，数字人未必就能稳定回答。它可能找不到关键段落，漏掉适用条件，也可能同时拿到新旧两个版本。
上一篇讲了AI数字人的角色提示词。这一篇接着解决“回答依据从哪里来”。提示词规定怎么接待，知识库提供能据以回答的资料；两者都不能代替企业对事实的确认。
先确定要回答什么，再决定上传什么
准备AI数字人知识库，不必从收集全部公司文件开始。先整理销售、客服最近经常被问到的问题：产品适合谁、哪些功能已确认、怎么接入、收费包含什么、出现问题找谁处理。再为这些问题找到经过确认的依据。
第一批内容可以包括现行产品说明、已审批的公开收费规则、常见问题和售后流程。营销PPT里的“灵活对接”“全场景适用”，如果没有具体范围，就不适合直接作为功能承诺。还应写清前提、限制和需要单独评估的事项。
不要把“有价值的内部资料”都当成“可以公开回答的内容”。官网访客不该拿到内部成本、客户合同或员工资料。公开客服库和内部员工库应分开；涉及个人数据的查询，应由服务端验证身份与权限后处理，不能只靠一句“请勿泄露”来控制。
一条资料，要让人看懂“支持什么、不支持什么”
下面是一组虚构的整理示例，用来说明写法，不代表任何实际产品功能。假设方案A已确认可以嵌入网页，但订单查询尚未评估。
如果原资料只写“方案A支持灵活集成，可满足企业多种业务需求”，它没有交代集成范围。用户问“能查订单吗”，数字人就缺少明确判断的依据。
改成一条完整FAQ会更清楚：
常见问法：
方案A可以放到官网吗？能接网站吗？能查询订单吗？
确认答案：
方案A支持网页嵌入。网页嵌入不等于能够读取企业订单；订单查询需要另行评估业务接口、身份验证和授权条件，目前不能承诺已支持。
这条资料还应记录适用方案、对外可见范围、确认来源、审核日期和维护人。记录这些信息，是为了日后知道找谁核实、哪份说明有效；并不是把字段写进正文后，系统就会自动做好版本筛选和权限控制。
同一个问题可以保留几种客户常用的说法，但不必复制成几十条相同答案。尤其不要只写一句“支持”，把产品名称和限制留在其他地方；那句话单独被检索出来时，很难判断说的是哪种方案。
上传之后，检查系统实际读到了什么
文件能打开，不等于内容已被正确处理。扫描PDF里的文字、表格里的列标题、图片中的条件说明，都需要检查解析结果。某些工具可以处理图片或表格，但不能默认每个平台、每种配置都能完整理解。
例如表格把“功能名称”“基础方案”“定制方案”放在不同列，如果解析后只剩一串“支持、不支持、支持”，对应关系就丢了。可以补充一句完整说明，把功能、适用方案和前提写在一起，再检查导入结果。
文档通常会被分成较小的片段，用来匹配用户问题。不要只看每段有多少字，更要看结论和限制条件是否仍在同一个完整语境里。“支持本地部署”与“仅适用于另行评估的定制方案”分开后，单独拿到前半句就容易出错。分段机制与上下文处理可参考Dify的文档分段说明。
FAQ适合按一个问题、一组完整答案组织；较长的技术手册可以按主题保留上下文。不存在适合所有资料的固定分段长度。用客户的实际问法试着检索，再决定是否调整，比套用一个字数更可靠。
明明有答案却答不上，要分两步排查
先看检索是否找对资料，再看数字人是否根据资料回答。不要一遇到错误，就同时改提示词、换模型、加文档；这样即使变好了，也很难知道原因。
以“方案A能查订单吗”为例，在后台找到对应问题的检索记录：如果没有返回相关资料，先确认文档已处理完成、处于可检索状态，应用连接的是正确知识库，查询内容和筛选条件也没有把目标文档排除。
如果返回的是方案B的说明，就检查产品名称、版本信息和检索范围。平台支持元数据筛选时，可以按明确的产品或版本条件缩小范围；客户没有说清产品时，则应先澄清，不能擅自替他选择。
如果已经找到方案A的正确段落，最终却仍说“支持订单查询”，就继续检查：限制条件有没有一并返回，检索结果有没有传入生成回答的步骤，提示词是否要求依据资料，以及是否混入了别的冲突内容。以Dify为例，检索结果需要作为上下文提供给后续大模型节点；只是写“请查询知识库”并不等于接通了这一步。Dify知识检索节点说明展示了这条处理链路。
检索返回的相关性分数也不是“答案正确率”。句子与问题相似，不意味着版本有效、权限允许或业务结论成立。这些条件仍需分别检查。
更新资料时，让旧答案真正退出使用
资料维护容易忽略的一件事，是新文档上传了，旧文档却还在使用。文件改名为“最新版”，并不能保证系统不再检索旧内容。
对功能、套餐和服务范围等会变化的内容，应记录生效时间、适用范围和负责人。更新时先确认新内容已能正常检索，再通过停用、归档或确定的筛选规则，让失效内容退出当前应用的检索范围；历史资料可以留存，但不要继续充当现行依据。平台的具体操作各有不同，Dify的文档管理说明列出了启用、停用和归档等方式。
“当前订单到哪里了”“今天还有多少库存”则属于动态业务数据。把昨天的订单表放进知识库，不能保证回答今天的状态。实时信息应从已授权的业务接口查询，并处理查询失败、结果过期和权限不足的情况。知识库更适合说明查询流程和业务规则，而不是代替实时系统。
用几类问题测试，而不是只问资料里的原句
验收时，既要检查“有答案时能否答对”，也要检查“没有依据时会不会乱答”。保留一组固定测试问题，每次改资料或配置后重复测试，避免修好了新问题，又把旧问题改坏。
- 换一种问法：把“支持网页嵌入吗”改成“能放到我们官网吗”，应找到相同的适用范围。
- 换一个产品：方案A与方案B分别提问，不能把两者的功能混在一起。
- 追问限制：确认功能后再问适用条件，不能漏掉前提或另行评估的要求。
- 问尚未确认的事：资料没有报价或交期时，应说明需要核实，而不是给出猜测。
- 复查更新和权限：旧说明不应作为现行依据；匿名访客不能检索到内部资料。
测试记录至少保留用户问题、预期依据、实际检索片段、最终回答和错误原因。一次答对不代表稳定，重要问题要换问法、换会话再试。把“找到正确资料”和“回答忠实于资料”分开记录，后续才能对症修改。Dify提供了独立的知识检索测试入口；在该入口临时调整的参数，不会自动成为应用的正式配置。
起步时，先做好能被复查的一小批资料
企业不必一次整理完所有文件。先选一个接待场景，把高频问题对应的依据、限制和后续处理方式写清楚，核实应用确实能取到这些资料，再逐步补充新问题。
上线后发现错误，也不要直接把数字人的回答加入知识库。先核对权威来源，由资料负责人确认，再更新正式内容。否则，一个错误答案可能变成下一次回答的“依据”。
判断知识库是否可用，看的不是上传了多少文件，而是能否找到正确、有效、允许使用的资料，并让回答保留必要条件。这一步做扎实，上一篇的角色提示词才有可靠的内容可用。
