提示词到底有没有用：两派吵了很久，其实早就同意了一件事

先说结论

1. 提示词不是”没用”，而是”不可靠”。同一段提示词，换一个上下文环境、换一次模型版本，行为就可能变——这是争了最久的那件事的真正分歧点。
2. 两派其实早就同意了一件事：必须测量。 有意思的是，这不是”反提示词”那派的独门主张——OpenAI 官方的提示词指南里，最佳实践一节就包含了”建测量提示词行为的测试与评测套件”和”把生产应用钉在具体的模型快照上”这两条（大意转述，非逐字引用）。
   ⚠️ 但要说清楚：这只是双方共同的最低要求，不等于”提示词的收益已经被证实”。提示词到底能带来多少提升，在更严格的实证研究里仍有分歧，本文没有第三方证据。
3. 提示词有三个地方确实有边际收益：约束输出格式、注入领域术语与判断标准、挑选示例。
4. 有两个地方基本没有：模型能力之外的知识与推理、需要外部实时事实的场景。注意限定条件——这两类不是”措辞技巧能补一点”，而是方向错了：正确的做法是接检索或工具，把事实来源搬进上下文，而不是继续改说法。

争议的两边各说了什么

“反方”的代表是一篇叫《Prompts aren’t Real》的文章（evaluation.club）。它的核心主张很直接：别把精力花在手调提示词上，去搭评测与优化流水线。它给的理由值得原样引用：

• 结构化输出”大多数时候“能遵守——比如你要求标题不超过 80 字符，它大部分时候照做，”但有时候它会彻底搞砸，把整个字段塞满垃圾”。即使用最强的模型，也还是有一小部分请求会失败。
• 更关键的是这句：给 agent 加一条新提示词，等于把它丢进一个”完全不同的上下文宇宙”——原来那套测试是在旧上下文里做的，新指令和已有的一堆指令叠加后，行为会被重新塑造。
• 而且”模型自己也可能在某天因为某些我们永远搞不清的原因改变行为“。
• 所以它的做法是：让模型读技能说明 → 生成大量对抗性场景 → 带技能跑一遍、不带技能跑一遍，看行为有没有真的改善；然后让机器去改提示词（原文提到过遗传帕累托这类优化方法，我没有细读它的实现，也没验证效果），循环到收敛——最后得到的提示词可能和最初那条完全不一样。

“正方”这边最权威的是官方指南。 OpenAI 的提示词工程文档开头对这件事的定义，大意是：提示词工程是”写出有效指令、让模型稳定地产出符合要求的内容”的过程——紧接着承认，因为模型输出是非确定性的，提示词这件事是艺术与科学的混合（转述其表述，关键词 consistently 取自原文）。

注意这个措辞：官方要的不是”能跑通一次”，而是”consistently（稳定地）”。而它给出的最佳实践里，恰恰包含了我上面引的那两条——建评测套件和锁定模型快照。

所以真正的一致点在这里：双方都承认”手调提示词只能靠碰运气”，都要求把它变成可测量的东西。分歧只在于你把时间花在哪：一边主张花在评测与自动优化上，另一边仍然提供一整套技巧清单。

把”偶尔失灵”变成一个数

《Prompts aren’t Real》里提了一个概念：pass^k（pass power k）——原文的语境是”要约束行为就得测量它，一个办法就是把测试跑很多遍”。

这里必须把两个容易混的指标分清楚，因为它们的含义正好相反：

• pass@k（能力上限）：同一个用例跑 k 次，至少有一次通过就算过。它回答”模型有没有可能做对”。
• pass^k（可靠性）：同一个用例跑 k 次，每一次都必须通过才算过。它回答”它是不是每次都能做对”。

生产环境要看的是后者。 单次成功毫无意义（模型本来就有不小概率蒙对）；”跑十次错一次”这种在演示里看不出来的问题，才是线上的真实事故来源。

# 示意代码：把"偶尔失灵"测量出来。K 是重复次数，cases 是你的用例集
K = 20
all_pass = any_pass = 0
for case in cases:
    results = [check(call_model(prompt, case)) for _ in range(K)]  # check 是你自己写的断言
    if all(results): all_pass += 1      # k 次全过
    if any(results): any_pass += 1      # 至少过一次

print(f"pass^{K} = {all_pass}/{len(cases)}   # 每次都过才算过 —— 可靠性")
print(f"pass@{K} = {any_pass}/{len(cases)}   # 有一次过就算过 —— 能力上限")

怎么读这两个数：如果 pass@20 很高而 pass^20 很低，说明模型有能力做对、但不稳定——这时候该做的是补断言、收紧输出约束、加校验重试，而不是继续改措辞。反过来如果两个都低，那是能力问题，改提示词基本没救。

注意”20 次全过”这件事本身的分量：在非确定性输出上，一个用例 20 次全过意味着方差极小；用例集越多，这个数越可信——单个用例全过不能说明什么，几十个用例的 pass^k 才有意义。

一张判断表：这类任务值得调提示词吗

一段最小可执行的流程

1. 先写断言，再写提示词。列出”什么样算过”（字段齐全、格式合法、事实引用可查、不许出现某类内容）。
2. 固定一个用例集（10~30 条，覆盖你真实遇到的边界情况）。
3. 跑 pass^k，记录基线。没有基线就没有优化。
4. 换一句话，再跑一遍，看通过率的增量——增量在噪声范围内就说明这句没用，删掉。
5. 锁定模型快照 + 定期复跑：官方指南建议把生产应用钉在具体模型快照上就是为了这个；模型一升级，全部重测。

这次没核实的

• 我没有做实测：本文的 pass^k 代码是示意写法，数字是示意，不是任何模型的真实通过率。
• 《Prompts aren’t Real》是一篇观点文章，不是论文，它举的例子（80 字符标题、结构化输出偶尔崩）来自作者自述，没有公开数据集。
• “遗传帕累托优化”这类自动优化方法我只核到原文提到，没有读它的实现细节，也没有验证效果。
• 官方指南的”技巧清单”本文没有逐条评估——它的定位是通用建议，个体差异很大。

参考来源

• Prompts aren’t Real（evaluation.club）——该文就发在这个站点的首页（URL 即根域，页面标题为 “Prompts aren’t Real”），作者未署名；本文引用的四句原话均出自该页
• OpenAI：Prompt engineering 指南——提示词工程的定义（强调 consistently）、建评测套件、锁定模型快照等最佳实践
• 本社区相关前作：提示词的失效边界写在选题池里——同类”先测量再下结论”的思路