| name | guide-meta-thinking |
| description | 元思考（MetaThink）方法论：从第一性原理推导系统行为，而非机械查文档。
核心是理解"为什么这样设计"而非"它是什么"，从设计约束推导出不可消除的行为边界，
用这些边界作为代码正确性的 eval 标准，并区分"我们的 bug"与"系统的固有限制"。
有以下意图时必须加载此 skill：
(1) 不知道某个行为是 bug 还是系统正常行为 → 用元思考做 fault attribution
(2) 面对新的技术系统，需要快速建立正确的心智模型 → 用元思考推导约束
(3) 对一段代码有多种实现方式，不知道哪种正确 → 用元思考找 eval 标准
(4) reconcile 发现异常，不确定根因 → 用元思考的约束链追溯
(5) 需要理解为什么 guide-polymarket-fundamentals 这样设计 → 读本 skill
|
| tags | ["meta-thinking","first-principles","methodology","eval","fault-attribution","meta-chain","essence"] |
| domain | pm |
| created | 2026-03-23T00:00:00.000Z |
| updated | 2026-04-15T00:00:00.000Z |
元思考（MetaThink）方法论
Patterns（可复用工作流）
核心定义：元思考不是"知道答案"，而是"知道如何推导答案"。
第一部分：元思考是什么
两种思维模式的对比
文档思维：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 标准是高置信约束，可以用来评估任何代码是否正确，不需要读完所有文档。
使用建议
当你需要判断代码正确性时：
- 先读 L0 — 获取高置信约束和 Eval 标准
- 按需读 L1-L4 — 补充具体知识验证推断
- 如果卡住 — 检查 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 中的落地
当你通过上述方法产生了一个新推断：
- 先在
references/api-verification.md 的"推断示例"部分记录完整推导链
- 在对应的 Lx 文件里用 FACT 注释记录，标注
source_type: INFERRED，confidence: MEDIUM/LOW
- 在
KNOWLEDGE_GAPS.md 提交 GAP，等待验证
- 验证通过后，升级 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。
第十部分：总结 — 三条原则的扩展
在 §结尾 的 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]，让整条演化路径可追溯。
