将 AI 输出视为不可信输入

Source: Dev.to

危险的假设

在生产环境的 AI 系统中，模型输出往往直接流入：

• 面向客户的响应
• 财务决策
• 工作流自动化
• 合规敏感路径

隐含的假设是：“模型按我们的要求工作，所以输出一定没问题。”
当出现故障时，事后分析通常会说：

• “提示不够严格”
• “我们应该多重试”
• “模型产生了幻觉”

但这些并不是根本原因。

真正的失败在于边界

模型并没有破坏系统。系统信任了模型。

从系统的角度看，AI 输出只是另一种外部数据源：

• 概率性的
• 非确定性的
• 不保证遵守不变量

这把它归入与以下同类的范畴：

• 用户输入
• webhook 负载
• 第三方 API 响应

我们并不 信任 那些数据。我们会 验证 它们。

为什么提示和重试无法解决这个问题

提示是指令，而不是强制执行。
重试可以提升得到更好答案的概率，但并不能保证：

• 结构正确性
• 合规性
• 安全性
• 一致性

使用一个 LLM 来评判另一个 LLM 只会给系统增加更多不确定性。这些都无法形成 硬性阻断。

正确的生产架构

一旦看到了，就很难再忽视。

LLM → Verification Layer → System

Verification Layer 的工作方式是：

• 生成之后
• 交付之前
• 在模型控制之外

它的职责不是要聪明，而是要 严格。

验证到底意味着什么

实际上，验证要强制执行三件事：

1. 合约

输出是否符合系统期望的结构？如果不符合，就不继续处理。

2. 策略

输出是否违反了任何确定性的规则？

• 合规语言
• 个人身份信息（PII）泄露
• 密钥泄漏
• 不安全的标记

如果违反，系统必须显式阻断或重写。

3. 明确的决策

每一次响应都必须产生一个明确的结果：

• 允许
• 阻断
• 重写
• 审计

没有沉默的失败。没有 “可能没事” 的模糊。

为什么这会改变一切

把 AI 输出视为不可信的输入会带来：

• 更简洁的模型也能使用
• 故障变得可预测
• 合规性可以强制执行
• 事故在造成损害之前被捕获

模型成为建议引擎，而不是事实来源。这正是概率系统应有的位置。

这不是安全问题——而是系统问题

这不是道德争论，而是生产层面的考量。每个成熟的系统都会在边界处强制信任。AI 系统也不例外。

最终原则

如果你的系统无法确定性地解释 为什么 某个 AI 响应被允许，那么它就不应该被允许。

如果你想在真实系统中强制实现这一边界，Gateia 是一个专为生成后验证构建的开源 TypeScript SDK：

npm install gateia

无聊而可靠。
严格而稳健。
为生产而生。