OpenClaw 这个 skill，为什么让那么多人上头？

月诸清酒
0 阅读11分钟

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.md
  2. 再把正确做法整理成一条学习记录
  3. 如果这个问题以后又出现两三次，就提升优先级
  4. 如果它已经是一个高频、稳定、可复用的问题模式，那就别只记日志了，直接抽成一个独立 skill

项目里的 references/examples.md 就给了一个非常像上面这种路径的例子，最后甚至演示了怎么把经验抽成 docker-m1-fixes 这样的 skill。

看到这里你就会明白，它真正想做的，不是“记录一次错误”，而是把一次错误变成未来的能力。

从源码看，它到底是怎么跑起来的？

这个仓库不大，但很完整。核心结构大概长这样：

SKILL.md
scripts/
  activator.sh
  error-detector.sh
  extract-skill.sh
hooks/openclaw/
  HOOK.md
  handler.ts
references/
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 能不能积累。

参考资料

avatar
文章
阅读
粉丝