Files
prompt-optimizer/mkdocs/docs/zh/user/testing-evaluation.md
linshen debb11fd31 docs(mkdocs): add v2.10.0 feature documentation
Add documentation for new v2.10.0 features in both English and Chinese:

- Favorites: example application to workspaces

- Models: provider-specific request details and capability tags

- Prompt Garden: direct use vs favorite saving guide

- Testing: Run All parallel execution说明

- Desktop: localhost/private network direct routing
2026-05-04 21:22:36 +08:00

191 lines
6.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 测试与评估
这页只解释一件事:
**左侧在改什么,右侧在看什么。**
如果把这层关系看清楚,很多按钮就不容易混淆了。
## 第一次使用,先记住这 4 句话
- **左侧**负责改提示词
- **右侧**负责跑真实结果
- **结果评估**看单列输出是否合格
- **对比评估**看多列输出之间谁更好、为什么
## 先看动作对照表
| 动作 | 在哪里 | 主要看什么 | 会不会改左侧工作区 |
| --- | --- | --- | --- |
| 分析 | 左侧 | 提示词本身的表达、结构、约束 | 会给建议,可应用到工作区 |
| 优化 / 迭代 | 左侧 | 直接生成或继续改写提示词 | 会 |
| 测试 | 右侧 | 真实执行后的输出 | 不会 |
| 结果评估 | 右侧单列 | 某一列这次执行是否达到目标 | 可给建议,应用时作用到工作区 |
| 对比评估 | 右侧多列 | 多个真实输出之间谁更好、为什么 | 可给建议,应用时作用到工作区 |
## 如果你只想快速分清,先看这 3 句
1. **分析**:不看右侧测试输入,只看提示词本身
2. **结果评估**:看某一次真实执行到底合不合格
3. **对比评估**:看多次真实执行之间的差异模式
## 左侧分析和右侧评估最大的区别
### 左侧分析
左侧分析看的是“这条提示词写得怎么样”。
它主要关注:
- 目标是否清楚
- 约束是否完整
- 表达是否容易被模型稳定理解
- 结构是否适合继续优化
### 右侧评估
右侧评估看的是“这次真实执行结果怎么样”。
它主要关注:
- 输入和输出是否匹配
- 输出有没有完成任务
- 哪些约束被满足或被违反
- 从结果反推,左侧工作区提示词还缺什么
## 左侧分析不会读取什么
为了避免语义混乱,当前实现里,左侧分析不会把右侧测试输入当成分析证据。
也就是说:
- 系统提示词工作区:左侧分析不会读取右侧测试文本
- 变量工作区:左侧分析不会读取右侧变量值
- 多消息工作区:左侧分析不会把右侧某次测试结果当成前提
如果你想基于真实输出问题来判断提示词是否有效,要去右侧做评估。
## 不同工作区下,右侧到底在测什么
| 工作区 | 右侧测试的主要输入 | 右侧评估时最重要的证据 |
| --- | --- | --- |
| 系统提示词工作区 | 测试文本 | system prompt + 测试文本 + 输出 |
| 用户提示词工作区 | 通常没有额外输入 | 执行提示词 + 输出 |
| 变量工作区 | 共享变量表单 | 执行提示词 + 变量值 + 输出 |
| 多消息工作区 | 整段会话 + 共享变量 + 可选工具 | 完整上下文执行快照 + 输出 |
| 文生图工作区 | 图像模型 | 提示词版本 + 图像模型 + 真实出图 |
| 图生图工作区 | 输入图 + 图像模型 | 输入图 + 提示词版本 + 真实出图 |
| 多图生图工作区 | 有顺序的输入图 + 图像模型 | 输入图集合 / 顺序 + 提示词版本 + 真实出图 |
## 结果评估和对比评估怎么选
当你想判断某一列输出本身是否合格时,用 **结果评估**
适合:
- 这一列有没有跑偏
- 为什么它多写了解释
- 为什么格式没遵守
- 这一版提示词单看有没有明显问题
当你已经跑出了两列或更多列,想比较差异时,用 **对比评估**
适合:
- 原始 vs 工作区
- 工作区 vs `v2`
- 同一提示词在不同模型下的差异
- 同一模型下不同版本谁更稳定
- 同一组图片输入下,不同图像提示词版本谁更稳定
- 同一版图像提示词下,不同图像模型谁更贴近目标
## 对比评估到底在比较什么
对比评估比较的是 **真实输出证据**,不是版本名字本身。
最常见的 3 类场景:
- **1. 同一模型下,不同提示词版本**:重点看提示词改动是否真的带来了结果变化。
- **2. 同一提示词,不同模型**:重点看:
- 哪个模型理解得更稳定
- 哪个模型更容易误解你的提示词
- 是否需要把提示词写得更明确,降低模型差异
- **3. 工作区临时修改 vs 已保存版本**:重点看当前工作区里的编辑稿,是否真的值得保存成下一版。
在图像工作区里,还要额外记住一句:
- **图像对比评估比较的是实际生成结果,不是提示词自我描述。**
所以如果你在图生图或多图生图里改了输入图,或者改了图片顺序,再去做对比评估,结论会很容易失真。
## “工作区”是什么意思
右侧版本选择里的 `工作区`,指的是 **左侧当前正在编辑的内容**
它不是简单的“最新已保存版本”。
你可以把它理解成:
- 原始:最初输入
- `v1 / v2 / v3`:已经保存过的版本
- 工作区:你当前正在改、但可能还没保存成版本的内容
## 聚焦说明是干什么的
当前评估入口支持填写可选的 **聚焦说明**
如果你手动补了关注点,例如:
- 不要解释
- 语气太强硬
- 对比不同模型为什么差这么多
- 工具调用参数经常漏字段
系统会优先围绕这个问题做评估,而不是只给一份泛泛的总结。
## 应用评估建议以后会发生什么
当前设计里,评估建议不会绑定某个版本分支。
应用时的原则是:
- 统一尝试作用到 **左侧当前工作区**
- 如果当前工作区已经变化太多,旧评估结果会变成过期状态
- 过期不代表结果消失,而是提醒你“这份结论对应的是旧内容”
## 第一次使用,推荐按这个流程走
1. 先在左侧形成一个可测试的工作区版本
2. 在右侧跑出 `2-4` 列真实结果
3. 先做结果评估,定位单列明显问题
4. 再做对比评估,总结不同版本或模型的差异
5. 把真正有价值的建议应用回左侧工作区
6. 必要时再保存为新版本继续循环
使用 `全部运行` 时,系统会尽量并行启动可运行的结果列,让对比准备更快。但评估原则不变:除非你就是要测试某个变量,否则尽量比较同一提示词 / 模型基线下的输出。
## 常见误区
### 误区 1左侧分析应该参考右侧测试输入
不是。左侧分析聚焦的是提示词本身,右侧测试输入属于执行证据。
### 误区 2右侧评估一定知道自己对应哪个历史版本分支
不是。当前设计的落点是“是否能改进当前左侧工作区”,而不是维护复杂的版本绑定关系。
### 误区 3对比评估只是在比较 A/B 标签
不是。它比较的是多列真实输出之间的差异模式。
## 相关页面
- [快速开始](quick-start.md)
- [选择工作区](choose-workspace.md)
- [系统提示词工作区](../basic/system-optimization.md)
- [用户提示词工作区](../basic/user-optimization.md)
- [变量工作区](../advanced/variables.md)
- [多消息工作区](../advanced/context.md)