为什么你的 Skill 库越堆越乱：用「Diff 笔记法」给存量做减法

**适用场景：** 你已经收藏或写了不少 skill（提示词、工作流、脚本），但经常记不清哪个版本能用、哪个早就过期了，翻找一次要花十分钟以上。

---

问题：Skill 库的「只进不出」

大多数人管理 skill 的方式是单向的：

1. 遇到好用法 → 存一份

2. 用法升级 → 再存一份（旧的懒得删）

3. 三个月后 → 同名文件 3 个，版本全靠文件名猜

结果就是：skill 库名义上是「资产」，实际上是「垃圾场」。真正动手用之前，你得先做考古——翻目录、打开比对、回忆当时为什么改过，一回合下来十分钟就没了。更要命的是「不敢删」：万一哪天又用上了呢？于是废弃版本永久驻扎在你的库里。

什么是 Diff 笔记法

每两周（或每次大版本更新时）对 skill 库做一次「差量盘点」，只记录**变化**，不重写全库。每次盘点产出一篇不超过 20 行的 diff 笔记，固定四段：

- **新增**：本周加了什么 skill，一句话说清触发条件（什么情况下该用它）

- **替换**：哪个旧 skill 被新版取代，旧版标记 `deprecated` 并写明「什么时候别再用」

- **删除**：直接移除，只留一行「删了什么 + 为什么删」

- **不变**：什么都不写

笔记归档在 skill 库根目录，可以是一篇滚动 `CHANGELOG.md`，也可以按月一篇（`diff-2026-08.md`）。关键规则：**只记差量**。三个月后的你（或同事）翻笔记，应该能在 30 秒内看懂「这段时间库变成了什么样」。

何时该用

- 你的 skill 超过 15 个，且存在同名或近名文件（`prompt-v2-final-实际是v3.md` 这类）

- 你发现自己在「找对版本」上花的时间，已经超过「用 skill」本身

- 多人共用一个 skill 库——这时 diff 笔记同时充当版本说明和交接文档

- skill 依赖外部工具，而工具升级会悄悄让旧写法失效

何时不该用

- 库只有 5 个以内 skill —— 一张清单就够了，别上流程

- 你的 skill 已在严格版本化的 git 仓库里 —— 用 git log、tag 和 PR 更专业，diff 笔记是重复造轮子

- 还在「野蛮生长期」—— 先跑两三个月积累真实痛点，再引入方法；太早引入只会制造仪式感

操作清单（单次盘点，15 分钟内）

1. 列出全库 skill 清单（文件名即可，别打开内容）

2. 逐个问三个问题：最近一次用是什么时候？现在有没有替代品？下次会用哪个版本？

3. 把答案归类到 新增 / 替换 / 删除 / 不变

4. 写 diff 笔记；给被替换的旧文件在文件头加标记：`⚠️ DEPRECATED: 已被 xxx 替代，2026-08-16`

5. 保存/提交。deprecated 满两周无人申诉，直接删除

常见坑

- **写成流水账**：diff 笔记不是日志。「不变」的绝对不要写，否则下次盘点没法读，笔记本身变成新的垃圾

- **只替换不删除**：废弃文件留在原地才是混乱之源。标记是第一步，删除才是目的

- **频率太高**：每周做会变成新的负担。双周或月度是合理节奏，太勤说明库本身还没稳定

- **团队共用库但只有一个人盘点**：diff 要进共享仓库并走 review，否则等于没做——别人不知道你的 diff，就会基于旧版本继续堆新文件

- **笔记和库不同步**：删文件时忘了同步 diff 笔记（或反过来）。两者同一次提交完成，是最省事的纪律

一句话总结

Skill 库的价值不在数量，在「打开就能用对的那个」。Diff 笔记法让你每次花 15 分钟维护这件事，而不是每次用的时候花 15 分钟考古。