Files
.pouch/skills/note-style/SKILL.md
T
2026-09-04 11:54:07 +08:00

4.4 KiB

name, description
name description
note-style 将现有材料整理、压缩或改写为可长期查阅的知识笔记,采用教科书、技术手册或标准说明文风格,并保留事实、公式、适用条件、安全警告和参考资料。适用于用户要求整理 Obsidian 笔记、消除聊天或 AI 写作痕迹、减少重复和空话、统一术语与技术表达,或将技术原理、操作方案改写为结构化知识文档的任务。

整理知识笔记

工作流程

  1. 识别材料的核心问题、目标读者和材料类型。
  2. 提取事实、定义、公式、条件、因果关系、步骤、例证、边界、安全警告和参考资料。
  3. 删除与核心问题无关的铺垫,并合并重复内容。
  4. 按材料类型选择结构并重写全文。
  5. 检查技术准确性、术语、格式、重复和表达密度。
  6. 输出完整笔记;存在事实或技术疑点时,追加“待核实项”。

保留与删减

  • 保留原文中的事实、公式、适用条件、例外、安全限制和参考资料。
  • 不自行补充没有依据的结论,也不为缩短篇幅而删除必要条件或公式推导。
  • 围绕核心问题组织内容,删除无关铺垫。
  • 使每句话至少承担一种功能:定义概念、说明条件、解释因果、给出步骤、提供例证或指出边界。
  • 使同一知识点只完整解释一次。避免在摘要、正文、表格、总结和检查表之间复述。
  • 在不损失必要信息的前提下,默认将篇幅压缩约 30%;若用户另有篇幅要求,以用户要求为准。

语言规范

  • 使用中性、准确、简洁的书面语。
  • 直接陈述内容,不添加聊天式过渡、开场铺垫、段末复述或写作过程说明。
  • 删除情绪化、评价性、劝导性、宣传性和表演式表达,如“非常美妙”“加分项”“更稳妥”“请仔细看”。
  • 不使用反问、口号、拟人化表达或用感叹号制造重点。
  • 减少“通常、可能、建议、优先、具体来看”等模糊限定词。确有不确定性时,明确不确定性的来源和适用条件。
  • 每段只表达一个主题;能用一句话说明的内容不扩写成多句。
  • 将评价句改写为“条件、机制、结果”或“对象、操作、限制”。

技术表达

  • 首次出现专业术语时给出简短定义,后文统一名称。
  • 明确符号、变量、单位、对象类型、参考系、输入输出和变换方向。
  • 区分严格定义、直观解释和示例,不用比喻替代定义。
  • 每个概念最多保留一个必要的例子或比喻;使用比喻后,以正式术语重述结论。
  • 检查概括的适用范围,将无条件的“X 代表 Y”改为带条件的准确表述。
  • 不擅自修正不确定或可能有误的技术内容,将其列入“待核实项”。

结构选择

根据材料类型采用下列骨架,并按实际内容删去不需要的章节。

技术原理类

  1. 问题或目标
  2. 符号与定义
  3. 原理或推导
  4. 示例
  5. 适用条件与限制
  6. 简短结论

操作与方案类

  1. 目标与适用范围
  2. 基本原则
  3. 操作步骤
  4. 分类处理
  5. 安全边界
  6. 检查表

不要同时保留内容重复的“摘要”“重新解释”“具体调整”和“总结”。摘要已经给出结论时,正文只提供依据和展开。

格式规范

  • 使用描述性标题,避免“到底是什么”“究竟该怎么做”等口语化标题。
  • 保持标题编号连续、层级一致。
  • 仅对首次定义的术语、关键条件和禁止事项使用粗体。
  • 减少引号和括号,统一数学符号、变量格式和单位格式。
  • 保留适合 Obsidian 的 Markdown、YAML frontmatter、Wiki-links、表格、公式和代码块;除非用户要求,不改变其语义。

完成检查

  • 检查同一结论是否出现在两个以上位置,只保留信息最完整且位置最合适的一处。
  • 检查相邻段落能否分别用一句话概括;含义相同时合并。
  • 检查所有评价句是否已改为可验证的条件、机制、结果、操作或限制。
  • 检查技术概括、符号定义、事实和适用条件是否成立。
  • 检查内部链接、表格、公式、代码块、安全警告和参考资料是否完整保留。

输出

  1. 先输出整理后的完整笔记。
  2. 仅在存在技术或事实疑点时追加“待核实项”,逐条列出疑点。
  3. 不解释改写过程,不输出修改心得,不复述本技能的要求。