我之前已经写过一篇「我用 ChatGPT 管理多个 WordPress 网站」，讲的是一个人编辑室怎样把选题、研究、写稿、SEO、Draft 和 Featured Image 放进日常工作流程。所以这篇不再重复「ChatGPT 可以怎样帮我经营网站」。

这次我想记录的是更具体的一件事：我到底怎样把 ChatGPT 接进 WordPress，让它从给我文字，变成真的可以把工作结果送进网站后台？

最近这段测试，我陆续把 WordPress MCP、Media Center、WebP 图片处理和 Featured Image 串起来。过程并不顺利：出现过 route error、HTTP 401、Token 明明相同却被判断为未配置、图片做好了却进不了 WordPress，也发生过工具为了安全拒绝修改非 Draft 文章。

但也正因为这些失败，我开始看清楚：所谓 AI 自动化，真正困难的往往不是「让 AI 会写」，而是权限、接口、文件流向和失败后的恢复机制。

先说清楚：这篇和我之前的 WordPress 文章有什么不同？

我已经写过 我用 ChatGPT 管理多个 WordPress 网站：一个人编辑室的实际工作流程，那篇重点是「编辑工作怎么分配给 ChatGPT」。另外，MCP 是什么？为什么 AI 接上工具后，才真正开始能做事？ 解释的是 MCP 的概念。

这一篇则只处理技术实施：ChatGPT → MCP → WordPress Draft → Yoast SEO → Media Center → WebP → WordPress Media Library → Featured Image。

换句话说，前两篇回答「为什么」和「怎么用」，这篇记录「我是怎样把这条链真的接起来」。

第一步：WordPress MCP 先只开放读取

我没有一开始就让 AI 拥有很多 WordPress 权限。最初只让它读取近期文章、搜索旧文章、读取 Draft，以及查看现有分类和标签。

这一步很重要。因为如果 ChatGPT 每天写文章之前不知道网站已经有什么内容，它很容易重复选题。事实上，这次我重新检查今天的 Draft，就发现它原来的角度和 9 月 9 日那篇文章太接近，于是决定重写。

这也是我现在认为最基本的自动化原则：先让 AI 看清楚现状，再允许它行动。

第二步：允许建立 Draft，但不给 Publish

读取稳定以后，我才加入建立和修改 WordPress Draft 的能力。

于是原本的流程从「ChatGPT 写完 → 我复制 → 打开 WordPress → 贴进去」，变成：

1. ChatGPT 读取近期文章和 Draft；
2. 检查是否重复选题；
3. 完成文章；
4. 使用网站现有分类与标签；
5. 直接建立 WordPress Draft；
6. 再读取一次，确认文章仍然是 Draft。

我刻意没有开放自动 Publish。因为建立 Draft 是可逆的，发布却会立即影响读者、搜索引擎和社交分享。对我的工作方式来说，让 AI 做准备工作、最后由人决定发布，是比较合理的边界。

第三步：把 Yoast SEO 也独立成一个动作

文章进入 WordPress 后，还有 Focus Keyphrase、SEO Title、Meta Description 和 slug。

以前这些资料即使已经由 ChatGPT 写好，我还是要自己逐项复制。后来我把 SEO metadata 也加入 Draft 工作流程，并规定 SEO Title 统一保留网站变量：

文章标题 ｜ %%sitename%%

这样 ChatGPT 不只是产生 SEO 建议，而是可以把已经确认的资料写进对应 Draft。

这里有一个我觉得很重要的差别：「AI 给你答案」和「AI 完成一个受限制的动作」不是同一件事。真正省时间的是后者。

第四步：文章通了，Featured Image 却卡住

文字和 SEO 打通以后，我原本以为工作已经完成大半，结果最麻烦的是图片。

ChatGPT 可以生成图片，但生成完成不等于图片已经进入 WordPress Media Library。中间还有尺寸、压缩、WebP、SEO 文件名、Alt Text、上传，以及最后把 Media ID 指定成 Featured Image。

我之前已经整理过 AI 图片上传 WordPress 前：做好 WebP 与图片 SEO 的 8 个步骤。这次真正要解决的是：怎样把这些步骤变成一条可以执行的文件流程。

第五步：为什么需要 Media Center？

我后来把图片工作拆出来做成 Media Center。它不是拿来写文章，而是负责图片和新闻稿素材的中转。

理想流程是：

1. 图片进入 Media Center 的指定 package；
2. 确认文件存在；
3. 需要时调整尺寸；
4. 转换成 WebP；
5. 换成有意义的 SEO 文件名；
6. 写入自然的 Alt Text；
7. 上传到 WordPress Media Library；
8. 指定为某篇 Draft 的 Featured Image；
9. 确认 WordPress 成功后，才决定是否清理 Datacenter 原文件。

这里最重要的不是「自动删除」，反而是只有确认下一步成功以后，才清理上一层的原文件。这样接口中途失败，图片仍然有机会恢复。

HTTP 401：Token 看起来一样，为什么还是认证失败？

Media Center 测试期间，其中一个最烦的问题是 HTTP 401。两个地方的 Token 看起来明明相同，诊断结果却一直说认证没有配置。

后来排查时，我发现这种问题不能只看「我明明已经填了 Token」。真正需要确认的是：

• 服务器实际收到什么 Authorization header；
• 收到的 Token 和服务器环境变量是否真的一致；
• 请求有没有进入正确 route；
• 错误发生在认证前还是文件处理阶段。

最后把诊断逻辑简化，直接检查服务器收到的 Token 与预期 Token 是否匹配，才终于把问题定位清楚。

这件事改变了我对自动化工具的要求：错误信息一定要能帮助排错。「连接失败」四个字几乎没有用；401、route、package、filename、post status 这些状态才真正有用。

另一个安全设计：Featured Image 只能送给 Draft

图片接口打通以后，我又遇到一个看起来像错误、实际上是安全机制的情况：当目标文章不是 Draft，工具直接拒绝设置 Featured Image。

一开始会觉得麻烦，但我后来反而认为这个限制应该保留。

因为图片上传工具的任务应该是「完成正在编辑的文章」，而不是随便修改已经发布的内容。只允许 Draft，等于在接口层多加一道保险。

同样的逻辑也适用于删除：如果 Media Center 原图要清理，应该等 WordPress import 成功以后才执行，而不是上传动作一开始就删掉来源。

现在这条链实际长什么样？

经过这些测试后，我想要的流程已经越来越清楚：

检查网站 → 选题 → 写稿 → WordPress Draft → Yoast SEO → 生成/取得图片 → Media Center → WebP/尺寸/SEO 文件名 → WordPress Media Library → Featured Image → 最后人工检查 → Publish。

其中 AI 可以执行很多步骤，但几个安全边界仍然保留：

• 文章默认只到 Draft；
• 使用现有分类和标签，不随便创造新 taxonomy；
• Featured Image 只允许写入 Draft；
• 删除 Datacenter 来源必须发生在成功导入之后；
• 最终 Publish 仍由我决定。

这才是我觉得有用的 AI 自动化

我以前想到「AI 自动化」，容易把重点放在少做多少次点击。但实际把这套东西接起来以后，我反而觉得最重要的是：每一步有没有明确输入、明确输出、明确权限，以及失败时能不能知道坏在哪里。

如果一个自动化流程平时很快，但出错以后完全不知道文件去了哪里、文章改了什么、为什么认证失败，那它反而会增加工作量。

现在这套 WordPress + MCP + Media Center 还不是所谓「全自动」。但它开始符合我的实际工作方式：机器处理重复而规则明确的动作，人负责选题、判断、检查和最后发布。

如果你也想做类似流程，我会这样开始

1. 先做只读接口，确认 AI 能正确看到网站内容；
2. 再开放建立 Draft；
3. 确认 Draft 修改稳定后才加入 SEO metadata；
4. 图片上传独立测试，不要一开始和文章流程绑死；
5. 为每个写入动作限制目标状态和权限；
6. 删除动作放到最后，并且必须建立在前一步成功的条件上；
7. 最后才考虑更进一步的自动化。

如果连第一阶段的错误都看不懂，就不要急着开放 Publish 或 Delete。工具越多，不代表流程越成熟。

小结

这次真正让我觉得 ChatGPT 开始进入 WordPress 工作流程的，不是它写出了一篇文章，而是它终于可以在受限制的权限下，把文章、SEO 和图片一步一步送到正确的位置。

而整个测试过程中最有价值的，其实也是那些失败：401、route error、图片接口缺失、文件不能写入、非 Draft 被拒绝。因为这些问题逼着我把流程的权限和恢复机制想清楚。

对我来说，好的 AI 自动化不是「什么都自动做」，而是该自动的尽量自动，该停下来的地方一定停下来。

FAQ

MCP 可以直接让 ChatGPT 控制 WordPress 吗？

要看你提供什么工具和权限。MCP 本身不是 WordPress 控制器；实际动作仍然由你建立的工具、WordPress API 和服务器权限决定。

为什么要另外做 Media Center？

因为图片和文章是不同的数据流程。Media Center 可以先处理素材、WebP、尺寸、文件名和来源，再把确认后的图片交给 WordPress，比让文章工具同时负责所有文件操作更容易检查。

为什么 Featured Image 只允许设给 Draft？

这是我刻意保留的安全边界。它可以避免图片工具意外修改已经发布的文章，也符合「AI 负责准备、人负责发布」的工作原则。

这套流程已经完全自动化了吗？

没有，也不是我的目标。现在重点是把重复、规则明确的工作串起来，同时保留人工审核、发布决定和必要的删除确认。