# 我让 AI 记住了怎么帮我写博客

每次做完一个项目的某个阶段，我都想记录一下。这个习惯从很早就有了，不管是网站上线、自动化流水线跑通、还是某个工具搭好，总觉得值得写一篇文章。但实际操作起来，这件事并不轻松。哪怕是已经有AI帮忙了。

每次打开 AI 准备写博客，我都要重新解释一遍：我是谁、我的风格是什么、受众是哪些人、这篇文章要存到哪里。AI 写出来的初稿大多还算过得去，但总是差那么一口气，要么语气像教程，要么结构太模板，或者存错了地方。问题在于，这些"背景知识"每次都要重新交代一遍。

我意识到，我一直在重复做同一件事。

![](https://res.cloudinary.com/dypkcf109/image/upload/v1772141624/obsidian/aeffs1ejcjt88bjbofzf.png)

> 这两篇就是AI帮我写的项目总结博客，非常好，比我写的快多了。 

## 真正的问题是上下文每次都在归零

我日常在跑好几个项目，有些是自己的产品，有些是客户合作，有些是内容工具。每个项目做完一个里程碑，我都会想记录。这件事的频率相当高，差不多每两三周就会有一个值得写下来的节点。

但每次写博客的时候，我都要花相当一部分精力在"让 AI 理解我"这件事上。我的写作风格、目标读者、文章要存到哪个 Obsidian 目录、frontmatter 该写什么字段……这些东西本质上是固定的，每次都交代一遍，纯粹是重复劳动。

我有两个参考文件：一个是记录我个人背景和项目信息的 `Bear.md.md`，另一个是详细定义内容标准的 `Content.md.md`，包括受众定义、平台策略、每种内容形态的写作结构。这两个文件我维护得还算完整，但 AI 每次启动新对话，这些东西都消失了。

所以我想做一件事：把"写博客"这个任务打包成一个可以随时调用的技能，让它知道去哪里找参考文件、按什么结构写、把结果存到哪里。

![](https://res.cloudinary.com/dypkcf109/image/upload/v1772141602/obsidian/ub6hgjqypmpilklax3gl.png)


## 设计一个技能需要想清楚几个问题

Claude Code 有一个技能机制，可以把操作流程写成 Markdown 文件，之后通过关键词触发。我之前已经用这套机制做了语音笔记处理、社交帖子发布等几个工具，所以对这个流程比较熟悉。

但写博客这件事有几个地方需要特别设计，不能直接套用以前的模式。

**第一个问题是"观察者视角"的定义**。我想让这篇博客读起来像一个在场的记录者在还原事情，而不是总结报告，也不是自我推销。这两者的区别很微妙，但读起来感受差很多。总结报告把经验升华，观察记录保留细节和不确定性，保留那种"我当时也不知道这样做对不对"的质感。我在设计这个技能的时候，专门写了这部分的提示：保留决策过程中的取舍，诚实写出没预期那么顺利的地方，细节比结论更重要。

**第二个问题是怎么处理项目有新进展的情况**。我的很多项目都是分阶段推进的，比如网站先上线，然后再做响应式改版，然后再做内容更新。每个阶段都可能值得记录，但记录方式有两种：写一篇续集，或者在旧文章基础上直接补充。这两种方式适用场景不同。如果这次进展是一个独立的里程碑，那写新文章更合适，读者不需要看上篇也能理解。如果这次只是小的修正或补充，那更新旧文章就够了。我在技能里加了这个选择逻辑，让它先检查 vault 里有没有相关旧文章，有的话给我选。

**第三个问题是文章存在哪里、按什么格式**。这个相对简单，但也是每次最容易出错的地方。我的博客草稿统一存在 Obsidian 的 `Bear Content Vault/Blog/drafts/` 目录下，frontmatter 需要包含标题、标签、状态、日期、语言、所属项目。这些东西如果每次靠我自己填，总会有漏掉的时候。

![](https://res.cloudinary.com/dypkcf109/image/upload/v1772141680/obsidian/sunexcxufvtoluxoqe7v.png)


## 从想法到可用，大概花了5分钟

整个技能的设计过程是和 Claude 一起完成的。我口述了需求，它先读了我的两个参考文件，然后我们讨论了几个关键的设计决策，最终把整个流程写成了一个 SKILL.md 文件，放到 `~/.claude/skills/blog-writer/` 目录下。

这个过程中让我觉得有点奇妙的是，我在让 AI 帮我设计一个"让 AI 帮我写博客的技能"。最后验证这个技能是否有效的方式，就是让它写这篇博客。所以这篇文章本身就是技能的第一次实际运行。

技能目前的工作流程是：触发之后先读两个参考文件，问清项目信息，检查有没有旧文章，然后按案例复盘结构写草稿，存到 vault。整个过程我只需要告诉它"帮我写一篇关于 XX 项目的博客"，其他的它自己处理。

## 这篇文章就是它生成的

我在写这篇文章的时候，几乎没有手动写任何东西。我说了一句"帮我写一篇关于 blog-writer 技能创建过程的博客"，它启动了，读取了参考文件，知道我写这篇博客的上下文（就在刚刚这次对话里），然后开始写。

它最终生成的内容和存储格式都符合我的预期，frontmatter 完整，文件命名格式对，存到了正确的目录。这说明技能的基础逻辑是跑通的。

当然，这是第一次运行，还有一些我还没验证到的地方。比如，当一个项目已经有旧文章、我需要写续集的时候，它的处理方式是否合理；或者对于一个信息不全的任务，它追问的方式是否自然。这些要等后续真正用到的时候再看。

![](https://res.cloudinary.com/dypkcf109/image/upload/v1772141739/obsidian/axg8ivpkztour8bstlhj.png)


## 接下来

这个技能接下来最需要做的一件事，是把它真正融入我的工作节奏。一个工具再好，如果不在合适的时机被想起来，也会慢慢被遗忘。我的计划是，每次一个项目到了某个里程碑，第一个想到的就是去跑这个技能，先把草稿存下来，再决定要不要修改和发布。

另外，这个技能的设计思路本身也是可以复用的：把一个重复性的内容创作任务，连同它所需的上下文，一起打包成一个可调用的工具。这个模式我觉得适用于不少场景，不只是写博客。

你有没有在用类似的方式把重复的 AI 任务标准化？或者你在做项目记录的时候，有什么卡住你的环节，欢迎留言聊聊。