set-note-description

汇总 frontmatter

为指定笔记生成 description 属性，并将其写入每篇笔记的 YAML frontmatter。

请先阅读目标知识库的说明。对于周期性笔记，如果知识库有适用于所请求粒度的专用汇总工作流，请优先使用。对于根据子级笔记综合而成的父周期笔记，如果有 periodic-rollup，请使用它。此技能适用于总结笔记本身的内容；如果没有更具体的工作流，也可将其作为备用方案。

如果没有指定笔记，请先询问要总结哪篇笔记。

---

作为 Markdown 文件分析助手，阅读笔记并生成便于检索的描述。遵循指定模式，或根据内容类型智能选择。

模式选择

如果用户指定了模式，请使用该模式。否则，根据内容类型进行选择：

以下情况使用摘要模式

• 临时性内容：每日日志、每周汇总、日记、周期性笔记
• 有时限的材料：会议记录、活动回顾、旅行日志
• 探索性思考：随想、头脑风暴、问题推演
• 个人反思：情绪梳理、回顾、经验教训

这些文档的价值在于其中的_见解或事件_——你可能不会重新通读全文，只需要提炼后的要点或记忆锚点。

以下情况使用元信息模式

• 参考资料：指南、操作方法、文档、模板
• 常青资源：流程、清单、政策、标准
• 知识库条目：概念说明、主题概览
• 精选合集：链接索引、阅读清单、资源汇编
• 项目材料：规范、设计、简报（文档承担结构性作用）

这些文档是你_按需检索_的——你要查找的是能解决问题或回答疑问的内容，而不是回想自己得出了什么结论。

判断主要意图

评估文档_本质上是什么_，而不是根据个别句子推断用途。如果相关信号相互冲突，请以文档的主要用途为准：

• 日记、日志或事件记录 → 摘要
  回忆_发生了什么_或_讨论了什么_。
• 手册、模板或参考指南 → 元信息
  了解_何时使用_该工具。
• 边思考边写或进行反思的人 → 摘要
  提炼某个时间点的领悟和个人见解。
• 百科条目、规范或项目简报 → 元信息
  说明主题或项目的范围、要求等结构性信息。
• 决策清单或会议结论 → 摘要
  提炼_实际结论_，让人无需通读文档。
• 精选合集或链接索引 → 元信息
  界定合集范围比逐一总结每个链接更有用。

---

边缘情况

混合文档（例如，包含可复用流程的每日日志）： 默认按照文档的_主要用途_处理。附带记录了流程的每日日志仍然是每日日志——使用摘要，并将流程作为值得注意的事项提及。如果该流程变得足够有价值，就应将其提取出来，单独记录。

会议笔记： 使用摘要。聚焦于决策、行动项和关键讨论内容，而不是“Q3 规划会议笔记。用于……时”。

书籍／文章笔记：

• 如果主要是摘录和引文，综合分析很少 → 元信息（“关于[标题]的笔记，涵盖[主题]。思考[领域]时使用。”）
• 如果包含大量个人评论、见解或与原文相关的论点 → 摘要（记录你自己的收获）

规格说明、简报、提案： 使用元信息。这些都是结构性文档——读者需要知道它们涉及的问题范围，而不是它们结论的摘要。

简短占位内容： 使用元信息。描述预期用途：“API 身份验证文档的占位内容。记录身份验证流程时使用。”

难以归类的内容： 默认使用摘要。记录实际内容，比对模糊内容做出笼统的元信息描述更有用。

---

摘要模式

用一两句话概括内容所述或发生的事情：提炼出的要点，以及有助于回忆的具体名称、事件和细节。对于探索性内容，记录主要主题。

保持朴素简洁。开门见山地描述内容本身，不要用评价或框架式的开场白（“高效的上午……”“这一天都在……”）。逐词删去冠词和填充词，但要保留通俗易读的句子，不要堆砌密集的分号式片段。避免使用衔接副词（“随后”“接着”“然而”）和叙事弧线（因果、解决过程）；提炼精髓，不必详尽罗列细节。

对于周期性笔记：

• 省略时间段前缀（文件名已涵盖）
• 尽量减少对卡片盒、补充内容或次要章节的着墨
• 聚焦实际内容、活动和见解

摘要示例

• "时间线预留 20-30% 的缓冲可避免 Acme Corp 延误；与 Sarah 团队提前对齐，比详细的技术规划更省时间。"
• "难以委派 Marcus 的入职工作——把亲自完成等同于关心；重新理解委派，将其视为建立信任。"
• "上午进行 Shopify 集成；下午因 AWS 中断和家人预约耽搁。阅读 Kleppmann 的作品时，发现自己在分布式系统方面存在知识缺口。"

---

元信息模式

描述这份文档_是什么_——类型、用途、范围——以及何时参考。遵循内容 + 时机模式：

[文档类型／主题] [范围或重点]。在[明确的触发条件]下使用。

明确说明触发条件。“在相关时使用”毫无用处；“调试身份验证故障或让新的后端工程师熟悉项目时使用”则便于检索。

对于采用元信息模式的周期性笔记（少见，但也可能按需使用）：聚焦于可作为检索锚点的领域、项目或主题。

元信息示例

• "关于知识库元数据规范和 Base 文件集成的指南。设计文件夹结构、排查查询问题或熟悉知识系统时使用。"
• "项目复盘模板，包含时间线、协作和技术债务方面的提示词。结束项目或准备团队复盘时使用。"
• "分布式系统阅读清单，附带进度笔记。选择下一本技术读物或向他人推荐资源时使用。"
• "关于 Shopify 库存同步的规格说明，涵盖错误处理和重试逻辑。实现库存功能或调试同步故障时使用。"

输出

根据笔记内容调整长度：通常以约 150–250 个字符（一两句话）为目标；对于简单或内容稀少的笔记，长度应远低于此，切勿为了凑字数而填充。将此作为起点，并根据笔记内容以及用户在其系统中使用描述的方式进行调整。务必远低于 1024 个字符；避免写成整段长文。

Frontmatter 位置

在 YAML frontmatter 的以下位置添加或更新 description 属性：

1. 身份与路由（aliases、icon、publish、permalink、url）
2. 内容/分类（tags、description）← 在此插入
3. 人员/时间/关系（author、members、meeting time、related）
4. 状态/来源（reviewed、created、modified）

重要规则

• 只修改 description 属性 — 切勿更改、转义或重新格式化其他内容
• 将摘要值放在双引号中
• 完全保留所有现有格式和 Obsidian 专用语法
• 如果无法写入文件，则输出一个 Markdown 代码块，内容仅为：description: "your summary here"

周期性笔记处理

对于周期性笔记：

• 如果文件名已表明时间段，则不要添加时间前缀
• 尽量降低对“卡片盒笔记法”或收件箱部分的重视——这些区域用于收集计划稍后重新整理或转成其他笔记的内容（例如草稿、原始记录、外部链接），不要让它们影响摘要
• 聚焦于当天的实际内容、活动和见解

分层汇总模式

对于基于子笔记进行的每周、每季度或每年综合总结，请遵循环境中的汇总工作流或 periodic-rollup。该工作流负责选择子笔记、处理缺失笔记以及汇总父笔记；不要在此之外再独立进行第二轮总结。