夜雨聆风OpenClaw 这个 skill，为什么让那么多人上头？
你有没有这种感觉：
AI 最烦人的地方，往往不是不会做，而是同一个坑会反复踩。
昨天刚纠正过它一次，今天换个会话，它又像失忆了一样；上周刚总结出的经验，这周再来一遍，它还是得从头学起。
所以当我看到 OpenClaw 里的 self-improvement 时，第一反应不是“又一个 skill”，而是：
终于有人认真在解决 AI 不长记性这件事了。
这也是它最容易打动人的地方。很多 skill 做的是加法，给 AI 多装一个能力；但 self-improvement 处理的是更底层的问题：
AI 做过的事、犯过的错、被纠正过的地方，能不能真的留下来。
如果一句话概括这篇文章的结论，那就是：
self-improvement 最有意思的地方，不是让 AI 当场变强，而是把“犯错、复盘、沉淀、升级”做成了一套可落地的工程流程。
它为什么容易火？
因为它击中的不是一个小众需求，而是所有 AI 重度用户几乎都会遇到的痛点：
• 同一个坑，隔几天又踩一遍 • 同一种偏好，换个会话又得重新教 • 刚刚说清楚的规则，下一次又像没发生过
大多数 skill 解决的是“怎么让 AI 多做一点事”，比如联网、抓页面、调用工具、生成代码。self-improvement 解决的则是另一件事：
怎么让 AI 把已经发生过的经验，变成下一次真的能用的东西。
也正因为这个问题太普遍，所以这类设计天然就容易传播。它不是那种看起来很炫、但离日常使用很远的项目；相反，它特别接近真实工作流，几乎每个长期用 AI 的人都能立刻看懂它的价值。
它到底是什么？
很多人看到这个名字，第一反应会以为它在做“AI 自我训练”。
其实完全不是。
self-improvement 更像一个给 Agent 配的错题本系统。它做的事情很朴素：
• 命令失败了，记下来 • 用户纠正了，记下来 • 发现更好的做法，记下来 • 用户提了当前还不支持的需求，也记下来
然后这些信息会被分门别类放到 .learnings/ 目录里：
• .learnings/LEARNINGS.md• .learnings/ERRORS.md• .learnings/FEATURE_REQUESTS.md
所以它的重点不是“再生成一段更聪明的话”，而是把经验结构化。
这个 skill 的核心说明写在项目根目录的 SKILL.md 里，里面列得很清楚：什么情况该记、记到哪里、格式怎么写、什么时候应该把经验继续升级。
先看一个最容易理解的例子
假设你让 AI 帮你处理一个 Docker 问题。
它第一次尝试构建镜像，报错了。你查了一圈，最后发现问题不是 Dockerfile 语法，而是 Apple Silicon 机器上的平台兼容性，需要加 --platform linux/amd64。
普通情况下，这次经验只会停留在这次对话里。任务做完，窗口一关，事情就过去了。
但 self-improvement 想做的，是把这次过程拆成四步：
1. 先把这次错误记录到 .learnings/ERRORS.md2. 再把正确做法整理成一条学习记录 3. 如果这个问题以后又出现两三次，就提升优先级 4. 如果它已经是一个高频、稳定、可复用的问题模式，那就别只记日志了，直接抽成一个独立 skill
项目里的 references/examples.md 就给了一个非常像上面这种路径的例子，最后甚至演示了怎么把经验抽成 docker-m1-fixes 这样的 skill。
看到这里你就会明白，它真正想做的，不是“记录一次错误”，而是把一次错误变成未来的能力。
从源码看，它到底是怎么跑起来的？
这个仓库不大，但很完整。核心结构大概长这样：
SKILL.mdscripts/ activator.sh error-detector.sh extract-skill.shhooks/openclaw/ HOOK.md handler.tsreferences/assets/如果不按文件看，而按机制看，它其实就做了四件事。
第一件事：定义什么值得记
在 SKILL.md 里，作者先把边界划清楚了。
比如：
• 用户纠正你，记到 LEARNINGS.md• 命令失败，记到 ERRORS.md• 用户希望你有某个还没有的能力，记到 FEATURE_REQUESTS.md• 发现更好的重复性做法，也记到 LEARNINGS.md
更重要的是，它要求这些记录不是随手写几句，而是有结构的。仓库里给了统一的 ID 规则：
• LRN-YYYYMMDD-XXX• ERR-YYYYMMDD-XXX• FEAT-YYYYMMDD-XXX
并且每条记录最好带上优先级、状态、领域、摘要、建议动作这些信息。
这一步看起来很“笨”，但恰恰是最重要的一步。因为没有结构化，后面就谈不上搜索、复用和升级。
第二件事：在启动时提醒你别忘了复盘
这套设计里，我觉得最巧的一处，是它没有指望 Agent “自己有自觉”，而是直接把提醒机制做进了生命周期。
OpenClaw 的 Hook 定义在 hooks/openclaw/HOOK.md，配置的是 agent:bootstrap 事件。真正执行逻辑的是 hooks/openclaw/handler.ts。
这个处理器做的事情不复杂：
• Agent 启动时触发 • 往上下文里塞一个虚拟文件 • 文件内容是一段提醒，告诉 Agent 在任务结束后检查有没有值得沉淀的学习
这很像你每次开始工作前，桌上都会自动多出一张便签，上面写着：
“干完别急着走，看看今天有没有什么应该记下来。”
源码里还有个细节很加分：它会跳过 sub-agent。也就是说，如果当前是子代理会话，就不重复注入这类提醒，避免上下文噪音越来越多。
这说明作者不是在写一个“看起来正确”的概念，而是真的在考虑真实使用时的体验。
第三件事：在容易出问题的时候给提醒
除了启动时提醒，这个 skill 还加了两个小脚本。
第一个是 scripts/activator.sh。
它输出的是一段很短的提示，大意就是：做完任务后，想一下这次有没有出现值得提炼的知识。如果有，就写进 .learnings/；如果价值特别高，可以考虑继续抽成 skill。
第二个是 scripts/error-detector.sh。
这个脚本的思路更直接：它会看工具执行输出里有没有明显的错误特征，比如：
• error:• failed• command not found• Permission denied• Traceback• TypeError
一旦检测到，它不会粗暴地自动生成一堆日志，而是给出一个提醒：这次错误值不值得记到 ERRORS.md？
这个分寸感其实很好。
因为“全部自动记录”听起来很聪明，实际往往会制造大量垃圾信息；而“检测到异常再提醒 Agent 判断”，更像一个成熟团队里的工作方式。
第四件事：把零散经验继续升级
真正让我觉得这个 skill 有方法论的，不是前面的记录机制，而是它给经验设计了“升级通道”。
项目里有个脚本 scripts/extract-skill.sh，专门用来把高价值 learning 抽出来，生成新的 skill 骨架。
这个脚本会做几件很实际的事情：
• 检查 skill 名字是否合法 • 避免输出路径越界 • 创建 skills/<skill-name>/SKILL.md• 自动塞进一个标准模板
这背后其实是在表达一个非常清楚的思路：
经验不应该永远只是经验。
如果一个问题足够常见、足够稳定、足够可复用，那它最后就不该继续躺在日志里，而应该被产品化，变成一个新的 skill。
这一步一出来，整个项目的气质就变了。它不再只是“帮 AI 记笔记”，而是在尝试建立一种经验生产线：
出错 -> 记录 -> 复盘 -> 提炼 -> 固化
它最厉害的，其实不是“会记”，而是“会升级”
很多人第一次看这种项目，很容易把它理解成一个日志系统。
但如果只是日志系统，它不会这么有意思。
self-improvement 真正厉害的地方，是把经验分成了两个层级。
第一层是局部经验。
比如这个项目里某个脚本只能用 pnpm，或者某个接口必须带特殊 Header。这类东西先记在 .learnings/ 里，解决的是“别在同一个项目里重复犯错”。
第二层是长期规则。
如果某条经验已经被证明反复出现，而且能稳定预防错误，那它就应该继续升级，进入：
• AGENTS.md• TOOLS.md• SOUL.md• CLAUDE.md
到了这一步，它就不再只是“某次对话留下的记录”，而更像团队内部的 SOP，或者 Agent 的长期工作手册。
这也是为什么我会觉得，这个 skill 更像一个“经验沉淀系统”，而不是一个单纯的小插件。
为什么这套设计很适合 OpenClaw？
因为 OpenClaw 本身就很适合做这种长期上下文工程。
从官方文档看，Skill 本来就是 OpenClaw 的核心扩展机制；它支持工作区技能、用户本地技能和内置技能，也支持 Hook 和工作区文件注入。
这意味着 self-improvement 可以把几件事自然串起来：
1. 用 SKILL.md定义行为2. 用 Hook 插入生命周期节点 3. 用工作区文件承接长期经验 4. 用脚本继续把经验工程化
很多平台也许也能模仿这套思路，但在 OpenClaw 里，这种设计是很顺手的。它不需要额外发明太多机制，直接顺着平台能力往下搭就行。
它最值得普通读者学的，不是代码，而是思路
如果你平时也在高频使用 AI，这个项目最值得拿走的，其实不是某个具体脚本，而是下面这套观念：
• 不要把每次纠正都当成一次性对话 • 不要把每次报错都当成临时事故 • 不要让好经验只存在于某一次窗口里
说白了，self-improvement 在做的是三件事：
• 把错误收进错题本 • 把经验写成可复用规则 • 把高频规则继续升级成真正的能力
这套思路不只适用于 OpenClaw。你就算不用 OpenClaw，甚至不用这个 skill，也完全可以把它学过去，用在自己的 AI 工作流里。
当然，它也有一个很现实的风险
这也是这篇文章里我觉得不能回避的一点。
这个项目最强的地方，也恰好是它最需要克制的地方：它会把一次会话里的经验，慢慢变成未来会话里的长期上下文。
第三方分析站 Oathe 也明确提醒过这一点。风险并不抽象，因为从源码路径就能看出来这条链路是存在的：
1. 对话、错误、纠正先进入 .learnings/2. 高价值内容再被 promote 3. 最后进入 AGENTS.md、TOOLS.md、SOUL.md、CLAUDE.md
这套机制当然很聪明，但也意味着一旦中间混进了错误规则、污染指令，或者不该长期保存的敏感信息，问题也会被一起放大。
所以对这个 skill 最准确的评价不是“神奇”，而是：
它是一个很强的经验放大器。
放大得越好，越需要有人在关键节点上做审核和取舍。
最后怎么评价它？
如果你把 OpenClaw 理解成一个个人 AI 操作系统，那 self-improvement 很像里面的记忆中枢。
它最有启发性的地方，并不是某一段代码写得多漂亮，而是它把一件过去很容易停留在口头层面的事，做成了工程流程：
• 什么时候该记 • 记成什么格式 • 什么值得升级 • 怎么把经验变成长期规则 • 又怎么把规则继续抽成 skill
很多 skill 在教 AI “怎么做更多事”，但 self-improvement 回答的是另一个更重要的问题：
AI 做过的事，能不能留下来。
如果说工具型 skill 解决的是效率，那么 self-improvement 解决的是积累。
这也是它最值得研究的地方。
可直接引用的一段话
self-improvement 最有价值的地方，不是让 AI 当场变得更聪明，而是把“犯错、纠正、复盘、沉淀、升级”做成了一套能长期运行的流程。它先把错误和经验收进 .learnings/，再把高价值模式升级成 AGENTS.md、TOOLS.md、SOUL.md 这样的长期规则，最后甚至还能继续抽成新的 skill。它解决的不是一次回答，而是 AI 能不能积累。
参考资料
• OpenClaw 官方 Skills 文档：https://docs.openclaw.ai/skills • OpenClaw 官方 Creating Skills 文档：https://docs.openclaw.ai/tools/creating-skills
