我把 OpenClaw 接进了自己的写作流水线

这篇文章算是第一次正式试跑。它讲的是这套流程怎么接起来，而它自己，也走了一遍这条流程。

一开始不是为了多装一个机器人

我接 OpenClaw，不是为了再弄一个聊天机器人。

真正想解决的是另一个问题：对话入口和业务系统要分开。

之前做自动化项目，很容易图省事。一个脚本直接读另一个项目的文件，一个服务直接执行另一个目录里的命令。刚开始确实快，能跑起来就行。

但跑一段时间后，麻烦就出来了。

包括不限于到底谁负责对话？谁负责数据？模型配置放在哪里？数据库状态归哪个项目管？任务失败了，是查 OpenClaw，还是查业务系统？

这些问题一多，项目就会变成一团线。能跑，但不好改，也不好查。

所以这次我没有让两个项目直接混在一起，而是给它们划了边界。

OpenClaw 负责对话入口、微信接入和 skills。
业务系统负责采集数据、整理素材、生成初稿，以及维护自己的状态。

两边不互相翻目录，不共享内部配置，也不直接操作对方的文件。

要交互，就走接口。

OpenClaw 只做它该做的事

这次 OpenClaw 跑在 Mac mini 上，并且用了单独的运行用户。这么做不是为了折腾，而是为了隔离。

OpenClaw 有自己的模型配置、微信状态、会话记录和 skill 文件。这些东西就留在它自己的环境里。

业务系统不直接读这些文件，也不需要知道它里面怎么存。

反过来，OpenClaw 也不直接读业务系统的数据库。

它要查业务状态，就问业务系统开放出来的接口。
业务系统要用模型润色，就走 OpenClaw 外面包的一层 Bridge。

这次改造的核心就一句话：

OpenClaw 不直接干业务，业务系统也不依赖 OpenClaw 的内部文件。

两条调用链路

这次接了两条链路。

第一条是 OpenClaw 调业务系统。

比如我在 OpenClaw 里问：

关注提醒模块现在有哪些事项？

它不会自己编答案，也不会去数据库里乱翻，而是通过一个轻量接口去问业务系统。

业务系统查完后，把结果返回。OpenClaw 再把结果整理成更容易看的文字。

第二条是业务系统调 OpenClaw。

我的写作系统不需要 OpenClaw 的所有能力。它现在只需要一个很具体的能力：把已有初稿润色得更像人写的。

所以我在 OpenClaw 外面加了一层 Bridge。业务系统把初稿交给 Bridge，Bridge 再调用 OpenClaw 的 humanizer skill，最后把润色后的正文返回。

这样关系就比较清楚。

OpenClaw 提供模型和 skill。
业务系统提供数据、任务和流程。
两边只通过接口说话。

这里有个重点：我没有让模型直接从零写内容。

因为业务系统里本来就有数据库，有结构化素材，有扫描结果，也有已经确认过的事件和案例证据。

这些东西是事实基础，不能交给模型凭空发挥。

现在的顺序是：

先由脚本从数据库里整理素材；
再由程序生成一版初稿；
最后只把表达润色交给 OpenClaw。

也就是：

事实由数据库和脚本控制，表达交给模型处理。

这比直接让模型写一篇完整内容稳得多。

直接让模型写，很容易出问题。它可能补一个不存在的案例，可能把不确定的信息写得很肯定，也可能为了让文章顺一点，自动加一些听起来合理、但我没有确认过的内容。

所以在这套流程里，模型不是作者。更像编辑。

它可以改语气、调结构、删废话，但不能决定事实。

现在的写作流程怎么跑

现在每次生成内容，系统会先整理一套素材基础。

里面大概有几类东西：

结构化素材，比如当天的案例、统计和关键事实。
写作边界，比如这篇内容讲什么，哪些内容不能写。
初稿和润色稿，用来保留修改前后的版本。
质量检查和人工复核清单，用来提醒我最后看哪些地方。

这不是自动发布。

我现在对它的定位很明确：自动生成一版可复核稿。

最后还是要人工检查。

重点看几件事：

案例能不能公开讲。
有没有暴露太细的内部信息。
有没有把路径、接口、配置写出去。
有没有把不确定的内容说得太死。
有没有写得太像机器整理出来的材料。

AI 可以省掉大量整理和润色时间，但最后那一眼不能省。

润色服务不能变成单点故障

接入 OpenClaw 之后，写作流程多了一步润色。

但这一步不能影响主流程。

如果 OpenClaw 临时不可用，系统不会直接中断，而是继续使用原始初稿。

这个设计对自动化任务很重要。

因为模型润色只是加分项，不应该变成整个流程的单点故障。

有 OpenClaw，文本更顺。
没有 OpenClaw，内容生成也要继续跑。

不过整个流程也会存在一些坑

第一个坑：模型会把聊天话术写进正文，模型有时候会返回这种话：

我先分析一下原文的问题。
下面是润色后的版本。
我会从结构、语气和表达上优化。

在聊天里，这些话没问题。

但如果它们被直接写进正文，就是事故。

所以我又加了一层清洗逻辑。只要返回内容里出现明显的过程说明，就把它截掉，只保留正式正文。

现在有一个硬要求：

最终正文第一行必须是标题，不能是模型解释。

不过这也让我重新想了想发文这件事，把这套流程跑通以后，我反而对自动化发文更加谨慎。

这类文章适合什么？

适合教程。
适合流程复盘。
适合信息整理。
适合把一堆零散步骤整理成一篇能看的说明。

比如这篇文章，本质上就是一次技术流程复盘。它有明确的对象，有清楚的边界，也有真实的改造过程。用系统先整理，再让模型润色，问题不大。

但如果是更偏观点、更偏情绪、更偏个人判断的文章，就不能这么处理。

模型可以把句子改顺，可以把结构排整齐，也可以帮你删掉一些废话。
但它很难替你真正想明白一件事。

它不知道你为什么烦。
不知道你哪里后悔。
不知道你踩坑时真正想骂什么。
也不知道你做完一件事以后，心里那个“不太对劲”的感觉来自哪里。

这些东西才是文章里最像人的部分。

所以我现在对这套写作流水线的判断是：

它适合生产“有用的内容”，但不适合直接生产“有人的内容”。

教程可以自动化。
资料整理可以自动化。
技术复盘可以半自动化。
但真正有记忆点的文章，还是要有人下判断。

哪怕那句话不那么工整，也比一整篇都很顺、但读完没感觉要好。

后面我会继续用这套流程处理信息整理和初稿润色，但不会把它当成完整作者。

它能帮我把材料收拾干净。
但文章里真正要说什么，还是得我自己决定。