测试与评估¶

这页只解释一件事：

左侧在改什么，右侧在看什么。

如果把这层关系看清楚，很多按钮就不容易混淆了。

第一次使用，先记住这 4 句话¶

左侧负责改提示词
右侧负责跑真实结果
结果评估看单列输出是否合格
对比评估看多列输出之间谁更好、为什么

先看动作对照表¶

动作	在哪里	主要看什么	会不会改左侧工作区
分析	左侧	提示词本身的表达、结构、约束	会给建议，可应用到工作区
优化 / 迭代	左侧	直接生成或继续改写提示词	会
测试	右侧	真实执行后的输出	不会
结果评估	右侧单列	某一列这次执行是否达到目标	可给建议，应用时作用到工作区
对比评估	右侧多列	多个真实输出之间谁更好、为什么	可给建议，应用时作用到工作区

如果你只想快速分清，先看这 3 句¶

分析：不看右侧测试输入，只看提示词本身
结果评估：看某一次真实执行到底合不合格
对比评估：看多次真实执行之间的差异模式

左侧分析和右侧评估最大的区别¶

左侧分析¶

左侧分析看的是“这条提示词写得怎么样”。

它主要关注：

目标是否清楚
约束是否完整
表达是否容易被模型稳定理解
结构是否适合继续优化

右侧评估¶

右侧评估看的是“这次真实执行结果怎么样”。

它主要关注：

输入和输出是否匹配
输出有没有完成任务
哪些约束被满足或被违反
从结果反推，左侧工作区提示词还缺什么

左侧分析不会读取什么¶

为了避免语义混乱，当前实现里，左侧分析不会把右侧测试输入当成分析证据。

也就是说：

系统提示词工作区：左侧分析不会读取右侧测试文本
变量工作区：左侧分析不会读取右侧变量值
多消息工作区：左侧分析不会把右侧某次测试结果当成前提

如果你想基于真实输出问题来判断提示词是否有效，要去右侧做评估。

不同工作区下，右侧到底在测什么¶

工作区	右侧测试的主要输入	右侧评估时最重要的证据
系统提示词工作区	测试文本	system prompt + 测试文本 + 输出
用户提示词工作区	通常没有额外输入	执行提示词 + 输出
变量工作区	共享变量表单	执行提示词 + 变量值 + 输出
多消息工作区	整段会话 + 共享变量 + 可选工具	完整上下文执行快照 + 输出

结果评估和对比评估怎么选¶

当你想判断某一列输出本身是否合格时，用 结果评估。

适合：

这一列有没有跑偏
为什么它多写了解释
为什么格式没遵守
这一版提示词单看有没有明显问题

当你已经跑出了两列或更多列，想比较差异时，用 对比评估。

适合：

原始 vs 工作区
工作区 vs v2
同一提示词在不同模型下的差异
同一模型下不同版本谁更稳定

对比评估到底在比较什么¶

对比评估比较的是 真实输出证据，不是版本名字本身。

最常见的 3 类场景：

1. 同一模型下，不同提示词版本：重点看提示词改动是否真的带来了结果变化。
2. 同一提示词，不同模型：重点看：
哪个模型理解得更稳定
哪个模型更容易误解你的提示词
是否需要把提示词写得更明确，降低模型差异
3. 工作区临时修改 vs 已保存版本：重点看当前工作区里的编辑稿，是否真的值得保存成下一版。

“工作区”是什么意思¶

右侧版本选择里的 工作区，指的是 左侧当前正在编辑的内容。

它不是简单的“最新已保存版本”。

你可以把它理解成：

原始：最初输入
v1 / v2 / v3：已经保存过的版本
工作区：你当前正在改、但可能还没保存成版本的内容

聚焦说明是干什么的¶

当前评估入口支持填写可选的 聚焦说明。

如果你手动补了关注点，例如：

不要解释
语气太强硬
对比不同模型为什么差这么多
工具调用参数经常漏字段

系统会优先围绕这个问题做评估，而不是只给一份泛泛的总结。

应用评估建议以后会发生什么¶

当前设计里，评估建议不会绑定某个版本分支。

应用时的原则是：

统一尝试作用到 左侧当前工作区
如果当前工作区已经变化太多，旧评估结果会变成过期状态
过期不代表结果消失，而是提醒你“这份结论对应的是旧内容”

第一次使用，推荐按这个流程走¶

先在左侧形成一个可测试的工作区版本
在右侧跑出 2-4 列真实结果
先做结果评估，定位单列明显问题
再做对比评估，总结不同版本或模型的差异
把真正有价值的建议应用回左侧工作区
必要时再保存为新版本继续循环

常见误区¶

误区 1：左侧分析应该参考右侧测试输入¶

不是。左侧分析聚焦的是提示词本身，右侧测试输入属于执行证据。

误区 2：右侧评估一定知道自己对应哪个历史版本分支¶

不是。当前设计的落点是“是否能改进当前左侧工作区”，而不是维护复杂的版本绑定关系。

误区 3：对比评估只是在比较 A/B 标签¶

不是。它比较的是多列真实输出之间的差异模式。