夜雨聆风What's up， 大家！这是我的第 9 篇原创文章。
装好 OpenClaw 后，很多人第一反应是"太好了，什么都交给它"。然后就出问题了——AI 帮你改了生产配置、AI 偷偷充了钱、AI 替你发了一篇质量堪忧的文章。问题的根源不是 AI 太蠢，而是你没告诉它"什么不能碰"。 今天这篇，就聊聊我怎么给 OpenClaw 划边界——一套经过实战验证的人机协作规则。
不划边界，翻车只是时间问题
我在写部署方案的时候，专门花了一整章来定义职责边界。这不是形式主义——这是你和 AI 长期协作的基础设施。
不划边界会怎样？我遇到过这些情况：
- • AI 自动"优化"了一个配置文件，结果把生产环境搞挂了
- • AI 以为在帮你省事，替你回复了一条消息，语气完全不对
- • 你让它生成文章，它顺手也帮你发布了——质量根本没审核过
这些问题的共同点是：AI 没有越权意识，你不画线它就默认"都能做"。
所以我的原则是：与其事后救火，不如事前画一张清晰的边界图。
尝试过程：从一张能力清单开始
能做 vs 不能做：9 对 6
我把 OpenClaw 的职责划成两份清单——9 件能做的事，6 件绝对不做的事：
| # | OpenClaw 能做（✅） | 对应场景 | OpenClaw 不做（❌） | 理由 |
| 1 | 内容生产（按工作流生成文章） | 系列文章、热点追踪 | 内容审核（最终质量人工把关） | AI 生成需人工校验 |
| 2 | 项目开发（读需求执行开发） | Skills 开发、脚本编写 | 文章发布（公众号/星球操作） | 涉及平台操作权限 |
| 3 | 文档更新（补充 docs/、README） | 技术文档维护 | 方案决策（战略层面设计） | 方向性决策需要人 |
| 4 | 素材采集（监控采集公众号素材） | 定时抓取 AI 热点 | 付费操作（购买 API Key 等） | 涉及资金安全 |
| 5 | 分析报告（进度分析、覆盖率） | 季度横评 | 星球运营（帖子回复、互动） | 需要人格化互动 |
| 6 | 状态反馈（飞书/Telegram 通知） | 心跳+异常告警 | 跨平台发布（微信/小红书） | 需人工登录操作 |
| 7 | 数据追踪（内容进度管理） | 后置链路自动处理 | — | — |
| 8 | Dashboard 更新（同步看板数据） | 脚本自动同步 | — | — |
| 9 | 学习笔记（读 prompt 记录理解） | 标注为 OpenClaw 笔记 | — | — |
这张表贴在方案文档的显眼位置。任何新任务下达前，先对照这张表判断：属于左边还是右边？
协作边界图：三条线
光有清单还不够，还得画出来让人一眼看清。下面这张图来自我的部署方案原文，完整展示了用户和 OpenClaw 之间的职责划分与信息流向：
核心逻辑就三条线：
- 1. 输入线：用户写需求 → OpenClaw 执行
- 2. 审核线：OpenClaw 产出 → 用户审核
- 3. 发布线：用户审核通过 → 用户发布
OpenClaw 永远不碰"审核"和"发布"这两个动作。 这是铁律。哪怕 AI 觉得自己生成的文章质量很好，它也没资格自行发布——最终质量判断权在人手里。
为什么要把边界画得这么死？因为 AI 的能力边界不是固定的——它可能今天还做不到某件事，明天升级后就能做了。如果你的边界是基于"AI 能不能做"来划的，那每次模型升级你都得重新划一遍。我的边界是基于"这件事该不该由 AI 做"来划的——审核和发布涉及质量判断和平台操作权限，不管 AI 能力多强，这两个动作的决策权必须在人手里。这个原则不会因为模型升级而改变。
最终方案：三表两词一机制的任务管理体系
有了边界，还需要一套任务管理系统让它跑起来。我设计了"三表两词一机制"：
| 组件 | 名称 | 作用 | 位置 |
| 表1 | 置顶任务表格 | 记录所有 OC-XXX 任务 | prompt.md 顶部 |
| 表2 | 定期任务表格 | 记录 RC-XXX 周期任务 | prompt.md 紧接表1 |
| 表3 | 两阶段对照表 | Windows 先行 vs OpenClaw 接手 | 方案第四章 |
| 词1 | 自动扫描提示词 | 定期扫描发现潜在任务 | 6 步流程 |
| 词2 | 手动闭环提示词 | 用户一句话→AI 闭环执行 | 6 步闭环 |
| 机制 | 三步工作流 | 圈方案→更新手册→实施执行 | 方案 §4.6 |
自动扫描：AI 主动发现需求
这是最有意思的部分。OpenClaw 不是被动等你下达任务，它会主动扫描你的项目，发现潜在需求。但关键规则是：扫描只扫描、分析、报告，不修改任何文件。发现的任务必须经过用户确认才能进入任务表。
注意这张图里有两个判断节点——"发现新任务？"和"用户确认？"。第一个判断是 AI 自动做的：扫描完项目后判断有没有需要处理的事项。第二个判断必须由人做：即使 AI 发现了任务，你不确认它就不能动。这两层过滤确保了 AI 不会自作主张——发现归发现，做不做你说了算。
扫描流程分 6 步：
| # | 操作 | 说明 |
| 1 | 扫描项目体系 | 读取技术架构文档，逐个扫描子项目，产出健康度基线 |
| 2 | 交叉对比发现缺口 | 数据清单对比 + 执行总表对比 + prompt 历史，产出差异列表 |
| 3 | 健康度评估 | README、docs 覆盖、需求完成率、活跃度，产出 🟢🟡🔴 评分 |
| 4 | 生成潜在任务清单 | 把缺口转化为具体任务建议，产出任务表 |
| 5 | 归档扫描报告 | 保存到指定路径，产出 .md 报告 |
| 6 | 推荐行动 | 挑 Top 3 最紧急任务，产出行动建议 |
手动闭环提示词：一句话变成完整任务
用户日常最常用的是手动闭环提示词。你只需要说一句话，AI 自动走完整个流程：
我需要给 OpenClaw 下一个新任务。请按以下闭环流程执行：
【第一步：理解我的需求】
用户描述：[一句话说明]
【第二步：定位涉及的项目和代码】
分析项目体系 → 搜索历史需求 → 分析项目当前状态
【第三步：圈方案】
判定写 story（短需求）还是 requirement（完整需求）
【第四步：更新手册】
根据方案更新 docs/ 对应章节
【第五步：更新置顶任务表格】
从表格上方插入一行 OC-XXX 任务
【第六步：汇报】
三步工作流状态表一句话需求也不能只写个备注了事——必须先落一份 story，再进入任务表。这是铁律。很多人觉得"这个需求很简单，不用写文档"，结果 AI 按自己的理解跑了一遍，产出物和你想的完全不一样。story 不需要写很长——三五句话讲清楚"要做什么、为什么做、验收标准是什么"就够了。它的价值不在于形式，而在于强迫你在动手之前把需求想清楚。
定期任务：AI 的日程表
除了一次性任务，OpenClaw 还有 7 个定期任务在后台跑：
| 编号 | 任务 | 频率 | 时间 |
| RC-001 | 热点采集 | 每天 | 08:00 |
| RC-002 | 数据一致性校验 | 每天 | 09:00 |
| RC-003 | Dashboard 状态刷新 | 每天 | 09:30 |
| RC-004 | prompt.md 新任务扫描 | 每30分钟 | 全天 |
| RC-005 | 子项目 README 健康检查 | 每周一 | 10:00 |
| RC-006 | 执行总表巡检 | 每周三 | 14:00 |
| RC-007 | 月度进度汇总报告 | 每月1日 | 10:00 |
而且 OpenClaw 会早晚各汇报一次：
# 早上 07:30 飞书消息
今日计划：
- 08:00 RC-001 热点采集
- 09:00 RC-002 数据一致性校验
- 09:30 RC-003 Dashboard 刷新
# 晚上 22:00 飞书消息
今日结果：
- ✅ RC-001 采集3条
- ✅ RC-002 无差异
- ❌ RC-003 Dashboard 模板缺失踩坑总结
| # | 坑 | 现象 | 解决方案 |
| 1 | 没划边界就上手 | AI 乱改文件、越权操作 | 先定"能做/不做"清单，贴在方案显眼位置 |
| 2 | 只有任务没有流程 | 任务堆积无人跟进，不知道做到哪了 | 三步工作流闭环：圈方案→更新手册→实施执行 |
| 3 | 不写 story 直接干 | 需求理解偏差，返工率居高不下 | 哪怕一句话需求也必须先落 story |
| 4 | 没有定期扫描 | 需求遗漏、项目文档腐化、README 过时 | RC-005 每周检查子项目健康度 |
| 5 | 审核和执行不分离 | AI 自己审核自己的产出，质量不可控 | 用户永远是最终确认人，发布权不下放 |
| 6 | 扫描发现问题就直接改 | AI 自作主张修改了不该改的文件 | 扫描只报告不修改，用户确认后才进入任务表 |
历史文章，请看这里：
2026-03-13：我有没有可能是首个公开烹饪龙虾OpenClaw方法的人