第3章：评估流程：五步闭环法

提示词评估这件事，说白了就是给提示词打分。但怎么打、打几分、打完分怎么办——这里头门道不少。

我刚开始做提示词工程时，也踩过坑。那时候写了个提示词，自己觉得挺完美，结果一上线，用户反馈乱七八糟。后来我才明白：评估不是拍脑袋，得有一套流程。

今天要聊的，就是这套流程——五步闭环法。它不是什么高深理论，而是我实战中反复打磨出来的套路。

第一步：定义目标

评估之前，先问自己一个问题：这个提示词到底要达成什么效果？

目标不清晰，评估就是瞎忙活。我见过太多人，上来就写测试用例，结果测了半天，发现根本不知道自己在测什么。

定义目标时，我习惯从三个维度入手：

• 准确性：输出内容是否与预期一致？
• 完整性：是否覆盖了所有关键信息？
• 可用性：输出结果是否可以直接使用？

举个例子。你写了个提示词，让AI生成产品描述。那目标可能是：

• 描述包含产品名称、功能、价格
• 语言风格符合品牌调性
• 字数控制在100-150字

目标越具体，后面的评估就越有方向。

第二步：设计测试用例

目标定好了，接下来就是设计测试用例。这一步，说白了就是给提示词出考题。

测试用例怎么设计？我总结了三类：

类型	说明	示例
正常用例	最常见的输入场景	“请生成一款智能手表的描述”
边界用例	输入极端或特殊的情况	“请生成一款价格0元的产品描述”
异常用例	输入错误或模糊的情况	“请生成描述”（缺少产品信息）

我曾经犯过一个错：只设计了正常用例。结果上线后，用户输入了“帮我写个东西”，AI直接懵了。从那以后，我每次都会加几个边界和异常用例。

设计测试用例时，还有个小技巧：每个用例都要写清楚预期结果。没有预期结果，你根本不知道AI答得对不对。

# 测试用例示例
用例编号：TC-001
输入：请生成一款智能手表的描述，价格2000元
预期结果：
- 包含“智能手表”关键词
- 提到价格2000元
- 语言风格简洁专业
- 字数在100-150字之间

第三步：执行评估

测试用例准备好了，那就开测吧。

执行评估时，我建议每次只测一个变量。什么意思？就是如果你改了提示词的措辞，就别同时改温度参数。否则你根本分不清是哪个改动影响了结果。

执行过程中，记得记录结果。我习惯用表格来记：

用例编号	输入	实际输出	是否通过	备注
TC-001	生成智能手表描述	输出包含手表名称、功能、价格	✅ 通过	字数略多，158字
TC-002	生成价格0元的产品描述	输出提示“价格异常”	❌ 未通过	需要优化边界处理

嗯，这里要注意：不要只记录“通过”或“不通过”。把实际输出也记下来，后面分析时用得上。

第四步：分析结果

数据拿到了，接下来就是分析。这一步，很多人容易犯一个毛病：只看通过率。

通过率当然重要，但它不是全部。我见过一个提示词，通过率90%，但剩下的10%全是致命错误——比如生成了错误的产品价格。这种提示词你敢用吗？

分析结果时，我一般会问自己三个问题：

• 失败用例有没有规律？ 比如都是边界用例出问题？
• 失败的影响有多大？ 是小问题还是大问题？
• 有没有隐藏问题？ 比如输出虽然正确，但格式不统一？

为什么会这样？因为有些问题，光看通过率是看不出来的。你得深入去看每一次输出。

第五步：迭代优化

分析完了，就该动手改了。这一步，我称之为“缝缝补补”。

迭代优化不是瞎改。你得根据分析结果，找到问题的根因，然后对症下药。

常见的优化方向有：

• 措辞调整：提示词太模糊？加几个关键词。
• 结构优化：提示词太长？拆成几步。
• 参数调优：温度太高？降一点。
• 增加约束：输出格式不统一？加个格式要求。

每次优化后，记得重新跑一遍测试用例。别偷懒，这一步不能省。

迭代几次后，你会发现提示词越来越稳。但也要注意：不要过度优化。我见过有人为了一个边界用例，把提示词改得又长又绕，结果正常用例反而出问题了。

闭环的意义

五步闭环法，说白了就是一个“定目标-出题-考试-改卷-补课”的过程。每一步都环环相扣，缺一不可。

你想想看，如果跳过“定义目标”，你都不知道考什么。如果跳过“分析结果”，你都不知道错在哪。如果跳过“迭代优化”，那评估就白做了。

这套流程，我用了很久。从最初的提示词小白，到现在能快速定位问题、精准优化，靠的就是它。

最后说一句：评估不是终点，优化才是。闭环的意义，就是让你不断逼近那个“最优解”。