验收契约：把「交付没交付」变成机器能判定的事
一句话结论：长任务第 12 轮报「72/72 全交付」，我们庆祝了半天，后来发现 72 份报告是脚本在 python_exec 里批量生成的——根本没走写文件的工具。问题出在"交付"这件事从来没法被机器判定。我们最后用"验收契约"把它钉死了。
怎么才算"交付了"
AI 交回来一份报告，你怎么知道它是真的、是齐的、是对应那份输入？传统做法靠人肉眼看，但长任务一天产出几十份，人看不过来，而且看的人也会被骗。
最痛的一次：验收只看"文件存在"，于是模型用脚本批量生成"形似"的报告，文件名、大小都像那么回事，验收全过。四道质量闸（零读多写、错位检测、写白名单、验收）全以 file 工具为统计面，python_exec 是盲区。
验收契约：交付面在派发时就定下来
治法是把"这份任务要交付什么"在派发时写成结构化契约：
- 来源一：用户题面里点名的文件名（如
web_search_design.md.audit.md）。 - 来源二：派发方按"批号 → 范围 → 路径"确定性生成（不让模型自拟路径，避免自创目录）。
- 来源三：模型从题面推导的命名声明（"命名规则：<源文件名>.audit.md" 这类短语）。
- 来源四：会话首条原始消息再推导一次任务级合同，与前面取并集。
四来源合起来，契约 = 白名单 = 验收三处同源。模型自创的路径物理上不可能通过。
缺口引擎：不只是"存在"
契约里的每一项，缺口引擎不只查"文件在不在"，还查要素：
| 断言 | 作用 |
|---|---|
| 文件存在 + 非空 | 防空文件、防 0 字节 |
contains 子串 | 防"形似神不似"——题面要求写明的字节数、行数、摘录，缺一个就点名 |
| 表格行数 / 列数 | 防索引表缺行、列位错 |
| 读取上限 2MB | 宁缺勿漏，超大文件不静默跳过 |
缺要素的清单会精确点名：path（缺要素：字节、摘录）——是哪一个文件、缺哪一样，一目了然。
真实性：两次可追溯
除了"交付什么"，还要解决"是不是真做的"：
- 写动作可追溯——每份产物要能追溯到一次可解释的写动作；单轮脚本写盘超过阈值，标
batch_generated判黄，不计入交付。 - 输入不可变——任务前后对源目录做 hash 快照，收车后比对，防止模型把报告写进源文件、污染输入。
结论
"交付没交付"从一句模糊的人话，变成了一份机器能逐条核对的契约。长任务第一次能说出"还差哪几份、每份差什么要素"，而不是报一个会骗人的总数。