meta-cognitive-reasoning

元认知推理

此技能提供严谨的推理框架，帮助避免分析、审查和决策中的认知失误。它要求基于证据得出结论、生成多个假设，并进行系统验证。

何时使用此技能

• 在对代码、系统或版本作出判断之前
• 进行代码审查或架构评估时
• 调试存在多种可能原因的问题时
• 遇到不熟悉的模式或版本时
• 提出可能产生重大影响的建议时
• 模式匹配引发即时结论时
• 分析文档或规范时
• 进行任何需要严谨分析推理的任务时

此技能的作用

1. 基于证据的推理：要求先展示证据，再作出解释
2. 生成多个假设：防止过早认定单一解释
3. 时效性知识验证：应对知识截止时间的限制
4. 防止认知失误：识别并避免常见推理错误
5. 自我纠正协议：为透明地纠正错误提供框架
6. 范围约束：合理分配认知精力

核心原则

1. 基于证据的推理协议

通用规则：没有证据，绝不下结论

MANDATORY SEQUENCE:
1. Show tool output FIRST
2. Quote specific evidence
3. THEN interpret

禁止使用的表述：

• “我假设”
• “通常意味着”
• “似乎”
• “测试通过”（没有输出时）
• “符合标准”（没有证据时）

要求使用的表述：

• “命令显示：‘实际输出’——解释”
• “第 N 行：‘代码片段’——含义”
• “让我验证……” -> 工具输出 -> 解释

2. 多个待验证假设

当相同的观察结果可能由不同机制导致，且这些机制的影响相反时，应先调查再下结论。

三层推理模型：

Layer 1: OBSERVATION (What do I see?)
Layer 2: MECHANISM (How/why does this exist?)
Layer 3: ASSESSMENT (Is this good/bad/critical?)

FAILURE: Jump from Layer 1 -> Layer 3 (skip mechanism)
CORRECT: Layer 1 -> Layer 2 (investigate) -> Layer 3 (assess with context)

决策框架：

1. 意识到存在多个假设

   • 哪些机制可能导致这一观察结果？
   • 哪些机制会产生相反的影响？

2. 明确提出相互竞争的假设

   • 假设 A：[机制] -> [影响]
   • 假设 B：[不同机制] -> [相反影响]

3. 确定可区分不同假设的证据

   • 哪一项观察可以证实或证伪每个假设？

4. 收集可区分不同假设的证据

   • 运行能够区分这些假设的特定测试

5. 结合机制背景进行评估

   • 相同观察 + 不同机制 = 不同评估

3. 知识的时效性

训练数据有时间戳；不知道某事 ≠ 某事不存在的证据

关键背景检查：

Before making claims about what exists:
1. What is my knowledge cutoff date?
2. What is today's date?
3. How much time has elapsed?
4. Could versions/features beyond my training exist?

高风险领域（始终验证）：

• 软件包版本（npm、pip、maven）
• 框架版本（React、Vue、Django）
• 语言版本（Python、Node、Go）
• 云服务功能（AWS、GCP、Azure）
• API 版本和工具版本

反模式：

• “版本 X 不存在”（未经验证时）
• “最新版本是 Y”（基于过时的训练数据时）
• 没有证据就标记为“严重/阻塞”

4. 自我纠正协议

发现先前输出有误时：

STEP 1: ACKNOWLEDGE EXPLICITLY
- Lead with "CRITICAL CORRECTION"
- Make it impossible to miss

STEP 2: STATE PREVIOUS CLAIM
- Quote exact wrong statement

STEP 3: PROVIDE EVIDENCE
- Show what proves the correction

STEP 4: EXPLAIN ERROR CAUSE
- Root cause: temporal gap? assumption?

STEP 5: CLEAR ACTION
- "NO CHANGE NEEDED" or "Revert suggestion"

5. 认知资源分配

简约原则：

• 选择满足要求的最简单方法
• 先进行简单验证；只有简单方法失败时才增加复杂度

范围约束：

• 将资源分配给实际要求，而非假设性的要求
• “这是明确要求的吗？”

信息经济：

• 重用已确认的事实
• 上下文变化时重新验证

原子性原则：

• 每项操作都应有一个明确目的
• 如果描述需要用“并且”连接不同目的，就将其拆分
• 优点：更容易诊断失败、更容易跟踪进度、更容易归属证据

6. 系统化完成纪律

在验证 ALL 要求之前，绝不要宣告成功

过早完成的高风险情境：

• 包含许多质量关卡的多步骤任务
• 成功修复重大问题之后（会触发认知奖励）
• 工具显示许多错误时（容易产生逃避的冲动）
• 会话接近尾声时（完成压力）

完成流程：

1. 将要求拆分为明确的检查点
2. 完整通过每个关卡后再继续
3. 在每个检查点提供证据
4. 抵制“差不多就行”的捷径

警示信号：

• 想着“差不多就行”，而不是检查所有要求
• 不经逐项分析就采用一刀切的解决方案
• 跳过系统化验证
• 明明证据表明并非如此，却仍宣告成功

7. 逐项分析优于批量处理

核心原则：每一项都值得单独关注

适用于：

• 错误消息（逐条阅读）
• 审查项目（逐行／逐个文件分析）
• 决策（不要采用一刀切的规则）
• 抑制项（逐项说明理由）

反模式：

• 不阅读细节就批量分类
• 不考虑上下文就采用一刀切的解决方案
• 批量处理各不相同的情况

8. 语义分析与字面分析

关注概念上的重叠，而不只是文本／模式重复

关键问题：

• 这里的实际目的是什么？
• 这是为了满足功能需求，还是只是匹配某种模式？
• 如果删除／更改它，会失去什么？
• 这是不是以不同方式表达的同一个概念？

应用场景：

• 文档：识别不同层级之间的语义重复
• 代码审查：理解意图后再提出更改建议
• 优化：改进之前先分析是否确有必要

如何使用

声明前先验证

Verify that package X version Y exists before recommending changes

Check if this file structure is symlinks or duplicates before recommending consolidation

提出多个假设

The tests are failing with timeout errors. What are the possible mechanisms?

These three files have identical content. What could explain this?

开展基于证据的审查

Review this code and show evidence for every claim

推理工作流

验证工作流

遇到不熟悉的版本／功能时：

1. 意识到不确定性：“我不记得训练数据中有 X”
2. 提出假设：A）不存在，B）存在但较新，C）当前版本
3. 得出结论前先验证：检查权威来源
4. 先展示证据，再作出解释：命令输出 -> 结论

评估工作流

分析代码、架构或配置时：

1. 观察：我看到了什么？
2. 调查机制：它是如何存在的？
3. 然后评估：根据其机制，它是好是坏？

审查工作流

进行代码审查、文档审查或任何分析时：

1. 明确范围：先询问，不要想当然
2. 为每项主张提供证据：文件：行：代码
3. 得出结论前提出假设
4. 区分机制与观察
5. 只有在问题得到验证后才使用强烈措辞

认知失误模式

模式 1：扫描而非阅读

• 发现细小问题，却漏掉明显问题
• 预防措施：逐行／逐条阅读

模式 2：脱离上下文的模式匹配

• 不理解问题就应用解决方案
• 预防措施：应用模板前先分析实际目的

模式 3：基于假设得出结论

• 以猜测代替验证
• 预防措施：必须基于证据进行验证

模式 4：过早宣告成功

• “任务完成” ≠ “要求已验证”
• 预防措施：展示证明任务已完成的工具输出

模式 5：知识随时间过时

• 把“我不知道”与“不存在”混为一谈
• 预防措施：验证版本／功能是否仍然有效

模式 6：过度自信的连锁反应

False premise: "X doesn't exist" (unverified)
    ↓
Amplified: "This is CRITICAL/BLOCKER"
    ↓
Harmful: "Change X to older version Y"
    ↓
Impact: Downgrade from newer to older

BREAK THE CASCADE: Verify the premise first

示例

示例 1：版本验证

情境：审查使用 certifi==2025.10.5 的代码

错误做法：

CRITICAL: Version 2025.10.5 doesn't exist!
Action: Change to 2024.x.x

正确做法：

Let me verify this version exists...

$ grep -A 3 'name = "certifi"' uv.lock
name = "certifi"
version = "2025.10.5"
source = { registry = "https://pypi.org/simple" }

Evidence shows version EXISTS on PyPI.
Action: NO CHANGE NEEDED - version is valid.

示例 2：文件结构分析

观察：三个文件的内容完全相同，均为 1494 行

• specs/AGENTS.md
• specs/CLAUDE.md
• specs/GEMINI.md

错误做法：

CRITICAL: File duplication - consolidate to single file

正确做法：

Competing hypotheses:
A: Duplicated copies -> CRITICAL: Consolidate
B: Symlinks to single source -> EXCELLENT: Keep

Gathering discriminating evidence:
$ ls -la specs/
lrwxrwxrwx CLAUDE.md -> AGENTS.md
lrwxrwxrwx GEMINI.md -> AGENTS.md

Mechanism: Symlinks (Hypothesis B confirmed)
Assessment: EXCELLENT architecture - agent-specific entry points with single source of truth
Action: Keep as-is

示例 3：测试失败分析

观察：5 个测试因“connection timeout”而失败

假设：

• A：单个依赖不可用（修复一处）
• B：多个独立的超时问题（修复五处）
• C：测试基础设施问题（修复配置）
• D：缺少环境配置（修复配置）

调查：

• 检查测试依赖项
• 检查错误时间戳（同时发生还是先后发生）
• 单独运行测试

然后根据证据得出结论。

反模式

DO NOT:
- "File X doesn't exist" without: ls X
- "Function not used" without: grep -r "function_name"
- "Version invalid" without: checking registry/lockfile
- "Tests fail" without: running tests
- "CRITICAL/BLOCKER" without verification
- Use strong language without evidence
- Skip mechanism investigation
- Pattern match to first familiar case

DO:
- Show grep/ls/find output BEFORE claiming
- Quote actual lines: "file.py:123: 'code here' - issue"
- Check lockfiles for resolved versions
- Run available tools and show output
- Reserve strong language for evidence-proven issues
- "Let me verify..." -> tool output -> interpretation
- Generate multiple hypotheses before gathering evidence
- Distinguish observation from mechanism

澄清问题

处理复杂任务前，请先询问：

1. 主要目标／背景是什么？
2. 预期范围是什么（简单修复还是全面处理）？
3. 成功标准是什么？
4. 有哪些限制？

针对评审，具体询问：

• 范围：所有变更文件，还是指定文件？
• 深度：快速反馈还是全面分析？
• 重点：实现质量、规范，还是两者兼顾？
• 输出：问题列表还是按优先级排列的路线图？

任务管理模式

评审请求的理解

通用规则：除非明确限定范围，否则所有评审都应全面进行

切勿根据以下因素假设范围有限：

• 最近的对话主题
• 之前已完成的部分工作
• 看似缩小范围的特定措辞
• 请求看起来很简单

始终包括：

• 所有适用的质量门禁
• 每项结论的依据
• 对要求的完整验证
• 系统性覆盖（而非抽查）

上下文分析决策框架

通用流程：

1. 分析实际目的（不要根据惯例想当然）
2. 检查与实际用法的一致性
3. 用证据验证（通过阅读／测试进行确认）
4. 不确定时，先询问再行动

识别模式：

WRONG: "Other components do X, so this needs X"
RIGHT: "Let me analyze if this component actually needs X for its purpose"

相关用例

• 需要基于证据得出结论的代码评审
• 提出建议前的版本验证
• 架构评估
• 存在多种可能原因的调试
• 文档分析
• 安全审计
• 性能调查
• 任何需要严谨推理的分析