AI 真正适合的，不是写博客，而是整理开发过程

为什么我越来越不相信”AI 写博客”这个说法#

大多数关于 “AI 写博客” 的讨论，停留在一个其实没那么重要的问题上：它写得像不像人。

我更在意另一个问题：它能不能稳定地产出一篇能发的文章。这两件事看起来差不多，差距其实非常大。前者只要求在某段文字里读起来像样，后者要求一整篇成稿在事实、结构、元信息、发布约束上同时不出错。从我自己的实际经验看，这两件事之间隔着一条不窄的鸿沟。

所以这篇文章不打算讨论”AI 会不会取代作者”。我想写的是一个被低估了的事实：AI 在博客这件事里最值钱的环节，从来不是创作，而是整理。

开发过程天然就是碎的，但这些碎片本来就能长成文章#

任何一次稍微复杂一点的开发过程，结束的时候手里都会留下一堆零散东西：

• 几条让你卡了半天的报错
• 试错时来回修改的命令
• 一两次”等等这思路不对”的转折
• 几条短小的 commit
• 一些临时判断和当时没记录的 trade-off
• 跟工具或同事来回沟通的片段

这些东西拼起来，其实就是一篇博客的全部素材。博客原料从来不缺，缺的是有人愿意花一两个小时把它们捋成一条叙事线。

人脑知道这些碎片是同一件事，但手工整理它们的成本高得惊人——要回忆、要排序、要剔除噪音、要补背景、要给每段加上”为什么”。多数情况下，写到一半你就放弃了，整件事就这么消化在记忆里。

AI 真正适合做的，是把碎片整理成结构#

让 AI 从零起草一篇有判断的文章，这件事我并不抱太大希望。但反过来——给它一堆已经存在的碎片，让它做归并、抽取、重排和压缩重复——这是它真正擅长的方向。

具体一点说，AI 在博客流程里能稳定承担的事情大概是这些：

• 从一段乱糟糟的会话里提炼出一个清晰主题
• 把同一个意思的若干条记录合并成一段
• 把”做了什么”重排成”为什么这样做”
• 给散落的内容补上章节边界和叙事顺序
• 顺手生成 frontmatter、摘要、tag、slug

这些动作的共同点是：你提供事实，它提供结构。判断什么值得写还是你的活，AI 只是把已经存在的东西组织得更可读。这比”让它从零生出一篇文章”现实得多，也稳定得多。

我现在更愿意把它当成一个会整理开发现场的编辑，而不是一个会代笔的作者。

但整理一旦没边界，AI 就会开始替你编#

如果文章只写到上一节就停，那是一篇生产力宣传稿。我必须紧接着写一句反制：

也正因为它擅长补结构，所以它也特别容易顺手补事实。

这是 AI 在博客流程里最大的风险，远远大过”写得不像人”。它的失败模式不是”写不出来”，而是”看起来什么都写得出来”——而你不仔细对，根本看不出哪一句是从素材里来的，哪一句是它顺手编的。

在博客这个场景里，这种”补全失控”会有几张固定面孔：

• 把猜测写成事实：没读过的源码、没翻过的规范，被它写成”X 引擎的策略是……”
• 拿旧记忆当现状：训练集里某个版本的字段名，被它当成你项目里现在还在用的字段
• 路径和文件名瞎猜：它觉得”应该长这样”的目录结构，可能跟你仓库根本对不上
• tag 命名漂移：你已经在用 JavaScript，它顺手给你写成 JS，下一次又写成 Js
• 时间写错：用 UTC 当日期，结果文章发布日期早了一天
• 元信息字段乱补：发明 schema 里根本不存在的字段，构建时直接报错
• 过度自信的口吻：“显然”、“众所周知”、“规范规定”——这些词是它最常不负责地用的几个

这些问题的共同点是：只要你不主动校验，它默认走最顺的那条路。文章读起来很顺，发布出去很糟。

所以处理 AI 写博客，真正要解决的不是”它写得不够好”，而是”怎么不让它顺手乱补”。

所以我最后要的不是”帮我写完”，而是”按流程推进下一步”#

意识到这一点之后，我对 AI 的预期换了一种形态。

我不再期望它一次产出一整篇成稿，而是要求它在每一步只做当前该做的事。这是从”生成文章”到”流程控制”的切换，区别看着小，实际差很多：

• 先核实事实，再给候选；不允许它一边猜一边写
• 先拟大纲，再等我确认；不允许它跨过对齐直接落盘
• 先聚合现有 tag，再选 tag；不允许它凭语感发明新词
• 先读 schema，再写 frontmatter；不允许它靠记忆补字段
• 先生成正文，再交给我审；不允许它顺手 push

每一步都要可审阅、可中断、可回退。这其实是在用”流程”约束它”补全的本能”——只要每一步范围都很窄，它能犯的错就有限。

这套思路落到工具上，就是把”AI 写博客”升级成”AI 参与博客工作流”。前者是把它当作者，后者是把它当流水线上的某个工位。后者远比前者实用。

我怎么把这件事落成一条可用的工作流#

这一节我才真正写到自己的实践，但篇幅会刻意压短——因为重点不是”我做了哪些细节修改”，而是”这些约束为什么必要”。

我维护着一个叫 blog 的小工具，本质是一份给 AI 的写作 SOP。它经历过若干次翻车，我现在总结下来，真正管用的约束都对应着上一节列出来的某种”补全失控”。挑几条最具代表性的：

先读 schema，不靠记忆写 frontmatter。
最早的版本是给 AI 一份”frontmatter 字段表”。结果是它非常守规矩地照着这份表写——但表里漏掉的字段它就完全不知道存在。后来我改成：每次写文章前，强制读项目里的 schema 文件本身。这样 AI 看到的就是当前真实字段，而不是我手抄过来的、可能已经过期的版本。这条约束防的是拿旧记忆当现状。

先聚合已有 tag，再选 tag。
不加约束的话，AI 每篇文章的 tag 都会按它对当篇文章的”语感”来给。结果就是 JS / JavaScript / Js 同时存在，后台标签云乱成一团。现在的做法是：写文章前先把所有历史 tag 聚合成一个频次表，让它从这个池子里挑，没合适的再新建。这条约束防的是命名漂移。

日期显式用北京时间。
否则它会用 UTC 当日期，文章发布时间能比真实时间早一整天。这条不解释了，直接写死：取当前北京日期，不允许它”自己判断”。这条约束防的是时间写错。

封面图走固定流程，不靠它自由发挥。
直接 fetch 第三方图床的页面会被 403 拦掉。这件事 AI 不知道，每次都会很自信地告诉你”我来下载一张”，然后失败。现在的做法是把”先搜出页面、再 curl 重定向、再下载到固定目录”写成显式步骤，AI 只是按步骤执行，不需要它发挥。这条约束防的是自信地走错的那条路。

每一条都不是”让 AI 更会写”，而是让它更难犯蠢。

这套约束加起来很朴素，但效果是：从”经常有一处莫名其妙的错”，变成”基本一次过”。对我来说这是一条很大的台阶。

结尾：AI 不是作者，更像一个会整理开发现场的编辑#

如果让我用一句话总结对 AI 写博客的态度，我会这样写：

当 AI 被要求创作时，它容易失真；当 AI 被要求整理时，它反而稳定、实用、可复用。

开发过程里本来就源源不断地产生素材，缺的从来不是话题，是组织成本。AI 真正能补上的，正是把这些散落的现场整理成文章的那一段工作——前提是你不要求它扮演作者，而是把它放在编辑的位置上，并且把每一步都收得足够窄，不给它顺手补全的机会。

如果你正打算让 AI 帮你写博客，我的建议是：不要让它”写”，让它”整理”；不要让它”决定”，让它”按流程推进下一步”。剩下的判断，留给你自己。