会自己长本事的 Skill
同一类任务，AI 总在同一个地方栽跟头。与其每次都人工去补规则，不如让 Skill 自己记下错题、定期复盘、反过来改写自己的检查清单——这篇把这套「自进化」方案从思想、原理到工程落地讲透。
一个永远在同一处摔跤的助手
你精心写了一份 Skill，它第一周表现惊艳，可第十次跑同类任务时，还是漏掉了那个老问题 你能感觉到它「哪里容易出错」，但每次都得你亲自去翻、去改 SKILL.md，谁来替你做这件事？
Skill 解决了「让 AI 一次就照规矩办事」，但没解决「让规矩自己变得更好」。
先把场景说具体。假设你写了一份「把文章排成网页」的 Skill，里面有十几条规则：标题怎么取、图怎么配、引用怎么标。前几次它干得不错。但跑得多了，你开始注意到一些反复出现的小毛病——中文标点后面老是多一个空格、长表格在手机上溢出、参考链接偶尔编造。每一次你都皱皱眉，手动改一下交付物，然后……就过去了。下一次同样的坑，它又踩一遍。
问题的根子在于：这些教训没有被「沉淀」下来。它们留在你的脑子里、留在一次次被你默默修正的产物里，唯独没有回流到那份 Skill。Skill 本身是一份静态的文档——你不动它，它永远停在第一天的水平。AI 不会因为「上次错了」就在下次自动长记性，因为它根本不记得上次。
这正是近来 AI agent 工程社区里兴起的一套做法——Skill 的自进化：给 Skill 配上独立的质检环节、让教训以文件形式留痕、定期回看提炼规律、再把规律反哺回 Skill 本身。Anthropic 官方的 skill-creator 插件也内置了这套迭代思路的工具化版本。本文就沿着三个层次把它讲清楚：先弄懂 Skill 这个载体（第 02 章），再拆解自进化的四步闭环和它的三本台账（第 03–04 章），然后从第一性原理和学术谱系回答「为什么这套真的有效」（第 05 章），最后落到 Claude Code 的具体工程实现、社区里的不同流派，以及它的边界（第 06–08 章）。
Skill 解决的是「按规矩做」，自进化解决的是「让规矩自己进步」。
先弄懂 Skill 本身
要让 Skill「改自己」，得先知道它长什么样、AI 是怎么读它的。这一节是地基，理解了它，后面「为什么改 SKILL.md 就能改变 AI 的行为」才说得通。
一个 Skill，本质上就是磁盘上的一个文件夹，里面有一份 SKILL.md，外加可选的脚本、模板、参考文档。SKILL.md 的开头是一段 YAML 元数据（frontmatter），其余是给 AI 看的 Markdown 指令。Anthropic 官方把它定义为「一种轻量、开放的格式，用专业知识和工作流扩展 AI agent 的能力」。
--- name: web-article description: 把文章排成可分享的网页。当用户要把 URL/文稿做成 HTML 长文时使用。 allowed-tools: Read, Write, Bash # 激活时免询问可用的工具 --- # 正文是给 AI 看的工作说明书 # 步骤、规则、检查清单都写在这里 —— 自进化要改的，主要就是这部分
关键不在于这个格式多简单，而在于 AI 怎么消费它。Skill 用的是一种叫渐进式披露（progressive disclosure）的机制——像一本组织良好的手册：先看目录，需要时再翻具体章节，最后才查附录。AI 不会把整个 Skill 一股脑塞进上下文，而是分三层按需加载。
这里有两个细节对自进化至关重要。其一，description 字段决定了 AI 什么时候会想起用这个 Skill——它要同时说清「做什么」和「何时用」，写得含糊就触发不准。其二，第 3 层的脚本和参考文档可以无限增厚而几乎不花 token。这意味着：错题本、检查清单、历史教训，完全可以作为外挂文件长期堆积，需要时才让 AI 去读。Skill 天生就为「沉淀知识」预留了空间。
自进化的四步闭环
地基铺好，来看核心。社区实践和 Anthropic 官方的迭代建议不约而同地收敛到一套闭环：质检 → 落档 → 回看 → 反哺，然后回到 Skill 本身，开始下一轮。我们一步步走。
第一步 · 设一个独立的 SubAgent 质检环节
关键词是独立。不是让那个干活的 AI 自己检查自己，而是另起一个子 agent（SubAgent），在干净的上下文里、带着「挑刺」的任务去审查产物。为什么要独立？因为干活的那个 AI 已经被自己的思路「带跑」了——它倾向于认为自己做得对，正如学生很难发现自己作文里的错别字。换一双没有先入之见的眼睛，才看得见真问题。这一点第 05 章会从原理上展开。
第二步 · 把质检与修复记录落到本地文件
所有关键点的质检审查和修复记录，都落到本地的 Markdown 文件里。社区实践中常见的命名是 first-spread-review.md、final-review.md、repair-log.md——分别对应「初稿铺开时的审查」「终稿审查」「修复日志」。这些文件就是那本错题本：哪一步检查了、发现了什么、怎么修的，全部留痕。
第三步 · 同类任务跑多了，回看这些记录
单次记录没什么用，积累才有价值。当同一类任务跑过很多次，Agent 可以回过头读这些台账，做一件人类复盘时做的事：找规律——之前哪些环节最容易出问题？是不是总在「配图」这一步翻车？是不是某类输入反复触发同一个 bug？
第四步 · 把沉淀的问题反哺给 Skill
这是闭环真正「进化」的一步。把回看中发现的高频问题，反过来去优化 Skill 的规则、检查清单和默认策略：给那个老出错的环节加一条强制检查、把踩过的坑写成一条明确禁令、把验证过有效的做法升级成默认行为。改完之后，Skill 就带着新长出的本事进入下一轮——于是它随着真实任务持续进化。
为什么是闭环，而不是一条直线？因为「改完一次」绝不是终点。新的规则上线后，会暴露出新的、更深一层的问题；错题本继续记，下一轮复盘继续提炼。每转一圈，Skill 的能力边界就往外扩一点。这跟一次性「把 Skill 写好」有本质区别——它把「变好」这件事，从一次性的人工劳动，变成了一个自动运转的过程。
不是写一份完美的 Skill，而是造一台让 Skill 持续变好的机器。
三本台账，各记什么
闭环的心脏是那几个 Markdown 文件。它们叫什么名字不重要，重要的是各自承担什么角色。把它们想成错题本的三个分册：一份是「过程巡检单」，一份是「终检报告」，一份是「错题与对策」。下面这张表是它们的分工。
| 文件 | 角色 | 记什么 | 怎么记才有用 |
|---|---|---|---|
| first-spread-review.md | 过程巡检 | 初稿/铺开阶段的审查：结构是否完整、信息是否遗漏、方向对不对 | 趁早抓大问题，避免错误被一路带到终稿 |
| final-review.md | 终检报告 | 交付前的最终质检：逐条核对检查清单，每项给「通过 / 不通过」 | 用二元判定，不打模糊的分数 |
| repair-log.md | 错题与对策 | 每次发现的问题 + 根因 + 怎么修的，带时间戳 | 记根因而非现象，才能复盘出规律 |
| learnings.md （社区常见） | 沉淀的口诀 | 从修复日志里提炼出的、已验证有效的规律和规则 | 时间倒序、短、具体、可执行 |
前三者为社区自进化实践中的常见命名；learnings.md 是另一种流行的「学习日志」分册，作用是把零散修复提炼成稳定规则，被多个开源框架（如 Singularity-Claude、AutoResearch）采用。
这里有一条贯穿所有成熟实践的关键原则：用二元判定，别用打分。让 AI 给自己的产物打「3 分还是 4 分」是不可靠的——它无法稳定区分这种主观刻度，今天 3 分明天 4 分，记录就失去了意义。改成一条条「通过 / 不通过」的硬性检查，含义清晰、可以自动化、也难以糊弄。这正是 final-review.md 该长的样子：
# 终检 — 2026-06-23 · 任务 #12 [PASS] 所有参考链接真实可访问，无编造 [PASS] 中文标点后无多余半角空格 [FAIL] 宽表格在 375px 视口下溢出 ← 触发一次修复 [PASS] 深色模式下 SVG 文字不丢色
而 repair-log.md 要记的不是「我把表格修好了」，而是根因——为什么会溢出、属于哪一类问题。只有记到根因，第三步回看时才能把零散的 FAIL 归并成「响应式溢出是本 Skill 的高频弱项」这样的判断，进而在第四步给 Skill 加一条针对性规则。
## 2026-06-23 · 表格溢出 现象: 宽对比表在窄屏横向溢出，撑破布局 根因: 表格未包在可横滚容器里，且未设 min-width 修复: 外层加 .wraps 横滚 + 移动端 min-width 归类: 响应式溢出（本月第 3 次） ← 回看时的信号
为什么这套真的有效
方案听起来很朴素，但它能成立，背后有三条扎实的原理。讲清楚它们，你才知道哪些环节绝不能省、哪些是锦上添花。
其一 · 固定模型，进化的是「外部记忆」
自进化没有动模型一根毫毛。模型的权重是冻结的，变的只是它读到的指令和上下文。这就把「让 AI 变强」从「重新训练」这件昂贵的事，降维成「改几个文本文件」这件几乎免费的事。错题本是一份外部的、可更新的记忆——模型不变，但它每次开工前读到的「行前须知」越来越厚、越来越准，行为自然越来越好。
为什么这点是前提？因为它决定了自进化是「可负担」且「可频繁发生」的。如果每次改进都要微调模型，没人会去做第 50 次复盘。正因为代价只是写文件，这个闭环才能日复一日地转下去，靠的是积累的复利而非单次的突破。
其二 · 干活的人，不能是打分的人
第 03 章强调「独立 SubAgent」，原理就在这。让模型评判自己的输出，会形成一个危险的反馈环：它逐渐学会生成「听起来对」而不是「实际对」的东西，因为它既是运动员又是裁判。学术界对这点有清晰的认识——有效的自我纠正往往需要一个独立的、足够强的验证者，或者借助外部工具（运行测试、执行代码、查证事实）给出客观信号，而不是让模型空口自评。
其三 · 教训要从「现象」抽象成「规则」才能复用
第三本台账（learnings.md）和「回看找规律」这一步，对应的是另一条原理：临时的、任务专属的记录无法迁移。如果只是流水账式地记「这次这里错了」，下次换个任务就用不上。必须做一层抽象——把「这次表格溢出了」提炼成「凡宽表格都要做响应式处理」，把单点经验上升为可复用的规则。这正是回看环节的真正价值：它不是简单重读，而是归纳。
在 Claude Code 里落地
原理讲完，来看怎么真正搭起来。好消息是，Claude Code 把这套闭环需要的四块积木都提供了：独立子 agent、读写本地文件、生命周期 Hook、跨会话记忆。下面逐块对应到闭环的环节。
积木一 · 独立子 agent 做质检
对应闭环第一步。有两种写法。一是在 SKILL.md 的 frontmatter 里声明，让这个 Skill 直接跑在一个 fork 出来的干净上下文里：
--- name: web-article-review description: 独立质检网页文章产物，逐条核对清单并写入 final-review.md context: fork # 在独立子上下文里运行，不被主线思路污染 agent: Explore # 用只读探索型 agent，专注审查不乱改 ---
二是定义一个专门的质检 SubAgent（放在 .claude/agents/），给它只读权限、甚至换更强的模型来当裁判：
--- name: skill-qa description: 独立审查产物质量，逐条二元判定，输出失败项与根因 tools: Read, Grep, Glob, Bash disallowedTools: Edit, Write # 只许挑刺，不许动手改 model: opus # 裁判用更强的模型 --- 你是独立质检员。对照检查清单逐条判 PASS / FAIL， 对每个 FAIL 给出根因，写入 final-review.md 与 repair-log.md。
积木二 · 读写本地文件做落档
对应第二步。Skill 本就能调脚本、读写文件，所以让质检 agent 把结果追加到 final-review.md、repair-log.md 是天然能力。第 04 章的那两个文件，就是这一步的产物。
积木三 · Hook 做质量门和自动留痕
Hook 是 Claude Code 的生命周期钩子。两个对自进化特别有用：Stop Hook 在 AI 准备收尾时触发，可以当「质量门」——没跑质检就不许结束；PostToolUse Hook 在每次工具调用后触发，可以自动把改动记进日志，实现「无人值守的留痕」。
{ "hooks": { "Stop": [{ "type": "command", "command": ".claude/hooks/require-final-review.sh" }] } } # 脚本检查 final-review.md 是否全 PASS；否则 block，让 AI 回去补
additionalContext 向 AI「建议」去调用质检。此外 Stop Hook 连续拦截有上限（防死循环），别把质量门设成永远过不去。积木四 · Memory 让台账跨会话不丢
对应第三、四步的根基。回看需要历史，而对话一关，上下文就清空了。Claude Code 的两层记忆解决了这点：CLAUDE.md（你手写的长期规则，每次会话自动加载，压缩后还会自动重载）和自动 Memory（AI 自己写的、跨会话保留的发现）。把 learnings.md 提炼出的规则沉淀进 CLAUDE.md 或 Skill 自带的参考文件，下一轮开工就自动带上——错题本才真正「常驻」。
把四块积木串起来，就是一条完整的工程闭环：
还有一条官方路径 · skill-creator
如果不想全手搓，Anthropic 官方插件 skill-creator 提供了半自动化的迭代框架，正是这套闭环的工具化实现：Eval（把测试用例和「期望行为」写进 evals 文件，跑隔离子 agent 评分）→ Improve（分析失败日志，提出针对性改进）→ Benchmark（盲测对比改进前后、有无 Skill 的表现）。它把「质检—回看—反哺」做成了可复用的工具链。
同一思想的三种流派
「让 Skill 自进化」不是某一个人的独门秘籍，而是社区里多路人马不约而同走到的方向。它们内核一致（质检→落档→回看→反哺），区别在自动化程度和谁来按下「改 Skill」那个按钮。看清这三派，你能按自己的场景挑。
| 流派 | 代表做法 | 谁触发改进 | 适合谁 |
|---|---|---|---|
| 手动复盘派 | 独立 SubAgent 质检 + review/repair 台账，攒够了人工回看、亲手改 SKILL.md | 人，定期 | 追求可控、改动需把关的场景；起步成本最低 |
| 学习日志派 learnings loop | 每轮开工先读 learnings.md，结束自动把新教训写回，下次自动加载 | 半自动，每轮 | 同类任务高频重复、希望经验自动累积 |
| 评测驱动派 skill-creator / eval loop | 二元 evals + 隔离子 agent 盲评，跑分→改→再跑分，量化对比 | 工具链，按需 | 需要可量化、可回归验证的团队协作 |
三派并非互斥——常见的成熟做法是叠加：手动复盘定方向、学习日志做日常累积、评测框架做改进前后的把关。
三者其实是同一条光谱上的三个点，从「全人工」滑向「全自动」。但请注意：自动化程度越高，越需要可靠的验证信号来兜底。手动派靠人把关，出不了大错；全自动派一旦评测标准定得松或被模型「钻空子」，就可能朝错误方向「进化」。这就引出了最后一章——边界。
不同流派的差异不在「要不要进化」，而在「敢把多大的方向盘交给 AI」。
边界与误区
这套方法很实用，但不是银弹。下面几条是实践里最容易踩的坑，也是判断「这次该不该上自进化」的依据。
误区一 · 让模型自己给自己打分
前面反复强调过：自评不可靠，打分更不可靠。质检环节必须独立，判定必须二元。省掉独立 SubAgent、图省事让主 agent 顺手自查，等于让闭环从源头失真。
误区二 · 台账只记现象，不记根因
repair-log 里如果全是「修好了」「优化了」，回看时根本归纳不出规律，自进化就退化成一堆无用的流水账。记根因、记归类，复盘才有抓手。
误区三 · 台账无限膨胀，没人整理
错题本越记越厚，但如果从不提炼、从不合并重复项，它最终会大到没法读，反而拖慢每次开工。要定期把验证过的规律升级成规则、把过期的条目清掉——learnings.md 用时间倒序、保持短小，就是为此。
误区四 · 在不该用的地方硬上
自进化的价值来自重复。一次性的、再不会做第二遍的任务，攒错题本毫无意义。它真正发光的地方，是那些同类、高频、有明确质量标准的任务。
最后用一个交互小演示，直观感受「轮次累积」如何让 Skill 的通过率爬升——每点一次「再跑一轮」，就模拟一次「质检→落档→回看→反哺」，看高频错题如何被逐步消化。
参考资料
技术机制与官方说法核实于 2026-06-23，以 Anthropic 官方文档为准；理论谱系为公开发表的经典研究；社区实践来源于 GitHub 开源项目与技术博客。具体特性可能随版本更新，以官方最新文档为准。