Selfhost

让 AI Agent 安全管理 WordPress：一次分类与标签重构中的失败、回滚与最终方法

让 AI Agent 安全管理 WordPress：一次分类与标签重构中的失败、回滚与最终方法 AI Agent 很适合处理重复的 WordPress 管理任务，但“可以调用 API”并不等于“适合自由决定网站结构”。 一次较大规模的分类与标签重构，很容易暴露这个差异。 表面目标可能很简单： 减少过度细分的 Category； 将三级结构压缩为较稳定的两级结构； 清理明显错误的 Tag； 保留真正有检索价值的细粒度主题； 不改变正文、Slug、发布时间和文章状态。 真正困难的部分，却不是 REST API，而是如何把语义决策和机械执行彻底分开。 第一类失败：用字符串代替语义 最早出现的问题，是使用简单字符串规则生成 Tag。 这种方法对长而明确的关键词有时有效，但对短词非常危险。 例如，一个只有几个字母的技术名词，可能恰好出现在： directory operator monitor editor vector 等完全不相关的单词内部。 如果使用： if keyword in body: add_tag() 就会产生大量假阳性。 这类错误的危险之处在于：系统表面上运行成功，API 返回 200，数据库也没有损坏，但网站语义已经被污染。 因此，HTTP 成功不等于任务成功。 第二类失败：过度依赖“语义审计” 发现字符串规则不可靠之后，一个自然的想法是：让模型重新阅读文章，然后判断 Tag 是否应该保留。 …

AI

把临时操作变成可复用能力：为 OpenClaw 设计一个安全的 WordPress 管理 Skill

把临时操作变成可复用能力：为 OpenClaw 设计一个安全的 WordPress 管理 Skill 让 AI Agent 管理 WordPress，看起来只需要“给它一个 API，然后让它发文章”。真正开始长期使用之后，很快会发现事情没有这么简单。 发布文章只是最表层的能力。实际还会遇到分类、标签、草稿、私密文章、Slug、特色图片、批量更新、权限控制、备份、回滚、异常中止等问题。如果这些规则只存在于某一次聊天里，那么下一次任务仍然要重新解释，执行结果也容易漂移。 更可靠的做法，是把已经验证过的规则整理成一个可复用的 Skill。这样，模型负责理解任务，Skill 负责约束行为，底层脚本负责与 WordPress API 交互。 为什么需要 Skill 一次性的提示词适合临时任务，但不适合作为长期运维规范。 例如，同样是“更新一篇文章”，实际可能有完全不同的风险： 修改正文可能意外覆盖原始 HTML； 更新分类时可能把原来的标签一起清空； 重新提交整篇 Post 对象可能改变 Slug、时间或状态； 批量操作时，一篇文章失败可能影响后续数百篇； REST API 中某些统计字段并不能完整反映 private 内容； 分类和标签虽然都属于 taxonomy，但它们的业务语义并不相同。 如果每次都让模型临场决定，很容易出现“技术上能执行，但业务上不应该执行”的情况。 Skill 的价值，就是把这些已经确认的规则固定下来。 一个合适的职责分层 比较稳妥的结构可以分成三层。 第一层是自然语言层。用户只需要描述目标，例如： 将一批文章重新分类，但不要改变正文、Slug 和发布状态。 第二层是 Skill。Skill 明确告诉 Agent： …