第1983篇：技术写作的AI辅助——从草稿到发布的完整工作流优化
第1983篇：技术写作的AI辅助——从草稿到发布的完整工作流优化
我有一个尴尬的事实要承认：我写这个公众号快到1983篇了，但在前几百篇里，写一篇文章的时间成本高得吓人。
那时候的流程大概是这样的：想到一个题目，先在脑子里转悠两天，开始写的时候发现思路是散的，写了几百字删掉重来，最后磕磕碰碰写出来，发现逻辑跳跃、前后不衔接，再花一个小时改。整个过程下来，一篇3000字的技术文章要花5-6个小时。
这个效率是不可持续的。
AI辅助写作这件事，我摸索了将近两年，走了不少弯路。今天把我现在用的这套工作流完整写出来，包括哪些地方AI帮得上，哪些地方AI帮不上，以及我犯过的那些让文章变质的错误。
先说清楚：AI辅助写作不是AI代写
这是我要先澄清的一个根本立场。
AI代写的问题不是文章质量差（AI生成的文章结构往往很工整），而是没有观点。AI能写出"Redis有五种数据类型，分别是..."，但AI写不出"我在一个每秒10万QPS的项目里，为什么最后没有用Redis的Sorted Set而是用了一套自己魔改的跳表实现"。
前者是维基百科，后者是有价值的技术文章。
技术写作的核心价值是作者的经历、判断和踩坑。这些东西只存在于作者的大脑里，AI学不会，也写不出。
所以AI辅助写作的正确用法是：用AI来处理写作过程中的摩擦力，把作者的精力集中到真正有价值的部分——判断、观点、经验。
我的技术写作工作流：六个阶段
每个阶段的AI参与度和我自己的参与度是不同的，下面一个一个讲。
第一阶段：选题酝酿——AI帮我做选题评估
选题是最不应该外包给AI的环节，但AI在这个环节有一个很有用的作用：帮你评估选题价值。
我的选题来源有三个：工作中遇到的真实问题、读者的问题和反馈、技术圈里最近的热点。
当我有一个粗糙的选题想法时，我会这样问LLM：
我在考虑写一篇关于"Kafka消费者组重平衡"的技术文章，
目标读者是有2-5年经验的Java工程师。
请帮我评估：
1. 这个主题的读者价值有多高？（从读者角度）
2. 这个主题最常见的写法是什么？大多数文章在哪里止步了？
3. 如果想让这篇文章比网上现有的文章有更多增量价值，应该聚焦在哪些角度？
4. 这个主题的自然搜索场景是什么？读者通常在什么情况下需要这个知识？这个评估的价值不是让AI告诉我写什么，而是帮我想清楚这篇文章为谁服务、提供什么不可替代的价值。
评估完之后，我会对选题做一个主观判断：这个话题，我有没有值得讲的个人经历或独特视角？如果没有，就算AI评估说价值很高，我也不写。没有真实经历支撑的技术文章，写出来就是一锅白水。
第二阶段：结构设计——这是AI最能帮上忙的地方
我发现自己在写作上最大的阻力不是不知道写什么，而是不知道按什么顺序写。
技术内容的结构设计涉及很多决策：先讲问题背景还是先讲解决方案？代码应该在哪里出现？哪个知识点依赖于哪个知识点？从哪里切入读者最容易接受？
这些决策消耗大量精力，而且结构设计的错误会让后面所有的写作努力都白费。
我现在的做法：先快速写下我想在这篇文章里讲的所有内容，不管顺序，就是一个乱序的想法清单。然后把这个清单扔给LLM：
我要写一篇关于Kafka消费者组重平衡的技术文章，
目标读者是有2-5年Java经验的后端工程师。
以下是我想涵盖的内容点（顺序是随机的）：
- 什么是消费者组
- 触发重平衡的三种情况
- 重平衡期间消费者会停止消费
- 分区分配策略：Range、RoundRobin、Sticky
- 我们在生产上因为session.timeout.ms设置不当导致频繁重平衡的事故
- JVM GC停顿也会触发重平衡（这个很多人不知道）
- Cooperative Sticky分配器（Kafka 2.4+）
- 如何监控重平衡频率
- 调优参数：heartbeat.interval.ms、session.timeout.ms、max.poll.interval.ms
请帮我设计一个文章结构，要求：
- 有清晰的认知递进
- 我的生产事故经历放在能起到最大教学价值的位置
- 不要把有趣的内容藏在文章末尾
- 给出每个章节的预期字数建议LLM通常能给出几个不同的结构方案，带着对各方案优劣的分析。我拿这个作为参考，再加入我自己的判断，最终确定结构。
这个过程帮我省了大量的"卡壳"时间，把写作的摩擦力从"不知道从哪里开始"变成了"按照确定的框架往下写"。
第三阶段：草稿创作——这部分AI最多只能打辅助
结构定了之后，真正的写作开始了。这个阶段我的原则是：先产出，不要在写的时候同时修改。
很多人写文章的方式是写一句、改一句，写到第二段，发现第一段不好，回去改，改了之后又觉得衔接不顺，再改……最后花了三个小时，只产出了五百字，而且这五百字还是反复改过的，质量倒也不差，但效率极低。
更高效的方式是：先快速把整篇文章的草稿打出来，哪怕很粗糙，哪怕有些句子是半成品。整个草稿完成之后，再回头修改。
在草稿阶段，我对AI的使用很克制：
- 可以用：帮我快速写一段特定角色的对话示例、帮我生成一个配套的代码片段、帮我把一个复杂概念用一句话先表达出来（之后我会改）
- 不应该用：让AI直接写正文段落
第二条是我踩过的坑。有段时间我会让AI帮我写某个小节的内容，然后在AI输出的基础上修改。看起来提效了，但实际上你会发现：AI生成的文字，你修改起来比自己从头写还费劲。因为你要先理解AI的逻辑，判断哪些地方对、哪些地方不对，然后在一个不属于你的表达框架里做外科手术式的修改。
结果是：你花在修改AI输出上的时间，比自己直接写还长，而且最终文章的流畅度和个人风格都变差了。
草稿阶段有一个AI用法是真正有价值的：帮你脱卡。
有时候你在写某个技术细节，卡住了，不知道怎么解释。这时候可以问LLM："用一个生活化的类比，解释一下什么是乐观锁和悲观锁的区别"，然后从LLM的回答里找灵感，改成你自己的表达。这是用AI"解锁"自己，而不是用AI代替自己。
第四阶段：AI辅助精修——这是价值最高的环节
草稿完成之后，进入精修阶段。这个阶段我会用AI做几件事：
1. 逻辑检查
以下是我的一篇技术文章草稿，请帮我检查：
1. 论述逻辑是否有跳跃或矛盾
2. 技术内容是否有明显错误（如果有，请指出）
3. 段落之间的衔接是否流畅
4. 是否有前文提到但后文没有收回的论点
[粘贴草稿]这个环节很有价值，因为自己修改自己的文章会有"思维盲点"——你看自己写的东西，脑子里会自动补全你写的时候想到的逻辑，所以你看不出跳跃。LLM作为一个"外部读者"会发现这些跳跃。
2. 表达优化
我的写作风格是偏口语化的，但有时候草稿里会出现拗口的长句子或者不够准确的技术描述。我会让LLM帮我优化：
以下几个段落写得比较生硬，请帮我改得更流畅，
保持口语化风格，但不要改变技术内容和我的观点：
[粘贴段落]注意这里的关键词："保持口语化风格"、"不要改变技术内容和我的观点"。这两个约束非常重要，否则AI会把你的文章改成一篇标准的正式技术文档，失去个人特色。
3. 读者视角检查
假设你是一个有3年Java开发经验的工程师，
你正在公司上班的间隙读这篇文章。
请告诉我：
1. 读到哪里你会觉得"这个我已经知道了，跳过"
2. 读到哪里你会觉得困惑
3. 读完之后你记住了什么
4. 这篇文章能解决你在工作中遇到的什么具体问题
[粘贴文章]这个检查帮我校准文章的内容深度——有没有太浅导致对目标读者没价值，有没有太深导致读者看不懂。
第五阶段：技术校验——AI不可靠，这个阶段要人工主导
这里有一个很重要的原则：AI辅助精修之后，所有技术细节必须人工校验。
AI在精修过程中可能会"顺手"修改一些技术细节，或者给出一个听起来合理但其实不准确的说法。特别是：
- 特定版本的行为差异（比如JDK8和JDK11的某些变化）
- 框架的内部实现细节（这些文档不常见，AI可能有偏差）
- 数字和参数（最大连接数、默认超时时间等）
我的做法是：文章发布前，把所有涉及具体参数、版本特性、源码引用的地方都标记出来，逐一对照官方文档或本地运行结果验证。
这个步骤不能省，省了就会在评论区被读者指出错误，积累了几次之后公信力就垮了。
第六阶段：发布优化——标题和开头的重要性
技术文章的标题和前三行，决定了有多少人会点进来读，以及点进来的人会不会读下去。
我会让LLM帮我生成5-10个标题候选，然后自己选：
这篇文章的核心内容是：
[一句话概括文章主旨]
目标读者是：有2-5年经验的Java工程师
请帮我生成10个标题，要求：
- 有具体数字或场景（更好的点击率）
- 不要标题党，标题要能准确反映内容
- 有些可以是问句，有些可以是陈述句
- 避免过于通用的表达（不要用"浅析"、"详解"这类词）关于文章开头，我有一个固执的坚持：开头必须是我自己写的，不让AI碰。
文章开头决定了读者对整篇文章的第一印象，也是建立"人味"最关键的地方。AI写的开头往往是这样的："在当今快速发展的技术环境中……"——这种开头我看到就想关掉页面。
好的技术文章开头应该是一个具体的场景、一个令人印象深刻的事故、一个出人意料的反直觉观点，或者一个读者一看就觉得"这就是我的问题"的痛点描述。这些东西只能来自于真实的经历，AI想不出来。
一个完整的Prompt模板库
经过长时间的摸索，我现在有一套固定的Prompt模板，用于写作工作流的不同阶段。分享一部分：
选题评估模板：
技术文章选题：[主题]
目标读者：[描述]
请从内容差异化、读者价值、我可能的独特视角三个维度评估这个选题结构设计模板：
文章主题：[主题]
想覆盖的内容点（乱序）：[清单]
请设计文章结构，并说明每个章节的目的和建议字数逻辑检查模板：
以下是技术文章草稿，请检查：逻辑跳跃、技术错误、衔接问题、未收回的论点
[粘贴文章]读者视角模板：
扮演：[目标读者描述]
评估以下文章：困惑点、跳过点、记住的内容、实际价值
[粘贴文章]踩过的坑，写在这里防止你重蹈覆辙
坑一：让AI统一"润色"整篇文章
这是最常见也是最致命的错误。AI润色后的文章会变得很"正式"、很"标准"，但失去所有个人特色。技术文章的价值恰恰在于作者的声音，让AI把你的声音磨平了，文章就死了。
坑二：把AI的每条建议都采纳
AI给出的修改建议不一定都是对的，有些建议是在往"标准化"方向拉，而你的文章可能偏偏需要"不标准"才好看。要保持判断力，对AI的建议有选择性地采纳。
坑三：用AI写代码示例
代码示例需要是真实可运行的，而且应该体现你的真实使用场景。让AI生成的代码示例往往是教科书风格的，缺乏真实项目里的复杂性和细节。建议代码示例都来自你真实写过或踩过坑的代码，AI最多帮你清理一下格式。
坑四：信任AI的"最新信息"
AI的训练数据有截止日期，对于版本敏感的技术细节，它可能给你JDK8时代的答案，但你的读者在用JDK21。一定要确认文章里的技术信息是否是当前版本的准确描述。
最后说一个哲学问题
经常有人问我：用AI辅助写作，这还算是你的原创吗？
我的答案是：当然是。
一个木匠用电锯做的家具，比用手锯做的效率高十倍，但家具的设计、比例、工艺选择，都是木匠的判断和匠心。没有人会说那不是他的原创作品。
AI是工具，我是工匠。工具帮我处理掉那些繁琐的摩擦力，让我把精力集中在真正创造价值的地方：我的经历、我的判断、我对技术的理解。
这才是AI辅助写作应有的姿态。