我现在最稳定的一套 AI 写作工作流：选题、成稿、分发三段式

很多 AI 写作流程的问题，并不在于它们完全无效，而在于它们只在灵感很强、材料很足、你又刚好愿意花很多时间盯着它的时候才好用。它们更像偶尔爆发的技巧，而不是可以接在真实项目推进之后反复运行的系统。对独立开发者来说，这种不稳定成本很高，因为你不是在空白环境里专门写作，你是在产品、工程、部署、内容和发布同时发生的现实里写作。

我现在最信任的一套流程，其实非常朴素：选题、成稿、分发三段式。听起来像常识，但真正稳定感恰恰来自每一段都有不同责任，AI 只在适合它的位置发力，而不是从空白页一路包办到底。

我现在不会再让 AI 从空白页直接“想一个主题并写出来”。因为只要跳过选题层，后面整篇文章很容易变成看似完整、其实没有主线的一般内容。更稳的做法是，先把最近真实发生过的事情记下来：一个构建阻塞、一轮 taxonomy 收口、一次 support pages 改造、一个 release gate 补强、一篇明显太薄的旧文章、一条真实的浏览器 QA 结论。然后我先自己判断：这里面哪些值得公开写，哪些只是过程噪音。

AI 在这一层最适合做的，是聚类、比较和提醒缺口。它可以帮我把几件看起来分散的事情压缩成一个主题簇，也能提示我哪个标题虽然成立，但容易和站内已有文章重复。比如这轮公共博客优化里，我其实不是先决定“要写哪篇 AI 文章”，而是先从真实动作出发：taxonomy 测试、首页 support page 对齐、内容审计、短文补厚、浏览器复验。选题的关键不是标题漂不漂亮，而是它是否真的来自当前工作主线。

进入成稿之后，我现在会尽量把输入压缩成三类材料：

一个明确立场

比如“首页不能继续只是文章流”“教程里 AI 最适合做结构，不适合做观点”“发布门禁必须先锁失败类型”“公共博客内容系统当前更适合轻量 MDX 而不是重型栈”。如果没有这句立场，后面正文只会越来越散。

三到五条支撑点

这些支撑点通常来自真实文件、真实测试、真实 UI 改动、真实构建链路或真实失败方式。也就是说，AI 不是对着抽象命题自由发挥，而是在对已有判断做组织。

少量足够具体的现场材料

比如脚本名、测试名、文件路径、页面结构变化、构建错误信息、浏览器验收观察。这些材料让文章不会滑向泛化教程，也让读者能感觉到这篇文章不是从空白模板里生成的。

接下来 AI 才开始发挥擅长的部分：给出骨架、补齐过渡、压缩重复、做反向提纲。真正让我觉得“稳定”的，不是提示词有多长，而是每一段都知道自己在服务哪条判断。只要这一点成立，返工通常会少很多。

我现在不会把分发理解成文章写完之后随手做的附属动作。相反，它更像最后一道编辑工序。原文写完之后，我通常会再让 AI 把它拆成摘要、站内导语、短帖版本，或者压成一句足够清楚的主命题。这样做不是为了多发几个渠道，而是为了反向验证：这篇文章到底有没有一个真的站得住的核心结论。

如果一篇正文怎么都拆不出一句有力的摘要，问题通常不在分发，而在成稿层还没写透；如果摘要能写出来，但每个版本都像在说不同事情，问题往往更早，说明选题层就没有真正收口。分发层最大的价值，就是把这些结构性问题暴露出来。

我现在会刻意保留“退回上一层”的能力

这也是我觉得这套流程最重要的地方。它不是单向流水线。如果分发层拆不出一句清楚命题，我会退回成稿层；如果成稿层怎么写都发虚，我会退回选题层，重新判断这篇文章值不值得存在。AI 在这里最重要的作用，不是让流程更快，而是让“退回上一层重新判断”这件事成本更低。没有这种退回机制，流程再顺，也只是在更高效地产出一般内容。

因为它把三种完全不同的工作拆开了。选题层负责价值判断，成稿层负责论证和表达，分发层负责验证结构是否真正站住。过去很多不稳定，都是因为这三件事被混在一个 prompt 里，最后模型只能用最熟悉的平均内容模板来兜底。看起来省步骤，实际返工更多。

而三段式把 AI 放回了更合适的位置：它帮助我降低组织和整理成本，但不替我承担主线判断。对于像 MakePlans 这种还在持续推进产品、工程、部署和公共表达的项目来说，这一点尤其关键。因为我真正需要的，不是一篇篇“还能看”的文章，而是一套能稳定把真实工作转成公开表达的流程。

对我来说，这就是稳定感的来源：不是某次突然写得很顺，而是每一层都知道自己该负责什么，出了问题也知道该退回哪一层修。只要这个结构还在，AI 写作就更像一套可维护系统，而不是偶尔灵光的技巧。