开头 150 字内直接给答案：OpenClaw 真正决定“能不能长期跑”的，不是一次跑通，而是可复跑：输入输出固定、每步有验收点、失败可重试、重复执行不产生脏数据。下面给你一套从 0 到 1 的工作流模板：先定目录与边界，再写任务清单，最后补幂等与重试。照着做，你能把发稿/巡检这类任务从“靠运气”变成“可控可查”。
适用场景
- 你要把“每天生成 3 篇草稿/信息图/清理草稿箱”做成稳定自动化
- 你要把重复运维操作（巡检、日志收集、配置检查）变成一键流程
- 你遇到过重复运行导致“重复发稿/重复上传/重复改配置”
前置条件
- OpenClaw / Claude Code 已可用（任选其一）
- 你能在本机或服务器上执行脚本（Python/PowerShell 任选）
- 有一个可复现的任务输入（例如 payload JSON、配置文件、URL 列表）
操作步骤
步骤 1：先定义“输入/输出/副作用”三件事
- 输入：固定路径的 payload/参数文件（例如
wp_drafts_payload_YYYY-MM-DD.json） - 输出：固定格式的 results（例如
wp_draft_results.json） - 副作用：哪些 API 会改数据（创建草稿/上传媒体/删除草稿）
验证方法：输入文件留存，确保任意时刻都能复跑同一输入得到可解释输出。
步骤 2：建立目录规范（模板）
workspace/
inputs/ # 外部输入（payload、URL清单）
outputs/ # 结果输出（results、报告）
logs/ # 运行日志（按日期）
cache/ # 缓存（可清理）
验证方法：每个文件都能说明属于输入/输出/日志/缓存中的哪一类。
步骤 3：写“任务清单”而不是写一段长指令
- 清单要可勾选：每一步都有完成条件（验收点）
- 先跑只读步骤（检查/预览），再跑写入步骤（创建/删除）
步骤 4：加上幂等策略（避免重复执行产生脏数据）
- 创建前先查：同标题/同 slug 是否已存在
- 上传前先查：同 hash/同 URL 是否已存在
- 插图用标记块：确保重复运行不叠加
步骤 5：加重试与回滚点
- 只重试失败项，不整批重跑
- 每一步输出结果到
outputs/，失败也要记录失败原因
常见问题与排查
- 为什么会重复发稿？ 多数是缺少创建前查询的幂等校验（标题/slug/meta）。
- 为什么重试会把问题放大？ 没区分失败项重试与整批重跑。
- 怎么判断流程稳定？ 同一输入连续跑 3 次，结果应一致且不产生重复内容。
总结
OpenClaw 的正确打开方式是：清单化 + 幂等 + 可验收 + 可回滚。先把输入输出和验收点定死，再谈生成质量，你的自动化才会长期稳定。
FAQ
1）幂等最简单怎么做？
创建前查询（标题/slug/哈希）+ 标记块防重复插入，成本最低、效果最好。
2）哪些步骤应该先只读？
检查站点可用性、拉取历史标题、校验 payload、预览将创建的标题列表。
3）清单写多细才合适？
以“别人照着能复现”为标准：命令、输入路径、验收点与失败处理写清楚。
常见误区与补充说明
- 误区 1：把工具当成一次性生成器。 建议把输入、输出、验收点固定下来，避免每次跑出不同结果。
- 误区 2：只写步骤不写判断。 每一步最好给出‘成功/失败’的判断方式，让读者能快速定位卡点。
- 误区 3：失败就整批重跑。 正确做法是只重试失败项，并记录失败原因，避免重复创建/重复写入。
示例：把流程落到一个最小闭环
- 准备一个输入（例如 payload 或 URL 列表）。
- 按步骤执行一次并输出结果文件。
- 用同一输入再跑一次，确认结果一致且没有重复副作用。