# Guide Meta Thinking

> 元思考（MetaThink）方法论：从第一性原理推导系统行为，而非机械查文档。 核心是理解"为什么这样设计"而非"它是什么"，从设计约束推导出不可消除的行为边界， 用这些边界作为代码正确性的 eval 标准，并区分"我们的 bug"与"系统的固有限制"。 有以下意图时必须加载此 skill： (1) 不知道某个行为是 bug 还是系统正常行为 → 用元思考做 fault attribution (2) 面对新的技术系统，需要快速建立正确的心智模型 → 用元思考推导约束 (3) 对一段代码有多种实现方式，不知道哪种正确 → 用元思考找 eval 标准 (4) reconcile 发现异常，不确定根因 → 用元思考的约束链追溯 (5) 需要理解为什么 guide-polymarket-fundamentals 这样设计 → 读本 skill

- Skill: `cyl19970726/guide-meta-thinking` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add cyl19970726/guide-meta-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cyl19970726/guide-meta-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cyl19970726 (https://skillmd.com/u/cyl19970726)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cyl19970726/guide-meta-thinking

---


# 元思考（MetaThink）方法论

## Patterns（可复用工作流）

| Pattern | 适用场景 | 文件 |
|---------|---------|------|
| **Lead-Audit Workflow** (2026-04-15) | Lead 有架构级怀疑 → spawn 审计 agent → bug class 枚举 → P0/P1/P2 并行 fan-out | [`patterns/lead-audit-workflow-2026-04-15.md`](patterns/lead-audit-workflow-2026-04-15.md) |

> **核心定义**：元思考不是"知道答案"，而是"知道如何推导答案"。

---

## 第一部分：元思考是什么

### 两种思维模式的对比

**文档思维**：Polymarket 的 FOK 订单在未完全成交时会被取消。

**元思考**：如果我设计一个混合撮合系统（链下匹配 + 链上结算），我需要一个机制保证原子性。FOK 是这个机制的自然结果——要么链下能撮合到全部数量，要么不提交链上。这意味着 FOK 的"kill"必然发生在链下，**链上不会有任何痕迹**。

这一点的差别是根本性的：

| 思维模式 | 告诉你什么 | 局限 |
|---------|-----------|------|
| 文档思维 | 结果是什么（FOK 被取消） | 文档不全时失效；无法推断未文档化行为 |
| 元思考 | 为什么只能这样；这意味着什么约束 | 约束是推导出来的，不依赖文档完整性 |

元思考的威力在于：**当文档缺失、文档错误、或行为未被文档化时，你仍然能推断出正确答案。** 更重要的是，你能推断出"哪些代码实现是不可能正确的"——即使这段代码表面上看起来没问题。

### 元思考的本质

元思考是约束传播（constraint propagation）：

```
系统要解决的问题
  → 工程不可避免约束（数学/物理层面）
    → 设计者必然选择的方案
      → 该方案带来的不可消除副作用
        → 代码必须尊重这些副作用，否则必然产生 bug
```

这条链上的每一步都是**必然推断**，不是猜测。如果你的代码违反了链上的某个节点，不是"可能有 bug"，而是"**必然有 bug**"。

---

## 第二部分：元思考的推导步骤（SOP）

标准流程，5 步：

```
Step 1: 定义系统要解决的核心问题
  → 不是"Polymarket 是什么"，而是"预测市场要解决什么问题"
  → 问法：这个系统如果不存在，用户面临什么困境？
  → 例：让"我相信 X 会发生"变成有对手方的可交易资产，
        同时保证结果由链上合约结算，不依赖中心化机构

Step 2: 识别不可回避的工程约束
  → 什么是数学/物理/经济层面无法绕过的？
  → 问法：即使无限资金、无限工程师，这个约束还存在吗？
  → 例：链上操作有 gas 成本（物理约束）
        区块有出块时间，确认有延迟（物理约束）
        两个系统之间必然存在信息不对称窗口（信息论约束）

Step 3: 推导设计决策
  → 给定约束，理性设计者必然选择什么？
  → 问法：给定这些约束，有哪些设计空间？最优选择是什么？
  → 例：gas 太贵 → 链下撮合是唯一可行选择
        链下撮合需要可信方 → Operator 模型是自然结果

Step 4: 从设计决策推出不可消除的行为约束
  → 这个设计选择带来了哪些无法消除的副作用（行为约束）？
  → 问法：做了这个选择，哪些事情"必然"成立？哪些事情"绝对不可能"？
  → 例：链下撮合 → 存在"不确定窗口"（从下单到链上确认之间状态不确定）
        不确定窗口 → 任何依赖"下单即确认"的代码必然产生 ghost 仓位

Step 5: 用这些约束评估代码实现
  → 代码是否违反了某个不可消除约束？
  → 问法：这段代码假设了什么？这个假设和约束链矛盾吗？
  → 例：在不确定窗口内做 DB 写入 → 假设"下单即持仓" → 违反 Step 4 约束
        → 这段代码必然产生 ghost 仓位 → 不是 typo，是架构错误
```

### SOP 使用注意

- Step 1-2 是**发现**约束，Step 3-4 是**推导**约束，Step 5 是**应用**约束
- 每一步要明确**推断置信度**。高置信（数学必然）vs 中置信（设计最优选择）vs 低置信（推断但未验证）
- 低置信推断必须记录到 KNOWLEDGE_GAPS，不能当作高置信使用
- SOP 可以反向使用：从一个已知 bug 反推"哪个约束被违反了"（fault attribution）

---

## 第三部分：三个完整的元思考案例

### 案例 1：为什么 pre-fill DB write 是架构错误而不是 typo

**问题**：发现代码在 order 提交后、fill 事件收到前就写了 DB 仓位记录。是 typo 还是架构错误？

**元思考推导**：

```
Step 1: Polymarket 要解决的核心问题
  → 让预测市场可交易，同时保证结算的可信性（链上合约）
  → 可信性要求：最终状态由链上合约决定，不由任何中心化方决定

Step 2: 不可回避的工程约束
  → 链上操作有 gas 成本（约束 A）
  → 区块确认有不确定延迟（约束 B）
  → 约束 A + B → 链下撮合是必然选择（否则每次下单都要等链上确认，体验不可接受）

Step 3: 设计决策
  → 采用链下 CLOB + 链上 CTF Exchange 的混合架构
  → 订单在链下撮合，撮合结果批量提交链上

Step 4: 不可消除的行为约束
  → 从"用户提交 order"到"链上确认成交"之间，存在不确定窗口
  → 在此窗口内，order 可能：成交、部分成交、被取消、超时、链下拒绝
  → 约束：在链上确认前，任何仓位状态都是"未确定"的
  → 推论：任何依赖"提交 order 即持仓"的代码，必然在某些场景下产生错误仓位

Step 5: 评估代码
  → pre-fill DB write 假设：提交 order 之后，仓位就存在了
  → 这个假设违反了 Step 4 的约束：提交 order ≠ 持仓确认
  → 结论：这不是"漏写了一个 await"，而是违反了混合撮合系统的不确定窗口约束
  → 修复方向：仓位记录必须在 fill 事件确认后写入，不能在 order 提交后写入
```

**结论**：这是架构错误。即使把代码改得再"干净"，只要保留 pre-fill write 的时序，ghost 仓位就会必然出现。修复必须改变写入时序。

---

### 案例 2：为什么 FAK 的 WS 事件顺序问题无法从"修代码"角度解决

**问题**：FAK 订单有时 WS 的 `USER_TRADE`（成交）事件在 `USER_ORDER`（订单状态）事件之后才到。代码依赖某个顺序，偶发 bug。能通过调整代码处理顺序修复吗？

**元思考推导**：

```
Step 1: WS 是什么
  → WebSocket 是 Polymarket 提供的实时推送基础设施
  → 目的：让客户端感知订单/成交的"尽快通知"

Step 2: WS 的工程约束
  → WS 是 best-effort 推送（无法保证消息顺序）
  → 这不是设计选择，是网络层的物理约束：
    - 链下 CLOB 服务和 WS 推送服务是不同进程
    - 成交事件和订单状态事件来自不同来源
    - 任何多路消息系统都无法保证跨来源的消息有序性

Step 3: Polymarket 的设计决策
  → WS 提供 best-effort 通知，不提供顺序保证
  → 链上状态（通过 API/链上查询）是最终真相
  → WS 是"加速感知"，不是"权威来源"

Step 4: 不可消除的行为约束
  → WS 事件顺序不被保证（这是约束，不是 bug）
  → 任何依赖 WS 事件特定顺序的代码，都会在网络波动时失败
  → 最终一致性只能由链上查询（reconcile）保证

Step 5: 评估"修代码"方案
  → 方案 A：调整代码处理顺序（先等 USER_ORDER，再处理 USER_TRADE）
    → 假设：如果等待足够长，顺序会正确
    → 反驳：WS 顺序无法被保证，等待只是降低了失败概率，不是消除
  → 方案 B：用 reconcile 保证最终一致性
    → 假设：WS 是加速通知，reconcile 是权威来源
    → 符合约束：reconcile 通过链上/API 查询，不依赖 WS 顺序
    → 结论：方案 B 是正确架构
```

**结论**：试图通过"修代码处理顺序"解决这个问题是错误方向。正确做法是接受 WS 的 best-effort 语义，用 reconcile 保证最终一致性。任何依赖 WS 顺序的代码都是架构上脆弱的。

---

### 案例 3：如何判断一个新发现的 discrepancy 是我们的 bug 还是 Polymarket 的行为

**问题**：reconcile 发现 DB 中一个仓位的数量和 Polymarket API 返回的数量不一致。这是我们的 bug 还是 Polymarket 的问题？

**元思考推导**：

```
Step 1: Polymarket 的真相层级
  → 链上合约是最终权威（数学不可篡改）
  → Polymarket API 是链上状态的索引（should mirror 链上）
  → WS 是链上/API 的推送（best-effort）
  → 我们的 DB 是我们对上述的本地记录

Step 2: 不可回避的约束
  → 链上合约状态是最终真相，所有其他层必须与之对齐
  → API 是 Polymarket 的责任范围，链上是公开可验证的

Step 3: 推导判断框架
  → 如果链上 ≠ API：这是 Polymarket 的 indexer/API 问题
  → 如果链上 = API ≠ DB：这是我们的 bug（我们的 DB 没正确跟踪）
  → 如果链上 = API = DB ≠ 期望值：这是我们对"期望值"的理解错误

Step 4: 不可消除约束
  → 链上是公开账本，不可否认
  → 我们的 DB 只是本地快照，必然落后于真相
  → 任何 DB 状态与链上不一致的情况，在没有证明 Polymarket 链上错误的前提下，
    都应假设是我们的 bug

Step 5: 操作化判断步骤
  1. 先查链上（CTF Exchange events / ERC1155 balance）
  2. 再查 Polymarket API（/data/positions 或 /trades）
  3. 比对：链上 vs API
     → 一致 → 这是我们的 bug，检查 DB 写入逻辑
     → 不一致 → Polymarket 问题，记录 discrepancy，等待 Polymarket 自愈
  4. 无论哪种情况，都要记录发现（KNOWLEDGE_GAPS 或 bug report）
```

**结论**：判断标准是"链上真相"，不是"API 返回"或"我们的期望"。链上查询和 API 返回一致但与 DB 不一致 = 我们的 bug。链上和 API 不一致 = Polymarket 的问题（极少见，但存在）。这个框架消除了"到底是谁的问题"的模糊性。

---

## 第四部分：元思考的局限性

### 元思考不是万能的

**需要基础知识**：元思考需要对底层系统有足够了解。没有读过 L1-L4（CTF 合约、CLOB 架构、订单类型、WS 数据层），推导很容易出错。元思考是在知识之上的推理，不是替代知识。

**推导可能有错误**：推导链中任何一步假设错误，结论都会错。这是为什么 `guide-polymarket-fundamentals` 使用 `confidence` 标注，并维护 KNOWLEDGE_GAPS。低置信推断需要用实际验证来确认或推翻。

**对实现细节无能为力**：Polymarket 的内部实现细节（例如：FAK 订单的链下拒绝具体发生在哪个微服务）无法从第一性原理推导。这类知识只能通过文档、API 测试、或源码（如果开源）获得。

### 元思考的适用场景

**适合**：
- 面对设计决策时（我应该用 FOK 还是 FAK？这段代码应该在 fill 前还是 fill 后写 DB？）
- 面对 bug 时（这个 bug 的根本原因是什么？是我们的 bug 还是 Polymarket 的行为？）
- 面对不确定性时（我不知道 Polymarket 怎么处理 X，但我可以推断出它必然遵守哪些约束）
- 评估新代码时（这段代码的假设和系统约束一致吗？）

**不适合**：
- 需要精确数字（合约地址、API 字段名、费率参数）→ 查文档
- 需要了解具体实现（某个 API 的响应格式）→ 查文档 + 实测
- 已经有高置信知识 → 直接用，不需要重新推导

### 置信度管理

元思考的输出要标注置信度：

| 置信度 | 含义 | 处理方式 |
|-------|------|---------|
| 高（数学必然） | 从工程约束直接推出，无假设 | 可以直接用于 eval 标准 |
| 中（设计最优） | 理性设计者的最优选择，但存在其他可能 | 用于 eval，但保留验证意识 |
| 低（合理推断） | 基于类比或部分证据的推断 | 记录到 KNOWLEDGE_GAPS，不用于强断言 |

---

## 第五部分：MetaThink 在我们项目里的体现

`guide-polymarket-fundamentals` 是元思考在 Polymarket 上的系统化应用：

### 结构对应关系

| guide-polymarket-fundamentals 组件 | 元思考 SOP 对应 |
|----------------------------------|----------------|
| **L0 设计推理层** | Step 1-4 的产物：核心问题 → 约束 → 设计决策 → 行为约束 |
| **L1-L4 知识层** | Step 2 的验证材料：具体知识用于确认推断的约束是否准确 |
| **L5 我们系统层** | Step 5 的产物：将约束应用于我们的代码，找出潜在违反 |
| **KNOWLEDGE_GAPS** | 低置信推断的存放处：元思考边界，待验证的假设 |
| **Fault Attribution Matrix** | Step 5 的反向应用：从已知 bug 追溯到哪个约束被违反 |

### L0 的特殊地位

L0（`knowledge/L0-design-reasoning.md`）是整个知识库中最重要的文件，因为它是**元思考的直接产物**。

其他层（L1-L4）是"Polymarket 是什么"，L0 是"为什么 Polymarket 必须这样"。L0 提供的 Eval 标准是高置信约束，可以用来评估任何代码是否正确，不需要读完所有文档。

### 使用建议

当你需要判断代码正确性时：
1. **先读 L0** — 获取高置信约束和 Eval 标准
2. **按需读 L1-L4** — 补充具体知识验证推断
3. **如果卡住** — 检查 KNOWLEDGE_GAPS 是否有相关 GAP，用元思考 SOP 推导一步

---

## 结尾：元思考的核心原则（3条）

### 原则 1：约束先于功能

理解一个系统，先找它的**不可消除约束**，再看它的功能。

功能可以改变（Polymarket 可以新增订单类型），约束不会改变（链上确认延迟是物理约束）。基于功能建立的心智模型会随文档更新而过时；基于约束建立的心智模型是稳定的。

应用：当看到一个新功能或 API，先问"它受哪些约束限制"，再问"它能做什么"。

### 原则 2：推导先于查找

在查文档之前，先推导"应该是什么"，再用文档验证。

推导的过程本身有价值——即使推导结果和文档一致，推导帮助你理解"为什么"，而不只是"是什么"。当文档缺失或错误时，你的推导是唯一的导航工具。

应用：面对一个不确定的行为，先用 SOP 推导"根据约束，这个行为应该是什么"，再查文档或实测确认。

### 原则 3：归因先于修复

找到 bug 的根本原因（**哪个约束被违反了**），再决定如何修。

表面修复（改一个变量名、加一个 null check）不能解决架构级违反。归因到约束层面后，修复方向才清晰：要么让代码尊重约束，要么（极少情况）证明这个场景不受该约束限制。

应用：发现 bug 后，不要立即看"怎么修"，先回答"这段代码假设了什么，这个假设违反了哪个不可消除约束"。

---

> **元思考的终极目标**：在任何陌生系统面前，能从第一性原理推导出"什么代码必然正确、什么代码必然错误"，而不依赖文档的完整性或他人的经验传授。

---

## 第六部分：从文档推断未记录行为

**这是元思考最重要的扩展能力：用已知文档推断出文档没有明确说的东西。**

### 为什么需要这个能力

Polymarket（或任何复杂系统）的文档永远是不完整的。文档说的是"happy path"，但我们关心的是边界行为：
- FAK 余量取消产生链上事件吗？（文档没说）
- GTD 的过期在链下还是链上执行？（文档没说）
- WS USER_TRADE 事件能否作为成交的最终确认？（文档没说）

元思考允许你从已有文档推断这些答案，并给出置信度评估。

### 推断的标准模板

```
[观察] 文档/代码中的 X
[约束] 来自 L0 设计推理的约束 Y（不可消除的）
[推断] 因此，行为应该是 Z
[置信度] HIGH / MEDIUM / LOW
[验证方法] 具体可执行的测试步骤
[代码含义] 这个推断意味着我们的代码应该/不应该做什么
```

### 三个完整推断示例

**推断示例 1：GTD 过期时间的执行位置**

```
[观察] CLOB API 文档：GTD 订单需要设置 expiration 字段（Unix 时间戳）
[观察] CTF Exchange 合约 ABI：matchOrders() 函数签名不包含 expiration 参数
[约束] 合约只验证签名有效性和代币余额，不验证时间戳（链上没有可靠时钟）
[推断] GTD 的过期检查必然发生在链下（CLOB operator 侧），而非合约层
[置信度] HIGH（合约 ABI 已验证）
[验证方法] 提交一个 10 秒后过期的 GTD 订单，过期后查链上是否有取消记录
[代码含义] GTD 过期事件通过 WS USER_ORDER CANCELLATION 送达，
            不会在链上留下 Transfer 痕迹，reconcile 不能从链上检测 GTD 取消
```

**推断示例 2：FAK 部分成交的 WS 事件数量**

```
[观察] Polymarket 文档：FAK = Fill available, Kill rest
[观察] 我们代码（monitor.ts）观察到：单次 FAK 可触发多个 USER_TRADE 事件
[约束] 链下撮合是逐笔匹配（每个 maker 订单单独匹配）
[推断] FAK 会为每个被匹配的 maker 订单产生一个独立的 USER_TRADE 事件，
        而不是一个汇总事件
[置信度] HIGH（代码实际观测）
[验证方法] 在 orderbook 深度允许的情况下下一个 FAK，监控 WS 接收到几个 USER_TRADE
[代码含义] 处理 FAK 成交时必须累加多个 USER_TRADE 事件的 size，
            不能假设"一个 FAK = 一个 TRADE 事件"
```

**推断示例 3：NegRisk 市场的价格约束**

```
[观察] Polymarket 文档：NegRisk = 多选项共享抵押品，有且只有一个选项 YES 赢
[约束] 因为只有一个选项能赢，所有选项的 YES 价格之和必然接近 1
[推断] NegRisk 市场所有选项的 YES midpoint 之和 ≈ 1（而非标准市场的单个 YES+NO≈1）
[置信度] MEDIUM（逻辑推断，未直接验证）
[验证方法] 取一个有 5 个选项的 NegRisk 事件，查所有选项的 YES midpoint，求和
[代码含义] 对 NegRisk 市场做套利检测时，不能用单市场的 YES+NO≈1 公式，
            而要用所有选项 YES 之和 ≈ 1 的约束
```

### 推断的置信度管理

推断的可信度取决于推导链的强度：

| 置信度 | 条件 | 处理方式 |
|--------|------|---------|
| HIGH | 直接从合约 ABI 或实际观测得出 | 可以直接用于代码决策 |
| MEDIUM | 逻辑推断，有 1-2 个假设前提 | 用于代码决策前先验证 |
| LOW | 多层推断，假设较多 | 记录到 KNOWLEDGE_GAPS，标注为待验证 |

**关键原则**：低置信度推断不能直接用于代码，必须先通过 API 测试验证后才能升级为 HIGH。

### 推断 vs 猜测的区别

推断是有依据的：每步都要标注来源（文档/合约/代码观测）。
猜测是没有依据的：不能进入知识库。

```
✅ 推断：文档说 matchOrders() 的 fee 参数类型是 uint256，
         因此 fee 不可能是负数，因此手续费只能是正向收取，不可能返还。

❌ 猜测："我觉得 Polymarket 可能会返还手续费" — 没有文档/合约依据
```

### 在 guide-polymarket-fundamentals 中的落地

当你通过上述方法产生了一个新推断：

1. 先在 `references/api-verification.md` 的"推断示例"部分记录完整推导链
2. 在对应的 Lx 文件里用 FACT 注释记录，标注 `source_type: INFERRED`，`confidence: MEDIUM/LOW`
3. 在 `KNOWLEDGE_GAPS.md` 提交 GAP，等待验证
4. 验证通过后，升级 confidence 为 HIGH，更新 `last_verified`

---

## 第七部分：元思考的元思考（递归应用）

**元思考本身是一个工具。工具也有它的第一性原理。**

**为什么需要元思考？**

文档是有限的，系统行为是无限的。在任何足够复杂的系统里，你不可能读完所有文档。但有一件事比功能更持久：约束。

Polymarket 的 API 字段会变，但"混合撮合系统存在不确定窗口"这个约束不会变，因为它来自物理/数学的必然性。**研究约束比研究功能有更高的知识 ROI**——这就是元思考存在的理由。

**元思考自身的不可消除约束（4条）**：

```
约束 A：推导链的强度 = 最弱假设的强度
  → 错误的出发点产生自洽但错误的结论
  → 处理方式：标注每个推断的前提假设，单独验证前提

约束 B：元思考需要种子知识，不能凭空推导
  → 必须有最小可信基础（合约 ABI / 实测数据 / 官方文档）
  → 处理方式：FACT 注释的 source_type 字段，HIGH confidence 必须有来源

约束 C：没有验证的推断会变成"自信的错误"
  → 元思考产生假设，不产生事实
  → 处理方式：所有 INFERRED 节点必须有验证方法，进入 KNOWLEDGE_GAPS

约束 D：Blind Spots — 你不知道你不知道的约束
  → 元思考无法推导出你完全不知道的约束
  → 处理方式：reconcile 作为 ground truth，发现未知约束
```

**元思考的失效边界**：

| 场景 | 元思考是否有效 | 替代方法 |
|------|--------------|---------|
| 系统设计决策（为什么有 4 种订单类型？） | ✅ 高效 | — |
| 边界行为推断（GTD 过期在链上还是链下？）| ✅ 有效，但需验证 | API 实验验证 |
| 具体实现细节（某 API 字段的精确格式？）| ❌ 低效 | 直接查文档 |
| 未知的系统 bug（Polymarket 内部 bug）| ❌ 无法推导 | 实测 + 对比多数据源 |
| 商业决策（为什么定这个手续费率？）| ❌ 无法推导 | 查公告或不推断 |

---

## 第八部分：元思考应用于 Agent Teams 设计

**这是元思考最重要的一个应用场景：如何设计 agent 协作结构。**

大多数人设计 agent teams 时是凭直觉（"这个 agent 做 A，那个做 B"）。元思考要求你从约束推导设计：

**Agent 信息处理的不可消除约束：**

```
约束 1：上下文污染
  单个 agent 在两个不同信息域（外部文档 / 内部代码）间频繁切换
  → 前一个任务的上下文干扰后一个任务的判断
  → 结论：信息来源不同的任务应该由不同 agent 承担

约束 2：专注度递减
  agent 的注意力是有限的
  → 任务越复杂，越容易在细节中丢失大局
  → 结论：Lead agent 的职责是保持北极星目标，不执行细节

约束 3：信息不对称的价值
  两个 agent 独立研究同一问题 → 结果差异揭示不确定性
  → 交叉验证比单 agent 更可靠
  → 结论：对于高 stakes 问题，parallel agents + Lead 交叉验证

约束 4：合成窗口
  Lead 做合成时，需要看到所有子 agent 的完整输出
  → 如果子 agent 输出太长或太分散，Lead 无法有效合成
  → 结论：子 agent 必须产出结构化、可对比的输出格式
```

**从这些约束推导出的 Agent Teams 设计原则：**

```
原则 1：按信息来源分工，不按功能分工
  ❌ "agent A 做前半部分，agent B 做后半部分"
  ✅ "agent A 研究外部文档，agent B 分析内部代码"
  原因：前者仍然需要共享上下文，后者真正实现了信息隔离

原则 2：Lead 不执行，只合成和决策
  ❌ Lead 同时研究文档和写代码
  ✅ Lead 只看子 agent 的输出，做交叉验证和最终判断
  原因：Lead 进入执行细节 = 丢失北极星目标

原则 3：子 agent 输出必须可对比
  ❌ 子 agent 随意格式输出
  ✅ 统一格式（表格 / FACT 注释）让 Lead 一眼看出差异
  原因：无结构输出 = 信息熵太高 = Lead 合成成本过高

原则 4：设计验证点，不只是分工
  parallel agents 完成后，Lead 必须问：
  "这两份结果哪里一致？哪里矛盾？矛盾意味着什么？"
  一致 → 提高 confidence
  矛盾 → 进入 KNOWLEDGE_GAPS，标注 LOW confidence
```

**实际案例：Polymarket 文档索引的 agent teams 设计**

```
问题：如何建立"场景 → 文档"的映射？

约束分析：
  - 场景知识来自"我们遇到的问题"（内部代码 / bug history）
  - 文档知识来自"Polymarket 提供了什么"（外部网络）
  - 两者信息来源完全不同 → 适合并行 agent

设计决策：
  Agent A：外部文档研究（WebFetch + context7）
  Agent B：内部代码分析（Glob + Read + Grep）
  Lead：交叉验证（文档说有 X API → 代码里是否用了？
                  代码里有 Y 场景 → 文档里是否有对应的 API？）

验证点：
  - 代码里 import 了 DataApiClient → 文档里必须有 Data API 说明
  - 文档里说有 /neg-risk/{token_id} endpoint → 代码里 TradingService 应该调用它
  - 如果代码用了但文档没有 → 可能是 undocumented API（标注 GAP）
  - 如果文档有但代码没用 → 可能是我们的遗漏（标注为待研究）
```

---

## 第九部分：Meta-Think 的形式化定义 (v5.1.1)

> 补充于 2026-04-13, 基于 v5.1 dogfood session 的反思：
> "我们的 meta 是带 frontmatter 的笔记，不是 proper meta-think"。

### 什么是 meta-think vs 什么是 note

**Meta-think** = 一个**自足的推断单元**，回答 6 个结构化问题，可以被其他 meta-think 引用、验证、推翻、合并。

**Note** = 一段自由文本记录，没有结构化的假设/置信度/证伪条件。Notes 有记录价值但没有推理价值 — 它不能被其他 meta-think "推翻"或"验证"，因为它没有明确的 claim。

**判断标准**：如果你不能写出 ≤200 字的 `essence`（核心发现），它不是 meta-think — 它是 note。Notes 可以存在，但不应该在 meta chain 上占据 node 位置。

### 6 必答题 — Meta-Think 的定义

每个 meta-think 必须结构化回答以下 6 个问题：

| # | 问题 | frontmatter 字段 | 对应 SOP 步骤 | canvas 显示层 |
|---|------|-----------------|-------------|--------------|
| **Q1** | 你发现了什么？ | `essence` (≤200字) | SOP 全链的浓缩 | **Node 文字** (唯一) |
| **Q2** | 你假设了什么？ | `assumptions: []` | Step 1-2 的前提 | Click detail |
| **Q3** | 你多确定？ | `confidence` + `confidence_reason` | 置信度管理 (§第四部分) | **Badge on node** |
| **Q4** | 什么能证伪你？ | `invalidation` | Step 4 约束的反面 | Click detail |
| **Q5** | 基于什么前置研究？ | `prior_evidence: []` | 种子知识 (约束 B) | Click detail |
| **Q6** | 识别了什么约束？ | `constraints: []` | Step 2-4 的产出 | Click detail |

### 为什么是这 6 个，不多不少

从 §第七部分 元思考自身的 4 条约束推导：

| 约束 | 推导出的必答题 |
|------|--------------|
| **约束 A**: 推导链强度 = 最弱假设 | → Q2 (assumptions) + Q3 (confidence) |
| **约束 B**: 需要种子知识 | → Q5 (prior_evidence) |
| **约束 C**: 未验证推断 = "自信的错误" | → Q4 (invalidation) |
| **约束 D**: Blind Spots | → Q6 (constraints) — 显式记录识别的约束，让 blind spots 可追溯 |
| — | → Q1 (essence) — 如果 meta-think 的结论不能浓缩为 ≤200 字，说明推导链不清晰 |

6 必答题是 §第七部分 4 条约束的**可操作化版本**。

### Essence 的写法

Essence 不是 summary（摘要），是 **distillation（蒸馏）**：

| 不好的 essence (summary) | 好的 essence (distillation) |
|--------------------------|---------------------------|
| "调查了 C4 economy chain adj 的效果" | "C4 economy adj 在 bin 0.3-0.4 时 -$0.71 Brier，但 PnL 无改善 → model calibration 有 ceiling" |
| "修复了 A3 settlement pipeline" | "Settlement PnL 需要 resolution 数据流过完整管线 — 缺任何一环都静默输出 M2M 而非 settlement" |
| "研究了 Mars API 数据" | "Mars REST /result endpoint 需要 tier 升级(40302)，pagination 默认 20 导致截断 — 只有 WS 是实时可靠数据源" |

**写法 SOP**: 先写 Conclusions，然后问自己"如果只让我说一句话，对方听完能知道什么"。那一句话就是 essence。

### Meta-Think Chain 的语义 (metas 之间的关系)

约束传播不止在单个 meta 内部（SOP Step 1-5），也在 meta 之间传播：

| 关系 | 含义 | frontmatter | 置信度影响 |
|------|------|-------------|-----------|
| `parent → child` | 从 A 派生出 B（分叉研究） | B 的 `parent: A` | B 继承 A 的 assumptions |
| `supersedes` | B 推翻 A 的结论 | B 的 `supersedes: [A]` | A 的 confidence → LOW，A 的 status → superseded |
| `validates` | B 独立验证了 A 是正确的 | B 的 `validates: [A]` | A 的 confidence → 升一级 (LOW→MED, MED→HIGH) |
| `consolidates` | C 合并 A+B+D 为本质总结 | C 的 `consolidates: [A,B,D]` | C 的 confidence = max(A,B,D) + 合并分析 |

**Supersedes 的第一性原理**：B 推翻 A ≠ "A 错了"。B 说的是 "A 的某个 assumption 被证伪了"（Q2 的哪一条假设被推翻）。这让推翻是可追溯的 — 不是 blanket 否定，是 specific assumption failure。

**Consolidation 的第一性原理**：当 N 个 meta-think 围绕同一主题从不同角度研究后，
Lead 提取**本质认知**（大 meta）和**细枝末节**（小 meta）。大 meta 的 essence 是跨 N 个 meta 的 synthesis，小 meta 标记为 `status: consolidated` 并指向大 meta。

### Confidence 衰减

一个 HIGH confidence 的 meta-think，如果满足以下条件之一，confidence 应被降级：

| 条件 | 降级到 | 原因 |
|------|--------|------|
| 6 个月内没有被 validate 或 reference | MED → LOW | 系统可能已经变化，旧约束推导可能不成立 |
| 依赖的 prior_evidence 中有 meta 被 superseded | 跟随降级 | 推导链上游失效 → 下游不可信 |
| assumption 中的某个外部条件已变化 | 需要重新 validate | e.g., Polymarket API 更新 |

**Meta-meta agent** 应该在 /loop 扫描中检测 "stale high-confidence" metas，
生成 WARNING: "meta-X confidence=HIGH 但 180 天未被 reference，建议 revalidate"。

### Essence 作为元思考的"原子单位"

**从 §第二部分 SOP 到 essence 的完整路径**：

```
Step 1: 定义核心问题
  ↓
Step 2: 识别不可回避约束 → Q6 constraints
  ↓
Step 3: 推导设计决策 → Q5 prior_evidence (基于什么推导)
  ↓
Step 4: 推出不可消除行为约束 → Q4 invalidation (反面是什么)
  ↓
Step 5: 评估代码/行为 → Q1 essence (结论)
  ↓
  标注 Q2 assumptions + Q3 confidence
```

**Essence 是 SOP Step 5 的终点**。如果你不能从 Step 1 走到 Step 5 并浓缩为 ≤200 字 essence，
说明中间某一步推导不清楚。**写 essence 的过程就是验证你是否真正理解了这个 meta-think 的本质。**

### 实际模板（供 v5/03-标准ritual.md 引用）

完整的 meta-think frontmatter + body 模板见 [`v5/03-标准ritual.md §3.5`](../guide-meta-agent-system/v5/03-标准ritual.md)。

---

## 第十部分：总结 — 三条原则的扩展

在 §结尾 的 3 条原则基础上，v5.1.1 补充 3 条：

### 原则 4：浓缩先于记录

写 meta 之前，先写 essence。如果 essence 写不出来，meta 不值得写 — 你还没想清楚。
记录 1000 行没有 essence 的细节 ≠ meta-thinking。反过来，1 行精准的 essence > 10 页散乱的笔记。

应用：每个 meta 的第一个动作是写 essence（草案），最后一个动作是更新 essence（终版）。

### 原则 5：假设显式化

每个推断都有隐含假设。不写出来 = 你无法被证伪 = 你也无法被验证。
显式写出 `assumptions` 让你的 meta-think 变成**科学假说**而不是**个人意见**。
科学假说能被推翻和改进，意见只能被争论。

应用：写 meta 时强制填 `assumptions: []`。如果列表为空，说明你没思考前提。

### 原则 6：证伪是进步

一个 meta-think 被 supersede 不是失败，是系统在进步。
被 supersede 的 meta 说明了"为什么那个方向不对" — 这个信息本身有巨大价值。
meta chain 上的 supersede edges 是**知识进化的路径**，不是错误记录。

应用：永远不删除被 supersede 的 meta。标记 `status: superseded` + `superseded_by: [meta-id]`，让整条演化路径可追溯。