题记：本文编译自 Anthropic 工程博客《Steering Claude Code: skills, hooks, subagents and more》，原文链接：https://www.anthropic.com/engineering/claude-code-best-practices。本文在翻译基础上做了整理和补充。

在使用 Claude Code 时，我的 CLAUDE.md 曾经写到几千行。项目规范、参考约定、编码风格、部署流程，还有日常开发中碰到的各种坑，全往里面塞。CLAUDE.md 的内容越来越丰富，Claude Code 也越来越好用。直到有一天我发现 Claude Code 开始选择性忽略某些指令，才反应过来，它的上下文太长了，它已经不能很好地遵循 CLAUDE.md 定义的各种规则了。

你是不是也碰到过类似的情况？明明写了“所有修改必须跑完整 e2e 测试”，结果只跑了一个单元测试就停了，需要你反复提示才执行。

我在这个问题上卡了很久，一度怀疑是 Claude 模型又降智了，后来才发现根本原因是上下文膨胀。把所有东西都塞进了 CLAUDE.md，这本身就是用错了 AI 工具。

Anthropic 最近发了一篇官方指南，系统梳理了提示 Claude Code 的 7 种方法和它们的实现原理。我之前踩过的很多坑，根因都是没搞清楚每种方法的加载时机和上下文成本。

下面是我对这篇指南的编译和解读，每一节加了自己的使用经验。

CLAUDE.md：写得越多，质量越差

CLAUDE.md 是使用 Claude Code 所必需的第一步，所以也就成了大家最先接触、也是最容易写过头的配置方法。它在 Claude Code 会话启动时就加载，全程驻留在上下文空间中。

不过这里有个容易忽略的设计：CLAUDE.md 的写法其实分两种。

第一种，放在项目根目录的 CLAUDE.md 每次会话都加载，压缩后会被重新读取。适合放构建命令、目录结构、团队硬性约定这些 Claude 需要始终知道的信息。

第二种，子目录的 CLAUDE.md（比如app/api/CLAUDE.md）只在 Claude 读到该目录下的文件时才加载。离开这个目录，这些指令就不在上下文里了。

Anthropic 给的建议是：根 CLAUDE.md 控制在 200 行以内，给它一个 owner，像审查代码一样审查对它的修改。

这件事在团队协作的大仓库里尤其明显。CLAUDE.md 很容易变成一个没人维护的公共配置文件，每个组都往里加自己的规范，没人删旧的。

最终每个工程师的每次会话都要加载所有团队的规范，不管跟当前任务有没有关系。

要解决也很简单，在 monorepo 里给每个团队目录配置单独的 CLAUDE.md，让团队只加载自己的规范。还可以用claudeMdExcludes 跳过不相关团队的文件。

总结起来一句话，不要把 CLAUDE.md 当成垃圾桶，而是寸土寸金的黄金地段。能不放的，就别放。

Rules：按路径触发，不白占上下文

Rules 是.claude/rules/ 目录下的 Markdown 文件。

不带路径限定的 Rule 跟根 CLAUDE.md 行为一样：每次会话都会加载、会话压缩后也会重新注入。其实本质上就是换了个目录放的 CLAUDE.md 内容。

真正有意思的是带路径限定的 Rule。给 Rule 加一个paths 字段，它就只在 Claude 碰到匹配路径的文件时才加载：

---paths: -"src/api/**" -"**/*.handler.ts"---所有 API handler 必须用 Zod 校验输入参数.

这条规则在你改文档的时候完全不占上下文，只有碰到 API 相关代码才会出现。

所以，凡是只对特定目录或文件类型生效的约束，都应该用 path-scoped Rule，而不是写在 CLAUDE.md 里。这是控制上下文膨胀最直接的手段。

什么时候用 Rule 而不是子目录 CLAUDE.md？当一个约束是跨目录的。比如“所有.handler.ts 文件都要校验输入”，它可能散布在多个目录下，放某一个目录的 CLAUDE.md 里不合适。

Skills：按需加载，用完即走

Skills 住在.claude/skills/ 目录里，每个 Skill 是一个文件夹，核心是一个SKILL.md 文件，里面包含了名称、描述和正文。

Skills 最关键的一个设计时只有名称和描述在会话启动时加载，正文只有在被调用时才进入上下文。

它的调用方式有两种：通过斜杠命令（比如/code-review），或者 Claude 根据任务自动匹配。

在使用 Skills 的时候，也需要注意会话压缩的行为：压缩时，已调用的 Skills 会被重新注入，但所有 Skills 共享一个总 token 预算。一次会话里调用太多 Skills，最早调用的会被丢掉。

Anthropic 给的原则是：流程性的东西放 Skill，不要放 CLAUDE.md。部署流程、发布检查清单、代码审查规范，这些都应该是 Skill。CLAUDE.md 只放 Claude 需要始终知道的事实。

我自己的经历可也是如此。之前 CLAUDE.md 里写了一大段“发布+验证流程”，后来拆成 Skill，不发布的时候这些指令就不占空间了。省下来的上下文让 Claude 能记住更多真正相关的事情。

Subagents：不是多一个帮手，是多一块白板

Subagents 是.claude/agents/ 目录下的 Markdown 文件，用 YAML frontmatter 定义名称、描述和工具权限，正文是这个子 Agent 的系统提示词。

名称、描述和工具列表在会话启动时加载。但正文永远不会进入主会话的上下文，它在子 Agent 自己的独立上下文窗口里运行，只有最终的摘要消息回到主会话。

这个设计对上下文管理的意义挺大的。Subagent 可以嵌套最多 5 层，动态工作流可以编排几十甚至上百个后台 Agent。中间结果全在脚本变量里，不污染主上下文。

那 Skill 和 Subagent 怎么选？Anthropic 给的判断标准是这样的：

• 用 Skill：当你希望流程在主线程里执行，你能看到每一步、随时干预。
• 用 Subagent：当侧任务的中间结果你不需要再看（深度搜索、日志分析、依赖审计），只需要一个最终摘要。

说白了，Subagent 的核心价值不是“多一个 Agent”，而是上下文隔离。让主会话保持干净，不被旁支任务的中间过程淹没。

我自己用 Subagent 最多的场景有两个：一个是让它先 explore 整个代码库，写一份结构报告回来，主 Agent 拿着报告再动手改代码；另一个是设计和实现分离，设计时需要进行大量的调研工作，但实现的时候只需要设计文档就足够了。

Hooks：让 Claude Code 100% 执行

Hooks 是在 Claude Code 生命周期事件上触发的用户定义命令。注册在settings.json 里，在文件编辑、工具调用、会话启动等事件上自动触发。

Hook 有五种类型：command、HTTP、mcp_tool、prompt 和 agent。前三种确定性执行（跑脚本、发请求、调工具），后两种用模型判断来决定输出。

Hooks 的上下文成本极低，配置在主上下文窗口外面，harness 直接执行。只有少数 Hook 的输出会回到主上下文（比如阻断型 Hook 的错误信息，让 Claude Code 知道为什么被拒绝）。

Hooks 在整套 Claude Code 体系里最容易被忽略但最重要的一点是：

“每次 X 都必须做 Y” 如果放在 CLAUDE.md 里，本质上是在靠模型的遵从性来保证执行。模型大多数时候会遵守，但在长会话、上下文压力大、或者遇到 prompt injection 的时候，它可以不遵守。

想要确定性执行，必须用 Hook。比如“每次编辑后跑 prettier”，这不该是一条指令让 Claude Code 选择执行，而应该是一个PostToolUse Hook 在每次文件写入后自动触发。

同理，“绝对不能做 X” 这种约束也不该靠 CLAUDE.md。用PreToolUse Hook 检查调用，exit code 2 直接阻断。对企业来说，更严格的配置可以用 Managed Settings，管理员部署、用户不可覆盖。

所以，你要注意，凡是在 CLAUDE.md 里写了“必须”或“绝对不能”的规则，都别忘了问自己一句：这条规则失败了会怎样？如果后果严重，就赶紧改成 Hook。

Output Styles 和 append-system-prompt：慎用，杀伤力大

最后两种方法放在一起说，它们都作用在系统提示词层面，威力大但副作用也大。

Output Styles 是.claude/output-styles/ 目录下的文件，注入系统提示词，永不压缩。注意一个关键细节：自定义 Output Style 默认会替换 Claude Code 的默认系统提示词，除非在 frontmatter 里设置keep-coding-instructions: true。

换句话说，一旦用了自定义 Output Style，Claude Code 默认的那些行为指导（怎么控制变更范围、什么时候加注释、安全关注点、跑测试再报完工）全部会被覆盖。Claude Code 就从一个软件工程助手变成一个通用助手了。

所以 Anthropic 的建议是：先看看内置的 Proactive、Explanatory、Learning 三个样式够不够用，再考虑自定义。

append-system-prompt 是另一种用法，它是 CLI 启动时传入的 flag，只对当前会话生效，不会持久化。它是纯追加的，不会替换默认行为，一般适合临时加一些格式偏好或领域知识。

我觉得大多数人不需要碰 Output Styles。内置样式加上 CLAUDE.md 已经够用了，除非你真的要把 Claude Code 改造成一个完全不同的角色。

别踩这些坑

最后整理一下 Anthropic 给的“反模式”清单，基本都是我自己踩过或见过别人踩的：

第一个是把“每次 X 都必须做 Y” 这种强制性约束写在 CLAUDE.md 里。模型的指令遵循和代码自动执行是两回事。如果这个行为必须可靠发生，一定要用 Hook。同理，“绝对不能做 X” 也不该靠 CLAUDE.md，禁止性约束在 prompt injection 面前毫无抵抗力，要用 Hook 或 Managed Settings 做墙纸约束。

第二个是把流程放在 CLAUDE.md 里面。CLAUDE.md 应该只放 Claude Code 需要始终知道的事实以及它最常犯的一些错误的经验教训，而流程则放到 Skills 里面。

第三个是 Rule 不加 paths。一条只对src/api/ 生效的规则如果不加路径限定，效果等同于在 CLAUDE.md 里多了一行，每次都加载，每次都耗 token。个人偏好也是同样的道理，所有的配置方法都分为项目级和用户级，“永远用 semantic commit message” 这种个人习惯应该只放在本地，项目级只放团队共识。

速查表：7 种方法一览

这张表最有价值的一列是“上下文成本”。搞清楚哪些指令需要全程驻留、哪些只在触发时加载，是用好这套系统的关键。

写在最后

说实话，这篇官方指南没介绍什么新功能，这 7 种方法早就存在了。但它的价值在于第一次把每种方法的加载时机、压缩行为和上下文成本都讲清楚了。

这 7 种方法按 harness 设计的思路大致可以整理成为四层：

• 全局层（CLAUDE.md、unscoped Rules、Output Styles）：高成本、高权威，克制使用
• 触发层（path-scoped Rules、子目录 CLAUDE.md、Skills）：按需加载，中低成本
• 隔离层（Subagents）：零主上下文成本，只关注结果
• 确定性层（Hooks）：绕过模型，代码级保证

搞清楚这四层，大部分“Claude 为什么忽略我的指令”的问题就有了答案。不是模型不听话，是你把指令放在了错误的层级，或者上下文爆满之后它被忽略掉了。

我推荐的实践顺序是这样的：所有项目第一步先给根 CLAUDE.md 瘦身，拆出去的流程丢进 Skills，跨目录的约束用 path-scoped Rules，必须 100% 执行的规则用 Hooks 做约束。然后在日常使用中持续观察、持续迭代修改，如果发现有的指令被忽略了，那大概率是相关的指令放错了层级。

上下文窗口就那么大，每一行指令都有成本。把对的指令放在对的层级，比写更多指令管用得多。

原文：Steering Claude Code: skills, hooks, subagents and morehttps://www.anthropic.com/engineering/claude-code-best-practices

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Codex 桌面版最近口碑爆了。我自己已经把很多工作都切到了 Codex 客户端的 Goal + GPT-5.5 上，一不小心就用了 20 多亿 token。

不过很多人第一次用 Codex，还是把它当一个更强的 coding agent，用来读仓库、改代码、跑测试、写 PR。这当然没错，Codex 的基本功能确实还是代码编程。但它的桌面客户端已经不只是编程工具了。Skills、Computer Use、浏览器操控、Gmail 和 Calendar 等等各种连接器和插件一路加上来，早就成了一个通用 Agent 客户端。甚至你还可以通过 ~/.codex/config.toml 配置文件给它接入 DeepSeek、Kimi 等第三方模型。

我让 Codex 扫了一下最近这个月的会话历史，总结了一些日常的使用方法，再加上自己的补充，整理成这篇分享给大家。如果你还不熟悉 Codex 桌面客户端的使用方法，可以参考 Jason Liu 最近写的 Getting the most out of Codex 文章（链接见文章最后），今天的文章假设你已经了解了 Codex 的基本用法。

1. 先给足上下文，再开始任务

AI Agent 最大的问题不是不会干活，而是太容易基于幻觉自信乱干。你不告诉它项目背景和规则，它就按自己的理解来，很容易过度自信，走向错误的方向。

要解决也很简单，写一个 AGENTS.md 放在项目根目录。Codex 每次打开项目会自动读这个文件，里面可以写项目背景、技术栈、代码规范、常见坑、测试方式，相当于给它一份新人上岗须知。如果任务涉及特定模块，还可以在 prompt 里直接指定“先读 docs/xxx.md 再动手”，让它从文档而不是从猜测开始。

Codex 桌面端有个置顶会话挺好用的，你可以把最常使用的会话固定在前面。不要把 Codex 的会话当成临时会话，而是一个持续的工作现场。Codex 已经能够自动帮你压缩会话上下文，再加上它的记忆功能，长时任务不需要新开会话，可以持续在同一个会话里持续下去。

这也是我觉得 Codex 最好用的一点，避免了很多上下文交接的问题，可以真正帮你干大活了。

2. 验证比生成重要得多

说实话，让 Codex 写代码，随便一个 coding agent 都能做个七八成。真正拉开差距的是验证，要拿真实的验证结果说话。

验证可以是很多东西：测试套件、benchmark、Web 界面截图、发布前 checklist 等等，也就是之前你自己手动做的所有操作应该都描述清楚，交给 Codex 让它去负责。

特别是在用 Goal 跑长任务的时候，这点更是必不可少。比如，“帮我把这个计划实现完” 看起来有目标，但其实病没有明确的停止条件。而好的 Goal 应该带上清晰的验证器：“完成后必须通过 xx 测试、浏览器检查和人工可审阅的变更摘要。如果验证失败，先修验证失败的问题，不要直接宣布完成。”

没有验证的 Goal，其实只是愿望。

3. 批量操作前加一道审查门

从我自己的使用历史来看，审查和清理类任务最容易翻车。Codex 默认倾向是搜到了就改，找到了就删。这时候，你需要主动在提示词里面拦一下。

具体做法是在 prompt 或 AGENTS.md 里加上审查规则。比如“批量修改前先列出所有命中并按类型分组（需要改 / 可能需要改 / 不该动），等我确认再执行”。清理旧分支也一样：“先输出 merged 和 unmerged 分支对比，标注哪些旧实现已被 main 覆盖，不要直接删”。

举个例子，代码库里搜到一堆旧 token 引用，不是所有命中都该删。有些是测试隔离需要的，有些是运行时继承的，真正有问题的可能只有几个。如果不加审查这道程序，Codex 可能会机械地全部清掉，然后测试挂一片（针对这个例子，加上上一步说的验证其实可以自动修复回来，但会浪费很多时间+token）。

这种不是高大上的 AI 能力，但特别体现人的判断，需要你把经常看到的坑告诉 AI，让它去主动规避。

4. 先配工具，再谈智能

模型当然重要，但真正决定 AI 能干什么的，是配置的工具、权限、上下文和验证方式。插件决定 Codex 能碰到哪些外部世界，Skills 决定它碰到这些世界时该怎么做。我自己常用的插件和 Skills 列在了文末附录里，这里只说一个最容易被忽略的点。

大多数人写 Skill，会把它当成说明文档：告诉 Codex 该做什么、按什么顺序做。这当然有用，但 Skill 真正值钱的部分不是流程，而是 Gotchas，也就是每次 Codex 犯错之后补进去的“别踩这个坑”。

比如：

• 这个数据源经常不可用，不要猜。
• 这个任务结束前必须跑某个验证。
• 这个工具第一次会失败，失败后应该换另一种方式。
• 这个类型的 review 不能机械接受，要逐条验证。
• 这个工作流适合先搜宽一点，再只打开高价值候选。

一开始写个十几行骨架就够了，用一段时间后它自然会长成一个成熟 Skill。好用的 Skill 不可能一次写好的，都是拿实际经验养出来的。

5. 用 Side Panel 边看边改

以前用 AI 做文档、网页、PPT，最烦的是上下文切来切去。AI 在聊天框里生成，产物在另一个窗口打开，发现问题又要截图回来描述。来回几次，人和 AI 都开始丢上下文。

Codex 的 Side Panel 可以把产物留在工作流里直接改。具体做法是：让 Codex 生成一个 index.html 或者打开一个 localhost 页面，它会在侧边栏渲染出来。你一边看渲染结果，一边在同一个线程里说“这个按钮太大了”“表格第三列数据不对”，不用截图，不用切窗口。

有两类任务特别适合这个场景。一类是前端和网页，直接在旁边检查样式、交互和移动端适配。另一类是文档型产物，报告、表格、PPT、数据分析页面放在旁边边看边改，比导出再反馈高效得多。

6. 重要上下文写到文件里

会话会压缩，模型可能会切换，对话里的重要决策和验证方式如果不主动写到外部文件里，就很容易会被丢掉。

我自己在做长任务的时候（特别是那种跨天的任务），会特意让 Codex 总结记录下 summary、checkpoint、handoff 文档和下次接手的入口说明。下一个会话或者新任务可以接着这些文件继续，不用从零开始。

要实现也很容易，不需要搞复杂的记忆系统。一个 TODO.md 写待办事项，再加几个文件夹分类放踩坑记录和项目状态，就够了。关键是可检查、可编辑、可删除。Codex 内置的 Memory 和 Chronicle 可以当快速回忆层用，但替代不了外部文件。只有写进文件里的记忆，才有机会变成系统。

7. 随时在线，随处接管

长任务跑着的时候，你不需要一直坐在电脑前。在 ChatGPT 手机端连上你的 Mac 或远程机器，可以随时给远端的 Codex 下任务，或者回复 Codex 需要你介入的问题。

一般来说，当你把任务定义清楚之后，就可以通过 Goal 来启动长时任务，然后等着 Codex 的通知就可以了。你可以在手机上随时能看到它的输出、审批命令、中途纠偏。不用坐在电脑面前盯着，同时关键决策又可以随时介入。

如果你有 Linux 服务器，Remote SSH 更值得配一下。Codex 会自动读取本地 SSH config 里的主机列表，连上之后直接在远程服务器里跑任务。日常运维、配置管理、代码部署，SSH 连上就能让 Codex 干活，电脑端/手机端都可以随时跟进。配合前面说的 AGENTS.md 和文件记忆，远程接入的时候上下文还在，不用重新交代背景。

8. 定时自动化：让会话自己醒过来

前面说的远程接入是“你主动去给 AI 下发任务”，而定时自动化是“让 AI 主动来找你”。

具体做法是给置顶线程设一个 Thread Automation。跟普通定时任务不同，Thread Automation 每次触发会回到同一个线程，带着上次的上下文继续工作。它知道上次检查到了哪里，哪些事项已经处理过，哪些数据源接不上。

我自己用得比较多的是两类。一类是信息聚合：每天早上自动检查未读邮件和 IM 消息，按优先级整理好，等我打开的时候直接看结论。另一类是监控类：定期检查 PR 列表、问题反馈或者关注列表，有新内容就整理摘要，没有就不打扰。

这儿有一点需要注意的是不要让自动化假装全知。没有就是没有，不要编造虚假信息；依赖不可用就直接报不可用，不要自作聪明。

9. 不只是代码：邮件、调研、文档也能跑

文章到这里，其实大部分的场景还都是跟代码相关的。但 Codex 桌面客户端接上 Gmail、Browser、Documents 这些插件之后，很多非代码任务也都能跑的不错。

我自己用得比较多的几个场景：让 Codex 过一遍项目和相关邮件，做图文并茂的汇报 PPT；给一个调研主题，让它用 deep-research 搜多个来源，整理成带出处的摘要；会议前把相关文档和之前的讨论丢给它，让它准备一份简要；写完公众号文章后让它排版成微信公众号格式并生成封面图。

这些任务的共同点是：以前要在好几个工具之间切来切去，现在可以在一个会话里串起来，省掉了大量的不同工具和上下文切换。

10. 别追求全自动，要把主动权留在人的手里

Codex 好用，也可以自动化很多任务，但并不意味着你就要完全放手让它全自动去自己玩。

恰恰相反，你越把它接进真实工作流，越会看到很多边缘问题：权限、登录态、数据源缺口、工具失败、上下文压缩、验证不充分、自动化误触发等等。

所以更合理的用法是：让 Codex 做上下文收集、执行、验证和初步整理，人保留判断、授权和最终责任。Codex 的 Steering（中途纠偏）和 Queuing（排队追加下一步）就是为这个设计的。真实的工作往往都是边看边改、边发现边调整，不是“人给一个完美需求，让 AI 一次性完成”。

也就是说，人不应该退到系统外面，而是站在系统里面，负责纠偏、验收和更新规则。

Codex 的语音输入也是一个让人留在 loop 里很好的设计。它不是让你口述代码的，而是在想法还没成型的时候随时输入给 Codex，或者在 Codex 走偏的时候随时修正它。语音输入不需要很完整，有错别字啥的都没关系，模糊指令对一个已经掌握足够上下文的 AI 来说已经足够让它理解你的意图。

相关链接：

• Jason Liu Getting the most out of Codex：https://x.com/jxnlco/status/2057153744630890620
• Codex 功能文档：https://developers.openai.com/codex/app/features/
• Codex Skills 文档：https://developers.openai.com/codex/skills

附录：我常用的插件和 Skills

以下是文中第 4 条提到的工具清单，供参考。

常用插件：

• Browser：本地网页、localhost、侧边栏里的页面检查和截图。
• Chrome：需要登录态、真实 Chrome profile、远程网页操作时用。
• Computer Use：只能通过桌面 GUI 完成的工作。
• Gmail：搜索邮件、读取正文、筛选待办、草拟回复。
• Documents / Presentations / Spreadsheets：文档、PPT、表格类 artifact。
• Product Design：早期产品想法、原型、截图到交互稿。
• Build Web Apps：前端应用、组件、浏览器验证。
• HyperFrames / Remotion：视频、动画、程序化内容。
• Superpowers：计划、TDD、系统化调试、验证、代码 review、开发分支收尾。
• Codex Security：安全扫描、威胁建模、finding 修复。

常用 Skills：

• brainstorming（Superpowers 插件自带）：头脑风暴和 SPEC 设计。
• handoff：将当前对话整理成交接文档（用于新开会话接手）。
• deep-research：多源搜索调研。
• claude-skill：调用 Claude Code 写文档、做设计或者跟 Codex PK。
• twitter-cli / xfetch：读取和搜索 X/Twitter 内容。
• xiaohongshu-cli：搜小红书内容。
• youtube-transcribe-skill：解析下载 Youtube 视频字幕。

相关 Skills 的安装方法：

npx -y skills add mattpocock/skills -g -s handoffnpx -y skills add feiskyer/codex-settings -g -s claude-skillnpx -y skills add feiskyer/codex-settings -g -s deep-researchnpx -y skills add feiskyer/codex-settings -g -s youtube-transcribe-skill

几个 CLI 工具的安装方法：

uv tool install xiaohongshu-cli twitter-cli
npm install -g xfetch-cli

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

刚装完 OpenClaw，简单试了几个场景，觉得也就那样。跟直接用 Claude Code 比，看不出有啥明显优势，反而还多了一层 Gateway 要维护。看起来它能干的，Claude Code 好像也都能做，干脆卸载算了？

你第一次用的时候是不是也这个感觉？反正我是。

后来用过一段时间才发现，问题不在 OpenClaw 不行，而在于没有“养”好。一个没调教过的 OpenClaw，确实看起来就是个套壳。但配到位之后，差距就出来了。比如，我跟 OpenClaw 说一句“review [PROJECT] PR #375”，它会自己切到项目工作目录、收集上下文、spawn Claude Code 做各种审查、汇总结果回来汇报，最后再发布审核意见到 PR 里面。并且，它还可以在跟你交互的过程中自动学习你教给它的经验，能够记住你跟它说的各种注意事项，用着用着也就离不开了。

这篇就分享一下，我是怎么一步步把 OpenClaw 从也就那样养到离不开的。

先写好三个文件

这是我觉得最重要的一步，先教 OpenClaw 怎么说话、怎么做事、怎么理解你。你给它配置得越具体、越有观点，OpenClaw 的输出就越像一个有血有肉的人。

具体来说，OpenClaw 的 workspace 里有三个核心文件，分别管不同的事。

SOUL.md 管 OpenClaw 怎么说话。注意这并不是 system prompt，而是 Agent 的身份定义。你在里面写什么样的语气、什么词不能用、什么样的输出让你满意，OpenClaw 就会照着来。

USER.md 管 OpenClaw 怎么理解你。当然这儿并不是放你的简历，而是让 OpenClaw 理解你怎么思考的文件，比如你的决策风格、什么让你烦、什么让你兴奋、你的沟通习惯等等。

AGENTS.md 管 OpenClaw 怎么做事。这里面就是纯流程，比如该做什么、不该做什么、失败了怎么处理、PR 怎么提等等。

这三个文件的分离很关键。SOUL.md 写好后应该很少变化，身份是稳定的；AGENTS.md 要经常更新，因为流程在不断迭代；USER.md 则随着 Agent 更了解你而逐步补充。

怎么写 SOUL.md

你可能觉得 SOUL.md 随便写几行就行了。我之前也是这么想的，结果 OpenClaw 动不动就回答一个技术问题先来三段废话。

那么，SOUL.md 具体该怎么写？

首先表达语气要写具体。我的 OpenClaw 叫 Klaw 🦀，表达要求是 language with voltage，每句话要值得存在。你要是泛泛地写个 be helpful and concise，那出来的东西跟 ChatGPT 没什么区别。写得越具体，输出越像你想要的样子。

然后禁用词表也要有。comprehensive、robust、leveraging 这些 AI 味词汇全部禁掉。

不过最关键的还是给好输出和坏输出的示例。与其写简洁明了四个字，不如直接给 OpenClaw 看一对对比：

好输出：

etcd compaction 的 revision 不对.看一下 --auto-compaction-retention
设的是不是 duration 模式,旧版本默认是 revision 计数.

坏输出：

Great question! Based on your use case, I'd recommend considering several
factors when configuring etcd compaction...

第一种是一个懂行的工程师在说话，第二种是一个 AI 在表演热情。OpenClaw 看到这对示例，立刻就知道你想要什么了。

调了几版之后的经验

用了一段时间之后，又踩了几个坑。

最大的教训是别写太长，1000-2000 字就够了。太长占用上下文空间不说，给 AI 太多的限制还容易降低 Agent 的智能。

还有一个容易犯的错是把 SOUL 和 AGENTS 混在一起。个性相关的放 SOUL，流程相关的放 AGENTS，分开写 OpenClaw 才分得清轻重。

另外 SOUL.md 不是写完就不动的，建议每周花几分钟回顾一下，删掉没用的，加上新碰到的问题。我自己已经改了四五版了，每次改完都觉得 OpenClaw 又多懂我了一点。

让它有记忆

LLM 最大的问题是无状态，每次对话都从零开始，你昨天告诉它的东西今天全忘了。OpenClaw 的解决方案是一套基于文件的记忆系统：

MEMORY.md → 长期记忆memory/2026-04-28.md → 每日笔记memory/working-buffer.md → 危险区缓冲SESSION-STATE.md → 活跃任务状态

那么，这套记忆系统具体是怎么工作的呢？

记忆怎么写进去的

OpenClaw 的记忆机制有点像数据库里的 Write-Ahead Logging：先落盘，再响应。它会扫描你发的每条消息，一旦发现重要信息（比如你纠正了它的错误、做了某个决策、表达了某种偏好，或者提到了具体的数值），就立即写入文件，然后才回复你。

简单说就是：让 OpenClaw 记住一件事，靠嘴说不可靠，写下来才可靠。

Dreaming

OpenClaw 还有个 Dreaming 功能，可以配一个定时任务在凌晨自动整理短期记忆：

{“memory-core”:{“config”:{“dreaming”:{“enabled”:true,“frequency”:“019***”,“timezone”:“Asia/Shanghai” }}}}

它会扫描最近的对话，把你经常用到的记忆晋升到长期存储，不常用的自然淘汰。有点像人睡觉时整理白天的记忆一样。

不过这里有个坑：dreaming 容易把一些啰嗦的内容也晋升上来，导致 MEMORY.md 越来越臃肿。目前还没有好的自动化方案，还是得你定期手动清理一下。

另外如果你同时在好几个项目上用 OpenClaw，建议不要把所有项目的具体信息都塞进主 MEMORY.md 里面。我的做法是给每个项目建一个单独的目录，项目相关的记忆都放在各自目录下，主 MEMORY.md 里只放索引。这样既不会互相干扰，找起来也方便。

长 session 不丢上下文

用久了你还会碰到一个问题：聊太久触发了 context compaction，OpenClaw 压缩上下文之后会丢失一些细节。它的恢复策略是先读working-buffer.md（这个是压缩前自动写入的摘要），再读SESSION-STATE.md（当前任务状态），然后翻一下近两天的日记。

给它装 Skills

Skills 是扩展 OpenClaw 能力的机制，每个 Skill 就是一个包含SKILL.md 文件的文件夹，告诉 OpenClaw 在什么场景下应该怎么做事。

你可能会想，Skill 是不是装得越多越好？其实不是。装多了互相打架不说，上下文也吃不消。

我目前安装的 Skills 大致分三类：

• 通用增强：proactive-agent（主动预判需求）、self-improvement（从错误中学习）、context-window-management（上下文快满时自动减负）、systematic-debugging（四阶段 root cause 分析）。
• 安全防护：skill-vetter（安装外部 Skill 前做安全审查）、dangerous-action-guard（执行不可逆操作前要你确认）、fact-check-before-trust（对事实性声明做二次验证）。
• 领域专用：按自己的工作场景来选装，比如github、cve-check、ado 等等。

至于一些常用 Skills 的用法，我之前在《OpenClaw 必备 Skill 清单》里详细写过，这里就不重复了。

这里重点说一个我觉得特别重要的规则：安装任何外部 Skill 之前，一定要先跑skill-vetter 审查安全。

举个实际的例子：我之前从一个社区 Skill 仓库精选了 10 个，审查完跳过了其中 3 个。一个会偷偷发 Reddit 请求，一个带了自动 cron 任务，还有一个藏了遥测代码。如果不审查就装上去，OpenClaw 就会在你不知道的情况下做你不知道的事。要知道 Skill 本质上是一段会被 OpenClaw 执行的指令，它有你的文件系统权限。之前在《23 万 OpenClaw 公网裸奔》那篇也聊过这个话题，安全这事真不能大意。

让它自己干活

配好了人格、记忆和 Skills 之后，OpenClaw 已经比刚装完的时候好用太多了。不过到这一步你还是得自己发指令、等结果。有没有办法让 OpenClaw 自己跑起来，你只管收结果？

这就是 ACP 和 Cron 干的事。

ACP

OpenClaw 可以通过 ACP 调用 Claude Code、Codex、OpenCode 这些 coding agent。整个流程大概是这样的：

你 → OpenClaw → 分析任务 → spawn Claude Code → 独立沙箱执行 → 完成后汇报

比如，你跟 OpenClaw 说一句 review [PROJECT] PR #375，它会自动切到项目工作目录，收集 PR 的上下文，spawn 一个 Claude Code 调用 code-review skill 做审查，最后把结果汇总回来。如果是你自己的 Code，还可以继续跟进这些审查结果迭代，直到得到一个比较满意的结果。最后去把审查结果发布到 PR 上面去，有 bug 就直接留 comment，没问题就 lgtm。当然，合并之前还是建议你人工去看看 PR，不要完全信赖 AI。

另外还可以把 ACP agent 绑定到 Discord 等 IM 频道。比如，你可以分别给 Claude Code 和 Codex 绑定到#claude 和#codex 两个不同的频道，然后你在里面发消息就会自动创建 thread 并启动对应的 ACP session，相当于在 Discord 里面直接跟 Claude Code 和 Codex 对话了。

定时任务

那如果你想让它定时干活呢？OpenClaw 的 cron 系统可以每个 job 都跑在隔离的 session 里，不会影响你正在用的主 session。我目前配了几个定时任务：Git Sync 每小时自动备份 workspace，AI News 每 8 小时抓一轮新闻推到 Discord，Dreaming 每天凌晨整理记忆，Issue Triage 每天上班前自动 triage issue 列表， Version Check 每天检查我关注项目的更新状况。

大模型配置

用得频繁的时候，经常碰到 GitHub Copilot 限流的问题。如果没有配 fallback chain，OpenClaw 就直接断线了。所以建议你也给 OpenClaw 的模型列表搭上备份配置，比如

{“model”:{“primary”:“github-copilot/claude-opus-4.6”,“fallbacks”:[“github-copilot/claude-sonnet-4.6”,“github-copilot/claude-opus-4.7”,“openai/gpt-5.4”] }}

另外 memory search 我也单独配了一个 provider，用的是 Azure OpenAI 的text-embedding-3-small，配合 hybrid search 也就够用了。后来还发现 GitHub Copilot 也有text-embedding-ada-002 可以拿来做记忆搜索，就给 OpenClaw 提了个 PR 把这个功能加上了。

踩过的坑

说实话，OpenClaw 目前还是一个需要你愿意折腾才能用好的工具，所以大家都还需要养龙虾。除了前面提到的 SOUL.md 写太长和 Dreaming 膨胀的问题，还有一些值得注意的坑。

比如 Gateway 重启之后，所有 ACP sessions 全部 reconcile 失败。查了一下原因是旧的 session 用 renderer v1 格式存储的，但新版本只认 v2。处理方法是杀掉 stale harness 然后重启 gateway。这件事给我的教训是：一定要把tools.sessions.visibility 设成all，这样你能看到所有 session 的状态，调 ACP 问题的时候没这个配置基本是盲调。

OpenClaw 每个版本的升级虽然会带来很多新功能特性，但也都会带来各种各样的问题，有些还会导致配置不兼容。所以，每次升级之后，不要着急重启 gateway，而是先跑一遍 openclaw doctor –fix，看看是否缺了依赖，配置是否有不兼容的问题。不修好这些问题，gateway 重启之后可能就完全挂掉了。

另外 OpenClaw 的文档目前还不算完善，很多配置的最佳实践得自己摸索。这也是我写这篇文章的原因，希望能帮后来的人少走点弯路。

写在最后

回到开头说的那个问题：OpenClaw 跟 Claude Code 到底有啥区别？

虽然我主要把 OpenClaw 用在编程相关的任务中，但纯论代码生成能力，Claude Code 还是比 OpenClaw 强得多。OpenClaw 真正的优势在于它是一个完整的 agent runtime。它可以通过 Discord、Telegram、Slack 这些 IM 渠道随时跟你交互，记忆系统让它不再每次从零开始，Skills 给它装上了模块化的能力扩展，ACP 让它可以调度 Claude Code 和 Codex 帮你干活，而 Cron 让它在你睡觉的时候自己把活干了。

不过这些都不是装完就有的。OpenClaw 更像是一个需要你花时间去养的东西，SOUL/USER/AGENTS 写得越具体它就越懂你，记忆积累得越多它就越好用，Skills 选得越精准它就越靠谱。刚开始确实要折腾，但养一段时间之后，你会发现你已经离不开它了。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 博客《Building agents that reach production systems with MCP》。文章从 Agent 连接外部系统的三条路讲起，重点梳理了 MCP 服务器的设计模式、认证标准化、上下文优化，以及 Skills 的互补定位。不算长，但信息密度不低，尤其是 Cloudflare 的代码编排模式和 Vault 的凭证管理思路，值得做 MCP 服务器的人细看和参考。

我之前给 Claude Code 配 MCP 服务器的时候，最头疼的是上下文占用的问题，后来《Claude Code 终于解决了 MCP 最大的痛点》那篇写过 Tool Search 怎么解决这个事。但用得越多越发现，上下文只是冰山一角。

本地开发时，Agent 调个 API、跑个命令行工具，一切都很丝滑。但等你想把它放到云上跑，问题就来了：CLI 工具没有 shell 可用，API 调用的认证凭证要自己管，每对接一个新服务就要从头写一套集成代码。

刚刚看到 Anthropic 发了一篇博客，系统梳理了 Agent 连接外部系统的三条路，以及为什么生产环境下 MCP 可能是最务实的选择，分享一下，供大家参考。

把 Agent 接入外部系统

Anthropic 把 Agent 接入外部系统的方式分成三种：直接调 API、用 CLI，以及走 MCP 协议。

直接调 API 是最多人的起点，也是最简单的。Agent 在沙箱里发 HTTP 请求，或者通过 function calling 调用外部服务。一个 Agent 对一个服务没什么问题。但接的服务一多，每个 Agent 和服务的配对都要单独处理认证、工具描述和异常情况。做过微服务的人应该很熟悉，这就是经典的 M×N 集成问题。

CLI 也能用，快、轻量，复用现有工具链。但在移动端、Web 端和云托管平台这些没有 shell 的地方往往会到处碰壁，认证也只能靠磁盘上的凭证文件。说白了，CLI 是本地开发的好帮手，离生产还差一截。

MCP 走的是协议层。Agent 连上一个 MCP 服务器，服务器把你系统的能力暴露出来，认证、发现、语义描述都标准化了。一个远程服务器可以同时服务 Claude、ChatGPT、Cursor、VS Code 这些客户端，部署在哪都行。MCP 的前期投入确实比前两种大一些，但换来的是可移植性，以及协议本身能描述的东西也更多。

我自己的感受是，本地开发阶段 CLI 和 MCP 都够用，但一旦 Agent 要上云、要服务多个客户端，MCP 基本是唯一的选择。那为什么 Anthropic 现在特别强调生产环境？

生产 Agent 跑在云上

因为生产级 Agent 越来越多地跑在云上，它们需要连接的系统也在云上：数据存在那里，工单跟踪在那里，基础设施也在那里。这些系统通常是远程的、带认证的，正好是 MCP 擅长处理的场景。

从 Anthropic 自己的产品线也能看出这个趋势。前段时间发布的 Managed Agents，底层就是靠 MCP 连接外部工具和数据源，之前那篇《Managed Agents 架构拆解》分析过它的脑手分离设计。Claude Cowork、Claude Code Channels 也是类似的思路，MCP 在里面扮演的就是连接层的角色。MCP SDK 的月下载量从年初的 1 亿涨到了 3 亿，增速确实有点猛。

不过 Anthropic 也没说 MCP 就应该替代其他方式。API 是基础，CLI 服务本地开发，MCP 覆盖云端。三条路最终都会并存。

那问题就变成了：决定用 MCP 之后，服务器怎么设计才好用？

MCP 服务器怎么设计才好用

Anthropic 目前 MCP 目录里有 200 多个服务器。从这些实践中他们提炼了几个设计模式，结合我自己写 MCP 服务器的经验，聊聊几个我觉得最有价值的。

远程服务器优先

只有远程服务器才能同时覆盖 Web、移动端和云端 Agent，这是分发的前提。本地服务器在开发阶段够用，但想让 Agent 在任何环境下都能调用你的服务，必须上远程。

按意图分组工具，不要一比一镜像 API

这个我之前在《Claude Code 终于解决了 MCP 最大的痛点》提过，工具越少、描述越好，Agent 用起来越准。一个create_issue_from_thread 工具，比让 Agent 自己拼get_thread +parse_messages +create_issue +link_attachment 靠谱得多。

做过 Agent 开发的你应该都体会过，把底层 API 原封不动暴露给模型，基本就是在赌它能自己编排出正确的调用序列。赌赢的概率不高。我之前做 Kubernetes MCP 服务器的时候，最开始也是把 Kubernetes API 一比一映射成工具，结果模型光是选对工具就要好几轮，后来按运维场景重新分组，调用准确率提升了很多。

大量 API 场景用代码编排

如果你的服务有几百个接口，按意图分组也覆盖不完。这时候 Cloudflare 的做法挺妙的：只暴露两个工具（搜索和执行），覆盖了大约 2500 个 API 端点，整个工具定义只占 1K token。思路是让 Agent 写一小段脚本，服务器在沙箱里跑，只返回结果。

用 MCP Apps 做交互

MCP Apps 是 MCP 协议的第一个官方扩展，允许工具返回交互式界面，图表、表单、仪表盘，直接嵌在对话里渲染。你让 Agent 查一下数据库的慢查询，返回的不是一堆文本，而是一个可排序的交互式表格。这体验一下子就提升上去了，Anthropic 说支持 MCP Apps 的服务器在用户留存上表现好很多，这个不难理解。

还有一个叫 Elicitation 的能力也值得关注。它让 MCP 服务器在工具调用中途暂停，向用户请求输入。比如你让 Agent 删一个资源，服务器可以弹一个确认表单，而不是直接执行。更敏感的操作比如 OAuth 登录，可以把用户引到浏览器里完成，凭证不经过 MCP 客户端。这个设计思路和之前聊过的 Managed Agents 的安全隔离一脉相承，敏感信息能不过手就不过手。

认证这块终于不用自己造轮子了

说实话，认证一直是 MCP 从开发到生产最让人头疼的部分。本地开发时 MCP 服务器大多不需要认证，或者直接用 API Key 凑合。但到了生产环境，用户授权、token 存储、过期刷新、多租户隔离，每个环节都是坑。之前每个 MCP 服务器都得自己处理 OAuth 流程，各种边角情况踩不完。

最新的 MCP 规范在这块改进了不少。CIMD（Client ID Metadata Documents）简化了客户端注册的 OAuth 流程，用户首次授权更快，反复弹授权框的情况也少了。MCP SDK、Claude.ai 和 Claude Code 都已经支持这个规范。

对云端 Agent 来说，令牌的存储和刷新是另一个痛点。Managed Agents 的 Vault 机制处理了这个问题：注册一次用户的 OAuth 令牌，创建 session 时引用 Vault ID，平台自动把凭证注入每个 MCP 连接，过期了自己刷新。不用自己搭密钥管理服务，不用每次调用传 token。这个思路和 Kubernetes 里 ServiceAccount 自动挂载 token 的逻辑挺像的，让凭证管理变成基础设施的一部分，应用层不用操心。

上下文效率：Tool Search 和程序化调用

MCP 服务器越多，上下文占用越大，这个问题前面提到过。Anthropic 现在有两个客户端侧的优化模式。

Tool Search 是按需加载工具定义，不一次性全塞进上下文。Agent 运行时搜索工具目录，只拉取当前任务需要的工具。根据 Anthropic 的测试，工具定义相关的 token 占用能降低 85% 以上，选择准确率基本不受影响。

程序化工具调用是在代码执行沙箱里处理工具返回结果，而不是原样扔回给模型。Agent 可以在代码里循环、过滤、聚合多次调用的结果，只把最终输出放进上下文。复杂的多步工作流能省掉大约 37% 的 token。

两个模式叠加使用的效果更好：上下文更精简，往返次数更少，响应也更快。

Skills 和 MCP 是互补的

这个话题之前也聊过。简单说，MCP 给 Agent 能力（能调什么工具、能访问什么数据），Skills 给 Agent 知识（怎么用这些工具完成具体任务），两者最好结合着一起使用。

具体有两种组合模式。

第一种是把 Skills 和 MCP 服务器打包成 Plugin。Claude 的 Plugin 可以捆绑 Skills、MCP 服务器、Hooks、子 Agent 这些组件，一键分发。比如 Cowork 的数据 Plugin，里面有 10 个 Skills 和 8 个 MCP 服务器，覆盖 Snowflake、Databricks、BigQuery 这些数据工具。这种模式让 Claude 从通用助手变成领域专家。

第二种是让 MCP 服务器自带 Skill。Canva、Notion、Sentry 这些厂商已经在做了，在 Claude 的目录里把 Skill 和 Connector 放在一起。MCP 社区也在做一个扩展，让服务器直接分发 Skills，客户端自动继承，版本跟着 API 走。

我的体会是：MCP 服务器只提供工具的话，Agent 每次都得自己摸索调用顺序和参数搭配，效率不高。Skill 把最佳实践编码进去，等于给 Agent 附了一份操作手册，开箱就能按套路来。

写在最后

回头看生产环境 Agent 集成外部系统这件事，由于 Agent 跑在云上，需要连接的服务也在云上，中间就需要一个标准化的协议层。

相比直接 API 调用和命令行 CLI，MCP 目前是这个位置上最合适的协议，特别是远程 MCP 服务器。MCP 的优势在于它是开放协议，不绑定任何一家模型厂商，一个服务器建好了，Claude、ChatGPT 之类的任意 AI Agent 都能用。

相关资源：

• 原文链接：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
• MCP SDK 文档：https://modelcontextprotocol.io/docs/sdk
• MCP Apps 扩展：https://modelcontextprotocol.io/extensions/apps/overview
• 高级工具使用指南：https://www.anthropic.com/engineering/advanced-tool-use
• 写好 Agent 工具：https://www.anthropic.com/engineering/writing-tools-for-agents
• MCP 规范（含 CIMD 和 Elicitation）：https://modelcontextprotocol.io/specification/2025-11-25

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

看 YouTube 上的技术演讲，遇到讲得特别好的，想把要点记下来。以前的流程是：先找个在线工具下载视频，再找个工具提取字幕，字幕格式乱七八糟还得手动清理。一套下来，光找工具就花了半小时，笔记还没开始写。

另一个场景更折腾。录完一段产品 DEMO，画面有了，但没有解说，自己录需要反复调节奏。每次都在想，Claude Code 能帮我写代码，为什么不能帮我处理这些视频的活？

想了想，干脆自己写一个。

于是就有了 video-skills

video-skills 是我开源的一个视频处理 Skill 集合，包含三个技能：

• download-video：从 YouTube、Bilibili、Twitter/X 等 1000 多个平台下载视频
• transcribe-video：提取视频字幕，优先走内嵌字幕，没有才调 API 去转录
• narrate-video：给视频自动生成配音，画面和语音节奏对齐

三个技能可以单独用，也可以串起来。比如我最常用的流程是：下载一个 YouTube 视频 → 转成文字 → 拿着文字稿去做笔记整理。或者录完一段 DEMO → 让 Claude 看着画面写解说词 → 生成配音合进视频。

安装有两种方式。在 Claude Code 里直接：

/plugin marketplace add feiskyer/video-skills/plugin install video-skills@video-skills

或者用 npx：

npx skills add feiskyer/video-skills

前置依赖就两个：yt-dlp 和ffmpeg，macOS 用 Homebrew 装就行：

brew install yt-dlp ffmpeg

其他平台可以让 AI 帮你自动安装。

下面按我自己最常用的两个场景，看看它们的用法。

场景一：YouTube 视频变文字笔记

上周看到 Andrej Karpathy 一个新访谈，一个多小时，想先拿到文字稿挑重点看。打开 Claude Code，把链接丢进去：

帮我下载这个视频 https://www.youtube.com/watch?v=kwSVtQ7dziU

download-video 会用 yt-dlp 把视频拉下来，存到~/Downloads/Videos/。只要音频、指定 720p 这些，直接用自然语言说就行。

下载完接着转文字：

把刚下载的视频转成文字

transcribe-video 会先检查视频有没有内嵌字幕。YouTube 上很多视频自带字幕，质量比语音识别好，速度快，关键是不花 API 的钱。只有没字幕的时候才走 OpenAI 的gpt-4o-transcribe。转出来的文字稿自动清理了时间戳和格式标签，直接就是干净的纯文本。拿到文字稿再让 Claude 做个摘要，整个流程一气呵成。

没有内嵌字幕的视频需要配置 API Key，创建~/.transcribe_video.env：

OPENAI_API_KEY=your-key-here

也支持其他兼容 OpenAI API 的平台，加上OPENAI_API_BASE 就行。

不过下载和转录只解决了看视频的问题。如果你还需要编辑视频呢？比如录了个产品 DEMO，画面有了，但没声音。

场景二：录完 DEMO 自动配音

以前自己录个视频 DEMO，经常出现口误、卡壳、节奏不对等等的问题，录完还要花很长时间去剪辑，折腾半天才能搞定。

现在录好视频，直接一句话就可以搞定配音问题：

给这个 DEMO 视频加上中文配音 demo.mp4

Claude Code 会先每隔几秒截帧，看每个时间点屏幕上在发生什么，建一个场景时间表。然后根据画面写带时间戳的解说词，每段文字量只占时间窗口的 80% ，段落之间自然留白。最后调 Azure TTS 逐段生成语音，按时间戳合成到视频里。

不过使用时需要注意，配置 Azure 密钥，创建~/.narrate_video.env 并设置：

AZURE_SPEECH_KEY=your-key-hereAZURE_SPEECH_REGION=eastus

写在最后

video-skills 做的事情其实并不复杂，只是把 yt-dlp、ffmpeg、还有 Azure Speech 这些命令行工具和 AI 调用包进了 Skill，但用起来的流畅度完全不一样。感兴趣的话可以直接安装来试试：npx skills add feiskyer/video-skills。

video-skills GitHub 为https://github.com/feiskyer/video-skills，有任何问题欢迎贡献完善。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程师 Thariq（@trq212）发表的长文。上次他的文章分享了《像 Agent 一样思考：Claude Code 工具设计的进化史》，这次聊的是 Skill 怎么写才好用。原文链接：https://x.com/trq212/status/2033949937936085378。

写过 Claude Code Skill 的人应该都有一个体会：写出来容易，写好很难。

之前我推荐过不少好用的 Skill（《十个顶级 Claude Code Skills，装上就不想卸》《OpenClaw 必备 Skill 清单》），但“好用的 Skill 到底是怎么写出来的”这个问题一直没怎么聊过。市面上的教程大都停在”创建一个 SKILL.md 文件”这一步，至于写什么、怎么组织、哪些信息该放哪些不该放，基本没人系统讲过。

Anthropic 内部现在有几百个 Skill 在日常使用，Thariq 最近把他们踩过的坑整理成了一篇长文。我读完觉得信息密度挺高的，很多坑自己也踩过，但一直没想清楚为什么。这篇就把里面最有价值的部分整理出来。

先纠正一个常见误解

很多人觉得 Skill 就是一个 Markdown 文件。能跑，但没用好。

Skill 的本质是一个文件夹，里面可以放脚本、数据、模板、配置，Claude 能发现、探索和操作这些文件。另外，Skill 还支持很多配置选项（详见官方文档的 frontmatter 参考），包括动态注册 Hook。

Anthropic 内部用得最好的那些 Skill，恰恰是充分利用了文件夹结构和配置选项的。后面会具体聊到。

9 类 Skill：你的团队还缺哪些？

Thariq 把 Anthropic 内部所有的 Skill 做了一次盘点，发现它们大致可以归为 9 类。他说最好的 Skill 通常干净利落地属于某一类，而那些让人困惑的 Skill 往往横跨好几类。

这个分类不是什么权威定义，但作为一个自查清单挺实用的，可以看看你的团队还缺哪几类。

库和 API 参考

教 Claude 怎么正确使用某个库、CLI 或 SDK。可以是内部库，也可以是 Claude 经常用错的外部库。这类 Skill 通常会带一个代码片段文件夹和一份“踩坑清单”。

比如你内部的计费库有一堆边界情况，或者你的 CLI 工具有一些 Claude 不知道的子命令和用法。

产品验证

描述怎么测试和验证代码是否正确。通常会配合 Playwright、tmux 之类的外部工具来做验证。

这类 Skill 的价值在于确保 Claude 的输出是对的，而不是“它说对了就信它”。Thariq 的原话是：让一个工程师花一周时间专门打磨验证类 Skill，是值得的。

可以考虑的技巧包括让 Claude 录制测试视频方便回看，或者在每一步强制做断言。这些通常通过在 Skill 中放脚本来实现。

数据获取与分析

连接到你的数据和监控系统。这类 Skill 可能会包含带凭据的数据获取脚本、Dashboard ID、常见查询工作流。

比如“哪些事件表能看到注册→激活→付费的转化漏斗”，或者“Grafana 里哪个 dashboard 对应哪个问题”。

业务流程自动化

把重复性工作流一键化。比如自动聚合 ticket tracker、GitHub 活动和 Slack 消息来生成 standup，或者自动创建 ticket 并触发后续的 review 和通知流程。

这类 Skill 指令通常比较简单，但依赖其他 Skill 或 MCP。一个有用的技巧是把每次执行的结果保存到日志文件里，Claude 下次执行时可以参考上次的结果，保持一致性。

代码脚手架

为代码库中的特定功能生成框架代码。当你的脚手架有一些无法纯粹用代码覆盖的自然语言需求时，Skill 的优势就体现出来了。比如新建一个带你们标准认证、日志和部署配置的内部应用。

代码质量与审查

在团队内部强制执行代码质量标准。可以包含确定性脚本来保证鲁棒性。你可能想通过 Hook 自动触发这些 Skill，或者放到 GitHub Action 里跑。

比如启动一个全新视角的子 Agent 来挑刺，迭代到只剩 nitpick 级别的问题为止。

CI/CD 与部署

帮你拉代码、推代码和部署的 Skill。比如监控 PR 状态，自动重试 flaky CI，解决合并冲突，开启 auto-merge。或者做灰度发布时自动对比错误率，有回归就自动回滚。

Runbook

拿到一个症状（Slack 线程、告警或错误签名），走一遍多工具调查流程，输出结构化报告。这就是把 on-call 经验沉淀成了可执行的标准流程。

基础设施运维

执行日常维护和运维操作，有些涉及破坏性操作，所以 Skill 里可以内置安全护栏。比如查找孤立的 Pod/Volume，先发到 Slack 等一段时间确认，用户同意后再级联清理。

这 9 类基本覆盖了一个工程团队日常工作的方方面面。如果你的团队刚开始用 Skill，可以从这个清单出发，看看哪几类能最快产生价值。我自己的体感是验证类和业务流程自动化类最容易见效，因为它们解决的是每天都在重复的痛点。

知道了该做什么类型的 Skill，接下来的问题就是怎么写了。

怎么把 Skill 写好？

这部分是我觉得全文最有价值的，因为很多坑不踩一遍真想不到。

Anthropic 最近也发布了Skill Creator 来简化 Skill 的创建过程，但即使有工具辅助，下面这些原则还是得自己把握。

别写 Claude 已经知道的

Claude 本身就懂很多编程知识，对你的代码库也有不少了解。如果你的 Skill 主要是知识类的，重点放在那些能把 Claude 推出它默认思维模式的信息上。

frontend-design Skill 是个好例子。它是 Anthropic 的工程师跟客户反复迭代出来的，核心就是教 Claude 避免那些经典的 AI 审美，比如 Inter 字体配紫色渐变。这些才是 Claude 需要被纠正的地方，而不是告诉它“请写出高质量代码”。

好好写 Gotchas 部分

任何 Skill 里信息量最高的部分就是 Gotchas（踩坑清单）。把 Claude 使用你的 Skill 时经常犯的错记下来，随着使用不断补充。

我自己写 Skill 的经验也是这样。一开始写的 Skill 可能只有二三十行，用了一个月之后 Gotchas 部分比正文还长。因为每次 Claude 犯一个新错，你就加一条，这些积累才是 Skill 真正的价值所在。

用好文件系统和渐进式披露

前面说了，Skill 是文件夹，不只是 Markdown。你应该把整个文件系统当作上下文工程和渐进式披露（Progressive Disclosure）的手段。在 SKILL.md 里告诉 Claude 这个 Skill 里有哪些文件，它会在合适的时候去读。

最简单的做法是把详细的函数签名和用法示例拆到references/api.md 里。如果你的最终输出是 Markdown 文件，可以在assets/ 里放一个模板让 Claude 复制使用。

脚本、示例、参考文档，这些都可以分门别类放进 Skill 文件夹。Claude 知道它们在那儿，需要的时候自己会去找。

这个思路在上一篇《像 Agent 一样思考》里也聊过。从被动接收上下文到主动探索上下文，渐进式披露是 Claude Code 工具设计的核心理念之一。

别把 Claude 钉死

Claude 会尽量遵守你的指令，但 Skill 是会被反复使用的，如果指令太具体，它在某些场景下就会变得很死板。给 Claude 它需要的信息，但也给它根据具体情况灵活调整的空间。

比如不要写“必须按 A→B→C→D 四个步骤执行”，而是写“通常的流程是 A→B→C→D，但可以根据实际情况调整顺序或跳过某些步骤”。

想清楚初始化流程

有些 Skill 需要用户先提供一些上下文才能用。比如一个发 standup 到 Slack 的 Skill，需要知道发到哪个频道。

一个好的做法是把这些配置信息存到 Skill 目录下的config.json 里。第一次运行时，如果配置不存在，Claude 就问用户；配置好了以后就直接用，不再重复问。

如果你想让 Claude 给用户提结构化的选择题而不是开放式提问，可以让它调用AskUserQuestion 工具。

description 字段是写给模型看的

Claude Code 启动时会构建一个所有可用 Skill 的清单，每个 Skill 带上它的 description。Claude 扫这个清单来决定“当前这个请求有没有对应的 Skill”。

所以 description 不是给人看的摘要，而是给模型看的触发条件。你应该写清楚“什么时候应该触发这个 Skill”，而不是“这个 Skill 做了什么”。

这个细节我之前也没太注意，但仔细想想确实重要。如果 description 写的是“用于格式化代码”，Claude 可能在很多场景下都不确定要不要用。但如果写的是“当用户要求格式化代码、或代码风格不一致时触发”，触发率会准确得多。

给 Skill 加记忆

有些 Skill 可以通过存储数据来实现记忆功能。可以简单到往一个文本日志里追加内容，也可以复杂到用 SQLite 数据库。

比如前面提到的 standup Skill，如果每次执行都把内容追加到standups.log 里，下次运行时 Claude 读一遍历史，就能知道哪些是新变化，不需要从头分析。

需要注意的是，Skill 目录下的数据在升级 Skill 时可能被删掉。所以应该把数据存到稳定的位置。目前 Claude Code 提供了${CLAUDE_PLUGIN_DATA} 作为每个 Plugin 的稳定存储目录。

放脚本，让 Claude 组合

给 Claude 代码是你能做的最有力的事之一。把辅助脚本和库函数放到 Skill 里，Claude 就可以把精力花在组合和决策上，而不是从头写重复的样板代码。

比如在数据分析 Skill 里放一组从数据源拉数据的辅助函数，Claude 就可以按需组合这些函数来回答“周二发生了什么”这类问题。

按需 Hook

Skill 可以包含只在被调用时才激活的 Hook，持续到会话结束。适合那些比较“有态度”的 Hook，平时开着太烦，但某些场景下非常有用。

比如/careful，通过PreToolUse 拦截 Bash 里的rm -rf、DROP TABLE、force-push、kubectl delete。你只在碰生产环境时才想开它，平时开着只会让人抓狂。再比如/freeze，阻止 Claude 编辑特定目录之外的文件。调试的时候特别有用，你只想加日志，不想 Claude 顺手把不相关的代码也修了。

别忘了统计

顺便提一下分发和统计。Anthropic 内部用一个PreToolUse Hook 来记录 Skill 的使用情况（示例代码），这样就能发现哪些 Skill 被高频使用、哪些触发率低于预期。

分发方面，小团队直接把 Skill 提交到仓库的.claude/skills 目录就行。规模大了以后，可以搭建内部的 Plugin Marketplace，让团队成员自己选择安装哪些。Anthropic 内部没有一个集中的团队来决定哪些 Skill 上架。有人做了一个好用的 Skill，先放到一个 sandbox 目录让人试用，有了口碑再提 PR 进入正式市场。

还有一个需要注意的问题：Skill 之间的组合和依赖。比如你的 CSV 生成 Skill 依赖一个文件上传 Skill。目前 Marketplace 还没有原生的依赖管理，但你可以在 Skill 里直接引用其他 Skill 的名字，Claude 会自动调用已安装的。

写在最后

回头看这篇文章，最让我有感触的是 Gotchas 部分。我自己写 Skill 的经历也验证了这一点，Skill 的价值不在初始版本写得多完整，而在于使用过程中不断补充 Claude 犯过的错。一开始写个十几行的骨架，用一段时间后自然会长成一个成熟的 Skill。

另一个让我重新审视的是“别写 Claude 已经知道的”。我之前写过一些 Skill，里面有大段的编码规范和最佳实践，这些其实 Claude 本来就会。真正该写进 Skill 的是那些 Claude 不知道的、你的团队特有的知识，比如内部约定、踩过的坑、用什么工具查什么问题。

如果你已经在用 Skills 但觉得效果一般，不妨回去对照一下上面的原则，看看有哪些地方可以调整。如果你还没开始，从一个小的 Gotchas 清单开始就行，不需要一上来就做得很复杂。

相关资源：

• 原文链接：https://x.com/trq212/status/2033949937936085378
• Claude Code Skills 文档：https://code.claude.com/docs/en/skills
• Agent Skills 课程：https://anthropic.skilljar.com/introduction-to-agent-skills
• Skill Creator 博客：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills
• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• Skill 使用日志 Hook 示例：https://gist.github.com/ThariqS/24defad423d701746e23dc19aace4de5

话题标签：#ClaudeCode #Skills #Anthropic #AI 编程

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上次分享了《十个顶级 Claude Code Skills，装上就不想卸》，不少读者问我 OpenClaw 这边有没有类似的推荐。今天就来一篇。

跟 Claude Code 比，全新安装的 OpenClaw 其实挺无聊的。它能聊天、能写代码、能操作文件系统，但碰到需要上网搜东西、刷个社交媒体、或者画张图的场景，就卡住了，看起来跟 ChatGPT 之类的聊天工具并没有多大区别。但这其实是还没用好 OpenClaw 最基本的扩展机制，也就是 Skill。ClawHub 上的 Skill 数量已经破了 25000，光是排名第一的 self-improving-agent 就有 20 多万的安装量。不过 Skill 装多了也有问题，互相打架不说，上下文也吃不消。所以关键还是选对几个真正有用的。

这篇就整理一份我自己在用的 OpenClaw Skill 清单，每个都有附安装命令，方便你一键安装。

先装这三个

这三个 Skill 我觉得属于必备级别，建议第一时间搞定。

Self-Improving Agent

ClawHub 排名第一不是没道理的。

这个 Skill 让 OpenClaw 具备了自我学习的能力。每次你纠正它的错误、每次命令执行失败、每次它发现了更好的做法，都会被记录下来，变成它下次做事的经验。用得越久，它就越懂你的习惯和偏好。

我用了一段时间之后，最明显的变化是它不再重复犯同一个错了。比如我习惯用 pnpm 而不是 npm，纠正过一次之后就再也没出过。听起来是个小事，但每天省几次纠正的功夫，累积下来效率提升挺明显的。

npx clawdhub install self-improving-agent

Find Skills

OpenClaw 不像 Claude Code 那样内置了大量工具，很多能力需要通过 Skill 来补齐。问题是 ClawHub 上 25000 多个 Skill，你怎么知道哪个能解决你当前的问题？

Find Skills 做的就是这件事。当你问 OpenClaw“怎么做 X”的时候，它会先去 ClawHub 搜一圈，看看有没有现成的 Skill 能用，找到了就直接推荐给你，省得自己一个个去翻。

有点像给 OpenClaw 装了个应用商店的搜索入口。

npx clawdhub install find-skills

Skill Vetter

前面说了 ClawHub 上有 25000 多个 Skill，质量参差不齐。有的 Skill 写得不错，有的可能藏着恶意代码，毕竟 Skill 本质上就是一段会被 Agent 执行的指令。

Skill Vetter 的作用是在安装前自动扫描 Skill 的内容，检查有没有潜在的安全隐患。比如 Skill 里是否有可疑的网络请求、是否试图读取敏感文件、是否包含 prompt injection 的模式。

如果你对安全要求更高，可以搭配慢雾（SlowMist）出的 OpenClaw 安全实践指南一起用。那份指南走的是零信任路线，默认假设 prompt injection、供应链投毒都可能发生，从日常操作到每晚巡检都有覆盖。对于在高权限环境下跑 OpenClaw 的用户来说，值得过一遍。

npx clawhub install skill-vetter

附安全实践指南链接：https://github.com/slowmist/openclaw-security-practice-guide

让 OpenClaw 能上网

裸机的 OpenClaw 没有联网能力，不能搜索、不能访问网页。这三个 Skill 分别解决搜索、浏览器操作和长文提炼三个场景。

Tavily Search

给 OpenClaw 加上网络搜索能力。Tavily 有月免费额度，对个人用户来说日常搜索基本够用，不需要一上来就掏钱。

搜索质量比让 OpenClaw 去 curl 一个搜索引擎然后解析 HTML 好太多了。返回的结果是结构化的，直接就能用。

npx clawhub install tavily-search

Agent Browser

有些事光靠搜索引擎搞不定。比如你要操作一个需要登录的后台、要在某个网站上填表单、或者要从一个动态加载的页面抓数据，这些都需要真正的浏览器。

Agent Browser 让 OpenClaw 能控制浏览器，点击、输入、截屏、导航，该有的都有。

这里有个关键技巧：用--auto-connect 参数连接到你已经登录过的 Chrome 浏览器。这样 OpenClaw 就能直接用你的登录态，不用每次都重新登录各种服务。省事太多了。

npx clawhub install agent-browser

Summarize

经常需要让 OpenClaw 帮你读一篇长文章或者处理一段音视频，Summarize 就是干这个的。给它一个网址、一个文件路径、或者一段媒体，它帮你快速生成摘要。

用之前需要先装个全局依赖：

npm i -g @steipete/summarizenpx clawhub install summarize

搜索、浏览器、摘要，三个加一起，OpenClaw 在信息获取层面就基本没有短板了。不过这还只是读的能力。如果你还想让它去社交媒体上逛，那就需要下面这组 Skill。

社交媒体三件套

这三个 Skill 来自同一个开发者 jackwener，做的事情就是让 OpenClaw 等各种 Agent 能搜索、访问和交互主流社交平台的内容。

小红书：

npx skills add jackwener/xiaohongshu-cli

Twitter/X：

npx skills add jackwener/twitter-cli

Reddit：

npx skills add jackwener/rdt-cli

我自己用得最多的是 xiaohongshu-cli 和 twitter-cli。比如想要了解某个工具的用户评价，让 OpenClaw 去小红书和 Twitter 上搜一圈，回来给我整理个摘要，比自己去翻快多了。

jackwener 还开源了 Bilibili、Telegram、Discord、微博、BOSS 直聘等平台的 CLI 工具和对应 Skill，需要的可以去他的 GitHub 上看看。

锦上添花

下面这几个不是每个人都需要，但如果你的使用场景刚好对上了，装了之后体验会好一截。

Proactive Agent

普通 OpenClaw 是你给任务它才干活。Proactive Agent 让它变得主动一些，能自我迭代、主动发现问题、主动优化方案。

npx clawhub install proactive-agent

GitHub

有开源项目要维护，或者想给别人的项目提 PR，这个 Skill 让 OpenClaw 能直接操作 GitHub 的 Issues、PR、Code Review 等工作流。

npx clawhub install GitHub

Nano Banana Pro

用 Gemini 3 Pro 的图像生成能力，让 OpenClaw 能画图。支持文生图和图生图，1K/2K/4K 分辨率都行，编辑已有图片也可以。做封面图、画流程图、生成配图的时候挺方便的。

npx clawhub install nano-banana-pro

Mcporter

OpenClaw 本身不支持 MCP 工具。如果你之前在 Claude Code 上用惯了各种 MCP Server，换到 OpenClaw 会觉得少了点什么。

Mcporter 做的是格式转换：把 MCP 工具转成 CLI 格式，再作为 Skill 给 OpenClaw 使用。算是一个桥接方案，让你之前的 MCP 生态投资不至于浪费。

npx clawhub install mcporter

以上就是我目前在用的 OpenClaw Skill 组合：先把自学习和安全两个基础打好，再把联网和社交媒体的信息通道打通，最后根据自己的工作场景挑几个辅助工具。而至于编程呢，还是把专业的事情交给专业的工具，继续交给 Claude Code 来负责。你可以用 OpenClaw 的 ACP Agent 来调度 Claude Code，顺手也解决了手机访问的问题（接入 Slack/Discord/飞书等可以随时手机下发任务）。

如果这些还不够用，下面这几个地方可以继续探索：

相关资源：

• ClawHub 官网：https://clawhub.ai/
• Awesome OpenClaw Skills：https://github.com/VoltAgent/awesome-openclaw-skills
• OpenClaw Skills 仓库：https://github.com/openclaw/skills
• SkillsMap：https://skillsmp.com/
• Skills.SH：https://skills.sh/
• Awesome OpenClaw Usecases：https://github.com/hesamsheikh/awesome-openclaw-usecases

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

用 Claude Code 大半年了，Skills 和 Plugin 装了几十个，删了一半，留下来的都是真正改变了我工作方式的。这篇就挑十个我用得最多、也觉得最值得推荐的，每个都附安装命令，拿去直接用。

先简单说下 Skill 和 Plugin 的区别。Skill 是一个包含 SKILL.md 的文件夹，教 Claude 怎么做某类任务；Plugin 更完整，可以打包命令、SubAgent、Hook 和 MCP 服务器。不过对使用者来说差不多，下面就不区分了。

Superpowers

如果只能装一个，我选这个。

Superpowers 打包了 20 多个可组合的 Skill，覆盖软件开发的完整流程。brainstorming、TDD、代码审查、Git 提交，每个环节都有对应的 Skill 来约束 Claude 的行为。

我用得最多的是 brainstorming。装了之后，Claude 不会拿到需求就直接开写，而是先问你一轮问题，探索不同方案，把设计决策摊开讨论，最后生成一份设计文档存到本地。看似慢了，实际上能省掉后面大量返工。你会发现很多问题在讨论阶段就暴露了，而不是写了三百行代码之后才发现方向不对。

另一个常用的是 TDD 工作流。它会强制 Claude 先写测试再写实现，跑不过就继续改，直到全绿。Claude 的默认行为是直接写代码然后告诉你“应该没问题”，有了这个约束差别非常大。

当然，20 多个 Skill 全开可能有点重。我一般只启用 brainstorming 和 TDD 两个，其他的按需打开。

claude plugin install superpowers

GitHub:https://github.com/obra/superpowers

Planning with Files

Claude Code 自带的 Plan Mode 有个让人头疼的问题：规划存在对话上下文里，上下文一压缩就丢了。长任务做到一半，Claude 忘了自己在干嘛。又从头开始。

Planning with Files 把规划、进度和知识都写进 Markdown 文件。Claude 开始干活前先创建计划文件，每完成一步就更新进度，遇到有用的信息就记到知识文件里。文件在磁盘上就不会丢，即使上下文被压缩了也能恢复状态。

这个思路其实来自 Manus。Manus 在复杂任务上表现好，核心原因之一就是中间状态都持久化了。Planning with Files 算是社区版的实现。

claude plugin marketplace add OthmanAdi/planning-with-filesclaude plugin install planning-with-files

GitHub:https://github.com/OthmanAdi/planning-with-files

UI UX Pro Max

让 Claude 写前端页面，出来的东西大都长一个样。紫色渐变背景，圆角卡片，居中布局，也就是典型的 “AI 审美”。

Anthropic 官方有个 frontend-design Skill 能改善一些，但 UI UX Pro Max 做得更彻底。它内置了 67 种 UI 风格和 161 套行业配色方案，根据你的项目类型自动推荐设计系统，从配色到排版到交互模式，一步到位。我试着让它做一个 SaaS 后台的 dashboard，选了 Bento Grid 风格，出来的效果比 Claude 默认的好太多，至少看起来不像 AI 做的了。

技术栈方面，React、Vue、Svelte、SwiftUI、Flutter 这些都支持，不只是 Web。

claude plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skillclaude plugin install ui-ux-pro-max@ui-ux-pro-max-skill

GitHub:https://github.com/nextlevelbuilder/ui-ux-pro-max-skill

聊完前端设计，下一个自然要聊的就是代码质量了。

Code Review

这是官方 Plugin 里我觉得设计最精巧的一个。

它不是让一个 Claude 从头到尾看代码，而是启动多个 Agent 并行审查同一个 PR。有的看逻辑正确性，有的看安全漏洞，有的看代码风格。每个 Agent 给出的问题都带置信度分数，最后按分数过滤，只保留高置信度的反馈。

为什么要搞这么复杂？因为 AI 代码审查最大的问题是假阳性太多。以前让 Claude 审代码，它总能挑出一堆潜在问题，看着很认真，但大部分都是过度谨慎的废话。有了置信度过滤之后，留下来的基本都值得看一看。

不过使用时要注意，大 PR 跑起来 token 消耗挺猛的，好几个 Agent 同时跑，一次 review 吃掉的 token 可能比写代码本身还多。小 PR 用着挺舒服，大 PR 建议先拆再审。

claude plugin install code-review

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-review

Code Simplifier

写代码的时候容易堆逻辑，写完跑通了就不想再碰了。Code Simplifier 帮你做那个“写完再看一遍”的事情。

它聚焦最近修改过的代码，检查重复逻辑、多余的中间变量、可以合并的条件分支。不改功能，只做简化。上次我写了一段数据处理的逻辑，里面有三段几乎一样的错误处理，跑完 Code Simplifier 它给合并成了一个通用函数，代码量少了三分之一。

claude plugin install code-simplifier

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier

Webapp Testing

前端写完了，测试怎么办？手动点来点去太慢，写 Playwright 脚本又太繁琐。这个 Skill 把过程自动化了：你告诉 Claude 要测什么场景，它自己用 Playwright 写脚本、启动浏览器、跑测试、截屏，有问题还会自己调试。跟前面的 UI UX Pro Max 搭配起来特别顺手。

claude plugin marketplace add anthropics/skillsclaude plugin install example-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/webapp-testing

Ralph Loop

名字来自辛普森动画里的 Ralph Wiggum，Anthropic 工程师 Daisy Hollman 做的。通过 Stop Hook 拦截 Claude 的退出，把同一个任务重新喂给它。

Claude Code 有个习惯：做到一半觉得差不多了就停下来说“我已经完成了基础框架，你可以在此基础上继续”。Ralph Loop 不让它停。Claude 试图退出，Hook 拦截，检查完成条件，没满足就塞回去。循环往复，直到真正做完。

简单粗暴，但真的管用。

用这个有个关键技巧：完成条件要写得越具体越好。做完这个功能不行，Claude 会自己说服自己已经完成了。要写“所有 CRUD 端点可用，测试覆盖率超过 80% ，README 包含 API 文档，完成后输出 COMPLETE”。条件越模糊，它越会找理由提前收工。

claude plugin install ralph-loop# 使用示例/ralph-loop:ralph-loop"实现用户认证模块。完成标准：JWT 登录注册、测试通过、README 更新。完成后输出 COMPLETE" --max-iterations20 --completion-promise"COMPLETE"

更好详细例子可以参考:https://awesomeclaude.ai/ralph-wiggum

MCP Builder

MCP 这个协议最近讨论度挺高，但真要从零写一个 MCP Server，门槛还是不低。MCP Builder 把构建过程拆成了四个阶段，引导 Claude 一步步完成：理解 API、设计工具接口、实现、测试。

用它的体验比直接让 Claude “帮我写一个 MCP Server”好很多。直接写的话 Claude 经常漏掉 rate limiting 和 token 过期处理等等之类边界情况，用了 MCP Builder 之后这些它都会主动考虑。

claude plugin marketplace add anthropics/skillsclaude plugin install example-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/mcp-builder

PPTX

做 PPT 大概是程序员最不想做的事。

这个 Skill 让 Claude 直接生成.pptx 文件，支持母版、图表、动画。说实话，生成的 PPT 不可能直接拿去做重要汇报，内容、排版和配色都还需要适当调整。但用它生成初稿已经完全够用了，可以大大节省 PPT 得创作时间。

它解决的是“从零开始太痛苦”的问题。起点有了，后面就快了。

claude plugin marketplace add anthropics/skillsclaude plugin install document-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/pptx

Skill Creator

最后一个放 meta 的。Skill Creator 是 Anthropic 官方出的，用来帮你创建新的 Skill 的技能。

之前我写过一篇文章聊它的更新（《写 Claude Skill 最大的盲区，Anthropic 终于帮你补上了》），核心变化是加了 eval 测试框架。现在你可以给 Skill 写测试用例，验证它到底有没有在起作用，还能做 A/B 对比，有 Skill 和没 Skill 的效果差多少，看数据说话而不是凭感觉。

上面九个用完了觉得不够？那就自己造。

claude plugin install skill-creator

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator

选 Skill 跟选工具一样，不在多，在合适。装太多互相打架，反而会影响整体的性能，并且上下文也吃不消，所以精选几个足够用即可。

另外，对不同功能的 Skills，特别是仅跟项目相关的 Skills，推荐放到项目中，提交到 Git，即方便了管理和团队共享，还节省了其他项目的上下文空间。

相关资源：

• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• Anthropic 官方 Plugins 仓库：https://github.com/anthropics/claude-plugins-official
• Awesome Claude Skills 社区列表：https://github.com/travisvn/awesome-claude-skills
• Claude Code Skills 文档：https://code.claude.com/docs/en/skills
• Skills 市场：https://skillsmp.com/

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

装完 OpenClaw 之后，很多人就拿它聊聊天、写写文案，然后觉得也就那样。

说真的，太浪费了。

OpenClaw 的核心设计不是聊天机器人，而是一个可以帮你执行任务、跑定时任务、自主完成工作的 Agent。它不只是回答你问题，还能帮你干活，编程、写作、跑脚本、调度其他 AI 工具干活，甚至在你睡觉的时候悄悄把明天的工作准备好。

下面分享几个我自己在用的玩法，从简单到复杂，随便挑一个入手。

AI 日报自动生成

这个应该是最简单的使用场景了。你可以让 OpenClaw 帮你自动从指定的技术博客、RSS 订阅源、社交媒体抓取最新内容，AI 打分筛选，每天推一份精选到你的 Slack 或者飞书上。

这种配置以往还需要专门写个程序，然后再去告诉 AI 调用。现在则不需要了，只要告诉 OpenClaw 你想要抓取哪些链接，它就可以帮你自动写好代码，并在需要时问你要相关的 API Key，然后帮你配置好定时任务。

OpenClaw 支持完整的cron 表达式，心跳任务走独立的队列通道，不跟实时消息抢位置。就这点，让定时任务真的靠谱，不会漏发。

让 OpenClaw 调度 Codex 和 Claude Code

这是我最近觉得最有意思的玩法。

OpenClaw 内置了coding-agent Skill，专门用来把编程任务委托给 Codex 或 Claude Code。你跟 OpenClaw 说“帮我用 claude 修复项目中的 xxx bug”，它把任务拆好之后，直接在后台起一个 Codex 或 Claude Code 进程去干，干完了通知你。

OpenClaw 不会一直等着这些结果，而是异步运行这些 Agent，你可以继续聊别的，它在完成后会主动通知你。甚至还可以让多个任务同时跑，不同任务跑在不同的 git worktree，互不干扰。

Codex 的调用方式差不多，把claude 换成codex 就行。这两个编程工具我都在用，各有适合的场景。

不过它这个 Skill 有时候也不太稳定，有时候也很影响效率。后面打算做两个专门的 Codex 和 Claude Code Skill，等稳定了之后再开源出来。

变成你的第二大脑

OpenClaw 天然有持久记忆，你只需要充分利用它。

比如给 OpenClaw 接上 Slack，然后你就可以随时给 Bot 发消息，说记住这个，它就永久存到自己的记忆中了。

如果记忆文件比较多，或者你想接入已有的知识库（比如可以把 Markdown 格式的文档目录直接配置到 OpenClaw 的记忆中），你还可以开启 OpenClaw 的混合检索，在 Markdown 记忆文件之上再加上向量搜索，相当于给 Agent 配了一套 RAG 系统，存进去的东西可以更快检索到。

传统笔记软件的核心矛盾一直是存进去容易，找出来难，而这种 Agent+RAG 系统可能是第一次从根本上解决这个问题。

内容创作工厂

给内容生产装一条流水线，是另一个我觉得很有意思的玩法。

给 OpenClaw 装备三个分工明确的 Agent：研究 Agent 每天自动扫描汇总热点（跟 AI 日报生成一样的逻辑），输出几个有意思的选题；写作 Agent 拿到选题构建大纲，撰写草稿；配图 Agent 根据内容生成封面图和文章配图。把这个流程配置成定时任务，你什么都不做，图文并茂的文章就帮你写好了。

这个模式的关键是每个 Agent 只做一件事，每件事都是一个固定的 workflow。研究 Agent 不管写作，写作 Agent 不管配图，配图 Agent 只看内容生图。上下文干净，输出质量稳定，比塞给一个 Agent 全做强得多。

不过说实话，这个模式实际跑起来并不会很美好。AI 写的初稿质量参差不齐，很多内容还都需要你做大量修改才能符合你的要求。

K8s 安全部署

想让 OpenClaw 7×24 稳定跑起来，最简单是一台 Mac Mini，但如果你本来就有 K8s 集群，容器化放进去更省心。K8s 给它三层保护：容器隔离、网络策略、资源限制。容器不碰宿主机文件系统，Network Policy 只放行外部 API 出口、挡住内网，资源上限防止失控吃算力。

我自己维护了一个 Helm Chart：feiskyer/openclaw-kubernetes，内置了 LiteLLM 作为模型网关。API Key 统一管在网关层，OpenClaw 只知道本地的 LiteLLM 地址，拿不到真实密钥，这样就算哪个 Skill 出问题也泄不出去。一条命令部署：

helm install openclaw oci://ghcr.io/feiskyer/openclaw-kubernetes/openclaw\ --create-namespace --namespace openclaw\ --set secrets.openclawGatewayToken=$gatewayToken\ --set secrets.telegramBotToken=$telegramBotToken

一个安全细节要注意，OpenClaw 的 Web 前端没有任何认证，千万不要直接暴露到公网上。正常使用，接入 Telegram、Slack 之类的聊天工具，在聊天工具中给 OpenClaw 发指令也完全不需要把 GateWay 公开。

玩法灵感库

如果看完这些还是不知道从哪入手，GitHub 上有个awesome-openclaw-usecases 仓库，收集了 30 个已验证的真实用例，也可以去看看，找找灵感。

几个让我印象深的案例：

语音确认出席。活动前让 OpenClaw 依次拨打每个嘉宾的电话，通过 AI 语音对话确认到场情况，最后汇总成一份报告。用的是 Telnyx 的语音接口，整个流程零人工介入。

Reddit→MVP 流水线。用Last 30 Days 这个 Skill 挖掘 Reddit 和 X 上最近一个月的真实用户吐槽，整理出痛点，然后让 OpenClaw 直接写一个 MVP。比如，研究 OpenClaw 的用户反馈，发现“初始配置太难”是高频问题，Agent 直接就做了一个配置向导 Web 应用出来。

AI 收益追踪。每次科技公司财报前自动准备摘要，财报后推送分析和对比，永远不会漏掉关注的公司。

写在最后

说到底，OpenClaw 能干多少事，取决于你给它配了多少 Skills、设计了多少 cron 任务。它就像一个本来什么都不会但极其听话的员工。你得先告诉它能用什么工具、怎么做事，它才会越来越有用。

Skills 生态现在挺成熟了。官方的ClawHub 上架了 1 万多个 Skill，直接clawhub install <skill-name> 一条命令就可以安装。VoltAgent/awesome-openclaw-skills 是社区维护的精选列表，按分类整理了数千个 Skill，找灵感比直接搜 ClawHub 更快。

当你碰到问题时，不妨到这里搜一搜，说不定就能找到你想要的。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。