| name | update |
| description | 更新已有笔记。支持两种模式:insert(插入新内容,匹配现有排版)和 refresh(刷新过时内容,可选 mini collect→curate→write 研究循环)。触发时机:用户要求修改、添加或更新已发布的笔记时。 |
Skill: update(笔记更新)
触发时机
用户要求修改、添加或更新已发布的笔记时。
输入
- 目标笔记路径(
3-published/ 或用户指定路径)
- 用户提供的新内容(insert 模式),或要刷新的章节名(refresh 模式)
执行步骤
Step 1: 读取并分析目标笔记
- 读取目标笔记完整内容
- 解析 YAML frontmatter:提取
type(concept/practice/compare/cheat-sheet)、tags、created、updated
- 识别笔记的章节结构(标题层级、Callout 类型、表格格式等)
- 确定笔记使用的模板类型,了解其章节约定
Step 2: 确认更新模式
用户提供了具体内容 → INSERT 模式
- 确认插入位置:用户指定章节名、或 "追加到末尾"
- 如果是替换:用户指定要替换的章节 → 进入 Step 3(替换该章节内容)
- 如果是新增:用户指定插入位置 → 进入 Step 3(在该位置插入)
用户要求刷新过时内容但未提供新内容 → REFRESH 模式
- 确认要刷新的章节
- 询问用户:"直接替换此章节,还是先重新搜集资料?"
- 选择直接替换 → 用户提供新内容 → 回到 INSERT 模式
- 选择重新搜集 → 进入 Step 2b
Step 2b: Mini 研究循环(仅 REFRESH 模式需要)
范围限定在该子主题,不重新搜集整个笔记的资料。
目录隔离:Mini 循环写入 0-inbox/{subtopic}/、1-curated/{subtopic}/、2-drafts/{subtopic}/,与父主题目录分离。更新完成后可保留作为参考或手动清理。
传递父主题上下文:调用各技能时,需传入父笔记信息:
- 父主题名(如 "React")
- 父笔记类型(concept/practice/compare/cheat-sheet)
- 目标章节的标题层级(如
###)
- 父笔记中观察到的格式约定(Callout 类型、表格风格等)
执行步骤:
-
调用 /collect,{topic} 设为子主题名(如 "useEffect cleanup"),搜索词需附加父主题上下文(如 "React useEffect cleanup pattern 2025"),确保搜索结果既有针对性又不脱离父主题背景
-
调用 /curate,仅整理新搜集的资料,按四维度评分
-
调用 /write,必须要求只生成目标章节的正文内容:
- 不要生成 YAML frontmatter —— 这些内容将被插入已有笔记
- 不要生成完整笔记结构(如标题、概述、总结等)—— 只写该章节的正文段落
- 保留父主题上下文:在提示中说明 "这是 {父主题} 笔记中 {章节名} 章节的内容更新"
- 匹配格式约定:告知 write 父笔记中使用的 Callout 类型、表格风格等
-
产出:纯章节正文 → 进入 Step 3 插入父笔记
Step 3: 最小改动插入
核心原则:只改需要改的部分,不动其余内容。
- 匹配格式:观察目标位置周围的格式约定
- 同级标题使用相同层级(如
###)
- 如周围有 Callout 块,新内容也用相同类型
- 如笔记用表格呈现对比数据,新内容也用表格
- 代码块标注相同语言
- 保持结构:不破坏现有标题层级,不越级
- 保留双链:不动现有
[[wikilinks]],新内容中的概念添加双链
- 更新 frontmatter:将
updated 字段设为当前日期
- 不重新美化整篇:不触碰不相关的章节
Step 4: 验证
- 读取修改后的章节,确认插入位置正确
- 检查标题层级是否仍然连贯(不越级)
- 抽查现有双链是否完整(至少检查 3 个)
- 向用户展示 diff 摘要(修改了哪个章节、新增/替换了多少内容)
- 用户确认 → 写入
产出
- 原笔记文件(in-place 更新)
updated 字段已更新的 frontmatter
禁止行为
- 不要重新格式化整篇笔记 —— 只动需要改的部分
- 不要修改不相关章节的内容
- 不要删除或破坏现有的
[[wikilinks]]
- 不要改变笔记的 template type(如把 concept 改成 practice)
- 不要在 INSERT 模式下添加用户未提供的信息
- 不要在 REFRESH 模式下对不相关的章节启动完整研究循环
硬停止 (Hard Stop)
本阶段任务完成。向用户展示 diff 摘要(修改了哪个章节、新增/替换了多少内容)。
确认前不得继续。等待用户明确确认或要求修改。