昨天我做了一件很小但很有代表性的事：把一篇草稿优化后发布到老达AI实践栏目。事情本身不复杂，流程也很常见：读草稿、优化标题和正文、补摘要、设置栏目标签、上传特色图、发布到 WordPress、再检查页面 SEO。
但发布完之后我发现一个问题：这次任务用了大约 129k 标记。文章是发出去了，质量也没问题，可这个消耗明显偏高。对一个需要长期运营的博客来说，如果每次发文都要重复读取大量配置、拉取完整接口响应、人工拼发布流程，这件事就不够工程化。
所以我顺手做了一次流程优化：把老达AI博客的发文流程沉淀成一个项目内的 WordPress Publisher Workflow。它不追求做成复杂平台，而是用一个轻量的 SKILL.md 加两个脚本，把高频、重复、容易出错的部分固化下来。
一、为什么一次普通发文会用到 129k 标记？
这次发文消耗高，并不是因为文章特别长，而是因为执行过程里有很多重复动作。
比如，为了确认栏目和标签，我读取了 WordPress 分类、标签和近期文章；为了确认 SEO 输出，我抓取了整页 HTML；为了补 meta keywords，又检查了主题文件；为了设置特色图，还读取了媒体库返回的大段 JSON。
这些动作都合理，但如果每次都这么做，就会变成浪费。真正需要的其实只有几个高价值信息：
- 目标栏目 ID 是多少；
- 应该复用哪些核心标签；
- 文章有没有摘要、特色图和内链；
- 发布后页面有没有 title、description、keywords 和 OG 图；
- 正文里有没有误写
<h1>。
换句话说，问题不在 AI 能不能完成发文，而在流程有没有被固定下来。没有固定流程时，AI 每次都要重新探索一遍网站结构；有固定流程后，AI 只需要执行检查清单。
二、我没有把它做成全局 Skill，而是放进项目里
一开始我考虑过创建一个全局 Codex Skill。全局 Skill 的好处是容易被自动触发，任何项目都能用。但这个发文流程只服务老达AI博客，里面包含栏目 ID、标签 ID、常用内链、WordPress 发布规范，这些都不是通用知识。
所以最后我选择放到项目目录里：
tools/wordpress-publisher/
├── SKILL.md
├── scripts/
│ ├── publish_post.js
│ └── check_post.js
└── references/
└── site-config.json这样做有几个好处。
第一，所有站点专用规则都跟项目放在一起，不污染全局技能目录。以后迁移网站、备份项目、调整栏目和标签，只需要看这个项目。
第二，AGENTS.md 继续作为总规则，项目内 SKILL.md 只管发文流程。两者不会混淆：一个管“网站原则”，一个管“发布动作”。
第三，脚本和配置可以版本化。虽然这个目录当前不是 Git 仓库，但从工程习惯上，它已经具备了可维护的结构。
如果你对 AI 项目规则感兴趣，可以先看我之前写的 老达AI博客 SEO 优化复盘。那篇讲的是内容和站点层面的 SEO，这篇讲的是把发布动作工程化。
三、这个项目内 Skill 到底解决什么问题？
它解决的不是“让 AI 会写文章”。AI 本来就会写文章。它解决的是“让 AI 每次都按同一套标准发布文章”。
我在 SKILL.md 里固化了几条关键规则：
- 正文不写
<h1>，标题由 WordPress 主题输出； - 摘要必须控制在 80-150 个中文字符；
- 每篇文章必须有特色图和清晰 alt；
- 至少加入 3 条站内相关链接；
- 优先复用已有核心标签，避免制造空标签；
- 发布后检查只取必要字段，减少大段接口返回。
这些规则原本写在对话里，每次都要重新强调。现在它们变成项目内文件。以后我只要说“把这篇草稿优化后发布到老达AI实践”，AI 就应该优先读取这个发布流程，而不是从零开始猜。
四、脚本负责执行，Skill 负责判断
这里有一个很重要的取舍：我没有把所有逻辑都写进 SKILL.md。因为如果 Skill 写得太长，本身也会消耗大量上下文。
更合理的分工是：
SKILL.md负责流程、规则和决策；site-config.json负责栏目、标签和常用内链；publish_post.js负责解析草稿、上传图片、调用 WordPress API；check_post.js负责发布后精简检查。
这就是“Skill 管流程，脚本管执行”。如果只写脚本，AI 不一定知道什么时候该用、怎么选栏目标签、什么时候需要补内链；如果只写 Skill，每次执行仍然要消耗很多标记。两者结合，才是更适合长期运营的方式。
这和 AI 智能体与自动化专题 里反复强调的思路一致：真正有价值的 Agent 不是会聊天，而是能稳定执行一套带规则的工作流。
五、我把哪些内容做成了配置？
最值得固化的是那些“经常用、但每次查都浪费”的信息。
比如老达AI博客的栏目 ID：
- 老达AI实践：1154；
- AI资讯：1155；
- AI工具：1157；
- AI百科：1385。
再比如常用标签：
- AI Agent；
- AI编程；
- AI实践；
- Codex CLI；
- OpenAI Codex；
- Claude Code。
还有常用站内链接，比如 老达AI实践专题、AI 编程工具专题、OpenAI Codex 最新进展 这些页面。它们经常适合作为文章内链，没必要每次都重新搜索。
六、发布脚本只做一件事：把草稿可靠地变成文章
publish_post.js 的设计很克制。它只做几件事：
- 读取草稿头部的标题、slug、摘要和特色图 alt；
- 检查正文是否包含
<h1>； - 根据命令参数设置栏目、标签和特色图；
- 必要时上传特色图；
- 调用 WordPress REST API 发布文章；
- 只返回文章 ID、链接、状态、slug、栏目、标签和特色图 ID。
这里最关键的是“只返回必要字段”。以前直接拿 WordPress API 的完整响应，会带回大量正文、链接、媒体尺寸和其他元数据。人类看不完，AI 也不需要。现在只拿发布结果，速度和标记消耗都会好很多。
脚本还支持 --dry-run。也就是说，正式发布前可以先看一眼即将提交给 WordPress 的精简 payload，确认标题、栏目、标签、特色图都对，再真正发布。这个功能看起来小，但能减少误发。
七、检查脚本只检查真正重要的页面结果
check_post.js 也没有试图做复杂爬虫。它只检查发布后最关键的结果：
- 页面是否返回 200；
<title>是否正常；meta description是否输出；meta keywords是否输出；og:image是否存在；- 特色图 alt 是否存在；
- 正文内容区是否误含
<h1>； - 正文里有多少条站内链接。
这里有一个小细节：一开始脚本把页面主题输出的标题 <h1> 也算进去了，导致误报。后来我把检查范围限定到正文内容区，也就是 entry-content，这样才符合发布规范。
八、这套流程能节约多少？
粗略估算，同样一篇文章，以前可能会消耗 100k 以上标记；如果后续都走这个项目内 workflow，常规发文应该可以压到 15k-30k 左右。具体数字取决于文章长度、是否需要查资料、是否需要生成图片、是否要改主题。
节约主要来自四个地方：
- 栏目、标签、内链不再每次重新查；
- WordPress API 只返回必要字段；
- 发布后检查只抓关键 meta；
- 固定脚本避免反复写临时代码。
对个人博客来说，这种优化不是为了炫技，而是为了长期稳定。一个流程如果每周都要用，就值得把它沉淀下来。
九、普通站长可以怎么照着做？
如果你也在用 WordPress 运营博客，不一定要照搬我的目录，但可以照搬这个思路。
第一步，先写清楚你的发布规范。比如标题怎么写、摘要多长、栏目怎么选、标签怎么复用、内链至少几条。
第二步，把固定信息放进配置文件。栏目 ID、核心标签、专题页、旧文章链接，这些都是高频数据。
第三步，把发布动作脚本化。上传图片、设置特色图、发布文章、返回链接，这些不要每次手工拼。
第四步，把发布后检查脚本化。不要只相信“发布成功”，要检查页面是否真的有 title、description、keywords、OG 图和正文结构。
第五步，把这套规则写进项目说明。对我来说就是 AGENTS.md 加一条：发布、更新或检查 WordPress 文章时，优先使用项目内流程。
如果你还在比较 AI 编程工具，可以延伸看 Cursor、Windsurf 还是 Claude Code 和 Claude Code vs Gemini CLI。工具本身会变，但把重复流程工程化这件事不会过时。
十、老达点评：AI 运营博客，重点不是一次写得快，而是每次都稳定
很多人用 AI 写博客，关注点还停留在“能不能帮我写一篇”。但真正运营一个网站，问题不是一篇文章，而是几十篇、几百篇文章如何持续稳定地产出、发布、检查和更新。
这次把发文流程做成项目内 Skill，对我最大的启发是：AI 工作流不能只靠临时对话。临时对话可以解决一次问题，但不能保证下一次还一样稳。
真正可持续的做法，是把规则写进项目，把配置放进文件，把重复动作交给脚本，把判断留给 AI。这样 AI 才不是一个临时帮手，而是能长期参与网站运营的执行系统。
对老达AI博客来说，这套流程只是开始。后面还可以继续把旧文更新、专题页维护、死链检查、百度推送、收录跟踪和流量复盘逐步固化。等这些环节都串起来，AI 才真正从“写文章工具”变成“博客运营助手”。
