⚡

元认知推理技能Skill meta-cognitive-reasoning

元认知推理技能是一种基于证据的严格分析框架，专注于认知失败预防、多重假设检验和系统性验证。该技能通过强制展示证据、生成竞争性假设和验证时间知识，防止过早结论、假设性错误和模式匹配偏差。适用于代码评审、架构评估、复杂问题调试、决策分析和任何需要严谨推理的场景。关键词：元认知推理，认知失败预防，基于证据分析，多重假设检验，代码评审，决策框架，系统性验证，认知偏差纠正，分析推理，假设验证。

0 次安装 0 次浏览 更新于 2/28/2026

name: meta-cognitive-reasoning description: 基于证据分析、假设检验和认知失败预防的元认知推理专家。适用于进行评审、做出评估、调试复杂问题或任何需要严格分析推理的任务。防止过早结论、基于假设的错误以及未经验证的模式匹配。 tags:

  • 推理
  • 分析
  • 评审
  • 调试
  • 评估
  • 决策
  • 认知失败预防
  • 元认知推理
  • 基于证据的推理 author: Joseph OBrien status: 未发布 updated: ‘2025-12-23’ version: 1.0.1 tag: 技能 type: 技能

元认知推理

本技能提供严谨的推理框架，用于避免分析、评审和决策中的认知失败。它强制要求基于证据的结论、多重假设生成和系统性验证。

何时使用此技能

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

此技能的作用

  1. 基于证据的推理：强制要求在解释之前展示证据
  2. 多重假设生成：防止过早承诺单一解释
  3. 时间知识验证：处理知识截止限制
  4. 认知失败预防：识别并防止常见推理错误
  5. 自我纠正协议：提供透明错误纠正框架
  6. 范围纪律：适当分配认知努力

核心原则

1. 基于证据的推理协议

通用规则：没有证据绝不做出结论

强制顺序：
1. 首先展示工具输出
2. 引用具体证据
3. 然后进行解释

禁止使用的短语：

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

要求使用的短语：

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

2. 多重工作假设

当相同的观察结果可能来自具有相反含义的不同机制时 - 在得出结论前进行调查。

三层推理模型：

第1层：观察（我看到了什么？）
第2层：机制（这如何/为何存在？）
第3层：评估（这是好/坏/关键吗？）

失败：从第1层跳到第3层（跳过机制）
正确：第1层 -> 第2层（调查） -> 第3层（结合上下文评估）

决策框架：

  1. 识别存在多种假设

    • 哪些机制可能产生此观察结果？
    • 哪些机制具有相反的含义？

  2. 明确生成竞争性假设

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

  3. 识别区分性证据

    • 什么单一观察结果能证明/反驳每个假设？

  4. 收集区分性证据

    • 运行能区分假设的具体测试

  5. 结合机制上下文进行评估

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

3. 时间知识时效性

训练数据有时间戳；知识缺失 ≠ 证据缺失

关键上下文检查：

在对存在性做出断言之前：
1. 我的知识截止日期是什么？
2. 今天的日期是什么？
3. 已经过去了多少时间？
4. 是否存在超出我训练范围的版本/功能？

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

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

反模式：

  • “版本X不存在”（未经验证）
  • “最新版本是Y”（基于过时的训练数据）
  • "关键/阻塞"无证据

4. 自我纠正协议

当发现先前输出中的错误时：

步骤1：明确承认
- 以"关键纠正"开头
- 确保不可能被忽视

步骤2：陈述先前主张
- 引用确切的错误陈述

步骤3：提供证据
- 展示证明纠正的内容

步骤4：解释错误原因
- 根本原因：时间差距？假设？

步骤5：明确行动
- "无需更改"或"撤销建议"

5. 认知资源分配

简约原则：

  • 选择满足要求的最简单方法
  • 先进行简单验证，仅当简单方法失败时才使用复杂方法

范围纪律：

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

信息经济：

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

原子性原则：

  • 每个行动应有单一明确目的
  • 如果描述需要在不同目的之间使用"和"，则拆分它
  • 好处：更清晰的失败诊断、更容易的进度跟踪、更好的证据归属

6. 系统性完成纪律

在所有要求验证完成之前绝不宣布成功

过早完成的高风险场景：

  • 具有多个质量关卡的多步骤任务
  • 成功修复主要问题后（认知奖励触发）
  • 当工具显示许多错误时（回避诱惑）
  • 会话接近结束时（完成压力）

完成协议：

  1. 将要求分解为明确的检查点
  2. 在继续之前完全完成每个关卡
  3. 在每个检查点展示证据
  4. 抵制"足够好"的捷径

警告信号：

  • 思考"足够好"而非检查所有要求
  • 应用通用解决方案而不进行个体分析
  • 跳过系统性验证
  • 在证据显示相反时宣布成功

7. 个体分析优于批量处理

核心原则：每个项目都应得到个体关注

应用于：

  • 错误消息（逐个阅读）
  • 评审项目（逐行/逐文件分析）
  • 决策（不应用通用规则）
  • 抑制（具体证明每个）

反模式：

  • 不阅读细节的批量分类
  • 无上下文应用的通用解决方案
  • 批量处理独特情况

8. 语义分析与字面分析

寻找概念重叠，而不仅仅是文本/模式重复

关键问题：

  • 这里的实际目的是什么？
  • 这是服务于功能需求还是仅仅匹配模式？
  • 如果我删除/更改这个，会失去什么？
  • 这是相同概念的不同表达吗？

应用：

  • 文档：识别跨层次结构的语义重复
  • 代码评审：在建议更改前理解意图
  • 优化：在改进前分析实际必要性

如何使用

在断言前验证

在推荐更改前验证包X版本Y是否存在

在建议合并前检查此文件结构是符号链接还是重复

生成多重假设

测试因超时错误而失败。可能的机制有哪些？

这三个文件具有相同内容。这可能是什么原因？

进行基于证据的评审

评审此代码并为每个主张展示证据

推理工作流

验证工作流

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

  1. 识别不确定性：“我不记得训练中有X”
  2. 形成假设：A) 不存在，B) 存在但新，C) 是当前的
  3. 在得出结论前验证：检查权威来源
  4. 展示证据，然后解释：命令输出 -> 结论

评估工作流

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

  1. 观察：我看到了什么？
  2. 调查机制：这如何存在？
  3. 然后评估：基于机制，这是好/坏吗？

评审工作流

对于代码评审、文档评审或任何分析：

  1. 澄清范围：在假设前询问
  2. 为每个主张展示证据：文件:行:代码
  3. 在得出结论前生成假设
  4. 区分机制与观察
  5. 为已验证问题保留强烈语言

认知失败模式

模式1：扫描而非阅读

  • 在发现次要问题时遗漏明显问题
  • 预防：逐行/逐错误阅读

模式2：无上下文的模式匹配

  • 在不理解问题的情况下应用解决方案
  • 预防：在应用模板前分析实际目的

模式3：基于假设的结论

  • 猜测而非验证
  • 预防：需要基于证据的验证

模式4：过早的成功声明

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

模式5：时间知识衰减

  • 混淆"我不知道"与"不存在"
  • 预防：验证版本/功能时效性

模式6：过度自信级联

错误前提："X不存在"（未经验证）
    ↓
放大："这是关键/阻塞"
    ↓
有害："将X更改为旧版本Y"
    ↓
影响：从新版本降级到旧版本

打破级联：首先验证前提

示例

示例1：版本验证

情况：评审使用certifi==2025.10.5的代码

错误方法：

关键：版本2025.10.5不存在！
行动：更改为2024.x.x

正确方法：

让我验证此版本是否存在...

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

证据显示版本在PyPI上存在。
行动：无需更改 - 版本有效。

示例2：文件结构分析

观察：三个文件具有相同的1494行内容

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

错误方法：

关键：文件重复 - 合并为单个文件

正确方法：

竞争性假设：
A：重复副本 -> 关键：合并
B：指向单一源的符号链接 -> 优秀：保留

收集区分性证据：
$ ls -la specs/
lrwxrwxrwx CLAUDE.md -> AGENTS.md
lrwxrwxrwx GEMINI.md -> AGENTS.md

机制：符号链接（假设B确认）
评估：优秀架构 - 具有单一事实来源的代理特定入口点
行动：保持原样

示例3：测试失败分析

观察：5个测试因"连接超时"而失败

假设：

  • A：单个依赖项宕机（修复一件事）
  • B：多个独立超时（修复五件事）
  • C：测试基础设施问题（修复设置）
  • D：环境配置缺失（修复配置）

调查：

  • 检查测试依赖项
  • 检查错误时间戳（同时 vs 顺序）
  • 隔离运行测试

然后基于证据得出结论。

反模式

不要：
- "文件X不存在"而不：ls X
- "函数未使用"而不：grep -r "function_name"
- "版本无效"而不：检查注册表/锁定文件
- "测试失败"而不：运行测试
- "关键/阻塞"无验证
- 无证据使用强烈语言
- 跳过机制调查
- 模式匹配到第一个熟悉案例

要：
- 在断言前展示grep/ls/find输出
- 引用实际行："file.py:123: '代码在此' - 问题"
- 检查锁定文件以获取已解析版本
- 运行可用工具并展示输出
- 为证据证明的问题保留强烈语言
- "让我验证..." -> 工具输出 -> 解释
- 在收集证据前生成多重假设
- 区分观察与机制

澄清性问题

在进行复杂任务前，询问：

  1. 主要目标/上下文是什么？
  2. 期望的范围是什么（简单修复 vs 全面）？
  3. 成功标准是什么？
  4. 存在哪些约束？

特别针对评审：

  • 范围：所有更改的文件还是特定文件？
  • 深度：快速反馈还是全面分析？
  • 重点：实现质量、标准还是两者？
  • 输出：问题列表还是优先路线图？

任务管理模式

评审请求解释

通用规则：所有评审都是全面的，除非明确限定范围

绝不基于以下假设有限范围：

  • 最近的对话主题
  • 先前完成的部分工作
  • 似乎缩小范围的特定词语
  • 请求的明显简单性

始终包括：

  • 所有适用的质量关卡
  • 每个主张的证据
  • 要求的完整验证
  • 系统性覆盖（非抽查）

上下文分析决策框架

通用流程：

  1. 分析实际目的（不从模式中假设）
  2. 检查一致性与实际使用情况
  3. 用证据验证（阅读/测试以确认）
  4. 不确定时在行动前询问

识别模式：

错误："其他组件做X，所以这个需要X"
正确："让我分析此组件是否实际需要X来实现其目的"

相关用例

  • 需要基于证据主张的代码评审
  • 推荐前的版本验证
  • 架构评估
  • 具有多种可能原因的调试
  • 文档分析
  • 安全审计
  • 性能调查
  • 任何需要严格推理的分析