给 KuroNotes 写一个博客写作 skill：从能用到好读的全过程

背景#

KuroNotes 搭起来之后，我很快发现一个实际问题：很多值得写进博客的内容，讨论时已经说清楚了背景、问题和方案，但最后还是停在聊天窗口里，没有继续整理成文章。

所以这次我想解决的不是泛化的“AI 自动写博客”，而是更具体的一步：把一段已经成形的技术讨论接成草稿，再在确认之后安全地发布出去。

目标和约束#

我没有把这个 skill 做成一个面向所有博客的通用工具，而是先给 KuroNotes 配了一个固定仓库版本。这样做的好处是路径、目录和构建命令都可以明确写死，行为会更稳定。

最早确定下来的约束只有几条：

固定仓库：/root/kuronotes
“记到博客里”默认只生成草稿，不自动发布
“发布出去”前必须先执行 pnpm build
发布时只提交目标文件，不使用 git add .

这几条约束本身很简单，但它们基本决定了这个 skill 的边界。

skill 的目录结构#

我最后把它收敛成了一个很小的结构：

1
kuronotes-blog-writer/
2
├── SKILL.md
3
└── references/
4
    ├── workflow.md
5
    └── writing-style.md

这里的分工是刻意拆开的：

SKILL.md：定义触发场景和核心工作流
references/workflow.md：保存仓库路径、文章目录、命名规则、发布顺序
references/writing-style.md：保存写作风格、禁写项和自检清单

这样做的目的，是让主文件只负责“怎么走流程”，而不是同时承担所有项目配置和写作偏好。

`SKILL.md` 应该写什么#

这个 skill 的主文件里，真正关键的是 frontmatter 里的 description。因为 skill 能不能被正确触发，很大程度上取决于这里是否覆盖了用户的真实表达方式。

对博客写作场景来说，我需要它能理解这些请求：

把刚刚讨论的问题记到博客里
整理成博客草稿
润色这篇文章
帮我看看这篇能不能发
发布 / push 博客更新

正文部分我反而写得比较克制，只保留了 4 条核心工作流：

新建草稿
改写或润色已有文章
审阅草稿
发布确认过的更新

这样可以让主流程保持清楚，也避免一上来把太多风格细节塞进上下文。

为什么要把 reference 文件拆开#

这次改 skill 时，一个很有用的调整是把“项目配置”和“写作判断”拆成两份 reference。

workflow.md 里放的是偏工程配置的内容，例如：

仓库路径：/root/kuronotes
文章目录：/root/kuronotes/src/content/posts/
文件命名规则：YYYY-MM-DD-<slug>.md
发布前校验命令：pnpm build

writing-style.md 里放的则是偏成稿质量的规则，例如：

开头先交代为什么要做这件事
技术细节保留必需的部分，不要写成流水账
默认删除只对内部操作有意义的路径和机械步骤
写完后检查小标题、列表密度和读者能带走什么

如果把这两类内容混在一起，skill 很容易越写越臃肿；拆开之后，后面无论是改流程还是改风格，都会轻松很多。

发布流程怎么写进 skill#

对博客类 skill 来说，我觉得最重要的不是“会不会 commit”，而是能不能把发布边界写清楚。

KuroNotes 这边最后保留下来的发布顺序是：

1
cd /root/kuronotes
2
git status --short
3
pnpm build
4
git add <target-files>
5
git commit -m "publish ..."
6
git push

这里我后来明确加了两条限制：

如果仓库里有与本次任务无关的脏改动，先停下来
只 stage 目标文件，不直接 git add .

前者是为了避免误提交，后者是为了把自动化控制在可审查的范围内。

第一版的问题出在哪里#

第一版其实很快就能用了：它能根据最近对话生成新草稿，也能在发布前执行构建校验。

但真正把它拿来写文章时，我很快发现它更像在输出一份内部说明，而不是一篇技术博客。背景铺得太散，内部细节留得太多，信息虽然完整，但缺少技术文章那种“先讲目标和约束，再讲实现”的节奏。

这也是我后来重新参考那篇 Markdown 图片网格文章的原因。它的写法很克制：背景很短，目标讲得很快，后面直接进入结构和关键实现。我要借的不是它的主题，而是这种信息组织方式。

所以回到这个 skill 上，我后面做的并不是继续往里塞更多规则，而是把已经有的结构重新压实：背景只保留问题定义，目标和约束前置，技术细节优先展示目录结构、触发方式、reference 分工和发布流程，只对内部协作有意义的细节则默认删掉。这样调整之后，文章读起来会更像一篇可以复用方法的技术记录，而不是一份过程完整但重点不够突出的内部备忘录。

如果你也想给自己的博客配一个类似 skill#

如果你也在维护自己的博客，我觉得最值得复用的不是某一段具体文案，而是下面这套配置思路：

先固定仓库路径、文章目录和构建命令
先做草稿，再做发布，不要把两者混成一步
主文件只保留触发条件和核心流程
把项目配置和写作风格拆到 reference 文件里
明确写出“什么不能做”，尤其是发布边界和禁写项

做到这一步，一个只服务自己博客的小 skill，基本就已经足够好用了。

结语#

到现在为止，kuronotes-blog-writer 仍然只是一个很小的 skill，但它已经把 KuroNotes 最常用的一条内容沉淀路径接了起来：讨论结束后先生成草稿，确认之后再经过构建验证发布。

比起“自动写作”，我更愿意把它理解成一个更顺手的博客入口。真正有价值的不是让它代替写作，而是把那些本来会散在聊天里的技术讨论，更稳定地沉淀成文章。