引言

OpenClaw 的 Skill（技能）机制，让用户能把”重复的手工操作”固化为可复用的 AI 能力。然而，从”写一个 SKILL.md”到”它真的在正确场景自动触发、稳定可靠地完成任务”，中间还有一段工程化的打磨过程。本文以”将日常运维流程固化为 Skill”为例，拆解完整的开发、测试与上线链路。

一、先想清楚：什么值得固化为 Skill

并非所有任务都适合做成 Skill。一个合格候选应同时满足：流程相对固定、会被反复执行、步骤可标准化。判断时先问三个问题——这个操作我做几次了？步骤是否一成不变？能否用清晰的指令描述？

以运维为例，”排查博客无法访问”就是一个典型候选：它包含固定的检查顺序（SSH → 看服务状态 → 查日志 → 定位根因），非常适合固化为诊断 Skill。

二、SKILL.md 的结构与触发设计

一个可用的 Skill 由 SKILL.md 及可选资源文件构成。SKILL.md 的 frontmatter 至关重要——name 与 description 决定了它能否被准确触发。description 应包含触发关键词与场景，让 AI 在遇到匹配任务时自动加载该 Skill。

---
name: "blog-outage-diagnostics"
description: "Triage blog.azcore.top being down. Use when the blog cannot be opened, returns an error, or after an upgrade the site broke."
---

description 写得越具体（含站点名、报错形态），触发越精准，误触发越少。

三、编写步骤：可执行的指令，而非散文

正文部分应使用可执行的祈使句，按顺序列出检查步骤，并明确每一步的产出与退出条件。避免空泛描述，多用具体的命令、工具与判定标准：

## 步骤
1. SSH 到服务器，检查 Nginx 与 PHP-FPM 状态
2. 查看最近错误日志（tail -f /var/log/nginx/error.log）
3. 用 curl 验证站点响应码，判断是否 502/504
4. 定位根因并给出修复方案

清晰的指令让 AI 无需每次重新设计流程，直接按既定路线执行，从而保证输出的一致性。

四、纳入上下文：让 Skill 用起来

写好 SKILL.md 后，把它放到 Skill 目录并确保 OpenClaw 能发现它。验证触发是否生效，最直接的方式是在对话中抛出匹配的场景，观察 AI 是否自动加载该 Skill、并按步骤执行。若未触发，往往是 description 的关键词与场景不匹配，需回头调整。

五、测试与迭代：从小样本到稳定

Skill 上线后，先在真实或模拟场景下跑几次，记录”哪些步骤可靠、哪些会跑偏”。对于故障诊断类 Skill，最好用历史故障案例做回放验证。发现脚本或步骤有误时，直接编辑 SKILL.md 修正——Skill 本就是可版本化、可迭代的活文档。

总结

把日常流程固化为 OpenClaw Skill，本质上是在”替未来的自己写一份操作手册”。关键是：选对候选、写清触发、给出可执行步骤、用真实场景验证。一个打磨成熟的 Skill，能把原本需要反复推敲的重复劳动，压缩成一句”帮我执行”。