OpenClaw 数字员工实操全景：云端部署、飞书指挥、Skill 开发、内容流水线与安全加固的完整方法论

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

如果你只想拿走结论，这几句就够了：OpenClaw 不是又一个聊天机器人，它是一个跑在你自己机器上的「执行网关」，能读写文件、跑 shell、控浏览器、调 API。真正决定它好不好用的，从来不是模型多强，而是三样东西——workspace 里那几个 Markdown 人格文件写得对不对、Skill 装得干不干净、以及你有没有把安全边界先划出来。落地路径我建议按这个顺序走：先用轻量云服务器的应用模板把服务跑起来，再用飞书长连接把指挥入口打通，然后用 SOUL.md 和 USER.md 把「它是谁、它服务谁」定死，最后才谈自动化业务流。至于内容自动分发，2026 年这个时间点我的建议是踩刹车——机器负责生产，人负责审核和按下发布键，这条线不能越。

下面是完整拆解：我会把部署、通道、人格、技能、内容流水线、多智能体、安全加固这七块拆开讲，每一块都给出可直接照抄的配置和命令，也会把我自己踩过的坑标出来。想看完整拆解，往下翻。

一、先把 OpenClaw 到底是什么讲清楚

1.1 它和你平时用的 AI 助手不是一类东西

很多人第一次听说这个项目，第一反应是「又一个套壳」。这个判断不太准确。

用一句白话解释：你平时用的对话式 AI，是「你问一句、它答一句」，它给你的是文字；OpenClaw 给你的是「事情做完了」。 它拿到的不只是一个对话框，而是宿主机的操作权限——可以执行 shell 命令、读写本地文件、驱动浏览器、调用各种外部 API。所以社区里管它叫「能动手干活的数字员工」，这个说法虽然营销味重了点，但方向没错。

项目本身的来龙去脉值得交代一下，因为这决定了它的设计取向。它由奥地利开发者 Peter Steinberger 创建，最初只是一个周末项目，目标是做一个通过聊天软件控制的本地 AI 助手，核心理念是「让 AI 通过你已经在用的聊天 App 跟随你」。它不在浏览器沙盒里跑，而是直接运行在宿主机操作系统层——这一点是它全部威力的来源，也是它全部风险的来源，后面第十章我会专门展开。

项目历史上换过好几次名字，曾用名 Clawdbot、Moltbot，所以你在网上搜到的老教程里出现这几个词，指的是同一个东西。国内社区习惯叫它「小龙虾」，是因为项目 Logo 和 claw（爪子）这个词的关系，纯属昵称，跟功能没关系。

1.2 三个定语：开源、本地优先、多通道

我自己折腾下来，觉得把它的特征概括成三条最省事：

开源。 基于 MIT 协议，代码公开。这意味着你可以完全私有化部署，也意味着你必须自己对安全负责——没有厂商替你兜底。

本地优先。 支持数据本地化运行，规避第三方服务器传输风险，实现数据自主可控。对于要处理内部文档、客户资料的团队，这一条是刚需。

多通道接入。 这是它体验上真正拉开差距的地方。你不需要再开一个新的 App，直接在飞书、企业微信、钉钉这些你每天已经在用的工具里跟它说话就行。腾讯云那边在云端一键部署 OpenClaw，微信、QQ、企业微信、飞书、钉钉等国内主流 IM 已经全面支持，对国内用户来说省了很多折腾。

1.3 它的运行逻辑长什么样

理解架构不需要看源码，画张图就够了。整体是一个典型的中枢辐射结构：

flowchart TD
    A["聊天入口<br/>飞书 / 企微 / 钉钉 / 网页控制台"] --> B["网关 Gateway<br/>消息接入 + 鉴权 + 路由"]
    B --> C["Agent 运行时<br/>组装人格 + 上下文 + 工具清单"]
    C --> D["大模型<br/>推理与规划"]
    D --> C
    C --> E["Skills 技能层<br/>可插拔的手和脚"]
    E --> E1["shell / 文件读写"]
    E --> E2["浏览器自动化"]
    E --> E3["第三方 API 调用"]
    C --> F["记忆层<br/>MEMORY.md + 每日日志 + 向量库"]
    F --> C

这张图里最容易被新手忽略的是两个地方。

一个是记忆层是双向的。它不是「跑完就忘」，而是会把重要的事沉淀成文件，下次启动继续用。这也是它跟大部分编码助手最本质的差别——Claude Code 是有状态会话内、无状态会话间的编码工具，OpenClaw 是始终在线、跨会话持久化的个人助手。

另一个是Skills 层是可插拔的。模型本身不会用微信公众号 API，也不会操作飞书多维表格，这些能力全靠技能包挂上去。所以你的数字员工能干什么，本质上取决于你给它装了什么技能、以及技能写得好不好。

1.4 一个我认为很关键的心态问题

网上不少教程会给你一种错觉：装完就能用，一句话让它干什么都行。

我的实际体验不是这样。它更像是招了一个能力很强但完全不了解你公司的应届生——什么都能学，但你不告诉它，它什么都不知道。所以社区里那个「养」的说法其实挺贴切：这不是一次性配置，而是一个持续投喂上下文、持续修正边界的过程。 你今天教它你们的选题标准，明天教它你们的排版规范，它才逐渐变成对你有用的东西。

想明白这一点，后面所有的操作才有意义。莫潇羽@无忆研习社 在这块上走过弯路——一开始总想着找一个「万能提示词」一劳永逸，后来才发现，把功夫花在结构化的人格文件和技能定义上，比堆提示词有用得多。

二、新手最容易翻车的五个地方

我把这一节提到前面，是因为这些坑几乎每个人都会撞一遍。先看一眼，后面遇到就不慌了。

这五条里，第三条最反直觉，也最值得单独说两句。

我第一次遇到是这样：先把数字员工的角色定义成了「新媒体研究员，专注 AI 赛道选题」，过了两天想让它顺手做一个跟内容无关的数据整理任务，它直接回绝了，理由是「这不在我的职责范围内」。当时还愣了一下，以为是模型抽风。

后来才反应过来——这恰恰说明人格文件生效了。它是严格按照你写的职责边界在办事。这个机制本身是好的，能防止智能体乱跑，但你要知道它的存在，否则会误判成故障。正确的处理不是反复去改那份人格文件（改来改去会把定位改得四不像），而是按职能拆成多个 Agent，各管一摊。这个思路我在第九章会展开。

第一条也说一下。机器人会回复类似「OpenClaw: access not configured. Your Feishu user id: ou_xxx，Pairing code: XXXXXX，Ask the bot owner to approve with: openclaw pairing approve feishu XXXXXX」的配对信息。很多人看到英文报错就慌了，其实这是设计好的安全机制：它不认识你，需要机器主人在服务端确认一次你是谁。 每个实例生成的配对码都不一样，跟着提示做就行，不用怀疑自己装错了。

三、把服务跑起来：本地还是云端，怎么选

3.1 先做选择题，别急着敲命令

部署方式无非本地和云端两条路，各有各的合适场景。我做了张表对比一下：

我的建议很明确：如果你的目标是对接公众号、飞书这类需要固定出口 IP 和常驻在线的业务，直接上云端。 别在本地折腾，因为你迟早会撞上「IP 白名单填了没用，因为家里宽带 IP 变了」这个问题，白白浪费半天。

反过来，如果你只是想让它帮你整理本地的一堆文档、改改代码，那本地部署更合适，也更安全——数据压根不出门。

云端还有一个被低估的好处：隔离。提供独立云端环境，与本地电脑物理隔离，保障本地隐私安全。考虑到这东西有 shell 执行权限，把它关在一台可以随时重装的机器里，心理压力小很多。

3.2 云端部署：应用模板路径

现在主流云厂商基本都提供了预置镜像，不需要你手工装依赖。以腾讯云轻量应用服务器（Lighthouse）为例，路径是这样的：

登录控制台进入轻量应用服务器产品页，在新购或重装页面选择「使用应用模板」，找到「AI 智能体」分类下的 OpenClaw 镜像。注意一点：重装系统会清空服务器上的所有数据，请务必提前备份，如果是拿一台在跑别的东西的机器来改，先想清楚。

配置怎么选？这里给个通用判断，不给具体价格，因为云厂商的套餐和活动价变动非常频繁，我写稿时看到的和你看到的大概率不一样，请以官方购买页面的实时报价为准。

内存建议 4G 起步，AI 任务比较吃内存，2G 的机器跑起来会有点捉襟见肘——这个经验我认同，实测下来 2G 在装技能包的时候确实容易触发超时。

一个容易被忽略的选择项是地域。有些教程会推荐选海外区域，理由是访问某些海外接口更顺畅。这里必须明确一句：如果你的业务要对接微信公众号、飞书、企业微信这些境内平台，请老老实实选国内地域。 腾讯云自己的说明也是微信 / QQ / 企微 / 飞书等国内主流 IM 应用推荐国内地域套餐。境内平台的接口对访问来源本身就有约束，跨境访问只会给你增加不必要的麻烦。

3.3 装完先做三件事，再谈别的

镜像跑起来之后，控制台会有一个应用管理面板，先确认服务状态是「运行中」。如果不是，重装一次应用通常就好了——拉取过程偶尔会出问题，这不是什么大毛病。

接着登录服务器，做三件事：

# 1. 确认系统版本和资源，别在配置不足的机器上折腾半天
cat /etc/os-release | grep VERSION
free -h && lscpu | grep "^CPU(s)"
df -h /

# 2. 记下这台机器的公网出口 IP，后面配平台白名单要用
curl -s https://myip.ipip.net || curl -s ifconfig.me

# 3. 看清楚配置目录在哪，这是后面所有操作的根
ls -la ~/.openclaw/

第二条我要重点强调。很多人在后面配置微信公众号接口时卡住好几个小时，根因就是没搞清楚「哪个 IP 才是真正发出请求的那个」。 云服务器控制台上显示的公网 IP，绝大多数情况下就是出口 IP，但也存在不一致的情况。稳妥做法是在服务器上实际发一个请求出去看看，或者直接看平台返回的报错——报错信息里会明明白白写着它看到的来源 IP 是什么。

3.4 配置目录：先认门牌号

~/.openclaw/ 这个目录是整个系统的家。你后面所有的「调教」动作，本质上都是在改这里面的文件。先认个脸熟：

~/.openclaw/
├── openclaw.json          # 主配置文件（模型、通道、端口都在这）
├── workspace/             # 数字员工的「灵魂」目录，建议做 git 版本管理
│   ├── SOUL.md            # 人格：它是谁、什么性格、什么原则
│   ├── USER.md            # 用户画像：你是谁、你的偏好和禁区
│   ├── IDENTITY.md        # 身份名片：叫什么名字、什么形象
│   ├── AGENTS.md          # 多 Agent 路由规则与标准作业流程
│   ├── TOOLS.md           # 工具备忘：什么工具怎么用
│   ├── MEMORY.md          # 长期记忆索引
│   ├── HEARTBEAT.md       # 定时自检与主动任务
│   └── skills/            # 已安装技能，一个技能一个子目录
├── agents/<cid>/          # 每个 Agent 的独立状态
├── memory/<cid>.sqlite    # 向量记忆库
└── secrets.json           # 凭证存储

这个结构是社区整理出来的通行版本，不同版本之间会有细微差异，部分版本里还会看到 BOOTSTRAP.md（初始化用完即删）和按日期切分的 memory/ 目录。以你本机 ls 出来的实际结构为准。

一句提醒放在这里最合适：secrets.json 和 workspace 目录里可能存有明文凭证，做 git 版本管理时务必把它们加进 .gitignore，也不要把整个目录同步到公共网盘。 具体的风险第十章会详细说，现在先记住这个动作。

3.5 大模型接入：国内怎么配

OpenClaw 本身不含模型，必须外接。这一步没得省。

国内可选的路子基本是三类：

一是云厂商自家的模型服务。 腾讯云、阿里云、火山、百度这些都有自己的大模型 API，在各自的控制台里开通资源包、拿到 API Key，填进 OpenClaw 的模型配置里就行。好处是账号体系和服务器在一起，出问题好排查；网络延迟也低。

二是各家的模型聚合网关。 一个 Key 打通多家模型，适合想对比效果的人。

三是本地部署开源模型。 数据完全不出门，但对硬件要求高，个人玩家慎入。

配置时有几个实际问题：

资源包会耗尽。 这是新手最常遇到的困惑——刚才还好好的，突然回复变成「资源包用量已耗尽」。这不是故障，就是额度用完了。智能体跑自动化任务时的 token 消耗比你手动聊天高一个量级，因为它要反复读文件、调工具、重试。做预算的时候按你手动聊天的三到五倍去估，会比较接近实际。

模型能力直接影响体验。 我实测下来一个很明显的现象：用推理能力偏弱的模型时，它经常「事情做完了但忘了告诉你」——任务实际执行成功了，聊天窗口里却一句反馈都没有。换成推理能力更强的模型，这种情况明显减少。所以如果你发现它老是「干活不吭声」，先怀疑模型，别怀疑自己配置错了。

额度和套餐是动态的。 各家的资源包规格、优惠力度调整得非常频繁，本文不列具体价格，请以官方定价页面的实时数据为准。

最后一句合规提醒，写在这里比较合适：如果你打算接入境外的模型服务，需要遵守国内网络与内容管理的相关规定。 从工程角度说，国内业务场景下用境内模型服务本来也更省事——延迟低、结算方便、出问题有中文支持。这不是权宜之计，是更优解。

四、把飞书变成指挥台：一条长连接打通的全过程

4.1 为什么值得花这个功夫

服务跑起来之后，你可以直接用网页控制台跟它对话。但我强烈建议你花二十分钟把 IM 通道打通，理由很实在：

第一，随手可用。 网页控制台意味着你得先开电脑、找到那个页面。接进飞书之后，手机上发一句话就能派活，通勤路上、开会间隙都能用。这个体验差别比听起来大得多。

第二，天然支持多人协作。 把机器人拉进群，团队里谁都能给它派活，输出结果全组可见。这才是「数字员工」这个说法真正成立的地方——它不是你一个人的玩具，是团队的一个工位。

第三，文件流转顺畅。 技能包、待处理文档，直接在聊天窗口里拖进去就行，省掉了一轮上传下载。

至于选哪个 IM，看你团队本来在用什么。企业微信、钉钉、飞书都支持。我这里以飞书举例，是因为它的开发者后台对个人开发者最友好，权限颗粒度也做得最细。

4.2 完整链路：七步走通

我把整个流程画成时序图，先建立全局印象，再逐步拆：

sequenceDiagram
    participant U as 你
    participant FS as 飞书开放平台
    participant OC as OpenClaw 服务端
    participant IM as 飞书客户端

    U->>FS: 1. 创建企业自建应用
    U->>FS: 2. 添加「机器人」能力
    U->>FS: 3. 批量导入权限并申请开通
    FS-->>U: 返回 App ID / App Secret
    U->>OC: 4. 在通道配置里填入凭证
    OC->>FS: 5. 建立 WebSocket 长连接
    FS-->>OC: 连接成功
    U->>FS: 6. 保存订阅方式 + 添加接收消息事件
    U->>FS: 7. 创建版本并发布应用
    U->>IM: 发第一条消息
    IM->>OC: 转发消息
    OC-->>IM: 返回配对码
    U->>OC: 在服务器执行配对命令
    OC-->>IM: 通道打通，正常对话

第一步，创建应用。 进入飞书开放平台的开发者后台，创建「企业自建应用」。注意选的是自建应用，不是小程序也不是网页应用。名字随便起，但建议起得有辨识度——以后你可能会建好几个，各管一摊，名字混了会很麻烦。企业用户可以传自己的 Logo，个人玩就用默认的。

第二步，添加机器人能力。 在「添加应用能力」里选「机器人」并开启保存。这一步不做，后面所有事情都白搭——没有机器人能力，它连消息都收不到。

第三步，配权限。 这是最烦但也最关键的一步。需要的权限至少包括：im:message（消息基础权限）、im:message:send_as_bot（以应用身份发消息）、im:message.p2p_msg:readonly（读取私聊消息）、im:message.group_msg:readonly（读取群聊消息），以及接收群聊中 @ 机器人消息的事件权限。

一个一个勾会勾到崩溃。飞书后台在「权限管理」里提供了「批量导入 / 导出权限」的入口，支持直接粘贴一段 JSON 配置进去。我的建议是：先想清楚你要用到哪些能力，再决定导入哪份权限清单。 如果你之后打算让它读写飞书文档、操作多维表格，那还得额外开通云文档相关的权限（docx 系列和 drive 系列），否则到时候会卡在「没有权限访问该文档」。

这里有个安全上的取舍必须说清楚。网上流传的一些「省事做法」是把 im:、contact:、file: 这些前缀下的权限全勾上，图个一劳永逸。如果你的飞书账号里有真实的企业通讯录、合同文件、内部沟通记录，请不要这么干。 权限一旦开出去，智能体在被提示词注入攻击时能触达的范围就是这么大。个人玩票的空账号可以粗放一点，企业环境请老老实实按需申请。这个判断我在第十章还会回来讲。

第四步，拿凭证填进去。 在「凭证与基础信息」页面复制 App ID 和 App Secret，回到 OpenClaw 的通道配置页，选择飞书通道、手动配置，两个值分别填进去，保存并重启服务。

第五步，确认长连接建立。 这一步没有明显的界面提示，你得去看服务日志。为什么这一步重要？因为下一步依赖它。

第六步，配置事件订阅。 回到飞书后台的「事件与回调」页面，订阅方式选择「使用长连接接收事件」，不是 Webhook。然后保存。

这里是新手第一个高频卡点：必须先完成服务端配置并确认长连接已经成功建立，否则保存订阅方式时会报「未检测到应用连接信息」。 顺序反了就走不通。很多人在这里反复试、反复失败，其实只是把第五步和第六步做颠倒了。

保存成功后，「添加事件」按钮才会变成可用状态。点进去搜索「接收消息」，勾选 im.message.receive_v1，确认添加。确保事件开关是开启状态。

「回调配置」那一栏同样要处理一下，订阅方式也选长连接，保存。

第七步，创建版本并发布。 填个版本号（1.0.0 就行），写一句更新说明，选择可见范围，提交发布。企业环境下可能需要管理员审批，个人开发者一般是即时生效。发布成功后，飞书里的「开发者小助手」会推送一条通知告诉你应用已安装。

4.3 那条「英文报错」其实是安全机制

发布完成后，去飞书里找到你的机器人，发一句「你好」试试。

大概率你会收到一段英文，大意是「access not configured」，后面跟着你的飞书 user id（ou_ 开头的一串）和一个配对码（Pairing code），最后是一句提示：让机器人的主人执行 openclaw pairing approve feishu <配对码> 来批准。

这不是报错，这是它在做身份确认。 设计逻辑很简单：飞书那边任何人都可能给这个机器人发消息，但不是任何人都有资格指挥它干活。所以第一次对话时，它会生成一个一次性配对码，要求机器主人在服务端亲手确认一次。

处理方式：把那条命令复制下来，登录服务器（云控制台一般都提供免密登录的入口，不用自己配密钥），粘贴执行，回车。

# 把 <配对码> 换成你自己收到的那一串
openclaw pairing approve feishu <配对码>

执行成功后，回飞书再发一句话，就能正常对话了。

每个实例生成的配对码都不一样，所以你在教程截图里看到的码跟你自己拿到的对不上，完全正常，不用怀疑装错了。这一点我特意写出来，是因为莫潇羽@无忆研习社 当初就在这儿愣了两分钟。

4.4 打通之后的常见状况

最后一个值得展开说：多人共用一个机器人时，如果不做会话隔离，A 说的话会污染 B 的上下文，输出会变得莫名其妙。配置项在通道设置里，把 session 的 dmScope 设为按渠道和对话方隔离，问题就消失了。团队使用场景下，这个配置基本是必选项。

五、给数字员工装上人格：workspace 里那几个 md 文件

5.1 这一步比装技能更重要

很多人拿到 OpenClaw 的第一件事是狂装技能，结果发现「装了一堆，用起来还是很笨」。

问题出在顺序上。技能决定它「能做什么」，人格文件决定它「该做什么、怎么做、为谁做」。 后者没定好，前者装再多也是一盘散沙——它不知道你要什么，只能瞎猜。

打个比方：你招了个新人，给他配了全套软件许可证（技能），但没告诉他公司是干什么的、他的岗位职责是什么、老板的偏好是什么（人格文件）。他能干活吗？能，但干出来的东西你多半用不上。

~/.openclaw/workspace/ 目录下那几个 Markdown 文件，就是在解决这件事。全是纯文本，不用写代码，用记事本都能改。

5.2 各个文件分别管什么

社区里流传一句总结我觉得挺到位：风格看 SOUL，对象看 USER，流程看 AGENTS，少一个都容易翻车。

5.3 SOUL.md 怎么写

先做个动作：直接问它「你现在的 SOUL.md 是什么内容？用中文回复」。

它会把当前的人格设定念给你听。默认版本是英文的，内容大致是强调「要真诚地提供帮助，而不是表演式地提供帮助」「要有自己的观点」这类通用取向。这份默认设定作为通用助手没问题，但对具体业务场景来说太宽泛了。

我的写法是分四块：

# SOUL.md

## 角色定位
你是一名内容运营助理，服务于一个小型消费品牌团队。
你的主要工作是：行业资讯梳理、竞品内容拆解、初稿撰写、素材归档。

## 性格与语气
- 专业但不端着，像一个靠谱的同事
- 结论前置，先说判断再讲依据
- 不说套话，不用「首先其次最后」这种模板结构
- 拿不准的事直接说不确定，不猜

## 工作原则
1. 所有对外信息必须标注来源，无法核实的一律不写
2. 涉及数据引用时，注明是官方口径还是二手转述
3. 不编造案例、不虚构数据、不夸大效果
4. 任何生成内容都视为初稿，最终发布由人工确认

## 红线（不可越过）
- 不得在未经确认的情况下向外部平台发布任何内容
- 不得删除或覆盖用户的原始文件，改动前先备份
- 不得在输出中包含任何绝对化的效果承诺
- 涉及医疗、金融、法律等专业领域的判断，只提示需咨询专业人士

写完之后，把整段内容发给它，让它更新 SOUL.md。它会自己改文件，改完还会跟你复述一遍新的设定，你顺便就能检查有没有理解偏差。

最后那个「红线」部分我建议每个人都写，而且要写死。 尤其是第一条——不经确认不对外发布。这不是形式主义，是给你自己留的保险。这东西有真实的执行权限，一旦人格文件里没有约束、模型又误解了你的意图，它是真的会把东西发出去的。第八章我会讲为什么这条在 2026 年尤其重要。

5.4 USER.md 怎么写

SOUL 定的是「它是谁」，USER 定的是「你是谁」。这份文件的作用是让它理解你的工作场景和偏好，少走弯路。

# USER.md

## 基础信息
- 称呼：直接叫名字就行
- 时区：Asia/Shanghai
- 角色：小型消费品牌的内容负责人
- 团队规模：三到五人

## 当前重心
- 正在搭建从选题到初稿的自动化流程
- 主力平台是公众号，其他平台以内容复用为主

## 输出偏好
- 语言：中文，除非我明确要求英文
- 排版：少用 emoji，不要机械排比
- 长度：日常回复控制在三百字以内，长文另说
- 黑名单表达：不要写「祝您工作顺利」这类客套话

## 雷区
- 不要擅自修改 workspace 目录结构
- 不要在没确认的情况下调用任何对外发布类技能
- 涉及金额、政策、平台规则的内容，必须提示我去核实实时口径

这份文件的价值会随时间递增。刚开始你可能觉得没必要写这么细，但用上一个月之后，你会发现自己反复在纠正同样的毛病——把这些纠正沉淀进 USER.md，就不用再重复第二遍了。

5.5 一个必须提前知道的机制：角色边界会真的生效

这是我前面在「五个坑」里点过的第三条，这里展开讲。

当你把 SOUL.md 里的角色定位写得很具体时，它会严格按这个范围办事，超出范围的任务会被拒绝。

举个我自己遇到的情况：先把它定义成「内容运营助理」，过几天想让它顺手做一件跟内容无关的事——整理一批公开数据、生成一张汇总表。它拒绝了，理由是这不属于内容运营的职责范围。

第一反应是「这不是变笨了吗」，冷静下来想，这恰恰是设计得对的地方。一个什么活都接的智能体，才是真正危险的。 边界清晰意味着它不会在你没想到的地方乱伸手。

那需求怎么办？有三条路：

路子一：改 SOUL.md，把新职责加进去。 最直接，但有副作用——改多了角色定位会越来越模糊，最后变成一个什么都会一点、什么都不精的四不像。我不推荐反复用这一招。

路子二：开新的 Agent。 一个负责内容、一个负责数据整理，各自有独立的人格文件和技能集。这是我现在的主力做法，第九章展开。

路子三：临时提权。 在单次对话里明确说明「这次任务是临时授权的例外」，多数情况下它会配合。适合一次性需求，不适合常态化。

顺带说一个观察：新手最容易犯的错，是一遇到拒绝就去疯狂改 SOUL.md。 改到最后那份文件变成一大坨互相矛盾的描述，模型也不知道该听哪句，行为就开始飘忽不定。人格文件要像岗位说明书一样保持克制，宁可开新岗位，不要把一个岗位写成万金油。

5.6 HEARTBEAT.md：让它主动干活

前面讲的都是「你说一句、它做一件」。真正让效率产生质变的，是让它自己按时干活。

HEARTBEAT.md 就是干这个的——定义定时执行的逻辑和主动任务的自检清单。

# HEARTBEAT.md

## 每个工作日 08:30
1. 检索指定信源列表的最新内容
2. 按选题标准筛出五条候选，写入飞书多维表格
3. 在飞书里给我发一条摘要消息，等我挑

## 每周五 17:00
1. 汇总本周产出的稿件清单和状态
2. 检查 workspace/skills/ 下是否有未使用的技能
3. 生成一份周报草稿存到指定目录

## 自检项（每次心跳都跑）
- 检查模型额度是否充足，低于阈值时提醒
- 检查上一轮定时任务是否有未完成项

我的建议是别一上来就配定时任务。先手动跑通完整流程，确认每一步都稳定了，再把它固化成心跳任务。否则一个环节出错，定时任务会每天给你制造一堆垃圾，还得花时间清理。

调试阶段有个小技巧：如果你从别处抄了一段带定时器的提示词，想立刻看效果，把定时器相关的表述先删掉，让它当场执行一次。跑通了再把定时逻辑加回去。这个顺序能省掉大量等待时间。

六、Skill：数字员工的手和脚

6.1 先把概念说明白

术语先解释一句：Skill（技能）就是一个装了说明书的文件夹，告诉模型「遇到某类任务时，按这个步骤、调这个工具、输出这个格式」。

它跟「插件」不完全是一回事。传统插件是一段代码，你得按接口规范去写；Skill 的主体是一份 Markdown 说明书，模型读懂了就会照做。这个设计的妙处在于——写技能的门槛从「会编程」降到了「会把流程讲清楚」。

用一个日常类比：你新招了个财务，他人是聪明的，但不知道你们公司报销走什么流程、用哪个系统、单据怎么归档。你写一份《报销操作手册》给他，他照着就能干活。Skill 就是这份手册。

技能生态还有一个交易场的概念，开发者可以把自己写的技能发布上去，别人可以下载使用。这让能力具备了可插拔、可扩展、可共享的属性。

6.2 SKILL.md 的标准结构

一个 Skill 的目录长这样：

my-skill/
├── SKILL.md          # 必须：定义 + 指令
├── scripts/          # 可选：可执行脚本
├── references/       # 可选：按需加载的参考文档
└── assets/           # 可选：输出用的资源文件

核心是 SKILL.md，遵循 AgentSkills 规范，头部是一段 YAML frontmatter：

---
name: daily-industry-digest
description: 每日抓取指定信源的公开资讯，去重、分类、生成中文摘要日报。当用户提到"资讯日报""行业动态汇总""每日简报"时触发。
user-invocable: true
metadata: { "openclaw": { "emoji": "📰", "skillKey": "daily-industry-digest" } }
---

（下面是 Markdown 正文，写给模型看的完整操作指令）

这里面最值得琢磨的是 description 这个字段。它不是写给人看的注释，是模型判断「要不要调用这个技能」的唯一依据。

技能的 name 和 description 会被注入到系统提示词里，模型根据用户意图自动判断是否调用。所以描述写得含糊，技能就永远不会被触发；描述写得太宽，又会在不该触发的时候乱触发。

我的经验是：description 里一定要写清楚「什么情况下用」，最好把用户可能说的原话关键词直接列进去。 对比一下：

正文部分写什么？把这四件事讲清楚就够了：这个技能做什么、需要哪些输入、执行什么流程、输出什么格式。 跟你给一个新同事写作业指导书是一个道理。

6.3 先摸清家底：它自带了哪些能力

装新技能之前，先看看已经有什么。直接问它：

请列出你当前所有可用的技能，包括系统自带的，按功能分类，并说明每个技能的用途。

它会给你一份完整清单。以我实测的云端实例为例，开箱状态下就自带了几十个技能，覆盖这么几类：

• IM 通道类：飞书、企业微信等国内主流沟通工具的消息收发
• 文档协作类：飞书文档读写、多维表格操作、云盘文件管理
• 系统操作类：文件读写、shell 执行、定时任务
• 浏览器自动化类：网页访问、内容提取、表单操作
• 信息获取类：天气查询、代码托管平台交互
• 记忆管理类：长期记忆的写入与检索

这一步千万别跳过。 我见过太多人上来就装一堆第三方技能，装完才发现系统里本来就有一个功能重复的，白白增加了攻击面和维护成本。

顺便说一句：同名技能会按优先级覆盖，本地技能目录优先级最高。所以如果你装了一个跟自带技能同名的第三方包，实际生效的是哪个，得看它在哪一层。这个坑不常见，但踩上一次能查半天。

6.4 装技能的三条路径

路径一：对话式安装。 最舒服的方式，直接跟它说：

帮我安装 X 技能。安装完成后告诉我哪些成功、哪些失败，失败的说明原因。

后半句很重要。你要养成给它下达「必须回报结果」指令的习惯——就像你派活给同事，不能只说「去做」，还得说「做完跟我说一声，有问题及时反馈」。不加这句，它经常默默装完就不吭声了，你也不知道到底成没成。

路径二：离线包安装。 这条路是给网络不畅的场景准备的。

现实情况是：部分技能仓库托管在境外，从国内直连的稳定性和速度都不理想，安装时容易触发超时和重试。 这不是什么需要绕过的技术难题，解法很朴素——用离线技能包。

做法是把技能目录打包成压缩包，在飞书里直接把文件拖给机器人，然后说：

联网安装失败，请从我发给你的这个压缩包里安装技能。

它会自己解压、放到正确的目录、完成配置。这个路径的另一个好处是可复现：你在一台机器上调好的技能组合，打个包，换台机器原样装上，不用重新折腾。团队内部分发技能也是这么干的。

路径三：手写目录。 最原始也最可控。自己在 ~/.openclaw/workspace/skills/ 下建目录、写 SKILL.md，重启服务即可生效。适合你要写高度定制化的内部技能。

6.5 让它自己写一个技能

这是我觉得整个系统里最有意思的部分：你可以用自然语言让它给自己造工具。

举个通用化的例子。假设我想要一个「行业公开资讯日报」的技能——每天从我指定的几个公开信源抓取内容，去重、分类、生成中文摘要。我不用自己写代码，直接说：

帮我创建一个技能，名字叫 daily-industry-digest。
功能：每日从我指定的信源列表抓取公开资讯，做去重和分类，生成中文摘要日报。
输入参数：信源列表（URL 数组）、时间范围（默认最近 24 小时）、分类维度（默认按主题）。
执行流程：逐个抓取信源 → 提取标题和正文摘要 → 按标题相似度去重 → 按主题分类 → 每条生成不超过八十字的中文摘要 → 汇总成 Markdown。
输出格式：Markdown 文档，包含日期、总条数、分类小标题、每条的标题 / 摘要 / 来源链接。
约束：只抓取公开可访问的页面，不做任何需要登录的操作；无法访问的信源跳过并在末尾列出。

发过去之后，它会自己写 SKILL.md、写辅助脚本、放到正确的目录、然后告诉你技能已经创建完成、核心功能是什么、怎么调用。

这里有个前提条件很多教程不讲：如果你的 SOUL.md 把角色定得太窄，它可能会拒绝创建跟这个角色无关的技能。 遇到这种情况，参考第五章的三条路子处理。我的做法是给「造工具」这件事单独开一个 Agent，人格定位就是「技能开发助手」，专职干这个，不跟业务 Agent 混在一起。

创建完之后一定要实测一次：

用 daily-industry-digest 技能跑一次，信源用我给的这三个，时间范围最近 24 小时。

跑通了再谈别的。我见过不少人技能创建成功就以为完事了，实际用的时候发现输出格式跟预期完全不一样——因为需求描述里格式部分写得太模糊。技能是要迭代的，第一版能跑就不错了。

6.6 技能来源：这是一个真实的安全问题

写到这里必须插一段警告，因为这是新手最容易忽视、后果又最严重的地方。

国家互联网应急中心在今年三月发布过关于 OpenClaw 安全应用的风险提示，明确点出了四类风险：提示词注入、误操作、插件投毒、安全漏洞。 其中「插件投毒」说的就是技能来源问题。

具体的攻击方式很朴素：有人写一个功能看起来正常的技能包，在里面藏一段恶意代码。你装上之后，它可能会读取你的凭证文件、把数据外传，或者把你的机器变成攻击跳板。因为 OpenClaw 有宿主机的高权限，一个恶意技能能造成的破坏远超普通浏览器插件。

我的做法是三条：

第一，来源可控。 官方渠道、可信社区、自己写的，这三类之外的技能包一律先不装。来路不明的压缩包，尤其是从聊天群里随手转来的，不要直接拖进去。

第二，装之前看一眼。 技能的主体是 Markdown 和脚本，是可读的。花两分钟扫一遍 SKILL.md 和 scripts/ 目录，看看有没有莫名其妙的网络请求、有没有读取 ~/.openclaw/ 下凭证文件的动作。看不懂也没关系，把内容贴给 AI 让它帮你审一遍。

第三，定期清理。 用不上的技能就卸载掉。装着不用的技能对你没有任何价值，但每一个都是一个潜在的入口。

这一段是全文我最希望你记住的部分之一。技能生态的开放性是这个项目的优势，也是它最脆弱的地方。

七、内容流水线：从选题到成稿怎么串起来

7.1 先说清楚这条流水线到底解决什么问题

内容团队的日常大概是这样的：早上刷一圈行业信息找选题，中午定下写什么，下午写稿排版，傍晚发出去。其中真正需要人的判断力的，其实只有「定选题」和「终审」这两步。中间那些——检索、去重、整理、初稿、排版——都是机械劳动。

自动化要解决的就是中间这段。不是替你决定写什么，而是把你决定之前需要看的东西整理好、把你决定之后的体力活干掉。

这个定位一定要摆正。我见过不少人期待「一句话生成一篇能直接发的爆款」，然后失望地放弃。真实的体验是：它能把你从八小时压到两小时，但那两小时是省不掉的。

为了讲得具体，下面我用一个虚构的案例贯穿：假设有一个小众户外品牌叫「野渡」，主打便携式咖啡冲煮套装，团队三个人，主要阵地是公众号。所有数据和情节都是为讲解构造的，不对应任何真实企业。

7.2 第一步：把信源框死

新手做这条流水线，第一个翻车点几乎都在这儿——不限定信源，让它「去网上搜」。

结果是什么？它会抓回来一大堆内容农场的稿子、标题党、二手转述，甚至互相矛盾的信息。基于这种素材做出来的选题，质量可想而知。

我的做法是在提示词里写死一份信源白名单：

## 信源白名单（只从这些地方取材，其他一律不采信）

### 一级信源（优先）
- 相关行业协会 / 标准化组织的官网公告
- 头部品牌的官方账号与官网新闻页
- 公开的行业白皮书、调研报告

### 二级信源（可用，需标注来源）
- 有编辑部背书的垂直行业媒体
- 主流科技 / 商业媒体的行业报道

### 排除项
- 无署名、无来源标注的聚合站内容
- 明显以引流为目的的营销号内容
- 无法追溯原始出处的二手转述

## 取材规则
1. 每条素材必须记录：标题、原文链接、发布时间、来源名称
2. 同一事件被多个信源报道时，以一级信源的表述为准
3. 涉及具体数据的，注明是官方口径还是媒体测算
4. 无法核实来源的内容，直接丢弃，不要写进结果

这一段模板你可以直接拿去改。把里面的信源类型换成你所在行业的，其他结构不用动。

限定信源带来的质量提升是立竿见影的。 我实测下来，加了白名单之后，选题的可用率从三成左右提到了七成以上——这不是精确统计，是我自己按周做记录得出的粗略感受，仅供参考。

7.3 第二步：三段式工作流

我把整条流水线拆成三段，每段之间留一个人工确认点。

flowchart LR
    A["段一：选题<br/>定时触发"] --> A1["按白名单检索"]
    A1 --> A2["去重 + 打分"]
    A2 --> A3["输出候选清单<br/>写入协作文档"]
    A3 --> P1{"人工挑选"}
    P1 --> B["段二：拆解<br/>学习对标内容"]
    B --> B1["拆结构 / 开头 / 节奏"]
    B1 --> B2["形成写作要点"]
    B2 --> C["段三：成稿"]
    C --