AI 报告反复变样？先用代码约束信源

同一个签证问题，第一次列出 8 份材料，第二次却变成 19 份。作者做的 AI 签证研究工具在演示时表现正常，真正重复运行，才暴露出答案不稳定的问题。

他的修复方向很明确：用代码限定来源，用固定问题约束遗漏，再限制重试、缓存结果。这套做法适合正在搭建 AI 检索与报告工具的程序员参考，但要分清：答案重复一致，和答案正确完整，是两件需要分别验证的事。

「只用官方来源」为什么不能只写在提示词里

这个工具接收护照所属国家、居住国和目的地，让 AI 阅读使馆及签证中心页面，最后生成包含申请地点、材料、费用和步骤的 PDF。

作者用「印度护照、居住印度、申请法国旅游签证」重复测试，材料数量从 8 份变成 19 份。原因之一是模型可以自行选择来源。「官方来源」这条提示有时有效，有时模型会采用看起来像官网的中介博客，或者已经过时两年的第三方摘要。

作者把来源资格改成了代码规则，只接受以下几类页面：

• 根据目的地国家的 ISO 代码识别出的该国自有域名。
• 申根申请涉及的欧盟机构页面，域名为 europa.eu。
• 带有目的地国家代码的签证中心连锁机构页面。
• 被签证中心官方页面明确列出的域名。

不满足条件的内容，在模型读取之前就被丢弃。提示词仍保留「只用官方来源」，但过滤流程已经不靠模型自觉执行。

来源是否合格，应当先由程序判定，再交给模型阅读。

不过，原文没有给出这套域名识别规则的具体实现，不能直接把上述描述当成完整的校验算法。

把「列出材料」改成必须逐项作答

另一个问题藏在提问方式里。

「列出申请材料」是开放问题。模型需要自行判断列到多细：保险、住宿证明、银行流水是否都要独立列项，每次生成都可能不同。

作者改成固定的 15 个材料问题，每次都要回答，覆盖护照要求、照片、申请表、旅行保险、住宿证明、银行流水等。报告中的其他通用内容仍然保留。

模型可以判定某项不需要，但必须同时提供理由、简短引文和支持该判断的官方 URL。护照、申请表、照片等少数项目则禁止跳过，原文没有列出全部不可跳过项。

这里最有用的设计，是把「没有出现」变成「明确作出判断」。材料没写进报告，究竟是模型漏掉了，还是申请人确实不需要，系统必须能区分。

固定清单约束输出范围，证据要求约束省略理由。

需要保留一个边界：固定 15 个问题只能保障这些问题被处理。作者没有说明清单如何覆盖各国差异，也没有说明遇到清单之外的特殊材料时如何补充。

重试、缓存和链接检查分别解决什么

作者早期设计过一次补全流程：发现缺项，就再调用模型补齐。实际使用中，每次额外调用也会带来新的偏移。

修改后，每份报告最多调用模型两次，走过回退流程后不再额外补全。这是给生成过程设置上限，避免修补一个遗漏时又引入另一套答案。

缓存解决的是另一个问题：即使来源和清单都固定，几分钟内重复运行，结果仍可能有细小差别。作者按护照、居住地、目的地、签证类型的精确组合缓存报告，保存 3 天。相同输入直接返回缓存，交付前重新检查链接，PDF 标注交付当天的日期。

他还处理了两个容易破坏信任的细节：

• 某个欧盟官方登记页面返回 HTTP 200，响应正文却为空。现在，状态为 200 但正文为空，也按死链接处理。
• 较长的官方原文引用曾触发模型服务商的版权过滤，导致调用失败。现在引文最多 12 个词，重试时改用自己的话转述，并进一步缩短引文。

修改后，作者称法国案例一次即可完成，示例报告显示 36 项事实中有 36 项得到官方页面确认，重复运行的材料清单也一致。另外两个实测案例，即埃及护照持有人居住沙特申请奥地利签证，以及印度前往英国，也都一次完成。

这是三个案例的结果，原文没有提供更大规模的测试数据。

我的判断

我认同作者把约束移到代码里的方向。相比继续堆叠「请认真检查」「不要遗漏」之类的提示，来源过滤、固定问题和省略证据都更容易检查，也更方便定位错误。

但「少调用就更可靠」目前仍是这套工具的经验之谈。原文没有给出不同调用次数下的准确率、遗漏率对照，不能据此认定所有研究任务都应减少调用。

缓存也有取舍。它能保证相同输入拿到同一份报告，却不会自动修正报告里的错误。重新检查链接，只能确认页面仍可访问，不能证明页面内容没有变化。PDF 使用交付日期，也不等于当天重新核验了全部事实。

「36 of 36」同样需要理解其范围：它说明作者报告中的事实都有来源支持，但原文没有交代核验是否独立完成，也没有证明不存在漏项。

因此，更适合借鉴的是这套可检查的流程，而不是直接接受它已经达到签证申请所需可靠性的结论。作者也明确披露，工具由他本人开发，并非政府网站，签证决定由使馆作出。

能拿来做什么

• 做 Node 驱动的 AI 检索服务时，可以先过滤来源，再把合格页面交给模型；如果采用域名规则，需要把作者尚未展开的识别逻辑补成可检查的实现。
• 做结构化报告时，可以为固定问题保存回答、是否适用、理由、短引文和来源 URL，让前端明确展示哪些项目已确认、哪些项目被判定为不需要。
• 给生成流程设置明确的调用上限，并记录回退原因。不要只看到缺项就不断追加补全调用，应先确认缺的是来源、问题定义，还是生成结果。
• 使用精确输入缓存时，应分别展示报告交付时间和资料核验时间；链接检测除了检查 HTTP 状态，还应处理正文为空的情况。