开始写博客后，我一直在琢磨，如何让写博客更方便一点。我先后调整了目录结构，优化了文件管理方式（Nuxt Content 多语言文件管理），但每次发布新文章依然有一堆重复动作要手动完成。
现在我要发布内容，流程是这样的：
- 打开博客工程 ——（每次都要切到工程目录）
- 在对应类型的文件夹下，新建一个临时文件夹 ——（先想清楚放哪儿）
- 新建一个临时的
index.zh-CN.md和meta.json文件，手动填一堆基础信息 ——（重复劳动的重灾区） - 开始写文章 ——（这步值得认真做）
- 预览并调整格式 ——（图还没放，预览也是临时看）
- 有图片还需要手动放到资源文件夹 ——（最打断思路的一步）
- 翻译成英文，手动创建
index.en.md文件，粘贴内容 ——（纯体力活） - 拟定标题、url、tags 等基础信息，更新文件夹名称和
meta.json文件 ——（决策和体力混在一起） - 在本地环境预览，检查文章展示是否正确 ——（不放心，再看一眼）
整个流程看下来，不知道你会不会跟我有一样的体会：还是麻烦。这就不可避免地在无形之中影响我写作的动力。一想到写东西要吭哧吭哧搞半天，就不想动笔了。
后来转念一想，既然我都辅助用 AI 了，为什么不更彻底一些呢？一些重复的工作直接流程化交给 AI 如何？想要做到这样的效果，那非 skills 莫属了。终于，我要创建属于自己的第一个 skill 了。
哪些步骤省不掉
用极简的思路去想，9 个步骤中，再怎样也省不了的是：
- 打开博客工程
- 输入文章的草稿
- 图片资源的管理
- 预览和格式调整
其他步骤都可以让 AI 自动帮我做。于是我就让 VS Code 的 Copilot 帮我基于下面的提示词生成一个 skill：
帮我生成一个辅助写文章的 skill
我会提供一个中文的初稿，根据初稿的内容，帮我判断是什么文章类型，自动拟定标题、标签、页面 url 等基础信息，然后根据文章类型在对应文件夹下生成内容。
标签可以从 i18n 的文件中获取，如果没有合适的标签，可以自动生成，但是要注意生成中英文双语的。标签最多不要超过 5 个。
从中文翻译成英文时，尤其注意不要修改原来的 markdown 格式，仅翻译文本内容
请结合现有代码的实现，生成具体的 skill
就这么一段提示语，然后 AI 帮我结合代码生成了一份详细的操作指南，给我惊到了。Skills 里详细地列举了当前我所有的博客类型，每个类型分别有哪些基础字段，还查询到了所有的标签。
生成 Skill 的部分节选：
## When to Use
- 用户写好了一篇文章初稿，需要生成博客文章（blog）
- 用户写了一段思考/随想，需要生成思考条目（thoughts）
- 用户想要添加一个馆藏条目（artifacts）
- 需要将中文内容翻译成英文并保持格式不变
- 需要为文章自动匹配或创建分类和标签，并同步 i18n 翻译
## Content Types Overview
| Type | Folder | Structure |
| --------- | ----------------------------------- | ---------------------------------------------- |
| Blog | `content/blog/<slug>/` | `meta.json` + `index.zh-CN.md` + `index.en.md` |
| Thoughts | `content/thoughts/<YYYYMMDD>-<NN>/` | `meta.json` + `index.zh-CN.md` + `index.en.md` |
| Artifacts | `content/artifacts/<id>.json` | Single JSON file with bilingual fields |
## Procedure
### Step 1: 分析用户初稿
接收用户提供的初稿内容，判断内容类型：
- **blog**: 长文、结构化文章、有完整标题和段落
- **thoughts**: 短思考、随想、无标题的碎片记录
- **artifacts**: 书影音游戏等作品的评价记录
如果用户未指定类型，根据内容长度和结构推断并询问确认。
### Step 2: 确定 Slug
**Blog**: 从标题生成英文 slug。规则：
- 全部小写
- 空格替换为连字符 `-`
- 去除特殊字符
- 示例：`"AI 辅助的全栈工作流与开发者成长"` → `ai-assisted-fullstack-workflow-and-developer-growth`
**Thoughts**: 使用当前日期格式 `YYYYMMDD-NN`。`NN` 从 00 开始递增，检查 `content/thoughts/` 下同名日期文件夹的最大序号。
**Artifacts**: 使用英文短标识符，如 `movie-harry-potter`、`game-hogwarts-legacy`。检查 `content/artifacts/` 下不重名。
### Step 3: 分析并匹配分类和标签
......
### Step 4: 创建内容文件（以 blog 为例，thoughts 类似）
......
### Step 5: 处理 Thoughts（思考条目）
......
### Step 6: 处理 Artifacts（馆藏条目）
......
### Step 7: 同步 i18n
......
### Step 8: 验证
完成后检查：
- [ ] 所有文件是否创建在正确的路径
- [ ] `meta.json` 的日期、分类、标签是否正确
- [ ] 中文和英文文件是否对应
- [ ] 翻译是否只修改了文本内容，保留了所有格式
- [ ] 新建标签是否在 `en.json` 和 `zh-CN.json` 中都添加了
- [ ] Artifact ID 如果使用了，是否与 `content/artifacts/` 中的文件一致
- [ ] SEO 元数据是否合理
### Step 9: 总结
向用户汇报完成的内容：
- 创建了哪些文件
- 使用了哪些分类和标签
- 是否有新建的标签及对应的 i18n 条目
- 提示用户检查翻译质量
## References
- Content config: 项目根目录 `content.config.ts`
- i18n 中文: `i18n/locales/zh-CN.json`
- i18n 英文: `i18n/locales/en.json`
- Content 目录: `content/blog/`, `content/thoughts/`, `content/artifacts/`
这样我就不再需要打开工程写草稿了，我可以在任何位置、任意编辑。写好草稿，润色完成后，再打开工程，对 AI 说：
/write-article 请根据下面的草稿帮我生成内容文件：
文章草稿
这样比原来的操作方便多了。再也不需要自己手动创建这、创建那。只需要把所有的精力放在文章内容和检查最终的格式上。
对 Skills 的新理解
没想到第一次自己创建 skill 不是编码，而是写文章。这让我对 skills 的理解更深了一层：凡是重复性的标准工作，都可以生成一个 skill 来让 AI 执行，提升做事效率。
这样修改后，写文章的阻力小了很多。唯一不方便的，就只是图片、文字格式排版的处理没有可视化编辑器那么友好了。这一点，后续再想办法吧。