搭建一套更高效的 AI 写作工作流

上一篇讲了我如何与 AI 协作完成一篇文章。不过，这个过程仍由人主导，需要持续投入时间和精力去跟进：每写一篇，都要向 AI 交代素材位置、传递大纲、说明审稿标准；中途停下来，还得记住进行到了哪一步，之后该做什么。

那么，有没有办法进一步提效呢？

有的兄弟，有的。我自己的做法，是把文章、素材和写作规范放进同一个仓库，将重复的操作整理进一个 skill，形成一套能自动推进、能中断续跑的写作工作流。在此基础上，再让 AI 不断从我的修改和反馈中归纳偏好，积累到仓库里，供后续写作复用。这样，仓库本身也就有了成长性——随着文章和修改记录不断积累，AI 生成的内容会逐渐接近我的思维方式和写作风格，后续需要我调整的地方也会越来越少。

本文就详细讲讲，如何搭建和使用这套工作流。

1. 用 Git 管理文章与写作资料

过去我习惯用飞书文档写文章，编辑交互顺手，排版样式丰富，图文、表格等内容的表现能力也很强。不过，自从开始使用 Claude Code，我已经把文章全量迁移到 Markdown，与素材、配图、写作规范一起放进 Git 仓库。这种变化主要出于以下几个考虑。

首先，Markdown 便于 AI 直接读写。标题、段落、链接都保存在文本中，工具读到的内容与我们编辑的内容一致，修改前后也容易比较。一般的技术文章用 Markdown 已经够用，需要嵌入交互组件时，再考虑 MDX。

其次，相关资料有了固定位置，AI 就可以按路径读取——写正文时参考素材和大纲，审稿时读取风格规范，不必每次重新粘贴。写作规范和工具由整个仓库共享，写下一篇时可以直接复用。

再者，在本地使用 agent 写作，我与它的交互会保存在会话日志里。文章哪里需要调整、为什么这么改、我更认可哪种表达，这些反馈都有记录。后续就可以让 agent 分析日志，从中提炼我的写作偏好和思维模式，再用于下一次写作。写得越多，积累的反馈也越多，生成的内容就能逐渐接近我的思路和风格，减少后续调整的成本——仓库也由此有了自成长性。

Git 则用于保留文章和规则的修改历史，改得不满意时，可以查看差异、恢复之前的版本。

可以从一个空目录开始，让你使用的 AI 编程工具完成基础整理：

请在当前目录建立一个用于技术写作的 Git 仓库；如果已经是仓库，沿用现有结构。

先检查现有文件，不覆盖已有内容。按当前仓库的约定安排以下位置：
- 每篇文章的工作目录：保存素材、规划、大纲、正文和进度。
- 共享的写作规范目录：供写作与审稿读取。
- 配图目录：与对应文章放在一起。

写一份简短说明，解释各目录用途，以及当前 agent 的会话日志保存在哪里、后续如何读取。
此时只建立目录和说明，不生成文章，不安装发布工具，也不自动提交已有改动。

仓库建好后，先放入一篇文章及其素材。至于发布站点、格式转换等工具，等有实际需要时再接入。

2. 把重复操作固化成工作流

回顾上一篇的写作步骤：从梳理想法开始，调研素材、确立主题、安排结构，再到成文、审稿、核实事实、配图，最后把修改中体现的偏好反馈给系统。每篇文章的内容不同，但围绕这些步骤的操作有很多是重复的——读取材料、按要求生成文件、检查结果，再把产物交给下一步。这些操作很适合整理成一套工程流程。

这套工程化环境的理想形态是：一个编排流程，加上若干职责明确的 step。整套流程由一个 new-article skill 管理，调研、拟大纲、写作、审查等 step 的执行说明放在它的 references/ 里；编排流程则负责推进这些步骤、传递产物、记录进度，并根据结果决定继续、回退，还是停下来等我确认。启动任务后，agent 按约定推进，我在需要确认方向和审阅内容时介入。

下面先看编排层如何推进流程、保存状态，再重点展开自动审查机制。

2.1 编排层如何推进流程

编排层可以沉淀为一个独立的 skill，就叫 new-article 吧。它接收文章主题、目标读者和素材位置，安排各阶段的任务。agent 执行到某一步时，读取对应的 reference 和材料，完成后检查结果，决定进入下一阶段、返回前面的步骤，还是等待我确认。

下面是它的整体流程：

图里的流程分成五个阶段。它沿用上一篇的八步，只在编排时做了合并：启动前先用追问形成 seed.md；成文、去 AI 味和事实核查合并为「写作与审查」；定稿后再执行偏好学习，作为收尾步骤。

1. 调研素材：围绕初步想法整理已有材料、补充外部参考，并保留出处。完成后由我 review，检查有没有遗漏、误解或需要进一步核实的内容；材料不够，就先补充，再进入规划。
2. 规划主题：结合素材，明确这篇文章想表达的判断、准备展开的论点，以及不打算涉及的范围。这一步需要我确认主题和重心；如果论点缺少支撑，就回到调研补材料，或重新调整主题。
3. 确认大纲：将规划整理成章节，安排顺序、详略和各节的论据，再交给我 review。结构不合适，就修改大纲；如果发现主题本身需要调整，则回到规划阶段。大纲确认之后，才开始写正文。
4. 写作与审查：agent 按大纲写完后，先根据沉淀的规则自行 review、反复修订，达到审核要求后再把成稿交给我做人工审核。这是整套流程中投入最重的部分，后面单独展开。
5. 按需配图：到这里，正文已经完成审查和人工审核，只需根据内容补充必要的流程图、示意图等。我再检查图片中的文字、关系和表达是否准确，确认后插入文章，完成本篇内容制作，再从定稿记录中归纳偏好。

整个过程通过一份 state.json 管理流转状态，记录当前进行到哪个阶段、产物保存在哪里、是否已经人工确认，以及还有哪些问题待处理。编排层在每次阶段切换或修订后更新这份记录。这样，即使中途关闭会话或暂停任务，再次启动时也可以读取状态、核对实际文件，从上次中断的位置继续，不必重新执行整套流程。

可以用下面这段 Prompt，让 AI 生成编排 skill：

请为当前写作仓库创建一个 new-article skill，将下面的流程固化下来：
启动前读取追问形成的 seed.md，随后执行：
调研素材 → 规划主题 → 确认大纲 → 写作与自动审查 → 人工审核正文 → 按需配图 → 定稿后沉淀偏好。

写作编排和各阶段规则集中在一个 new-article skill，配图调用已有的
gen-image、add-illustrations 工具 skill，不重复实现生图接口。
SKILL.md 保持精炼，负责流程编排；
各步骤的具体方法放进同目录的 references/，执行时按需读取。
具体如何拆分文件、组织步骤，请结合当前仓库自行设计。

每篇文章有独立的工作目录：stages.md 保存本篇的阶段安排，state.json 记录流转状态，
seed.md、素材、规划、大纲和正文也放在这里，支持中断后继续。
上一篇的 research.md 在这里统一命名为 evidence.md，已有材料直接沿用或迁移，不另建重复素材库。

调研、规划、大纲完成后由我确认。正文写完后，agent 按沉淀的写作规范和个人偏好
自行审查、修改、重新评分，通过后再交给我人工审核；最多三轮，仍未通过就报告问题。
审稿可以调整段落组织和详略；涉及章节顺序、核心判断或讨论范围的变化，先交我确认。
正文确认后按需配图，我检查图片内容。定稿后执行偏好学习，方法见 references/learn-style.md。

请直接生成 skill 及其 references，并给出使用示例。本次只搭建工作流，不开始写文章。

上面这段 Prompt 有几个设计点：

• 主文件保持精炼：SKILL.md 只保留职责、阶段顺序、推进条件和参考文件的读取时机，让 agent 先掌握流程全貌。
• 步骤说明放进 references/：调研、规划、大纲、写作、审查等具体方法都在同一个 skill 内维护，供不同文章复用。
• 每篇文章有自己的工作目录：stages.md 保存本篇的阶段安排，state.json 记录执行进度，与素材、大纲和正文放在一起，不混进 skill 的参考文件。
• 执行时按需读取：在具体动作处引用对应的 reference，避免一开始就加载所有细节，也避免参考文件只是列在目录里、执行时没有被读取。
• 状态落盘，支持续跑：用 state.json 保存阶段和确认状态，重新启动时核对实际产物，从中断处继续。
• 写清暂停条件：需要人工确认、缺少必要材料或自动修订达到上限时，停止并报告问题，不能自行跳过或降低标准。

2.2 各步骤通过文件交接

各步骤通过文件传递结果。例如，调研时把收集的素材保存下来，规划时读取这些素材，确定文章的主题和论点；写作时再读取素材和确认过的大纲，展开成正文，供后续审查。每一步的产物都保存在文章目录里，既方便随时查看和修改，也能在切换会话后继续使用。

例如，一篇文章的工作目录可以这样组织。上一篇的 research.md 在这里统一称为 evidence.md，仍是同一份素材；图片统一放进 assets/，已有 images/ 目录也可以沿用，保证引用一致即可：

articles/
└── writing-with-ai/
    ├── stages.md
    ├── state.json
    ├── seed.md
    ├── evidence.md
    ├── plan.md
    ├── outline.md
    ├── article.md
    └── assets/

这些文件分别保存以下内容：

每份步骤说明都要明确需要读取哪些材料、将结果写到哪里。agent 按 stages.md 找到对应的 reference，再读取本篇文章的文件执行任务；reference 本身只保存方法，不混入某篇文章的素材或进度。

调研、规划、大纲和成文的具体做法，上一篇已经详细介绍，这里不再逐步重复。下面重点讲 agents 如何在交稿前完成多轮审查和修订。

2.3 让 agents 先完成多轮审查

在我这套流程里，审查是投入最重的一部分。AI 写出初稿已经很快，但初稿里那些反复出现的问题——翻译腔、啰嗦重复、无关展开、缺少依据的结论——如果每篇都要由我逐处指出，后续修改仍然需要大量精力。因此，交给我之前，先让 agents 按已经沉淀的规则完成审查和修订，尽量提前处理这些已知问题。

首先要有明确的审稿依据。我把写作规范和已经确认的个人偏好交给审稿步骤，让它检查具体段落，而不是笼统地要求“去掉 AI 味”。例如，检查一段话是否啰嗦重复，可以给出这样的对照：

• Bad case：“每个阶段的结果都会保存到文件中，方便后续步骤读取。这样，下一步就能直接使用上一步保存的结果，不必重新整理。通过文件保存中间结果，各阶段就能复用之前的产出。”
• Good case：“每个阶段将结果保存到文件，供下一步直接读取，避免重复整理。”

原文三句话都在说“保存结果，供后续复用”，后两句没有补充新的信息，合并即可。这样的例子能让 agent 明白，应该删的是重复论述，而非一概缩短句子。这些规则与对照可以从平时的修改和反馈中积累，第三节会介绍如何维护。

执行时，我将表达修订、事实核查和评分分开：

• 表达修订：直接修改正文，先处理重复论述和详略问题，再调整翻译腔、生硬衔接等词句。
• 事实核查：读取修改后的正文，对照素材检查事实，列出有冲突或缺少出处的论断，并注明依据。
• 质量评分：根据规范评估修改后正文的论证、结构、风格和可读性，给出分项结果、具体问题及判断依据。

事实核查和评分的结果统一交给编排层汇总，用于判断是否需要继续修订。

审查发现的问题需要分别处理：句子不自然，可以直接改写；某个数字缺少出处，就应标为“待确认”。找不到依据不能直接判定它错误，更不能替换成另一个未经验证的说法。文章只有观点、缺少论据时，评分报告则需要指出是哪一段、缺少什么支撑，方便下一轮有针对性地补充。

上述流程会反复执行：根据审核发现的问题修改正文，再重新核查和评分。直到总分达到 80 分、风格分项达到 20 分，思想深度单独达标，同时通过事实核查，才把成稿交给我做二次审核。

当然，自动修订也需要停止条件。我的实现最多执行三轮，包含首轮。达到上限仍未通过，就列出剩余问题，交给我决定。尤其是缺少实验数据、主题与素材不匹配这类问题，反复润色并不能解决，需要补材料或调整论点。

审查方法保存在 references/review-and-retry.md，可以用下面这段 Prompt 补全：

请完善 new-article skill 内的 references/review-and-retry.md，
将表达修订、事实核查、质量评分和循环修订写成同一份执行说明，不创建子 skill。

请按以下顺序组织执行方法，使用共享写作规范和已确认的个人偏好作为依据：
1. 风格改写：直接修改正文，先处理重复论述、详略失衡和衔接问题，
   再调整 AI 套话、翻译腔及不符合个人偏好的措辞，保留已确认的核心判断；涉及章节顺序、核心判断或讨论范围的变化，先提建议交作者确认。
2. 事实核查：交给独立上下文的 subagent 执行，明确传入改后的正文、素材和核查规则。
   让它对照来源逐条检查事实，只返回问题清单，不修改文章。每条注明位置、原文和依据；
   缺少出处的标为待确认，不擅自判错或编造替代说法。由主 agent 汇总结果并安排后续修订。
3. 质量评分：交给另一个独立上下文的 subagent 执行，传入改后的正文、写作规范和评分标准。
   评估技术内容、逻辑、风格和可读性，总分 100，其中风格分项 25 分；思想深度单独检查。
   只返回各项分数、判断依据、完整问题清单及对应段落，不修改正文，由主 agent 汇总结果。

明确通过条件：总分至少 80，风格至少 20，思想深度达到单独标准，事实核查无未解决问题。
未通过时合并问题清单，按 references/writing.md 的定点修订说明修改正文，再重新检查。
最多三轮，包含首轮。通过后交给我人工审核，达到上限仍未通过则报告剩余问题。
将检查结果、轮次和剩余问题保存到文章目录，更新本篇 state.json。

主 SKILL.md 只保留进入审查、通过后继续和未通过时暂停的条件，链接到此 reference。
本次只完善执行说明，不对具体文章执行审查。

这些检查能减少我反复指出同类问题的次数，但审核分只是交稿条件。文章是否表达了我想说的内容、哪些论述还需要取舍，仍要在人工 review 时逐段判断。

2.4 多路审查

如果还想把审查做得更充分，可以分别启动独立的 Claude Code、Codex、deepcode 本地 CLI 进程，review 同一份稿件。以我个人的使用感受，Claude Code 中所用模型偏理性，Codex 中所用 GPT 模型更擅长通识，deepcode 中所用 DeepSeek 模型在中文表达上更合我的口味。这是我对当时所用模型的体验；CLI 是调用工具，审阅表现也会随模型和配置变化。因此，我会给它们不同的审阅侧重：

• Claude Code：重点检查论证是否严谨、前提能否支撑结论，以及技术方案的解释有没有遗漏。
• Codex（所用 GPT 模型）：从更广的知识背景审视文章，检查概念有没有混淆、判断是否缺少适用条件，以及换到其他场景还能否成立。
• deepcode（所用 DeepSeek 模型）：重点看中文语感，检查翻译腔、别扭的句式、重复铺陈，以及哪些表达读起来不像我自己写的。

这只是我安排审稿任务时的经验分工，各自仍然要读取同一份写作规范和个人偏好。比如一句“这个方案能显著提升效率”，有的 reviewer 会追问数据依据，有的会检查结论能否推广，另一个则可能提醒“显著提升”太笼统。

这里我会要求各路独立审查，只给问题清单，汇总后再统一改写。先让它们各自读同一版正文，避免跟着另一份意见重复判断；随后由主 agent 合并重复问题，保留各自发现的遗漏。意见冲突时，对照文章主题、事实依据和我的写作偏好决定取舍，不按赞成的模型数量直接定对错。

统一修改后，再对改过的内容进行核查和评分，必要时继续交叉 review。从我的使用感受来看，让各路分别检查逻辑、知识和表达，比反复要求同一个 agent“再检查一下”，更容易发现遗漏的问题。

可以用下面这段 Prompt，为现有审查流程补充多路 CLI 审阅：

请在 new-article 的 references/review-and-retry.md 中补充以下机制：

再设计一个可选的多路审查环节：分别启动独立的 Claude Code、Codex、deepcode 本地 CLI 进程，
让它们审阅同一版正文，依次侧重逻辑严谨性、通识与适用边界、中文表达。
每个进程都读取同一份写作规范和个人偏好，独立完成审查。
各路独立输出问题清单，不直接修改文章。由主 agent 去重、处理冲突后统一改写，再核查和评分。
通过各 CLI 的非交互调用方式传入审稿任务并收集结果；先检查本地命令是否可用，
缺少某个 CLI 时如实说明，不将主 agent 的自查冒充为该进程的审查结果。

在主 SKILL.md 中补上对应的读取时机，保留已有修订上限。

3. 让写作系统持续成长

这套流程里，写作规范很重要。AI 怎么组织论证、哪些地方需要展开、用什么措辞，都需要参照它；写完之后，也要依据它来审查。规范越完善，越贴近自己的表达习惯和思考方式，生成的文章才越有自己的个性。否则，即使流程跑得再顺，也可能每次都要花不少精力，才能把文章改成自己想要的样子。

但这份规范需要不断维护。我们很难一次性说清自己的所有偏好，同样的写法，换一个话题、面对另一群读者，也可能有不同的取舍。

而且，即使做了很多沉淀，这些规则也只能不断接近你的表达和思维习惯，不可能完整地代表你在每篇文章里真正想说什么。成稿依然需要自己认真 review：这个判断是不是我的意思，这里有没有讲到重点，这个说法我是否认可。随着规范逐渐完善，我们希望 AI 少犯那些已经纠正过的问题，让自己需要反复解释、亲手调整的地方越来越少，逐步降低每次 review 的成本。

3.1 从自己的文章中提炼初始风格

为了搭建这套审核体系，我的做法是，先把自己过去写过、现在读起来依然认可的文章交给 AI，让它从中分析我的表达习惯和思考方式，整理成一份 writing-style.md。选文时，可以覆盖几种平时常写的题材，既有讲原理的，也有分享实践经验的，方便它区分哪些是稳定习惯，哪些只是某篇文章的需要。

分析的内容可以包括：

• 如何展开一个话题：从具体问题切入，还是先交代背景；什么时候给出结论，什么时候补充解释。
• 如何组织论证：更关注原理、实践过程，还是方案之间的取舍；会不会主动说明成本和适用条件。
• 如何分配篇幅：哪些地方愿意花几段讲透，哪些知识默认读者已经了解；案例和比喻通常用在什么地方。
• 如何表达：句子长短、口语程度、转折方式，以及标题和段落之间的衔接习惯。

每个判断都要能在原文里找到依据。例如，AI 总结出“作者喜欢从实际问题切入”，就应该列出几篇文章的开头，说明我是怎样引出问题的。我再核对这些归纳，把不准确的删掉，把自己认可但没有说清楚的补充完整。

首次搭建时，可以用下面这段 Prompt，让 AI 直接分析过去的文章，生成初始规范：

请阅读我提供的这些文章：[文章路径列表]，分析我的表达习惯、结构安排和思考方式，
整理成一份 writing-style.md 草稿。

每条归纳附上原文依据，区分跨文章的稳定习惯与特定题材的写法，
不套用通用写作模板，也不替我编造偏好。先交给我核对，确认后保存到
new-article skill 的 references/writing-style.md。

这是首次建立规范时的一次性工作。生成的 writing-style.md 放在 new-article 的 references/ 里统一管理，后续写作和审查直接读取它即可。

这份初始规范就是种子。它让 AI 在第一次参与写作时，就能参考我已经形成的习惯；后续写作中的修改和反馈，再给它提供继续生长的养料。

3.2 从日常修改中积累偏好

写这篇文章时，我就反复给过几类反馈：先讲清楚背景，再展开具体做法；前一篇已经讲过的步骤，这一篇不要重复；举例要给出具体的改前、改后，不能只是笼统地描述问题。这些反馈涉及措辞、文章结构和解释方式，要求细碎，逐条梳理也很繁琐，很难一次性说清楚。所以，更好的方式就是在日常写作和 review 中，遇到了就提出来，日积月累，再逐渐沉淀成明确的项目上下文文档。

在本地与 agents 协作，这些交互会留在会话日志里。文章审完之后，就可以让 agent 回头读取相关记录，把我的修改要求、当时的原因说明，以及对应的改前改后内容放在一起分析，归纳到 learned-preferences.md 中。

可以用下面这段 Prompt 补充这一步：

请为 new-article 补充 references/learn-style.md，在文章完成正文审核和配图验收、定稿后，
从本篇相关的本地会话日志和修改记录中归纳我的写作偏好，保存到 learned-preferences.md。

结合修改前后和我的原因说明，分析表达习惯、结构取舍与思考方式，为每条归纳保留依据。
区分本篇的特殊要求和可复用的偏好；不确定的先作为候选，反复出现或经我确认后再正式采用。
已有同类条目就补充证据，避免重复；与现有规范冲突时交给我判断，不自动覆盖。

在主 SKILL.md 中补充该步骤的读取时机。本次只生成执行说明。

agent 整理完成后，我再对照当时的反馈，检查它有没有理解错。

3.3 让学到的偏好参与下一次写作

偏好保存下来之后，还要用到下一篇文章里。我把两份文件作为共享资料：writing-style.md 保存已经确认的整体写作规范，learned-preferences.md 补充日常修改中逐渐发现的偏好。规划、写作和审查都读取它们，让这些积累影响文章从组织到表达的整个过程。

例如，“先交代背景，再展开具体做法”在规划时就能用来检查章节顺序；到了写作时，agent 应该先说明为什么需要这套做法，再介绍文件和操作；审查时，则检查是否尚未交代目的，就开始介绍实现细节。如此这般，这两份沉淀下来的文档，才能真正影响到后续文章的撰写过程。

之后每写一篇，都把人工 review 中发现的新偏好补充进文档，供下一篇写作时参考，让已经提过的要求不必反复交代。

3.4 定期整理积累下来的规则

随着反馈增多，同一个意思可能被记成几条规则，也可能出现不再适用的要求。比如，“少讲重复结论”和“不要换着措辞重说同一个判断”，就可以合并到一起，保留最能说明问题的例子。

我也会重新看那些一直没有得到验证的候选偏好：当初是不是理解错了，是不是只适用于某一种文章。如果自己的写法已经变化，就调整对应规则。对于反复验证、已经稳定下来的习惯，也可以在我确认后整理进 writing-style.md，避免两份文件越来越长，却找不到重点。

这类整理也可以交给 agent，用下面这段 Prompt 定期执行：

请先查找并分析本仓库的写作日志，重点阅读我在人工 review 时提出的修改要求、原因说明，
以及对应的改前改后内容，再据此整理 new-article 使用的 writing-style.md 和 learned-preferences.md。
合并重复条目、精简表述，保留有代表性的例子，并注明对应的日志依据。
找不到相关日志或依据不足时如实说明，不凭现有规则的措辞推测我的偏好。

检查长期未验证的候选偏好，以及相互冲突或已经不适用的规则。
有明确依据的直接整理；无法判断是否仍符合我习惯的，列出问题交给我确认。
对于已经稳定、适合纳入 writing-style.md 的偏好，提出调整建议。

完成后简要说明改了什么、为什么改，方便我 review。

日常写作不断补充偏好，定期整理则把重复的合并、过时的更新，让这两份文档跟得上自己写作习惯的变化，方便后续继续使用。

4. 用这套流程持续写技术博客

这套流程已经帮我完成了数十篇文章，我觉得它非常适合技术相关的文章写作。这类文章经常需要结合文档、源码、实验结果和项目经验，把一个问题讲清楚。从整理素材到核查结论，再到调整结构和表达，每篇都要经历这些工作，正好可以通过前面的流程组织起来。

比如，要写一篇项目性能优化的复盘，就可以把相关代码、测试数据和自己的分析放进文章目录，让 agent 据此梳理问题、规划大纲，再逐步完成正文和审查。我在几个关键阶段参与 review，重点看优化思路有没有讲清楚、数据能不能支撑结论、方案的成本和适用条件有没有交代。素材传递、进度记录，以及按已有规范反复修改的工作，都可以交给流程处理。

持续写同一个技术领域时，积累的资料也很容易复用。写系列文章，可以让 agent 读取前几篇，了解哪些概念已经解释过、这一篇应该重点讲什么；以前整理过的源码分析、实验记录，也可以成为新文章的素材。文章之间因此有了联系，不必每次都从头交代背景。

对我来说，这样的仓库既保存了已经写过的内容，也保存了我是怎样把它们写出来的。后续有了新的选题，带着素材和想法进来，就可以沿用已有流程继续写，把精力更多地放在技术分析和经验总结上。

5. 总结

这篇文章介绍了我如何把日常的 AI 写作过程整理成一套可以持续使用的工作流，主要做了三件事：

• 把文章和资料放进仓库：用 Markdown 保存正文，与素材、配图一起管理，让 agent 能直接读取和修改，也方便保留版本。
• 用一个 skill 组织写作流程：主文件负责推进，各步骤的方法放进 references，通过文件交接结果、记录状态；正文经过多轮自动审查后，再交给我 review。
• 让写作规范持续成长：从过去的文章中提炼初始风格，再从日常写作日志中归纳偏好，定期整理，用到后续文章里。

搭建时，可以直接用文中的 Prompt，让 agent 结合自己的仓库生成这些文件，再拿一篇真实文章跑一遍。过程中遇到需要反复说明的要求，就继续补进对应的执行说明或写作规范，让这套流程逐渐贴合自己的习惯。

有了这套环境，接下来还要处理写作中的具体问题：AI 写得啰嗦、主次不清时，应该从哪里改起？怎样提供样本和反馈，让表达更接近自己？哪些内容需要亲自判断和核实？下一篇《如何使用 AI 写技术文章：最佳实践》，我会结合实际修改经验，展开聊聊这些问题。