上星期参加一个技术方案评审有人贴出一段“基于现有架构的弹性扩容设计”。文字结构漂亮分点清晰结论也放在了开头。读到一半我发现了问题监控指标的单位写反了Kafka被描述成“适合点对点通信的消息队列”。前者是事实错误后者是技术判断失准。追问之后对方承认整段背景分析是让 AI 生成的还没来得及逐条核验。这不是个例。我见过不少开发者和内容从业者刚开始尝试用 AI 加速写作时几乎都会踩进同一个坑AI 生成的内容越长、越像样埋雷的概率反而越高。所以我很同意这句话You Should Almost Never Use AI to Write Anything Substantive。它不是在反对 AI而是在划一条责任线AI 可以负责“写得像”但“说得对”的责任必须由人来承担。1. 这句话不是否定AI而是在给内容质量划责任红线1.1 先搞清楚什么叫“substantive content”很多人会把“substantive”理解成“长文”或者“正式文章”我觉得不准确。判断一篇内容是不是“实质性内容”要看它是否需要为事实负责、是否会被别人当作决策依据、是否带着署名和承诺。举个最简单的例子你在本地写一段给自己看的备忘只要自己能看懂AI 拼拼凑凑问题不大。但如果你要把一份技术方案放进评审会议让团队依据它决定架构方向这就是实质性内容。同理故障复盘、产品 PRD、安全报告、数据分析结论、对外发布的署名文章都属于这一类。这些内容的共同特征是出错后影响真实决策读者会默认内容经过核验发布者要对信息质量承担责任内容里的判断和取舍不能只用“文字通顺”糊弄过去。所以“substantive content”不等于“长内容”而是“有后果的内容”。一个公司公告可能只有两百字但它照样是实质性内容。1.2 为什么“看起来通顺”反而更危险这里有一个被低估的问题AI 生成内容的流畅性会天然压制读者的警惕心。我们平时读文章遇到语句不通、逻辑断裂会本能地放慢速度开始怀疑。但 AI 生成的文字往往语法正确、句式平稳、章节结构完整读起来非常“顺”。这种顺会制造一种可信感让人产生错觉既然文字这么专业内容应该也没有问题。实际恰恰相反。AI 擅长的是“用专业语气组织句子”不是“确认句子里的信息真实”。它可能把一个不存在的开源项目写进参考文献可能把某个框架的能力描述成另一个框架可能给出一串看起来很精确但实际不可复现的数据。这些错误一旦被流利的段落包装就特别难被发现。我自己的体会是让 AI 写实质性内容最大的成本不是“生成”这一步而是“审查和纠偏”这一步。你花了十分钟让它生成一篇看起来完整的文章随后可能要花两小时来逐句排查错误。如果时间不够这些错误就会原样进入交付物变成你签名负责的内容。如果你的内容需要别人依赖它做判断那么 AI 生成得越流畅你就越要提醒自己这不是可信的保证只是一个更精致的草稿。1.3 模型负责“写得像”人负责“说得对”这句话可以作为核心原则。AI 能通过语言模型学习大量文本的模式知道一份技术方案通常由背景、现状、方案选型、风险评估、实施计划组成。这是“结构能力”。但它不知道你的项目真实背景是什么不知道你在上一轮评审中答应过什么不知道线上系统的流量峰值是不是真的像文档里写的那么高。这些“知道”属于人。人需要提供输入、设立边界、做取舍并且为最终结果负责。所以我们面对的不该是“用不用 AI”的问题而是“AI 介入到哪一层”的问题。你可以让 AI 提供框架、生成候选表达、检查格式但最终的内容主权和判断权必须留在人和流程手里。2. 理解AI的生成机制才知道该信任哪一层2.1 语言模型在做续写不是在做思考很多人对 AI 写作的预期是“它像一个懂很多的人在帮我写文章”。这个预期是误解的根源。大语言模型的基本工作方式是条件概率预测给定前面一段文字预测下一个最可能出现的 token。它不是在理解世界也不是在查资料而是在进行一种极其庞大的模式匹配。训练数据里出现过大量“技术方案应该怎么写”的文本所以它能生成很像样的段落。但这不等于它理解技术方案里的每句话。这意味着一个关键结论AI 生成内容的优化目标是“看起来合理”不是“事实上正确”。如果你用一个不存在的产品名问它它很可能不会说“我不知道”而是会顺着你的话生成一个符合语境的描述。因为从模型的角度看保持对话的连贯性和可信度比承认不知道更重要。2.2 幻觉不是 bug而是机制的一部分“AI 幻觉”这个现象经常被当成模型的缺陷。但严格说它是当前生成机制的自然结果。模型没有实时访问真实世界的能力它的知识来自训练数据和上下文窗口。当上下文窗口里没有足够信息它会选择最连贯的补全方式。再加上解码策略为了多样性不会永远选择概率最高的那个 token所以它会在事实、人名、版本号、引用出处这些地方“自由发挥”。工程上有很多缓解手段比如让 AI 基于给定材料回答用 RAG 检索增强生成把 temperature 调低要求输出“不确定”标记。这些方法能降低幻觉率但无法根除。因为模型没有底层的事实数据库也没有“我查一下再回答”的能力。所谓“联网搜索”也不是搜索后真正阅读而是把网页片段变成新的上下文再继续预测。理解了这一点就会明白在“事实准确性”这件事上AI 永远只是辅助不是权威。2.3 对写作实践的启示既然模型的强项是语言模式弱项是事实与判断那使用方式就应该顺势而为。适合让 AI 做的生成提纲、扩展要点、压缩长文、改变语气、翻译、润色、把口语整理成书面语。不适合让 AI 独立完成的需要给出结论、判断优劣、确认数据、引用来源、否定某个选项、承诺交付结果。换句话说AI 可以作为“表达层”的帮手但“认知层”必须由人来主导。如果你把一篇文章拆成“想法”和“表达”两部分AI 擅长的是优化表达甚至能在一定程度上辅助整理想法但真正决定“这篇文章为什么存在、要改变什么、结论是否成立”的仍然是你自己。3. 哪些内容可以交给AI哪些应该守住“人写”3.1 适合用AI快速产出的内容类型不是所有写作都需要上纲上线。有相当一部分写作是低风险、可验证、以格式为主的这些可以放心让 AI 参与甚至让它直接生成初稿。我通常会把这类内容分成三种日常事务型周报、会议纪要、邮件初稿、项目状态更新。这些内容有固定格式信息可由人提供AI 主要做重组和润色。模板说明型代码注释、README 初稿、FAQ、操作手册中的标准步骤。内容是操作性的通常可以验证AI 生成后简单检查即可。发散辅助型起标题、生成调研提纲、列出候选方案、头脑风暴风险点。这类内容不要求一次准确重点是提供候选让人来筛选。这些内容的共同点是即使错了影响范围小或者容易被快速发现或者本来就是给人“参考取舍”的。此时让 AI 加速收益远大于风险。3.2 不适合AI直接生成的场景和上一篇的列表刚好相反下面这些场景属于高风险、强判断、重责任的内容不太适合让 AI 直接生成最终交付物技术方案、架构设计、迁移计划产品需求文档、业务规则定义数据分析报告中的结论部分故障复盘、安全公告、风险说明法律或财务相关的条款性文本需要署名的深度文章或对外技术博客。这些内容的价值核心是“判断”和“取舍”。AI 可以帮你把背景写得更完整把某个方案的优点列出来但它没法理解你们团队的现状不知道你为什么要在这三个方案里选一个也不知道这次技术选型背后还牵涉到哪些组织因素。一个比较实用的判断标准如果这份内容最后需要有人“签批确认”那个签批人不能是 AI。如果出错后的追责对象是你或你的团队那么 AI 就不应该成为真正的作者。3.3 边界不等于禁止从“替代”转向“协作”把内容分成“可以用”和“不能用”两类不是要给你一份禁令清单而是想说明边界之外AI 仍然可以在很多环节提供价值。比如写产品 PRD你可以让 AI 根据你提供的用户反馈和业务目标生成章节框架和问题清单但优先级排序、异常流程、非功能需求、发布策略必须由产品经理自己决策。再比如写技术方案AI 可以帮你生成一张“方案对比表”的模板但评估维度怎么定、每个方案打几分、推荐哪个方案这些都必须来自项目真实情况。所以更好的做法是把 AI 当成一个“写作协作伙伴”而不是“替身”。你负责提供信息、设定约束、做最终判断AI 负责把这些素材组织成更清晰的表达。这个协作关系一旦建立写实质性内容就不需要担心被 AI 带偏因为 AI 只是帮你把话说明白并没有替你做决定。判断一份内容能不能交给 AI不是看它长了多少而是看它需要为多少“不可验证的断言”负责。断言越多人的参与就必须越深。4. 一套“人为主、AI为辅”的写作工作流4.1 前置准备先给AI足够的上下文和边界我发现很多人在使用 AI 写作时上来就丢一句“帮我写一份技术方案”然后期待高质量输出。这几乎不会成功。原因很简单AI 不知道你的项目背景、目标读者、已有结论、限制条件。你给它的信息越少它就越会从训练数据里抽取“最常见的技术方案套路”来填充。于是你得到的不是方案而是“通用模板”。正确做法是先做一次“输入工程”明确这份内容的读者是谁、目标是决策还是记录把已知事实、数据、结论、涉及的系统名称和版本写清楚告诉 AI 哪些是必须覆盖的内容哪些是不能写进去的要求 AI 把不确定的信息写成占位符而不是编造。举个例子如果你要写一份技术方案可以先给 AI 这样一段输入你是一名技术文档编辑。请基于以下背景生成一份技术方案提纲。 背景 - 系统当前是单体应用计划逐步拆分为微服务 - 主要矛盾是发布频率低、线上变更风险高 - 团队人数 6 人运维能力有限 - 初步倾向使用容器化和 CI/CD但还未确定具体平台。 要求 - 覆盖背景、目标、方案候选、风险、实施步骤、验收标准 - 不要引入没有事实依据的具体产品版本号 - 所有未知信息写成[待确认]占位不要猜测 - 输出只给提纲不要展开成完整正文。 技术细节[在这里填写真实版本、配置、代码路径等]这样 AI 生成的是“脚手架”不是“结论”。真正的技术判断和最终内容仍然由你在后续步骤中填充。4.2 用AI生成“脚手架”而不是直接生成正文“脚手架”包括结构提纲、问题清单、需要补全的信息列表、可能的段落顺序。它最大的价值是帮助我们整理思路而不是代替思考。我自己的习惯是在写一篇长文之前先给 AI 提供三四个零散的关键词和模糊想法让它帮我列出可能的文章框架。然后我会逐条分析哪些框架适合读者哪些章节是废话哪里的论证逻辑会断裂。这个过程很多时候比直接写正文更重要。如果你跳过这一步直接让 AI 生成全文你等于把思考过程外包了。等文章写出来你不仅没有建立清晰的认知还会被它的表达带着走。你会发现自己很难看出文章里的问题因为里面的术语你都“好像认识”但实际没有经过自己的消化。所以宁可多花五分钟先让 AI 把提纲和关键问题列好也不要急着让它写完整段落。4.3 人工补全核心内容再用AI润色和压缩进入正文写作阶段我会坚持一个原则核心的结论、判断、数据解释、风险分析这几部分由人亲自写。为什么因为这些内容不是靠语言能力就能写好的。一个风险结论涉及你对系统现状的理解一段数据分析涉及你对业务指标的定义一段架构解释涉及你对取舍逻辑的叙述。这些信息零散地存在于你的经验和项目上下文里AI 就算能组织语言也无法替你组织这些认知。核心内容写完以后AI 的作用有两块润色把重复表达、口头语、不够清晰的长句改得更紧凑压缩在字数受限的场景中删掉冗余内容保留必要信息。但即使是润色也要逐段回读。AI 可能会在改写的过程中不自觉地改变语义边界把“不建议”改成“不推荐”把“可能”改成“一定会”。这种细微变化在单独句子里很难发现放在整个文档里却会影响判断。4.4 强制事实核查让输出可见、可测、可追溯实质性内容发布前必须有一轮事实核查。这个流程不能省也不能只靠“我读过一遍感觉没问题”。一个比较有效的做法是建立核查清单所有数字是否有来源来源是否可靠所有产品名、版本号、命令、配置文件是否与实际环境一致所有“根据调研”“通常认为”“业界共识”后面的结论是否有对应的依据代码能否运行如果生成的是代码片段至少要在一个最小环境里执行一次。引用的外部链接是否真实存在如果想让 AI 生成“参考链接”请默认它可能编造必须人工验证。如果时间紧张无法完成核查那么我宁可在文章里少写一部分内容也不要把未经核实的信息放进去。在技术内容里一个错误的结论比一段缺失的信息危险得多。5. 收到AI内容后的排查顺序5.1 先看现象通顺但空洞是最常见的信号当你拿到一段 AI 生成的文字不要急着点头。先看它是否出现了这些现象段落之间很顺滑但没有推进任何核心观点大量使用“一般来说”“从更高层面看”“值得注意的是”这类空泛连接句在关键数据点出现“具体数据可参考官方文档”但并没有给出真正可检索的信息结论部分只是重复前文没有给出选择和取舍代码看起来像伪代码结构完整但无法运行。如果你发现内容只是“读起来没问题”但始终没有讲清楚“下一步到底该做什么”那么它很可能只是一个语言模型而不是一份实质性内容。5.2 再查输入很多时候问题出在提问方式AI 的输出质量高度依赖输入。如果输入本身含糊输出也会含糊如果你没有给出边界它会默认使用“最大公约数”来填充。所以排查问题时不要只盯着 AI 输出还要回看你自己的提问。你的问题里是否包含了足够的上下文是否明确要求它禁止编造是否提供了具体数据如果什么都没有先补充输入再重新生成往往比逐句修改 AI 输出更有效。5.3 验证关键断言把它当成一篇需要审稿的文章把 AI 输出的所有“可验证断言”抽取出来逐一核对。所谓可验证断言是指那些能够通过查证来判断真伪的内容比如版本号、发布日期、API 参数、兼容性、数据规模、引用来源、公司名、指标计算方式。在抽取断言时要特别留意那些语气肯定但信息非常具体的句子。例如“某框架在 3.2 版本中引入该能力”这句话听上去很专业但很可能来自模型对训练数据的中位推断而不是事实。一个常见做法是把这类句子复制到搜索框里独立搜索如果可以找到官方来源才算通过。AI 生成的内容里最需要警惕的不是明显的错误而是“语气笃定但出处存疑”的细节。语气越确定越要在事实层多问一句。5.4 确认逻辑链从“堆信息”变成“有论证”实质性内容很忌讳“每句话都对但段落之间没有关系”。AI 擅长生成并列式的信息点但不太擅长生成层层递进的论证。排查时可以抽取出关键段落问三个问题这一段在全文里承担什么作用是背景、论据、还是结论如果删掉这一段全文逻辑是否受到影响上一段和下一段之间是靠因果关系连接还是靠“此外”“同时”这种并列关系连接如果一篇内容从头到尾都是“此外”那它只是在罗列信息不是在建立观点。你需要重写主线把并列结构改成因果或取舍结构。5.5 回到原始目标内容是否真的解决问题最后一步把文章放回到原始目标里看。它是否回答了读者最关心的问题是否给出了明确行动建议是否说明了不这样做的风险是否指出了适用边界如果一份技术内容读完之后读者只能获得“信息量很大”的感觉却不知道下一步该做什么那这份内容还没有完成。AI 可以帮助你收集信息、组织语言但它不能代你判断“这篇文章应该帮助读者做出什么决定”。6. 长期看别让AI替你退化了判断力6.1 写作本身就是思考过程技术写作不是“把已知的东西写出来”更多时候是“写着写着才想清楚”。你可能在写方案时发现某个前提不对在写总结时发现某个结果可以解释得更准确。这个过程本身就属于思考的一部分。AI 直接生成全文等于把这段思考过程跳过了。你会得到一个看起来完整、但并没有经过自己消化的文本。短期看是效率提升长期看却是判断力和表达敏感度的退化。我自己最明显的体会是当我很长时间不写正文只靠 AI 生成初稿再修改时我会发现自己对语言的控制感变弱了。面对一段含糊的表述我不再能立刻感知到它有问题面对一个缺少论据的断言我也不像以前那样警觉。写作能力不是天生就有而是靠反复训练维护的。6.2 培养“编辑脑”而不是“生成脑”把 AI 当写作工具最健康的姿态是把自己训练成一个高标准的编辑而不是一个只会按“生成”按钮的操作员。编辑脑的工作方式是拿到 AI 输出的多个版本不急着选第一个对比不同版本提取各自的长处进行合并和改写在每次审校时记录 AI 易犯的错误形成自己的“易错清单”把 AI 生成的内容当成“候选素材”而不是“答案”。这样AI 会从“替代你思考的工具”变成“帮你看到更多可能性的镜子”。你仍然在主导判断但你能接触到的信息宽度被扩大了。6.3 一个可以长期使用的“AI写作四问”我后来给自己定了一个检查清单每次想让 AI 参与实质性写作时都会先回答这四个问题这段内容需要为事实负责吗需要就必须逐字核验不能让 AI 自由生成。这段内容是否依赖具体上下文依赖就把上下文完整提供给 AI并明确未知范围。这段内容被公开后我能解释每一句话的理由吗不能就不要直接发布。这段内容的核心作用是启发、表达还是定案表达和定案必须人主导AI 只能出素材和意见。这四个问题不是限制 AI 的使用而是帮你决定AI 应该在哪个位置干活你应该在哪个位置把关。回到文章标题里的那句“almost never”——我理解它不是让你完全放弃 AI而是提醒你在实质性内容面前警惕心要超过对效率的期待。AI 是一个高效的文字生成器但你才是内容质量的第一责任人。下一次想让 AI 替你写一段重要内容时先问自己如果这段话出了问题谁会承担后果答案如果指向你那你就该出现在创作链路里而不是让 AI 替你按下发送键。