给 AI 审查员加个“收据”

在自动化部署流程中引入 AI 进行 Canary 发布审查是一个诱人的想法，但最近的一次实战经历给我敲响了警钟：盲目信任 AI 的记忆，可能会导致严重的生产事故。

实战背景：一个简单的自动化脚本

为了测试一个免费的大模型服务，我编写了一个简单的 Python 脚本，作为定时任务每 5 分钟运行一次。该脚本会抓取系统的错误率和 P95 延迟，将过去 30 分钟的数据打包成一个 JSON 包，然后发送给 AI 模型，要求它给出一个发布审查的结论（Go 或 No Go）。

按照预期，模型应该能敏锐地发现数据的变化。然而，问题很快暴露了：模型似乎“失明”了，它记住了部署前的状态，却忽略了部署后的现状。

致命盲点：模型无法区分“昨天”与“现在”

在一次运行了约 11 小时的任务中，系统的错误率从 0.2% 猛烈飙升到了 1.8%。然而，模型却给出了冷静的“Go”判决，理由是“错误率稳定在 0.2%”。

问题的根源在于提示词。 虽然我在提示词中说了“现在”，但大模型并没有真正的时钟来验证这个时间概念。它将上下文窗口中存储的、属于部署前的“旧基准”误认为是当前的观测值。模型并非在“幻觉”数据，而是过于信任了上下文记忆中那个看起来最自信的数字。

# 旧版本的载荷构建，缺乏时间戳验证
payload = {
    "metric": "error_rate",
    "points": points[-6:], # 最近的六个样本
}
# 模型直接读取了历史上下文中的 0.2%，而忽略了当前飙升的 1.8%

解决方案：强制要求“证据收据”

为了修复这个问题，我引入了一个核心概念：要求模型为每一个判决提供“收据”。

简单来说，就是让模型在输出 JSON 时，必须回显数据的校验和，并附上具体的观测时间戳。如果收据缺失、校验不匹配，或者时间戳过旧（超过 5 分钟），则直接判定该判决无效。

代码实现：校验与时效性校验

我们不再依赖模型自己的判断，而是编写了确定性代码来充当守门员。以下是核心的验证逻辑：

import json
import time

def verify_receipt(raw: str, expected_checksum: str, max_age: int = 300) -> bool:
    """
    验证模型返回的收据是否合法。
    1. 校验和必须匹配。
    2. 证据中的时间戳必须在 5 分钟内。
    """
    out = json.loads(raw)
    
    # 1. 校验和验证
    if out.get("checksum") != expected_checksum:
        return False
    
    # 2. 时效性验证
    for evidence in out.get("evidence", []):
        # 检查 as_of 时间戳是否过期
        if time.time() - evidence["as_of"] > max_age:
            return False
    
    return True

提示词重构：从建议到契约

仅仅修改代码还不够，提示词也需要升级。我们需要明确告诉模型，它看到的数据包是唯一的“真理源”，并且要强制它引用载荷中的时间戳。

新的提示词更像是一份合同：

SYSTEM = "" 你正在审查一次金丝雀发布。下面的数据包是唯一当前的数据。 标记为 "baseline" 的值仅作为参考，绝非当前观测值。 必须返回严格的 JSON：{"verdict": "go|no_go|needs_attention", "checksum": "...", "evidence": [...]} 每一个证据条目都必须复制载荷中的 observed_at 时间戳。严禁编造时间戳。 ""

经验总结

这次经历给我带来了三个重要的启示，对于所有开发者都极具价值：

1. 警惕“记忆幻觉”： 大模型有强大的记忆，但也容易将历史上下文误认为当前现实。在涉及时间敏感的决策时，不要让模型自己管理时间概念。

2. 证据链的重要性： 任何自动化审查的输出，都必须包含对原始数据的引用（如校验和）和来源证明（时间戳）。这不仅是调试的依据，更是防止 AI 自信地撒谎的防火墙。

3. 确定性代码优于第二层模型： 在关键路径上，不要试图用另一个模型去“审查”第一个模型。使用确定性代码进行简单的校验和逻辑判断，往往比引入复杂的模型更可靠。

通过给 AI 审查员加上一个“收据”，我们成功地将一个可能引发事故的盲目工具，变成了一个可靠的自动化助手。