lionad-morotar/distill-and-archive

当前 SKILL 服务且仅服务于 ~/Github/Lionad-Morotar/blog 博客项目，所有改动都应以该项目为基础。

上下文

目标

将网络文章或内容提炼为精炼知识点，并归档到用户的笔记系统中。没有用户输入时，从会话上下文（如用户询问问题，LLM 做出的回复）提取原始内容。

工作流程包含：内容提取与 distill、笔记系统调研、归档计划制定、用户确认、执行归档和提交。尤其要注意知识点的存放位置。

归档模式

1. 简单归档：当用户明确要求"简单归档"时，适合简单的链接列表、索引等输入内容。输出严格使用 * [标题](地址)：说明 模板；知识点标题应指向具体内容（如"V8 引擎实现参考"），禁止命名为"学习资源"、"参考链接"等宽泛索引标题。
2. 默认归档：当用户未指定归档模式时，采用默认归档模式，适合单个或多个知识点，一整篇博客等输入内容

可以归档的内容

• 链接：简单归档模式下可以归档链接及简单的介绍
• 知识（Knowledge）：事实性、客观、可验证的内容
• 观点（Opinion）：作者的主观经验、实践偏好、流派主张
• 高层次洞见（Insight、元思考、元认知）：部分高难度网站或信息特殊的网站，可提炼高层次洞见——捕获思维模式而非操作细节。这种洞见关注作者如何理解问题、建立概念关联、形成独特的认知框架，而非具体的技术步骤或实现方法。

Workflow

1. 获取内容：从用户输入获取内容，当输入为空时回退到从上下文提炼内容
2. 主代理（你）直接使用工具执行以下任务 2.1 内容验证：区分事实和观点，展开简单的补充搜索，验证一手优质来源、区分不同角度、避免流畅性偏见 2.1.1 如果在会话上下文中，step 1 的内容已经得到充分验证，可跳过 2.1 步骤 2.2 将内容整理为精炼知识点
   • 默认归档：正文使用自然叙述，不出现 L1/L2/L3 等验证标签
   • 简单归档：严格使用 * [标题](地址)：说明 模板，知识点标题指向具体内容，不展开长篇描述，禁止宽泛索引标题
   • 保留通用性，移除特定项目描述：归档的是通用知识，应保留足够的技术细节（如具体 API、配置项、阈值、工具组合），但移除当前项目/会话的特有名称、临时变量、业务术语或“当前项目 xxx”式表述。把触发条件泛化为可复用的技术条件，让 future self 看笔记时不需要回忆本次会话；同时避免过度抽象到只剩口号。 2.3 定位每个知识点的存放位置
   • 列出同一 Subdomain 下所有候选 Topic 文件，用 extract-markdown-meta.js 读取每个文件的 title、description、toc
   • 优先选择内容主题与知识点最匹配的 Topic 文件，禁止把知识点放进入口/索引文件（如 prompt.md、ai.md 等仅做导航的文件）
   • 给出精确插入锚点（前序/后序四级标题），并避开引用边界 2.4 为每个知识点撰写归档计划（包含所有知识点的四层定位表格、内容草稿和文件变更清单）
3. 输出完整归档计划 3.1 快速读取目标文件片段，校验插入锚点是否真实存在、是否切断引用边界、是否把知识点错误放入入口/索引文件 3.2 必须输出完整归档计划（包含四层定位表格、每个知识点的正文草稿、文件变更清单、引用来源说明）后，再向用户请求确认 3.3 若锚点缺失、定位不合理（如把知识点塞进索引文件）、或可能切断引用边界，返回上一步修正
4. 得到用户肯定后，根据计划写入并提交，提交信息“gists: 补充/更新/删除 [主题/文件] [简要描述]”，无需推送
5. 索引维护（简单归档模式可跳过此步骤）
   • 若新建了 Topic 文件，必须同步更新所属子领域的索引文件（如 content/6.maps/_ai/ai.md），在对应分类下增加指向新 Topic 的链接，避免“有文件无入口”
   • 若新增了 Domain 目录，更新 content/6.maps/Agents.md
6. 简单报告结果

关键细节

1. 读取 content/6.maps/Agents.md 可参考现有结构（置信度低）
2. 每个知识点都应使用基于四层认知结构（Domain → Subdomain → Topic → “#### <标题>”）的定位技术；一个 #### 四级标题对应一个原子化知识点
3. 禁止使用笼统的标题（如"## 学习资源"、"## 参考链接"）创建标题以及归档到这些位置
4. 优先使用 JS 脚本读取文件元数据（包含标题、目录等）以确定文档内容，而不是直接读取整个文档。脚本位于 skill 私有工具链目录：

   node ~/.claude/skills/distill-and-archive/scripts/extract-markdown-meta.js <文档绝对路径> [--depth=3]
   

5. 避免过拟合陷阱：不要仅因为文章提到了某领域术语，就将其归入该领域
6. 简单知识保持单一核心观点，不强行拆分
7. 禁止使用 --- 分隔线
8. 引用格式统一为“见：”链接：归档正文不使用 [^n] 或 [^label] 脚注；每个 #### 知识点正文结束后空一行，跟唯一一行 见：[标题](url)。若把多个 get-secrets 要点合并到同一个 #### 标题下，也只保留一个 见：
9. 内容验证阶段工具调用限制：内容验证阶段只能使用 open-websearch / fetchWebContent / Read 等只读搜索工具，每个知识点验证最多 2-3 次工具调用，超限时自动终止并返回当前结果
10. 使用三层事实模型验证内容（仅用于内部验证阶段）： L1 经验事实，可量化、可证伪，如“「已核实」式陈述，精确数字/日期” L2 解释性框架，因果解释、意义赋予如“有分析认为/证据指向」式陈述，呈现多元框架” L3 价值判断，应然陈述、主观评估，如“「作者主张/建议」式陈述，标注为观点”

强制说明：L1/L2/L3 仅用于内部验证阶段，禁止出现在返回给用户的归档计划正文中。验证完成后，应将 L1/L2/L3 的区分内化到语气里——L1 用直接陈述、L2 用“这反映了/其机制在于”、L3 用“工程上应/建议”——并在验证摘要中用自然语言描述（如“经验事实，已得到 OpenAI 官方文档验证”），而不是保留 L1/L2/L3 标签。

11. 简单归档模式专用约束

    • 严格使用 * [标题](地址)：说明 列表项格式
    • 知识点标题应指向具体内容（如“V8 引擎实现参考”），禁止“学习资源”、“参考链接”等宽泛索引标题
    • 链接本身即为引用来源，无需再额外添加“见：”行
    • 简单归档作为已有 Topic 下的一个具体知识点存在，不应单独创建只含链接列表的索引文件

12. 通用性校验：归档前检查知识点是否仍能被 future self 看懂，且保留了足够的技术细节。若正文依赖当前项目的具体信息，应泛化为通用技术条件或补全上下文；禁止出现“当前项目 xxx”“本次会话中的 xxx”等指代。

13. 正文行长度控制：归档正文每行不超过 120 个字符；超过时在句读或短语边界 soft wrap。写入后必须运行 node /Users/lionad/Github/Lionad-Morotar/blog/scripts/lint-md.mjs 检查修改的文件。

14. 计划调整只返回变更部分：当用户对已给出的归档计划提出调整（如增减知识点、修改位置、合并条目）时，仅输出需要变更的项（位置、内容或文件清单），不要重复返回完整的四层定位表格和所有知识点正文。

简单归档模版

#### 具体的技术点标题

* [标题](地址)：简短的链接说明

示例：

#### V8 引擎实现参考

* [V8 Resources](https://mrale.ph/v8/resources.html)：V8 引擎演讲、文章与视频资源索引，涵盖性能优化、编译管线、GC 与 inline caching 等实现细节

默认归档模版

• 默认归档模版

归档计划确认模版

在归档前使用此模板向用户确认：

• 归档计划确认模版

基本知识

四层认知结构详情参考

| 层级 | 定义 | 物理形式 | 判断标准 | |------|------|----------|----------| | 领域 (Domain) | 最高层级的知识边界 | _domain/ 目录 | 存在于 0.index.md 的导航结构中，目录以 _ 开头 | | 子领域 (Subdomain) | 领域内的专业分支 | subdomain/ 子目录或文件 | 构成独立学习单元，有明确知识边界 | | 主题 (Topic) | 具体的技术点或概念 | .md 文件 | 超过 150 行或有扩展潜力的内容拆分为独立文件 | | 知识点 (Knowledge Point) | 原子化的思考性内容 | #### 四级标题 | 观点、案例、洞见，不拆分为独立文件 |

L 层级表述规则参考

• L1 经验事实 — 直接陈述，精确数字/日期，如：「2025 年 OpenAI 报告亏损 50 亿美元，较 2024 年增长 180%。」
• L2 解释性框架 — 「有分析认为」「证据指向」，可呈现 2 个框架，如：「有分析将 OpenAI 比作 AI 界的 WeWork，但这一类比存在争议——OpenAI 拥有 200 亿美元收入，而 WeWork 主要是亏损。」
• L3 价值判断 — 标注为「作者主张」「文章建议」如：「作者主张，投资者应对高估值 AI 公司保持谨慎，优先考虑现金流而非增长率。」