wiki-audit

Wiki 审计

根据引用的来源核实单个 wiki 页面。分为两个阶段：先检测未引用的事实性主张，再通过为每个来源并行派遣一个子 Agent 来核实有引用的主张。在强模式（wiki-audit strong）下，第三阶段会加入跨模型对抗性审查：由不同提供方的模型重新审查相同主张，检查是否存在过度推断和矛盾；与常规审查意见不一致之处将成为审查发现。

前置条件

查找 SCHEMA.md（从当前工作目录向上搜索，或在 ~/wikis/ 中搜索）。如果未找到，告知用户先运行 wiki-init。阅读 SCHEMA.md，了解 wiki 根路径和 Citations 部分（审计要执行的规则和脚注格式）。

链接样式。 从 SCHEMA.md 读取 link_style:。如果缺少该字段，或 <wiki-root>/config/link-style.md 不存在，则默认使用 obsidian（[[slug]]）。否则，读取 <wiki-root>/config/link-style.md。被审计页面中的脚注 slug 目标可能采用 obsidian 或 markdown 格式——使用 ## Parse 规则识别两者。你撰写的审计报告也是一个 wiki 页面，因此其交叉引用和 slug 目标示例应按照 ## Emit 规则生成。

如果 SCHEMA.md 没有 Citations 部分（较早版本的 wiki，在此技能推出前初始化）：本次运行使用下面的备用约定，并在最后询问用户是否要将 Citations 部分追加到 SCHEMA.md，以便后续操作保持一致。

Cite every non-common-knowledge factual claim. Granularity is paragraph or claim,
never per-sentence. Format: Markdown footnotes. Two citation kinds:

Quote:     [^N]: <target> <locator> — "<verbatim quote>"
Synthesis: [^N]: <target> <locator> [synthesis] — <what supports the claim>

Three rules:
1. Target is one of: a slug reference to a source-type wiki page (form per the
   wiki's link_style; fallback `[[source-slug]]`), raw/<file> or assets/<file>
   (a local file path), or a URL. Never an entity / concept / analysis page.
2. A semantic locator is present (§section, p.N, [HH:MM:SS], URL anchor, dated
   post). PLUS a line-range token (L142-145, L142, or L142-145,L201-203) when the
   resolved raw source is text-addressable (markdown / plaintext / code / cached
   HTML). The line-range points into the raw source file and is required for both
   citation kinds. Exempt (semantic locator only): PDFs, transcripts, live URLs
   with no local copy.
3. Either a verbatim quote, or the [synthesis] tag plus a description of what
   the cited range supports.

**模式：**如果调用参数包含单词 strong（例如 wiki-audit strong transformer-architecture），则启用强模式——在 Phase B 之后运行 Phase C（§3b）。否则运行常规模式（仅 Phases A 和 B）。如果还有其他参数，则剩余的参数标记（如有）指定页面。

如果用户未指定页面，询问要审计哪个页面。接受 slug、文件名或绝对路径。解析为 wiki/pages/<slug>.md。每次运行只审计一个页面。

流程

1. 读取目标页面

读取完整页面。记录：

• frontmatter 中的 sources: 列表（页面正式引用的来源）。
• 所有脚注定义（[^N]: ...）和正文中的脚注引用（[^N]）。

如果页面没有脚注，但包含事实性内容，这本身就是审计结果——每条主张都将成为 Phase A 的审查发现。仍然运行 Phase A；跳过 Phase B。

2. Phase A — 检测未引用的主张（1 个子 Agent）

派遣一个子 Agent。提供：

• 完整页面内容。
• 从 SCHEMA.md 复制的 Citations 部分。
• 页面中的 sources: 列表。

任务：列出每条缺少脚注的、非常识性的事实主张。返回结构化列表，格式为 (行号, 主张文本, 建议来源（取自来源列表；若无则为 "unknown"）)。

子 Agent 应用 SCHEMA.md 中的“哪些内容需要引用”规则：按段落或主张粒度判断，常识除外。

3. 阶段 B — 引文声明核验（N 个子 Agent，并行）

对于页面中的每条脚注定义，解析以下内容：

• 目标 — slug 引用（通过 config/link-style.md 中的 ## Parse 匹配——从 Obsidian 或 Markdown 格式中提取 slug）、raw/ 或 assets/ 下的路径，或 URL。
• 语义定位符（§章节、p.N、时间戳、URL 锚点、带日期的帖子）。
• 行范围 L<start>-<end>（如果存在；可按文本定位的来源会带有行范围）。
• 原文引文或 [synthesis] 描述。

将每个目标解析为可阅读的内容：

• slug 引用 → 读取 wiki/pages/<slug>.md，查找原始文件路径（在其 **Source:** 行中）。然后读取 raw/ 或 assets/ 中的原始文件。
• raw/<file> 或 assets/<file> → 直接读取文件。
• <URL> → 检查 assets/ 中是否存在缓存副本（文件名根据 URL 生成）。如果存在，则读取；如果不存在，将脚注标记为 🚫 source-missing（不要重新获取——这属于修复步骤）。

任何无法解析的目标，判定结果均为 🚫 source-missing；不要为其分派子 Agent。

快速路径 — 带有行范围（L…）的脚注： 不要分派子 Agent。 将目标解析到原始文件，然后仅读取引用的行（例如，使用 sed -n '142,143p' raw/<file>，或使用带有相应偏移量和长度的 Read 工具）。然后：

• 引文脚注： 在该行范围内对原文引文进行字符串匹配，忽略首尾空白，并将连续的内部空白合并为单个空格。匹配 → ✅ supported。不匹配 → ❌ unsupported（注明这些行的实际内容）。
• 综合脚注（[synthesis] + L…）： 分派子 Agent，但只提供引用的行片段（而非整个来源）以及综合描述，并按照下方的判定标准给出结果。这是限定读取范围的情形，成本远低于读取整个来源。

无法读取行范围的脚注（范围超出文件内容、文件缺失）应标记为 🚫 source-missing。

慢速路径 — 不带行范围的脚注（旧版引用和豁免来源：PDF、转录文本、实时 URL）：

按解析后的文件对可解析的脚注分组（针对同一 PDF 的多条脚注只读取一次）。使用 Agent 工具，为每个文件并行分派一个子 Agent。每个子 Agent 会收到：

• 原始来源内容（来自 raw/、assets/ 或缓存的 URL）。
• 针对该来源的脚注列表——每条脚注包含编号、定位符，以及原文引文或 [synthesis] 描述。
• 下方的判定标准。

每个子 Agent 针对每条脚注返回一个判定结果和一行说明：

• ✅ supported — 引文与引用定位符处的来源文本字符串匹配（存在 L… 行范围时可确定性匹配），或 [synthesis] 描述准确概括了引用范围。
• ❌ unsupported — 在引用定位符或行范围处找不到引文，或来源内容与声明相矛盾。
• ⚠️ partial — 引文是转述而非逐字引用（且没有 [synthesis] 标签），或综合描述夸大了引用范围。

对于 ❌ 和 ⚠️，说明中必须包含来源的实际内容，以便用户判断如何修复。

为什么按来源而不是按脚注分组： 读取 PDF 的成本很高。针对五条脚注读取一篇 30 页论文一次，胜过读取五次。

3b. 阶段 C — 跨模型对抗性审查（仅强模式）

仅当审计通过 wiki-audit strong 调用时，才运行本节。在普通模式下，完全跳过本节并转到步骤 4。

1. 选择审查模型（提供商链）。 按顺序检测是否有可用的不同提供商 CLI：

• command -v codex 成功 → 使用 codex（OpenAI）。标签：模型 codex，提供商 openai。
• 否则，如果 command -v gemini 成功 → 使用 gemini（Google）。标签：模型 gemini，提供商 google。
• 否则，通过 Agent 工具调用 Claude 子 Agent（Sonnet）。标签：模型 claude-sonnet，提供商 anthropic。为每条发现标记 same-provider — weaker signal，并告知用户，安装 codex 或 gemini 即可启用真正的跨提供商检查。

2. 组装有界载荷 — 复用阶段 B 的工作；不要重新读取原始来源：

• 目标页面的完整正文。
• 对每条引用的主张：主张文本，加上阶段 B 已读取的行范围摘录。
• 目标页面通过 [[slug]] 直接链接的每个页面的正文（仅直接链接，不包括整个 wiki）。

将载荷与下面的指令块一同写入临时文件 $TMPDIR/wiki-review-<page-slug>.md。

3. 指令块（原样放在载荷文件顶部）：

You are an adversarial reviewer. Given a wiki page, the source excerpts its claims
cite, and the bodies of its directly-linked neighbor pages, find ONLY these problems
and return them as a JSON array — nothing else. Do not restate claims that are fine.
Finding types:
- "overreach": a claim generalizes beyond what its cited excerpt supports.
- "internal-contradiction": two claims on this page conflict.
- "cross-page-contradiction": a claim conflicts with a directly-linked neighbor page.
Each finding is an object: {"type": "...", "where": "<line / footnote / page ref>",
"detail": "<one sentence>"}. Return [] if you find nothing.

4. 以非交互模式调用审查模型：

• codex：codex exec "$(cat "$TMPDIR/wiki-review-<page-slug>.md")"
• gemini：gemini -p "$(cat "$TMPDIR/wiki-review-<page-slug>.md")"
• 子 Agent 回退方案：派发一个 Agent，其提示词为载荷文件的内容。

如果 CLI 调用出错，查看其非交互用法（codex exec --help / gemini --help）并重试一次；如果仍然失败，则转到子 Agent 路径。将审查者的回复解析为 JSON 发现数组（允许前后有其他文本——提取该数组）。

5. 筛选分歧。 仅保留阶段 A/B 未标记的发现：阶段 B 评为 ✅/⚠️ 的主张被审查者判为 overreach，属于分歧；前两个阶段都未指出的矛盾，也属于分歧。丢弃仅重复阶段 A/B 现有结论的审查者发现。保留下来的列表即为阶段 C 发现。

6. 在已审计页面（而非报告）的 frontmatter 中写入 review:。 这是审计元数据——像报告一样自动写入；页面内容不变。在页面 frontmatter 中添加或替换 review: 块：

review:
  model: codex          # gemini | claude-sonnet, per the chain above
  provider: openai      # google | anthropic
  date: <today>
  status: disputed      # `clean` if step 5 left zero disagreements, else `disputed`
  findings: 2           # the disagreement count; OMIT this line when status: clean

将阶段 C 发现纳入步骤 4 的报告。

4. 撰写审计报告

始终写入报告——不要征求许可。路径：wiki/pages/audit-<page-slug>-<today>.md。下面的模板使用 obsidian 风格的 slug 引用以提高可读性；在实际报告中，每个 slug 引用都必须遵循 config/link-style.md 中的 ## Emit 规则。

---
title: Audit Report — <page-slug> — <today>
tags: [audit, maintenance]
sources: []
updated: <today>
---

# Audit Report — [[<page-slug>]] — <today>

## Summary
- Cited claims verified: N
- ✅ Supported: N    ❌ Unsupported: N    ⚠️ Partial: N    🚫 Source missing: N
- 🆘 Uncited factual claims: N
- 🧪 Cross-model disagreements: N   (strong mode only; omit this line in normal mode)

## 🆘 Uncited Claims (Phase A)
- Line 42: "Transformers replaced LSTMs as the default sequence model."
  Suggested source: [[attention-is-all-you-need]] or unknown
  Fix: add footnote, weaken claim, or remove

## ❌ Unsupported (Phase B)
- [^3]: claims "8 attention heads with 128 dims each"
  Source says: "h = 8 parallel attention layers ... d_k = d_v = 64"
  Fix: correct the dimension to 64

## ⚠️ Partial (Phase B)
- [^7]: [synthesis] description says "compares to RNNs across 4 benchmarks"
  Source range covers 2 benchmarks, not 4. Tighten the description.

## 🚫 Source Missing
- [^5]: https://example.com/post — no cached copy in assets/
  Fix: re-fetch source, or remove citation

## ✅ Supported
- [^1], [^2], [^4], [^6], [^8] — all verified

## 🧪 Cross-Model Review (<model> / <provider>)
- overreach — [^3]: claim generalizes to "all transformers" but the cited excerpt
  (L142-143) covers only the encoder.
- internal-contradiction — line 12 says "8 heads", line 40 says "16 heads".
- cross-page-contradiction — [[this-page]] vs [[other-page]] disagree on the release date.
Disposition: surfaced for user review (not auto-applied).

仅在强模式下包含 ## 🧪 Cross-Model Review 部分。其标题应注明审查者（例如 (codex / openai)）；当提供商链回退到子 Agent 时，标题应为 (claude-sonnet / anthropic — same-provider, weaker signal)。每条阶段 C 分歧占一行；如果阶段 C 未发现分歧，则写 - none — reviewer agreed with the normal audit.

审计报告仅为本地文件。 写入报告前，确保 wiki 根目录中的 .gitignore 包含 wiki/pages/audit-*.md 这一行；如果缺失则追加（为在此约定实行前初始化的 wiki 自动修复——如果没有 .gitignore，则创建它）。审计报告绝不会出现在 wiki/index.md 中：索引由 bin/generate-index.py 生成，该脚本会跳过 audit-*.md 文件，因此无需手动添加或移除任何内容。强模式运行时，提交记录是 §3b 中写入页面的 review: frontmatter 标记；报告本身仍保留在本地。

5. 提供具体修复方案

对于每个非空类别，一次提供一个选项：

• 🆘 未引用：“在页面的 sources: 列表中查找依据，并为这些主张建议脚注吗？”
• ❌ 不受支持：“应用报告中列出的更正吗？（我会先展示差异。）”
• ⚠️ 部分支持：“完善综合描述，或为缺少的内容添加 [synthesis] 标签吗？（先展示差异。）”
• 🚫 缺少来源：“重新获取 URL / 将放错位置的 PDF 移回 raw/ 吗？”

仅在用户确认后应用。每次写入前都展示确切差异。

6. 记录操作

遵循 SCHEMA 的操作日志与提交约定。请注意，审计报告本身已被 gitignore（audit-*.md），因此只有页面更改可以提交。

• **Git wiki：**如果审计更改了任何可提交文件——页面的引文修复，或强模式下的 review: frontmatter 令牌——则建议提交（应用了修复时默认为 fix:，仅运行了 review 令牌时为 chore:，并附上 trailer），并在确认后提交。没有更改内容的常规模式审计无需提交。

  fix: resolve uncited claims on <page-slug>
  
  Wiki-Op: audit
  

• **非 Git wiki：**追加到 wiki/log.md：

  ## [<today>] audit | <slug reference to <page-slug>> — N supported, N unsupported, N partial, N uncited
  Report: audit-<page-slug>-<today>.md (local-only)
  Cross-model: <model>/<provider> — clean | N disagreements   # strong mode only
  Fixed: <list, or "none">
  

7. 向用户报告

• 审计报告：wiki/pages/audit-<page-slug>-<today>.md
• 一行结论（例如：“8 条已引用主张中有 5 条得到验证，发现 2 条未引用主张”）
• 是否应用了任何修复