每天花 1 分钟，我的自动化公众号有了 1200 多个粉丝

最近看了一下公众号后台：粉丝已经有 1,215 个，目前每天新增大约 20 个，累计广告收入 315.74 元，还收到了一笔读者赞赏。

这些数字不大。不过，这个号现在每天大概只需要我花 1 分钟，就值得继续做下去了。

我最近留意了一下，每天大约能多 20 个关注。

每天 1 分钟，时间省在哪里？

我自己做公众号，花时间的地方远不止写稿。

找选题、整理素材、写内容、排版，再进入后台发表。单独看，每一步都不复杂，但每天重复一遍，很容易占掉一整段时间。

把其中的重复操作交给自动化之后，日常操作就少了很多。我使用的工具是 Codex + Cloudl：Codex 负责理解任务、编排流程并调用命令，Cloudl 通过浏览器扩展连接已登录的 Chrome，执行具体的网页操作。

我用的是 Cloudl 1.8.10，下面也按这个版本来写配置步骤。它的公众号命令支持创建和查询草稿；最终发表、复杂排版和正文多图插入，还需要在后台完成，或者另外配置浏览器操作。

现在每天花的那 1 分钟，主要用来查看结果、确认是否需要调整。 发现内容有问题，该修改还是要修改，不能为了省时间把明显有错的文章发出去。

当然，我也不是从第一天就只花 1 分钟。前期选方向、搭流程、调试都花了时间，后面遇到问题也得维护。流程跑顺了，每天才轻松下来。

自动化最有用的地方，是让我更容易坚持更新。每天不用再为一遍遍重复的操作，专门空出一段时间。

收益 300 多元，甚至有人赞赏

目前后台显示，累计广告收入是 315.74 元。

这是慢慢攒下来的，昨天的收入只有 1.59 元，离靠公众号养活自己还很远。

但结合每天的投入来看，我觉得这个结果可以接受。账号在持续积累粉丝，也开始产生一点收入，接下来就有理由继续观察和调整。

还有一件挺开心的小事：收到了一笔 1 元的赞赏。

金额很小，截图时也还没有到账，但有人看完文章愿意赞赏，还是让我感到意外。

想到有一位读者愿意用这种方式支持我，就更想认真把内容做下去。

比自动化更重要的，是赛道

如果让我重新开始，我会先花时间想清楚：这个号写给谁看？他们为什么需要这些内容？

自动化能提高发表效率，但文章发出去了，不等于就有人愿意读，更不等于有人愿意关注。

选错方向，生产得越快，需要回头调整的内容可能就越多。

我认为，一个值得持续做的方向，至少要回答三个问题：

• 读者是否有持续需求？ 看完这一篇之后，过几天还会不会需要类似内容？
• 有没有稳定的素材来源？ 能不能持续更新，而不是写完几个选题就没东西可写？
• 读者为什么关注这个号？ 你提供的信息、整理方式或观点，能不能让他期待下一篇？

想清楚这些，我才知道该让自动化帮我做什么。

所以，前期最值得反复打磨的是内容方向。先观察什么内容有人看、有人关注，再把有效的做法固定到流程里。

赛道决定内容有没有人需要，自动化决定你能不能以较低的投入持续提供。

Cloudl 配置流程：从安装到第一篇公众号草稿

整条链路是：Codex → Cloudl 命令 → Cloudl 本地服务 → Browser Bridge 扩展 → 已登录的公众号后台。下面先用终端命令跑通 Cloudl，再把经过验证的步骤交给 Codex 执行。

整理这份教程时，我对照了本机 Cloudl 1.8.10 的帮助信息、安装文档和公众号适配器源码。配图用的是之前实测时留下的截图，版本和环境可能与你的不同。

第一步：准备环境与 CLI 源码

准备 Chrome、Git、Node.js 和 npm。Cloudl 1.8.10 要求 Node.js 至少为 20.18.1。在终端检查：

node --version
npm --version
git --version

每条命令都应输出版本号。缺少哪项，就先安装哪项，再重新打开终端。

Cloudl 随包文档提供的源码地址是：

git clone https://github.com/jyjyxt/cloudownloader.git
cd cloudownloader

安装前先确认拿到的是 CLI 包。 这里容易混淆：下载器网站也用了这个项目名，如果拿到的是 Next.js 网站源码，安装后不会有 Cloudl 命令。可以这样检查：

node -p 'JSON.stringify({name: require("./package.json").name, bin: require("./package.json").bin}, null, 2)'

CLI 包应显示 @jyjyxt/cloudl，并在 bin 中包含 cloudl。如果仓库使用子目录布局，进入 cloudl/ 后再检查；如果没有该目录，也没有 bin.cloudl，需要先取得包含 CLI 的源码版本。

我本机的 CLI 源码和命令可以正常使用，不过还没确认这个仓库目前是否公开提供同一版本。如果下载后找不到 CLI 包，先检查源码版本，拿到正确的包再继续安装。

第二步：安装并关联 cloudl 命令

在刚刚确认过的 CLI 包目录执行：

npm install
npm link
cloudl --version
cloudl --help

源码安装会通过 prepare 脚本构建 CLI，npm link 会把命令关联到当前 Node.js 环境。看到版本号和帮助信息，说明命令安装成功。

保留这个源码目录。移动目录或切换 Node.js 环境后，可能需要重新执行 npm link。

第三步：安装 Browser Bridge 扩展

随包文档提供两种安装方式。如果 Cloudl Releases 中提供 cloudl-extension-v{version}.zip，可以下载并解压；没有可用安装包时，可以从已经取得的 CLI 源码构建：

npm --prefix extension install
npm --prefix extension run build

然后在准备运营公众号的 Chrome 用户配置中操作：

1. 打开 chrome://extensions。
2. 开启右上角的“开发者模式”。
3. 点击“加载已解压的扩展程序”。
4. 选择包含 manifest.json 的目录。
5. 确认 Browser Bridge 已启用。

可以参考上图找到扩展管理入口。使用源码构建时，要加载 extension/，不要选 extension/dist/。加载完成后，也不要删除或移动这个目录。

第四步：检查浏览器连接

保持 Chrome 打开，在终端执行：

cloudl doctor

检查结果中，Daemon 应处于运行状态，Extension 应显示 connected，并能看到已连接的 profile。你的版本和 profile ID 可以与截图不同。

本地服务会按需启动。遇到连接问题，可以执行：

cloudl daemon status
cloudl daemon restart
cloudl doctor

doctor 通过说明浏览器连接正常，公众号登录状态需要下一步单独确认。

第五步：登录公众号，绑定浏览器配置

在安装了扩展的同一个 Chrome 用户配置中，打开 https://mp.weixin.qq.com/，完成登录，确认后台显示的是目标公众号。

然后查看 Cloudl 已连接的浏览器配置：

cloudl profile list

把输出中的目标 ID 替换到下面的命令，为它起一个容易识别的别名：

cloudl profile rename YOUR_CONTEXT_ID wechat-main
cloudl profile use wechat-main
cloudl --profile wechat-main weixin drafts --limit 5 -f json

最后一条命令用于读取草稿箱。新账号没有草稿也正常；重点是确认能进入正确账号，而不是停在登录页。

浏览器 profile 决定使用哪一份登录状态。重命名 profile 不会自动切换公众号，仍要核对浏览器里实际登录的账号。

第六步：创建第一篇草稿

先用短正文跑通流程。将封面路径换成电脑上真实存在的图片，标题、作者和摘要也换成自己的内容：

cloudl --profile wechat-main weixin create-draft \
  '这是第一篇测试正文。先确认标题、正文和封面都能正确保存，再接入正式内容。' \
  --title '公众号自动化流程测试' \
  --author '你的署名' \
  --summary '验证 Cloudl 创建公众号草稿的完整流程。' \
  --cover-image '/absolute/path/to/cover.png' \
  -f json

这条命令会实际创建草稿。标题最长 64 字，作者名最长 8 字。封面参数接收本地路径，适配器会先把图片上传到正文，再设为封面，所以需要检查正文中图片的位置。

当前版本按纯文本插入正文。 直接传入 Markdown 或 HTML，不会自动变成排版后的文章；本篇文章里的 Markdown 图片链接，也不会因此自动上传到公众号。

如果需要精细排版和多张正文配图，先创建草稿，再在编辑器中补齐；需要把这部分也自动化时，应另行配置浏览器操作并验证结果。

保存后读取草稿箱：

cloudl --profile wechat-main weixin drafts --limit 5 -f json

打开对应草稿，检查标题、段落、封面和摘要。命令返回 draft saved 表示适配器检测到了保存成功；如果返回 save attempted, check browser to confirm，就需要到后台确认，避免重复创建。

第七步：按需设置原创与赞赏

对于符合原创声明条件、且后台已具备对应功能的文章，可以在创建草稿时追加这些参数：

--original-declaration '你的原创署名'
--reward true
--reward-account '后台已有的赞赏账户名称'

赞赏账户需要与后台可选账户匹配。参数本身不会开通账号权限，自动生成的文章也不应仅因为“自动化”就统一勾选原创。创建完成后，要到编辑器确认设置是否生效。

第八步：完成发表，并把流程固定下来

本机版本的 cloudl weixin 没有直接发表命令。完成上面的操作后，文章仍在草稿箱。

第一次运行时，在公众号后台预览草稿，补齐排版和图片，检查手机端效果，再通过后台提供的发表流程完成操作。是否还需要扫码或其他确认，以实际页面为准。

如果要让 Codex 继续通过 Cloudl 操作最终发表，需要单独设计这段浏览器流程：选择目标草稿、核对账号与标题、完成发表操作、检查结果并记录文章链接。遇到需要人工扫码的页面，就应明确返回待处理状态。

我建议把每天的任务信息固定成下面这些字段：

先手动跑通一篇，再把同样的步骤交给 Codex，让它调用 Cloudl 执行。安装工具不会自动建立定时任务；还需要在任务调度器中配置执行时间、工作目录、命令路径和日志，并确保运行时电脑唤醒、Chrome 打开、公众号登录有效。

可以把下面这段作为交给 Codex 的任务说明模板：

读取今天的待处理文章，使用 wechat-main 浏览器配置。
确认目标公众号、正文和图片文件；处理前检查同一任务是否已有草稿。
调用 Cloudl 创建草稿，随后读取草稿箱并核对结果。
记录状态和执行日志，保存成功后标记为“待发表”。
如果保存结果不确定，检查后台，不要直接重复创建。
最终发表按另行配置的流程执行，只有确认发表成功后才标记“已发表”。
遇到登录失效、扫码或页面异常时，报告具体需要处理的步骤。

对我来说，每天能省下时间，靠的是把素材准备、排版和发表这些步骤提前理顺。第一次配置时多花些工夫，后面就少一些重复操作。

一个号跑通之后，还可以考虑矩阵

等这个号的定位、内容和发表流程都稳定下来，我也想试着把这套流程用到其他账号上。

例如，围绕不同的细分人群，分别提供他们需要的内容。素材整理、排版、发表这些步骤可以复用，但选题和表达要跟着读者变化。

配置上，可以为不同账号分别创建 Chrome 用户配置，每份配置安装扩展、登录对应公众号，然后用 cloudl profile list 获取各自 ID，分别起名为 wechat-main、wechat-second。

任务中显式指定账号，例如读取第二个账号的草稿：

cloudl --profile wechat-second weixin drafts --limit 5 -f json

后续创建草稿也使用对应的 --profile。每个账号分别保存选题、素材、任务状态和日志，先逐个验证登录与草稿创建，再扩大任务数量。

不过，多做几个号，我要审核的内容和维护的流程也会跟着增加。每个号能不能做起来、能有多少收益，还得分别去试。

我更倾向于先跑通一个，再逐步扩展。确认每个账号都有值得关注的内容，复用流程才有意义。

常见问题与维护

源码安装的 CLI，可以在对应源码目录更新：

git pull --ff-only
npm install
cloudl --version
cloudl doctor

手动加载的扩展需要单独更新。源码构建时，重新运行扩展安装与构建命令，再到 chrome://extensions 点击扩展的重新加载。

眼下，1,215 个粉丝、300 多元累计广告收入，加上一笔小小的赞赏，已经给了我一些继续做的动力。

接下来，我想把更多精力放在赛道和选题上。重复操作交给流程，自己多想一想：下一篇文章，读者到底为什么要看？