deep-audit

深度对抗式审计

一种收敛速度快于逐轮审查的替代方法。不是让一位审查者每轮发现一两个问题，而是同时让许多相互独立的质疑者审查整个产物，裁定他们发现的问题，修复所有已确认的问题，然后重新验证。该方法借鉴了高难度形式化证明工作背后的多 Agent 方法论（多样化的独立组合、全程对抗、只接受具体证据、综合—质疑—重复）。

何时使用

• 产物足够复杂，导致单次审查每轮都会发现新问题（这表明逐轮审查并不适用）。
• 正确性至关重要，漏掉缺陷的代价很高（例如，提交至顶级会议的论文、证明、安全敏感的更改、迁移）。
• 用户要求“全部修好”“审查得更深入”“更快收敛”或“确保万无一失”。

前提是用户已选择启用多 Agent 编排（他们要求工作流／深度审计／分派多个 Agent，或已启用 ultracode）。如果没有，先向用户提议，并说明大致成本。

方法

1. 分解（多样化组合）。 按想法而非章节拆分产物：每个独立的主张、引理、估算器、子系统、不变量。添加跨领域的失效模式视角（见下文）。确保覆盖到每个关键主张都至少由一个专门针对它的 Agent 进行质疑。不要告诉 Agent 你倾向的解读，以保持独立性，避免它们都得出同一个看似合理却错误的结论。

2. 分派对抗式查错者（每个组件一个）。 提示每位查错者反驳，默认“这里有错误”，并要求每项主张都以实际文本／代码为依据（要阅读原文，不要凭记忆转述）。以下硬性规则取自实践证明有效的方法：

• 只接受具体发现。 每项发现都必须包含：准确位置（文件：行号／标签 + 引用文本）+ 一句话说明缺陷 + 一个失败案例（具体输入／配置 → 错误输出，或缺失的确切前提）。
• 拒绝状态报告、“看起来没问题”、“这是标准做法／常规流程”、含糊的乐观判断，以及“全局步骤很简单”之类的说法。
• 如果某项修复把同一个难题转移到别处，或假定了自身结论，那就不算修复——请标记出来。
• 如果经过真正的攻坚仍未发现问题，Agent 必须说明具体尝试了哪些攻击，以及每种攻击为何未能奏效，而不能只说“没有问题”。

3. 裁定每项发现（独立裁判）。 由另一位裁判重新打开每个引用位置，并以审慎态度同时审视产物和该项发现，作出 CONFIRMED / REFUTED / DOWNGRADED 的判定。这一步可以排除误报（误读、实际上已在其他位置给出的前提、在所述条件下并不会出现的失败案例），确保修复清单可靠。

4. 综合。 按位置去重，按致命 > 重大 > 轻微排序，并整理成一份清晰的缺陷清单。只有通过这一步的发现才能列为问题。

5. 修复所有已确认问题，然后重新验证。 在主流程中由你应用所有已确认的修复（修复需要细致判断）。然后重新审计已修改的位置，并检查修复是否引入了新缺陷。重复多轮，直到连续两轮审计结果为空（兜底上限：5 轮；若某项发现从第 N 轮持续到第 N+2 轮，则交由用户处理，而不是进行第三次修补）。不要在第一轮后就停下。

失效模式视角（根据领域调整）

除了逐个组件检查攻击面外，还要明确扫查以下跨领域模式——真实缺陷往往藏在这些地方：

• 过度宣称： 标题或摘要所声称的内容超出了定理或测试实际能证明的范围。
• 证明中的范围扩张： 需要一致结果的地方却使用了逐点结果；未加限定地陈述了仅在双方都正确时才成立的性质；将特殊情况的论证当作一般情况使用。
• 隐含假设： 使用了可微性、密度、连续性、有界性或正性条件，却从未（在数学中）说明；或者使用了未经检查的前置条件或不变量（在代码中）。
• 边界情况： 原子分布或并列值、端点或无界支持、空输入或退化输入、参数空间的边界。
• 循环论证： 假设预先假定了自身结论；结果引用了自身；引用的文献支持力度不及声称（请阅读引用来源）。
• 内部矛盾： 定义或符号被以两种方式使用；表格单元格与命题矛盾；正文与附录说法不一致；交叉引用悬空或错误。

新视角审查（最终关卡）

每一轮针对性审查都会继承编写提示词者的盲点：关注提示、修复历史和预期失效模式都会让审查人员优先关注已知问题。完成所有针对性审查和修复后，进行一次几乎不提供上下文的冷审查：交由独立审查人员，仅提供文档本身和最简指令（“找出具体缺陷：位置 + 失败案例”），不提供集群分配、历史记录或特别关注清单。只需改变切入点来实现多样化（像期刊审稿人一样从正文开始；从附录开始；从表格或主张开始；或由审查人员自行选择一处深入检查）。照常裁定。新视角审查无发现、针对性审查覆盖完整且机械检查全绿，三者共同构成关闭标准；若新视角审查发现针对性审查遗漏的问题，这也说明提示词集存在问题——将遗漏的失效模式加入视角清单。

完整清单——绝不抽样

对于论文或证明文档：先枚举每一条形式化陈述（通过 grep \begin{theorem|proposition|lemma|corollary} + 标签），再为每个证明分配一名验证者——必须覆盖 100% 的关键陈述，而不是“审查人员挑选的几个证明”。抽样只能以线性且随机的方式收敛；完整清单则一轮即可覆盖。将紧密关联的小引理归入同一组；大型证明由专人验证。除问题发现外，每位验证者还应提交一份已验证步骤清单和一份假设台账（已使用与已陈述的对照；使用了但未陈述的假设即为发现）。

机械检查套件（收益最高的检查）

书面论证读起来可能无懈可击，但其定义的对象可能是错的。对于每个估计方程、影响函数恒等式、识别主张和总体矩，都要编写可执行检查，在对抗性玩具设计上计算总体对象——截断（删失端点低于结果端点）、内部原子分布、错误设定的干扰项、边界或重叠失败——并通过数值断言验证所声称的中心化或恒等式（可用解析方法，或使用固定随机种子的精细网格或大 N 计算）。将脚本作为仓库中的永久测试目录保存，并附上 README；对应公式发生任何更改后都要重新运行。一个 5 行的总体计算就能发现一类缺陷（尾部重新归一化求根、符号翻转、质量缺口加权），而仔细阅读或模型共识都未必能可靠发现这些问题。

修复规范

• 修复引入的新数学尚未经过审计：每轮修复之后，都必须对恰好被修复的位置进行一轮验证，然后才能宣布问题已关闭。
• 在工作流综合中，按 INDEX 将发现与裁决匹配（要求裁决者按发现的顺序返回裁决），绝不能按位置字符串匹配——裁决者会改述位置，导致条目被悄然遗漏。采取行动前，应根据审查记录核对综合后的摘要。

受阻路径也是审计结果

如果某个组件在既定假设下无法修复，这是一个发现，而不是审计失败：报告尚存的确切缺口（具体缺少的假设或失效的步骤）以及坦诚的选项（弱化主张、补充假设、限制范围）。不要寻找有利的解读，也不要让 Agent 把定理级别的缺口搪塞成“常规事项”。

编排

• 在一条消息中并行调用多个 Agent（每个组件派一名查找者），然后针对每个组件的发现安排一名评审者，最后综合结果；参见 orchestrator-protocol.md。如果有 Workflow 工具可用（例如在 ultracode 会话中），pipeline(components, finder, judge) 是一种可选的加速方式：查找者一返回结果，就立即评审该组件的发现（无需等待其他查找者）；但它绝非必需。返回已确认的问题列表；之后由你亲自修复。
• **模型分工：**查找者使用强大的执行／分析模型（负责查找并攻击）；评审者使用强大的裁定模型。按照本地约定 model-routing.md 分配（此处：两个角色都使用 Opus 层级，调整层级前先增加评审者的工作量；Fable 层级由单次会话决定，绝不是整个模型集群的默认值）。每个组件只安排一名评审者（一次裁定该组件的所有发现），以节省评审预算。
• **坚持完成。**不要返回“尽力而为”的结果或列出困难之处。返回已确认的缺陷（修复后还要进行一次干净的重新审计），或者准确陈述最有力的单一遗留缺口。

提示词模板

查找者：“你是一名负责审计单个组件的严苛评审员。阅读 {locations} 中的实际文本。重点攻击：{failure modes}。只返回具体发现（位置 + 缺陷 + 失败案例）；不要说‘看起来没问题’／‘常规事项’或含糊其辞。重新引入难题的修复不算修复。如果没有发现问题，请列出你进行的具体攻击及其为何均已排除。”

评审者：“一名对抗性评审员针对组件 X 返回了以下发现。逐条打开所引位置，根据文本实际内容及其证明进行核实，并标记为 CONFIRMED／REFUTED／DOWNGRADED。既要审视产物，也要审视发现，不要轻信任何一方。”

共享准则集中存放于一处

本审计依赖的三项内容未在此重述，因为它们与其他验证环节使用相同的规则；在此再写一份会导致内容偏离：

• 种入故障校准——未能发现预置缺陷的检查，不构成任何依据。 → /vaccinate 和 verification-ladder.md 第 0 阶。
• 独立性与相关错误——模型之间意见一致不等于确认；它们可能以相同方式出错。→ verification-ladder.md 第 3 阶。
• 五个可信度问题——一项问题的证据不能消除其他问题。 → external-oracle-process.md §6。

审计仓库本身

有关仓库基础设施审计的应用——surface-sync、技能／Agent／规则完整性、钩子和脚本审查、文档与实际情况的偏差——请参见 references/repo-infrastructure-audit.md。 从 ./scripts/backtest.sh 开始：机械化测试集已经编写完成，脚本可以判定的事项，Agent 绝不应手动核查。