如何用 AI 写技术文章

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

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

因此，我想请你先接纳「AI 写文章」这件事本身——它正当、可以做，但得有方法地做。这套方法论可以浓缩成一条动线：定下主题，和 AI 一起收集素材，再由我来定文章的框架结构，最后让 AI 把一个个具体段落写实。 下面我会结合自己的写作经验，详细展开如何借助 coding agent 把这条动线落成一套流程化、工程化的高效协作方案。

1. 我的写作流程

先还原我真实写一篇文章的完整过程。不是理论上「应该怎么写」，是我坐在电脑前实际走的步骤、每一步和 AI 怎么配。

1.1 从一个想法到一篇成稿

一篇文章从零到成稿，我大致走这么八步，每一步都以上一步的产出为输入：

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

   我想写一篇技术文章，但目前只有一个很粗糙、不完整的想法：<把你脑子里那点东西原样写下来，允许含糊>。
   
   请扮演一个苏格拉底式的提问者，帮我把这个想法想清楚：
   - 每次只问我一个问题，等我回答后再问下一个，不要一次抛一堆；
   - 多从根子上追问——我为什么这么想、这个判断的前提是什么、换个场景还成立吗；
   - 目标是把我脑子里那个模糊的念头一点点挖完整，而不是急着帮我组织成文章。
   
   先从你觉得最该先问清楚的那个问题开始。

   这里需要注意两个点：

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

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

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

   我要写一篇技术文章，目前的初步想法已经梳理到 seed.md 里，请先读它。
   
   现在围绕这个想法尽可能完整地收集资料，不要帮我做取舍、不要替我拿结论，只管把信息收全：
   1. 这个主题下有哪些常见的讲法、角度、切入点，尽量穷举；
   2. 业界／社区通常怎么定义相关概念，有哪些代表性观点和反对意见；
   3. 有没有反例、边界情况、容易被忽略的坑；
   4. 别人写同类主题时，通常怎么组织结构。
   
   结果结构化地写进 research.md，每一条标注来源，便于我后面回溯。

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

   我想表达的核心大概是：<把你此刻能想到的核心判断写下来，允许含糊>。
   
   请扮演一个尖锐的提问者，不要急着帮我组织，而是连续追问、逼我把它想清楚：
   - 这个判断的反面是什么？有没有站得住的反例？
   - 我说的「X」，到底指什么？换个说法还成立吗？
   - 如果只允许留一句话，这篇文章到底在说什么？
   
   每一轮只问，不替我下结论。直到我能用一句话说清、且这句话能反过来判定哪些点该留、哪些该砍为止。

4. 排主次、搭骨架——定结构。 这一步要反复推敲、仔细打磨，它直接决定了文章最终的质量，所以必须由我人工来定，不外包给 AI。具体为什么、怎么做，下一节展开。

5. 让 AI 写具体内容，并反复 review、去 AI 味。 结构定下来之后，就可以让 AI 在遵循「写作规范」的前提下，帮我把每一节的具体内容写实。这里的写作规范主要是两份：一份是我手写的写作宪法（禁哪些 AI 腔、思想深度要到什么线），一份是机器归纳的偏好清单（这份清单怎么来，后文会讲）。塞给 AI 的时候，我盯得最紧的是不许它动结构——章节的顺序、主次、每节的核心判断都已经定好，它的任务只是把内容写实、把论据补足：

   读取我上一步定好的大纲文件（比如 outline.md），逐节展开成文，严格遵守两点：
   1. 只写内容，不动结构——章节的顺序、主次、每节的核心判断都已经定好，你的任务是把每一节写实、把论据补足，不许新增章节、不许调整顺序、不许把某个次要点扩写成主线。
   2. 全程遵守我这两份写作规范文件（写作宪法 + 偏好清单，路径见下），尤其是里面标注的 AI 腔禁令和思想深度要求。
   
   大纲：<你上一步存下的大纲文件路径>
   规范：<写作宪法、偏好清单两份文件的路径>

   但初稿一定还有 AI 味，这一步真正的重头戏不在「写」，而在写完之后的反复 review 与修改——一遍遍读、一处处抠，把机器腔改回人话。这是整个流程里需要投入最多时间和注意力的步骤，具体怎么改我放到第三部分深讲，这里先把最常遇到的几类问题列出来：

   • 空泛的断言：没有主语的伪权威（「有一种直觉认为……」），以及「X 是起点 / 是关键 / 是核心」这类宏大而空洞的判断。
   • 翻译腔：英译中直接搬过来的句式，比如「理解了 X，再看 Y 就顺了」「这也说明 / 这恰恰印证了……」「是在做 X，而不是做 Y」。
   • 自媒体腔：靠卖关子、情绪煽动提气的包装，比如「这不是白拿的」「这笔账得算清楚」。
   • 耍小聪明：为对仗而对仗、需要读者停下来解码的俏皮话。
   • 套话词：核心价值、关键要点、显然、值得注意——出现即删。
   • 过度比喻和生造词：和技术没有实质对应关系的形象比喻（「给反熵地基浇混凝土」「拆墙／物理墙」），以及临时自造、不通行的缩略词（「搭仓」）——AI 爱靠这些充「生动」，删掉，直接说那件技术事实本身。
   • 后置判断句式：把结论吊在句尾的「X，是故意的」「不是 A，是 B」，是英译中的直译习惯，中文不自然。改成判断前置、事实跟后。
   • 口语词没升级：承载论证的正文主干里混进随手的白话（「真的快」「这里要提醒一句」「极易跑偏」），该换成平实准确的书面表述（「确实快」「需要注意的是」「极易偏离预期」）；旁注里的口语不受此限。
   • 同一判断换措辞重说：一个已经成立的判断，在后文换个说法再讲一遍——这是全篇最高频的冗余。发现某段推导只是前文某句的同义改写，直接删，别留两处等价表达。
   • 段落内的微观结构：一整段读下来重复啰嗦、或前后自相矛盾。比如一段里「这个方案很轻量」开头、结尾又补一句「实现起来其实挺重的」，自己打自己；或者同一层意思在段内颠来倒去说了三遍。这本质也是结构问题，只是尺度落在段落内部——成文之后要专门盯一遍：每段是不是只讲清一件事、有没有句子在原地打转、有没有前后掐架的表述。

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

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

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

这条动线里，第 4 步定结构、第 5 步的去 AI 味各有专节（定结构见下一节，去 AI 味见第三部分），其余都在本节讲了。要补一句的是：这条线是可断点续跑的——每一步的中间产物各存一份文件，哪一步没过，回哪一步重来，前面的成果不用推倒。

1.2 为什么定结构不能交给 AI

定结构这一步得实打实砸时间，而且越舍得在这儿花，后面返工的风险越低——结构定歪了，正文写得再多也得推倒重来。要说清为什么，得先纠正一个容易有的误会：定结构不等于我从零手搭骨架。初稿的结构照样是 AI 给的——我把素材和想法丢过去，它很快能铺出一版章节安排。问题在于，这版初稿几乎从来不能直接用。AI 生成的结构有几个稳定的毛病：什么都想讲，点铺得又多又平，主次拉不开；相关的点散落在好几节、该合的没合；为了「结构完整」硬凑出承上启下、总结展望这类空架子；顺序上也常常只是按素材冒出来的先后排，而不是按读者能跟上的动线排。

而结构一旦有问题，是全局性的——它决定读者顺不顺得下来、抓不抓得住重点。遣词造句错了，改一句是一句，损失是局部的；结构错了，后面每一节写得再漂亮，读者依然拎不清你到底想说什么，是一篇废稿。所以拿到 AI 那版初稿之后，真正吃功夫的是后面那道人工 review：逐个点去掂量该重点讲还是一笔带过、哪些虽然对但不服务主线所以要狠心删掉，把散的合并、把顺序按阅读动线重排，一轮轮收敛，直到结构和主题彼此咬合。这道删和收敛的活，才是定结构真正的重量所在，也正是下面要讲的、机器替不了的那部分。

这里还有一层，是我自己以前也没想透的。我曾以为「想清楚」和「定结构」是先后两步——先把要表达的想清楚，再去搭结构。后来发现不对，它们更像螺旋交织：先搭一个粗结构，把点摆出来，摆的过程会逼出新想法；想法补上，再回头优化结构；如此反复几轮，谁先谁后取决于当时的题目和素材成熟度。结构不只是想法的容器，它还是逼我把想法想清楚的工具。一堆点摆成骨架之后，哪里虚、哪个点撑不住、哪两个点其实该合并，一眼就现形了。想得含糊的地方，会在搭结构这一步集中暴露出来——这也是为什么这道 review 不能省：省了它，等于把「想清楚」这一关一起跳过了。

这也是我想和「outline-first」拉开的地方。业界讲先列大纲防止 AI 从头到尾自行发挥的很多，这没错，但那讲的是列大纲这个动作；我想讲的是大纲内部的功夫——主次、详略、取舍。列出大纲只是把牌摊开，真正决定文章成色的，是摊开之后那轮删和排。

说到这，这篇文章的题眼也就出来了：框架是我的，血肉可以让 AI 丰富。 为什么框架这一步的删和取舍非我不可？因为 AI 的强项恰恰在这里变成短板。它擅长「想全」——给个主题就能铺得面面俱到，每个点都展开，这是天赋。但写文章要的不是全，是重点，面面俱到就等于没有重点。让它铺初稿正是借这份「求全」的天赋，可紧接着的删繁就简，它做不了。

更进一步，这件事原理上就喂不过去。抓重点、删冗余靠的是一个判断——「什么更重要」——而这个判断没有客观答案，它是我的判断，不是能塞进 Prompt 的参数。你可以在 Prompt 里让 AI「只讲三点」，但「哪三点值得讲」这个裁量，是你脑子里那把没有客观刻度的尺子在量，给不出去。所以「减」这件事无法外包，不是 AI 现在还不够强、给足标准就能算——是原理上不能。

这直接决定了定结构那一步的 Prompt 该怎么设计。我绝不让 AI 提几个结构方案让我挑——那等于把「减」这个动作交还给了 AI，让它替我定重点。我让它做的，是把料摊全成一张备选清单，用它「求全」的天赋把牌全摊到桌面上；然后我在这张清单上抓重点、砍冗余、搭骨架。

基于前面调研铺出来的所有料，帮我把这篇文章「可能讲的点」穷举成一张备选清单：
每一个可以展开的角度、每一条素材、每一种讲法、别人组织同类主题的不同结构，都单独列一条，尽量全，宁多勿漏。

注意：不要帮我排主次、不要帮我挑哪些该留、不要给我一个你认为最好的大纲方案。
你的任务只是把牌全部摊到桌面上，出哪张牌、怎么排，我自己来。

向 AI 要的是穷举与铺陈，重点由我来定。这就是「加」和「减」的分工在流程里最具体的落地。

1.3 AI 没改流程，只把成本打到了地板

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

变得最狠的，是那些「写作之外」的执行活。以前为了把一个点写透，我要翻大量文档、啃源码、亲手构造一个 case 去验证、满世界找反例——大量时间花在落笔之前的准备和落笔之后的核验上，真正写字反而是小头。现在这些活 AI 替我干，几分钟到几十分钟就出结果。步骤一样，每一格的耗时被压没了。

成文也快了，但我得说句实话：AI 铺初稿确实快，几分钟给我一版。可快的只是「铺出一版」，不是「审成一篇我敢署名的」。前面说过，文章没有「能不能跑」这个客观裁判，成稿仍然要我一句句重度 review（详见第三部分）。所以这一步的准确定性是：执行提速，把关不省。

由此推出一个我认为很重要的结论：执行成本从几天压到几十分钟之后，瓶颈自然回到了最上层那件机器省不掉的事——想清楚、排主次、狠取舍。这和写代码是同构的：当敲代码、查 API、写样板都被 AI 接管之后，程序员就该把注意力挪到「架构怎么分层、边界划在哪」上。写作一样——执行越廉价，人越该把心力压在结构与思想上，而不是继续纠结遣词造句。既然这层值得投入注意力，那它就值得我为它专门搭一套工程。这就交棒到第二部分。

2. 把写作过程工程化

第一部分那条动线，目前还只长在我脑子里和手上——每次写文章，都要我亲自记着走到哪一步了、亲自把上一步的产物递给下一步。这一部分讲怎么把它固化成仓库里一条能自己跑、能断点续跑、能自己越长越准的流水线。

我先讲地基（第 1 节，为什么要一个本地仓库），再讲这条线本身（第 2 节），最后补线上两个最该亲手造的部件（第 3 节）。这里要先打个招呼：第 3 节给的不是成品。我不会把自己那份 learn-style、article-scorer 的文件贴给你——那是我的私货，未必合你的口味。我给的是「当初我让 AI 造出这个部件的那段指令」，你复制它，长出属于你自己的同款能力。

2.1 为什么写作要用一个本地代码仓库

这一节篇幅刻意压短——它逻辑很重，但不该铺细节。压短本身，就是在自我应用第一部分讲的「主次分明」。

第一个理由是，只有这样 agent 才进得来。公众号后台、Notion、各类富文本 CMS，本质都是给人用的 GUI——agent 进不去、读不顺、也改不动。而纯文本的 md／mdx 加上文件系统，正是 coding agent 的原生工作面：它能读全上下文、能跨文件改、能顺手跑工具。第一部分说「让 AI 填血肉」，可 AI 要真能干活，先得有一个它进得来、改得动的工作面——local repo 就是这个前提。

第二个理由是，流水线和资产才有地方长。第 2、3 节要讲的编排引擎、写作宪法、偏好清单、各阶段的 skill 与 agent，这些东西要能版本化、能被 agent 反复读写，就得有地方住下来。local repo 是它们的物理地基——没有它，后面那套「自生长」无处生长。

顺带一提，「个人博客是内容的家、公众号只用来引流」这个我一直信的判断，其实是上面两条的一个推论：所谓「家」，就是这个可沉淀、可迭代、还能自证清白（有编辑历史、版本记录）的本地载体。公众号能带流量，但写作体验和阅读体验都太差，只配当引流渠道。

最后是一条诚实的边界，我不想神化它。这套活法是有门槛的——你得会 git、会用 coding agent、能容忍纯文本工作流。对不写代码的创作者，它并不友好。所以我把话说清楚：这是给已经在 repo 里工作的技术创作者的一种活法，不普适。如果你不是程序员、命令行也不熟，我更建议用 Codex 桌面端——它把仓库操作包进了图形界面，门槛低不少；Claude Code、Codex 命令行版本当然也都能干这套活。

2.2 把流程固化成一条能自己跑的流水线

整条线的入口是一条命令：/write-article。

它的核心设计，是一个编排引擎统领全局。这个引擎自己不写正文、不核事实、不打分、不去味，它只做四件事：推进阶段、给各阶段部件传参、在关键处卡住等人工拍板、判断要不要回退。真正干活的，是它调起来的一个个专项部件。引擎唯一亲自动手的事，是读写一份 state.md 记录「现在走到哪了」——正是这份状态文件，让整条线可以断点续跑。

这些部件分两类，这个分法是整条线的关键设计：

一类是 skill，跑在主上下文里，负责「按固定流程产出或改写一份文件」这种确定性工序——比如 research、plan-article、gen-outline、add-illustrations，以及那个去味改写、直接落盘覆盖原文的 review-article skill。

另一类是 subagent，各自开一份隔离的上下文，负责「需要独立判断、且不该污染主上下文」的重活——比如 article-writer-pipeline、fact-checker、article-scorer，以及那个只读审查、只出问题清单不改文件的 review-article agent。

为什么重活全交给 subagent？因为一篇长文要塞进大量素材、规范、历史 diff，如果全堆在主上下文里，引擎很快会被噪声淹没、判断力下降。把写作、核查、打分、审查各丢进一个独立 subagent，各自带着自己那摊上下文干完活、只吐回一份结构化结论——主上下文始终保持干净。这不是为并行而并行，是用上下文隔离换判断力。

（这里有个容易踩的坑先提醒一句：review-article 这个名字下同时挂着一个 skill 和一个 subagent——skill 负责改写落盘，agent 负责只读出清单，同名不同物、职责相反。别搞混。）

整条线的全貌是这样：

逐阶段看一遍它吃什么、干什么、吐什么：

阶段 0 · 调研。 吃一个主题加一堆散落的一手素材，把它们收敛、脱敏、结构化成 evidence.md，作为后面所有事实的唯一可追溯来源。它对应第一部分的「收素材」，但多做一件事——每条素材都标出处，供后面的核查回溯。素材分两级：一手的（我亲历的）是主干；泛化知识点（业界怎么定义、别人的方案长什么样）一手给不出，这一步上网搜进来，标成「外部参考」、带上来源、和一手素材物理分开。判据很简单：一手能覆盖的就不搜。之所以放在这一步而不是拖后，是因为写作时任何论断都要能溯源到 evidence，外部知识不在这步进来，后面就进不了唯一可信源。全自动。

阶段 0.5 · 规划定主题。 吃 evidence.md，在素材之上确立核心主题、排出骨架的重心，产出 plan.md。这就是第一部分那个「想清楚 × 定结构」螺旋的工程化落点——引擎会把核心主题单独拎出来盯着，它一偏，后面全白写。这一步也上网，但只做两件事：验证与查重。搜官方文档核对已有事实、补可引用的生态数据，再搜同主题的优质文章看别人怎么写、好定一个差异化的角度。来源写进 plan，只用公开来源。

阶段 1 · 大纲。 吃 plan.md，产出 outline.md——一份脑图式的结构稿，跟你现在读的这份文章的同类产物长得一样。它内部自带一道 review：初稿生成后，换两个正交视角自查——一个代入读者问「我读得懂吗」，一个拿核心主题去问「这一节是在支撑它、推论它，还是在划它的边界」。让同一个模型拿同一套标准查两遍，只会自我确认；换视角，才逼得出真问题。打磨完，撞上第一个人工卡点。

G1 · 人工拍板大纲方向。 引擎在这里停住，等我。方向对了就放行；核心主题偏了、重心错了，就回退重来。这一关留给人——结构层的取舍不外包，这是第一部分那句题眼在工程上的落地。

阶段 2-4 · 写作、核查、审查、评分。 这是一个内部自驱的回退循环，四步全跑在独立 subagent 里：article-writer-pipeline 吃 outline + evidence + plan 铺出初稿；fact-checker 逐条比对 evidence.md，揪出对不上来源的说法；review-article agent 按写作宪法只读审查、只吐一份问题清单；article-scorer 按五个维度加一道思想深度硬 gate 打分。四项判据（总分、风格、深度、事实）任意一项不过，就把各家的问题汇成一张清单打回去重写，最多跑几轮，要么全过、要么硬停。这四步引擎自动流转、人不介入，也是整条线上 review 最密集的一段。

阶段 5 · 配图。 吃定稿正文，在合适的位置补 Mermaid 图或示意图，产出可发布的成品。全自动，产出后撞上第二个人工卡点。

G2 · 人工验收终稿。 我签字才算定稿；不满意就回退。这一关也留给人——终稿署的是我的名字，最后一道门只能我自己把。

这条线里有三条串联机制，我觉得值得单独点出来：

其一，产物即接口。每个阶段吃上一阶段吐出来的文件、吐出下一阶段要吃的文件——evidence.md → plan.md → outline.md → article.md。阶段之间只靠文件耦合，这和第一部分那条手工动线完全同构。流水线不是另起一套东西，它就是把我脑子里那套手工流程原样固化下来。

其二，state.md 记账，所以能断点续跑。每推进一步就更新状态，哪一步没过，回那一步接着跑，不用从头再来。

其三，多层 review，机器兜底、人守内核。大纲阶段的正交视角 review、写作循环里的三道机器关、G1／G2 两处人工卡点——机器负责把「事实错、AI 腔、深度不够」这类有客观判据的问题反复筛掉，人只在两个判据主观的地方出手：大纲方向对不对、终稿认不认。

除了主线，还有一条更重的 review 支线。定稿之后如果我还嫌 AI 味重，会单独走一遍 deai-review-article 循环——让 Claude、Codex、deepcode 三个不同厂商的引擎并行 review（各出各的清单、都不改文件），汇总去重之后统一改写、再打分，循环到达标为止。它不在主线里，是发布前的一道可选加强关。为什么要三个引擎？因为多引擎交叉，比单模型自查更能兜住盲区——同一个模型的偏见，它自己是照不出来的。

2.3 给流水线补两个关键部件

上一节那条线是骨架，每一步具体拿什么标准干活，靠的是嵌在线上的部件。这一节补分量最重的两个：一个喂给写作阶段，一个挂在回看环节。各给一段可直接复制的「造 skill 的元 Prompt」；其余部件思路一致，末尾带过——真要一个个展开，就正好犯了本文要批的那个毛病：求全，等于没重点。

第一块是双层风格系统，嵌在写作阶段，决定 AI 按什么标准填血肉。它其实是两份东西：一份手写的写作宪法（我对「什么是好文章」的硬规矩——禁哪些 AI 腔、思想深度到什么线），加一份机器归纳的偏好清单（历次手改沉淀成的、更细的用词与结构偏好）。

为什么要分两层？因为内核（什么算好、什么算深）没有客观答案，只能人守，所以宪法必须手写、不许机器改；而细枝末节有大量真实的 diff 可以学，交给机器归纳最省力。下面这段元 Prompt，是当初我让 AI 帮我把这套结构搭出来的——复制它去生成你自己的宪法，不是我的：

我要在这个仓库里建立一套「写作风格」资产，分两层，帮我把骨架搭出来：

1. 一份手工维护的「写作宪法」（writing-style.md）：这是我对「什么是一篇好技术文章」
   的硬规矩，只由我手写、不允许机器改写。先帮我起一个空骨架，分这几节：思想深度要求、
   遣词造句禁令、过渡与衔接、标题规范、自检清单。每节先留标题和一句说明，具体条目我自己填。

2. 一份机器归纳的偏好清单（learned-preferences.md）：从属于宪法、不覆盖它。帮我设计它的
   格式——每条规则要能记录：规则名、类型（用词/结构/过渡/标题）、证据（「AI 原文→人工改后」
   的真实对照 + 原因）、首见/近见日期。并划出三个区：已确认（稳定偏好）、候选（未达门槛）、
   观察池（单次出现）。先把文件模板和字段说明写出来，条目留空。

只搭结构、写清楚每个字段是干什么的，不要替我编造具体规则。

第二块是偏好归纳流水线（learn-style），挂在回看环节，是我这套东西里全网最没成型的差异化。它是一个 skill，回看某篇从初稿到定稿的全部修改，归纳出「这次暴露了哪些偏好」，然后带着晋升门槛追加进那份偏好清单——跨文章复现、够次数了才「毕业」进已确认区，一次性的随手改只进观察池。

为什么非要门槛？因为没有门槛，机器会把我某次心血来潮当成稳定偏好，越学越偏。有了门槛，它只固化那些「反复出现、跨文章都成立」的部分——这是整套自生长「越用越准」而不是「越用越飘」的关键。造它的元 Prompt：

帮我写一个 skill（放在 .claude/skills/ 下），叫「学习我的写作偏好」，做这几件事：

输入：一篇文章的修改记录（git diff，或我提供的「AI 原文 vs 我改后」对照）。
任务：
  1. 逐条比对改动，判断每处「我为什么这么改」，归类成 用词/结构/过渡/标题 之一。
  2. 把每条候选偏好写成结构化条目：规则描述、类型、证据（原文→改后 + 原因）、日期。
  3. 关键——带晋升门槛：一条偏好必须「跨 ≥2 篇文章复现、且累计出现 ≥3 次」才能写进
     learned-preferences.md 的「已确认」区；没达标的进「候选」区；只出现一次的进「观察池」。
  4. 追加时先检查是否已有同类条目，有就更新次数、不要新建重复条目。

约束：这个 skill 只归纳「细节偏好」（用词/结构/过渡/标题），绝不改动 writing-style.md
里的思想深度等内核规矩——内核只由我手工维护。每次写入单独成一个 git commit，方便我 revert。

这里藏着一个我认为很关键的分层判断：细枝末节让机器学，内核只让人守。你翻一遍我那份偏好清单里的所有规则，会发现它们的类型全是「用词／结构／过渡／标题」，没有一条是「思想深度」。这不是偶然——思想深度这一层，我没交给机器归纳，而是一方面写死在手工宪法里，另一方面做成一道独立的硬 gate：打分不是五维凑够 80 就行，思想深度单独一维、单设硬门槛，本质、代价权衡、边界各自达线，不达标一票否决，不许拿其他维度填平。为什么这么设计？因为深度不是词句级的 diff 能提炼出来的，它是「这篇到底想没想透」的整体判断——这种判断机器学不会，只能靠一道人定的门禁兜住下限。自生长学细节抬上限，硬门禁守内核兜下限，是一对搭档。

其余的部件，我只按环节点到，不逐个展开——列在这里，是想让你看到一条线上能挂多少东西：事实核查（只跑只读命令、拿正文逐条比对素材库，找不到出处的标「待确认」而非「错误」，专防 slopsquatting 那类幻觉包名）；去 AI 味的多引擎支线和大纲的正交 review（上一节已讲，此处只归位）；偏好归纳的自我迭代循环（除 learn-style 外还有一层编排，定期评测定基线、归纳新偏好、给各 skill 提优化建议再回喂验证，只出报告、不自动改宪法或 skill，采纳权在人）；配图与预览发布（识别配图位并生成图的一组部件，加上把定稿转成能粘进公众号的内联样式富文本的预览工具，把「写完」接到「发出去」）；以及把整条线挂进仓库的 harness 自治循环（让「扫已发布文章、检出技术过时或风格漂移、产出更新方案」也被调度，仍挂着评分加事实核查双门禁）。

这一堆部件，其实共守一条横切的铁律：每一个涉及「机器写东西」的部件，都只给建议、只写进隔离的附属文件、每次写入单独成一个可 revert 的 commit，写作宪法永不被自动改动，最终采纳权永远在我手里。 这是整套工程能让「AI 自治」和「人始终把关」并存的总约束。

最后说句诚实话——收益要认，代价也别遮。我实测这套自生长真的在降本：LP 规则、harness 的运行记录，把重复劳动（搬样板、抓细节偏好、筛质量下限）一点点吃掉，后写的文章确实更省事。这一点我说「越用越省」，不心虚。但同一件事的另一面是：重度审核这一环，人始终没退出。连守内核的那道深度 gate，机器也只能算辅助——它能挡住「明显没想透、通篇只有抽象断言」的稿子，把最差的一档拦在门外，但它判不出「假深度 vs 真洞见」那条细线：一篇结构上四层俱全、每层都有像样支撑的文章，机器会判过，可我读下来仍可能觉得「这是把深度的壳搭齐了，没真穿透」。这条线只有人能划。所以「越用越省」我说，「从此解放双手、自动出好文」我绝不说——后者既和「人仍需重度审核」这个事实打架，也是把话说满。

一句话收这一部分：这套系统真的让写作越来越省，但省下来的时间没让人离场，而是全挪去了那件唯一省不掉的事——重度审核。

3. 最佳实践

前两部分是主干论证。这一部分收拢一批跨文章复用、但不属于任何一个主干环节的散装经验，每条独立成节，按需取用。「去 AI 味」分量最重，放最前面。

3.1 去 AI 味

先给一个定性：去 AI 味不是「换一批词」的美容活，它的本质也是减。AI 求全，铺出来的东西冗余、层级摊平、措辞过度；去味，就是把它砍回重点、把语感矫回自然。这和第一部分讲的「定结构 = 减」是同一件事的第二次执行——定结构时我第一次排主次，AI 成文时又把主次摊平了，去味时我再把它压回去。

说个我自己的成长暗线。我以前去 AI 味，一上来就纠结遣词造句——盯着单个词换；现在我会优先去掉啰嗦重复或结构有问题的点，词句排到后面。这些年我动手的颗粒度是一路往上移的：从词，到句式，到结构。这个迁移我踩了弯路才想明白——一句句抠得很爽，可一段啰嗦重复、结构失衡的文字，每句都改漂亮了整体还是 AI 味，因为 AI 味的重灾区在篇章级的冗余与对称，不在单句。先抠词，是在错的层级用力。

第一步先改结构。 两个动作：删啰嗦重复（同一个判断换个措辞重述一遍，只留一处），重建层级、修详略。这里要讲清 AI 为什么总把结构写塌——它分不出哪个点更重要（因为「更重要」没有客观答案，它没法从文本推断），于是默认行为就是把所有点摆平、给等量篇幅。这会同时导致两种病：层级塌了，是主次在结构维度被抹平（本该「1 主 + N 从」的，被排成 N+1 个并列）；详略失衡，是主次在篇幅维度被抹平（每个点分到差不多的字数，不管它值不值）。两种病同根，都是「AI 只会等量地加，分不出轻重」。给你两个能一眼自查的信号：「这几段是不是一样长、一样重？」（查详略失衡）、「这几个点是不是被我并列成了 1、2、3，其实它们该有主从？」（查层级塌）。修法是同一个——找出那个主，其余让位。

第二步再抠词句，而且是整类扫，不是逐个换。 我出手最快的是三类：翻译腔（「理解了 X 再看 Y 就顺了」「这也说明／这恰恰印证了」「是在做 X 而不是 Y」），情绪化表达（「不是白拿的」「这笔账得算清楚」这类没信息量的提气），过度拟人拟物（「给反熵地基浇混凝土」「拆墙／物理墙」「拿尺子去量」这类和技术没有实质对应的比喻）。这三类都有固定句型，可以成类地扫掉——翻译腔认句式、情绪化认套话、拟人拟物认比喻，投入产出比最高。它们的根是一致的：AI 底座是英文语料，中文是「翻译」出来的，句法骨架还是英文的；再加上它爱用形象修辞来充「生动」。

这里有一条边界不能误伤：禁的是没有信息量的煽动包装，不是语气本身。感叹号点睛、有主体的强判断（「没有银弹！」）、「我个人」这类署名，都是人味，正向保留。我删的是虚火，不是火。

最后放两个诚实的锚。第一个关于破折号——em-dash 被叫作「最有名但已经失效的 tell」，2025 年 11 月之后 OpenAI 已经让模型服从「别用破折号」的指令，而破折号恰恰是我的写作招牌。所以要记住：单个 tell 不是证据，密度才是，别一见破折号就当罪证。第二个关于检测器——它不可靠。FTC v. Workado 案里，某检测器号称 98% 准确，实测约 53%，跟抛硬币差不多，联邦已经禁止它这么宣称（FTC v. Workado, 2025-08）。追「0% AI 检出」是一种范畴错误——你在拿一把测不准的尺子给自己判刑。自证清白靠的是编辑历史、版本记录，不是刷检测分。

3.2 喂样本，而不是喂一长串禁令

想让 AI 写出你的风格，最有效的不是甩给它一长串「不要用什么词」的禁令，而是喂给它你真实写过的东西——几篇范文，让它从样本里学你的声音、句式、节奏。禁令只能挡住「不要变成什么」，长不出「你是谁」。一份纯禁令清单，能让 AI 不写那几个 AI 味词，但写出来还是「平均风格、最大公约数」，不像任何一个具体的人。宝玉那句话说得很到位——你去不掉 AI 味，只能用你自己的味道盖过去。声音是正向的东西，只能从正例里学，删是删不出来的。

但禁令也不是没用——两者是分工，不是二选一：禁令守下限（挡掉 AI 味、翻译腔、生造比喻），样本抬上限（长出你的声音）。真正的做法是样本加带正反例的规则双管齐下——这也是第二部分那份偏好清单里，每一条都写成「AI 原文→人工改后」真实对照的原因。比起一句抽象禁令，一个「极易跑偏→极易偏离预期」的具体改法对照，信息量大得多。

3.3 你是笔的主人，署名的内容必须亲自 review

优先用 AI 写——它就像一支特别好用的笔，你不用亲自琢磨每个细节就能把内容铺出来，这是它最大的价值。但这支笔默认和我的风格差别很大：它啰嗦，它爱自我扩展（擅自加内容、发散、拔高），这是它的默认倾向，不是偶发。

而这里有一个区别于写代码的关键判断：代码有「能不能跑」这个客观标准兜底——它可能也分好坏，但至少有一条客观底线；写文章没有这个东西，好坏没有客观裁判，唯一的把关人就是你自己。所以对文章，人的审阅不是可选项，是唯一的质量来源。Paul Graham 那句「Writing is thinking」我很认同——把写作外包，等于把思考外包（Paul Graham, "Writes and Write-Nots"）。落到动作上：至少你署名的内容，每一句都得人亲自过。这是第二部分说的「重度审核人始终没退出」在个人纪律层面的对应。

3.4 Prompt 内嵌在流程里，别泛泛说「告诉 AI 你的需求」

教「用 AI 写作」，重心应该放在与 AI 协作的指令（Prompt）上，代码只作演示——这也是本文自己遵守的一条要求。介绍某个协作步骤时，直接给出可复用的 Prompt，并且让它出现在那个步骤的自然位置，而不是泛泛描述「把需求告诉 AI」、或者把所有 Prompt 堆到文末。Prompt 的抽象层次也要拿捏——描述意图，而不是写死项目专属的路径和配置。你回看前两部分那几段 Prompt，我都没写死自己的文件名，用的是「粘贴你的大纲」「写进 research 笔记」这类描述，就是这个道理：写死了，你复制过去用不了。

3.5 AI 补的是完备度，不是判断力

AI 帮你的不是「替你想」，是把你脑子里那份不完整、靠临场调取的隐性清单，补成一份显式、穷举、可复用的清单。它的强项（穷举、不漏项）正好压在人的短板（临场容易漏）上。

举个我自己的实例。我写 Rush monorepo 那一章时，其中「迁移已有仓库」的一节，AI 给出的那套策略——渐进可回滚、按依赖图从叶子往回迁、循环依赖就地拆、迁一个项目的三个动作、移除旧基建的收尾清单——这些我自己也能做，但它讲得比我一次性写更完整。完整在哪？它补上了一批我凭经验知道、但临场不一定每次都调取齐的边界：迁移期两套 node_modules、lockfile、命令入口并存，要专门防依赖解析互相污染；剩余项目彼此成环、导致「下一批可迁为空」这种退化情况要单独列出；移除旧基建前，先逐项确认「是否还被引用」，把可删的和需先改的分开。这些不是措辞更全，是一份检查清单的完备度——老手心里有，但靠临场记忆调取，难保每次都摊全。

所以 AI 真正的增量不是「提速」，是把专家脑子里那份靠临场调取的隐性清单，补成一份显式穷举的清单。同一种能力，放对位置是增量、放错位置是负担：AI 的「全面」用在成文铺陈上是灾难（要人砍），用在检查清单、边界穷举上是实打实的福利。但诚实的边界还是那句——AI 补的是完备度，不是判断力。那份迁移清单里哪几条成立、哪几条是过度、整套流程适不适用你的仓库，仍是我拿自己的判断筛过的。AI 把清单摊全，我决定清单里哪几条留下、边界划在哪。

4. 人守住什么

写到这里，前面那条主线该收口了。这一整套东西——从流程到工程到手艺——最后都指向同一个问题：在 AI 什么都能帮一把的时代，人到底不可替代在哪？

我的答案是品味。前面那些伏笔，其实都指向同一样东西：写文章没有客观标准（所以唯一裁判是你自己）、重点的判断标准只在你脑子里（所以喂不过去）、「减」需要一把只在人脑里的尺子（所以无法外包）——它们说的都是那把没法外包的尺子，就是作者的认知与品味。AI 能写、能改、能对齐规则，但代替不了「我觉得这样才对」的那个判断。这篇文章的最高价值，其实就是想把「我的品味」尽可能显式地交出去——写作宪法里的禁令与正例、偏好清单里每一条真实的 diff，本质都是「把品味结构化、可传递」的努力。品味没法直接教，但可以通过大量「这样不行→这样才对」的具体对照，让它变得可学一点。

但我不想给一个漂亮的收尾。真实的情况是——品味能沉淀主体，但沉淀永远追不上人的变化。主体那部分（核心审美、大的判断倾向）相对稳定，可以沉淀进系统；可细枝末节上，人是在不断变化的——我今天觉得这样好，过阵子品味又变了。所以沉淀这件事，永远追不上变化。这就是整套写作工程的天花板，也是它诚实的边界：系统能搬走的，是那部分稳定的、我反复改过的判断（就是偏好清单里那些脚印），AI 可以复用；系统永远搬不走的，是那块随人变化、活的、能应对全新情况的判断——碰到一个我从没改过的新句子、新情境，AI 学到的脚印不够用，还得本人在场重新下判断。

由此我收敛出一个不夸大的结论：可自生长的写作工程，不是要「把作者替换成一套规则」，而是把稳定的那部分品味沉淀下来、让 AI 逐步逼近，从而把作者的注意力解放出来，专注在那块沉淀不了、必须本人在场的活判断上。它逼近品味，但永远到不了、也不该到「完全替代作者」——因为作者本人还在变。工具越强，越反衬出「那个还在变、还在生长的人」才是不可替代的内核。

所以回到开头那个邀请。我不是要你学我这一套——这套流水线只是我的一种活法，长在我的品味上，未必合你。我想请你收回的，也只是那点「AI 写的就是次一等」的偏见：接纳「用 AI 写文章」这件事，然后按你自己的品味，认真地做。工具从来决定不了成品的好坏，决定它的是你有没有守住那把只在你脑子里的尺子。