GenAI输出必须自带结构化证据链，否则是失职

生成式系统的失效方式与普通软件截然不同。它们不会崩溃。它们产生的内容看似合理、流畅，却时不时出错——而且规模庞大、姿态正经。若没有中间的过滤机制就把输出抛向外部世界，那是失职。我们的系统有三道墙。

第一道墙：证据门

每一条自动化陈述都必须附带证据，而证据必须结构化，不能靠感觉：

{
  "claim": "business site has no online booking flow",
  "evidence": {
    "url": "https://example-biz.com/reserve",
    "fetched_at": "2026-03-11T02:14:09Z",
    "check": "booking CTA selectors absent in rendered DOM",
    "screenshot": "sha256:9f2c11ab..."
  },
  "verdict": "pass"
}

没有证据对象，就不通过。规则要求精确匹配却用了模糊匹配，不通过。要求如此简单——"给我看看你从哪里读到的"——惊讶于多少幻觉就此死在这一步。

第二道墙：身份门，以及教会我们谦逊的那个 bug

一个关于真实企业撰写内容的 pipeline，必须首先证明它看的是正确的企业。我们的第一道身份门将企业名称与域名进行比对，任何不匹配的跳过。合理，在一个企业使用韩文名称却持有拉丁字母域名的市场里，这个做法灾难性地错误。那道门悄无声息地丢弃了 98% 的合法目标。修复方案是：不再信任域名字符串，改为从页面本体验证身份，名称、地址、电话与记录交叉核对。此后通过率从 2% 升至 71%，零错误实体事故。教训推广开来：一道 fail closed 的门可以和一道 fail open 的门一样错误，只有测量才能告诉你你面对的是哪种失败。

第三道墙：对抗性二审

我们所知的最便宜的质量升级，是让第二个模型实例攻击第一个的输出。不是改进，是反驳。审查者 prompt 明确其职责是找到缺陷，而当不确定时应该判定该发现为"已反驳"，因为漏掉的缺陷比我们丢弃的一个要多。一个只负责找缺陷的审查者，会找到协作式审查者出于礼貌而忽略的那些。通过审查的发现才是值得处理的。

在这三道墙之后，是回归测试套件，约 3900 个案例，预期失败数为零，每起事故新增一个案例。这一切都不会显著拖慢 pipeline。所有这些加在一起，才让我们能把生成式机器对准现实世界的后果，然后睡得着。