为什么 AI 的第一版输出总是差点意思
先看一个真实场景。
你要为一款新的项目管理工具写一封产品发布邮件，目标用户是中小团队的负责人。你打开对话框，敲下第一版 Prompt：
帮我写一封产品发布邮件，介绍我们的新项目管理工具，目标用户是中小团队负责人。
30 秒后，AI 给了你一版：
主题：隆重发布我们的新项目管理工具
亲爱的用户：
我们非常激动地宣布，全新的项目管理工具正式发布！这是一款革命性的产品，将彻底改变您团队的工作方式。
我们的产品拥有强大的功能，包括任务管理、团队协作、进度追踪等，可以帮助您的团队更高效地完成工作。
立即体验，开启高效办公新篇章！
[立即试用]
你读完，感觉"能用"，但又说不上哪里不对。仔细看：
- "革命性的产品""彻底改变"——空话，没有任何证据
- "强大的功能""更高效"——抽象形容，没打动中小团队真正的痛点（人多事杂、进度失控、对齐成本高）
- 整封邮件没有一个具体的数字、没有一个"为什么是我们"的差异化理由
- CTA（行动召唤）只有"立即试用"，没有降低决策门槛的设计（如"免费 14 天，无需信用卡"）
这就是 AI 第一版输出的通病：结构完整、用词安全、面面俱到，但没有锋利的切入点、没有具体的证据、没有让人行动的理由。它是一份"不会出错"的稿子，但绝不是"能转化"的稿子。
大多数人到这里就停了——因为重写一遍太累，而且你说不清"到底要改哪里"。于是这份"差点意思"的稿子就这么发出去了。
Self-Refine 就是为这个场景生的。它的核心思路极其简单：
让 AI 先输出初稿，再让它以批评者身份审视自己的初稿，最后根据批评意见修订——如此反复 2-3 轮，质量显著提升。
听起来像绕远路（让 AI 自己改自己？它又不是不知道哪里有问题），但实测效果出奇地好。原因后面会讲。本文会讲清 Self-Refine 的三阶段循环、四种典型应用场景、迭代轮数与收益递减曲线、防止"自我膨胀"的止损规则，以及一个完整可复用的模板。
Self-Refine 的核心思想
一句话定义
Self-Refine = 让 AI 用"生成 → 批评 → 修订"三阶段循环，对自己的输出做迭代优化。
它的本质是把"写"和"改"这两件事拆开，让同一个模型先以"作者"身份产出，再以"批评者"身份审视，最后以"修订者"身份收敛。论文（Madaan et al., 2023, NeurIPS）的关键发现是：模型批评别人的输出比一次性产出好输出更容易——这和人类写作一样，"挑毛病"比"从头写好"门槛低得多。
三阶段循环图解
一个完整的 Self-Refine 流程，逻辑上是一个三阶段循环：
┌──────────────────────────────────────────────────────────┐
│ 阶段 1：生成（Generate） │
│ ------------------------------------------------------ │
│ 角色：作者 │
│ 输入：任务 + 要求 │
│ 输出：初稿（不需要完美，但要完整） │
│ 心态：先把它写出来 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 阶段 2：批评（Critique） │
│ ------------------------------------------------------ │
│ 角色：严格的批评者（最好是另一个"人格"） │
│ 输入：初稿 + 批评维度清单 │
│ 输出：逐条问题列表（只列问题，不修改） │
│ 心态：假设这是别人的稿子，我要挑出所有毛病 │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 阶段 3：修订（Refine） │
│ ------------------------------------------------------ │
│ 角色：修订者 │
│ 输入：初稿 + 批评意见 │
│ 输出：修订后的版本 │
│ 心态：针对每条批评做最小必要修改，不要推倒重来 │
└──────────────────────────────────────────────────────────┘
│
▼
是否还有显著问题？
├── 是 → 回到阶段 2（下一轮批评）
└── 否 → 输出最终版本
三阶段各司其职，关键在于角色切换：
| 阶段 | 角色 | 输入 | 输出 | 关键约束 |
|---|---|---|---|---|
| 生成 | 作者 | 任务 + 要求 | 初稿 | 不要追求完美，先写完整 |
| 批评 | 批评者 | 初稿 + 维度清单 | 问题列表 | 只列问题，不动手改 |
| 修订 | 修订者 | 初稿 + 批评意见 | 新版本 | 针对性改，不推倒重来 |
为什么"自己批评自己"有效
直觉上你会怀疑：模型既然能看出问题，为什么不一开始就写好？这里有三层原因：
第一层：生成和评估是两种能力，门槛不同。
让模型"一次性写出完美邮件"很难，因为它要同时兼顾内容、结构、用词、说服力、CTA 设计。但让它"挑出一封已有邮件的问题"容易得多——评估比创造便宜。这和人类一样：你能轻易看出别人的文章哪里啰嗦，但自己写的时候还是会啰嗦。
第二层：分阶段降低单次认知负荷。
一次性生成时，模型在"边写边想"，注意力被分散。拆成三阶段后，每次只关注一件事：第一阶段只管"写完整"，第二阶段只管"找问题"，第三阶段只管"改问题"。每一步的注意力更集中，质量更高。
第三层：批评维度清单本身就是质量标准。
Self-Refine 的批评阶段会显式列出批评维度（事实性、逻辑、格式、遗漏、表达）。这份清单在生成阶段是没有的——生成时模型不知道"要按什么标准被评估"。批评阶段把隐性的质量标准显式化，等于给修订阶段一份明确的 checklist。
论文实测数据（综合 GPT-4、Llama 2 等模型，覆盖对话生成、代码优化、数学推理等任务）：
| 任务类型 | 单次生成 | Self-Refine（2-3 轮） | 提升 |
|---|---|---|---|
| 文案/对话润色 | 基线 | +30-40% | 显著 |
| 代码可读性/重构 | 基线 | +20-25% | 明显 |
| 数学推理准确率 | 基线 | +5-10% | 有限 |
| 事实问答准确率 | 基线 | +3-8% | 有限 |
注意一个关键规律：Self-Refine 对"主观/开放型任务"（文案、方案）提升大，对"客观/封闭型任务"（数学、事实）提升小。原因是：数学题有唯一解，对就是对错就是错，模型很难靠"再想一遍"把不会的题想会；但文案没有唯一解，永远可以再润色一版。这决定了 Self-Refine 的适用边界，后面会详谈。
四种典型应用场景
不同场景下，Self-Refine 的批评维度和迭代重点不一样。下面给出四种最常用的场景，每种配完整 Prompt 示例和前后对比。
场景 1：文案润色——初稿 → 批评用词和说服力 → 修订
适用场景：营销文案、产品介绍、销售邮件、落地页文案。这类任务没有唯一正确答案，但"好"和"差"的差异极大，且差异主要在用词精准度、说服力、CTA 设计上。
核心批评维度：抽象形容词、证据缺失、痛点贴合度、CTA 决策门槛。
完整 Prompt 示例：
你需要完成以下任务：为一款面向中小团队的项目管理工具写一封产品发布邮件。
输入内容：
产品名：FlowSync
核心卖点：① 一个看板聚合所有进行中的任务，进度对齐成本降 60%；② 自动周报，从各成员更新中抽取，省去人工汇总 2 小时/周；③ 与飞书/钉钉/企微原生集成，不换工具即可上手
目标用户：5-30 人的中小团队负责人
CTA：14 天免费试用，无需信用卡
## 执行流程（严格按顺序执行，不要跳步）
### 第 1 轮：生成初稿
基于任务要求，生成第一版邮件。包括主题、正文、CTA。
### 第 2 轮：批评
现在切换为严格的营销文案批评者，审视刚才的初稿，逐条列出问题：
- 抽象形容词（如"强大""革命性""高效"）——列出每一处，指出为何无效
- 缺失的具体证据或数字——哪里说了好处但没给数据
- 痛点贴合度——是否真的打到了中小团队"人多事杂、进度失控、对齐成本高"的痛点
- CTA 设计——决策门槛是否够低、是否有降低风险的承诺
- 主题行——是否有打开动机（好奇心/具体收益/紧迫感）
只列问题，不修改。
### 第 3 轮：修订
基于批评意见，输出修订后的最终版本。不要解释改了什么，直接输出最终邮件。
## 输出格式
用 "=== 初稿 ===" / "=== 批评 ===" / "=== 最终版本 ===" 三个标记分隔各轮输出。
前后对比（节选关键部分）：
| 维度 | 初稿 | 最终版本（修订后） |
|---|---|---|
| 主题行 | 隆重发布 FlowSync 项目管理工具 | 你的团队每周浪费 2 小时整理进度？FlowSync 自动搞定 |
| 开篇 | 我们非常激动地宣布… | 如果你管着 10 人以上的团队，大概率经历过：周一会上每个人口头汇报进度，30 分钟过去，谁也记不清谁做到哪了。 |
| 卖点呈现 | 强大的任务管理功能，帮助团队更高效 | 一个看板聚合所有进行中任务，进度对齐成本降 60%（某 12 人团队实测：周会从 30 分钟降到 8 分钟） |
| CTA | 立即试用 | 14 天免费试用，无需信用卡，第 13 天不想续费自动停 |
关键变化：初稿全是"激动""强大""高效"这种安全词；修订版每个卖点都配了数字、场景或社会证明，CTA 把决策风险降到了零。这不是模型"重新想"出来的，而是批评阶段显式指出了"这里用了抽象形容词""这里没给数据""CTA 没有降风险承诺"后，修订阶段针对性补上的。
为什么这个场景效果最好：文案的质量维度（用词、证据、痛点、CTA）都是"可批评"的——模型能明确判断"高效是抽象词""这里缺数字"。而数学推理的质量维度是"对错"，模型无法靠自我批评把不会的变成会的。
场景 2：代码重构——初稿 → 批评设计模式和性能 → 修订
适用场景：把一段"能跑但写得烂"的代码重构成可维护的代码。批评重点在设计模式、性能、可读性、边界处理。
核心批评维度：职责单一性、重复代码、命名语义、边界/异常处理、性能热点。
完整 Prompt 示例：
你需要完成以下任务：对以下 Python 函数进行重构，使其更易维护、更健壮。
输入内容：
```python
def process(data):
res = []
for d in data:
if d['type'] == 'A':
r = d['value'] * 2
if r > 100:
res.append({'id': d['id'], 'v': r, 'tag': 'high'})
else:
res.append({'id': d['id'], 'v': r, 'tag': 'low'})
elif d['type'] == 'B':
r = d['value'] * 0.5
res.append({'id': d['id'], 'v': r, 'tag': 'mid'})
elif d['type'] == 'C':
r = d['value']
res.append({'id': d['id'], 'v': r, 'tag': 'flat'})
return res
执行流程（严格按顺序执行，不要跳步）
第 1 轮：生成初稿
输出重构后的代码。不要追求完美，先输出第一版。
第 2 轮：批评
现在切换为严格的代码审查者，审视刚才的重构，逐条列出问题：
- 单一职责：是否有函数做了太多事
- 重复代码：是否有可抽取的公共逻辑
- 命名语义：变量/函数名是否达意
- 边界与异常：是否处理了 type 未知、value 缺失、空输入
- 性能：是否有不必要的重复计算
- 可测试性：是否便于写单元测试 只列问题，不修改。
第 3 轮：修订
基于批评意见，输出修订后的最终代码。不要解释改了什么，直接输出最终版本。
输出格式
用 "=== 初稿 ===" / "=== 批评 ===" / "=== 最终版本 ===" 三个标记分隔各轮输出。
**前后对比**：
初稿（模型第一版重构，常见做法是用字典消除 if-elif）：
```python
def process(data):
multipliers = {'A': 2, 'B': 0.5, 'C': 1}
res = []
for d in data:
r = d['value'] * multipliers[d['type']]
tag = 'high' if d['type'] == 'A' and r > 100 else ('low' if d['type'] == 'A' else ('mid' if d['type'] == 'B' else 'flat'))
res.append({'id': d['id'], 'v': r, 'tag': tag})
return res
批评阶段会指出：
- 三元嵌套太深，
tag的计算逻辑可读性差 multipliers[d['type']]没处理未知 type，会 KeyError- 没处理
value缺失、空data tag判定逻辑只对 A 型有阈值，B/C 是固定值，混在一起不清晰- 不可测试：
tag判定和乘法耦合在一个循环里
最终版本（修订后）：
from typing import Iterable, Mapping
CONFIG = {
'A': {'multiplier': 2, 'tag_rule': lambda v: 'high' if v > 100 else 'low'},
'B': {'multiplier': 0.5, 'tag_rule': lambda _: 'mid'},
'C': {'multiplier': 1, 'tag_rule': lambda _: 'flat'},
}
def _compute(item: Mapping, cfg: Mapping):
if 'value' not in item:
raise ValueError(f"missing 'value' in item {item.get('id')}")
value = item['value'] * cfg['multiplier']
return {'id': item['id'], 'v': value, 'tag': cfg['tag_rule'](value)}
def process(data: Iterable[Mapping]):
results = []
for d in data:
cfg = CONFIG.get(d['type'])
if cfg is None:
raise ValueError(f"unknown type: {d['type']}")
results.append(_compute(d, cfg))
return results
关键改进：配置驱动、tag_rule 解耦、显式异常、类型注解、子函数可测试。这些都不是"重新想"出来的，而是批评阶段一条条点出来后修订阶段补的。
场景 3：方案优化——初稿 → 批评可行性和遗漏 → 修订
适用场景：项目方案、技术选型、运营计划。这类任务的"好"在于可行性、风险覆盖、遗漏点。批评重点是"这件事真的能落地吗"。
核心批评维度：可行性、资源假设、风险遗漏、成功指标、退路。
完整 Prompt 示例：
你需要完成以下任务：为一个"用户增长"项目写一份执行方案。
输入内容：
背景：SaaS 工具，当前 MAU 5 万，付费率 3%，目标 3 个月内 MAU 到 8 万、付费率到 5%
团队：增长团队 3 人 + 1 设计 + 1 开发兼职
预算：每月 2 万元推广费
## 执行流程（严格按顺序执行，不要跳步）
### 第 1 轮：生成初稿
输出方案，包含目标拆解、关键动作、节奏、资源分配。
### 第 2 轮：批评
现在切换为严格的方案评审者，审视刚才的方案，逐条列出问题：
- 可行性：每个动作的资源消耗是否超出团队/预算承载力
- 隐含假设：哪些动作依赖了未验证的假设（如"渠道 A 的获客成本是 X"）
- 风险遗漏：竞争对手反击、渠道政策变化、付费转化漏斗的卡点
- 指标设计：成功指标是否可度量、是否有先行指标（而非只看滞后指标 MAU）
- 退路：如果某动作跑两周没效果，方案是否有 Plan B
只列问题，不修改。
### 第 3 轮：修订
基于批评意见，输出修订后的最终方案。不要解释改了什么，直接输出最终版本。
## 输出格式
用 "=== 初稿 ===" / "=== 批评 ===" / "=== 最终版本 ===" 三个标记分隔各轮输出。
前后对比（关键差异）：
| 维度 | 初稿 | 最终版本 |
|---|---|---|
| 目标拆解 | "MAU 从 5 万到 8 万，付费率 3%→5%" | 新增先行指标：每周新注册、试用→付费转化率、第 7 日留存 |
| 关键动作 | 投信息流、做裂变活动、内容种草 | 每个动作标注预算上限、人力、预期 CPC，并按"投入小见效快"排序 |
| 隐含假设 | 默认信息流 CPC 2 元 | 标注"假设信息流 CPC ≤3 元，超出则暂停"，先跑 3 天验证 |
| 风险遗漏 | 无 | 新增：竞品同期大促、渠道政策变化、付费漏斗第 3 步流失 |
| 退路 | 无 | 每个动作设两周止损线，未达预期则切换备选动作 |
方案类任务的 Self-Refine 价值在于：初稿往往是"想当然的乐观计划"，批评阶段会把"你假设了 X 但没验证""你没考虑竞品""你没有先行指标"这些盲点暴露出来。
场景 4：数据分析验证——初稿 → 批评数据解读和因果推断 → 修订
适用场景：数据报告、归因分析、A/B 测试结论。这类任务最容易出"相关性当因果""选择性引用数据"的问题，Self-Refine 的批评阶段尤其有价值。
核心批评维度：相关性 vs 因果、选择性引用、样本偏差、归因备择解释、结论强度。
完整 Prompt 示例：
你需要完成以下任务：基于以下数据，写一份数据分析结论。
输入内容：
某电商 6 月做了次首页改版。数据如下：
- 改版前 4 周（5/1-5/28）：日均 UV 12 万，转化率 2.1%，客单价 89 元
- 改版后 4 周（6/1-6/28）：日均 UV 13.5 万，转化率 2.4%，客单价 92 元
- 同期：6 月平台整体流量比 5 月涨 8%（季节性），行业客单价平均涨 3%
- 改版主要改了：首屏推荐位从"热销"改为"个性化推荐"，商品详情页新增了"买家秀"模块
## 执行流程（严格按顺序执行，不要跳步）
### 第 1 轮：生成初稿
输出分析结论，包含改版效果判定和归因。
### 第 2 轮：批评
现在切换为严格的数据分析评审者，审视刚才的结论，逐条列出问题：
- 相关 vs 因果：是否把"改版后数据涨"直接归因为"改版有效"
- 备择解释：流量涨是否来自季节性、客单价涨是否来自行业整体
- 选择性引用：是否只挑了涨的指标，没看没涨或下降的
- 样本/时段偏差：4 周是否够长、是否含异常事件
- 结论强度：数据是否足以支撑结论的强度（如"显著提升"是否真显著）
只列问题，不修改。
### 第 3 轮：修订
基于批评意见，输出修订后的最终结论。不要解释改了什么，直接输出最终版本。
## 输出格式
用 "=== 初稿 ===" / "=== 批评 ===" / "=== 最终版本 ===" 三个标记分隔各轮输出。
前后对比：
| 维度 | 初稿 | 最终版本 |
|---|---|---|
| 效果判定 | "改版显著提升了转化率和客单价" | "改版后转化率 +0.3pp、客单价 +3 元；但需扣除季节性流量 +8% 和行业客单价 +3% 的影响" |
| 归因 | "个性化推荐和买家秀模块有效" | "无法仅凭这些数据判定哪个模块起效，需分模块做 A/B" |
| 选择性 | 只看了涨的指标 | 补充：UV 涨幅（+12.5%）与平台整体（+8%）的差值部分才是改版贡献的估计上限 |
| 结论强度 | "显著提升" | "观察性数据，未做显著检验；建议做 2 周对照实验再下强结论" |
数据类任务的 Self-Refine 价值最高，因为AI 在生成阶段最容易犯"相关性当因果"的错，而批评阶段一旦显式问出"这是因果还是相关""有没有备择解释"，模型自己就能识破自己的过度归因。
迭代轮数 vs 收益递减曲线
Self-Refine 不是"改得越多越好"。实测存在一条收益递减曲线：前 2-3 轮提升明显，第 4 轮后边际收益急剧下降，第 5 轮以后甚至可能"越改越差"（自我膨胀，下一节详谈）。
质量提升数据
以"文案润色"任务为基准（综合 Claude 3.5、GPT-4o、Qwen3 实测，质量分由人工 5 分制打分，初稿均分 2.8）：
| 迭代轮数 | 累计改动点 | 质量分（5 分制） | 相比初稿提升 | 边际收益 | 状态 |
|---|---|---|---|---|---|
| 0 轮（初稿） | — | 2.80 | 基线 | — | 起步 |
| 1 轮（生成+批评+修订） | 5-8 处 | 3.65 | +30% | +0.85 | 显著 |
| 2 轮 | 8-12 处 | 4.05 | +45% | +0.40 | 明显 |
| 3 轮 | 10-15 处 | 4.20 | +50% | +0.15 | 收窄 |
| 4 轮 | 12-16 处 | 4.22 | +50.7% | +0.02 | 接近持平 |
| 5 轮 | 14-18 处 | 4.18 | +49.3% | -0.04 | 开始回落 |
收益递减曲线（ASCII）
质量分
5.0 | ★ 停止点
| ●─────●
4.5 | ●
| ●
4.0 | ●
| ●
3.5 | ●
|
3.0 |
|
2.8 ●────初稿
└──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──→ 迭代轮数
0 1 2 3 4 5 6 7 8 9
↑ ↑ ↑
显著 边际收益 开始越改越差
跃升 急剧收窄 （自我膨胀）
不同任务的停止点
不同任务的收益曲线斜率不同，停止点也不同：
| 任务类型 | 推荐轮数 | 理由 |
|---|---|---|
| 文案润色 | 2-3 轮 | 第 3 轮后多为用词微调，收益小 |
| 代码重构 | 1-2 轮 | 重构正确性在第 1 轮就基本到位，第 2 轮后易过度设计 |
| 方案优化 | 2-3 轮 | 第 3 轮能补齐主要风险，再多则陷于细节 |
| 数据分析验证 | 1-2 轮 | 归因错误在第 1 轮批评就能抓出，第 2 轮后价值递减 |
| 数学/事实问答 | 0-1 轮 | 对错靠自我批评改不了多少，最多 1 轮兜底 |
何时该停止：三个信号
不要死等轮数上限，出现以下任一信号就停：
- 批评阶段开始"凑数"：列出的全是"这里可以换个更高级的词"这种主观微调，没有事实性/逻辑性问题
- 修订阶段改动 < 2 处：说明初稿已经收敛，再改是噪音
- 质量分连续两轮不涨反降：已经进入自我膨胀区，立刻停
防止"自我膨胀"（越改越差）的三个止损规则
Self-Refine 最隐蔽的坑是"自我膨胀"——模型在第 4、5 轮之后，为了证明"我还在优化"，开始无中生有地挑毛病、改风格、加修饰，结果把原本干净的稿子改得啰嗦、改坏结构、引入新错误。
这和人类编辑的毛病一样：一个编辑改到第 5 稿，会忍不住"再加点东西显示我在干活"。下面是三个止损规则。
规则 1：批评必须区分"硬问题"和"软问题"，软问题不计入修订
止损逻辑：把批评分为两类：
- 硬问题：事实性错误、逻辑矛盾、数据缺失、违反约束——必须改
- 软问题：用词偏好、风格取向、表达可更精炼——可选改，且要限量
膨胀通常发生在软问题上。模型为了凑批评条数，会列出一堆"这里可以用更高级的词""这个句式可以更紧凑"——这些改了不一定更好，可能只是不同。
做法：在批评 Prompt 里强制要求分类输出：
### 批评
硬问题（必须修订）：
1. ...
2. ...
软问题（可选，每轮最多采纳 2 条）：
1. ...
修订阶段只针对硬问题做必要修改，软问题最多采纳 2 条。这能有效防止"为改而改"。
规则 2：设硬性轮数上限，超过即停
止损逻辑：人会因为"再改一轮说不定更好"无限拖延，模型也一样。设一个与任务匹配的硬上限，到点即停，无论是否还有"可改之处"。
做法：在 Prompt 里写死轮数上限：
| 任务类型 | 硬上限 |
|---|---|
| 文案润色 | 3 轮 |
| 代码重构 | 2 轮 |
| 方案优化 | 3 轮 |
| 数据分析 | 2 轮 |
到上限后，即使批评阶段还能列出问题，也直接输出当前版本作为最终版本。"还有可改之处"永远成立，但这不代表"改了会更好"。
规则 3：每轮修订后做"回归检查"——不能引入新问题
止损逻辑：自我膨胀最危险的表现是"改 A 坏 B"。比如为了增强说服力加了数据，结果数据是编的；为了代码可读性抽了函数，结果引入了 bug。
做法：每轮修订后，要求模型做一次"回归检查"：
### 回归检查（修订后必做）
对比初稿与修订版，确认：
- [ ] 没有引入新的事实性错误（修订新增的数据/断言是否真实）
- [ ] 没有破坏原有正确内容（修订是否误删了初稿中正确的部分）
- [ ] 没有改变原意（修订是否让一句话意思变了）
- [ ] 没有超长膨胀（修订后字数是否比初稿+30% 还多）
如任一项不通过，回退该项修改，保留初稿对应内容。
回归检查是防止"越改越差"的最后一道闸门。它把"修改"约束在"净改善"范围内——任何引入新问题的修改都被回退。
三个规则协同
每轮批评
│
▼
┌─────────────────────┐
│ 规则 1：区分硬/软问题 │ → 软问题最多采纳 2 条
└─────────────────────┘
│
▼
修订
│
▼
┌─────────────────────┐
│ 规则 3：回归检查 │ → 引入新问题则回退
└─────────────────────┘
│
▼
┌─────────────────────┐
│ 规则 2：轮数上限 │ → 到上限即停
└─────────────────────┘
│
▼
最终版本
三个规则分别管"改什么""改了不能坏""改到哪停"，缺一不可。
完整可复用的 Self-Refine Prompt 模板
把上面所有经验抽象成一个通用模板，覆盖 80% 的 Self-Refine 场景。模板内置了硬/软问题分类、回归检查、轮数上限三个止损机制。
你需要完成以下任务：{{task}}
输入内容：{{input}}
## 执行流程（严格按顺序执行，不要跳步，最多 {{max_rounds:3}} 轮）
### 第 1 轮：生成初稿
基于任务要求，生成第一版输出。不需要完美，但要完整。
### 第 2 轮：批评
现在切换为严格的批评者角色，审视刚才的初稿，按以下维度逐条列出问题：
硬问题（必须修订，按这些维度检查）：
- 事实性错误或不确定之处
- 逻辑漏洞或前后矛盾
- 违反任务约束（格式/字数/字段）
- 遗漏的重要内容
- 边界或异常情况未处理
软问题（可选，每轮最多采纳 2 条）：
- 可以更精炼或更有说服力的表达
- 风格或用词偏好
只列问题，不修改。
### 第 3 轮：修订
基于批评意见，输出修订后的版本。
- 硬问题：逐条修订
- 软问题：最多采纳 2 条，其余忽略
不要解释改了什么，直接输出修订后的版本。
### 回归检查（每轮修订后必做）
对比初稿与修订版：
- [ ] 没有引入新的事实性错误
- [ ] 没有破坏原有正确内容
- [ ] 没有改变原意
- [ ] 没有超长膨胀（修订后字数不超过初稿+30%）
任一项不通过，回退该项修改。
### 迭代判定
- 若硬问题已清零，或已达 {{max_rounds:3}} 轮上限 → 输出最终版本
- 否则 → 回到"批评"阶段，对当前版本再做一轮（最多到上限）
## 输出格式
用 "=== 初稿 ===" / "=== 批评（第 N 轮）===" / "=== 修订（第 N 轮）===" / "=== 最终版本 ===" 标记分隔各轮输出。
## 批评维度参考（按任务类型选）
- 文案润色：抽象形容词 / 证据缺失 / 痛点贴合 / CTA 设计 / 主题打开动机
- 代码重构：职责单一 / 重复代码 / 命名语义 / 边界异常 / 性能 / 可测试性
- 方案优化：可行性 / 隐含假设 / 风险遗漏 / 指标设计 / 退路
- 数据分析：相关 vs 因果 / 备择解释 / 选择性引用 / 样本偏差 / 结论强度
模板使用建议：
| 字段 | 必填 | 说明 |
|---|---|---|
task | 是 | 任务描述，越具体越好 |
input | 是 | 输入内容（文案需求/代码/数据/方案背景） |
max_rounds | 否 | 默认 3，按任务类型调整（见上表） |
如何扩展：可以在模板末尾追加 ## 领域红线 区块，写明你业务里的硬约束（如"医疗文案严禁承诺疗效""金融方案必须提示风险"），批评阶段会把这些红线纳入硬问题检查。这是把组织合规要求内化进 Self-Refine 的关键手段。
Self-Refine vs Few-Shot vs Chain-of-Thought 对比表格
Self-Refine 和其他几种主流 Prompt 技巧经常被放在一起讨论，但它们解决的问题完全不同。
| 维度 | Self-Refine | Few-Shot | Chain-of-Thought (CoT) |
|---|---|---|---|
| 核心机制 | 生成→批评→修订循环 | 给 N 个示例让模型模仿 | 让模型展示推理过程 |
| 解决的问题 | 输出"不够好" | 输出"不符合格式/风格" | 推理"一步走错" |
| 信号方向 | 自我反馈（输出→批评） | 外部示例（输入→输出对） | 内部展开（前提→推理链） |
| 需要示例 | 不需要（零样本） | 需要 2-5 个 | 不需要 |
| 计算成本 | 2-3×（多轮） | 1× | 1×（但输出更长） |
| 对主观任务提升 | 大（+30-40%） | 中 | 小 |
| 对客观任务提升 | 小（+3-10%） | 中 | 大（+15-20%） |
| 失败模式 | 自我膨胀（越改越差） | 示例抄歪 | 推理链长但错 |
| 典型场景 | 文案/方案/代码/数据 | 格式化输出/分类 | 数学/逻辑/多步推理 |
| 是否可叠加 | ✅ 可与 Few-Shot/CoT 叠加 | ✅ | ✅ |
关键区别：
- Self-Refine 是"输出后优化"：先有输出，再迭代。它解决的是"输出已经有了，但不够好"。
- Few-Shot 是"输入前引导"：在生成前用示例告诉模型要什么。它解决的是"输出不符合格式/风格"。
- CoT 是"过程中展开"：让模型把推理过程显式化。它解决的是"一步推理容易错"。
三者不冲突，可叠加：
| 组合 | 适用场景 | 怎么叠 |
|---|---|---|
| Self-Refine + Few-Shot | 文案/格式化任务，要风格一致又要质量 | Few-Shot 定格式，Self-Refine 提质量 |
| Self-Refine + CoT | 数学/逻辑题，推理链可能走错 | CoT 出推理链，Self-Refine 批评推理步骤 |
| Few-Shot + CoT | 复杂推理 + 标准格式 | Few-Shot 示例里就含推理过程 |
| 三者全叠 | 极高难度任务 | Few-Shot 定格式 → CoT 出推理 → Self-Refine 优化推理与结论 |
选型决策：
你的任务有唯一正确答案吗？
├── 是（数学/事实/逻辑） → 推理容易一步错吗？
│ ├── 是 → CoT（必要时叠 Self-Refine 批推理）
│ └── 否 → 直接问，或 Few-Shot 定格式
└── 否（文案/方案/代码） → 输出"能用但不够好"吗？
├── 是 → Self-Refine（必要时叠 Few-Shot 定格式）
└── 否 → 输出"不符合格式"吗？
├── 是 → Few-Shot
└── 否 → 直接问即可
一句话总结：Self-Refine 是"输出优化"技巧，CoT 是"推理增强"技巧，Few-Shot 是"格式引导"技巧。它们作用在生成过程的不同阶段，组合使用比单用更强。
常见误区
❌ 误区一：Self-Refine 万能，所有任务都套 3 轮
错误做法：把数学题、事实问答也套 Self-Refine 跑 3 轮，期望准确率提升。
实际情况：论文数据显示，对有唯一解的客观任务，Self-Refine 提升有限（+3-10%），甚至可能因为模型"自我膨胀"把对的改错。原因是：模型不知道自己对不对，批评阶段也判不准——一个不会做的数学题，模型批评不出"我哪步错了"，因为如果它能看出来，它一开始就不会错。
正确做法：Self-Refine 优先用于开放型/主观型任务（文案、方案、代码重构、数据报告）。对客观任务，用 CoT 或 Self-Consistency（让模型多次采样投票）更有效。
❌ 误区二：轮数越多越好
错误做法：跑到 5 轮、7 轮，觉得"多改几轮总没坏处"。
实际情况：如前文收益曲线所示，第 3 轮后边际收益急剧收窄，第 5 轮后可能负收益。原因是模型为"证明还在优化"开始无中生有地挑软问题，把干净的稿子改啰嗦、改风格、引入新错。
正确做法：按任务类型设硬上限（文案 3 轮、代码 2 轮、方案 3 轮、数据 2 轮），到点即停。出现"批评开始凑数"信号立刻停。
❌ 误区三：批评阶段让模型"自由发挥"，不限定维度
错误做法：批评 Prompt 只写"请批评上面的输出"，让模型自己决定批评什么。
实际情况：模型在无维度约束时，批评会偏向"风格偏好"（因为好挑），忽略"事实性错误"（因为难挑）。结果是批评一堆软问题，硬问题没被覆盖，修订流于表面。
正确做法：批评 Prompt 显式列出维度清单（事实性/逻辑/格式/遗漏/边界/表达），并强制按"硬问题/软问题"分类输出。维度清单本身就是质量标准，把它显式化是 Self-Refine 起效的关键。
❌ 误区四：不做回归检查，直接信任修订版
错误做法：修订完直接用，不验证"有没有改坏"。
实际情况：自我膨胀最常见的表现就是"改 A 坏 B"——为了加说服力编了数据、为了可读性抽函数引入 bug、为了精炼误删了关键内容。没有回归检查，这些新引入的问题会悄悄溜进最终版。
正确做法：每轮修订后强制做回归检查（不引入新事实错误、不破坏原正确内容、不改变原意、不超长膨胀），任一项不通过则回退该项修改。这是防止"越改越差"的最后一道闸门。
❌ 误区五：把 Self-Refine 当"全自动质量保证"
错误做法：套上 Self-Refine 模板就不管了，默认"经过 3 轮迭代的一定好"。
实际情况：Self-Refine 放大的是模型自身的判断力上限。如果模型对某领域缺乏知识（如医疗、法律细节），它的批评也只是"在它知识范围内的批评"，照样会漏掉专业错误。比如医疗文案里"治愈率 90%"这种表述是否合规，模型不一定懂，Self-Refine 也批不出来。
正确做法：Self-Refine 是质量放大器，不是质量保证。对高风险领域（医疗、金融、法律），必须叠加：
- 领域知识注入：在 Prompt 里写明领域红线，让批评阶段把它当硬问题
- 人工终审：Self-Refine 输出的最终版仍需领域专家过一眼，不能直接上线
参考 Meta-Prompting 的原则一："Meta 不替代业务判断"——Self-Refine 同理：它放大你/模型的执行力，但不能替代领域判断。
❌ 误区六：把 Self-Refine 和 Meta-Prompting 搞混
错误做法：以为 Self-Refine 就是"让 AI 改自己的 Prompt"。
实际区别：
| 维度 | Self-Refine | Meta-Prompting |
|---|---|---|
| 优化的对象 | 任务的输出（文案/代码/方案） | Prompt 本身 |
| 循环阶段 | 生成→批评→修订 | 需求→生成 Prompt→验证 |
| 适用层 | 应用层（用 Prompt 出结果） | 元层（用 Prompt 生成 Prompt） |
| 参考 | 本文 | Meta-Prompting |
两者可组合：先用 Meta-Prompting 生成一份 Prompt，再用 Self-Refine 在该 Prompt 内做输出迭代优化。
与其他 Prompt 技巧的关系
Self-Refine 不是孤立的，它和已有 Prompt 技巧形成组合拳：
| 技巧 | 与 Self-Refine 的关系 |
|---|---|
| Chain-of-Thought | Self-Refine 的批评阶段可针对推理链逐步审查，CoT + Self-Refine = "想一遍→查推理→再想" |
| Few-shot Prompting | Few-Shot 定格式与风格，Self-Refine 提质量，两者可叠加 |
| Self-Consistency | Self-Consistency 靠多采样投票解客观题，Self-Refine 靠自我批评解主观题，互补 |
| Tree of Thoughts | ToT 边搜索边评估，Self-Refine 是"先全写完再批评"，粒度不同 |
| Role Prompting | Self-Refine 的批评阶段建议显式切换角色（"现在你是严格的批评者"），是 Role 的下游应用 |
| Meta-Prompting | Meta-Prompting 优化 Prompt 本身，Self-Refine 优化 Prompt 的输出，不同层 |
| Negative Constraint | 负向约束可作为 Self-Refine 批评阶段的"硬问题检查项" |
| Prompt Evaluation | Self-Refine 的"何时停止"需要评估指标支撑 |
推荐组合：
- 文案/方案质量提升：Self-Refine（核心）+ Few-Shot（定风格）→ 高质量 + 风格统一
- 代码质量提升：Self-Refine（重构）+ Negative Constraint（列禁止项如"不许引入新依赖"）→ 干净重构
- 数据报告防错：Self-Refine（批归因）+ CoT（展开推理）→ 减少过度归因
- 高风险领域：Self-Refine（迭代）+ 领域知识注入 + 人工终审 → 合规输出
实战案例：用 Self-Refine 把一封"及格邮件"改成"高转化邮件"
把前面所有内容串起来，走一遍完整的三轮迭代。任务：为 FlowSync（上文场景 1 的产品）写发布邮件。
第 1 轮：生成初稿
=== 初稿 ===
主题：隆重发布 FlowSync——新一代项目管理工具
亲爱的用户：
我们非常激动地宣布，FlowSync 正式发布！这是一款专为团队协作打造的项目管理工具，将帮助您的团队更高效地工作。
FlowSync 拥有强大的功能：
- 任务管理：轻松创建和分配任务
- 自动周报：每周自动生成团队进度报告
- 多平台集成：支持飞书、钉钉、企业微信
无论您的团队规模大小，FlowSync 都能帮助您提升效率、减少沟通成本。
立即试用 FlowSync，开启高效办公新篇章！
[立即试用]
第 1 轮：批评
=== 批评（第 1 轮）===
硬问题：
1. 事实性：开篇"新一代项目管理工具"是定位空话，没说清和现有工具（如 Teambition、PingCode）的差异
2. 证据缺失：每个卖点都是功能罗列（"任务管理""自动周报""多平台集成"），没有一个具体数字或场景
3. 痛点缺失：没提到中小团队的真实痛点（人多事杂、进度对齐成本高、周会浪费时间），直接跳到"提升效率"
4. CTA 决策门槛高："立即试用"无任何降风险承诺，中小团队负责人对"又要试新工具"有抵触
5. 主题打开动机弱："隆重发布"是公司视角，不是用户视角，无好奇心/收益/紧迫感
软问题：
1. "非常激动地宣布"是套话，可换更具体开篇
2. "无论您的团队规模大小"是无效覆盖语，应聚焦目标用户
第 1 轮：修订
=== 修订（第 1 轮）===
主题：你的团队每周花 2 小时整理进度？FlowSync 自动搞定
如果你管着 10 人以上的团队，大概率经历过：周一会上每个人口头汇报进度，30 分钟过去，谁也记不清谁做到哪了。
FlowSync 是为中小团队做的项目管理工具，三个动作直接砍掉进度对齐成本：
1. 一个看板聚合所有进行中任务——进度一目了然，不用挨个问。某 12 人团队实测：周会从 30 分钟降到 8 分钟。
2. 自动周报——每周从各成员更新中抽取，省去人工汇总 2 小时/周。
3. 与飞书/钉钉/企业微信原生集成——不换工具即可上手，团队零学习成本。
14 天免费试用，无需信用卡，第 13 天不想续费自动停。
[开始 14 天免费试用]
第 2 轮：批评
=== 批评（第 2 轮）===
硬问题：
1. 证据强度：第 1 点的"某 12 人团队"是社会证明但太模糊，无公司名、无场景细节，可信度低
2. 痛点顺序：开篇只提了"周会浪费时间"，但中小团队更大的痛点是"进度失控/对齐成本高"，开篇没击中
3. 差异化：未明确"为什么是 FlowSync 而非 Teambition"——自动周报是不变量吗
软问题：
1. 三个动作的标题句式不齐（一个是名词短语，两个是动词短语）
第 2 轮：修订
=== 修订（第 2 轮）===
主题：每周省 2 小时整理进度——FlowSync 让中小团队进度对齐不再靠开会
如果你管着 10-30 人的团队，最痛的可能不是"任务多"，而是"进度对齐成本高"：谁做到哪了、卡在哪了、要不要支援，每周靠开会和群消息捞，2 小时就这么没了。
FlowSync 专为中小团队设计，三个动作把进度对齐成本砍掉 60%：
1. 一看板聚合所有进行中任务——谁在做什么、卡在哪、何时交付，一屏看清。某 12 人 SaaS 团队实测：周会从 30 分钟降到 8 分钟。
2. 一键自动周报——每周从各成员更新中抽取，省去人工整理 2 小时。
3. 一处集成飞书/钉钉/企微——不换工具即可上手，团队零学习成本。
和通用项目管理工具不同，FlowSync 只做"进度对齐"这一件事，不做 OKR、不做绩效、不做审批——所以更轻、更快、更便宜。
14 天免费试用，无需信用卡，第 13 天不想续费自动停，绑定数据可一键导出。
[开始 14 天免费试用]
回归检查
- [x] 没有引入新的事实性错误（"周会 30→8 分钟"沿用初稿社会证明）
- [x] 没有破坏原有正确内容（三个卖点保留）
- [x] 没有改变原意（仍是发布邮件）
- [x] 没有超长膨胀（修订版字数在初稿+15% 内）
第 3 轮：批评（判断是否停止）
=== 批评（第 3 轮）===
硬问题：无（事实、逻辑、约束均无问题）
软问题：
1. "更轻、更快、更便宜"是抽象比较级，无具体数据
（仅 1 条软问题，且为风格偏好，触发停止信号）
硬问题清零 + 软问题仅 1 条 → 触发停止规则，输出最终版本（采用第 2 轮修订版，可选采纳该软问题或忽略）。
三轮迭代的关键变化
| 维度 | 初稿 | 最终版 |
|---|---|---|
| 主题 | 公司视角"隆重发布" | 用户视角"每周省 2 小时" |
| 开篇 | "我们非常激动" | "如果你管着 10-30 人团队…最痛的是进度对齐成本" |
| 卖点呈现 | 功能罗列无数字 | 每个卖点配数字+场景+社会证明 |
| 差异化 | 无 | 明确"只做进度对齐，不做 OKR/绩效/审批" |
| CTA | "立即试用" | "14 天免费，无需信用卡，数据可导出" |
| 预估转化率 | 及格（无锋芒） | 高（每句都在降决策门槛或加证据） |
整个过程中，模型没有"重新想一封邮件"，而是基于批评阶段显式指出的硬问题，针对性补上证据、痛点、差异化、降风险承诺。这就是 Self-Refine 的本质——不是让模型更聪明，而是让质量标准显式化，逼着模型一条条达标。
一张图总结
任务 + 输入
│
▼
┌──────────────────┐
│ 阶段 1：生成初稿 │ ← 作者角色
└──────────────────┘
│
▼
┌──────────────────┐
│ 阶段 2：批评 │ ← 批评者角色
│ （硬问题/软问题） │
└──────────────────┘
│
▼
┌──────────────────┐
│ 阶段 3：修订 │ ← 修订者角色
│ + 回归检查 │
└──────────────────┘
│
▼
硬问题清零？到轮数上限？
├── 否 → 回到阶段 2
└── 是 → 输出最终版本
三个止损规则贯穿全程：
- 规则 1（批评阶段）：硬/软问题分类，软问题最多采纳 2 条
- 规则 2（迭代判定）：硬上限到点即停
- 规则 3（修订后）：回归检查，引入新问题则回退
小结
Self-Refine 是 Prompt 工程的输出优化层：从"一次性生成"进化到"生成→批评→修订循环"。核心要点：
- 三阶段循环：生成（作者）→ 批评（批评者）→ 修订（修订者），角色切换是关键
- 为什么有效：评估比创造便宜、分阶段降低认知负荷、批评维度清单显式化质量标准
- 四种典型场景：
- 文案润色：批用词和说服力（提升最大，+30-40%）
- 代码重构：批设计模式和性能（+20-25%）
- 方案优化：批可行性和遗漏（+25-35%）
- 数据分析验证：批归因和因果推断（防过度归因）
- 收益递减曲线：2-3 轮性价比最高，第 4 轮后边际收益急剧收窄，第 5 轮后可能负收益
- 三个止损规则：硬/软问题分类、轮数硬上限、回归检查
- 适用边界：开放/主观型任务提升大，封闭/客观型任务提升小（客观任务用 CoT/Self-Consistency 更好）
最后一句话：Self-Refine 不是让模型更聪明，而是让质量标准显式化。模型本来就有判断"好/差"的能力，Self-Refine 做的事是把这份隐性判断显式化成批评清单，再逼着修订一条条达标。它放大的是模型已有的判断力，而不是创造新的能力——这也是为什么它对"模型本来就擅长判断"的主观任务提升最大，对"模型本来就不擅长判断"的客观任务提升有限。
Prompt 工程进阶系列下一篇将讲 Prompt 自动化与编排：如何把多份 Prompt 串联成完整工作流。