Prompt 改完以后，凭什么说它真的更好了？

把人工试聊拆成可重复运行的销售场景、分组评分和版本比较，再通过 PoC 验证完整链路，交给运营做最终判断。

44局

销售场景评测矩阵

26 局推进 / 18 局识别处置

60%+

打分波动收敛

重复评测结果更稳定

≈5min

一轮完整评测

平均耗时缩短约 83%

01评测策略

把主观试聊，变成 44 局可复现评测

运营修改销售 Agent Prompt 后，很难判断哪里变好、哪里退化。

WHO客户身份

WHAT需求状态

HOW沟通阻力

SCENARIO MATRIX44 局固定产品与 Prompt，改变客户情境

A26 局销售推进推进、探需、红线与适应性

B18 局识别处置分类、退出、转交与特殊场景

约 100 份人工参考评分重复评测打分波动收敛 60%+

我的洞察: 销售推进和识别处置的目标不同：前者要推动有效客户，后者要尽早识别无效或特殊线索，不能只用一个标准评价。
我的设计: 按客户身份、需求状态和沟通阻力建立 44 局矩阵，拆成 26 局销售推进和 18 局识别处置并分别评分；再用约 100 份人工参考评分和约 8—10 个典型正反例校准 Judge。
结果与状态: 通过人工评测集、评分规则和 Few-shot 锚点校准，将重复评测的打分波动收敛 60%+

02PoC 与上线

44 局多轮对话是长任务，容易出现耗时过长、对话不收敛或单局失败。

不收敛 → 自动退出API 失败 → 最多重试 3 次单局失败 → 标记并允许补跑

BEFORE平均 30 min

AFTER约 5 min / −83%

我的洞察: 这是有人审核的内部工具，第一步不是自动发布 Prompt，而是让评测过程能跑完、结果能检查、失败后能继续。
我的设计: 参与用 Dify 和本地 Python 跑通最小 PoC，串联客户模拟、分组 Judge、问题归因、候选 Prompt、同条件复测和人工决策，并补充自动退出、三次重试与失败局补跑。
结果与状态: V1 上线供 4 名运营使用；一轮完整评测由平均 30 分钟缩短至约 5 分钟，缩短约 83%