如何摆脱“凭感觉”评估 AI 提示词
使用代表性案例、明确评分表、失败分类和成本意识，建立可重复的提示词评测。
一份漂亮答案不能证明结果可靠
一次表现亮眼可能掩盖提示词的不稳定。同一提示词遇到更短输入、歧义、缺失字段、另一种语言或冲突指令时，可能立刻失效。当你不再问“这一份看起来好不好”，而是问“这个工作流多大概率满足要求”，评测才真正开始。
并不是每个小任务都要建立实验室级基准。目标是收集足够证据，在多个提示词版本、模型或工作流改动之间做选择，而不被某个令人印象深刻的案例误导。
建立有代表性的测试集
从真实工作中选择五到二十个输入。应包含正常案例、困难边界、信息缺失、嘈杂素材，以及至少一个正确行为应该是先提问或拒绝编造事实的案例。
- 代表大部分使用情况的典型输入。
- 虽然少见但代价很高的失败。
- 存在歧义和上下文不完整的请求。
- 用户真实使用的语言和格式。
- 用于测试不确定性规则的案例。
准备一份完整产品简报、一份没有证据的简报、一个企业受众、一个消费者受众、一条包含未经支持统计数字的请求，以及一条同时要求两个 CTA 的请求。
为可观察要求评分
有效评分表应直接对应任务。编程任务可以评估正确性、仓库兼容性、测试覆盖和不必要改动；营销文案可以评估事实支持、受众匹配、清晰度、报价准确性和 CTA 纪律。
使用带明确含义的小尺度评分。三档——不满足、部分满足、完全满足——通常比假装能区分 83 分和 84 分更稳定。
- 把关键要求和个人偏好分开。
- 虚构事实或不安全行为应直接判为失败。
- 记录失败原因，而不只是总分。
- 即使使用 AI 评分，也要人工抽查。
追踪失败类别和运营成本
总分告诉你哪个版本胜出；失败类别告诉你该修什么。可以标记上下文缺失、违反约束、虚构事实、格式错误、回答不完整或过度冗长等类别。
最好的提示词不一定输出最长，也不一定调用最贵模型。应衡量延迟、Token、人工修正时间和严重错误成本。带清晰来源边界的短提示词，可能优于复杂但不稳定的长提示词。
只有当新提示词减少关键失败、不降低事实准确性，并且节省的人工修正时间足以覆盖额外延迟或模型成本时，才发布新版本。
把提示词当作有版本的产品资产
把提示词版本、模型与设置、测试输入、输出、评分和评测日期保存在一起。模型或来源文档变化后，应重新运行相同案例，而不是默认工作流仍然可靠。
也不要无限优化。先定义发布门槛，达到后上线；真实用户发现重要失败时，再把它加入回归案例。