一个“看起来很厉害”的AI稿，和一个“可以稳定交付”的AI写作系统，真正的差别大多藏在第一段文字出现以前。

弱流程通常是：让模型“写一篇专业文章”，看完以后觉得哪里不够好，就继续提示，直到语言变顺。

强流程会先做一串编辑决策：什么叫成功；哪些材料有事实权限；哪些地方允许推演；怎么验收；模型不确定时怎么办。

失败往往到后面才暴露。初稿几分钟就出来，编辑却花一小时追无来源断言、删重复结构、纠正术语，最后还发现文章回答了一个和真实读者稍微不同的问题。

这首先不是“文笔问题”，而是流程设计问题。

下面是一份可以直接复制的决策清单，并说明每一项为什么存在。

1. 定义“读者要做什么决定”，不要只写题目

“写AI工具”只是题目。

“帮助两人创作工作室判断：应该用一个通用AI完成写作，还是采用研究—起稿分阶段流程”才是读者决策。

后一种更容易验，因为可以检查读者最终有没有拿到：

  • 比较标准；
  • 取舍；
  • 什么条件会改变答案；
  • 下一步动作。

没有读者决策时，模型最容易写成百科式覆盖。句句都可能没错，整体却不帮人做任何事。

清单： 先写一句“读完以后，读者应该能够……”

2. 把“有事实权限的资料”和“创意资料”分开

不要把官方文档、头脑风暴、客户原话和未经确认的想法混在一个巨大上下文块里。

最好明确标：

  • FACTS： 可以当事实写的材料；
  • VOICE： 只用于学习语气，不能当证据；
  • IDEAS： 假设和角度，不得升级成事实；
  • EXCLUSIONS： 这篇明确不碰的声明、产品或话题。

结构化边界能挡住一个很常见的问题：模型从“脑暴笔记”里捡到一句很有说服力的话，然后不知不觉把它写成了事实。

主流模型厂商的提示指南都在强调清楚指令和上下文分区。到底用Markdown标题还是XML标签不是核心，核心是语义边界要看得懂。

清单： 编辑能不能指出每条非显然事实具体由哪一块资料授权？

3. 先定义工作，再选模型或工具

很多团队顺序反了：先喜欢上一个工具，再让所有写作任务迁就它。

更稳妥的顺序是：

  1. 定义任务；
  2. 判断需要多少上下文和推理；
  3. 判断是否必须联网/检索文件；
  4. 判断输出是否要严格结构；
  5. 最后才选产品、模型或流程。

工作改变，工具选择也应该变。大量简单变体可能更适合快而便宜的模型；复杂综合可能值得更强推理；反复改稿可能需要可编辑写作区域；如果提示、测试和结构都要版本控制，代码流程又更合适。

清单： 记录“这个工具为什么适合这项工作”，而不是“团队为什么喜欢它”。

4. 明确模型可以“编”什么

创意工作需要发明，事实工作需要约束，很多项目两者都有。

例如幻想游戏团队要写上线文章。AI可以提出比喻、标题、转场、明确标成“假设”的举例；但不能发明发布日期、平台、玩家数、奖项、引用、功能。

边界必须写出来。

一个很好用的要求：

只允许发明明确标记为假设的说明例子；不得发明测量结果、引用、客户、法律结论、产品能力或“我们亲测”。

这句话的保护作用，比十个“更专业、更像人”的形容词都大。

清单： 把允许发明和禁止发明的类别直接列出来。

5. 批量生产以前，先设计验收

如果你说不清“什么叫合格”，继续生成更多版本并不会自动解决。

一篇文章可以靠编辑直觉，五十篇最好有重复可执行的检查。

常见维度包括：

  • 事实是否有支持；
  • 是否真的帮助指定受众；
  • 结构是否独立；
  • 风格是否匹配；
  • 禁止声明是否缺席；
  • title/H1和元数据是否正确；
  • 站内是否重复；
  • 本地化是否自然；
  • 来源是否足够新。

当前模型优化文档一直强调eval，本质原因很简单：没有测量，提示词优化很容易变成凭感觉。

清单： 至少准备一个客观能失败的测试，再准备一个必须人工判断的编辑问题。

6. 示例用来教“边界”，不只是教“语气”

只给“好范文”，模型可能只学到表面形式。

成对示例更容易把规则讲清：

好： 对比先说清推荐会因什么条件变化。
坏： 没定义标准就说某工具“最好”。

好： 假设案例明确写明是假设。
坏： 虚构小案例装成真实客户成果。

对照能让模型学到底层规则。

但示例也要彼此有差异。如果每个样板都是同一种开头、五个H2、一张表、结尾清单，系统最终学到的是骨架。

清单： 多个示例之间，结构本身应该看得出不同。

7. 事先规定“不知道时怎么办”

可靠系统一定要有“不知道”的出口。

如果不规定，模型很容易因为对话默认偏爱流畅而把缺口抹平。

缺证据时可以：

  • 标记该声明；
  • 只在草稿环境写 明确标注“待补来源”的内部草稿备注；
  • 交互场景下请求缺失文件；
  • 直接删除断言；
  • 并列不同解释而不强选；
  • 转人工审核。

不同场景选不同做法，但“默默补一个看似合理的答案”不应该是发布流程的默认。

清单： 给无来源断言写一个明确fallback。

8. 起稿上下文要比研究资料更窄

研究阶段会收集很多可能有用的东西，起稿阶段应该做选择。

正式写以前，最好整理一个短的“批准事实包”，只保留：

  • 大纲真的会用到的事实；
  • 准确名称和术语；
  • 必要的当前日期/版本；
  • 批准来源URL；
  • 已知不确定项。

这样能减少分心，也让后续逐条核验更快。

清单： 正文应该能追溯到一个经过整理的资料包，而不是几十页原始搜索结果。

9. 本地化要保留“目的”，不是逐句排队翻译

中英文发布时，逐句直译很容易语法没问题、用途却变差。

两种语言的读者对术语解释、例子、句长、链接文字、单位和CTA可能有不同习惯。EN/ZH要共享同一个事实边界和读者决策，但完全没必要共享每一个段落节拍。

本地化时检查：

  • 哪些东西必须一致？
  • 哪些案例跨语言仍自然？
  • 哪个术语需要解释，而不是音译？
  • CTA在中文里是否真的像人会说？
  • 标题本地化以后搜索意图还在不在？

清单： 验语义和事实对齐，不验逐句对齐。

10. 重要内容要保留修订谱系

某条声明被审核后改掉，应该留足够记录说明“为什么改”。

简单production ledger可以记录：

  • 来源版本；
  • 提示/流程版本；
  • 文件hash；
  • QA结果；
  • 定点修复；
  • 最终gate；
  • 发布时间。

这不是为了官僚化，而是防止已经修好的断言被旧稿重新覆盖，也能区分“模型写过”和“编辑批准过”。

清单： 如果团队说不清当前哪个文件是权威版本，流程还没有真正结束。

一个复盘：为什么“很顺”的稿还是失败

假设团队要求：

给小型设计公司写一篇AI写作工具购买指南。

第一稿非常漂亮，有开头、对比表、推荐。

但审核后发现：

  1. 功能对比依赖没有来源的产品假设；
  2. “最适合agency”没有评价标准；
  3. 和前四篇文章又是同一个五段骨架；
  4. 编了一个“某工作室每周节省8小时”的案例；
  5. 中文把工作流和产品术语逐字翻，读起来很别扭。

修法不是“让AI再准确一点”。

应该重做流程：

  • 产品功能只认官方资料；
  • “best”改成场景标准；
  • 先选大纲，再起正文；
  • 禁止虚构数字案例；
  • 中文单独给本地化brief；
  • 文风润色以前做一次claim audit。

第二稿可能生成得慢一点，却会更快进入“可相信”状态。

什么情况下可以简化流程

不是所有任务都需要这么重。

私人脑暴里，错一个想法成本很低；公开知识库、产品对比、医疗解释、受监管行业页面，则需要更强来源控制。几篇内容可以人工看，几十篇最好有自动元数据和重复检查。个人作者可以接受更大风格波动，品牌编辑部可能要求严格一致。

流程应该和三个东西成比例：错误成本、重复规模、审核难度。

可直接复制的清单

生成以前：

  • 已定义读者决策
  • FACT/VOICE/IDEA分区
  • 工具按任务选择
  • 发明边界写清
  • 来源新鲜度够
  • 验收标准已定义
  • 缺证据fallback已定义

生成以后：

  • 事实能追到批准来源
  • 假设案例诚实标注
  • 结构没有复制邻近文章
  • 语气符合真实受众
  • 本地化保留目的与边界
  • 元数据正确
  • 权威文件可识别
  • 修订历史可追

AI写作里真正隐藏的手艺，并不是让模型多写几个漂亮段落，而是设计一个流程，让它不能悄悄把不确定写成确定、把模板写成内容、把脑暴写成事实。

Sources

Related Reading