用事实白名单与代码校验约束模型编造

让 LLM 每天自动写一条 YouTube Shorts，最危险的故障未必是服务宕机，而是它顺手补了一个不存在的数字，再把传闻讲成事实。作者的改法是：先人工整理带来源的事实，再让 AI 改写，最后用代码检查，不合格就重试或回退。

这套设计值得程序员参考，因为它把「请模型别编」变成了可以执行的约束。不过，数字检查能兜住多少错误，另一个 LLM 能不能当裁判，仍然需要打问号。

先限定事实，再让模型组织语言

作者运营着一个无人值守、每天发布一条 Short 的频道。最初的流程很直接：给 LLM 一个主题，让它生成脚本。问题随后出现：脚本加入了笔记里没有的数字，也会把传闻当成事实。

调整后，作者先写好经过核实、附带来源的事实，AI 只负责把这些材料组织成脚本。

模型负责表达，事实来源由人提前限定。

这比单纯在提示词里写「不要编造」更容易检查。输入只有一个主题时，程序很难判断模型补充的信息是否可靠；输入是一组明确的事实时，至少有了可供比对的依据。

但事实核验并没有消失，只是被移到了生成之前。作者没有详细说明这些来源如何核实、多久更新，因此不能把后续自动化理解成整条链路都不再需要人。

五道检查分别能拦住什么

作者给脚本安排了五层处理：

1. 数字白名单：脚本中的每个数字都必须出现在事实材料里，少数明确允许的数字除外，例如倒计时。不符合就拒绝，让模型重试。
2. 重复检查：拒绝重复的 n-grams，也检查近期视频里重复出现的观点。n-grams 可以理解为连续的词语片段，用来发现措辞重复。
3. 传闻标注：事实材料中以 RUMOR: 开头的内容，必须在脚本里保留传闻属性，否则拒绝。
4. 模型复核：再调用一次 LLM，将 temperature 设为 0，要求列出没有事实支持的主张。
5. 纯事实回退：模型持续失败时，直接用事实材料制作视频，接受表达不够抓人。

这里需要分清检查目标。数字白名单约束的是数字来源；重复检查处理的是内容雷同；传闻标注约束的是信息确定性。它们各自覆盖一类问题，不能互相替代。

第四层尤其特殊。虽然 temperature 为 0，它仍然是一次模型判断，无法因此变成可靠的程序校验。作者也没有给出重复观点和传闻措辞的具体识别实现，不能据此认定这些检查已经覆盖所有表达方式。

逐句标来源更好查，但还不能证明整句正确

一位读者指出了两个缺口：模型复核仍可能漏判，而数字白名单看不见没有数字的虚构陈述。

读者建议让模型为每句话返回对应事实的索引，再由代码检查：这句话里的数字，是否出现在它引用的那条事实中。

这比在整份材料里搜索数字更严格。一个数字即使确实存在，也可能被安到了错误的对象或事件上。逐句关联能缩小核对范围，也便于定位问题。

但索引只能告诉程序去哪里查，数字一致也只能证明数字这一部分匹配。即使引用正确、数字相同，模型仍可能改写主体、条件或因果关系。

可追溯有助于核查，但不等于已经证明语义正确。

而且，这项建议在原文中仍是作者正在跟踪的 issue，并非已经完成并验证的能力。

作者把同样的回退思路用于其他环节。语音依次尝试 Edge TTS、ElevenLabs、Cloudflare、离线系统语音；图像依次尝试 Cloudflare FLUX、NVIDIA、自有生成器、归档素材、程序生成渐变图。项目采用 MIT 许可，使用 Python + FFmpeg，作者称无需 API keys 也能运行。这应与上述回退路径一起理解，不能理解为所有在线服务都免密钥可用。

我的判断

我认可这套方案对职责的划分：先限定可用事实，再检查输出，失败时保留一个能完成任务的退路。与只靠提示词约束相比，它给程序提供了明确的拒绝条件；与只让另一个模型审稿相比，它至少把部分判断落到了代码上。

局限也很明确。原文没有提供错误率、拦截率或改造前后的对照数据，因此目前更适合把它视为工程经验，不能替它背书为「解决幻觉」的验证方案。

纯事实回退也依赖输入事实准确、未过期，制作过程没有改变含义。它能降低生成环节添油加醋的风险，却不能替代事实核验。至于语音和图像的多级回退，解决的是发布连续性，与内容正确性是两件事。

能拿来做什么

• 用 AI 生成版本更新短视频或技术资讯脚本时，可以先整理带来源的事实条目，再让模型改写，并明确限制数字和传闻措辞。
• 在 Node 自动化任务里，可以把数字检查、重试和回退拆成独立步骤。生成失败后直接使用审核过的事实文本，让每日任务仍能完成。
• 如果准备加入逐句事实索引，应把它用于定位和核查；数字匹配后，仍需关注主体、条件和因果有没有被改写。
• 对无人值守的内容流水线，可以分别给语音和图片设置备用路径，提前接受回退后的质量差异，避免单个服务故障阻断发布。