随手记

OpenClaw 实战任务库：30 个最常用自动化场景（含提示词模板）

30 个可复制的 OpenClaw 自动化任务模板，覆盖运维排障、写作博客、研究整理、提醒计划与分工协作；每条含前置条件、验证点与常见坑。

TuBaiBai

04 Feb 2026 — 24 min read

这是一篇“公共可复现”的任务库文章：你可以把每条的提示词直接复制给 OpenClaw 使用。
本文严格遵守两条规则：
1) 不虚构任何 OpenClaw CLI 子命令（不确定就让你运行 openclaw help 自查）。
2) 任何依赖特定能力（浏览器接管、消息渠道、定时调度、外部插件/skills、系统权限）的任务，都明确写出前置条件、如何验证与替代方案。

TL;DR（先看这段就能上手）

1) 先确认你安装与部署没走弯路：

2) 先确认你知道有哪些 CLI 命令可用（不同版本可能不同）：

并在终端运行：openclaw help（如你使用 gateway，再跑 openclaw gateway status）

3) 如果你要做本地检索/记忆（Ollama）：

4) 如果你用 1Panel 管理容器/部署服务：

使用前“统一自查”（强烈建议做一次）

把下面这段发给 OpenClaw（之后你可以固定成一个常用指令）：

在开始任何任务前，请先输出：
1) 你当前可用的能力/工具清单（例如：是否能执行 shell、是否能读写文件、是否能用浏览器、是否能发送消息、是否支持定时/cron、是否支持子任务并行）
2) 每类能力的前置条件与如何验证（例如需要我运行 openclaw help、openclaw gateway status，或在某个 UI/扩展里确认已连接）
3) 若前置条件不满足，请给最小替代方案（例如输出手工步骤、生成脚本、生成清单或模板）
注意：不要编造不存在的 OpenClaw CLI 子命令；如不确定，让我运行 openclaw help 并贴输出。

分类目录

A. 运维/自托管（Ops）任务 1–10
B. 写作/博客运营（Writing/Blog）任务 11–18
C. 研究/资料整理（Research）任务 19–24
D. 提醒/计划与定时（Reminders）任务 25–27
E. 多任务分工/委派（Delegation）任务 28–30

每条任务都包含：
(a) 用途 / (b) 可复制提示词 / (c) 期望输出 / (d) 验证点 / (e) 常见坑
并且在需要时给出：前置条件 + 如何验证前置条件 + 替代方案

A. 运维/自托管（Ops）1–10

1) 服务器体检：一键巡检报告（非破坏性）

用途：快速了解系统状态（版本/资源/磁盘/端口/失败服务/错误日志摘要）。
前置条件：需要能执行命令；若 OpenClaw 不能执行命令，则改为输出你手动执行的命令清单。
如何验证前置条件：让 OpenClaw说明是否能运行 shell；不确定就你自己跑 openclaw help 看是否有相关能力说明。
提示词模板

  请生成一份“Linux 服务器体检”方案（通用 Debian/Ubuntu）：
  1) 给出最小命令序列（非破坏性：uname/lsb_release/free/df/ss/systemctl/journalctl 等）
  2) 生成一个 healthcheck.sh 脚本 + healthcheck-report.md 报告模板
  3) 每一步都有注释：目的、需要 sudo 与否、验证点
  如果你无法执行命令，请把命令与预期输出格式写清楚，我来手动执行并回贴结果。

期望输出：脚本与报告模板（建议落盘）。
验证点：脚本能运行；报告包含时间戳与关键指标表。
常见坑：依赖工具缺失（lsof 未装）；输出太长不落盘；忘了区分 root/非 root。

2) 端口占用/服务起不来：最短排障路径

用途：定位“端口已被占用/服务未监听/监听地址不对”。
前置条件：能运行 ss/systemctl/journalctl 或等价工具；容器环境还需要 docker。
提示词模板

  我遇到“服务起不来/端口占用”。请给我一个通用排障流程：
  - 如何查端口占用（优先 ss，其次 lsof）
  - 如何定位进程与启动来源（ps/systemctl；若是容器则 docker ps/inspect）
  - 如何看日志（journalctl 或 docker logs）
  输出：最小命令序列 + 一份 Markdown 排障记录模板。

期望输出：步骤化命令清单 + 记录模板。
验证点：能回答“哪个进程占用哪个端口，来自哪个服务/容器”。
常见坑：忽略 IPv6；只看容器内端口不看宿主映射；日志看错服务名。

3) 容器不断重启（restart loop）定位清单

用途：容器启动后立即退出、反复重启。
前置条件：需要 Docker 可用；若你用 1Panel，也可在面板里看容器日志（作为替代）。
提示词模板

  请给我一份 Docker 容器反复重启的通用排障手册：
  - docker ps / docker logs / docker inspect / docker events 的最小用法
  - 退出码怎么看、如何根据退出码缩小范围
  - 常见原因分类：入口命令/参数、环境变量缺失、卷权限、依赖未就绪、端口冲突、健康检查失败
  - 每类原因给“验证步骤 + 修复方向”
  如果我用 1Panel，请补一个“在面板里对应看哪些信息”的通用指引（不绑定具体 UI 文案）。

期望输出：原因分类 + 验证与修复路线图。
验证点：能拿到退出码与最后 20–50 行日志。
常见坑：只看 docker ps；忽略卷权限（UID/GID）；健康检查导致误判。

4) 生成 systemd service 模板：让任意服务“开机自启+自动重启”

用途：将任意命令（Node/Python/二进制）稳定托管。
前置条件：systemd 系统（大多数 Debian/Ubuntu 默认是）；需要 sudo 写入 /etc/systemd/system/。
提示词模板

  请给一个通用 systemd service 模板（用占位符）：
  - 以 appuser 运行、WorkingDirectory、EnvironmentFile、Restart 策略、资源限制可选
  - 给出部署步骤：创建用户/目录权限、写 service 文件、daemon-reload、enable、start
  - 给出验证：systemctl status、journalctl 查看日志
  注意：不要写死具体项目路径与命令，用占位符即可。

期望输出：可复制的 .service 内容 + 操作步骤。
验证点：服务状态 active；日志可查；重启后自动起来。
常见坑：ExecStart 路径错误；环境变量没加载；WorkingDirectory 不对。

5) 反向代理最小配置：Nginx/Caddy（含 WebSocket）

用途：域名访问内网服务，并为 HTTPS/鉴权铺路。
前置条件：你已安装并能管理 Nginx 或 Caddy；有域名解析到服务器。
如何验证：你能 curl http://127.0.0.1:3000 看到后端响应（示例端口）。
提示词模板

  请给 Nginx 与 Caddy 的“反向代理最小配置”各一份（使用 example.com -> http://127.0.0.1:3000）：
  - 必要的 header 转发与 WebSocket 配置
  - 如何验证后端可达、如何定位 502/504/400
  - 逐步加 HTTPS、鉴权、限流的路线图（只要步骤，不要厂商绑定）

期望输出：两套最小配置 + 验证与排障清单。
验证点：域名访问成功；错误时能按清单定位到后端/反代/证书问题。
常见坑：漏 WS 头；后端监听地址限制；反代与容器网络打架。

6) 备份与恢复 SOP：把“可恢复”写成流程

用途：自托管最核心能力：可恢复。
前置条件：有可写备份目录；建议准备异地存储（可选）。
提示词模板

  请输出一份通用“备份与恢复 SOP”（适用于自托管服务）：
  - 需要备份的对象分类：配置、数据目录、上传文件、数据库、密钥/环境变量
  - 备份策略：频率、保留周期、异地、加密
  - 给出 tar/rsync + sha256 校验示例
  - 给出恢复演练清单：如何验证备份可用（不只备份成功）

期望输出：SOP 文档 + 示例命令。
验证点：能完成一次“备份→删除测试目录→恢复→哈希校验一致”。
常见坑：只备份配置不备份数据；无加密；从不演练恢复。

7) 安全基线检查：最小够用版

用途：降低常见安全事故概率（弱口令、暴露管理端口、无 2FA）。
前置条件：能查看 SSH 配置与防火墙规则；需要 sudo。
提示词模板

  请给我一份“自托管安全基线（最小够用版）”清单：
  - SSH、用户权限、sudo、最小开放端口
  - 防火墙（ufw 或 iptables）思路
  - 日志与告警（可选：fail2ban）
  - 反向代理与证书的最小安全建议
  每一项都必须包含：如何验证是否达标（命令或检查步骤）。

期望输出：分项 checklist（带验证方法）。
验证点：每项能打勾并留档。
常见坑：把管理面板直接暴露公网；误封 SSH；证书私钥权限过宽。

8) “长日志→3条线索→下一步命令”自动摘要

用途：快速从日志中抓根因假设。
前置条件：你能提供日志内容（粘贴/文件）。
提示词模板

  我将提供一段日志。请你：
  1) 先用 5 行以内总结发生了什么
  2) 原样引用 3-5 行最关键错误/警告
  3) 给 2-3 个根因假设，并为每个假设给可执行的验证步骤
  4) 输出“下一步排障命令列表”（尽量通用）

期望输出：摘要+关键行+假设+命令列表。
验证点：按验证命令能逐个确认/排除假设。
常见坑：只给结论不给验证；猜测太多不收敛。

9) 变更记录（Changelog/Release Notes）模板

用途：每次升级/改配置都可追溯、可回滚。
提示词模板

  请给我一个“变更记录/发布说明”模板（Markdown）：
  - 变更目标、影响范围、风险、回滚方案、验证用例
  - 需要记录的命令、配置 diff、关键日志位置
  并给一个占位示例（不用真实系统信息）。

期望输出：模板 + 示例。
验证点：每次变更都能填完整，尤其是回滚与验证用例。
常见坑：只写“已更新”；没有回滚与验证。

10) 故障复盘（RCA）模板：把事故变成改进项

用途：建立“不会再犯同类错误”的机制。
提示词模板

  请给我一个 RCA（故障复盘）模板：
  - 时间线、影响范围、根因、触发条件、修复、预防
  - 必须包含：监控缺口、自动化改进项、验收标准
  并给一个占位示例。

期望输出：RCA 模板。
验证点：预防项有明确验收标准（可测试）。
常见坑：结论空泛（“加强监控”）；没有具体阈值与责任拆解。

B. 写作/博客运营（11–18）

11) 从主题生成 SEO 大纲 + 长尾关键词 + FAQ

用途：写作前“结构先行”。
前置条件：无。
提示词模板

  主题：{你的主题}
  请输出：
  1) 读者画像与搜索意图（信息型/排障型/交易型等）
  2) 10-15 个中文长尾关键词（含疑问句）
  3) H2/H3 大纲（每节写要点）
  4) FAQ 至少 6 个（与正文不重复）
  5) 建议的内链方向（我再补具体 URL）

期望输出：可直接写正文的大纲。
验证点：包含“步骤+验证点+排坑”。
常见坑：关键词太宽；FAQ 与正文重复；没有验证点。

12) 旧文升级改写（提升可读性与可复现）

用途：用较低成本提升已有流量文章表现。
提示词模板

  我将粘贴旧文正文。请在不改变主题的前提下升级改写：
  - 增加 TL;DR
  - 重排结构（更清晰的 H2/H3）
  - 每个步骤增加“验证点/检查命令”
  - 增加 FAQ（至少 6 个）
  输出：完整 Markdown。

期望输出：新版 Markdown。
验证点：读者按步骤能完成并自查成功。
常见坑：为了变长而注水；引入未经验证的断言。

13) 文章系列规划（主题集群）

用途：围绕 OpenClaw/自托管做内链网络。
提示词模板

  请围绕“OpenClaw + 自托管 + Ollama/RAG + 1Panel”规划 8 篇系列文章：
  - 每篇：标题、目标关键词、读者意图、建议长度、与前后篇衔接
  - 给出内链结构（入门->进阶->排障->最佳实践）
  - 标注支柱页（pillar）与支持页（cluster）

期望输出：8 篇计划 + 内链结构。
验证点：每篇都有明确承接与导流。
常见坑：选题重复；缺排障型长尾；没有支柱页。

14) 多平台摘要：站内/社交/论坛三套文案

用途：同一主题多渠道分发。
提示词模板

  我将给你文章标题与 5-8 个要点。请生成：
  1) 站内摘要（120-160字）
  2) 社交短帖（80-120字）
  3) 技术论坛发帖版（含目录 + 关键步骤）
  要求：不夸大承诺，不制造“免费破解/盗版”等引导。

期望输出：三种版本。
验证点：三者信息一致、长度合适。
常见坑：短帖像论文；论坛版缺少步骤与检查点。

15) 命令/配置片段审校（防复制翻车）

用途：发布前检查风险与可复现性。
提示词模板

  请审校以下命令/配置片段：
  - 标注危险命令（如 rm -rf、覆盖写）并给更安全替代
  - 补充前置条件（权限/依赖/版本）
  - 为每一步增加“验证命令/检查点”
  输出：修订后的片段 + 审校报告。

期望输出：可复现的修订片段。
验证点：每一步都能验证成功/失败。
常见坑：默认依赖存在；忽略权限；没有回滚/清理。

16) 术语表：降低新读者门槛

用途：让新手读得懂后续内容。
提示词模板

  主题：{填}
  请输出术语表 10-20 条：
  - 一句话解释
  - 一句话说明“本文中它用于解决什么问题”

期望输出：术语表（可放开头或附录）。
验证点：术语解释与正文一致。
常见坑：解释太学术、脱离文章语境。

17) 合规承接“订阅制平台/创作者变现工具”相关流量（中性）

用途：只做隐私/支付风控/账号安全等合规主题承接。
提示词模板

  我有一篇涉及“订阅制内容平台/创作者变现工具”的旧文入口。请给我：
  1) 一段中性合规的提示文案（不涉及露骨内容，不提供绕过付费/盗版方法）
  2) 3 个合规延伸选题（隐私保护、支付风控、账号安全、内容合规等）
  3) 编辑检查清单（避免敏感与违规）

期望输出：提示文案 + 延伸选题 + 检查清单。
验证点：不出现“免费获取/破解/绕过付费”等引导。
常见坑：暗示性措辞；提供规避平台规则方法（不应提供）。

18) 内链策略：把新文接入 4 篇高流量旧文

用途：提高站内浏览深度与主题权重。
提示词模板

  请为我的新文章设计内链策略（给锚文本建议与插入位置）：
  - /openclaw-install-host-vs-docker-debian-ubuntu/
  - /openclaw-cli-commands-guide/
  - /openclaw-ollama-local-memory-search/
  - /1panel-moltbot-clawdbot-tutorial/
  输出一个 checklist：新文至少插 3 处内链，若我愿意改旧文，也给每篇旧文加回链的建议位置。

期望输出：内链插入点 + 锚文本建议。
验证点：新文至少 3 处自然内链。
常见坑：锚文本太硬（“点这里”）；与段落语义不相关。

C. 研究/资料整理（19–24）

19) 把一个问题拆成 10 个“可搜索查询”

用途：更快找到答案与权威来源。
提示词模板

  研究问题：{填}
  请拆成 10 个搜索查询（中文为主，可混合英文关键字）：
  - 覆盖：教程、官方文档、常见报错、对比、最佳实践
  并解释每个查询的意图与期望找到的资料类型。

期望输出：10 个查询 + 意图说明。
验证点：查询包含“报错关键字/版本号维度”。
常见坑：10 个查询其实是同义重复。

20) 阅读清单 + 摘要表格模板（可引用）

用途：把收藏变成能用的笔记。
提示词模板

  请生成“阅读清单 + 摘要表格”模板（Markdown 或 CSV）：
  字段：链接、来源类型（官方/博客/论坛）、关键结论、适用版本、引用句子、行动项
  并给 5 条占位示例。

期望输出：模板 + 示例。
验证点：每条都有行动项与适用版本。
常见坑：只堆链接；不记录版本导致踩坑。

21) 多来源整合成“可复现步骤”（带出处）

用途：把多篇资料合并成可交付教程。
提示词模板

  我将提供多段摘录（每段附来源链接）。请整合为：
  - 一份分步骤教程（每步写清目的）
  - 每个关键结论后标注来源链接
  - 若不同来源冲突，标出冲突点并给验证方法（如何判断哪种适用）

期望输出：带引用的步骤教程。
验证点：关键结论可回溯；冲突点可验证。
常见坑：把不同版本的结论混用；遗漏引用。

22) 抓取失败/打不开网页时的替代策略

用途：研究不中断。
提示词模板

  如果你无法访问某网页/抓取内容，请给替代策略：
  1) 先找官方文档/镜像/缓存版本
  2) 用搜索摘要 + 多来源交叉验证
  3) 列出我需要手动提供的最小信息清单（复制关键段落/截图/报错文本）

期望输出：Plan B 步骤。
验证点：能继续推进到可操作结论。
常见坑：停留在“打不开”，不给下一步。

23) 选型对比表（工具/方案决策）

用途：把“感觉”变成“可验证评估”。
提示词模板

  我需要对比选型：{A vs B vs C}
  请输出评估表（Markdown）：
  - 维度：部署难度、资源占用、效果、生态、可维护性、安全、成本
  - 每个维度给验证方法（小实验/样例问题/压测思路）
  最后给出推荐：在什么条件下选哪个。

期望输出：评估表 + 验证方案 + 推荐条件。
验证点：能按验证方案做一个最小对比实验。
常见坑：纯主观评分；忽略维护与迁移成本。

24) 常见报错字典（面向读者的“报错→原因→验证→修复”）

用途：提升搜索命中与自助排障体验。
提示词模板

  主题：{填：例如 Docker/反向代理/某服务}
  请生成 12 条常见报错/现象字典：
  - 报错原文或现象
  - 最常见原因
  - 最小验证命令/检查步骤
  - 修复方式（分步骤）
  注意：不要虚构冷门报错；每条必须可验证。

期望输出：12 条字典条目。
验证点：每条都能执行验证步骤。
常见坑：编造报错；修复依赖特定环境却没写前置条件。

D. 提醒/计划与定时（25–27）

重要说明：
- 若 OpenClaw 具备内置调度/cron：按它的指引做；
- 若不具备：使用系统 crontab 或 systemd timer 替代；
- 若无法主动发消息：用“生成提醒文件/终端输出/写入日志”替代。

25) 每天固定时间提醒（通用）

用途：每天提醒备份/写作/巡检。
前置条件：可能需要定时能力或系统 cron/timer。
如何验证：让 OpenClaw说明是否支持定时；不确定你运行 openclaw help 查看相关说明。
提示词模板

  我想每天 {09:30} 提醒我做 {任务}。
  请先判断你是否支持“内置定时/调度”，并告诉我如何验证已启用。
  - 若支持：给创建步骤 + 如何列出/验证该提醒
  - 若不支持：给 crontab 或 systemd timer 的替代方案（含验证）
  若无法发消息通知：改为生成 reminders/YYYY-MM-DD.txt 文件或写入日志。

期望输出：可执行方案 + 验证方式。
验证点：到点能收到提醒（或生成文件）。
常见坑：时区不一致；计划任务环境变量缺失；脚本无执行权限。

26) 事件倒计时提醒（提前 N 次）

用途：证书到期、续费、发布前检查。
提示词模板

  我想为一个事件设置“多次提醒”。

  事件时间：<YYYY-MM-DD HH:MM>
  事件描述：<一句话描述>
  提前提醒：<7天>、<24小时>、<30分钟>

  示例：
  - 事件时间：2026-03-01 10:00
  - 事件描述：域名续费（tbbbk.com）
  - 提前提醒：7天、24小时、30分钟

  请提供“多次提醒”的实现方案：
  1) 若你支持内置调度：如何设置三次提醒 + 如何验证已注册（能列出任务/查看下一次触发时间）
  2) 若你不支持：请给 cron 或 systemd timer + 脚本方案

  约束：
  - 不要求发送到特定平台；如果无法主动通知，就改为生成提醒文件（例如 reminders/YYYY-MM-DD.txt）或写入日志。

期望输出：多次提醒配置方案。
验证点：能列出已注册任务/或看到 timer/cron 条目。
常见坑：日期格式；时区不一致；重启后丢失（未持久化）。

27) 每周复盘模板自动生成

用途：形成持续迭代节奏。
提示词模板

  请生成每周复盘模板（Markdown），并设计自动化流程：
  - 每周一生成 weekly-review-YYYY-WW.md
  - 模板包含：目标、完成、问题、下周计划、可自动化项、关键指标
  若你无法定时执行：给 crontab 或 systemd timer 替代方案（含验证）

期望输出：模板 + 自动生成流程。
验证点：每周自动出现新文件（或能一键生成）。
常见坑：周编号计算；重复覆盖旧文件。

E. 多任务分工/委派（28–30）

28) 大项目拆解为 5 个可并行子任务（含验收）

用途：写系列、做迁移、做深度调研。
前置条件：如果 OpenClaw 支持“子任务/子代理并行”，可以并行；否则按阶段交付。
提示词模板

  项目：{填}
  请拆成 5 个子任务，每个包含：
  - 产出物（文件/清单/脚本）
  - 验收标准（可测试、可检查）
  - 依赖与风险
  若你支持并行子任务：说明并行方式与汇总格式；
  若不支持：给分阶段执行顺序与每阶段交付物。

期望输出：拆解清单 + 验收点。
验证点：每项都有可交付物与验收方式。
常见坑：拆太粗；验收标准含糊；依赖不清导致返工。

29) 把想法整理成 PRD/任务单（可交给别人执行）

用途：减少沟通成本。
提示词模板

  想法：{填}
  请整理成 PRD/任务单（Markdown）：
  - 背景、目标、非目标
  - 使用场景（用户故事）
  - 功能清单（Must/Should/Could）
  - 风险与依赖
  - 验收标准（可测试）
  结尾给我 5 个澄清问题。

期望输出：PRD + 澄清问题。
验证点：他人仅看 PRD 就能开始执行。
常见坑：目标不可量化；验收不可测试；需求与实现混淆。

30) 交付前“可复现性检查清单”（最终把关）

用途：确保输出可迁移、可复现、可回滚。
提示词模板

  请对你刚给出的方案/脚本/教程做一次“可复现性交付检查”：
  - 前置条件（系统/权限/依赖/配置）
  - 步骤与每步验证点
  - 回滚/清理步骤
  - 常见失败点与替代方案
  输出为一个 CHECKLIST（Markdown）。

期望输出：Checklist。
验证点：换机器/新目录也能照做或快速定位失败原因。
常见坑：缺清理步骤；验证点不明确；依赖版本没写。

FAQ（常见问题）

Q1：我怎么知道我这套 OpenClaw 支持哪些功能？
A：让 OpenClaw输出能力清单；你本机运行 openclaw help（必要时再查 /openclaw-cli-commands-guide/）。如果你使用 gateway，再跑 openclaw gateway status。

Q2：为什么本文不直接写“某某 openclaw 子命令”？
A：不同版本/不同安装方式可用子命令可能不同。本文遵循“不可虚构命令”的原则：不确定就让你 openclaw help 自查，再把输出贴给 OpenClaw做适配。

Q3：浏览器自动化一定能用吗？
A：不一定，通常需要浏览器接管/扩展/relay 等前置条件。未满足时，用“手动操作 + OpenClaw生成步骤/表单/检查清单”替代。

Q4：提醒/定时一定能推送到 Telegram/Discord 吗？
A：不一定，取决于你是否配置了消息渠道。未配置时建议用系统 cron/systemd timer 生成文件提醒或写日志。