我一开始只是想解决一个很具体的问题：文章已经在 WordPress 保存了，博客页面却还停在旧版本。过去每次改完内容，我都要再去找到构建入口、手动触发任务，然后盯着构建和部署状态。步骤不算复杂，但它把“写完文章”和“让读者看到更新”拆成了两件事，也很容易漏掉后半段。
后来我把这条链路逐步扩展成一套个人内容工作流：在微信里交代写作或修改需求，由 ClawBot 通过受控 API 操作 WordPress；我检查草稿并明确发布后，服务器再自动构建 Astro 静态博客。写作入口变轻了，内容审核和部署状态仍然清楚可查。
先看清楚这条链路
这条工作流可以分成内容管理和网站交付两段。上半段解决“内容怎么进入 WordPress、谁来决定发布”；下半段解决“公开内容变化后，服务器如何构建并把新页面交给读者”。把两个问题拆开，才不会把 API 请求成功误认为网站已经更新。
图 1：微信写作经受控 API 进入 WordPress，人工发布后触发独立的构建与部署链路。按本项目实际工作流整理的原创示意图。
图里最重要的边界是：ClawBot 负责内容操作，WordPress 是内容源，VPS Runner 负责执行构建，静态部署平台负责交付页面。部署状态通过只读查询逐段回看，不让“任务已接受”替代“页面已经更新”的判断。
微信是入口，WordPress 仍是内容源
接入微信 ClawBot 后，我可以直接在聊天里提出写作、修改或查询需求。ClawBot 再调用博客工具，由 WordPress Site Manager 的 AI Content API 执行相应操作。这样微信只是自然语言入口，文章仍保存在 WordPress；Astro 生成的是面向读者的静态页面，不需要再维护第二份正文。
接口按能力开放具体动作，而不是把 WordPress 管理员账号交给 AI。它可以读取有权限的文章、创建和修改草稿，并提供受控的发布流程；没有文章删除、页面写入或相册写入能力。更新时带上文章的 modifiedAt，服务端会检查版本，避免用旧内容覆盖别人刚做的修改。幂等键则用来处理网络重试，避免同一请求重复执行。
发布的最后决定仍由我做。草稿准备好后，我先检查结构、事实和表达，再走明确的确认步骤。接口返回“可以发布”只代表满足受控流程条件，不代表文章已经公开。
服务器上分别跑着什么
这套系统不是把所有服务塞进同一台机器。WordPress 主机负责内容管理与 AI Content API；一台固定出口的 VPS 运行 GitHub Actions 自托管 Runner；构建完成后，公开部署仓库和静态托管平台负责提供博客页面。源码仓库保存站点代码，公开部署侧只接收构建产物，凭据与权限也按这条边界分开。
使用 GitHub 托管 Runner 时，我遇到过一个很具体的网络问题：从 GitHub 托管环境请求 WordPress REST API 会被主机的 Bot Verification 拦截，返回 HTTP 403。构建代码本身没有问题，失败发生在 Runner 到内容源的访问路径上。后来我把 Runner 放到有固定出口的 VPS，并在主机侧允许这个出口，构建就能稳定完成。这里的关键不是简单“换一台服务器”，而是让请求从可识别、可控制的网络出口进入 WordPress。
微信链路也经历过类似的分层排查。最初 Gateway 能收到微信消息，并不等于消息已经交给 Agent、模型完成回复并成功发回微信。我把渠道接收、Agent 调度、模型响应和消息回传分开检查，才不会把“服务进程在运行”误当成“端到端功能可用”。
一次发布怎样变成一次部署
WordPress 中的公开内容发生变化后，Site Manager 会记录内容修订，并在大约一分钟的防抖窗口内合并连续修改、过滤重复修订，再通过 workflow_dispatch 提交构建任务。构建进入队列后，VPS Runner 同步 WordPress 内容与媒体，运行 Astro 生成静态页面，再运行 Pagefind 建立站内搜索索引，最后把构建产物送到公开部署端。
防抖窗口解决的是“连续保存导致重复构建”，队列解决的是“前一轮构建还没结束时又来了新更新”。这两者不一样：只做防抖，稍晚到达的修改仍可能撞上正在运行的任务；如果新任务直接取消旧任务，也可能让有效构建中断。因此我保留修订去重，并让构建排队执行，让每次公开内容变化最终都能被纳入构建。
状态要按阶段确认
发布之后，我不会只看一个绿色的“成功”。系统分别跟踪 WordPress 内容变更、构建任务派发、GitHub Actions 构建、部署平台更新和公开页面可达性。派发成功只表示构建请求被接收；构建成功也不能单独证明部署已完成；页面可达则还需要结合对应的部署版本判断。
部署状态接口是只读的：它汇总各阶段结果，不负责重新触发或重试任务。把状态查询和触发动作分开，既能让 ClawBot 回答“文章现在到哪一步”，也避免一次查询意外启动新的构建。
自动化的边界仍然由人决定
这次升级最有价值的变化，不只是少点一次“构建”。微信让内容操作更顺手，受控 API 把权限限制在具体内容动作里，WordPress 保持为唯一内容源，服务器负责把公开内容变成可访问的静态站点，而人工审核保留了发布决定。
我现在把这条链路看成几个有明确责任的阶段：消息进入、草稿变更、人工发布、构建执行、静态部署、状态回读。每一步都能单独检查，也能知道失败发生在哪里。自动化因此不再是一个黑盒按钮，而是一套能追踪、能恢复、并且不会替我决定文章何时公开的工作流。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时