写好 Prompt：从“灵感手写”到采样、A/B Test 与自动化评测-平芜编程栈

tldr:
1、好 prompt 是激活正确分布：底层原理
2、对于强 agentic 模型，过度规则会造成模型开始“执行规则”，而不是进入状态：不同模型，不同策略
3、编写prompt的采样也是在挖掘自己的真正需求：模型可以走多远、现在这个路径是不是正确的？
4、模型采样输出prompt和对应回答，高频采样模型回答，选择最优解，尝试其他方向再选：用向量激活向量
5、人工A/B test + ai评分：多轮测试稳定性+建立评测数据+自动化测试

一、先建立一个认知：Prompt 不是命令，而是分布激活器

大模型不是传统程序。

语言模型更像是：

给定上下文 → 激活某个语义/行为分布 → 采样一个可能输出

所以 prompt 的作用不是“强制模型执行某条命令”，而是通过语言、场景、角色、格式、示例、评价标准，把模型引导到某个输出区域。

比如这两种 prompt：

请自然一点，不要啰嗦，不要像 AI，不要说教，不要过度解释。

和：

像一个有经验的产品顾问一样回答：直接、具体、重视取舍，先指出核心问题，再给可执行建议。

除此之外，还记得：temperature、top_p、max_tokens、存在惩罚、频率惩罚这些采样参数吗？它们也是一部分。

二、好 Prompt 的定义：稳定提高目标输出概率

我现在更倾向于这样定义一个好 prompt：

好 prompt 不是偶尔产出一个神回复，而是能够稳定提高目标回复出现概率的上下文设计。

这句话里有几个关键词。

1. 不是单次效果，而是稳定分布

一次回答好，不代表 prompt 好。
可能只是采样运气好。

一个 prompt 要经过多输入、多轮次、多温度、多模型测试后，仍然稳定产出目标风格，才算真正有效。

2. 不是越完整越好，而是越有效越好

很多 prompt 写得很长，但里面充满冲突约束：

要简洁，但要全面。 要自由发挥，但必须严格遵守。 要自然，但每次必须包含三个部分。 要有创造力，但不能偏离任何细节。

这类 prompt 会让模型进入“执行规则”的模式，而不是进入目标状态。

尤其是强 agentic 模型，过度规则会让它从“自然完成任务”变成“表演自己正在遵守规则”。

3. 心智对齐

一千个人心里有一千个 prompt（哈姆雷特）。

你可以解释这些问题吗：什么是Agent？什么是Harness？什么是Prompt？

对于不同人脑子里对这些概念的理解，可能会导致完全不同的 prompt 设计。

模型可能需要理解什么是“我们”：“我们”可能是AI、可能是开发者、可能是用户；

三、不同模型，需要不同 Prompt 策略

prompt 不是通用的。
同一段 prompt 在不同模型上的表现可能完全不同。

1. 弱模型：需要脚手架

能力较弱的模型，通常更需要明确步骤、格式和约束。

例如：

请按以下结构回答： 1. 先总结用户问题； 2. 再列出三个原因； 3. 最后给一个建议； 每部分不超过三句话。

弱模型需要被“扶着走”。

2. 强模型：更适合状态激活

强模型本身有更好的语义理解、上下文补全和任务规划能力。
这类模型如果被过度限制，反而容易失去自然性和创造力。

对于强模型，更好的方式是：

你是一个严谨但不啰嗦的技术顾问。 回答时优先指出关键判断、隐藏风险和可执行下一步。 不要写成百科解释，也不要为了完整而展开无关背景。

这类 prompt 没有规定每一步怎么做，但激活了一个清晰的行为状态。

3. 推理型模型：目标与验证标准更重要

推理模型通常不需要你规定太多中间步骤，而更需要清楚定义：

目标是什么；
什么算成功；
有哪些约束；
哪些错误必须避免；
最终答案如何验收。

例如：

请解决这个问题。优先保证结论正确。 如果信息不足，请指出缺失信息。 不要为了给出答案而猜测关键事实。 最后用一小段说明你的置信度和主要不确定性。

四、Prompt 编写本身也是需求发现

很多时候，我们以为自己知道想要什么，其实只是知道一个模糊方向。

比如：

我想要一个更好的总结 prompt。

但“更好”是什么意思？

可能是：

更短；
更有洞察；
更适合发给老板；
更像咨询顾问；
更保留细节；
更适合行动决策；
更适合会议纪要；
更适合知识沉淀；
更适合二次传播；
更少废话；
更有观点。

这些差异并不是一开始就能想清楚的。

只有当你看到大量候选输出后，才会发现：

原来我不是想要“全面”，我是想要“能帮我决策”。 原来我不是想要“正式”，我是想要“有判断”。 原来我不是想要“详细”，我是想要“抓重点”。

所以 prompt 采样不是简单测试效果，它本身也是在挖掘需求。

prompt 迭代的过程，就是通过模型输出显化自己的隐性偏好。

五、一个有效方法：意图展开 + 响应映射

六、用模型生成候选 Prompt

我现在很推荐一种采样 prompt 的方法：

不要直接让模型回答原问题，而是先让模型枚举用户可能真正想继续问什么，再给出对应回答。

也就是“意图展开 + 响应映射”。

核心 prompt 可以是：

使用“意图展开 + 响应映射”。 不要直接回答原问题。 请先枚举 10 个“用户可能想继续问什么”，然后针对每个问题，给出一个示例回答。

这个方法的价值在于：
它不是让模型直接给你一个答案，而是让模型帮你展开“需求空间”。

当需求空间被展开后，下一步是让模型生成多个候选 prompt。

好的候选集合是：

Prompt A：专家诊断型。 Prompt B：反方质疑型。 Prompt C：新手教学型。 Prompt D：决策建议型。 Prompt E：风险审计型。 Prompt F：执行清单型。 Prompt G：高管摘要型。 Prompt H：苏格拉底追问型。 Prompt I：案例驱动型。 Prompt J：评分裁判型。

真正有价值的是探索不同方向，而不是在同一方向上换词。

七、不要选“最好的一次回答”，要选“更稳定的 Prompt”

有了候选 prompt 后，不能只让每个 prompt 跑一次。

因为单次输出有随机性。
你应该让每个 prompt 在多个测试用例上多次采样。

基本流程：

候选 prompt A ├── 测试用例 1 → 采样 5 次 ├── 测试用例 2 → 采样 5 次 ├── 测试用例 3 → 采样 5 次 └── ... 候选 prompt B ├── 测试用例 1 → 采样 5 次 ├── 测试用例 2 → 采样 5 次 ├── 测试用例 3 → 采样 5 次 └── ...

然后比较的不是某个单点神回复，而是整体分布。

一个 prompt 如果偶尔非常惊艳，但经常跑偏，它未必好。
另一个 prompt 如果上限没那么夸张，但稳定可靠，可能更适合生产。

八、建立 Prompt A/B Test

btw, 我vibe coding 了一个简单的 Prompt A/B Test 工具，欢迎试用和反馈：prompt_test

prompt A/B test 的核心是：
在相同输入、相同模型、相同采样参数下，比较不同 prompt 的输出效果。

一个最小 A/B test 可以包含：

prompt_id model temperature test_case_id input output judge_score human_preference failure_tags timestamp

示例表结构

字段	含义
prompt_id	当前 prompt 的版本
model	使用的模型
temperature	采样温度
test_case_id	测试用例编号
input	用户输入
output	模型输出
judge_score	AI 评分
human_preference	人工偏好
failure_tags	失败标签
notes	人工备注

A/B test 最重要的是保证对比公平：

同一批测试用例；
同一个模型；
相同采样参数；
相同上下文长度；
多次采样；
盲评更好；
人工偏好与 AI 评分分开记录。

九、自动化评测脚手架

有了 A/B test 之后，下一步是自动化评测。

一个 prompt evaluation harness 至少需要四层：

1. Prompt Registry：管理 prompt 版本 2. Test Dataset：管理测试用例 3. Runner：批量运行 prompt × test cases × samples 4. Evaluator：AI 评分 + 规则检查 + 人工标注

十、多轮测试稳定性

如果 prompt 用在多轮对话或 agent 场景中，单轮测试是不够的。

多轮测试要看：

模型是否保持任务目标；
是否逐渐漂移；
是否重复同一种话术；
是否忘记前文约束；
是否在用户追问时能修正；
是否能处理冲突信息；
是否能承认不确定；
是否能主动澄清。

一个多轮测试用例可以这样设计：

id:decision_summary_multiturn_001turns:-user:"帮我总结这段项目会议。"-user:"再短一点，给老板看。"-user:"哪些是需要他拍板的？"-user:"如果只能保留三条呢？"-user:"有没有你不确定但需要补充的信息？"expected_behavior:-不重复全部背景-能逐步压缩-能区分事实、判断和待确认信息-不编造负责人或截止时间

多轮测试特别容易暴露 prompt 的真实稳定性。

有些 prompt 单轮很强，但第二轮开始就失焦；
有些 prompt 初始平平，但多轮对话中非常稳。

十一、一个最小 Prompt Evaluation Harness

如果要快速落地，可以先做一个最小版本。

目录结构可以是：

prompt-eval/ prompts/ summarizer_v1.yaml summarizer_v2.yaml summarizer_v3.yaml datasets/ summarization_cases.yaml outputs/ runs/ evaluators/ judge_decision_summary.yaml scripts/ run_eval.py aggregate_results.py

十二、Prompt 迭代像进化算法

整个流程可以看成一个 prompt evolution loop：

定义目标 ↓ 意图展开 ↓ 生成候选 prompt ↓ 批量采样输出 ↓ AI judge 初筛 ↓ 人工 A/B 校准 ↓ 分析失败模式 ↓ 融合 top prompt ↓ 局部变异 ↓ 重新评测

这里有三个关键操作：

1. 变异

对已有 prompt 做局部改变：

更简洁；
更严格；
更少解释；
更强判断；
更强澄清；
更偏专家；
更偏教学；
更偏执行；
更偏审计；
更偏结构化。

2. 交叉

把多个优秀 prompt 的优点融合：

保留 A 的判断力、B 的简洁格式、C 的风险意识。

3. 压缩

把长 prompt 压缩成最小有效版本：

请将这个 prompt 压缩到 50%，保留核心行为激活点，删除重复规则和弱约束。

最终目标不是得到一个最长 prompt，而是找到：

最小、稳定、可解释、可评测的 prompt。

十三、总结

prompt 编写不应该停留在“我感觉这个更好”。

应该有更系统的方式，最后，一句话概括：

prompt engineering 的成熟形态，不是写出一段完美提示词，而是建立一个能持续发现需求、生成候选、采样比较、自动评测、人工校准和回归验证的迭代系统。

写好 Prompt：从“灵感手写”到采样、A/B Test 与自动化评测