经常写公众号的朋友应该都有这种体验：让大模型帮你起个初稿很容易，但出来的文字总有一种说不出的“班味”，开头必是“随着”，结尾必是“总而言之”，段落工整得像在填表格，每段三句话，每句话都挑不出毛病，可连在一起就是没人想读。读者可能说不清哪里不对，但直觉会告诉他们：这是 AI 写的。我从前年开始折腾 OpenClaw，用这个 AI Agent 框架去跑公众号内容生产流程，后来又在中间加了一层 Humanizer 做文本后处理，专门用来把机器生成的语言重新“翻译”成人话。这套组合我稳定用了小半年，公众号文章的打开率和留言率都明显比纯 AI 草稿好，今天就把完整的思路、部署、配置和踩坑记录整理出来，希望能帮到同样想用 AI 提效又不想被一眼看穿的朋友。
我先说清楚这套方案适合谁：适合已经用大模型写过公众号文章、觉得“能写但没灵魂”的人，也适合想搞半自动内容流水线、让 AI 帮你完成初稿和排版、但最终发布前仍要人工把关的运营者。它的核心不是让机器完全替代人，而是把机械劳动剥出去，把文字的温度留下来。
1. 为什么公众号写作需要“OpenClaw + Humanizer”这套组合
1.1 公众号文章的“AI味”到底出在哪
早期我直接用 ChatGPT、文心一言这类产品写公众号，拿到初稿后经常不知道怎么改。后来我认真对比过 AI 生成文本和真人文章的差异，发现问题不在“对错”，而在“习惯”。大模型在生成时倾向于选择概率最高的词、最稳妥的句式，比如高频率使用“首先、其次、最后”，喜欢把句子写得完整且对称，还特别爱用“值得注意的是”“不难发现”这类连接语。真人写公众号不是这样，真人会为表达情绪牺牲点语法正确性，会突然来一个短句，会在该收住的地方果断收住。
这种差异本质上是“过度工整”造成的。大模型不会像人一样有表达冲动，它只是在所有位置选了最不容易出错的词语。这个现象在长文里尤其明显，模型生成的段落越长，越容易出现“每段都正确但从头到尾没有重点”的问题。公众号文章是给人看的，读者需要的不是全对，而是“读得下去”。所以只靠提示词让模型“写得口语一点”不够，需要有一层专门做文本风格修正的工具。
1.2 OpenClaw 和 WorkBuddy 这类工具怎么选
选 OpenClaw 而不是直接用 WorkBuddy，或者干脆用一个在线写作工具，核心原因是 OpenClaw 足够开放。WorkBuddy 这类商业化 Agent 工具也有不少人用，界面漂亮、上手快，内置了很多模板，配置好后也能生成文章，但问题在于它的流程是封闭的。你很难在生成初稿后插入一个自定义的“文本人味化”处理步骤，更没办法把一个本地跑着的人性化改写服务接进去。而 OpenClaw 本质上是一个开源的 Agent 运行框架，模型可以自己接，渠道可以自己配，中间环节也能通过工具调用或者 HTTP 请求打通，这对做内容生产的人来说太关键了。
另外 OpenClaw 支持多 Channel，可以把飞书、微信公众号、Telegram、网页控制台这些入口统一管理。我看过不少人在问“OpenClaw 和 WorkBuddy 哪个好”，我的看法是：如果你的需求是“点几下鼠标就能生成文章”，WorkBuddy 省心；如果你的需求是“让 AI 自动化地完成选题、写稿、改稿、送审、进草稿箱”，OpenClaw 的可定制性才真正够用。我属于后者，所以我选了它。
| 对比维度 | OpenClaw | WorkBuddy |
|---|---|---|
| 开源程度 | 开源，可自托管 | 偏商业化封闭产品 |
| 模型接入 | 支持 OpenAI 兼容接口、本地模型、魔塔等渠道 | 以官方内置模型为主 |
| 流程自定义 | 可通过代码、API、工具函数自由扩展 | 依赖产品内置自动化节点 |
| 上手成本 | 需要一点命令行和配置基础 | 对新手更友好 |
| 适合场景 | 想搭自动化内容管线的折腾型用户 | 不想折腾、开箱即用的轻量用户 |
1.3 Humanizer 不是“降AI率”，而是“补人味”
很多人第一次听到 Humanizer，会想到市面上那些“降 AI 率工具”。我不太喜欢这个叫法，因为“降 AI 率”听起来像在做文字伪装。我实际用下来的体会是，Humanizer 真正做的事情是“把机器生产的书面语重新拉回日常口语”。
我用的是本地部署的 Humanizer 服务，它的处理逻辑分几步：第一步，拆长句，把一段三行以上的长句切成两个短句；第二步，替换高频 AI 连接词，比如“首先”改“先说”，“最后”改“还有”；第三步，打散工整的排比结构，把“它能够A，能够B，能够C”改成“它不光能A，B和C也顺手干了”；第四步，在合适位置插入第一人称视角的表达，比如“我之前试过”“你注意看这里”。这四步做完，文字的“AI味”自然就淡了。
有人可能会问，直接让大模型在提示词里写“口语一点”不行吗？我试过，效果不稳定。大模型理解“口语一点”是抽象概念，它不知道怎么把已经生成的段落做局部手术。Humanizer 这种独立后处理的好处是：初稿该怎么写就怎么写，生成完了统一改，规则可控，效果可量化。对我来说，它相当于给 OpenClaw 配了一个负责“改稿”的文字编辑。
2. 环境准备：把 OpenClaw 跑起来
2.1 Windows 和 Linux 的部署差异
OpenClaw 的部署方式取决于你的系统。Linux 最省事，只要装了 Docker 和 Docker Compose，clone 项目仓库后把.env.example复制成.env，填好配置，再执行docker compose up -d就能跑起来。Windows 这边稍微多几步，因为 OpenClaw 依赖 Docker，而 Docker Desktop 在 Windows 上又依赖 WSL2。我看很多人卡在“OpenClaw 安装时提示 could not safely verify the WSL2 environment”这一步，这个提示的意思是说安装脚本无法确认你的 WSL2 环境是正常的。
解决方法不复杂。先打开 PowerShell，管理员模式执行wsl --update，再执行wsl --set-default-version 2。如果机器上有多个 Linux 发行版，还要确认默认版本是 2，可以用wsl --status查看。最后重启 Docker Desktop，再去跑 OpenClaw 安装脚本就能通过检测了。如果还是不行，检查一下 Windows 功能里有没有开启“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，这两项没开也会导致校验失败。
这里也补充一句，Windows 下我不建议用 Docker Desktop 的“直接挂载盘符”方式去放 OpenClaw 的项目目录，路径最好放在 WSL2 的文件系统里，比如~/openclaw。放 Windows 盘经常会出现文件权限和路径格式问题，重试多次才反应过来，纯属浪费时间。
2.2 接入模型：千问、模型服务与本地模型怎么配
OpenClaw 本身不自带模型能力，它需要接一个大模型来当 Agent 的“大脑”。国内用户我推荐接入千问系列，也就是通义千问，理由很直接：中文语感好，指令遵循能力稳，API 价格相对亲民。OpenClaw 可以通过 OpenAI 兼容模式接上千问的 API，只需要在配置里把 Base URL 指向阿里云百炼的兼容地址。
如果你是刚上手，配置在.env里，核心参数大概是这样：
# 模型供应商选择 openai-compatible，因为千问开放了兼容接口 LLM_PROVIDER=openai-compatible LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 LLM_API_KEY=sk-你的密钥 LLM_MODEL=qwen-plus如果你的内容量不大，qwen-plus性价比最高；想要更强的长文控制能力，就换qwen-max。这段时间总有人问 OpenClaw 能不能“对接魔塔”，这里也说明一下，魔塔 ModelScope 上有不少开源模型权重，你可以用 Ollama 这类本地推理工具把模型跑起来，然后给 OpenClaw 配一个本地接口。我试过用 qwen2.5-7b 跑本地版，速度可以，但在公众号这种长文场景下，本地小模型的上下文连贯性还是不如云端大模型，容易写着写着就跑偏。
2.3 Channel 链路设计：公众号写作场景要连哪些
OpenClaw 里的 Channel 是一个很关键的概念，你可以把它理解成一个“消息出入口”。它既能接收任务，也能往外发送内容。具体到公众号写作这件事，我不建议直接把公众号后台交给 Agent 全自动发布，风险太大，而且公众号一天的发文次数有限，草稿一旦出错就很麻烦。我一般这样设计链路：输入端用飞书，因为我可以在飞书里给 OpenClaw 发指令、审核标题摘要；输出端用微信公众号接口，OpenClaw 把写好的内容推到公众号草稿箱，而不是直接群发；最后一步人工在公众号后台点一下发布按钮。
这样做的好处是，Agent 负责跑完所有脏活累活，人到最后一个环节做判断。别小看这个设计，如果 OpenClaw 直接把内容群发，万一数据引用错了，或者出现了 AI 编造的人名，文章就撤不回来了。草稿箱模式给了人一个缓冲空间。
有不少人问过“OpenClaw 能发消息微信，但微信发消息没回复”是怎么回事，大概率就是 Channel 的收发链路没配对。OpenClaw 通过某个渠道把消息发出去了，但这不等于它能接收微信消息。接收消息需要配置微信平台的服务器回调地址，个人微信还要依赖额外的 Hook 能力，容易触发风控，所以我不建议把个人微信作为输入输出通道。公众号场景就老实用公众号接口，配合飞书做日常交互，稳得多。
2.4 最小可运行配置实例
我下面给一个最小可运行配置模板，但注意不同版本字段名可能略有出入，最稳妥的做法是打开项目里的.env.example对着填。我的配置文件大概长这样：
# .env OPENCLAW_ENV=production LLM_PROVIDER=openai-compatible LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 LLM_API_KEY=sk-你的密钥 LLM_MODEL=qwen-plus # Humanizer 服务地址，后面会讲到 HUMANIZER_API_URL=http://127.0.0.1:8787/humanizeChannel 配置我放在config.yaml里：
channels: feishu: enabled: true app_id: cli_your_app_id app_secret: your_app_secret wechat_official: enabled: true app_id: wx_your_app_id app_secret: your_app_secret这里我刻意留了空值，密钥只放在本地.env里，不要提交到 Git。配置完之后，启动 OpenClaw，先去飞书给它发一条“你好”，看它能不能回。飞书通了再配置公众号渠道，每一步都验证完再往前走，别一上来就全接好，出了问题根本不知道是模型、网络还是 Channel 的问题。
3. 把 Humanizer 接进 OpenClaw 工作流
3.1 Humanizer 的处理逻辑和接入位置
Humanizer 我建议单独部署成一个本地 HTTP 服务，这样 OpenClaw 可以通过工具调用或者 Webhook 把它接到工作流里。它的内部逻辑不复杂，但放在那个位置很有讲究：初稿生成之后，进入公众号草稿箱之前。
为什么不能放在初稿生成之前？因为大模型生成文本是逐字预测的，如果我们在提示词层面强行要求“请用人类风格写作”，模型确实会做一些调整，但它无法保证每个段落都达到我想要的自然度。更重要的是，后处理阶段我们可以自己控制规则，比如设置“每段最多两个冒号”“尽量少用首先其次”“长句比例不能超过多少”，这些规则在生成阶段很难稳定执行，但在后处理阶段可以用代码精确控制。
我用的 Humanizer 核心流程是这样的：收到初稿后，先做段落切分和句子边界识别，然后逐个判断句子长度和句式类型，如果发现超过 40 个字的长句，就尝试从连接词或逗号处拆开；接着，把高频出现的“首先、其次、然后、最后、总之”等词替换成更自然的说法；再往后，检测排比句，如果发现连续三个相同结构，就重写其中一两个；最后会往文章里插入一些和主题相关的个人视角短句，比如“这里我说一下自己的感受”。整个过程大概几秒钟，HTTP 接口调用完后返回改写版文本。
3.2 自动化流水线：从选题到公众号草稿箱
有了 OpenClaw 和 Humanizer，一条完整的公众号生产流水线是这样跑的：
第一步，我在飞书里给 OpenClaw 发一条指令，比如“根据我今天发给你的三篇参考资料，写一篇关于 AI Agent 的公众号文章，1200 字，读者是运营人员”。第二步，OpenClaw 收到任务后，先调用千问生成初稿，同时生成标题候选和摘要。第三步，OpenClaw 把初稿 POST 到 Humanizer 服务，让改写后的文字变自然。第四步，OpenClaw 调用微信公众号接口，把处理后的正文推送进公众号草稿箱。第五步，我打开公众号后台，看一遍草稿，改改标题，配个图，最终点击发布。
第四步里涉及微信公众号接口。公众号新增草稿的接口是POST https://api.weixin.qq.com/cgi-bin/draft/add?access_token=ACCESS_TOKEN，Body 里带一个articles数组，正文放在content字段里。OpenClaw 里可以写一个简单的 Python 工具函数来实现：
import requests def add_wechat_draft(access_token, title, content_html): url = f"https://api.weixin.qq.com/cgi-bin/draft/add?access_token={access_token}" payload = { "articles": [ { "title": title, "author": "博主", "digest": "摘要需要有点钩子", "content": content_html, "content_source_url": "" } ] } resp = requests.post(url, json=payload) return resp.json()这里需要注意，公众号正文接口接收的是 HTML 内容，不能直接贴纯文本。我的做法是把自然段用<p>标签包起来，标题用<h1>或<h2>，需要加粗的关键句用<strong>。公众号后台对复杂 HTML 样式的支持有限，越简单越好，别塞一堆<section>和 inline style，后台改起来很痛苦。
3.3 实操案例：一篇科技资讯如何被“说人话”
我拿一个真实的例子来说。假设 OpenClaw 生成的初稿是这样：
“随着人工智能技术的快速发展，智能体已经成为企业数字化转型的重要抓手。首先，它能够自动化处理大量重复性任务。其次，它能够通过自然语言与用户进行无缝交互。最后，它能够显著降低企业运营成本，提升整体效率。”
这段话语法完全正确，但就是典型的 AI 味。Humanizer 处理完之后变成：
“最近总有人问我，AI 智能体到底能干嘛。说简单点，它就像个帮你盯着流程、替你把重复活干掉的数字员工。你不用学复杂的系统，用大白话告诉它要做什么，它就能把任务拆开，一步步跑完。”
前后差别在哪？第一，开头不再用“随着”，直接抛出一个真实的问题。第二，原文里的“首先、其次、最后”结构全部取消了，换成了一个更松散的叙述。第三，加了“说简单点”这个口语过渡词，读者会觉得有人在对着他说话，而不是在念报告。第四，句子长短变了，有短句“说简单点”，也有中等长度的解释句，读起来有节奏。
这个案例是我之后做所有 Humanizer 规则的基础：本质不是替换几个词，而是把“汇报式表达”改成“对朋友解释”。
3.4 公众号排版与发布时的小细节
就算文字已经“人味”到位了，公众号发布环节还是有几个细节需要注意。
标题长度尽量控制在 64 字以内，否则在一些用户的消息列表里会被截断。摘要不能偷懒，随便填或留空都会影响打开率，Humanizer 可以顺带处理摘要，把摘要改成“一句疑问句 + 一个利益点”的结构。
正文排版方面，段落与段落之间要有空行，手机端用户最怕看到整屏密密麻麻的字。关键结论可以加粗，但别全篇加粗。文中有数字、人名、公司名这些事实信息，发布前人工核一遍，这一步千万别省，AI 生成内容最怕细节编造。
我不建议完全无人值守。OpenClaw 把草稿推到草稿箱后，人至少要花三分钟看一眼：第一，标题是否吸引人；第二，第一段有没有直接进入主题；第三，结尾有没有给读者一个关注或转发的理由。三分钟换一次发布安全，很划算。
4. 我踩过的坑：OpenClaw + Humanizer 常见问题实录
4.1 WSL2 环境校验失败和安装问题
前文提到了could not safely verify the WSL2 environment，我再展开讲一下。这个问题看起来是环境检测失败，实际原因通常是 WSL 内核版本太旧。Windows 10 和 Windows 11 对 WSL2 的支持程度不一样，旧版本需要手动更新内核。
解决步骤按顺序来：先执行wsl --update，再执行wsl --set-default-version 2，然后查看wsl --status是否显示默认版本为 2。如果机器上跑的是多个发行版，还需要对每个发行版执行wsl --set-version Ubuntu-22.04 2。最后重启 Docker Desktop。如果用的是老项目里跳过检测的开关，我不建议一开始就跳过，因为 WSL2 环境不正常的话，后面 Docker 容器启动大概率还会出更多问题。
4.2 agent failed before reply: session file locked
这个报错原文很长，我记一下关键信息：“agent failed before reply: session file locked (timeout 60000ms)”。刚开始遇到这个报错我以为是文件权限问题，后来排查才发现是并发会话冲突。
OpenClaw 在处理每个会话时，会生成一个 session 文件，同时上一个请求还在运行，锁没释放，新的请求进来就会等待，等超过 60000 毫秒就会报 timeout。解决办法：第一，减少同一时间触发的任务数量，别连续给 OpenClaw 发好几条指令；第二，检查 OpenClaw 配置里有没有并发相关的参数，把同一个 session 的并发关掉；第三，如果确定是残留的 lock 文件导致的问题，可以在停止服务后删掉对应 session 目录下的.lock文件，但删之前备份一下同名的.jsonl文件，避免上下文数据一起丢了。
4.3 飞书/微信消息有去无回
这个问题在社区里被问了无数次，原话通常是“OpenClaw 能发消息微信，但微信发消息没回复”。核心原因就是我只配了“发送消息”，没配“接收消息”。在公众号场景里，如果想让 Agent 读取用户的私信或者群里的指令，必须确保微信公众平台后台的服务器配置是通的，也就是 Token、EncodingAESKey、URL 这三样都要和 OpenClaw 里的配置匹配。
另一个问题是网络回调。微信公众平台要求回调地址能公网访问，本地跑 OpenClaw 的话，回调地址就收不到微信服务器的消息，这也是“能发不能收”的常见原因。我的建议是先别碰微信个人号，用飞书做输入通道，因为飞书支持长连接模式，不需要暴露公网地址，本地跑起来就很稳。等飞书链路完全没问题了，再考虑把公众号草稿箱作为输出通道。
4.4 长文截断和并发超时
“OpenClaw 在飞书输出容易被截断”这个我也遇到过。飞书消息有长度限制，Agent 如果把整篇公众号长文直接往飞书里吐，后半段会被切掉。解决办法很直接：别让 OpenClaw 把长文直接发到对话窗口，而是让它把完整内容写入一个 Markdown 文件或者上传到云文档，在飞书里返回一个链接。
还有一个容易踩的坑是 Humanizer 超时。如果初稿特别长，比如超过 3000 字，Humanizer 的处理时间会明显上升，而 OpenClaw 的回复超时时间可能只有 60 秒，就会导致整体流程失败。我把 Humanizer API 的超时时间调到了 120 秒以上，同时在流水线里限制单次生成的文章初稿不超过 3000 字，超长内容拆成系列文章来写。这样既避免了截断，也避免了超时。
4.5 问题排查速查表
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| 安装时提示 WSL2 environment 校验失败 | WSL 内核版本旧或未启用虚拟机平台 | 更新 WSL，设置默认版本为 2，重启 Docker |
| agent failed before reply: session file locked | 同一会话并发冲突或残留锁文件 | 降低并发、关闭同会话并发、备份后清理 lock |
| 微信能发消息但收不到消息 | 未配置公众号服务器回调或回调地址不可公网访问 | 用飞书长连接做输入，公众号只做草稿输出 |
| 飞书输出内容被截断 | 消息长度超过平台限制 | 让 Agent 写入文件/云文档，返回链接 |
| 长文处理时 agent 超时 | Humanizer 处理时间超过默认超时 | 调大超时时间，限制单篇初稿长度 |
5. 最后说几句大实话
这套 OpenClaw + Humanizer 的方案，我用了几个月后最大的体会是：AI 写作的价值不是替代人，而是帮你把 70% 的重复文字工作先干完，剩下 30% 的决定和把关才是人最该花时间的地方。Humanizer 也不是一个神秘的“去 AI 味工具”，它本质上就是编辑经验的产品化，把“少用首先其次、长句拆短、加入个人视角”这一堆改稿习惯变成了自动化规则。
最后再分享一个小技巧。我每天会让 OpenClaw 从我的收藏夹和固定信息源里挑出三条资料，生成一份“话题毛坯”，然后丢给 Humanizer 处理成更像随手记录的灵感卡片，存进飞书知识库。等到真要写某篇文章时，这些卡片就是最好的素材库，比临时抱佛脚让 AI 硬写一篇要自然得多。这套流程跑顺之后，你不用等灵感，灵感会自己排着队来找你。
