把AI写作真正跑顺，先记住三个结论。

第一： 研究、起稿、核验是不同工作。把它们揉进一次请求里，交互次数可能少，但隐藏错误往往更多。

第二： 最好的prompt不一定最长。真正有价值的是最小一组“可验证”的指令和上下文。

第三： 每轮修改都应该减少不确定。如果每次只有“再好一点”，这个流程其实没有学习。

下面是一条面向公开发布内容的完整生产线。低风险脑暴可以简化。

09:00——先写生产brief

打开任何AI工具以前，先定：

  • 受众；
  • 读者最终要做什么决定；
  • 格式和长度；
  • 事实范围；
  • 允许来源；
  • 禁止声明；
  • 语气；
  • 本地化要求；
  • 验收检查。

例如：

受众：独立创作工作室。
决策：什么时候一次AI起稿就够，什么时候需要分阶段。
范围：工作流原则和当前官方文档能确认的写作功能。
禁止：伪造亲测、保证准确、编客户成果。
输出：英文主稿+中文本地化，都有来源。
验收：所有产品特定声明能追到当前官方资料。

后面文字怎么改，这份brief都保持稳定。

09:20——资料搜集和正文分开

不要第一句就是“研究并写”。

先收权威材料。工具类内容优先用产品官方文档确认产品行为；功能、限制、套餐、界面路径这类会变的东西要记录核验日期。

研究表只需几列：

  • 声明；
  • 来源URL；
  • 核验日期；
  • 准确边界；
  • 它是耐用原则还是高频变化功能。

这样可以挡住一个常见错误：正文根据“我记得这个工具以前能这样”写，而不是根据当前资料。

10:00——把研究压成“批准事实包”

原始研究很多，起稿不应该全吃。

例如：

批准使用

  • 清楚指令和相关上下文能让任务边界更明确；
  • 示例可用于控制格式和行为；
  • 生产提示迭代应该配合测试/eval；
  • 可编辑写作区域等功能可能随产品、套餐、设备和灰度不同。

不批准

  • “某模型永远最适合创作”；
  • “用户平均节省N小时”；
  • 当前来源没有的功能；
  • 只凭记忆写的产品行为。

正式draft packet应该比research folder小。起稿需要的是选择，不是资料堆积。

10:30——先选结构，再要段落

如果结构重要，不要让模型一次同时决定结构和正文。

先草拟两到四种骨架。

流程题用时间线；比较题用决策标准；排错题用症状→原因→修法；分析题用论点和反例。

只用一个标准选：哪种形式让读者最容易完成他的决定？

批量生产时，顺便保留被放弃的结构，可以避免邻近文章自动继承同一个骨架。

11:00——用锁定资料起英文主稿

这时模型拿到：

  • production brief；
  • approved facts；
  • 已选结构；
  • 来源URL；
  • 发明边界。

可以明确写：

如果一句有用的话必须依赖批准资料里不存在的事实，不要自行补。删掉，或者标记给审核。

初稿因此可能没那么“自信”。这反而是好事。生产目标不是自信，是可控。

11:30——文风以前先做claim audit

逐句分类：

  • 事实；
  • 解读；
  • 建议；
  • 假设例子；
  • 转场。

事实要有证据路线；建议要有决策规则；假设要有可见标签。

先不要修节奏。

如果某一节连续三个断言没有来源，不要先去网上拼材料替已经写好的句子找背书；应该回到批准事实包重写。研究应该推动文章，而不是文章逼研究“事后证明”。

12:00——再做reasoning audit

现在看逻辑桥。

检查：

  • 结论真的来自证据吗？
  • 有没有把两个不同概念偷偷当成同一个？
  • “可能有帮助”是否一路滑成“必然改善”？
  • 产品能力是否没有评价标准就直接变成推荐？
  • 是否写明什么条件会改变答案？
  • 限制是否放在建议附近，而不是藏到最后？

生成文本最危险的地方，经常不是两头明显错，而是中间有一个“读起来特别顺”的逻辑跳跃。

13:00——检查结构是否和邻居撞骨架

拿这篇outline和站内附近文章对比。

看：

  • 开头机制；
  • H2数量和顺序；
  • 表格位置；
  • 案例套路；
  • 结尾动作。

不要为了“反AI”随机求新。但如果每篇编辑文章都以“五条建议”结束，站点就会逐渐像程序输出。

只有当结构更适合问题时才换。

13:30——终于可以改声音和压缩

现在删除：

  • 先宣布题目的空开头；
  • 换词重复的bullet；
  • 用模糊语气隐藏边界的句子；
  • 无功能形容词；
  • 无来源最高级；
  • 只是把标题复述一遍的正文。

把抽象建议换成决策语言。

弱：

为AI写作提供上下文非常重要。

强：

当模型无法从请求本身判断受众、资料边界或输出限制时补上下文；不会改变稿子的背景就不要塞。

后一种告诉你“什么时候需要”。

14:00——中文按目的本地化

不要把英文全文丢去逐句翻译然后结束。

中文环节应该同时拿到：

  • 同一套批准事实；
  • 英文主稿；
  • 中文受众；
  • 固定术语；
  • 允许调整句序和例子的权限；
  • “不得新增事实”的硬规则。

之后检查：

  • 事实一致；
  • 标题/搜索意图一致；
  • 术语自然；
  • CTA自然；
  • 链接和元数据正确。

中文应该像中文作者写的，但证据谱系和英文一致。

15:00——元数据和完整性检查

编辑质量很好，也可能被生产错误拖垮。

检查：

  • article_no三位补零；
  • title和H1完全一致；
  • slug和canonical路径一致；
  • EN canonical指向EN；
  • ZH canonical指向ZH；
  • alternate互相指；
  • Sources存在；
  • Related Reading指向预期内链；
  • 文件名可确定；
  • 所有hash必须在最终修改以后再生成。

一旦hash生成，后续定点修复应该产生有记录的新版本，而不是偷偷改“已经冻结”的文件。

15:30——真正的acceptance gate

QA分两类。

机械检查

  • 元数据；
  • 链接模式；
  • Sources数量；
  • hash；
  • EN/ZH配对；
  • 重复；
  • 占位和禁用套话。

编辑检查

  • 实用性；
  • 证据质量；
  • 推理；
  • 诚实边界；
  • 本地化；
  • 商业表达是否恰当。

机械PASS不等于编辑PASS。编辑PASS但没有稳定artifact，也不等于生产完成。

什么时候可以简化

两句话邮件不需要source ledger；私人场景脑暴不需要元数据；低风险想法列表也不必做完整claim audit。

这些情况可以走轻流程：

  • 不写当前事实；
  • 输出是一次性的；
  • 人已经掌握全部背景；
  • 审核成本非常低。

这些情况值得走完整流程：

  • 公开内容；
  • 事实会变化；
  • 批量很大；
  • 多语言；
  • 需要跨人交接；
  • 发布后修错成本高。

repair的基本规则

QA发现问题，不要默认把整篇重新生成。

只改最小授权范围：

  • 一个错误来源；
  • 一个metadata字段；
  • 一个无来源段落；
  • 一段重复；
  • 一个本地化错位。

然后重跑完整性检查，记录新hash。

这样可以保住已经合格的部分，不让一次小repair制造五个新变化。

一屏版本

  1. 定读者决策和边界。
  2. 从当前权威资料研究。
  3. 研究压成批准事实包。
  4. 用问题选择结构。
  5. 起英文主稿。
  6. 查事实。
  7. 查推理。
  8. 查结构重复。
  9. 改声音。
  10. 中文本地化。
  11. 验metadata、链接和hash。
  12. QA后再冻结。

这套顺序不是为了仪式感，而是让错误尽量在便宜的时候暴露。AI真正节省的不是“打字时间”，而是当每个阶段都知道自己负责真相、结构、语言还是验收时，返工会少得多。

给工作流加一个“停止生成”规则

AI辅助写作很容易进入无限循环，因为每一轮都能给出另一个“看起来也可以”的版本。稳定流程必须明确什么时候停止换整稿，什么时候进入验证。

可以提前设定停止条件：结构已经回答读者的真实决策；主要事实有来源；禁区没有越界；中文本地化保留原意。达到这些条件后，不再继续要求“再写一版完整的”，只做定点修改。

这样能防止两个问题：一是后期整稿重写把已经修好的事实错误重新带回来；二是五个不同版本被混在一起，最终没有统一作者结构。生成次数更多并不自动等于质量更高；证据和决策稳定后，越窄的修改越容易审计。

Sources

Related Reading