Skill 本质解构：OpenClaw 如何用结构化 Markdown 实现 5 类可复用操作文档

1. Skill 不是“功能按钮”，而是可执行的结构化契约

大多数人第一次看到 OpenClaw 的Skill概念时，下意识会把它当成一个带 UI 的快捷操作——点一下“生成测试用例”，点一下“重构函数签名”，点一下“补全异常处理”。我最初也这么想。直到我们团队在交付一个金融风控接口模块时，连续三次被 QA 打回：不是逻辑漏判，而是同一个边界条件（空字符串输入触发下游空指针）在三个不同 Skill 中被反复遗漏。我们翻日志发现，这三个 Skill 分别由三位同事维护，各自写了一段相似但不一致的校验逻辑，没人意识到它们本该共享同一份约束定义。

那一刻我才真正理解：OpenClaw 的 Skill 本质不是代码片段，而是一份可被机器解析、可被人类评审、可被版本控制的结构化契约（Structured Contract）。它用 Markdown 这种人机共读的格式，把“做什么”、“怎么做”、“在什么条件下做”、“失败了怎么退”全部锚定下来。它的核心价值不在于让 AI 多快写出代码，而在于让团队对“自动化行为”的预期达成精确共识。

这个认知转变直接改变了我们后续所有 Skill 的设计方式。比如现在写一个validate-input-formatSkill，我们不会直接塞一段正则匹配 Python 代码进去，而是先定义：

• 输入 Schema（必须含field_name,expected_type,allow_empty字段）
• 预期输出（{ "valid": bool, "error_mes