元提示

Meta-prompting

PE-E-08内容已写满G05评测与自动优化第 20 层

评测元提示批量改写

一句话结论

元提示把提示词本身当作被优化对象，批量产出改写候选；候选必须经评测集筛选，增益需稳定才可投产，判定权不在元提示手里。

本页结构（可跳转）

层次图：元提示处在被优化对象的上一层、三种典型用法，以及「提高候选生成速度、判定权仍在评测集」的对照纪律。（本站自制）

01为什么需要它

元提示让模型生成或改进提示词本身，处在被优化对象的上一层，适合批量改写与风格归一。

它的产出质量仍然由评测集与判据决定：无判据的元提示只是换一种说法，候选再多也无法证明改好了。
逐条人工改写提示词在几条时可行，到几十条以上就变成不可维护的工作量；元提示的价值正是把这份工作量换成一个可复跑的流程，而判定权必须留在评测集手里。

适用边界

元提示有效的前提是已有可用基线与判据，它的收益是批量的候选生成速度，而不是判定能力；在没有基线与判据时，它不能替代人工判断，也无法证明改动有效。此外它固化了被给定的迭代策略与判据，判据宽松时会朝着宽松方向过度优化；对涉法务、安全、合规的提示词，人工逐条改写与评审的代价是应当接受的成本。

02机制说明

元提示（Meta-prompting）不改变模型与训练，只把提示词本身当作被优化对象：让一个模型生成或改进另一个提示词。

它的典型用法有三种：把粗糙指令扩写成完整提示、把长提示压缩成要点、以及把一组提示统一到同一风格与结构。
它的价值在于规模：当需要处理大量同类提示时，逐条人工改写不现实，而元提示可以批量产出候选。
工程要点有三条
1. 元提示必须附带明确的目标与约束（目标模型、输出契约、风格要求），否则候选会偏离
2. 候选必须经评测集筛选，不能直接采用
3. 应保留改写前后的对照记录，以便判断元提示带来的增益是否稳定。
需要警惕的是把元提示当成「自动写好提示词」的魔法：它提高的是候选生成速度，判定权仍在评测集。

03何时该用 / 何时不该用

按场景对照：先看条件，再看该怎么做。
类别	场景 / 条件（总结）	具体做法（细节）
该用	已有基线与判据、需要批量改写同类提示时	元提示能显著提升候选生成效率。
该用	需要把一组提示统一到同一结构或风格时	元提示适合做归一。
该用	提示词里存在大量重复模板、但每次只改少量字段时	让元提示批量产出候选，再按判据筛选。
不该用	无判据的场景	候选无法被筛选，改动有效性不可证。
不该用	替代人工判断	元提示提高候选生成速度，不提高判定能力。
不该用	跨出目标模型规格的改写	不声明目标模型与输出契约时，候选会朝错误方向漂移。

04实验台

shellbash

查看代码

# 把元提示产出的候选与基线放进同一评测集对比（判据先定，再谈改写）
cat > promptfooconfig.yaml <<'YAML'
prompts: [prompt-baseline.txt, prompt-rewritten.txt]
providers: [<目标模型>]
tests:
  - vars: { input: "<一条代表性输入>" }
    assert:
      - type: is-json
      - type: contains
        value: "<必须出现的字段名>"
YAML
npx promptfoo@latest eval -c promptfooconfig.yaml --no-cache

预期观察：两条提示词在同一批样本上各得一个通过率；候选只有高于基线才被采纳，否则退回并补一条负数例。结论以通过率差值陈述，不以元提示自己的评语为准。

promptmarkdown

查看代码

你是一名提示词改写工程师。把下面的原始提示词改写为更明确的版本。

硬约束：
1. 目标模型：<型号>；输出契约：<字段/格式>；风格：<要求>。
2. 保留原提示词中的全部业务规则与边界条件，不得新增未经确认的规则。
3. 逐条列出你做的每一处改动，并给出改动理由与所依据的约束编号。
4. 只输出改写后的提示词与改动清单，不要解释你的思考过程。

原始提示词：
<PASTE_PROMPT>

预期观察：产物分两部分：改写后的提示词与逐条改动清单；清单让评审者可逐条驳回到具体约束编号，而不是接受一个整体印象。不得把候选直接投产。

filemarkdown

查看代码

维护 `meta-prompt-log.md` 三张表：
1. 改写批次表：批次 id / 目标模型 / 约束清单 / 候选条数 / 评审人
2. 对照表：原提示词 id / 改写后 id / 评测集版本 / 通过率 / 是否采纳
3. 漂移表：候选名 / 偏离的约束编号 / 现象 / 处置
规则：未被约束清单覆盖的改动一律退回；同一批次里未被采纳的候选也要留档，用于判断元提示的增益是否稳定。

预期观察：读者能凭三张表回答「这批改写带来了多少稳定增益」与「候选最常在哪个约束上漂移」，而不是凭印象评价候选质量。

05证据

主张「元提示」在业界教学体系里是独立列出的提示技术条目，与 APE 等自动生成路线并列，而不是某个模型的私有技巧。

分级community

来源S-0066 https://www.promptingguide.ai/

原文

展开原文关键句

Prompting Techniques → Zero-shot / Few-shot / CoT / Meta Prompting / Self-Consistency / Prompt Chaining / ToT / RAG / ART / APE / Active-Prompt

主张「让模型生成指令」这条路线的收益是可量化的：自动生成的指令在 24 个 NLP 任务中的 19 个上达到或超过人工标注者写的指令。

分级paper

来源S-0050 https://arxiv.org/abs/2211.01910

原文

展开原文关键句

Experiments on 24 NLP tasks show that our automatically generated instructions … achieve better or comparable performance to the instructions generated by human annotators on 19/24 tasks.

主张把提示词本身当作被优化对象、由模型生成候选再由指标筛选，其产物可以超过人工设计的提示词，但收益按任务差异很大。

分级paper

来源S-0051 https://arxiv.org/abs/2309.03409

原文

展开原文关键句

the best prompts optimized by OPRO outperform human-designed prompts by up to 8% on GSM8K, and by up to 50% on Big-Bench Hard tasks.

06术语

术语元提示　Meta-prompting

界定让模型生成或改进提示词本身的提示方式，处于提示词与被优化对象之间的上一层。

07失效模式

把元提示产出的候选直接投产没有评测集筛选，它只是换一种说法，改好改坏都说不清。
元提示里不写约束目标模型、输出契约、风格都不声明，候选会朝错误方向漂移且无法判定该退回哪一条。
不留改写前后对照无法判断增益是否稳定，下一批仍在同一处重复犯错。
对同一批提示反复自我改写、从不引入新判据候选逐渐收敛到同一种风格，看起来稳定，实际掩盖了结构性缺陷。
把元提示当成微调或元学习的同义词以为它能改变模型本身，于是跳过了它真正需要的评测集与判据。

08在本站知识结构中的位置

所属分组: G05评测与自动优化
依赖深度: 第 20 层（同层节点彼此无先后约束）

前置PE-E-07→PE-E-08 本节点→后继PE-E-09

在交互全景图中定位本节点。