ARIS 对抗式声明审计

它解决什么问题

长程任务最常见的失败模式不是模型「明显崩了」，而是它顺着上下文编出一段听起来很对、但证据链已经断掉的结论——ARIS 论文管这叫 plausible unsupported success。这类错误肉眼极难查出：中间推导很顺，格式很专业，措辞很确定，但引用的那次实验根本没有对应的日志，或者只挑了好看的那几组数据报上来。

一句话问答出错，你立刻就能发现。一篇八千字的技术报告出错，要等读者或 reviewer 来挑刺。任务越长，这个坑越致命。ARIS 的思路是别靠作者自觉，把「验证」做成 harness 的一等公民。

它怎么工作

两条流程配合：对抗式编排负责找漏，三阶段声明审计负责记账。

对抗式编排（executor ↔ reviewer）

• 默认跨模型家族：executor 用主力模型推进草稿，reviewer 用另一个家族的模型专门挑刺。异族 reviewer 更容易跳出同一个训练偏差。
• reviewer 只找四类问题：证据缺口、逻辑跳跃、未证断言、被静默继承的前提。它不替 executor 写内容，否则就变成两个 executor 互相包庇。
• 轮次纪律：意见编号为 R{轮次}.{序号}，executor 修订时必须回指具体编号，禁止「假装改了」。默认最多 3 轮，第 3 轮 reviewer 仍打回 P0，就收口并标注未达成共识的争议点。

三阶段声明审计（顺序不可跳）

1. 完整性验证 — 核对原始日志、文件、截图是否齐全、可复现，输出 integrity_checklist.md，每项打 ✅/⚠️/❌。标 ❌ 或 ⚠️ 的条目要登记为待补证据；关键证据缺失时先补证据或降级措辞，不允许直接放行。
2. 结果→声明映射 — 建 claim_ledger.md，强制「每个声明 ↔ 它的证据行」。任何填不进台账的声明都是红色缺口，只能三选一：补证据、降级措辞、删除。
3. 声明审计 — 把成稿里每个陈述和台账交叉比对。成稿说了台账没有 → 幻觉或漂移，必须改；台账有但成稿没说 → 补回或标注「未采用」。产物是 claim_audit_report.md。

过程留痕

• 每轮结束更新 references/results.tsv（8 列，制表符分隔），记录轮次、意见编号、闭合状态。
• 中间证据统一写成 文件名:行号 或截图/日志路径 + 时间戳，例如 exp/benchmark_0421.md:L12。
• 实在做不到异族审查时，在 note 列标注降级层级（L1/L2/L3）及原因，别假装审过了。

另外，执行层的持久化 knowledge 沉淀在这个项目里落地为 LLM Wiki（library vault）并配 wiki-lint 做健康巡检，长程任务靠的是知识沉淀层，不是只靠上下文窗口。

什么时候用 / 不适合

适合：要发布的长文、技术报告、公众号文章；做过分析或研究、怕「中间推导太顺、最后结论飘了」；产出要求可追溯，每个结论都能点名证据；用户直接说「帮我审一下这篇」「这个结论有依据吗」。

不适合：一步能答完的简单问答、纯闲聊；不需要证据链的纯创作（小说、诗歌）；已经有更强的人工同行评审流程、不缺这一步。

几个注意点：

• 它不保证结论正确，只保证结论和证据之间的关系被显式记录下来。审计能查掉无依据的断言，查不掉实验设计本身的问题。
• 前置条件是待审产物已经带有中间证据（原始日志、文件、截图路径可追溯）。如果草稿本身就是凭空生成的，审计会刷出一片 ❌，但它不能替你重新造数据。
• references/ 目录只承载证据与演进记录，不含运行时逻辑，产物需要手工或按 Runbook 归档。