技术写作的工程化：从选题、生成、排版到发布

当文章数量超过 60 篇以后，瓶颈已经转移——从写作能力变成了内容资产管理能力。

过去写技术文章，我很容易陷入一种状态：看到热点，临时开写；写完 Markdown，再手动排版；发出去以后，只看阅读量，很少复盘为什么这篇好、那篇差。

写到一定数量后，我发现问题不在"能不能写"，而在"能不能稳定地产出有价值的文章"。

所以我开始把技术写作当成一个工程问题来处理：选题是输入，文章是构建产物，排版是发布适配，数据反馈是监控指标。

过去几个月，我积累了 60 多篇技术文章，主题覆盖 AI Agent、Claude Code、Codex、DeepSeek、Kimi、云服务、工具教程。回头看，这些文章不是零散的——它们正在形成一张知识网络。

这篇文章的目的不在炫耀自动化——它是一次系统复盘：技术写作也可以像软件工程一样，有输入、处理、质检、发布和反馈闭环。

你可以把它当成一本"方法论手册"来读。我在每一节都会给出可以直接用的检查清单和最小可用方案。

1. 为什么技术写作需要工程化？

先看常见痛点，看看你中了几条：

• 选题靠感觉，写完才发现和三个月前的文章撞题了。

• 热点来了就追，缺少长期内容主线，文章之间没有关联。

• 素材散落，链接、截图、代码片段到处乱放，用到时找不到。

• 版本混乱，Markdown、公众号 HTML、配图、封面、审稿记录——哪个是最终版？

• 发完即止，没有归档，没有数据复盘，不知道这篇到底有没有用。

• AI 帮忙写，但如果没有流程约束，会产生大量质量不稳定的稿件，改起来比重新写还累。

这些问题的本质是一样的：把每篇文章当成独立事件处理，而不是一个系统的产物。

当文章数量只有个位数时，靠记忆就能管理。超过十几篇以后，瓶颈就转移了——从写作能力变成内容资产管理能力。

这也是为什么软件开发有版本控制、CI/CD、监控告警，而大多数人的写作流程还停留在"新建文件夹 → 随便命名 → 写完发出去 → 忘记它存在"。

关键判断：

技术写作不是灵感驱动的单点行为，而是一条可以工程化的流水线。选题、素材、生成、审稿、排版、发布、复盘——每一步都可以沉淀为资产。

2. 我的内容资产现在长什么样？

在讲流水线之前，先看看底子。

我把已有的文章分成了几个大类。这个分类本身，就是工程化的第一步——知道你有什么，才知道该补什么。

为什么要做这个分类？

因为写每一篇新文章的时候，我不再只问"这个选题好不好"，而是先问：

• 这属于哪个系列？

• 它和已有的哪些文章关联？

• 它是补了内容矩阵里的哪块拼图？

• 它服务的是哪个读者场景：搜索型、收藏型，还是讨论型？

内容是一个知识库，不是孤立文章。每写一篇，都应该知道它属于哪个系列、补哪块拼图、服务哪个读者问题。

3. 第一环：选题工程化

选题是整个流水线的入口。入口质量决定整条链的产出。

我的选题来源分四类：

行业热点： Claude、Codex、DeepSeek、Kimi、GLM、JetBrains 这些产品和生态的每一次重大更新，都可能是选题。但不等于每个热点都值得写——需要过滤。

工程经验： 自己真实搭工具、踩坑、调试、发布的过程，是最难被复制的选题。别人可以追同一个热点，但复刻不了你踩过的坑。

数据反馈： 社区热力值、互动率、收藏率、阅读表现——数据会告诉你读者真正想要什么，而不是你以为他们想要什么。

内容缺口： 拿着第 2 节的分类表，看一眼就会发现覆盖的盲区。比如我的趋势类已经写得很多了，但工程实战和对比评测还可以补。

选题不再是"我想写什么"，而是经过一套选择题来过滤：

最后再加一个评分维度：

超过 3 分的选题才值得动笔。这个评分表不高深，但它把"感觉这话题不错"变成了可以对比的量化决策。

4. 第二环：素材工程化

AI 写作最容易出问题的地方，不在文笔——在素材边界。

素材不清楚，生成内容就容易虚——看起来通顺，但事实不准、数据没来源、结论浮在半空。

每篇文章涉及的素材包括：

• 官方文档链接

• 新闻 / 博客来源 URL

• 命令行输出（保留原始输出，不是手工排版后的版本）

• 代码片段（可运行的，不是截图的）

• 截图和流程图

• 数据表（谁发布的、哪个时间点）

• 个人实验记录（什么环境、什么参数、什么结果）

• 已发文章的引用

我的实践是两条底线：

1. 每篇文章尽量有明确来源。 事实性陈述要能追溯到官方文档或可验证的原始出处。

2. 技术结论区分事实、推断和个人观点。 不把"我猜测"写成"事实上"。

不同类型文章对素材的要求不一样：

关键原则：

素材不是"收集完就放一边"的参考，而是草稿质量的硬约束。素材密度越高的文章，AI 生成的偏离率越低。

5. 第三环：草稿生成工程化

这一环最容易引起误解，所以先说清楚：我的做法是，把流程拆成多个明确的小任务，每个任务都有可检查的输入输出。

每个小任务的输入和输出都可以检查。一个环节的输出不过关，就回到上一环补素材或调指令，而不是一路冲到底。

我把 AI Agent 的角色拆成了几个：

每一步的输入和输出都是文件，存放在文章目录下——这样任何一步都可以回溯、重做或改进。

关键句：

AI 最大的价值不是"替你写"，而是让每一步都有东西可审查。空白页是最难审的。AI 给了你一个初稿——哪怕它只有 60 分——你就能开始审改了。

6. 第四环：审稿和质量控制

如果全文只能认真写一节，我会选这节。

技术文章的质量，不取决于写得有多快，而取决于审稿有多严格。AI 可以帮你写，但审稿的责任永远在你这里。

我的质检清单分三层：

第一层：事实审稿——有没有错？

• 技术名词有没有用对？（Agent vs Agentic，Tool Use vs Function Call，这些不是同义词）

• 版本号、发布时间、API 名称是不是最新的？

• 数据有没有来源？来源是不是一手？

• 代码能不能跑？有没有漏掉依赖或配置步骤？

• 截图和文字描述是否一致？

第二层：结构审稿——读起来顺不顺？

• 标题有没有过度承诺？（"彻底解决"、"一行代码搞定"——这种词要慎用）

• 文章结构是否有逻辑断层？读者会不会读到中间发现少了一环？

• 段落是否太长？公众号阅读场景下，超过 5 行的段落基本不会有人读完。

• 是否只是复述新闻，没有自己的判断？

• 前后结论是否矛盾？

第三层：价值审稿——读者看完能带走什么？

• 有没有和已发文章重复？

• 是否至少提供了一个可执行步骤？

• 是否有表格、清单或流程图提升收藏价值？

• 读者看完后，能说出一句"原来如此"吗？

三层审稿对应三个不同的审稿视角：

事实审稿，是用工程师的眼睛看，有没有 bug。 结构审稿，是用编辑的眼睛看，信息流对不对。 价值审稿，是用读者的眼睛看，读完有没有收获。

最后，一个核心原则——和《Generated Code is Real Code》一脉相承：

AI 生成的文章也是文章。不能因为它是 AI 写的就降低审稿标准。 降低标准等于告诉读者：这篇东西不值得认真读。

7. 第五环：排版工程化

排版属于内容交付的一部分，不是最后的美化步骤。

技术文章如果代码块难读、表格错位、图片不清楚、段落挤成一片，价值会直接打折。读者不会说"内容好但排版差"，读者只会说"这文章不好读"然后关掉。

我的排版工程化是这样做的：

源文件是 Markdown，不是 HTML。 所有内容修订都在 Markdown 里完成，HTML 是通过脚本生成的，绝不手改。因为一旦开始手改 HTML，你就失去了源文件的更新能力——下次修改只能改 HTML，恶性循环。

一篇内容，多个发布目标：

源文件，所有修订的入口

目录结构示意：

content/

topic-name/

article.md # Markdown 源文件（source of truth）

article.html # 微信公众号发布版

imgs/

cover.png # 封面图

diagram.png # 架构图

screenshot.png # 实操截图

REVIEW.md # 审稿记录

这样的好处是：

• 一个目录就是一个完整的发布包，不会出现"封面在桌面上，正文在文稿里，截图找不到了"。

• 同一篇文章的不同版本都在一个地方，归档就是一整个文件夹。

• 如果将来要改成其他平台的排版（比如 头条号、掘金），只需要新增一个生成脚本，源文件不变。

8. 第六环：发布和归档工程化

发布不是结束。发布是从"我的文档"变成"公共资产"的分界线。

发布前 Check List

• [ ] 标题是否适合目标平台？（公众号重标题，技术社区重关键词）

• [ ] 摘要能不能在 3 秒内说明这篇文章的价值？

• [ ] 封面在小图（朋友圈卡片）下是否可读？

• [ ] 代码块在手机上是否可读、有没有换行？

• [ ] 外链是否都有效？头条号不能带外链的话，是否需要改成备注？

• [ ] 文末是否有互动引导？（问题、投票、评论期待）

• [ ] 是否更新了选题库状态？（标记为"已发布"，为后续选题提供排重参考）

发布后归档

一篇文章发布后，归档的内容不只是最终 HTML：

不归档的文章，只是一次性内容。归档后的文章，才是可以复用的资产。

9. 第七环：数据反馈工程化

写文章和写代码一样：没有线上数据，就只是个人练习。

我的做法是：每篇文章发布后，回头看一眼数据。不光"看完"，更要把数据当成下一轮选题的输入。

这里简单说一下我自己的数据现状（2026 年 6 月）：

这些数据告诉我的事很简单：下一阶段的目标变了——从"多写几篇"转向"每篇写得更值得收藏"。

具体来说：

• 标题要更精准，减少泛泛的趋势解读。

• 增加手把手的步骤、可复用的配置、可直接套用的模板。

• 增加盘点类和对比类内容，这类文章天然高收藏。

• 每篇结尾放一个明确的互动问题，把读者从"看完就走"拉成"看完想说一句"。

数据反馈让写作从"我觉得不错"变成"读者真的有没有用"。

10. 这套流水线带来的变化

不夸张地说，这七环走下来，写作这件事在我这里的形态完全变了。

变化一：选题不再孤立

每篇新文章都能迅速挂到某个系列里。选题从"想到什么写什么"变成"这个位置缺一篇什么"。内容矩阵的空白区越来越小。

变化二：写作速度更稳定

每次写作从已有模板、素材清单、审稿清单开始，不再从零构思结构。写第 10 篇和第 1 篇花的时间差不多——甚至更少，因为积累的素材和模板在复利。

变化三：质量更容易控制

因为每一步都有检查项，你不需要依赖"今天状态好不好"。状态不好，多跑一遍审稿清单就是。质量的下限被流程托住。

变化四：文章可以复用

一篇文章不只是"发出去的东西"。它可以继续拆解成：

• 选题灵感 → 喂给选题池

• 审稿记录 → 下次写文章时提前避坑

• 代码片段 → 复用在不同文章中

• 排版模板 → 降低下一篇文章的排版成本

• 数据表现 → 作为同类选题的数据参考

变化五：复盘更具体

不再只看阅读量，而是看阅读、收藏、互动、排名变化的组合。一篇阅读量一般但收藏率高的文章，价值可能远大于一篇阅读量高但零收藏的文章——前者是工具属性，后者只是标题吸引人。

11. 普通技术作者怎么复用这套方法？

不是每个人都有一整套 CLI 工具和自动化脚本。但核心不是工具，是思路。

不需要一开始就做完整系统。先做 5 个文件夹：

content/

ideas/ # 选题池 —— 一个 .md 文件，记下想到的选题

sources/ # 素材 —— 链接、截图、引用，按选题分类

drafts/ # 草稿 —— 正在写的文章

published/ # 已发布 —— 每篇一个文件夹，含最终版本和配图

reviews/ # 复盘 —— 数据表现和改进记录

每篇文章保留 5 个东西：

1. 选题来源（为什么写这篇）

2. Markdown 原稿

3. 发布版本（公众号 / 博客 / 掘金）

4. 配图 / 表格

5. 发布后数据

每篇文章发布前问 5 个问题：

1. 这篇解决什么问题？（读者看完能得到什么）

2. 读者为什么要收藏？（有没有清单、表格、代码、模板）

3. 有没有真实例子？（还是全篇抽象描述）

4. 有没有可执行步骤？（复制粘贴就能用的那种）

5. 和我以前写的有什么不同？（角度、深度、时效性）

这 5 个文件夹 + 5 个保留物 + 5 个问题——成本几乎为零，但效果是把你从"写作靠灵感"拉到"写作有体系"。

结尾

技术写作当然需要表达能力。但写到一定阶段以后，更需要工程能力。

选题是需求分析，资料是输入数据，草稿是构建产物，审稿是测试，排版是发布适配，阅读和互动是线上反馈。

当我开始这样看待写作以后，文章就不再是一篇篇孤立的输出，而是一套可以持续迭代的系统。写第 62 篇的时候，不需要再犯第 3 篇犯过的错。

这套流水线本身也在迭代——这篇文章就是一次系统复盘的产物。接下来我可能会把每个环节拆成更具体的工具和模板，写成系列文章。

你现在写技术文章，最卡的是选题、动笔、排版，还是发布后的复盘？欢迎留言告诉我。 我想看看大家卡在哪个环节，后面把这个流水线拆成具体工具和模板分享出来。