让 AI 管理 WordPress 内容，最大的误区不是技术难，而是上来就给它管理员权限。真正可落地的做法，应该是把 WordPress 接入拆成一条受控流程：先给一个专用低权限账号，再使用可撤销的 Application Password 做 API 认证，默认只允许读取或创建草稿，最后把发布动作留给人工确认。这样你获得的是“AI 协助内容运营”的效率，而不是“把整个站点赌给自动化”。
先明确目标：管理内容，不是接管后台
如果你的目标是让 AI 帮你整理选题、生成草稿、补充摘要、检查标签、上传候选图片，那它根本不需要管理员能力。你真正需要的，是一个能读取现有文章、创建新草稿、更新指定字段、在需要时查询媒体信息的受控接口。目标越明确，权限越容易缩小，工具设计也越简单。
为什么推荐用 WordPress Application Passwords
WordPress 官方把 Application Passwords 定义为可撤销、按应用生成的程序化访问凭证，专门用于 API 认证，而不是浏览器后台登录。官方文档还说明，这类凭证会被哈希存储、创建时只显示一次，并且可以单独吊销，不必更换主账号密码。对 MCP 场景来说，这正好符合“给某个自动化接入单独凭证”的需求，比直接共享站长主密码安全得多。
Basic 认证在 WordPress 场景下怎么正确使用
WordPress 官方文档进一步说明，Application Passwords 通常通过 HTTP Basic Authentication 使用：用户名是 WordPress 登录名，密码是生成的应用密码，而且必须始终走 HTTPS。这里最容易出错的地方有两个：第一，把应用密码当成普通后台登录密码使用；第二，在不安全链路上发送 Basic 凭证。前者违背了官方用途，后者则会放大被截获风险。
推荐的 MCP 工具分层
- 只读工具：列出文章、读取文章、查询分类、查询标签、查看媒体信息。
- 低风险写工具：创建草稿、更新摘要、更新 SEO 字段、上传候选媒体但不发布。
- 高风险工具：正式发布、覆盖已发布正文、删除文章、批量改分类。
第一阶段只开放前两层，就已经能覆盖绝大多数内容生产场景。高风险工具最好单独留到后续，并配人工确认。
一个安全的实际流程
- AI 读取现有栏目、标签和重复标题，避免撞题。
- AI 在本地生成正文、摘要、SEO 和 FAQ。
- 通过 MCP 创建 WordPress 草稿，而不是直接发布。
- AI 回读草稿，确认标题、分类、图片和元数据是否写入成功。
- 人工在后台或审核流程中确认，再决定是否公开。
这个流程的关键在于“先草稿、再读回、后审核”。只要你把发布留给最后一步，很多前期错误都还能被拦住。
账号和权限怎么配更稳
建议单独创建一个只服务于 MCP 的 WordPress 账号，不与站长主账号混用。这个账号最好只拥有完成当前任务所需的最低能力，例如编辑草稿而不是管理全站设置。同时，给这个账号单独生成应用密码，并在不再使用时随时撤销。这样即便凭证泄露，攻击面也比管理员账号小得多。
图片和媒体为什么也要单独审查
内容自动化很容易忽略图片风险。除了大小、格式和加载是否正常，更重要的是图片来源是否合法、是否与主题直接相关、是否会把低分辨率图标硬拉成大图。你完全可以让 MCP 负责上传媒体、关联草稿，但图片来源和最终视觉效果最好仍然留一道人工检查，尤其是对外公开的特色图。
最容易出问题的四个地方
- 直接给管理员账号和长期凭证，省了配置却放大了风险。
- 让 AI 直接发布，跳过草稿与读回验证。
- 把 Application Passwords 当成人工后台登录密码使用。
- 没有记录哪篇内容由哪个工具、哪个账号、哪次调用写入。
一个更稳的落地建议
先把第一版 MCP 工作流限定在“读取站点信息 + 创建草稿 + 读回校验”。这一步跑顺后，再考虑开放更新正文、更新图片或安排审核节点。别急着一步到位做成全自动发布系统，因为内容后台一旦接上真实站点，错误代价通常远高于你节省的那一点手工时间。
相关阅读
总结
让 AI 安全管理 WordPress，不是把后台交给模型，而是把模型放进一套受控流程里：低权限账号、应用密码、HTTPS、草稿优先、读回验证、人工确认。只要这六个环节站稳，你就能在不牺牲站点安全的前提下，真正享受内容自动化带来的效率提升。
