做教程内容时，AI 最该承担的是结构，不是观点

很多 AI 写出来的教程有一个共同特征：信息看上去很全，结构也似乎完整，但真正跟着做时总有一种别扭感。原因通常不在语言能力，而在教程这种东西从来不只是知识堆叠。教程的本质是作者替读者做了一轮路径选择：什么必须先讲，什么可以先略过，哪里要提醒风险，哪里要明确告诉读者别走那条看起来也合理的路。

一旦这部分路径判断被交给模型自行决定，文章就会很快滑向平均答案。它会尽量兼顾不同情况，尽量不给出太锋利的结论，尽量把所有方案都说得像能成立。这样写出来的东西也许不算错，但它不再像教程，更像一份被整理过的资料。对读者最有价值的那部分——“在当前约束下到底应该怎么做”——反而会被稀释掉。

在这个项目里，我越来越明确地把 AI 放在结构位，而不是观点位。比如我写公共博客 taxonomy、support pages、Cloudflare 兼容或 release gate 相关内容时，第一步不会让 AI 从空白页直接起稿，而是我先给出一句非常清楚的判断：这篇文章最核心的结论是什么，它要帮助读者避免哪种误判，它应该服务哪类读者任务。只有这一步先由人拍板，后面的结构才有稳定的重心。

接下来 AI 才开始发挥它真正高效的部分。它很擅长检查章节顺序是否跳步，是否漏了前置条件，是否把几个不同层级的问题混写在一起，也能快速把一堆零散材料整理成更像教程的骨架。比如一篇工程教程可能天然要包含：背景、边界、失败方式、推荐顺序、验证步骤；一篇内容系统文章可能需要：为什么要这么做、当前约束是什么、为什么不用另一种方案、未来何时值得升级。让 AI 帮我先把这种结构搭稳，是非常划算的。

我越来越认同一个简单划分：结构工作适合给 AI，观点工作必须留在人。原因不复杂，结构出问题会带来阅读成本，观点出问题会带来判断成本。前者可以通过反向提纲、段落调整、章节重排不断修；后者一旦错了，读者会直接被带偏，而承担后果的是作者的信誉，不是模型的概率输出。

我现在最常让 AI 做的，是三类结构动作

第一类是章节排序。它能提醒我是不是把读者真正关心的问题放得太后，或者一上来就掉进实现细节，忘了先交代为什么这件事重要。

第二类是缺口检查。比如我在写 release gate 或 Cloudflare 兼容时，AI 很容易指出：你提到了 build:cf，但还没解释为什么 next build 通过仍然不等于可发布；你提到了 proxy 问题，但还没交代最后为什么要把 redirect 和安全头迁到 next.config.mjs。

第三类是反向提纲。文章写完之后，我经常会让 AI 再把现成正文压成骨架，看每个 ## 小节到底在回答什么问题。如果骨架提取出来以后发现几段都在说同一件事，说明结构还没真正成立。这一步对教程尤其有用，因为教程最怕“看起来每段都通顺，实际上没有一步真正带着读者往前走”。

这个项目里很多值得写的内容，其实都带有非常明确的现场约束。比如公共站首页为什么不能继续只是文章流，support pages 为什么不能像另一套设计系统，Cloudflare / OpenNext 构建为什么会被 proxy/middleware 直接卡住，release gate 为什么必须把 smoke、full test、build 和文档 checklist 分层处理。这些问题都不是普世模板问题，而是“在这个项目当前结构和当前目标下，什么更成立”的问题。

这种判断一旦让 AI 来代做，就很容易变成一套漂亮但没有现场的教程。它会自动回到通用最佳实践、行业常识或泛化建议，而不是把问题压回真实文件、真实脚本、真实失败方式。教程于是会越来越像百科，而不是一个真的做过这件事的人留下来的路径说明。

我并不觉得这会让写作变慢。恰恰相反，先把责任边界划清之后，返工通常更少。AI 负责把路搭出来，保证结构不散、节奏不乱、前提条件没漏；人负责决定到底往哪边走、为什么这么走、哪条路虽然也能解释但不该在当前阶段推荐。这种分工一旦成立，教程会更像真实经验的整理，而不是一次“请模型帮我写完”的委托。

对我来说，教程写作真正需要的从来不是更会说话的模型，而是一套更清楚的职责分工。AI 负责结构与校对，作者负责经验、取舍和后果。只有当这条线划清，教程才会从“信息像很多”变成“真的能带人走完一条更可靠的路径”。