我做了一个修 Skill 的 Skill

我最近干了一件有点“反直觉”的事：给自己做了一个“修工具的工具”。

起因其实很小。

我昨天刚把 wechat-writer 重构了一轮我把 11 个 AI 员工全裁了，只留了 1 个，跑起来之后发现有几个地方不顺：输出格式有瑕疵、流程步骤有遗漏，属于那种“用一次就会想顺手修掉”的小问题。

于是我顺口跟 AI 说：帮我改一下这里、这里，还有这里。

它很认真地点了点头，然后转身去改了……这次生成出来的文章文件。

更具体一点：我看到它动的是 02_Draft.md 这种“产物”，而不是 SKILL.md 这种“工具”。光标在正文里闪，改动也开始出现在正文里。

我盯着屏幕愣了两秒，突然意识到：这不是它笨，是我给了一个天然会被误解的指令。

“改 这里、这里还有这里”，在它眼里，很容易等价成“改你刚刚让我生成的东西”。

而我想要的，是去动 SKILL.md、去动脚本、去动规范，而不是动这次的产物。

这类误会，修一次不难。

难的是：你会在未来的一次次维护里，不停地重演它。

---

维护为什么会越来越累

写一个 skill 的成本，很多时候是一次性的。

但维护它，是复利。

每次你发现一个小问题，手上都会重复同一套动作：

先定位文件在哪。

再翻上下文，确认这个地方到底该怎么改。

改完还要验证，有时候还得顺手把版本号加一下，免得下次不知道自己改过什么。

这些动作本身，并不“创造新东西”。

它更像是你在做一份长期兼职：一直在给自己的系统打补丁。

我自己就很典型：为了把 wechat-writer 修顺手，我一路从 3.0.2 改到了 3.0.9。看起来像“更新很勤快”，其实全是这种零碎的小修小补。

我当时脑子里冒出来一个念头：

既然这些动作每次都一样，那它就应该被流程化。

而流程化的东西，就该被 skill 化。

---

我做的这件事：用 skill 管 skill

我给它起了个名字，叫 skill-updater。

它不负责写文章，也不负责生成内容。

它只负责一件事：当我用完某个 skill 之后，如果我对这个 skill 有反馈，它帮我把反馈变成一次“可控的更新”。

这里有个关键词：可控。

我不想要那种“它看懂了就直接改”的自动化。

我想要的是：先把修改计划展示出来，我确认后它再动手。

不然我宁可它别自动。

我只需要把“我不爽的地方”说出来，它把剩下的脏活累活接走。

比如我说一句「这个步骤写得容易让人误会」，它不会立刻去改正文，而是先把“准备动哪里”列出来：要改哪个 SKILL.md、可能还要动哪份规范文件，然后问我一句：确认执行吗？

---

你可以直接复制这段提示词发给 AI

如果你也想做一个类似的元技能，其实不用从头拆解。

下面这段就是我当时用的提示词，直接丢给 AI，让它按这个要求去创建即可。

我当时是在 Claude 的技能环境里，直接调用 /skill-creator 这个元技能来做这件事。

如果你没有这个命令，也没关系：你就把这段当成一份“需求说明”发给 AI，让它按你自己的技能体系/目录结构去生成对应的文件就行（路径按你的环境改一下）。

用 skill-creator 帮我创建一个自更新的 skill 吧，以后我用这个 skill 来做 skill 本身的 update，免得你理解错我的意思。

要求：
1. 先搜索 .claude/skills/ 里现有的 SKILL.md，学习格式
2. 这个 skill 的作用是：当我用完某个 skill 后，能收集我的反馈，自动更新到那个 skill 里
3. 触发方式：/自更新
4. 执行逻辑：
   - 搜索我最近使用的 skill
   - 对比这次的使用过程，看哪里可以优化
   - 找到对应位置，更新进去

这个自更新 skill 请放到全局目录去，这样我在任何一个项目就都可以用

在此，要特别感谢公众号“AI 产品自由”提供的思路和提示词。

---

它为什么能避免“理解错”

我后来发现，AI 不是不懂“你要改 skill”。

它是不知道：你说的“改”，到底是改产物，还是改工具。

只要你没有把“更新对象”和“操作边界”写死，它就会用它的默认理解去补全。

而 skill-updater 做的事情，其实就是把边界钉牢：

• 它先问清楚目标是哪个 skill
• 它先告诉你要改哪些文件、改哪里
• 它要求你确认

这三步一加，误会会明显变少。

我更喜欢把它理解成：我给 AI 加了一个“刹车踏板”。

---

实战：我拿它修 wechat-writer

skill-updater 写完之后，我第一件事就是拿它去修 wechat-writer。

因为那套系统我用得最多，问题也暴露得最快。

有些改动看起来琐碎，但都是“用一次就会被绊一下”的那种：

• 标题不只是给 4 个方向，还要同时产出 slug，不然发布时总会漏
• published 文件的格式，前后多一个空行都不行（公众号排版很挑剔）
• 归档必须是“移动不是复制”，不然 To-be-used/ 里会残留一堆项目垃圾
• _source/ 的规则要明确，不然素材散落，回头复盘找不到
• 引用旧文要统一用 [[标题]]，不然链接会越写越乱

这些东西，如果靠“记忆”去守，很快就会漏。

但如果你把它写进流程里，就会像护栏一样，默默把你推回正确的路上。

（这块如果你想看我之前怎么搭 skills/软链接，可以顺手翻旧文：在Claude Code 里用 Skills 要付费？那我用 Gemini CLI 免费白嫖。）

---

说到底，我是在做一件很“省心”的事

我以前总觉得，工作流的进化应该是“加功能”。

后来才发现，真正省心的进化，是“降低维护成本”。

你有了一个能持续修补的机制之后，很多系统上的焦虑会自然下降：

它不需要完美。

它只需要能被持续修好。

如果你也在搭自己的 AI 写作/开发/运营流程，我的建议很朴素：

先别急着扩功能。

先给自己做一个“修工具的工具”。

从“展示修改计划 → 用户确认 → 版本追踪”这三件事开始，就够了。

---

附：skill-updater 的 SKILL.md（可直接复制）

不同工具/环境的技能目录可能不一样。

如果你用的是 Claude Code，我个人习惯放在 ~/.claude/skills/；如果你有项目内 skills，也可以再用软链接接入。

不懂这些也没关系，你先把内容保存出来，跑起来再慢慢调。

提醒一句：下面这份 SKILL.md 里提到的 references/、scripts/ 之类目录，不是每个 skill 都必须有。目标 skill 有就读、没有就跳过，核心是流程本身。

---
name: skill-updater
description: "当用完某个 skill 后，用于收集反馈并自动更新该 skill。触发方式：/自更新 或 /skill-update。这个 skill 会分析最近使用的 skill，对比使用过程中暴露的问题，找到对应位置并更新进去。"
---

# Skill 自更新工作流

## 概述

这是一个元技能（Meta-Skill），用于在使用其他 skill 后，收集反馈并将改进点自动更新到对应 skill 中。确保「单一来源」原则——同一信息只在一个地方维护。

## 触发条件

- 用户输入 `/自更新` 或 `/skill-update`
- 用户在使用完某个 skill 后，提出改进意见

## 工作流程

### Step 1: 识别目标 Skill

1. 检查当前对话历史，识别最近使用的 skill
2. 如果无法确定，询问用户：「你想更新哪个 skill？」
3. 定位该 skill 的文件路径：
   - 全局：`~/.claude/skills/[skill-name]/`
   - 项目内：`[project]/Skills/[skill-name]/` 或 `.claude/skills/[skill-name]/`
4. 如果是符号链接，追踪到真实路径

### Step 2: 收集反馈

向用户确认需要更新的内容，按类型分类：

| 类型 | 描述 | 更新位置 |
|:---|:---|:---|
| **流程问题** | 工作流步骤缺失或顺序不对 | SKILL.md 主体 |
| **输出格式** | 生成的文件格式不符合预期 | SKILL.md 或 references/io_schema.md |
| **脚本问题** | Python 脚本有 bug 或逻辑错误 | scripts/*.py |
| **参考资料** | 缺少必要的参考文档 | references/*.md |
| **风格规范** | 写作风格或用词不符合预期 | references/style_guide.md |

### Step 3: 定位修改点

1. 读取目标 skill 的 `SKILL.md`
2. 如需要，读取相关的 `references/` 或 `scripts/` 文件
3. 根据反馈类型，定位需要修改的具体文件和位置
4. 如果涉及多个文件，列出所有需要修改的位置

### Step 4: 展示修改计划

向用户展示：

```
📋 修改计划

目标 Skill: [skill-name]
当前版本: [version]

修改 1: [文件路径]
- 位置: [具体段落/行号]
- 原内容: [摘要]
- 新内容: [摘要]

修改 2: ...

确认执行？(Y/n)
```

### Step 5: 执行更新

1. 获得用户确认后，逐一执行修改
2. 如果 SKILL.md 的 frontmatter 中有 `version` 字段，自动递增补丁版本号
3. 保存所有修改

### Step 6: 验证更新

输出更新摘要：

```
✅ 更新完成

Skill: [skill-name]
版本: [old] → [new]

已修改文件:
- SKILL.md (流程步骤)
- references/io_schema.md (输出格式)

主要改动:
1. [改动描述 1]
2. [改动描述 2]
```

## 关键原则

- **单一来源**: 同一信息只在一个地方维护，避免多处修改导致不一致
- **最小改动**: 只改必要的部分，保持 skill 的稳定性
- **用户确认**: 所有修改必须经过用户确认才执行
- **版本追踪**: 每次更新都应递增版本号

## 常见更新场景

### 场景 1：输出格式不对

```
用户反馈：「生成的 published 文件里缺少 slug 字段」

定位：
→ SKILL.md 中的「归档」步骤
→ 或 references/io_schema.md 中的输出规范

修改：
→ 添加 slug 字段的生成要求
→ 说明 slug 应在「标题确定」时一并生成
```

### 场景 2：流程步骤缺失

```
用户反馈：「标题应该有 4 个维度：情绪型/共鸣型/数字冲击型/反常识型」

定位：
→ SKILL.md 中的「标题生成」步骤

修改：
→ 更新标题维度定义
→ 删除旧的「悬念流/对仗流/教程流」描述
```

### 场景 3：代码块格式问题

```
用户反馈：「prompt 代码块用 ```prompt 标记后没法直接复制」

定位：
→ SKILL.md 中的「视觉设计」步骤
→ 或 references/io_schema.md 中的 prompt 格式规范

修改：
→ 改为使用无标记的 ``` 代码块
→ 在代码块外用标题标注类型
```

### 场景 4：脚本 bug

```
用户反馈：「visualize.py 识别不到 prompt」

定位：
→ scripts/visualize.py

修改：
→ 检查正则表达式
→ 修复关键词匹配逻辑
```

## 注意事项

- 修改前确认文件的真实路径（处理符号链接）
- 对于大型改动，建议用户先在测试项目中验证
- 如果用户的反馈涉及多个 skill，逐个处理