当 Skill 遇到"保鲜期"：技能自迭代的工程实践

最好的 Skill，是会自己进化的 Skill。

一个让我警醒的时刻

上个月，我信心满满地向同事展示自己精心打造的代码审查 Skill。

“看，它会自动检查命名规范、识别潜在 bug、生成审查报告。”

同事试用了一下，皱起眉头：“它怎么还在检查 var 声明？我们三个月前就全面切 let/const 了。”

我愣住了。

这个 Skill 我花了两周时间打磨，当时确实很好用。但三个月后，它已经在检查一个根本不存在的问题，同时漏掉了团队新引入的 TypeScript 严格模式规范。

Skill 不是写完就结束的产品，它是有"保鲜期"的活文档。

这个认知促使我思考一个问题：如何让 Skill 持续进化，而不是慢慢腐烂？

What：什么是 Skill 自迭代

Skill 自迭代，是指 Skill 能够基于实际使用反馈，持续更新和完善自己的能力。

这不是让 Skill 自己修改自己（那太科幻了），而是建立一套反馈-分析-改进的闭环机制：

使用 Skill → 收集反馈 → 分析问题 → 更新 Skill → 再次使用

与"一次性创建"模式的对比：

维度	一次性创建	自迭代模式
生命周期	创建即定型	持续演进
反馈处理	堆积或忽略	结构化吸收
质量趋势	逐渐过时	越用越好
维护成本	集中式大改	分散式微调

Skill 的真正价值不在于创建的那一刻，而在于它能陪你走多远。

Why：为什么 Skill 必须能自迭代

问题一：环境在变，Skill 会过时

项目在演进，技术栈在升级，团队规范在调整。一个月前正确的检查规则，可能现在已经是错误的。

我的代码审查 Skill 就是典型案例：它还在检查 ES5 语法，而项目早已全面拥抱 ES2020+。

问题二：需求会暴露，Skill 有盲区

没有哪个 Skill 能在第一版就覆盖所有场景。只有在真实使用中，才会发现：

• 漏掉了某个重要检查点
• 输出格式不够实用
• 某个步骤顺序不对

这些不是设计失误，而是必然会出现的认知盲区。

问题三：用户会反馈，但反馈容易丢失

最有价值的改进信号藏在用户的日常反馈里：

• “这个不太对…”
• “应该是这样…”
• “你漏了…”

但这些碎片化的反馈，如果不及时捕获和处理，很快就会淹没在对话历史中。

Skill 的腐烂不是一瞬间发生的，而是在无数个"算了，下次再改"中逐渐累积的。

How：如何实现 Skill 自迭代

答案是建立一套结构化的复盘机制。我把它封装成了一个专门的 Skill：skill-review。

核心工作流程

回顾对话 → 提取负反馈 → 分析迭代方向 → 生成待确认清单

第一步：回顾对话，识别 Skill 使用情况

扫描当前对话的全部内容，回答三个问题：

1. 调用了哪些 Skill？
2. 每个 Skill 产出了什么？
3. 用户对产出的反馈是正面还是负面？

这一步的目的是建立事实基础，而不是急于改进。

第二步：提取负反馈，捕获改进信号

负反馈是 Skill 迭代的燃料。需要识别这些信号：

反馈类型	典型表述	含义
直接否定	“不对”、“不行”	结果错误
修正意见	“应该是…”、“改成…”	需要调整
质疑	“真的吗？”、“确定？”	可能有问题
补充要求	“还要加上…”、“漏了…”	覆盖不全

关键技巧：记录用户原话。

不要急于总结或归纳，保留原始表述能帮助后续准确理解问题本质。比如：

用户说："生成的测试用例没有覆盖边界条件"

这比"测试不够全面"要精确得多——问题不是数量，而是边界覆盖。

第三步：分析迭代方向，分类处理

不是所有反馈都需要改 Skill。根据反馈性质，分三类处理：

A. 需要更新现有 Skill

• 问题指向 Skill 的某个具体步骤或规则
• 可以通过增加检查点、修改格式、调整流程解决
• 属于该 Skill 的职责范围

示例：用户反馈"API 文档没有包含错误码说明"→ 修改文档生成 Skill 的输出模板

B. 需要新建 Skill

• 发现了一个完整的新工作流
• 现有 Skill 都覆盖不了这个场景
• 这个方法论可以复用（不是一次性的）

示例：用户反复需要"将复杂函数拆分成多个小函数"→ 新建代码重构 Skill

C. 不需要改动

• 一次性的特殊情况
• 用户个人偏好，不具普遍性
• 属于内容问题，不是方法问题

示例：用户说"这个变量名换成驼峰式"→ 不改 Skill，下次指定命名风格即可

区分"内容问题"和"方法问题"，是避免 Skill 臃肿化的关键。

第四步：生成迭代清单，等待确认

把分析结果整理成结构化的待办清单：

## 现有 Skill 更新：
- [ ] API 文档生成 Skill：新增"错误码说明"输出段落
- [ ] 单元测试 Skill：增加边界条件检查提示

## 新建 Skill：
- [ ] 新建 code-refactor Skill（代码重构辅助）

为什么要"待确认"？因为人是最终决策者。

自动生成的建议可能有误判，可能优先级排错，可能遗漏上下文。让用户确认后再执行，既保证了自动化效率，又保留了人类判断力。

实践建议：让自迭代成为习惯

建议一：固定复盘节点

不要等问题堆积。建议在以下时机触发 skill-review：

• 每周结束时
• 某个 Skill 密集使用后
• 收到明确负反馈后

建议二：优先级排序

不是所有改进都值得立即执行。优先级判断：

影响产出质量 > 影响执行效率 > 影响输出格式

一个导致错误结果的 bug，比一个让输出不够美观的格式问题重要得多。

建议三：保持 Skill 的"单一职责"

如果一个 Skill 需要频繁大改，可能是它承担了太多职责。考虑拆分成多个小 Skill，每个专注做好一件事。

建议四：记录迭代历史

在 Skill 文件中保留一个简单的 changelog：

## 迭代记录
- 2026-01-15：新增边界条件检查规则（来源：用户反馈#12）
- 2026-01-10：API 文档增加错误码段落（来源：团队规范更新）

这不仅是记录，更是未来复盘的素材。

总结

Skill 不是静态的工具，而是动态的知识载体。

它的价值不在于第一版有多完美，而在于能否建立起持续进化的能力。通过结构化的复盘机制——回顾使用、提取反馈、分析方向、生成清单——我们可以让 Skill 越用越好，而不是越用越旧。

写 Skill 是一次性投入，让 Skill 自迭代是持续收益。

参考来源

• 方法论参考：skill-review/SKILL.md
• 实现思路：Claude Code Skills 生态实践