用 WorkBuddy 定时任务实现论坛每日自动发帖：配置、调度与避坑

pbai

免费乐捐，感谢支持

用 WorkBuddy 定时任务实现论坛每日自动发帖：配置、调度与避坑

阅读说明
1. 适用版本：WorkBuddy 桌面客户端（「自动化」定时任务功能）；目标论坛为 Discuz! X 系列（X2 / X3 / X3.4 / X3.5 同理）
2. 支持数据库：本文不涉及数据库
3. 操作系统与环境要求：Windows / macOS 桌面客户端；任务触发时客户端需保持在线；需要一点 Python 常识（只用来排查问题，不需要你写代码）
4. 难度系数：★★☆☆☆
5. 其它阅读说明：本文讲的是「怎么用 WorkBuddy 把每日发帖这件事跑起来」，不教从零手写 HTTP 请求。发帖这个动作由工作空间里的固定脚本完成，WorkBuddy 负责写稿、调度和复核。看着像多绕了一层，但这一层正是稳定性的来源

一、前期准备：先手动跑通，再谈自动化

一句话原则：自动化只放大已经跑顺的流程。手动都跑不通的事，定时执行只会让你每天收到同一条失败记录。

1.1 先定三件事

要定的事	说明
发什么	内容从哪来——本地 Markdown 队列、数据库，还是让 Agent 现写现发
发到哪	论坛版块用 fid 标识，主题分类用 typeid 标识，两个数字都要提前确认
多久一次	论坛后台通常有「两次发帖间隔」限制，常见 15 秒到 10 分钟。一天一篇是最不容易触发风控的节奏

1.2 账号与凭据

• 不要用管理员账号跑自动化。脚本出问题时，管理员号能造成的破坏大得多。
  
• 注册一个专用发帖号，和日常号分开，出问题影响面小，统计也方便。
  
• 口令不要写进提示词。提示词会被保存下来、每次触发都作为执行指令使用；凭据应该单独放一个文件，提示词里只写「口令去哪个文件取」。
  

1.3 手动跑通一次（这一步不能省）

先在对话里手动下发一次任务，例如：

2. 读工作空间里的发帖配置，把 posts/ 队列里序号最小的那篇发到论坛，
3. 发完把结果写进 publish_log.json，并告诉我帖子链接

复制代码

确认三件事：能登录、能发出、产物落在你预期的路径。然后再用同样的输入复跑一次，确认结果路径、权限、格式都稳定——这时才轮到配置定时任务。

二、环境搭建

2.1 客户端与工作空间

WorkBuddy 桌面客户端登录后即可用，不需要额外装服务。真正要准备的是一个专用工作空间——在客户端里新建一个任务时指定工作目录，把这个流程用到的所有东西都放在里面，不要和别的项目混在一起。

2.2 工作空间里该放什么

只放三样：

目录 / 文件	作用
posts/	待发内容队列，按 01_xxx.md、02_xxx.md 这样排好序
发帖器（一个固定脚本）	真正执行「登录 → 取表单 → 提交 → 复核」的确定性代码
config.json + 凭据文件	站点地址、发帖账号、口令文件路径、默认版块

关键点：发帖动作必须固化成一个脚本，而不是让 Agent 每次现编。原因见第四节。

2.3 两个必须检查的开关

• 网络权限 / 沙箱。★这是第一大坑：客户端默认在受限沙箱里运行命令，网络请求会被静默拦截——脚本不报错、退出码为 0，但一个字也没发出去，日志文件也不生成。现象是「任务跑完了，什么都没发生」。遇到这种情况，检查该任务是否被允许访问外网，并在执行需要联网的命令时显式申请放行。
  
• 防休眠。定时任务要求客户端在线且系统不休眠。挂后台任务前，去「设置 → 系统设置」里把防休眠打开（不同版本入口略有差异）。电脑该休息还是要休息，别长期开着不管；如果只是白天办公时段发文，就设成工作时段触发。
  

2.4 把流程封装成技能（可选，但强烈建议）

跑顺之后，把「本项目的发帖流程」写成一个技能（Skill）放进工作空间，记录：目标版块、分类、白名单字段、常见报错对照。这样以后每次触发，Agent 不用重新摸索，出错也能自己按对照表排。

三、登录与会话保持

3.1 谁在管会话

这是最容易误解的一点：会话保持不归 WorkBuddy 管，也不该由它临时处理。

HTTP 是无状态的——登录成功后，服务端并不知道下一个请求是谁发的，除非带上登录时下发的 Cookie。这件事由工作空间里那个发帖器用 Cookie 会话容器（CookieJar）完成：登录一次，后续所有请求自动带上 Cookie，直到这次运行结束。

WorkBuddy 的角色是：在设定的时间点，按你的提示词把这个流程跑一遍。

3.2 你需要做的只有两件事

• 在 config.json 里写好站点地址、发帖账号、口令文件的路径。
  
• 在凭据文件里写好口令，并确保这个文件不进版本库。
  

3.3 三个坑

现象	原因	处理
登录提示成功，下一步又变游客	请求没带 Cookie	检查发帖器是否每次都复用了同一个会话容器
提交时提示「来路不正确」	表单校验令牌（formhash）过期或跨会话复用	每次运行都重新取一次，绝不跨运行缓存
换个站点就登录失败	老论坛页面是 GBK 编码	解码时 UTF-8 失败要能退到 GBK

四、发帖「接口」到底是什么

4.1 先说真相

Discuz 论坛没有开放的发帖 API。所谓「调用发帖接口」，本质是模拟浏览器提交发帖表单——表单地址形如：

2. forum.php?mod=post&action=newthread&fid=<版块号>&topicsubmit=yes

复制代码

这个地址不用你去记。它由发帖器在运行时从发帖页面自己抓取，因为里面的校验令牌每次都不一样。

4.2 两条路线，别选错

	路线 A：让 Agent 每次现编	路线 B：调固定脚本（推荐）
做法	每次触发时，由 Agent 自己拼请求发帖	请求逻辑写死在脚本里，Agent 只负责调用和汇报
确定性	低，同样的输入可能走不同的实现	高，同样的输入必然同样的动作
出错影响	可能多带字段、误改置顶精华等越权选项	白名单过滤，只提交该提交的字段
可审计	难，每次行为不一样	易，脚本是唯一事实来源

选 B 的理由很简单：发帖是对外操作，涉及一个真实账号和一个公开可见的帖子。把可变量压到最低，是这类任务唯一正确的设计取向。Agent 应该被授权去写、去判断、去复核，但不该被授权即兴决定「怎么发」。

4.3 于是分工是这样

• Agent 干：按选题写正文、检查字数与结构、转换格式、调用脚本、复核发布结果、写日志。
  
• 脚本干：登录、取表单、白名单过滤、提交、拿回帖子编号。
  
• 你干：定选题、复核草稿、配置定时规则、处理异常。
  

五、标题与正文的构造

5.1 内容队列

把待发文章放在 posts/ 下，文件名带序号。每次触发只取序号最小的那一篇，发完就归档到 published/。队列化是防重复的第一道闸门：任务跑两次也不会发重，因为文件已经不在队列里了。

5.2 标题：前缀就是路由

如果同时运营两个版块，用一个约定解决分流——看标题前缀决定发到哪：

标题前缀	目标版块	主题分类
产品线 A 相关	版块 X（fid=93）	对应的专属分类
其余	版块 Y（fid=33）	「学习笔记」一类的通用分类

这个约定写在提示词里，Agent 每次自己判断，不需要你手动指定。

标题还有一条硬约束：Discuz 默认限 80 字节，中文按实际字节算，所以中文标题控制在 40 个字以内较稳。脚本里加一道长度检查，超了截断并告警，别让提交直接失败。

5.3 正文：Markdown 进，BBCode 出

你只管写 Markdown，转换由脚本负责。转换的关键是代码块要"先寄存、后还原"：代码块里常含 Markdown 语法字符，如果先做行级替换再处理代码块，代码会被改得面目全非。

5.4 三个坑

• ★★ 正文里绝对不能出现字面的论坛标签。写「如何发帖」「如何排版」这类教程时最容易踩：你在正文里举例说明 code、b、size 这些标签长什么样，如果直接写成方括号形式，发布后会被论坛当成真标签解析，整段排版立刻乱掉。
  

   规避办法：需要举例时用文字描述（「形如 方括号 + 标签名」），或者用代码块包住，绝不让它裸露在正文里。发完之后再回读一次正文，确认标签个数是成对的、没有奇怪的加粗和字号跳变。

• 标题里不要放标签，会被转义成字面量。
  
• 正文文件保存为 UTF-8 无 BOM，否则中文可能变乱码。
  

5.5 流程纪律：写稿和发布分开

不要让「写稿」和「发布」在一次触发里自动连着做。 正确姿势是两步：

• 第一步（Agent 自己跑）：按选题写草稿 → 落盘到 drafts/。
  
• 第二步（你确认）：你回复「复核」或「通过」，草稿才移入 posts/ 队列。
  

多这一步的代价是几十秒，省下的代价是不会半夜自动发出去一篇你自己都没看过的文章。

六、发帖参数与版块设置

6.1 fid 和 typeid 怎么定

• fid（版块号）：打开该版块首页，地址栏里 forum-<数字>-1.html，那个数字就是。
  
• typeid（主题分类）：必须从发帖页里读出来，不能猜。 发帖页有一个分类下拉框，脚本把它读成「名称 → 编号」的对照表，然后按名称取值。
  

按名称取值的好处：换一个论坛、或者版主改了分类名，脚本不会错，因为它每次都是现读的。

6.2 白名单：只提交该提交的字段

这是整套流程里最重要的一条纪律。Discuz 的发帖表单有几十个字段，其中大部分是「附加选项」：标签、签名、阅读权限、售价、回复可见、置顶、精华、解析开关……

这些都不要提交。它们属于版主和管理员的权限范畴，脚本误改等于越权。

做法是白名单：只保留 formhash、fid、subject、typeid、message、提交标志这几项，其余全部丢弃。Discuz 对「没提交的复选框和下拉框」的处理是「保持不变」，所以只发这几项是安全的。

实测效果：发帖页镜像出 18 个字段，白名单过滤后只剩 6 个。这 6 个字段的名字，应该出现在每次运行的日志里。

6.3 两条内容纪律

纪律	原因
同一版块连续不超过 3 篇就换版块	避免单一版块刷屏，维护体验
选题前先查已有内容的目录帖	防止同一个主题写第二遍；确实要重写，就定位成「进阶篇 / 实机验证篇」并明确区分

七、把它做成定时任务

7.1 操作路径

打开 WorkBuddy 左侧的「自动化」页面 → 右上角「添加」→ 填写配置 → 保存。页面上可以查看已安排的任务和历史执行记录。

7.2 六个配置项

配置项	怎么填
名称	一眼能认出来的名字，例如「每日技术文章发布」
工作空间	指向第二节准备的那个专用目录，不要用默认分配的新目录——否则脚本、队列、配置全都不在里面
提示词	任务目标 + 输出要求 + 约束条件（模板见 7.3）
模型与技能	需要长文写作就选能力强的模型；把项目技能挂上
定时规则	设置频率和生效日期区间；留空生效日期表示长期
推送	开启后任务完成会把结果推到小程序，方便第一时间查看

7.3 提示词模板（可直接抄）

2. 读取工作空间里的发帖配置和 posts/ 队列。
3. 把队列中序号最小的一篇文章发到论坛：
4. - 标题前缀含「产品线A」的发到 fid=93，分类名「PBIDEA」；
5.   其余发到 fid=33，分类名「学习笔记」。
6. - 只提交白名单字段，不要碰置顶、精华、阅读权限、售价等任何附加选项。
7. - 正文如果是 .md，先转成论坛格式再发。
8. 发完后：
9. 1. 必须拿到帖子编号（tid）才算成功；拿不到就停下，不要重试。
10. 2. 回读正文，确认没有字面标签残留、标签成对。
11. 3. 把结果（时间、版块、标题、tid、链接、失败原因）追加到 publish_log.json。
12. 4. 成功的文章从队列移到 published/。
13. 如果提示需要审核、或遇到 429/503，立刻停止并告诉我，不要自动重试。

复制代码

最后一行是这份提示词里最值钱的一句。

7.4 更省事的做法

不想填表单，直接在对话里说：

2. 把刚才这套发帖流程设为自动化，每天早上 9:00 执行，结果推给我

复制代码

客户端会把当前这套流程保存成定时任务。

7.5 ★★ 执行机制的三个关键事实

这三条不搞清楚，任务一定会「莫名其妙地不工作」：

• 只在会话空闲时触发。 如果触发的那一刻系统正在处理别的请求，执行会顺延到当前操作完成后。所以「9:00 发的」实际可能是 9:07 发的，不是故障。
  
• 触发时间有随机偏移（Jitter）。 循环任务最多延迟周期时长的 10%（上限 15 分钟）；整点、半点的任务最多提前 90 秒。这是为了错开大量任务同时执行。如果你的内容对时间很敏感（比如必须在开盘前发出），把触发时间往前挪 15 分钟。
  
• ★「定时任务」和「自动化」是两套东西，别混。 用对话方式说「每天几点做什么」创建的任务（底层是一套即用即弃的调度），循环最长只持续 3 天，过期前会最后触发一次，之后需要重新创建；而「自动化」页面里配置的任务是长期保存的配置。
  

   这里踩坑的人最多：用对话方式设了个「每天发一篇」，第四天开始就再没动静，自己完全没察觉——因为前三天是成功的。
   上线后第一件事，就是确认自己的任务属于哪一套。如果走的是短期那一套，要么安排定期重建，要么直接改用自动化页面。

7.6 手动补跑

漏发了不用改配置，直接在对话里说一句：

2. 手动跑一次每日发布任务

复制代码

发帖器本身是幂等的（队列 + 日志），补跑不会重复发。

八、常见错误与调试

按「现象 → 原因 → 处理」排表，遇到问题直接对号入座。

现象	可能原因	处理办法
★ 任务跑完了，什么都没发生	沙箱拦网，网络请求被静默丢弃	给该任务放行网络访问；判断成功要看产物文件，别信退出码
到了点没触发	客户端没在线／电脑休眠／触发时正忙被顺延	检查客户端状态与防休眠设置；看历史执行记录确认是否顺延
前几天正常，第 4 天起彻底没动静	用了只持续 3 天的短期定时任务	见 7.5 第 3 条，改用自动化页面或安排重建
提示 429 / 503	触发限流	不要立即重试。等几十分钟再试，或今日放弃并告警
帖子进了审核队列	论坛对新号或含链接内容开了审核	脚本识别到「审核／待审」文案就停下，等人工在后台放行。绝不能重试
重复发了两篇	提交成功但判定没拿到 tid，脚本又试了一次	成功判定以 tid 为准；重试前先比对队列与日志
中文变乱码	表单没按 UTF-8 编码，或正文文件带了 BOM	提交数据按 UTF-8 编码；正文存成 UTF-8 无 BOM
页面回读全是乱码字节	服务端返回了 gzip 压缩	请求头里声明不要压缩
发完回读帖子页看不到内容	帖子页有反爬，返回的是混淆脚本	这是预期行为，不是失败。改查版块列表页，看最新主题里有没有你的标题和作者
正文排版乱了、莫名加粗	正文里有字面论坛标签，被当真标签解析	见 5.4 第 1 条；回读正文确认标签成对
拿不到帖子编号	页面结构变了，或被重定向	把当次响应存成 HTML 用浏览器打开看，错误通常一眼可见

三个通用调试手法

• 看产物，不看回显。这类任务最反直觉的地方是：命令可能静默失败而退出码为 0。判断依据永远是「日志文件和产物有没有真的更新」。
  
• 降级法。把流程拆成「只登录 → 只取表单 → 只组装 → 再提交」，一步一步确认，别一次性跑全流程。
  
• 对照浏览器。手工能发成功、脚本发不成功时，把浏览器开发者工具 Network 面板里的表单数据和脚本提交的数据逐项对比，差异点就是问题点。
  

九、上线前检查清单

正式开启定时之前，逐条打勾：

• [ ] 手动跑通过至少一次，并且用相同输入复跑过一次结果一致
  
• [ ] 工作空间指向正确，posts/、配置、凭据都在里面
  
• [ ] 网络权限已放行，防休眠已按需设置
  
• [ ] 提示词里写明了「失败不重试」「需审核就停下」
  
• [ ] 确认任务属于长期生效的那一套，或被安排了重建
  
• [ ] 口令只存在于凭据文件中，提示词和日志里都没有明文
  
• [ ] 第一周每次执行后都人工看一眼日志
  

安全与合规红线

• 口令绝不硬编码，凭据文件不进版本库。
  
• 不用管理员账号跑自动化。
  
• 遵守论坛版规。多数论坛对自动化发帖有明确规定，动手前先看版规；不做刷屏、灌水、批量搬运。本文讨论的是「把自己创作的内容按计划发布」这一正当用途。
  
• 只提交白名单字段，不碰置顶、精华、阅读权限、售价等任何附加选项——那是越权。
  
• 控频，宁慢勿快，一天一篇足够。
  
• 失败就停，不要无人值守地反复重试。重试是重复发帖的头号元凶。
  
• 敏感信息不落盘，日志里不打印口令与 Cookie 全文。
  

十、本文的验证情况

环节	验证情况
专用工作空间 + 队列化内容（posts/ → published/）	已实机运行
配置与凭据分离（提示词只写「去哪取口令」）	已实机运行
登录与会话保持（Cookie 落盘 9 条）	已实测
发帖表单镜像（formhash 等 18 个字段）	已实测
主题分类按名称读取（读出 7 个分类）	已实测
白名单过滤（18 个字段 → 最终仅 6 个外发）	已实测
提交成功判定（以 tid 为准）与发后复核	已实测
帖子页反爬时改用版块列表兜底核验	已实测
每日定时触发 + 失败不重试 + 日志留痕	已在真实站点连续运行验证
沙箱拦网导致静默无输出	已踩中并确认现象

未实测部分如实说明：客户端「自动化」页面各版本的具体界面文案、防休眠入口位置可能随版本变化，请以你本机实际界面为准；不同论坛的反爬策略差异较大，列表兜底方案未必对所有站点有效。

十一、结语

整套东西拆开，其实只有四件事：

把流程固化成脚本 → 让 Agent 只做调度与复核 → 把内容做成队列 → 用自动化页面按时触发。

真正容易出问题的从来不是「怎么发」，而是那三个不会报错的地方：沙箱拦网静默失败、任务三天后悄悄过期、失败之后自动重试。把这三处管住，剩下的就是纯体力活了。

第一次跑成功只能说明流程有希望。真正可用的标准是：无人值守时仍能稳定产出，失败后能追踪原因、找回源文件、重新执行。