关于 essence-diagnosis
essence-diagnosis 是用于分析复杂、尚不明确问题的 Agent 技能，不负责提出修复方案。它构建证据链与逻辑链、比较多个假设，并要求通过 multi-agent-debate 进行对抗式审查。
主要功能
- 01结构化 SOAP 诊断流程
- 02收集并去噪信息来源
- 03构建并检验多个假设
- 04将证据映射为因果逻辑链
- 05要求多 Agent 对抗式审查
适用场景
- 01调查原因不明的复杂问题
- 02比较不同的根因假设
- 03编写可追溯的诊断报告
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/essence-diagnosis确认已加载。
附带文件reference.md
详细介绍
本质诊断
角色：仅对复杂问题进行本质分析和诊断。生成完整的证据链 + 逻辑链 + 假设列表。不解决问题（不提供解决方案、不执行、不修复）。必须协调
multi-agent-debate进行对抗性验证。输出模板和格式见 reference.md。
为什么需要此技能
面对复杂问题（大量日志、因素相互交织、症状与本质脱节），人类和 AI 往往会犯同样的错误：停留在第一个看似根因的解释上。这是过早收敛。一旦收敛，后续分析就会变成“证明自己正确”——确认偏误随之出现，反例遭到忽视，其他解释被舍弃。
此技能的唯一价值，就是通过结构化流程对抗这两种认知陷阱，将“我觉得是 X”转变为“证据链指向 X，且 Y/Z 已被证伪”。它不负责修复，而是提供一份经得起对抗性验证的诊断报告。
与其他技能的关系
| 技能 | 职责 | 与此技能的关系 |
|---|---|---|
solve-workflow | 完整工作流（分析 → 解决方案 → 执行 → 验证 → 回顾） | 此技能是其第 1.2 阶段的深度分析，专注于分析/诊断；也可单独使用 |
multi-agent-debate | 对现有结论进行三 Agent 对抗性验证 | 此技能的输出 = 其输入；单向协调，辩论不会回调此技能 |
diagnose / debug-workflow | 单一错误的诊断/调试 | 它们假设“已知这是错误”；此技能不做此假设，适用于“甚至还不确定问题是什么”的模糊状态 |
hybrid-debug | 混合应用（WebView/WKWebView/Electron + H5）的四层调试 | 领域特定的预筛选：对于混合应用问题，应先应用其四层模型；只有在逐层结构化分析后问题仍不明朗时，才升级到此技能 |
触发条件与模式
触发词：本质诊断、根因诊断、深度诊断、诊断问题本质、梳理问题逻辑、证据链分析、逻辑链分析、essence-diagnosis
默认行为：用户调用此技能时，默认问题较为复杂——不设置复杂度门槛。
方法论基础
三种来源融合（均有成熟的行业实践支持，并非凭空创造）：
| 来源 | 借鉴机制 | 在此技能中的作用 |
|---|---|---|
| 医学鉴别诊断（DDx） | SOAP 格式 + 并行假设 + VINDICATE 分类 | 流程基础（S/O/A 三个部分）+ 强制穷尽假设 |
| 强推理（Platt） | 并行假设的证伪（而非证实）、可证伪性（Popper） | 假设检验机制——寻找反例，而非支持者 |
| 故障树/事故调查 | 自顶向下的因果回溯、证据支持矩阵 | 逻辑链可视化 |
核心流程：S → O → A → Debate
S — 主观信息：信息场收集与去噪
目标：从混乱的信息场中进行结构化提取——不要全盘接受。复杂问题的本质是信号被噪声淹没；去噪是第一步。
- 来源清单：日志、代码、文档、指标、配置、用户反馈、会议记录、git 历史……列出所有可用的信息来源
- 去噪：去重、按时间对齐、按相关性排序、标记明显的噪声
- 输出：客观事实列表（每项均注明来源
file:line/cmd/N samples）
为什么要先去噪再形成假设？因为当你满脑子都是假设时再读日志，只会看到支持这些假设的行——这正是确认偏误的入口。严格禁止在去噪过程中形成假设。
O — 目标：生成多个假设并构建证据链
目标：强制提出多个假设，避免过早收敛。
- 生成假设（≥3）：逐一检查 VINDICATE 通用分类法中的每个类别（见 reference.md）；每个类别至少提出一个假设
- 为每个假设构建证据链：使用 Toulmin 论证模型（见 reference.md）；6 个要素必须完整
- 分离证据与假设：先收集证据，再将其与假设匹配；绝不“先形成假设，再搜寻证据”
- 没有来源，就没有结论：每条证据都必须引用原文及行号、命令输出或样本数量，否则将其舍弃
为什么要 ≥3 个？只有一个假设时，你会不自觉地只收集支持它的证据；有两个时，你会选择更顺眼的那个；有三个或更多时，你才会真正进行比较。这是鉴别诊断中沿用百年的经验法则。
A — 评估：组装逻辑链并反击偏见
目标：将证据链组装成逻辑链，并主动寻找自身工作中的漏洞。
- 构建逻辑链：自上而下进行因果回溯（故障树，见 reference.md）；每条因果链路都需要证据支持
- 反击偏见检查：针对每个假设，逐项完成以下 4 项偏见检查清单
- 识别最薄弱环节：找出逻辑链中最薄弱的 2-3 个环节——这些环节将交由辩论审查
- 设计物理验证：每个结论都必须对应一个可执行的验证命令或实验
编排 multi-agent-debate（硬性约束，不可选）
完成 S/O/A 后，必须调用 multi-agent-debate 进行对抗式验证。这是此技能的硬性约束。
移交材料（格式见 reference.md）：
- 一段话概述主要假设
- 证据列表（每条证据都带有来源标签）
- 2-3 个最薄弱环节
辩论返回结论后，更新诊断报告中的“已确认事实 / 合理推断 / 尚未解决的争议”各章节。
为什么必须进行辩论？无论 S/O/A 多么严谨，它们都是由单个分析者推动的，因此存在盲点。辩论运用三个对抗视角（Defender / Challenger / Evidence Hunter），强制打破单一视角，并通过物理证据裁定推理争议。
证据链硬性约束
| 规则 | 原因 |
|---|---|
| 没有来源，就没有结论 | 没有原文引用的“证据”是幻觉的温床——大模型会捏造看似合理的引用 |
| Toulmin 6 个要素（Claim / Data / Warrant / Backing / Qualifier / Rebuttal） | 强制将每个结论分解到可审计的粒度；Rebuttal 会促使你主动设想反例 |
证据标签：[FACT:file:line] [FACT:cmd] [FACT:N samples] [INFERENCE] [UNRESOLVED] | 事实与推断必须在视觉上清晰区分，否则推断会悄然变成“事实” |
| 分离证据与假设 | 先收集证据，再提出假设——避免假设污染证据收集 |
偏见反击检查清单
在阶段 A 中，对照每一项检查每个假设：
| 偏见 | 表现 | 应对措施 |
|---|---|---|
| 确认偏误 | 只收集支持假设的证据 | 要求每个假设列出 ≥2 条反面证据；找不到反面证据本身就是危险信号 |
| 过早收敛 | 遇到第一个看起来合理的假设就停止 | 要求所有 ≥3 个假设都完整走完证据链；不得中途放弃 |
| 锚定效应 | 被第一条信息 / 第一段堆栈跟踪锚定 | 在阶段 S 的去噪完成前，禁止形成假设 |
| 将相关性视为因果关系 | A 和 B 同时出现，因此 A 导致 B | 要求给出机制解释（A 通过什么机制导致 B），并搜寻反例 |
输出格式
完整的 SOAP 诊断报告 + 证据链表格 + 逻辑链图示 + 辩论交接包——模板见 reference.md。
此技能的最终交付物是诊断报告，而非修复计划。报告必须以如下说明结尾：“This report covers diagnosis only and has not entered the resolution phase.”
危险信号（反直觉陷阱）
- ❌ 跳过 S 阶段，直接提出假设——基于未经去噪的信息提出假设，就是在噪声之上构建
- ❌ 将推断混入证据收集——把推断当作事实会污染证据链，且难以追溯
- ❌ 只为最有可能的假设构建证据链——其他假设未完成 = 过早收敛，这正是此技能要对抗的问题
- ❌ 逻辑链超过 5 步且没有中间证据——冗长的推理链容易滋生幻觉；每一步都需要依据
- ❌ 在组织辩论前未找出最薄弱的环节——辩论会失去目标，沦为空洞争论
- ❌ 把此技能当作修复工具——交付诊断报告后，如果用户需要修复，请转交给
solve-workflow或专用技能