我的写作流程

AI 能写代码，也能写文章。但有一个现象我一直觉得耐人寻味——社区对 AI 写代码大体是接受的，对 AI 写的文章却评价很低，「AI 味很浓」几乎成了差评的同义词，大家潜意识里更信手写的东西。

作为一个既用 AI 写代码、也用 AI 写文章、并且真的写了不少的人，我承认这个偏见不是空穴来风。创作成本降下来之后，确实涌入了大量参与者，写出很多粗制滥造的内容——社区里的内容数量急剧上升，高质量的比例却急剧下降，读起来处处踩雷，阅读体验非常糟糕，这是事实。Simon Willison 用「slop」描述这类内容，他的定性我很认同：罪不在用了 AI，在于未经审阅就发出去、把评估的成本转嫁给了读者（Simon Willison, "Slop", 2024）。

因此，我想请你先接纳「AI 写文章」这件事本身——它正当、可以做，但得有方法地做。这套方法论可以浓缩成一条动线：定下主题，和 AI 一起收集素材，再由我来定文章的框架结构，最后让 AI 把一个个具体段落写实。 这是三篇文章里的第一篇，先还原我真实写一篇文章的完整流程；第二篇讲怎么把它固化成一条能自己跑的流水线，第三篇讲我个人总结出来的用 AI 写文章的若干最佳实践。

1. 从一个想法到一篇成稿

先还原我真实写一篇文章的完整过程。不是理论上「应该怎么写」，是我坐在电脑前实际走的步骤、每一步和 AI 怎么配。一篇文章从零到成稿，我大致走这么八步，每一步都以上一步的产出为输入；下面逐步展开。

1.1 从一个粗糙想法起步，让 AI 追问着把它想清楚

脑子里冒出个念头，通常还很粗糙、不成体系。这时我启动 Claude Code，把这个想法原样丢给它，让它扮演一个苏格拉底式的提问者，每次只问我一个问题，一问一答地把我想说的东西挖完整。Prompt 大致是这样：

我想写一篇技术文章，但目前只有一个很粗糙、不完整的想法：<把你脑子里那点东西原样写下来，允许含糊>。

请扮演一个苏格拉底式的提问者，帮我把这个想法想清楚：
- 每次只问我一个问题，等我回答后再问下一个，不要一次抛一堆；
- 多从根子上追问——我为什么这么想、这个判断的前提是什么、换个场景还成立吗；
- 目标是把我脑子里那个模糊的念头一点点挖完整，而不是急着帮我组织成文章。

先从你觉得最该先问清楚的那个问题开始。

这里需要注意两个点。其一，一次只问一个：不让 AI 一口气抛出一串问题——那样我只会挑好答的敷衍两句、难的自动跳过；逼成一问一答，每个问题都得当场想、当场答，想法才会被一步步推向更深。其二，只问不答：不让它替我给结论，它一旦开始「我觉得你想说的是……」，产出的就是它的判断，而这一步要挖的是我脑子里那点还没成形的东西——让它当提问者、而不是答题者，才能把我内心深处的想法挖出来。

一轮轮问答下来，那个起初含糊的念头会被逐渐补全、澄清，最终收敛成一个完整、清晰的想法。之后我会把它落成一份种子文档（比如 seed.md）存下来——它既是这一步的产出，也是后面每一步的起点。

1.2 让 AI 调研、收集素材

想法有了，接下来需要尽可能完整地收集这个主题相关的信息：让 AI 联网检索，把相关资料、不同角度、代表性观点乃至反例，尽量多地搜罗回来。这里我对它的要求很明确——只要它收得全，明确不要它帮我筛、帮我拿主意（为什么这么要求，第二篇会讲到）。Prompt 大致是这样：

我要写一篇技术文章，目前的初步想法已经梳理到 seed.md 里，请先读它。

现在围绕这个想法尽可能完整地收集资料，不要帮我做取舍、不要替我拿结论，只管把信息收全：
1. 这个主题下有哪些常见的讲法、角度、切入点，尽量穷举；
2. 业界／社区通常怎么定义相关概念，有哪些代表性观点和反对意见；
3. 有没有反例、边界情况、容易被忽略的坑；
4. 别人写同类主题时，通常怎么组织结构。

结果结构化地写进 research.md，每一条标注来源，便于我后面回溯。

1.3 在素材之上，确立属于自己的核心主题

素材一多，很容易犯一个错：作者自己也抓不住重点，总想着一把梭、把搜来的东西统统写进去。可有必要吗？如果没有你自己的想法，把 AI 推导出来、网上搜罗回来的观点复述一遍，本质上就是咿呀学语——尤其在 AI 时代，这种四平八稳的复述文章，AI 分分钟就能生成一批。真正稀缺、真正值得写下来的，是你自己的判断：这个主题里，有没有一个只有你会这么看的角度？所以素材在这一步的作用，不是让你去里面「找」一个论点，而是给你一个全局视角——看清别人都说过什么、盲区在哪，免得闭门造车重复了前人的话；但要表达的那个观点，终究得从你自己心里长出来。这一步我做的，就是拿素材当参照、往自己内心里反复追问，把那句「我到底想说什么」问出来，落成一句能统摄全文的核心主题（说句实话，你正在读的这篇文章，核心主题就是这么一轮轮问出来的）。追问的 Prompt 我一般这么开：

我想表达的核心大概是：<把你此刻能想到的核心判断写下来，允许含糊>。

请扮演一个尖锐的提问者，不要急着帮我组织，而是连续追问、逼我把它想清楚：
- 这个判断的反面是什么？有没有站得住的反例？
- 我说的「X」，到底指什么？换个说法还成立吗？
- 如果只允许留一句话，这篇文章到底在说什么？

每一轮只问，不替我下结论。直到我能用一句话说清、且这句话能反过来判定哪些点该留、哪些该砍为止。

主题确认后，我会把核心判断、目标读者和讨论范围写进 plan.md，供拟大纲和写正文时读取。

1.4 排主次、搭骨架——定结构

这一步要反复推敲、仔细打磨，它直接决定了文章最终的质量，所以必须由我人工来定，不外包给 AI。具体为什么、怎么做，第 2 节展开。

1.5 让 AI 写具体内容，并反复 review、去 AI 味

结构定下来之后，就可以让 AI 在遵循「写作规范」的前提下，帮我把每一节的具体内容写实。这里的写作规范主要是两份：一份是由 AI 分析范文起草、我确认并持续维护的写作宪法（禁哪些 AI 腔、思想深度要到什么线），一份是机器归纳的偏好清单（这份清单怎么来，第二篇会讲）。塞给 AI 的时候，我盯得最紧的是遵守已确认的大纲——按既定的章节顺序、主次和核心判断展开内容，论据必须来自素材。审稿时可以调整段落组织和详略；若涉及章节顺序、核心判断或讨论范围的变化，先提出建议，交我确认：

读取已确认的主题、素材和大纲，逐节展开成文：
1. 遵守大纲的章节顺序、主次和核心判断，不把次要点扩写成主线。
   若发现大纲需要调整，先提出建议及原因，交我确认后再改。
2. 事实、案例和论据必须来自素材；缺少支撑的标为待补，不自行编造。
3. 全程遵守写作宪法和已确认的偏好，尤其是表达和思想深度要求。

主题：plan.md
素材：research.md
大纲：outline.md
规范：<写作宪法、偏好清单两份文件的路径>

初稿通常还需要反复 review 与修改。审稿时，我先看主次是否清楚、推理是否完整、段落有没有重复，再处理翻译腔、空泛断言和没有信息量的修辞。比如，「使用轻量」与「建设成本高」未必矛盾，要先核对两句话指的是不是同一层面，不能只凭字面判错。

这一步需要投入大量时间和注意力。判断表达是否合适，要结合语境和它承载的信息，不机械删词，也不为了精简省掉必要解释。具体方法与可复用的 Prompt，放在第三篇的审稿与表达部分。

1.6 逐条核事实

每一条技术主张、每一个命令、每一份数据，都要核对；尤其各种技术名称——包名、API、命令、库名、版本号，AI 偶尔会在这些地方出现幻觉。尤其是伪造的包名——AI 幻觉出一个根本不存在的依赖后，攻击者会去抢注这个包名、往里投毒，形成一条活的供应链攻击链路，业界管这个叫 slopsquatting（相关研究：在该研究测试的模型与设置中，生成的包推荐有 19.7% 指向不存在的包；另一项重复实验中，43% 的幻觉包在同一提示的十次重试中均再次出现）。这些我不靠人工逐条看，而是派一个专门的 fact-checker subagent 去核，逐条比对素材库、找不到出处的说法就标「待确认」。关键在于比对的对象是独立的素材库，而不是反过来问 AI「你写得对不对」——让模型自我核实等于没核实。Mata v. Avianca 案就是现成的反例：律师用 ChatGPT 引了六个虚构判例，追问「你确定吗」，模型又编造了一份确认（Mata v. Avianca）。

核这一步我用的 Prompt 大致是这样，重点在于只准跟素材库比对、不准自我背书：

起一个独立的 subagent，把这篇成稿逐条拿去和我第 2 步收集的素材库比对，做一次事实核查：
- 逐条抽出文章里的技术主张、命令、数据、包名／API／库名／版本号；
- 每一条只跟素材库比对，来源确实支持该论断、适用条件一致的标为已核实；与来源冲突的注明差异，追不到出处的一律标「待确认」，不凭模型记忆判定对错，不擅自修改正文；
- 你的角色是防编造的哨兵，不是证伪的实验室——拿不准是不是公开常识，就从严标「待确认」交我拍板。
最后给我一份清单：哪些已核实、哪些与来源冲突、哪些待确认，并附对应依据或缺失原因。

1.7 配图

这一步我写了两个 skill 配合：一个 gen-image，封装对生图接口的调用，给它一段描述就吐一张图；另一个 add-illustrations，负责通读全文、基于内容找出适合配图的位置（流程、架构、复杂逻辑那些光靠文字费劲的地方），再调 gen-image 把图生成、插回对应段落。找图位、出图都交给 AI，我只做最后的取舍——这张图对不对题、要不要留。

这两个 skill 本身也是用 AI 生成的，你可以照着下面两段 Prompt 让它帮你各造一个。先造底层的 gen-image——注意生图走 gpt-image-2 模型，密钥不写进代码、从环境变量读：

帮我写一个 gen-image skill：接收一段文字描述，调用 OpenAI 的图像生成接口画一张图，存成 PNG 到当前目录。要求：
- 模型用 gpt-image-2；接口地址和密钥都从环境变量读取（如 OPENAI_BASE_URL、OPENAI_API_KEY），不要把密钥硬编码进脚本；
- 尺寸可选，默认根据内容排布方向推导（横向流程图用 3:2、竖向分层用 2:3、单概念用 1:1），不要一律用方图；
- 脚本以 JSON 返回结果：成功给出图片路径，失败给出错误原因，便于上层程序判断。

再造上层的 add-illustrations，让它调用刚才那个 gen-image：

帮我写一个 add-illustrations skill：接收一篇 Markdown 文章的路径，通读全文，找出最适合配图的位置（多组件架构、完整流程、方案对比、抽象概念这几类），为每处生成一张插图并插回对应段落之后。要求：
- 生成图片时调用我已有的 gen-image skill，不要自己另写一套调用；
- 每处先产出候选清单（位置、图类型、建议描述、推荐尺寸）让我确认，再动手生成；宁缺毋滥，一篇最多几张；
- 图中所有文字标签用中文；生成的图统一收进文章同级的 images/ 目录、按文章名编号命名；
- 只按文件路径操作图片，全程不要把图片内容读进上下文。

1.8 把偏好喂回系统

定稿之后，我让 agent 回看这篇从初稿到定稿的全部修改，归纳出「这次又暴露了我哪些用词、结构上的偏好」，追加进第 1.5 步用的那份偏好清单。写得越多，这份清单越准，AI 出的初稿就越收敛到我的个人品味，下一篇能提前规避掉更多老问题（它的门槛机制第二篇讲）。

驱动这一步的 Prompt 大致如下，关键是让它归纳出带正反例的具体规则，而不是一句抽象感想：

对比这篇文章的初稿和定稿，把我这一轮做的修改都挖出来，归纳成可复用的写作偏好候选，追加进我那份偏好清单文件：
- 只收「我把 AI 写的 X 改成了 Y」这类真实修改，别凭空发挥；
- 每条规则写成「AI 原文 → 人工改后」的具体对照，并补一句我为什么这么改；
- 和我已有的写作规范去重，已经覆盖的就不要重复记；
- 区分本篇特殊要求与可复用偏好，候选经跨篇验证或我确认后再正式采用。

这一步是整条流水线里最有复利的一环：每一篇的修改都沉淀成下一篇的预防，清单越用越贴合我，也就是第二篇要展开的「越长越准」。

这八步里，第 1.4 步定结构见第 2 节，第 1.5 步的去 AI 味见第三篇，其余都在上面讲了。要补一句的是：这条线是可断点续跑的——每一步的中间产物各存一份文件，哪一步没过，回哪一步重来，前面的成果不用推倒。

2. 为什么定结构不能交给 AI

定结构这一步需要投入大量时间反复打磨，越舍得在这一步花时间，后面返工的风险越低——结构定歪了，正文写得再多也得推倒重来。这不是说要我从零手搭骨架：初稿结构照样由 AI 铺，喂给它前面收集的素材，让它先出一版：

读取已确认的主题规划（plan.md）和素材（research.md），围绕核心判断拟一版结构大纲：
列出章节、标题、各节论点及对应素材，按目标读者安排顺序和详略。
素材不足以支撑的论点标为待补，不为了覆盖素材而增加章节。
将草稿保存到 outline.md，供我 review。
先给一版完整的，不用追求完美，我会在这个基础上继续调整。

只是它铺出来的那版通常问题不少。比较常见的几类：

• 什么都想讲，点铺得又多又平，主次拉不开；
• 相关的点散落在好几节，该合的没合；
• 为了「结构完整」硬凑出承上启下、总结展望这类空架子；
• 顺序常常只是按素材冒出来的先后排，而不是按读者能跟上的动线排。

拿到这版初稿，我一般先让 AI 起一个 subagent 挑一遍毛病，把明显的问题先收掉一轮，再上手细改。用 subagent 而不是让它自己接着改，是图它带着独立视角审，不被前面拟稿的思路锚住：

起一个 subagent，让它换一个挑剔的审稿人视角，独立审一遍这版结构大纲，指出其中的问题：
哪些点主次不分、哪些相关的点散落该合并、哪些是为了凑「结构完整」硬加的空架子、章节顺序是否符合读者的阅读动线。
这是一篇技术文章，重点从「思想深度是否够」这个角度审——每一节有没有停留在罗列现象、缺少往下追问的判断。
（若是实操教程，改为侧重步骤是否可落地、有无缺漏；若是科普，改为侧重表述是否好懂。）

即便让它自查过一轮，仍务必人工 review 一遍：逐个点去掂量该重点讲还是一笔带过、哪些虽然成立但不服务主线因而必须删掉，把散的合并、把顺序按阅读动线重排，一轮轮收敛，直到结构和主题彼此咬合。遣词造句错了，损失是局部的，改一句是一句；结构错了却是全局的，后面每一节写得再好，读者依然拎不清你到底想说什么。而这道人工收敛，恰恰是机器替不了的。

另外，这个 review 的过程，其实也是逼你把想法想得更清楚的过程。我曾以为「想清楚」和「定结构」是先后两步——先把要表达的想清楚，再去搭结构。后来发现不对，它们更像螺旋交织：先搭一个粗结构，把点摆出来，摆的过程会牵出新的想法；想法补上，再回头优化结构；如此反复几轮。因此，结构不只是想法的容器，它还是逼我把想法想清楚的工具。

想法停在脑子里时是抽象、含糊的，落成一份结构大纲，就把它具象成一个个能被端详的点——摆出来之后，哪个判断其实还没想透、哪两个点背后其实是同一个意思，才看得清。所以真正吃功夫的从来不是「列出大纲」这个动作，而是大纲内部的主次、详略、取舍：列出大纲只是把牌摊开，决定文章质量的，是摊开之后那轮删和排。

3. AI 只是降低了写作成本

回头看上面这八步，你会发现一件事：认真写一篇技术文章，该走的步骤，AI 来之前和来之后其实没变——收素材、想清楚、定结构、成文、核事实、去味、配图，一步都不少。AI 动的不是流程，是每一步的成本。

降得最多的，是写作之外的准备与核验。以前为了把一个点写透，我要翻大量文档、啃源码、亲手构造一个 case 去验证、满世界找反例——大量时间花在落笔之前的准备和落笔之后的核验上，真正写字反而是小头。现在这些交给 AI，几分钟到几十分钟就出结果。步骤一样，但每个环节的时间成本大量降低。

但成本降下来，不等于活就干完了。有了 AI，写作确实快，一篇文章几分钟就能出一版，可快的只是「写出一版」，而不是一次性就能生成一篇足够成熟、对读者有启发、真正有价值的文章——反而非常容易出现啰嗦重复、把不相干的点硬凑进来，甚至编出并不存在的事实和引用。这些问题没有「能不能跑」那样的客观裁判替我兜底，只能靠我一句句重度 review 去挑（详见第三篇）。所以成本虽降，投在 review 上的时间反而是省不掉的大头。

也正因如此，人在这条链路里的角色变了：不再是那个从头到尾一字一句敲出来的人，更像是导演加审核——把要讲什么、按什么结构讲定下来，交给 AI 落笔成文，再逐段审它写出来的东西合不合格。写字这件体力活让渡了出去，定方向和把质量关这两件事，仍牢牢攥在自己手里。

当执行成本从几天压到几十分钟，写作的瓶颈就从「执行」上移到了「决策」——想清楚要表达什么、如何组织结构、取舍哪些内容，这些是 AI 无法代为执行的。这与软件开发的演进同理：当编码、查 API、写样板逐步交给 AI，工程师的价值重心便转向架构设计与边界划分。写作也是如此——执行越廉价，人越应当把精力投向结构与思想。

4. 如何进一步提效

上面按手动推进的方式拆解了这八步：每一步都得我记着该做什么、手动把上一步的产物喂给下一步。写得多了会发现，这里面大量环节是重复、可固化的——同一套 Prompt、同一份规范、同一批检查项，每篇都在重来一遍。

既然如此，就可以把它提炼成一条更高效的流水线：让这八步在仓库里自动串起来、每步的产物自动落盘、哪步没过能回哪步续跑，我甚至能把自己的用词偏好持续喂回去、让它一篇比一篇更贴合我的口味。怎么把手工动线固化成这样一套能自己跑的工程，我们下一篇《搭建一套更高效的 AI 写作工作流》继续展开讲。