Imported from jiatong-lab914/obsidian-knowledge-mode (skills/insight-refinery/SKILL.md). Install upstream with npx skills add jiatong-lab914/obsidian-knowledge-mode --skill insight-refinery. Copyright stays with the author.

Insight Refinery

把当前待连接内容与 Vault 中的旧认知连接成可判断结构。当前输入可以是一个闪念、问题、新观察、多段碎片、几个指定节点或一组新旧判断。轻量优先，用户负责判断连接是否成立。

选择模式

• 联点探索模式（默认）：把一个或多个当前输入与现有 Claims/Contexts 联点呈现，允许类比、同构和跳跃，但全部新关系保持为候选；不急着验证、命题化或写回。
• 连接验证模式：用户明确询问连接是否成立、要求找反例、判断能否成为 Claim，或准备写回时，对选中的候选连接进行严格验证。
• 全局巡视模式：用户明确要求巡视全部 active claims、寻找跨簇连接或 unknown unknown。

信号明确时直接进入对应模式，不把路由问题丢给用户。

层级职责

• 未经确认的当前输入是临时工作节点：闪念、问题、观察、碎片和用户指定的新关系都可以尚未结构化，默认既不是 Context，也不是 Claim。先保留原始表达和输入之间已有的关系，必要时再展开可能含义；不能为了方便检索而过早把它们压成单一命题。
• Claims 是主要语义节点：用于快速发现已有结构、模型、判断和可能连接。
• Contexts 是情境证据：用于检查 Claim 和候选连接来自哪些具体经历、事实或材料，防止结构脱离语境后固化成偏见。
• Layer 0 是原始备份：inbox/、daily/、wraps/ 不作为日常联点语料库；只有审计、准确还原、Context 不足或用户明确要求时才读取。
• Context 中出现的后设解释、局部模型或历史归纳不能自动当作已确认 Claim；只有正式 Claim 或用户当场确认的判断才能作为已确认语义节点。
• 引用 Context 时必须区分：实际材料/可观察事件、用户当时的感受与解释、AI 后续整理或推断。当时解释只能证明“当时这样理解”，不能自动证明该解释为真；AI 后续推断不能作为事实证据或 confirmed relation，除非它已被用户确认并写成正式 Claim。

检索

联点探索模式

1. 保留当前输入的原始表达，把一个或多个输入作为本轮临时工作节点；输入含义不清时再展开 1-3 种可能解释，提取少量关键词和同义表达，但不预先选定唯一解释。
2. 先搜索 status: active 的 claims/ 文件名、正文、YAML 和标签，找到可能与当前输入相关的语义节点。
3. 对命中的 Claims 做轻量健康检查：确认当前 status，读取 boundary，检查与当前问题相关的 conflicts_with 和 replaces 链；旧版本保留作审计，不混入当前语义模型。
4. 基于通过轻量检查的 Claims 形成候选局部语义模型；这里只产生 candidate connection，不把语义相似自动说成事实、同构或因果。
5. 默认只沿当前问题需要的方向探索一跳：询问形成前提时，读取命中 Claim 主动声明的 emerges_from / derived_from；询问后续结论时，反向搜索通过这两个字段引用命中 Claim 的 active Claims。只有用户明确要求关系地图、同时查看上下游、寻找 unknown unknown 或全局巡视时，才正反向探索；关系方向不是真理优先级。
6. 当候选连接需要具体证据、语境、边界校准或 confirmed 判断时，再沿真实来源和 wikilink 读取必要 Contexts。提取依据时标注它属于实际材料、当时解释还是 AI 后续推断，不把三者混写成同一强度的证据。
7. 如果没有命中 Claim，不自动搜索 contexts/。只有当前问题明确需要具体叙事、语境或来源，或能够说明候选连接仍缺少哪项证据/边界时，才搜索相关 Context；否则说明未命中已有 Claim，并停止 Vault 扩展。
8. 默认最多一跳。只有进入连接验证、连接多个指定节点，或第一跳留下能够明确说明的关系断点时，才允许第二跳；开始第二跳前先说明第一跳缺少什么。不得重复访问已读节点；发现循环关系时停止并报告，不把循环引用当作独立证据。
9. 两跳不包括自动展开 inbox/、daily/ 或 wraps/ Source。指向 Layer 0 的 wikilink 默认只用于定位。
10. 需要进入 Layer 0 时，先说明读取理由、目标文件以及为什么 Claim/Context 不足，再读取最少文件；没有明确目标时才做关键词搜索，不默认全局扫描。

日常联点不恢复“读取一篇长 MD 再从头寻找结构”的旧路径。长文只在用户明确指定或需要来源审计时作为补充材料，不取代 Claim/Context 的结构化召回。

只有实际读取了命中 Claims 之外的关系节点、Context 或 Layer 0 时，才在输出中简短说明扩展理由和实际来源；不展示冗长 Trace。

全局巡视模式

全局巡视不是关系库存。只有完成全量语义筛查、对抗性深读和处理回执，才能称为语义巡视完成。

1. 读取所有 status: active Claims 的正文，不以 frontmatter、标签、文件名、关系图或抽样代替。每条至少读取 Claim、## 推理路径 或旧版 ## Why、Evidence、boundary 和 Could Update If；缺少章节时报告缺口，不补写或臆测缺失内容。对实际存在的必读正文均完成筛查、并把缺失章节记为缺口后，该 Claim 可以计入 semantic_screened；不得把不存在的内容视为已经提供证据。
2. 建立仅限本轮的处理清单，区分：
   • structural_read：只读取结构、字段或链接；
   • semantic_screened：正文与上述关键章节已参与判断；
   • adversarial_deep_read：已执行反例、替代解释或跨 Claim 边界检查；
   • evidence_checked：已读取直接相关 Context 校准证据。 处理清单只用于报告读取深度，不写入 Vault，也不把“文件已打开”冒充“语义已处理”。
3. 基于已声明的一跳关系识别知识簇、孤立 Claim、重复前提、边界缺口和未解释冲突；关系图只作为候选入口，不把连接度、primary_tag 或空 conflicts_with 当作语义结论。把本轮识别出的主要知识簇及其 Claim 范围列入处理清单，使后续深读覆盖可以复核；这只是当前巡视的工作分组，不新增持久分类或 recall 规则。
4. 比较不同知识簇中结构相似但尚无 wikilink 的 Claim，同时主动寻找结论相近但分类前提不同、或边界不同却会在同一现实决策中导向相反行动的 Claims。
5. 对每个主要知识簇至少选择一个高影响、中心、较高 confidence、证据较弱或更新条件较模糊的 Claim 做对抗性深读；身份、行动或产品约束较强的孤立 Claim 也不得仅因没有关系而跳过。处理回执必须逐行映射 知识簇 -> 被深读 Claim -> 选择理由 -> challenge outcome，并为纳入范围的高影响孤立 Claim 单列同样的映射。被选中的 Claim 没有 finding 或 challenge failed 结果时，不算完成深读。
6. 对选中 Claim 执行以下检查：
   • 分类赌注：它在回答什么问题，暂时忽略了哪些差异；这些差异是否可能改变当前结论？
   • 最强反例 / 替代解释：同一材料还能支持什么竞争性解释？当前 Evidence 为什么足以或不足以排除它？
   • 边界碰撞：同一个现实情境落入不同 Claim 的 boundary 时，是否会导向相反判断或行动？不要用“边界不同”直接结束检查。
   • 自我封闭：boundary、Evidence 或 Could Update If 是否过度弹性、循环自证、不可观察，导致任何反例都能被吸收？
   • 证据独立性：多个来源是否来自同一批材料，多个 Claim 是否只靠互相引用制造支撑？
   • 重分类条件：什么新事实会迫使收窄、替代或放弃当前分类？条件是否具体到未来能够识别？
7. 当挑战必须依赖具体证据、语境或边界校准时，只读取直接相关 Context；未读取必要 Context 的挑战保持 candidate，并明确缺少哪项证据。不得为证明“审得很深”递归读取所有 Context 或 Layer 0。
8. 将结果区分为：
   • confirmed conflict：相同边界与条件下存在不能同时成立的结论，并有明确文本依据；
   • candidate boundary collision：边界不同，但现实分类选择可能导向相反判断或行动；
   • candidate self-sealing：边界或更新条件可能使 Claim 难以被反驳；
   • candidate evidence weakness：证据不足、同源放大、循环支撑或替代解释未排除；
   • candidate connection：值得继续验证的新连接；
   • challenge failed：已经提出强挑战，但当前文本与证据暂时能够回答。
9. 不设冲突数量目标。严格来自攻击过程和证据要求，不来自强制负面结论；挑战失败也要保留其问题、依据和失败原因。
10. 如果没有高优先级语义发现，不得裸报“未发现”。按知识簇展示最强的失败挑战、比较过的 Claims 和失败原因，让零发现结论承担举证责任。
11. 输出处理回执：active Claims 总数；逐 Claim 的 semantic_screened 清单；主要知识簇全集及 Claim 范围；知识簇和高影响孤立 Claim 的深读覆盖映射；evidence_checked Context IDs；verifier 状态；未完成项及原因。逐 Claim 筛查清单必须为每条 Claim 留一个紧凑的正文依赖锚点，例如实际用于判断的 Claim 要点、boundary、更新条件或缺失章节，不复述全文。缺少全量语义筛查、任一主要知识簇或纳入范围的高影响孤立 Claim 深读、challenge outcome 或最终回执时，只能说明完成了语义库存，不得声称全局语义巡视完成。

V1 不使用 embeddings。关键词和 wikilink 找不到的内容可能漏检，应明确这一限制。

验证模式与升格前的召回自验证

联点探索模式不要求每个当前输入先完成完整审计；只需标明来源和 candidate 状态，不把候选连接说成事实。

用户要求验证、形成候选 Claim、准备写回，或全局巡视需要给出较强判断时，必须自查：

• 支持证据：哪些 Context、Claim 或经上述门槛读取的 Layer 0 片段直接支持它？多条 Claim 如果来自同一个 Context，不能冒充多个独立证据。
• 反例/冲突：是否有 conflicts_with、边界相反或语义张力的内容？
• 适用边界：它在哪些情境下成立，哪些情境下不应推出？
• 分类与更新条件：当前问题、暂时忽略的差异和重分类触发条件是否可辨认、可观察，而不是依靠弹性边界吸收所有反例？
• 最新版本：是否有 status: replaced/invalid、relations.replaces 或更新后的判断？
• 证据缺口：还有哪一格没有找到证据，必须标为推测或候选？
• 层级校准：当前依据是具体 Context，还是另一个尚未被验证的语义模型？不能用多个相互引用的 Claim 制造虚假的证据闭环。
• 引用校准：引用的 Context 片段究竟是可观察材料、用户当时的解释，还是 AI 后续推断？回答是否准确保留了它的证据强度？

如果证据不足，只能输出候选连接或待验证问题，不能写成已确认关系。

关系路由

• 先区分证据关系与 Claim 关系：Context 或原始材料通常进入 sources 和 Evidence；Claim A 确实为 Claim B 提供独立支撑时，才在 B 中使用 supports 指向 A。同源材料不能被多条 Claim 放大成独立证据。
• 如果新发现只是重复、补充、时间差异或边界差异，优先去重、补 Evidence、收窄边界或提议更新旧 Claim，不为关系本身制造第三条 Claim。
• 同边界冲突、版本替代和状态变更继续遵守根目录 AGENTS.md 与 Claim Schema；不在本 Skill 复制另一套冲突协议。
• 新判断 C 从单一 Claim 或单一来源直接推出时使用 derived_from；只有多个 Claims 组合后产生独立、可调用、可更新的第三命题 C 时，才使用 emerges_from。Context 或原始材料只是提供实例、反例或边界时，仍然只进入 sources 和 Evidence。
• 如果只是说明节点如何连接，保留为 Notes 或 candidate connection；没有独立第三命题就不升格。

联点探索

从一个或多个当前输入出发，先保留原始表达；含义不清时列出 1-3 种候选解释，再选取最相关的 3-7 个 Claim/Context 节点。每条候选连接说明：

• 可能是什么关系：相似结构、条件分叉、张力、因果假设、类比或仅仅表面相似；
• 为什么可能有关；
• 来自哪些 Claim/Context；
• 哪里不像、哪里仍然缺证据。

探索阶段允许给出 1-3 个竞争性解释，但不默认把当前输入压缩成 Claim。输出的目的首先是让结构可见，而不是让每次联点立即闭环。

联点结束时不强制给当前输入或新关系归类。它可以：

• 只作为本轮有趣但未成熟的工作结果散掉；
• 在出现不可替代的具体经历、事件或材料后，成为候选 Context；
• 在形成可独立调用、可追溯且可更新的判断后，进入候选 Claim 的严格验证。

连接验证

只验证用户选中的连接，区分：

• 真冲突；
• 视角差异；
• 时间差异；
• 边界差异；
• 结构同构；
• 仅仅表面相似；
• 相关被误读为因果。

验证后给出“保留、收窄、改写或放弃”建议，并说明关系、强度、来源和理由。不能把相关包装成因果。只有用户进一步要求沉淀时，才把验证结果整理为候选 Claim。

关系状态必须区分：

• confirmed relation：来自真实 wikilink、YAML relations、明确来源文本或用户当场确认。
• candidate relation：当前推理提出但尚未写入或确认的连接。

局部图和文字说明里都要标出 candidate relation，不把它伪装成既有知识。

验证结论声明

进入连接验证或全局巡视并准备给出较强判断时，先给出：

发现：
发现类型：confirmed conflict | candidate boundary collision | candidate self-sealing | candidate evidence weakness | candidate connection | challenge failed
关系层次：因果 | 相关 | 推测 | 不适用
依据：

Mermaid

• 普通一对一关系不画图。
• 三个以上节点或多步推理时生成局部 Mermaid。
• 默认最多 7 个核心节点。
• 每条边写明关系名称。
• 跳跃性推理为每一步提供 premise 与 source。
• Mermaid 只是当前解释，不代替 claim 中的真实 wikilink。
• confirmed relation 和 candidate relation 必须在边标签中区分。

图后只附一句摘要和来源清单。

写回边界

• 不自动创建 claim、关系或 wikilink。
• 联点探索默认不提出候选 Claim；只有用户要求验证、沉淀或明确询问能否成为 Claim 时才进入升级判断。
• 用户认可后，先展示具体候选 patch。
• 新结构只能作为候选更新，不静默覆盖旧判断。
• Claim 写入遵守 _system/claim-schema.md 和根目录 AGENTS.md。
• 遇到事实争议时建议 researcher；已有结论需要换路复查时建议 verifier。
• 未经用户明确要求，不启动 Sub-agent。