把 AI 任务拆成收集、起草、核验

提示词越写越长，结果却始终只有约 70% 能用，修改甚至比自己写还费时间。作者的解法是把一次大请求拆成 Gather、Draft、Verify：先整理事实，再生成草稿，最后对照材料找问题。

这套方法的重点，是让人能在步骤之间介入。作者用 14 个已合并 PR 生成发布说明的经历，展示了如何把整篇返工变成局部修改。对需要用 AI 写发布说明、技术文档的程序员，这个流程值得借鉴，但它的效果也有明确边界。

先整理事实，才能发现输入缺了什么

一次性要求 AI 交付成品，实际上塞进了四件事：找事实、判断重点、组织表达、检查结果。作者认为，前面漏掉的事实很难在后面补回来，写错的内容也可能被润色得更像真的。

这是作者对问题的解释，并非经过对照实验验证的模型规律。不过，他举的例子很具体：过去把 14 个 PR 的标题贴进去，直接索要发布说明，结果 AI 编造了一个功能名称，还把一项修复描述反了。

调整后的 Gather 阶段只做材料整理：把 14 个 PR 的标题和描述分成新功能、问题修复、内部改动，并标出描述模糊、无法向用户解释的条目，暂时不写发布说明。

模型标出了两个模糊 PR。作者再对照实际代码检查它们，整个步骤约两分钟，大部分时间花在人工确认上。

先暴露材料里的空缺，比让模型把空缺写顺更有价值。

Gather 的通用要求是列出任务需要的事实，每项附来源，无法确认的就标为 unknown。这里的来源首先承担追溯作用：让人知道一条说法从哪里来，方便回查。

草稿要允许存疑，检查要另开一轮

Draft 阶段才开始写作。作者给发布说明设定了明确格式：只使用前面分组后的材料，每项改动一行，使用朴素语言和现在时，不用营销措辞，排除内部改动。遇到不清楚的地方，标记 [CHECK]，不要猜。

两个约束各有作用。

「只使用已有材料」限制内容来源，减少模型补充听起来合理的细节；[CHECK] 则提供一种合规的停顿方式，让草稿可以带着待确认项交付。

但允许标记疑点，不代表模型一定能识别自己的所有猜测。作者后面的检查结果恰好说明，这个约束仍会漏网。

Verify 阶段要求模型把草稿与 Gather 的分组清单逐项比较，只报告三类问题：

• 草稿出现了哪些清单中没有的主张。
• 清单中哪些面向用户的改动没有写进草稿。
• 哪些句子可能让用户误解。

这一轮还有一个限制：只列问题，暂时不要重写。这样人可以先判断问题是否成立，再修改被标出的句子。

在作者的发布说明案例里，Verify 找到了一处编造的细节和一项遗漏的修复，最终经过两处小修改就发布了。相比之下，旧流程需要整篇返工。

作者展示了 chat.openai.com 和 claude.ai 的界面，并表示同一套三步流程可以跨聊天工具使用。原文没有给出模型版本或跨工具对照数据，能借鉴的是步骤与检查清单。

我的判断

我赞同把事实整理、写作和核对拆开，尤其是发布说明这种需要忠实对应代码变更的任务。分步之后，错误更容易定位：输入没交代清楚，就补材料；草稿遗漏了内容，就修对应条目。

但原文的约 70% 可用率、步骤之间投入约 30 秒，以及减少返工的效果，都是作者的经验描述。他没有提供样本量、模型版本、统一评价标准，也没有比较一份结构清晰的单次提示词。不能据此认定，三轮请求普遍优于一轮。

真正需要计入成本的，还有人工介入。案例中的两个模糊 PR，是作者查看实际代码后才确认的。团队如果没有人承担这一步，拆分流程也无法自动补齐事实。

Verify 能检查草稿是否忠于材料，不能证明材料本身正确。

如果 PR 描述就写反了，草稿准确复述它，核对也可能通过。涉及实际行为的疑问，仍要回到代码、测试结果或其他原始证据。对于内容很短、材料已经明确的任务，一次请求加人工检查也可能更省事。

能拿来做什么

• 用 AI 生成发布说明时，先提供真实的 PR 标题和描述，让它分类并标出疑点；人工核实后，再生成面向用户的条目。
• 写需要忠实依据材料的技术文档时，把「仅使用这些材料」和 [CHECK] 写进要求，让未确认内容留在明面上。
• 检查草稿时，单独发起一轮对照任务，明确检查新增主张、遗漏信息和歧义，确认问题后再局部修改。
• 把三轮交互优先用于需要他人阅读、出错后返工成本较高的内容，并观察节省的修改时间能否覆盖整理材料的投入。