夜雨聆风AGENT-007 · Day 3 主文
前两天讲了工作空间怎么搭、记忆系统怎么修。今天讲让整件事真正值回票价的那个部分。
OpenClaw 的日常用法，是你发消息、它回答。这是被动响应模式，本质上和用 ChatGPT 没什么区别，只是多了一些记忆和配置。
SKILL.md 解决的是一个不同的问题：怎么让 Agent 在你不问它的时候，主动把事情做完。
每周一早上，本周日历分析已经在桌面上；每天八点，邮件摘要已经推过来；每月一号，订阅账单报告已经生成好。你没有发任何消息，它就做了。
这不是魔法，是 SKILL.md 在工作。
提示词和 SKILL.md 的本质区别
你在对话框里发的提示词，解决的问题是：这次，我要它做什么。
SKILL.md 解决的问题是：以后，在什么情况下，它应该自动做什么。
这个区别比看起来要深。
提示词是一次性的指令，生命周期就是这一轮对话。SKILL.md 是持久的行为定义，被注册进 OpenClaw 之后，每次符合触发条件就激活，和你有没有在线无关。
从结构上说，一个提示词只回答「怎么做」，SKILL.md 要回答三个问题：什么时候触发、执行什么流程、什么情况下不执行。 第三个问题是大多数人写 SKILL.md 时跳过的，也是工作流出问题的主要来源。
三种触发机制，各有代价
SKILL.md 支持三种触发方式，每种有不同的可靠性和适用场景，选错了比不用还糟。
定时触发（schedule 字段）
最可靠的触发方式。在 frontmatter 里写 schedule: "monday 8am"，每周一早上八点准时执行，不需要你做任何事。
适合有固定节奏的任务：周报、日历预警、订阅审计。
一个容易忽略的细节：定时触发的时间以你配置文件里的时区为准，不是服务器时区。如果你在上海但 OpenClaw 服务器在美国，没有正确配置时区，「每周一早上」会在周日深夜执行。
关键词触发（description 语义匹配）
你在对话里说「帮我查一下本周日历」，OpenClaw 匹配所有已注册的 SKILL.md，找到 description 最相关的那个，自动激活。
description 的写法直接决定触发准确率——这一点很多人不知道。
写太宽泛，比如「处理所有工作相关的任务」，会误触发。你说「帮我写封邮件」，它也可能激活这个工作流，然后做了一堆你没想要的事。
写太窄，比如「当用户说'帮我生成本周日历摘要'时触发」，会漏触发。你说「看看我这周有什么会」，匹配不上，工作流没激活，直接用默认方式回答。
正确的写法：覆盖用户可能用的多种表达，同时限定核心意图：
description:查询和分析用户的日历安排。当用户询问日程、会议、这周有什么、明天安排如何时触发。仅处理日历查询，不处理日历修改或创建。HEARTBEAT 触发
HEARTBEAT 是 OpenClaw 的定期探活机制——系统每隔一段时间发一个 ping，Agent 醒来检查有没有需要处理的事情。
适合需要实时监测的场景：收到带特定关键词的邮件就通知我、价格低于某个阈值就提醒我。
代价是持续的资源消耗。HEARTBEAT 触发的工作流在每次 ping 时执行一次检查，检查逻辑越复杂，积累的 token 消耗越可观。只把真正需要实时监测的任务放在 HEARTBEAT 里。
SKILL.md 的三段式结构
一个能稳定运行的 SKILL.md，正文需要覆盖三个部分：When to trigger、Process、Rules。
When to trigger
比 frontmatter 里的 schedule 和 description 更细——在什么时候执行，什么情况下跳过：
## When to trigger- 定时：每周五 17:00- 关键词：用户要求生成周报、复盘、工作总结- 跳过：如果今天是节假日，延到下个工作日- 跳过：如果本周日历数据不可用，输出错误提示Process
步骤要具体，顺序要合理。写 Process 的核心原则：先读后写，先验证后执行。
## Process1. 读取本周日历（周一到周五所有事件）2. 读取本周已完成的任务列表3. 验证：如果两项数据都为空，停止执行，告知用户4. 生成复盘文档：本周完成的事、遇到的问题、下周优先级5. 展示草稿，等待用户确认6. 用户确认后保存到 memory/YYYY-MM-DD-review.md注意第 3 步：验证。很多工作流在数据缺失时会继续执行，生成一份空白或错误的输出。加验证步骤，是让工作流「优雅失败」而不是「静默出错」的关键。
Rules
这是最常被跳过但最重要的部分。Rules 定义工作流的边界——什么绝对不做，遇到什么情况怎么处理：
## Rules- 不修改、不删除任何日历事件- 不自动发送任何邮件或消息- 如果某个任务的状态不确定，标注「需确认」而不是猜测- 生成的文档保存前先展示给用户预览- 运行时间超过 3 分钟，输出当前进度并等待用户指令没有 Rules 的工作流，是一个没有边界的 Agent——它会在你没预料到的情况下做出你没预料到的决定。
skills/ 文件夹的二级目录
大多数人把 SKILL.md 直接平铺在 skills/ 下面，这能用，但有一个浪费：工作流用到的参考资料（示例输出、格式模板）要么塞进 SKILL.md 本身，要么放进 AGENTS.md，两者都在污染常驻上下文。
正确的结构是给每个技能建子目录：
skills/├── weekly-review/│ ├── SKILL.md│ └── references/│ ├── example-output.md│ └── template.md└── email-digest/ ├── SKILL.md └── references/ └── sender-rules.mdreferences/ 里的文件只在这个技能被激活时加载进上下文，平时不存在。一个复杂工作流的参考资料可能有几千字，这种方式让它只在用到的时候才占空间。
从需求到 SKILL.md：完整案例
需求：每周五下午五点，自动生成本周工作复盘，保存到记忆文件夹。
设计步骤：确定触发方式（固定时间 + 偶尔手动）→ 梳理流程（先读后写）→ 写 Rules（想清楚边界）。
---name:weekly-reviewdescription:生成每周工作复盘报告。当用户说「生成周报」「本周复盘」「周五复盘」时触发，或按定时计划自动运行。schedule:"friday 17:00"---# 每周工作复盘## When to trigger-定时：每周五17:00自动运行-关键词：用户主动要求生成周报或复盘-跳过：节假日不自动运行，等用户手动触发## Process1.读取本周（周一到今天）的日历事件2.读取本周标记为完成的任务3.验证：日历和任务均为空则停止，提示用户4.生成复盘报告：-本周主要工作（按重要性，不超过5条）-未完成事项和原因-下周优先级（最多3项）5.展示草稿给用户，等待确认6.确认后保存到memory/YYYY-MM-DD-weekly-review.md## Rules-不自动保存，必须用户确认后才写入-不修改任何日历或任务-不确定的内容标注「待确认」，不猜测-整份报告不超过500字这是 SKILL.md 的完整逻辑链。任何工作流需求都可以套进这个框架。
副文 A 讲 gws 工具链——真正让工作流有数据可用的那把钥匙。副文 B 逐一拆解五个高价值工作流的设计决策，看懂了能举一反三。
互动：你最想自动化的一个重复工作是什么？留言，我来帮你写 SKILL.md。
提示词模板
帮我把以下工作需求转化成一个 SKILL.md：需求描述：[你想自动化的任务]触发方式偏好：[定时 / 关键词 / 两者都有]可用工具：[Gmail / Calendar / 飞书 / 其他]最重要的限制：[不能做什么]输出要求：给出完整的 SKILL.md，包括 frontmatter 和正文，并在每个关键决策点加注释说明你为什么这样写。