科学公式验证编排 Skill

本 Skill 定义一套分阶段（Stage）的科学公式验证流水线。你的职责是按照流水线依次执行验证，并在每个 Stage 产出结构化结果。本 Skill 是编排层——定义流程、数据协议和决策路口；具体的验证技术细节（数值分析、量纲检查等）由未来的能力 Skill 提供规则。

1. 为什么需要

AI 生成的公式可能包含符号错误、量纲不一致、推导跳步、来源不可追溯等问题。如果直接采信，会导致工程设计错误、论文结论失效或代码实现 bug。本 Skill 的目标是提供一套可验证、可追溯、可扩展的检查流程，让你在回答用户之前完成公式可信度评估。

核心原则：

• 优先验证，而非优先生成：在给出公式结论前，先完成验证
• 优先引用权威来源，而非依赖模型记忆：每个结论需要标注出处或推理依据
• 所有结论可追溯：报告中每条判断必须附上来源或推导链
• 明确列出假设与限制：未验证的部分必须显式标注，不暗示置信度

2. 架构总览

2.1 Stage 流水线

Stage -1 → Stage 0 → Stage 1 → Stage 2 → Stage 3 → Stage 4 → Stage 5 → Stage 6 → Stage 7 → Stage 8
  │          │          │          │          │          │          │          │          │          │
 触发判定   验证规划   问题定义   来源+符号   数学一致性 推导验证   工程合理性  交叉验证   实现映射   综合报告

每个 Stage 产出一个 Markdown 格式的结构化验证摘要，作为下一 Stage 的输入之一。各 Stage 的输出在内存中以键值结构组织（字段 → 结论），Stage 之间通过 verification_context 共享状态。

2.2 决策路由

在执行 Stage 0 后，你需要根据验证目标决定后续路径：

2.3 与其他 Skill 的协作

本 Skill 是编排层，不内置具体验证技术。以下 Skill 应在对应 Stage 执行前加载：

3. Stage -1：触发与作用域判定

在收到任何公式验证请求时，首先执行此 Stage，确定是否需要验证以及验证深度。

设计意图

并非所有公式都需要完整验证。本 Stage 通过快速评估，决定是否进入流水线以及使用哪种验证深度，避免资源浪费。

核心职责

• 判断请求是否包含需要验证的公式（纯描述性文字不需要）
• 评估公式复杂度（简单代数 / 多变量方程 / 含积分/矩阵/偏导）
• 根据用户上下文决定验证深度（用户说"帮我看看"vs"严格审查"）

建议执行内容

1. 提取用户消息中的公式原文
2. 统计公式包含的变量数量、操作符类型（∑、∫、∂、矩阵等）
3. 检查用户是否明确表达了验证意图（"验证""检查""对不对""审查"等）
4. 根据公式复杂度和用户意图，在以下选项中选择验证深度：
   • 快速检查：简单代数式、用户只想知道"对不对"
   • 标准验证：中等复杂度、工程场景
   • 全面验证：高复杂度、论文/安全相关、用户明确要求严格审查
5. 如果请求不包含可验证的公式，直接告知用户并终止流水线

输入

• 用户原始消息（文本或含公式的消息）

输出

以 Markdown 格式输出本 Stage 的判定结论，包含以下字段：

• 是否验证：是 / 否
• 验证深度：快速检查 / 标准验证 / 全面验证
• 公式数量与复杂度：简要说明（如"2 个公式，含矩阵运算和中等级数展开"）
• 跳过原因（如不验证）：说明为何不进入流水线

依赖关系

无依赖，本 Stage 始终最先执行。

可复用性

可独立复用——任何对话中需要判断公式验证必要性时均可调用。

工具建议

无需外部工具，纯分析型 Stage。

可扩展点

• complexity 字段可增加更细粒度的分类（如"偏微分方程""含边界条件"）
• 可结合对话历史判断用户是否在持续追问同一公式

4. Stage 0：验证规划

在确定需要验证后，制定详细的验证计划，包括工具选择、执行策略和 Stage 裁剪。

设计意图

不同公式需要不同的验证手段。本 Stage 在正式执行前规划整个验证流程，避免盲目执行所有 Stage。

核心职责

• 分析公式所属领域（数学、控制、信号处理、ML 等）
• 决定哪些 Stage 需要执行、哪些可以跳过
• 规划每个 Stage 需要的工具（Web 搜索、符号计算、数值验证等）
• 输出可执行的验证计划

建议执行内容

1. 分析公式的领域特征：
   • 含 s、z 变量 → 可能是控制/信号处理（检查传递函数模式）
   • 含 θ、φ 和三角函数 → 可能是坐标变换
   • 含 E[]、P() → 可能是概率/统计
   • 含 ∇、∂ → 可能是场论/优化
2. 制定 Stage 执行计划，标记每个 Stage 的：
   • required：必须执行
   • optional：根据中间结果决定
   • skip：明确不执行
3. 列出每个 Stage 需要的工具，参考以下映射表：

输入

• Stage -1 的输出（公式复杂度、验证深度）
• 公式原文
• 用户上下文（领域快照）

输出

以 Markdown 格式输出验证计划，包含以下字段：

• 领域分类：判断公式所属领域（如 控制理论、信号处理、优化算法）
• Stage 执行计划：列出每个 Stage 的执行状态（必须执行 / 可选 / 跳过）
• 工具规划：标注各 Stage 计划使用的工具（如 Stage 2: 网络搜索 + Context7）
• 预估迭代次数：如 Stage 4 推导可能需要多次尝试，预估并说明
• 备注：需要特别注意的风险或不确定点

依赖关系

依赖 Stage -1 的输出。

可复用性

可独立复用——任何需要制定验证策略的场景均可使用。

工具建议

• context7_resolve-library-id / context7_query-docs：查询领域相关文档
• websearch_web_search_exa：搜索标准/论文出处

可扩展点

• tool_plan 可扩展为插件式工具注册表，新增工具无需修改核心逻辑
• 可增加"历史验证案例库"查询，复用已知结果

5. Stage 1：问题定义确认

验证公式之前，先确认公式对应的问题定义是否正确。问题定义错误会导致后续所有验证失去意义。

设计意图

公式是特定问题的数学表达。如果问题本身的定义（研究对象、假设条件、坐标系、边界等）有误，公式再"正确"也没有意义。本 Stage 是后续所有验证的前置关卡。

核心职责

• 提取并确认研究对象（是什么系统/过程/变换）
• 确认坐标系、参考系、约定方向
• 列出假设条件与适用范围
• 识别问题定义中可能存在的歧义或错误

建议执行内容

1. 从公式中提取研究对象——它描述了什么的数学关系？
   • 例如：F = ma → 研究对象是质点的受力与加速度关系
2. 列出公式隐含的假设条件：
   • 例如：质点假设（忽略体积）、惯性参考系、低速（非相对论）
3. 检查坐标系约定：
   • 例如：电机控制中 d-q 轴的定义、右手定则还是左手定则
4. 如果用户没有明确提供上下文，你需要主动提问确认
5. 如果发现问题定义与公式不匹配，立即标记 problem_mismatch: true 并向用户提出

输入

• Stage 0 的验证计划
• 公式原文
• 用户提供的上下文

输出

以 Markdown 格式输出问题定义确认结果，包含以下字段：

• 研究对象：公式描述了什么系统/过程/变换（一句话概括）
• 假设条件：列出公式成立的前提假设（列表形式）
• 坐标系/参考系：涉及的坐标约定、方向定义
• 适用范围：公式成立的领域和边界条件
• 问题匹配：公式是否与用户描述的问题匹配，不匹配时说明原因
• 歧义点：当前上下文无法确定、需要用户澄清的点

依赖关系

依赖 Stage 0 的领域分析结果。

可复用性

可独立复用——任何数学建模场景都应先确认问题定义，即使不进行公式验证。

工具建议

• 网络搜索：查询该领域标准教科书的问题定义方式
• 用户交互：通过 question 工具确认歧义点

可扩展点

• 可构建"常见问题定义模式库"——控制理论、信号处理、优化等领域有各自的标准建模框架
• 可增加"跨领域类比检测"——检查公式是否被错误套用到不兼容的领域

6. Stage 2：来源与符号统一

合并原 Stage 2（文献来源验证）和 Stage 3（符号统一）。在查找文献出处的同时建立统一符号表。

设计意图

符号统一通常与文献检索同时完成——查文献时会自然对比不同来源的符号体系。将两者合并减少了一次上下文传递和符号转换开销。

核心职责

• 查找公式的权威来源（教材、论文、标准、官方文档）
• 对比不同来源的符号定义
• 建立本验证会话的统一符号表
• 标注来源的可信度等级

建议执行内容

来源验证部分：

1. 识别公式的潜在出处类型：
   • 基础物理/数学公式 → 标准教材
   • 控制算法 → IEEE 论文、行业标准
   • 信号处理 → 经典教材（如 Oppenheim）、标准文档
   • ML 算法 → 原始论文（如 "Attention Is All You Need"）
2. 使用网络搜索查找权威来源，记录每个来源的：
   • 出处（书名/论文标题/标准编号 + 页码/章节）
   • 可信度等级：high（教科书/标准）、medium（同行评审论文）、low（博客/论坛）
   • 公式在该来源中的原始形式

符号统一部分：

3. 提取公式中每个变量的定义：
   • x → 状态向量（维度 $n \times 1$）
   • A → 系统矩阵（维度 $n \times n$）
   • u → 控制输入（维度 $m \times 1$）
4. 当不同来源使用不同符号表示同一物理量时，建立映射表
5. 标注单位（SI 单位），检查量纲

输入

• Stage 1 的问题定义（研究对象、坐标系等）
• 公式原文

输出

以 Markdown 格式输出来源验证与符号统一结果，包含以下字段：

• 文献来源列表：每项含出处（教材/论文/标准 + 页码）、可信度（高/中/低）、原文公式形式、是否匹配
• 统一符号表：每个变量的定义、数学维度、物理单位（SI）
• 符号冲突：不同来源间不一致的符号定义及差异说明
• 未验证符号：未能确认含义的变量，标记为待确认
• 首选来源：综合可信度最高的单一出处推荐

依赖关系

• 依赖 Stage 1 的问题定义来搜索正确的文献
• 输出符号表供 Stage 3、4、5、7 使用

可复用性

• 来源验证可独立复用——任何需要查找公式出处的场景
• 符号统一依赖于具体公式，不可独立复用

工具建议

• websearch_web_search_exa：搜索文献出处
• context7_query-docs：查询特定库/框架中的公式定义
• grep_app_searchGitHub：搜索开源实现中的公式引用
• 加载 web-reference-tracing Skill：确保溯源准确性

可扩展点

• trust_level 可扩展为更细粒度的评分体系（如加权可信度）
• 可增加 BibTeX 格式的引用输出
• 符号表可输出为机器可读格式（JSON Schema），供其他工具消费

7. Stage 3：数学一致性检查

验证公式本身是否满足基本的数学规则，不依赖外部来源。

设计意图

即使公式有权威来源，仍可能存在笔误、排版错误或版本差异。本 Stage 通过纯数学检查发现这类问题。

核心职责

• 检查量纲一致性（物理公式）
• 检查矩阵维度兼容性
• 检查代数恒等式（如展开后是否等价）
• 检查符号方向的物理一致性
• 检查坐标系变换的自洽性

建议执行内容

1. 量纲检查（仅物理公式）：
   • 将每个变量替换为其 SI 量纲
   • 检查等式两边量纲是否一致
   • 检查加减项的量纲是否一致
   • 例如：$v = at$ → $[LT^{-1}] = [LT^{-2}][T]$ ✓
2. 维度检查（矩阵/向量公式）：
   • 标注每个矩阵/向量的维度
   • 检查乘法是否兼容：$(m \times n) \times (n \times p) \rightarrow (m \times p)$
   • 检查加减是否兼容：维度必须完全一致
   • 检查是否有意外的维度扩张或缩并
3. 代数验证（可选，取决于公式复杂度）：
   • 对公式两侧进行代数变换，检查是否自洽
   • 例如：$(a+b)^2 = a^2 + 2ab + b^2$ → 展开验证
   • 对于含级数、积分的公式，验证特殊项的取值
4. 坐标变换一致性：
   • 如果公式涉及坐标系变换（如旋转矩阵），检查变换矩阵是否正交（$R^T R = I$）
   • 检查变换前后物理量不变性
5. 使用数值代入作为快速检查（选 2-3 组数值代入公式两侧，比较结果）

输入

• Stage 2 的符号表（维度、单位信息）
• 公式原文

输出

以 Markdown 格式输出数学一致性检查结论，包含以下字段：

• 量纲检查：等式两边量纲是否一致，不一致处列出
• 矩阵维度检查：所有乘法/加减的维度兼容性，不兼容处列出
• 代数验证（如执行）：验证方式（展开/化简/代入）、是否通过、细节说明
• 数值抽样（如执行）：测试值、两侧结果对比、容差
• 坐标一致性（如涉及）：变换矩阵是否正交、不变量是否保持
• 发现的问题：任何违反数学规则的项

依赖关系

• 依赖 Stage 2 的符号表（需要维度和单位信息）
• 不依赖 Stage 4（推导验证）——数学一致性检查可以独立完成

可复用性

可独立复用——任何场景下检查公式的数学自洽性均可使用。

工具建议

• 符号计算工具（SymPy / Mathematica 概念）：用于代数展开和等价性验证
• 手动量纲分析：将 SI 基本量纲代入
• 数值代入法：手动选取测试值

可扩展点

• 数值代入可自动化为蒙特卡洛随机采样
• 量纲检查可集成第三方量纲分析工具
• 可扩展为检查更多数学性质（如凸性、单调性、对称性）

8. Stage 4：推导验证

验证公式是否可以从基础理论完整推导得到。关注推导过程中的每一步依据、跳步和隐含假设。

设计意图

"公式正确"和"公式推导正确"是两回事。一个公式可能最终形式正确，但推导过程中存在逻辑跳跃或不当近似。本 Stage 逐步骤重建推导链，发现隐藏的问题。

核心职责

• 从基础理论出发重建推导链
• 检查每一步的依据是否充分
• 识别跳步（缺失的中间步骤）
• 列出推导过程中的隐含假设
• 标记推导链中的薄弱环节

建议执行内容

1. 确定推导起点：公式从哪些基本定律/公理出发？
   • 例如：$F=ma$ 从牛顿第二定律出发
   • 例如：卡尔曼滤波从贝叶斯估计出发
2. 列出推导步骤，对每一步标注：
   • 依据（引用了什么定理/假设/前一结果）
   • 是否可验证（verifiable / assumed / unverifiable）
3. 跳步检测：
   • 相邻步骤之间如果缺少中间推导 → 标记为 gap
   • 尝试填补跳步——使用符号计算或手动推理
4. 隐含假设识别：
   • 例如：推导中使用了"线性化"但未说明线性化条件
   • 例如：忽略了高阶项而只保留了一阶近似
5. 边界条件验证：
   • 推导过程中是否引入了仅在特定条件下成立的近似
   • 这些条件是否与公式适用范围一致
6. 输出推导链，并用 confidence 标注每步的可信度

输入

• Stage 2 的符号表和来源信息
• Stage 3 的数学一致性结果
• 公式原文

输出

以 Markdown 格式输出推导验证结论，包含以下字段：

• 推导起点：从哪些基本定律/公理出发
• 推导步骤：每步标注表达式、依据来源、可验证性（可验证 / 基于假设 / 不可验证）
• 跳步列表：相邻步骤间缺失的中间推理（含严重程度：轻微 / 中等 / 严重）
• 隐含假设：推导过程中未明说的前提条件及其影响
• 边界条件：推导成立的限制条件，违反时的后果
• 综合可信度：推导链的整体可靠性评估（高 / 中 / 低）

依赖关系

• 依赖 Stage 2 的符号表和来源（需要知道基本定律是什么）
• 依赖 Stage 3 的结果（已有数学一致性保证，减少重复检查）

可复用性

不可独立复用——推导需要知道基本理论起点（来自 Stage 2）。

工具建议

• 符号计算工具：逐步推导验证
• 网络搜索：查找标准推导过程（如教科书附录中的证明）

可扩展点

• 可构建"标准推导模板库"——常见公式的标准推导路径（如 PID → 传递函数、欧拉-拉格朗日 → 运动方程）
• 可增加"推导复杂度评估"——预测该推导需要多少步，用于决策是否需要用户确认

9. Stage 5：工程合理性检查

验证公式是否符合物理规律、工程经验和控制理论的基本约束。关注实际可实现性。

设计意图

数学上正确的公式不一定工程上可行。本 Stage 从工程视角检查公式是否违反物理定律、是否在极限情况下退化合理、数量级是否在合理范围。

核心职责

• 极限情况检查（$t \to 0$、$t \to \infty$、参数趋于极值）
• 退化情况检查（特定参数下公式是否退化为已知简单形式）
• 数量级检查（结果是否在物理合理范围内）
• 物理定律兼容性（如能量守恒、热力学第二定律）
• 可实现性检查（是否存在实际系统能产生公式描述的行为）

建议执行内容

1. 极限情况分析：
   • 取 $t \to \infty$：系统是否收敛到稳态？稳态值是否合理？
   • 取 $t \to 0$：初始条件是否满足？
   • 取参数趋于 0 或 $\infty$：是否有奇点或退化？
2. 退化检查：
   • 如果取下某个参数为 0，公式是否退化为更简单的已知公式？
   • 退化后的公式是否正确？
3. 数量级合理性：
   • 将典型工程数值代入，检查结果数量级
   • 例如：电机电流公式的结果不应是 $10^6$ A 量级
4. 物理约束检查：
   • 效率应 $\leq 1$（或 100%）
   • 概率应 $\in [0, 1]$
   • 质量/能量应为正值
5. 稳定性检查（控制系统公式）：
   • 系统矩阵的特征值是否在左半平面？
   • 传递函数的极点是否稳定？

输入

• Stage 2 的符号表
• Stage 3 的数学一致性结果
• 公式原文

输出

以 Markdown 格式输出工程合理性检查结论，包含以下字段：

• 极限分析：各极限条件（$t \to 0/\infty$、参数趋于极值）下的行为，是否合理
• 退化检查：特定参数取值下公式是否退化为已知简单形式，退化结果是否正确
• 数量级检查：典型工程数值代入后的结果量级，是否在物理合理范围内
• 物理约束：是否违反基本物理定律（效率 ≤1、概率 ∈[0,1]、质量/能量 ≥0 等）
• 稳定性检查（如涉及动态系统）：特征值/极点是否稳定
• 发现的问题：任何违反工程常识的项

依赖关系

• 依赖 Stage 2 的符号表（需要物理量纲和典型值）
• 依赖 Stage 3 的数学一致性（确保代数操作正确）
• 不依赖 Stage 4（推导链）

可复用性

可独立复用——任何工程公式的合理性检查均可使用此框架。

工具建议

• 数值计算：代入典型值
• 极限分析：手动/符号计算极限
• 稳定性分析：手动/符号计算特征值

可扩展点

• 可构建"领域特定检查清单"——如电机控制专用（Park/Clarke 变换约束）、信号处理专用（Nyquist 条件）
• 可增加"实测数据对比"——如果有实验数据，可直接验证公式预测

10. Stage 6：多文献交叉验证

对比多个独立来源的公式形式，分析差异原因，确认最可信版本。

设计意图

同一公式在不同教材/论文/标准中可能略有不同（符号约定、归一化方式、坐标系选择）。本 Stage 通过交叉对比，识别差异并分析原因，避免盲信单一来源。

核心职责

• 查找至少 2-3 个独立来源
• 逐一对比公式形式、符号约定、适用范围
• 分析差异来源（归一化、符号约定、单位系、近似级别等）
• 判断哪个版本更可信，或标注各版本的适用条件

建议执行内容

1. 收集至少 2-3 个独立来源的公式版本（如果 Stage 2 已收集，复用其来源列表）
2. 对每个来源建立对比矩阵：

3. 逐一分析差异：
   • 符号差异：如果不同来源用不同符号但数学结构一致 → 标记为"符号约定差异"，不影响正确性
   • 结构差异：如果公式数学结构不同 → 深入分析原因（近似方式不同？简化假设不同？）
   • 适用范围差异：标注各版本成立的假设条件
4. 给出综合判断——如果所有来源一致 → 增强可信度；如果分歧严重 → 降低可信度

输入

• Stage 2 的来源列表（复用并扩展）
• 符号表

输出

以 Markdown 格式输出多文献交叉验证结论，包含以下字段：

• 对比来源数：参与对比的独立来源数量
• 对比矩阵：用表格列出各来源的公式形式、符号约定、归一化方式、适用范围
• 一致性判断：全部一致 / 符号差异 / 结构差异
• 差异分析：逐一解释不一致的来源——是符号约定不同、近似方式不同还是假设条件不同
• 推荐版本：在分歧时推荐最可信的版本，附理由

依赖关系

• 强依赖 Stage 2 的来源列表
• 依赖 Stage 3 的数学一致性（已确认公式自洽，交叉验证才有意义）

可复用性

不可独立复用——需要已有来源列表（来自 Stage 2）。

工具建议

• websearch_web_search_exa：搜索额外来源
• webfetch：获取论文/教材中的公式原文
• 加载 web-reference-tracing Skill：确保多源对比时可追溯

可扩展点

• 可增加"共识度评分"——量化不同来源的一致程度
• 可扩展为自动采集 N 个来源并进行统计对比

11. Stage 7：工程实现映射

分析公式如何映射到程序实现，识别数值风险并提供实现建议。

设计意图

公式的正确性不等同于实现的正确性。本 Stage 关注公式的"工程落地"——变量映射、数值稳定性、浮点误差、边界处理。

核心职责

• 建立公式变量 ↔ 代码变量的映射
• 评估数值稳定性（如减法消去、大数除以小数）
• 评估浮点误差累积风险
• 识别边界条件处理需求（除零保护、定义域限制）
• 提供实现建议（算法选择、优化方向）

建议执行内容

1. 变量映射：
   • 列出每个数学变量对应的代码变量名和类型（float64 / int / complex128）
   • 标注矩阵存储格式（稠密/稀疏/对角）
2. 数值稳定性分析：
   • 检查是否存在相近数相减 → 可能导致有效数字丢失
   • 检查是否存在大数除以小数 → 可能溢出
   • 检查是否存在指数/对数/三角函数的极值输入
3. 浮点误差评估：
   • 评估误差传播路径（哪些操作的误差会被放大）
   • 建议使用 float64 还是需要更高精度
4. 边界处理：
   • 识别需要特殊处理的条件（除零、负数开方、矩阵奇异）
   • 提供边界值的安全处理方式
5. 实现建议：
   • 是否有已知的高效算法？
   • 是否适合向量化/SIMD？
   • 是否需要查表法替代实时计算？

输入

• Stage 2 的符号表（变量类型、维度、单位）
• Stage 5 的边界条件分析
• 公式原文

输出

以 Markdown 格式输出工程实现映射建议，包含以下字段：

• 变量映射表：数学变量 → 代码变量名、类型（float64/int/complex128）、数组形状
• 数值风险：是否存在相近数相减、大数除以小数、矩阵奇异等风险，每项附缓解方案
• 精度要求：建议的浮点精度（float32/float64/更高）及误差累积风险评估
• 边界处理：需要特殊处理的边界条件（除零、负数开方、矩阵奇异），每项附处理方式
• 实现建议：推荐算法、适合的加速方式（向量化/SIMD）、可参考的开源实现

依赖关系

• 依赖 Stage 2 的符号表
• 依赖 Stage 5 的边界条件分析

可复用性

可独立复用——任何需要将公式转化为代码的场景均可使用。

工具建议

• grep_app_searchGitHub：搜索开源实现参考
• context7_query-docs：查询数值计算库（NumPy/SciPy/LAPACK）的最佳实践

可扩展点

• 可集成自动代码生成（从公式直接输出伪代码/真实代码）
• 可增加"性能分析"——预估计算复杂度和内存占用

12. Stage 8：综合可信度报告

汇总所有 Stage 的验证结果，生成结构化的可信度评估报告。

设计意图

独立的分 Stage 结果对用户而言碎片化。本 Stage 将所有发现综合为一份可操作的报告，回答核心问题："这个公式值得采用吗？"

核心职责

• 汇总各 Stage 的关键发现
• 给出多维度的可信度评分
• 明确指出已确认、未确认、存疑的内容
• 提供决策建议（采用 / 需修正 / 不推荐）

建议执行内容

1. 汇总各 Stage 结果，提取关键发现
2. 按维度评分（0-100）：

3. 加权计算综合可信度分数
4. 分类列出：
   • 已验证：各 Stage 确认正确的部分
   • 存疑：有矛盾或不确定的部分
   • 未验证：由于信息不足或工具限制未检查的部分
5. 生成决策建议：
   • 推荐采用（综合 > 80，无关键问题）
   • 有条件采用（综合 60-80，有轻微问题可修正）
   • 需进一步验证（综合 40-60，存在不确定项）
   • 不推荐（综合 < 40 或存在严重问题）

输入

• 所有前序 Stage 的输出（Stage -1 到 Stage 7）

输出

以 Markdown 格式输出综合可信度报告，包含以下字段：

• 总体摘要：一句话概述验证结论
• 分维度评分（0-100，附依据）：
  • 数学正确性（Stage 3 + 4，权重 30%）
  • 来源可信度（Stage 2 + 6，权重 25%）
  • 工程合理性（Stage 5，权重 20%）
  • 物理一致性（Stage 1 + 3，权重 15%）
  • 实现可行性（Stage 7，权重 10%）
• 加权综合分：按上述权重计算
• 已验证项：各 Stage 确认正确的内容
• 存疑项：有矛盾或不确定的内容
• 未验证项：因信息不足或工具限制未检查的内容
• 决策建议：推荐采用（>80）/ 有条件采用（60-80）/ 需进一步验证（40-60）/ 不推荐（<40），附具体理由

依赖关系

依赖所有前序 Stage 的输出。

可复用性

不可独立复用。

工具建议

无需外部工具——纯汇总型 Stage。

可扩展点

• 评分维度和权重可配置化（不同领域可自定义权重）
• 可增加可视化输出（雷达图、颜色标记热力图）
• 可增加"历史验证记录管理"——跨会话复用已验证结论

13. 增量再验证规则

当用户修改公式后，不需要重新执行完整流水线。只重新验证受影响的 Stage。

设计意图

用户可能反复调整公式。如果每次微调都重跑全部 Stage，效率极低。本规则定义变更影响分析策略。

核心规则

1. 变更分类：
   • 符号级变更（修改变量名、下标）→ 仅重新执行 Stage 2（符号统一）
   • 表达式级变更（修改项、系数）→ 重新执行 Stage 3 → Stage 4（如推导受影响）→ Stage 8
   • 结构级变更（增删项、改变公式形式）→ 重新执行 Stage 3 → Stage 4 → Stage 5 → Stage 8
   • 上下文变更（问题定义、适用范围变化）→ 重新执行 Stage 1 → Stage 2 → … → Stage 8
2. 依赖链分析：
   • Stage 2 的输出被 Stage 3、4、5、7 使用 → 如果 Stage 2 结果变化，下游全部重跑
   • Stage 3 的输出被 Stage 4、5、8 使用 → 如果 Stage 3 结果变化，Stage 4、5、8 重跑
   • Stage 4 与 Stage 5 独立 → Stage 4 结果变化不影响 Stage 5
3. 增量验证执行规则：
   • 变更前，标记当前验证上下文中的 affected_stages
   • 仅执行标记为 affected 的 Stage
   • 未受影响的 Stage 直接复用上次结果
   • 在 Stage 8 报告中标注哪些 Stage 的结果是复用的

14. 流程不足分析

当前验证流水线存在以下不足：

14.1 无法验证经验性/试探性公式

纯经验公式（如通过数据拟合得到的回归方程）无法通过本流水线的 Stage 4（推导验证）——没有推导链可言。这类公式只能通过 Stage 3（数学一致性）、Stage 5（工程合理性）、Stage 6（多源对比）和数值实验来评估。

14.2 对高维/复杂公式的推导验证能力有限

Stage 4 依赖 LLM 或符号计算工具逐步重建推导链。对于涉及张量运算、泛函分析、随机过程等高度抽象的公式，推导重建可能不完整或错误。

14.3 跨领域公式的 Stage 1 准确性不足

Stage 1 要求识别公式所属领域和假设条件。对于跨领域交叉的公式（如"用控制理论分析生物系统"），单一领域的假设体系可能不适用，而你难以自动识别这种跨界。

14.4 缺乏数值实验验证

当前流水线仅在 Stage 3 中建议"数值代入法"作为辅助手段，没有独立的数值实验 Stage。对于复杂公式，数值仿真验证往往比纯分析更有效。需要补充 Stage 5.5：数值实验验证（见 §15）。

14.5 来源评价体系不够细化

Stage 2 的 trust_level 仅有三级（high/medium/low）。对于灰色文献（预印本、技术报告、会议演示）没有精确分类。需要更细的来源评分标准。

14.6 缺乏自动化闭环

当前流水线依赖你手动执行每个 Stage。对于重复性验证（如同一类公式的不同参数组合），缺乏自动化支持。

15. 建议新增 Stage：数值实验验证（Stage 5.5）

为什么需要：纯分析性验证（Stage 3、4、5）依赖逻辑推理，但对复杂公式（多维积分、迭代公式、概率分布），数值仿真往往能更快发现错误。

解决的问题：弥补 Stage 4（推导验证）对经验公式无效的缺陷；提供比 Stage 3 数值代入法更系统的数值验证。

与已有 Stage 的关系：

• 插入在 Stage 5 之后、Stage 6 之前（Stage 5 已确认工程合理性，数值实验在此基础上进行）
• 独立于 Stage 3、4（不依赖推导链）
• 为 Stage 6（交叉验证）提供数值证据

是否默认启用：建议在"全面验证"深度下默认启用，"标准验证"下可选。

收益：

• 可发现解析推导难以发现的数值问题（如收敛速度、奇点行为）
• 对无推导链的经验公式提供唯一的系统性验证手段
• 为 Stage 8 报告提供定量可信度证据

Stage 定义（概要）：

• 核心职责：设计数值实验、执行仿真、对比理论预测与数值结果
• 建议执行内容：
  1. 选取典型参数集（至少 3 组，含边界值）
  2. 使用数值方法（如 Python/NumPy）计算公式结果
  3. 与理论预期（如极限值、守恒量）对比
  4. 检查收敛性、稳定性、计算误差
• 输入：Stage 2 符号表 + Stage 5 边界条件分析
• 输出：数值结果表、误差分析、与理论预期的偏差

16. 架构评估与优化建议

16.1 降低耦合度

• 数据协议标准化：每个 Stage 的输入/输出使用定义好的 JSON 结构（已在各 Stage 中给出）。Stage 之间不直接依赖对方内部状态，只依赖输出结构。
• 共享上下文集中管理：verification_context 作为独立对象，各 Stage 只读写自己关心的字段，不修改其他 Stage 的输出。
• 新增中间缓存层：对于耗时操作（如 Stage 2 的文献检索），缓存结果以便增量验证时复用。

16.2 提高可维护性

• Stage 定义与实现分离：本 Skill 定义 Stage 的"做什么"（职责、输入输出），未来的能力 Skill 定义"怎么做"（具体检查清单、算法）。
• 版本化 Stage 输出：每个 Stage 报告标注本 Skill 版本号，便于兼容性追踪。
• 单 Stage 测试：每个 Stage 的验证逻辑应能独立测试（输入 → 输出可验证）。

16.3 提高可扩展性

• 插件式 Stage 注册：新增 Stage 只需在本文档的流水线图中插入，并定义其输入输出接口——不需要修改已有 Stage 的定义。
• 能力 Skill 懒加载：在 Stage 定义中通过 suggested_skills 字段声明需要的 Skill，由上层调度器按需加载。
• 开放评分权重配置：Stage 8 的评分权重可通过用户配置覆盖，适应不同领域的关注重点（如电机控制更偏重 Stage 5，理论数学更偏重 Stage 4）。

16.4 提高验证准确率

• 多路径验证：关键检查点（如符号统一、推导关键步）应同时使用 2 种独立方法验证（如符号计算 + 数值代入）。
• 共识机制：Stage 6 要求至少 3 个独立来源，降低单源错误风险。
• 可追溯性链：每条判断附上来源/推理链，用户可独立核查——即使你的判断有误，追溯链也能帮助用户发现。

16.5 适配 AI Agent 可组合 Skill

• 与 web-reference-tracing 互操作：Stage 2、6 声明需要该 Skill，上层自动加载。
• 与 adr-guidelines 互操作：验证结论可转化为 ADR 记录，标记技术选型中的公式可信度依据。
• 输入/输出标准化：每个 Stage 输出独立 JSON 对象，便于工具链解析、存储、跨会话复用。
• 决策路口显式化：Stage 0 和 Stage -1 定义了明确的验证深度选择，减少 Agent 瞎猜。

17. 快速参考

18. 禁止事项

• 禁止在未完成 Stage -1 和 Stage 0 的情况下直接跳到后续 Stage
• 禁止在 Stage 2 来源验证中仅凭模型记忆给出出处而不使用搜索工具验证——引用需要可追溯的真实来源
• 禁止在 Stage 4 推导验证中跳过中间步骤——每一步必须有明确依据
• 禁止在 Stage 8 报告中使用模糊表述（"似乎正确""应该没问题"）——必须使用定量评分或确定的结论
• 禁止将未验证的结论标记为"已验证"
• 禁止在增量验证时直接复用旧版符号表而不检查变更影响
• 禁止在 Stage 1 跳过问题定义直接进入数学检查——问题定义错误会让后续所有验证无效

19. 自检要求

在完成公式验证并输出最终报告前，逐项自检：

• Stage -1 是否已正确判断验证必要性？
• Stage 0 是否制定了明确的 Stage 执行计划和工具选择？
• Stage 1 是否已确认问题定义、假设条件和适用范围？
• Stage 2 是否至少找到了 1 个可追溯的权威来源？（快速检查模式除外）
• Stage 3 是否检查了量纲、维度兼容性和基本代数关系？
• Stage 4 是否具有逐步骤依据的推导链？（快速检查模式除外）
• Stage 5 是否检查了极限情况、退化情况和物理约束？
• Stage 6 是否对比了至少 2 个独立来源？（仅全面验证模式）
• Stage 7 是否提供了数值稳定性建议？（仅快速/标准模式为可选）
• Stage 8 报告的评分是否有各 Stage 的依据支撑？
• 报告是否明确列出了已验证、存疑和未验证的内容？
• 是否避免了模糊表述，使用了可验证的判断？
• 是否为增量验证场景正确识别了受影响 Stage？

如出现违反以上规则的情况，重新执行相关 Stage。