我一直觉得，“让 AI 写博客”和“让 AI 真正参与我的写作流程”其实是两回事。

前者现在已经不难了。给一个主题，模型通常都能很快生成一篇结构完整、逻辑也过得去的文章。但真正用下来，我总觉得差一点。问题往往不是内容完全不对，而是它不太像我会写出来的东西。语气不够自然，重点不够稳定，结构也未必符合我真正想要的节奏。更麻烦的是，每次写新文章时，我都要重新告诉它一遍：先别急着写全文，先给我几个风格选项；先出标题和大纲，我确认后再继续；中间如果细节不够，就继续问，不要直接补全。

说到底，我缺的不是一个“会写文章的 AI”，而是一个知道该怎么和我配合写文章的助手。也正因为这个原因，这次我没有继续把精力放在“怎么写出一篇更像样的博客”上，而是换了个方向，直接用 Codex 给自己做了一个 blog 写作 skill，把这些平时反复重复的要求沉淀下来。

从“会写”到“会配合”

我一开始就把这个 skill 的目标收得很窄。它主要是给我自己用的，后面也可能公开到 GitHub；内容上聚焦技术教程类博客，默认中文，主要面向独立博客的写作场景。更重要的是，它的工作方式不能是“你给我一个题目，我直接吐你几千字”，而应该是先协助我把文章的方向定下来。

对我来说，一个更理想的流程应该是这样的：先给我几种可选的语言风格，再给一个推荐标题和几个备选标题，然后先出大纲，等我确认结构和深度之后，再沿着大纲逐段往下写。写到中途如果有关键细节不明确，就继续问，而不是靠猜把内容补满。最后，除了正文，它还应该顺手把标题、关键词、slug 和 description 这些博客发布时真正会用到的内容一起准备好。

真正开始做的时候，我先和 Codex 一起把这些规则整理清楚。现在回头看，这一步比我原来想的还要重要。因为只要规则没说清楚，后面无论写多少内容，本质上都还是在一遍遍重复临时沟通。我当时最明确的几件事是：这个 skill 只做 blog 写作，不去泛化成万能文案助手；默认应该先出大纲，而不是直接出全文；风格不能靠一句“写自然一点”来模糊控制，而要明确给出几种选项和短示例；如果信息不够，就要优先追问，而不是把模糊内容写得看似完整。还有一点也很关键，就是它不只负责正文，而要把博客发布真正需要的元信息一起纳入流程。

把流程落成一个真正的 Skill

方向定下来之后，我就在本地文件夹里把这个想法做成了一个真正的仓库。因为后面打算公开到 GitHub，所以我没有把它当成一次性的 prompt，而是按一个可以维护的项目来处理。整个结构其实不复杂，核心文件就是 SKILL.md，里面定义了这个助手的默认行为、交互顺序、输出格式，以及在不同阶段应该怎么提问、怎么继续推进。除此之外，我补了一个简单的 README.md、一个最小的 .gitignore，然后做了第一次提交，把它固定在一个干净的起点上。

真正让我觉得这件事开始变得“有意思”的，不是仓库搭起来了，而是我发现，原来自己过去那些看起来很凭感觉的写作习惯，是可以被明确写成规则的。比如默认中文、默认独立博客场景，比如先给风格选项和标题建议，比如先确认大纲再继续正文，比如中间要允许多轮确认。这些东西过去都只是我脑子里模糊的偏好，但一旦被写进 skill，它们就变成了一套可以重复使用、也可以持续优化的方法。

真实样例，才会暴露真正的问题

不过，规则写出来只是开始。一个 skill 到底好不好用，不能只看文件本身写得多完整，而要看它在真实任务里会不会暴露问题。所以接下来我没有继续往里面堆很多“看起来很丰富”的功能，而是直接拿它跑了一篇真实文章，主题是 C++ 标准库中的 std::map 详解。

这个过程基本就是按照 skill 预设的流程在走：我先给主题、读者、篇幅和目标，它先给风格选项、标题建议和大纲；我确认方向之后，它再开始往下写正文。这个过程最直接的收获，就是让我更确信 outline-first 真的很有必要。因为技术文章一旦结构偏了，后面越写越难改，而先看大纲，很多问题其实在正文开始之前就能发现。

但更有价值的是，这个真实样例很快暴露出了 skill 还不够好的地方。比如那篇 std::map 文章第一版的内容其实没大问题，结构也完整，但后半部分的表达明显有一种“太规整”的 AI 痕迹，句式偏平均，转折也偏机械。这种问题如果只看规则，很难提前意识到；只有真正把文章写出来，再自己顺着读一遍，才会立刻感觉出来。于是我又反过来继续用这个助手去润色那篇文章，让它从“结构正确”往“更像自然博客”靠近。也正是这个来回调整的过程，让我越来越确定，一个真正可用的 blog 写作 skill，并不是为了第一次输出就完美，而是为了支持这种持续协作和逐轮修正。

这次搭建之后，我真正得到的东西

做到这里之后，我最大的感受反而不是“我用 Codex 写出了两篇文章”，而是“我开始把自己的写作方式做成了一套能复用的系统”。这两件事听起来很像，实际差别很大。前者更像一次性的效率提升，后者更像是在搭一个长期工作流。对我来说，后者才是更有价值的部分。因为我真正需要的，从来不是一个偶尔能写出像样文章的模型，而是一个越来越懂我怎么写、也越来越懂该怎么和我配合的助手。

如果要总结这次搭建最值得保留的经验，我觉得核心其实只有一条：好用的写作助手，重点不是生成能力本身，而是流程设计。风格要先定，大纲要先过，中间要允许确认，最后要补齐发布信息，这些东西单独拿出来都不复杂，但组合在一起之后，才真的构成了一个“能长期用”的 blog 助手。也正因为如此，我后面还会继续迭代它，但方向不会是盲目加功能，而是继续拿真实写作样例去反推它哪里还不够顺手。比如以后我可能会补更多风格模板、更多技术文章骨架，或者针对不同平台做一些轻量适配，但前提都一样：它得先在真实写作里证明自己有用。

如果以后我真的把这个仓库公开到 GitHub，我想最值得分享的，可能不是某一段提示词，而是这整个思路本身。不要只想着让 AI 替你完成任务，也可以试着把你做事的方法交给它，让它慢慢学会按照你的方式来协作。等这种方法真正沉淀下来之后，它带来的帮助，往往会比单次生成一篇文章更长久。