build-evidence-map

构建证据地图

将一个有争议的问题转化为可移植的决策产物，展示哪些内容支持当前立场、哪些内容对其构成反对，以及哪些仍然未知。 不要用图表去装饰一个尚未追溯来源的答案。

对于简单的事实性主张或一般性事实核查请求，请改用 doublecheck 之类的验证 工作流。当证据、中间主张、权衡取舍与缺失事实之间的关系至关重要时，请使用本技能。

工作流

1. 界定一个决策。 写出一个可证伪的问题和一个临时立场。不断收窄该问题，直到 读者能够识别出这张地图正在检验的是哪种行动或信念。

2. 收集有界的来源区域。 优先采用直接观察和一手来源。记录 URL 或绝对本地路径、 发布者、发布日期、检索日期、章节/页码/行号/时间戳定位符，以及一段简短的可核对 摘录。当来源质量存在争议时，阅读 references/evidence-ladder.md。

3. 原子化推理过程。 只创建四种节点类型：

   • position：当前唯一的裁决；
   • claim：一个中间命题；
   • evidence：对某一来源区域的忠实陈述；
   • unknown：一个可能改变裁决的具体缺失事实。

4. 为每条边标注类型。 使用 supports、contradicts、qualifies 或 missing。添加一段通俗易懂的说明，解释来源节点为何对目标节点产生影响。 主题相似并不构成支持。范围、日期或人群不同并不自动构成矛盾。

5. 保留反证。 不要因为临时裁决在反证面前依然成立就删除反证。用 qualifies 边来表示范围差异。

6. 以结构化方式表达不确定性。 不要臆造置信度百分比。 添加一个 unknown、收窄立场，或对某一主张加以限定。

7. 写出 UTF-8 JSON，后缀为 .doubt.json。遵循 references/map-schema.md。保持 ID 简短、 稳定且具有语义。

8. 以失败即关闭的方式验证。 相对于本 SKILL.md 解析 scripts/validate.mjs，然后用 Node.js 18 或更新版本运行它：

   node <skill-directory>/scripts/validate.mjs decision.doubt.json
   

   随附的验证器仅使用 Node.js 内置模块，不需要 npm 或 网络访问。在报告成功之前修复每一处发现的问题。只有当命令以 0 退出并打印 VALID，后跟一个 64 字符的凭据时，才能说这张地图是有效的。文件哈希、节点数量、JSON 解析或人工模式 审查都不是 Doubt 凭据。如果无法运行确定性验证，请报告 该阻塞情况，而不是捏造成功。

   只有当用户已经安装了 [email protected] 时，才渲染经过验证的地图；不要隐式安装或执行远程包：

   doubt map decision.doubt.json --out decision.html
   

9. 仅在获得明确网络许可时才验证来源快照。 以下命令会检索每个已记录的 HTTP(S) 来源，并在 无法匹配某段摘录时以失败即关闭的方式终止：

   doubt verify decision.doubt.json \
     --out decision.verified.doubt.json
   

   切勿隐式运行此命令。本地文件验证不使用 网络。不要手写 verification 对象，也不要隐藏不匹配。

10. 检查交付物。 确认问题、裁决、 反证、未知项、边说明以及确切的来源区域仍然 可读。将 JSON 视为规范的可编辑产物；HTML 是可分享的视图。

质量门禁

一张完成的地图必须满足以下全部条件：

• 恰好有一个 position 具有传入推理；
• 每个证据节点都指明一个来源，并参与一条边；
• 每个来源都被使用，并且具有日期、有界定位符以及实质性 摘录；
• 每个非 position 节点都有一条指向 position 的有向路径；
• 推理图没有重复边或有向环；
• 当来源集合中包含相反或限定性证据时，这些证据已呈现；
• 每个改变决策的缺口都是一个显式的 unknown 节点；
• 每条边注释都解释了支持、矛盾、限定或缺失；
• 结论的范围不超过证据。

交付结果

报告：

• 用一句话说明当前 position；
• 最强的反证或限定；
• 最重要的未解决 unknown；
• 指向规范 JSON 和任何 HTML 的路径；
• 确定性验证和显式来源验证是否运行。

绝不要将结构上有效的地图描述为已被证明为真。验证确立的是 可追溯性和图完整性；来源质量和推理质量仍 需要人工审查。