我以前让大模型制作答辩 PPT 时，经常把要求一股脑写进 Prompt：

“帮我制作一份 10 页左右的英文答辩 PPT，每页不超过 5 个要点，需要包含研究背景、方法、实验结果和总结，并为每页添加演讲备注。”

看起来已经说得很清楚了，但模型交付时，还是可能少掉一两项：页数合适，却漏了实验结果；内容基本完整，却夹杂了中文；页面都做好了，最后才发现没有演讲备注。

这类问题让我逐渐意识到：需求写进 Prompt，不等于需求一定会被执行。

后来，我开始在 Prompt 里加入一份“验收清单”。这个方法并不复杂，却明显减少了大模型漏需求的情况。

为什么要求写得很全，模型还是会漏？

大模型接收到的往往不是单一任务，而是一组同时存在的目标：

• 完成主要内容；

• 遵守格式限制；

• 保留指定信息；

• 避免某些表达；

• 满足篇幅和语气要求。

当要求越来越多时，模型通常会优先完成最核心的任务，而把一些“边缘要求”弱化掉。尤其是要求分散在多段对话里，或者既包含内容创作又包含格式约束时，遗漏更容易发生。

所以，问题不一定是 Prompt 写得不够长，而是缺少一个明确的交付标准。

我的做法：生成前提取，生成后验收

现在遇到要求较多的任务，我会让大模型先把需求整理成清单，再开始生成；完成后，再按照同一份清单逐项检查。

可以直接复制下面这段 Prompt：

请先从我的要求中提取一份“验收清单”，区分：
1. 必须包含的内容；
2. 格式与篇幅要求；
3. 明确禁止出现的内容；
4. 最终需要交付的文件或附加信息。

确认清单后再完成任务。

完成后，请逐项对照验收清单进行自检：
- 已满足：说明对应位置；
- 未满足：直接修改后再交付；
- 无法判断：明确指出，不要自行假设。

最终只向我交付通过检查的版本，并附上一份简短的验收结果。

这段话真正有用的地方，不是让模型多说一次“已完成”，而是把模糊的自然语言要求，转换成可以逐项核对的标准。

验收清单最好写成可判断的条件

例如，“PPT 做得专业一些”就很难验收，因为不同人对“专业”的理解并不一致。相比之下，下面这些要求更容易检查：

模糊要求	可验收的表达
页数不要太多	总页数控制在 10～12 页
每页简洁一些	每页不超过 5 个要点，每个要点不超过两行
内容要完整	必须包含研究背景、方法、实验结果和总结
全部使用英文	标题、正文、图注和备注中不得出现中文
方便现场讲解	每页添加对应的英文演讲备注

我现在会尽量把“感觉型要求”改成“可观察条件”。因为只有能够判断是否满足，才谈得上验收。

一个容易忽略的细节：不要只让模型汇报

如果 Prompt 只是写：

请检查是否满足以上要求。

模型很可能简单回复“均已满足”，但不会真正修复问题。

因此，我会额外加上一句：

如果发现未满足项，不要只在检查结果中说明，请先修改成品，再重新验收。

这句话把“检查”从结果汇报变成了修订闭环。比如验收时发现第 7 页缺少实验结论，模型应该先补全这一页，再重新检查页数、语言和备注，而不是只告诉我“实验结果部分不完整”。对制作 PPT、写代码、整理申报材料或生成表格来说，这一点尤其重要。

哪些任务最适合使用？

我认为，验收清单最适合两类任务：

第一类是要求很多的任务。例如制作一份文档，既要遵守模板，又要控制篇幅，还要包含指定模块。

第二类是交付成本较高的任务。例如代码修改、表格生成和演示文稿制作。等文件生成后才发现漏项，返工往往比提前核对更麻烦。

当然，验收清单也不是万能的。它能减少“要求已经明确，但模型没有执行”的问题，却不能自动判断要求本身是否合理，也不能替代人工核对事实、数据和专业结论。

最后

使用大模型久了，我越来越觉得，一份好 Prompt 不只是告诉模型“要做什么”，还应该告诉它“怎样才算做完”。

需求负责指明方向，验收清单负责守住交付底线。

有时候，让大模型少漏一项，并不需要更复杂的提示词技巧，只需要在任务末尾补上一句：

请按照验收清单逐项检查，发现遗漏就先修改，再交付最终版本。

这句话很普通，但它让大模型从“生成一份答案”，多走了一步，变成“交付一份经过核对的结果”。