多 AI 协作如何用结构化凭证验收

AI 说「做完了」，只能证明它作出了这个声明。作者用 ChatGPT/Codex 和 Claude 维护一个九种语言的个人网站，多方协作时遇到的薄弱环节，是下一个 AI 往往只能相信上一个 AI 留下的摘要。

他的办法很小：给任务附一张 JSON 交接卡，再用脚本检查它有没有达到验收条件。它值得借鉴的地方，是把「完成」拆成可检查的要求；需要打问号的地方，则是字段齐全与结果可靠之间，仍有一段距离。

交接时要传证据，不能只传结论

作者的协作流程里，有 AI 起草，有 AI 审核，还有 AI 检查页面实际渲染。问题出在交接：一句「页面已检查」没有交代谁检查、检查了什么，也没有留下未解决的问题。

Multi-AI Handoff & Approval Card 把这些信息装进同一个结构，跟着任务一起走。下面这张卡用来明确交接时必须提供什么：

{
  "task": "what was asked, in one sentence",
  "claimed_result": "what the AI says it did",
  "risk_tier": "auto | auto-then-verify | human-approval",
  "risk_reason": "why this tier",
  "evidence": [
    { "check": "what was checked", "checked_by": "script / fresh-context run / human (not the same AI run)", "result": "pass | fail | unclear" }
  ],
  "changed": ["pages, files or systems touched"],
  "rollback": { "how": "how to undo it", "who": "who can undo it" },
  "open_items": ["anything unverified, ambiguous or skipped"],
  "approved_by": "a human, or the rule that allowed auto-approval"
}

重点看 evidence：作者要求，检查者不能是执行任务的同一次 AI 运行，可以是脚本、带新上下文的另一次运行，或者人。

另外两个关键字段是 rollback 和 open_items。前者要求验收前讲清楚如何撤销、由谁撤销；后者容纳没验证、含糊或跳过的事项。把 open_items 写成空数组，也是在声明「没有遗留问题」，不能随手填空。

原文说卡片有八个字段，但示例和后面的 REQUIRED 实际都列了九个。落地时应以具体结构为准。

风险分级负责分流，脚本负责拦住不完整的交接

作者不主张每一步都让人批准，因为高频确认容易让人养成直接点「同意」的习惯。卡片提供三个等级：auto、auto-then-verify、human-approval，再用 risk_reason 解释选择原因。

不过，原文没有给出完整的分级标准。哪些动作可以自动通过、哪些必须人工介入，还需要团队自己定义。

下面的 Python 脚本把卡片接入验收流程：发现问题就输出 NOT DONE，并返回非零退出码。

import json
import sys

REQUIRED = ["task", "claimed_result", "risk_tier", "risk_reason", "evidence",
            "changed", "rollback", "open_items", "approved_by"]
TIERS = {"auto", "auto-then-verify", "human-approval"}

def check(card):
    problems = []
    for key in REQUIRED:
        if key not in card:
            problems.append(f"missing field: {key}")
    for key in ["task", "claimed_result", "risk_reason", "approved_by"]:
        if key in card and not str(card[key]).strip():
            problems.append(f"empty field: {key}")
    if card.get("risk_tier") not in TIERS:
        problems.append("risk_tier must be auto, auto-then-verify or human-approval")
    evidence = card.get("evidence") or []
    if not evidence:
        problems.append("no evidence: the work is reported, not done")
    for item in evidence:
        if item.get("result") != "pass":
            problems.append(f"evidence not passing: {item.get('check', '?')}")
        if not str(item.get("checked_by", "")).strip():
            problems.append(f"evidence without a checker: {item.get('check', '?')}")
    rollback = card.get("rollback") or {}
    if not rollback.get("how") or not rollback.get("who"):
        problems.append("rollback needs both how and who")
    if card.get("open_items"):
        problems.append(f"{len(card['open_items'])} open item(s) still listed")
    return problems

if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        card = json.load(f)
    found = check(card)
    for p in found:
        print("-", p)
    print("DONE" if not found else "NOT DONE")
    sys.exit(0 if not found else 1)

要留意最后一行 sys.exit(0 if not found else 1)：它让检查结果可以成为流水线步骤或下一个 agent 接手前的门槛，而不只是终端里的一句提示。

作者给出的失败案例是一项文章发布任务：等级为 human-approval，但批准人为空；链接检查结果为 unclear，检查者也为空；回滚只写了如何撤稿，没写负责人；图片署名仍未处理。脚本因此列出五项问题，输出 NOT DONE。

检查通过，为什么仍不能直接相信

这段脚本能检查声明是否满足部分约定，却不能证明声明是真的。

它检查了 checked_by 是否非空，却无法判断填写的人或脚本是否真的执行过检查，也无法识别它是不是原来那次 AI 运行。它接受 approved_by 中的非空文本，却不会因为等级是 human-approval 就验证批准者确实是人。

实现也没有完全覆盖作者所说的「每个字段都填好」：changed 只检查是否存在，允许空数组；证据里的 check 没有必填校验；部分文本字段经过 str() 转换，null 也可能绕过空值检查。它还不是严格的 JSON Schema 校验器。

作者自己也承认，风险会随上下文变化。同样一次页面修改，放在无人访问的页面和首页，风险不同。验证者也会犯错，两个模型如果读的是同一份错误摘要，可能一起得出错误结论。

新上下文提供了重新检查的机会，但独立性还取决于它拿到了什么材料。

我的判断

我赞成把 claimed_result 与 evidence 分开。它迫使接手者区分「AI 说做了什么」和「有什么依据支持这个结果」，也把回滚与遗留事项提前到了验收阶段。

但原文提供的是个人网站的实践描述、检查脚本和失败示例，没有给出采用前后的错误率、交接耗时，也没有与普通检查清单或现有 CI 做对照。这是一套可尝试的经验方法，不能据此认定多 AI 协作已经更可靠。

和普通 Markdown 清单相比，JSON 更方便被程序读取；和测试及 CI 相比，它更适合补充责任人、风险理由与未决事项。真正决定验收质量的，仍是检查覆盖了什么，以及证据从哪里来。

能拿来做什么

• 给 AI 修改页面的任务附上交接卡，在 changed 中列出文件，在 evidence 中分别记录构建检查和实际渲染检查，避免一句「页面正常」包办所有验收。
• 在现有流水线里接入卡片检查，利用非零退出码拦住资料不全的交接；正式使用前，补齐字段类型、空值和人工批准规则的验证。
• 让另一次 AI 运行复核时，提供原始任务、实际改动和检查结果，让它重新判断，减少只读上一份摘要造成的共同误判。
• 发布文章或页面前，把署名、链接等未完成事项留在 open_items，并写清撤回方式和负责人，处理完再申请验收。