# Lesson 00｜从“能跑”到“可复用”：OpenClaw 用例工程方法

# 核心问题

很多同学第一次用 OpenClaw，会把目标定成“脚本能跑、能发消息”。但一旦进入真实场景（长期 cron、多来源抓取、多账号、多人协作），你会发现：真正的成本不在写出第一版，而在第二天还能跑、第三周还能扩展、半年后还能被别人接手。

这一课讲“用例工程化”的最低可行方法：把一次成功变成可复用资产。

# 案例（真实）

# 案例 A：Overnight Goal Autopilot（从目标到产物）

夜间无人值守推进长期目标，不只输出“想法”，而是落盘 4 份行动文件并一次性播报。

• 证据1：sessionKey=agent:main:cron:25dc7e01-e375-484c-a331-a326a7f616c2:run:929f80cc-43fd-4995-9b65-b491d874d85d｜2026-03-03T18:00:00.116Z｜quote 摘要："先读取：.../memory/overnight-goals-v1.md ... 每天执行一次：生成今天要推进的 4-5 个高杠杆任务..."
• 证据2：同 sessionKey｜2026-03-03T18:00:27.240Z｜quote 摘要："Successfully wrote .../2026-03-04__nightly-push/01_today_plan.md"

# 案例 B：长期项目目录重构（让产物可检索、可维护）

当产物散落在不理想层级时，直接影响检索与后续维护；一次迁移把“历史包袱”清掉，并用后续自动产出验证不回归。

• 证据1：sessionKey=agent:main:telegram:group:-1003807921933:topic:4214｜timestamp=1772327040080｜quote 摘要："已把 Overnight Goal Autopilot 的历史产出从根级 outputs/ 迁到项目目录"
• 证据2：同 sessionKey｜timestamp=1772327455215｜quote 摘要："... 全部上移为 projects/overnight-goal-autopilot/<日期目录>/...，并删除 outputs/ 层"

# 失败点（常见错误尝试）

1. 只追求“当次 OK”：消息发出就算完成，没留下可复用模板；下次只能从聊天记录里翻。
2. 产物不落盘或落盘无规范：今天写在 A 目录，明天写在 B 目录；三周后你自己都找不到。
3. 缺少“回执定义”：到底以什么为成功？是“写了文件”还是“发了消息”？是否需要“仅发送一次汇总”？这些不先约定，后面就会刷屏或误以为成功。

# 关键转折（工程化思维）

把用例当成“产品功能”，最小可复用单元不是一句 prompt，而是：

• 输入契约：读哪份说明书/规则文件（如 overnight-goals）
• 输出契约：固定目录 + 固定命名 + 固定份数/序号
• 回执契约：最终只发一次总览通知（避免噪音）
• 验证契约：写入成功要有明确 log；Unknown 就标 Unknown

当你做到这四个“契约”，用例才从“能跑”变成“可交接”。

# 可复用 SOP（用例工程 6 步）

1. 定义目标的“可验证产物”：文件/表/消息/状态机。不要只写“生成报告”。
2. 固化目录与命名：建议 projects/<project>/<YYYY-MM-DD__desc>/NN_xxx.md（案例已验证）。
3. 固化模板与序号：产物数量固定，便于 diff 与回归。
4. 把规则写进文件而不是脑子：如目标说明书、过滤规则、触发门禁。
5. 把成功标准写进回执：至少包含：产物列表、是否发送成功（ok=true/false）、Unknown 的边界。
6. 用“下一次自动产出”做回归验证：迁移/重构后，必须跑一次同类任务验证不回归（案例 B 的经验）。

# 课后作业

1. 选你手上一个“今天能跑”的小用例（抓取/汇总/提醒都行），把它改造成“可复用资产”，至少补齐：
   • 规则文件（输入契约）
   • 产物目录与命名（输出契约）
   • 成功回执字段（回执契约）
2. 写一段“交接说明”（200 字即可）：别人接手需要知道什么？Unknown 是什么？
3. 自检清单（打勾）：
   • 产物可被 git 跟踪/对比
   • 失败时能定位到是“抓取失败/处理失败/投递失败”哪一层
   • 下一次跑起来，不需要翻聊天记录