让 AI 自己挑自己的刺：一份"生成—评估—修订"的提示词工程指南

如果你经常用大模型写周报、做方案、出代码，大概率遇到过这种情况：

提示词写得很认真，模型第一次输出也像模像样。但仔细一看——数字是编的、用户反馈被美化了、下周计划全是"加大投入"式的空话。你让它"再改改"，它换个说法继续编。

问题不在模型，也不在你写的提示词太短。问题在于：你只要求它"写出来"，却没有要求它"写出来之后，自己审查一遍再交付"。

Anthropic 在 2024 年 12 月发布的《Building effective agents》中，把"评估—优化工作流"（evaluator-optimizer workflow）列为智能体系统最核心的几种模式之一：一个 LLM 调用负责生成响应，另一个负责提供评估和反馈，两者在循环中迭代；适用的前提是"有明确的评估标准，且迭代修订能带来可衡量的改善"，这类似于人类作者在打磨一份文档时的反复写作过程。

换句话说，"写完后自己挑刺再改一遍"，不是民间技巧，而是被主流 AI 工程实践认可的工作流。

但要小心——这个工作流有效果，也有边界。本文把它落到可直接复用的提示词模板上，并讲清楚什么时候该用、什么时候它会失灵。

一、为什么"自检"这件事真的有用

大模型生成文本和评估文本，是两类相互竞争的认知任务。一次性要求模型"既写出又判断写得好不好"，它往往会顾此失彼。

把它拆成两步：

1. 生成阶段：专注把内容产出来，不停下来自我怀疑；

2. 评估阶段：切换成一个"挑剔的审查者"，对照明确标准找问题；

3. 修订阶段：根据反馈改稿。

Anthropic 明确指出，这种"生成—评估—反馈"循环特别适合"首次生成通常不够好、但质量又很重要"的任务，例如文学翻译、复杂搜索、代码生成、API 文档、客户沟通、SQL 查询等。

OpenAI 的提示词工程最佳实践也从侧面支持了这件事：他们建议"尽可能具体、详细地描述期望的上下文、结果、长度、格式、风格等"，以及"提供参照文本（grounding）以减少模型编造"。这两点恰恰是"让模型自检"能有效运转的前提——标准必须明确，事实必须有锚点。

二、关键边界：自检不是万能药

这里必须泼一盆冷水。Learn Prompting 在 2026 年发布的反射提示（reflection prompting）指南中，诚实地指出了自检的失效边界：

💡自检真正发挥作用的地方：

• 有可验证结果（代码能否编译、答案能否验算、数据能否通过 schema 校验）

• 长文写作中结构和连贯性比创意更重要

⚠️自检悄悄失效的地方：

• 没有外部信号可参照时，模型常常"横向漂移"而非"向上提升"——改得更顺手，但不更准确

• 面对自己无法验证的事实时，模型往往会确认幻觉而非纠正幻觉——它不知道自己不知道什么

• 在创意写作上，自检常常让文字变得保守、平庸

这给我们一个非常务实的启示：

"自检 + 外部验证"永远胜过"自检 + 信任"。

也就是说，提示词里不能只写"请检查你自己的输出"，而要给模型一个可对照的真相源——原始数据、参照文档、schema 约束、或者干脆接一个编译器/校验器。

三、把"自检"固化进提示词的四个部件

基于上面的依据，一个带自检能力的提示词，应该由以下四块组成：

1. 任务与约束（对应 OpenAI "be specific" 原则）

把任务、受众、输出格式、长度、风格写清楚。OpenAI 明确指出："写一首关于 OpenAI 的诗"是低效的，"写一首简短的、鼓舞人心的诗，聚焦 DALL-E 产品发布，模仿某位著名诗人的风格"才是高效的。

2. 事实锚点（对应 OpenAI "provide grounding" 原则）

把所有"模型不允许脱离"的事实材料，用"""或###等分隔符清晰地包起来，并与指令区分开。OpenAI 强调："LLM 容易在没有足够上下文时编造信息，提供参照文本可以对抗这种倾向"。

3. 自检段（核心）

明确要求模型在交付前执行"挑刺—修订"循环，并且：

• 指定一个具体的批判者角色（不要笼统地说"检查质量"）

• 要求列出至少 3 处具体问题

• 要求逐条修订并说明改了哪里

• 最后跑一个可打勾的检查清单

4. 硬约束

明确禁止项：不允许编造数字、不允许引用材料中不存在的事实、遇到不确定必须显式声明而非猜测。

四、可复制的通用模板

下面这份模板把上面四块串起来，可直接套用到周报、方案、代码、内容创作等场景：

你是一名{{具体角色}}，请基于下方材料完成{{具体任务}}。## 任务- {{核心动词导向的任务描述，避免"稍微分析一下"这类模糊词}}- 输出格式：{{Markdown 表格 / 分段 / JSON schema}}## 背景材料"""{{起止时间、渠道、原始数据、用户原话等所有事实锚点}}"""## 硬约束- 所有数字必须能在"背景材料"中找到对应- 用户反馈只能引用材料中的原话或标签，禁止补写- 材料中不存在的信息，改写为"建议下一步收集 XX 数据"- 输出长度：{{具体字数或段落数}}## 自检环节（必须执行）写完正文后，停下，以"{{挑剔的资深角色}}"视角重新审视：1. 找出至少 3 处问题（事实错误 / 数字越界 / 结构缺陷 / 推断过度）2. 对每处问题给出 1-2 句具体改写建议3. 按建议逐条修订原输出，并标注"第 X 条已修订"4. 修订后，对照以下清单逐项打勾：   □ 所有数字均来自背景材料   □ 未引用材料中不存在的事实   □ 每个判断都有明确依据   □ 输出格式符合要求   □ 挑出的问题已全部修订## 最终输出仅输出修订后的正文（不含自检过程）。
跑出来的结果会有两个本质变化：

• 数字不再凭空冒出来——因为硬约束要求"所有数字必须能在背景材料中找到对应"

• 下周计划不再空泛——因为挑刺环节会逼着模型把每条计划对应到本周的某个具体异常点上

五、跨场景套用

内容创作（公众号选题）：自检段指定批判者角色为"挑剔的主编"，检查项包括"标题是否有具体冲突感""导语是否有可代入场景""是否出现'赋能/抓手/闭环'等空话"。命中空话必须替换成具体描述。

代码研发（SQL 改写）：自检段要求模型以"严格的 SQL reviewer"视角，列出至少 3 个潜在问题（性能、可读性、边界条件），再输出修订版。如果有条件，把修订版真正丢到数据库里跑一遍——这正好契合"自检 + 外部验证"的原则。

产品方案 / PRD：自检段要求以"挑剔的技术负责人"视角检查可行性、资源估算、风险点，并逐条修订。

六、三个必须记住的边界

写进提示词里的"自检"不是银弹。在套用上面的模板时，请始终记往：

⚠️第一，自检不能替代事实核查。

模型对自己无法验证的事实，往往会确认幻觉而非纠正幻觉。凡是涉及真实数据、真实用户反馈、真实市场情况的内容，必须提供原材料作为锚点，或由人工复核。

⚠️第二，评估标准必须先定义清楚。

Anthropic 特别强调，evaluator-optimizer 工作流适用的前提是"有明确的评估标准"。如果你的提示词只写"请检查质量"，模型就会陷入"不断挑小毛病、不断小修小补"的死循环，改来改去也不收敛。必须给出具体的检查维度。

⚠️第三，设置停止条件，控制成本。

每多一轮评估和修改，就多消耗一轮 token 和时延。Anthropic 建议"在开始迭代之前，先定义最大迭代次数和明确的质量阈值"。在单轮提示词里，这意味着自检段不要要求"无限循环改进"，而是固定为"一轮挑刺 + 一轮修订 + 一轮清单打勾"。

七、今天就能做的两个动作

1. 翻出你上周写过的最失败的一个提示词，把上面的"自检环节"和"硬约束"两段塞进去重跑。重点观察：编造的数字是否消失了？空泛的结论是否变少了？

2. 把"自检段"作为团队提示词模板的标准件。下次任何人写新提示词，默认带自检。你会发现，80% 的"AI 胡说八道"问题，在自检段面前都会现形。