Astro 博客中为 Codex 和 Claude Code 增加文章增删改 Skill

最近在整理这个 Astro 博客时，碰到一个很实际的问题：虽然文章本质上就是 Markdown 文件，但一旦开始让 Codex、Claude Code 这类 agent 直接参与内容维护，就不能只停留在“它们会改文件”这个层面。

真正麻烦的地方不在于能不能改，而在于怎么让它们按同一套规则去改。

如果没有边界，最容易出现的情况不是“不会写”，而是：

• 新文章写到了错误目录
• frontmatter 风格前后不一致
• 改正文时顺手把 slug 或文件名改了
• 用户只说“改一下”，结果 agent 把整篇文章大改了一遍

所以这次做的事情，不是先去补一个完整后台，而是先在仓库里增加一个专门面向文章增删改的 skill，让本地 agent 处理博客内容时有一套统一约束。

目标不是替代编辑器，而是统一行为

一开始最容易走偏的方向，是把问题理解成“要不要做一个更复杂的内容管理系统”。

但这次更核心的目标其实不是 UI，也不是接口，而是行为规范。

我希望这个 skill 至少能解决几件事：

1. 新增文章时，默认写入 content/blog。
2. 修改文章时，优先最小改动，不碰无关内容。
3. 删除文章时，只删目标 Markdown 文件，不顺带清理别的资源。
4. 用户只给一句话主题时，也能先整理出一篇可编辑草稿。
5. 如果信息不够，就保守收窄，不编造事实。

也就是说，这个 skill 的价值不在“替 agent 写文章”，而在“约束 agent 怎么写、怎么改、什么时候不能乱动”。

为什么先做 skill，而不是先补完整 API

从站点实现上看，这个博客现在已经有“读取文章”和“创建文章”的基础能力，但还没有完整的文章更新、删除接口。

如果这时候为了让 agent 可用，立刻去补一整套文章编辑 API，其实很容易把任务扩大：

• 要重新设计接口
• 要考虑鉴权
• 要补更新和删除逻辑
• 还要处理前端管理页如何对接

这当然不是不能做，但它不是当前最小必要路径。

相反，如果目标只是让 Codex、Claude Code 这类本地 agent 能可靠地协助维护博客，那么先把约束沉淀成一个 skill，收益反而更直接：

• 不需要先改动整站架构
• 能立即统一新增、修改、删除时的操作规则
• 后面就算补 API，这些规则仍然可以继续复用

所以这次采用的是一个更轻的方案：先把“文章怎么被 agent 修改”这件事写清楚，再决定以后要不要继续把它系统化。

skill 里真正重要的，不是能力，而是边界

这次新增的 skill 放在仓库里的结构很简单：

skills/blog-post-editor/SKILL.md
skills/blog-post-editor/agents/openai.yaml
docs/skills-blog-post-editor.md

文件不多，但边界必须明确。

其中 SKILL.md 里最重要的几条约束，不是“会不会生成文章”，而是：

1. 新文章优先写到 content/blog，不是别的目录。
2. 编辑前先读目标文章或相邻样例，再动手。
3. 除非用户明确要求，否则不主动修改 slug、文件名和发布日期。
4. 删除时只删目标 Markdown 文件，不顺手扩散操作范围。
5. 一句话起稿可以做，但不能伪造数据、截图内容、测试结论或排障经历。

这些规则看起来都不复杂，但实际很关键。

因为对 agent 来说，真正容易出问题的地方，通常不是“不会创建文件”，而是默认自由度太高。一旦没有边界，模型就很容易把“协助编辑”做成“擅自重写”。

一句话生成草稿，为什么也要单独写规则

文章增删改之外，这次还额外补了一种能力：当用户只给一个主题、一句话描述，或者一个很简短的提纲时，agent 可以直接先生成一篇可编辑草稿。

这个能力看上去很自然，但如果不写清楚，也很容易失控。

因为“一句话生成草稿”和“自由发挥写长文”只有一线之隔。

所以这里单独加了几条限制：

• 草稿要基于用户已经提供的信息展开
• 结构可以完整，但细节表达要保守
• 不要为了凑篇幅加入没被验证过的技术细节
• 如果关键信息缺失，就缩小主题，而不是硬写

这样做的好处是，agent 既能提高起稿速度，又不会因为“自动补全欲望太强”而把文章写偏。

这类 skill 更像仓库内规范，而不是魔法能力

很多时候，大家提到 skill，会直觉想到“模型多了一种新能力”。

但对这种场景来说，它更像是一份仓库内的操作规范。

因为 Codex、Claude Code 这类 agent 本来就会读写文件，skill 并不是让它们第一次获得“编辑 Markdown”的能力，而是把下面这些事情固定下来：

• 文章放哪
• frontmatter 长什么样
• 哪些字段默认不能乱动
• 什么时候可以直接起稿
• 什么时候必须保守处理

从这个角度看，skill 的价值其实很像“给协作者写 onboarding 文档”，只是这里的协作者变成了 agent。

下一步可以继续做什么

把文章增删改 skill 落下来之后，后续还有几个自然延伸方向：

1. 给文章修改和删除补正式 API，而不是只靠本地文件操作。
2. 让管理页支持调用同一套规则，而不是和 skill 各写一套逻辑。
3. 把“生成草稿”和“直接发布”拆成更清晰的两个模式。
4. 如果后面接 MCP 或远端发布链路，再把 skill 扩展成“改稿 + 发布”的完整工作流。

不过这些都属于下一阶段的事。

当前这一步更重要的是先把边界立住：让 agent 在这个博客仓库里处理文章时，行为一致、风险可控、改动范围可预期。

小结

这次给 Astro 博客增加文章增删改 skill，本质上不是为了炫技，也不是为了让 agent 看起来更自动化。

真正的目的，是把“文章编辑这件事的默认规则”沉淀下来。

这样以后无论是 Codex、Claude Code，还是别的本地 agent，只要进入这个仓库，就知道：

• 新文章该写到哪里
• 改文章时什么可以动、什么不要乱动
• 删除时边界在哪
• 用户只给一句话时，草稿该怎么保守展开

当这些规则先被固定下来之后，后面的自动化才更值得继续往下做。