分析 / 评估 / 对比评估手工验收

这是当前最短手测版。 目标不是记录所有历史现象，而是帮助你快速确认“当前实现是否符合设计”。

1. 本轮范围

只测 4 个文本工作区：

• basic-user
• basic-system
• pro-variable
• pro-multi

本轮不测：

• image 右侧 result / compare

2. 启动方式

pnpm -F @prompt-optimizer/core build
pnpm -F @prompt-optimizer/ui build
pnpm -F @prompt-optimizer/web dev --port 18181

打开：

http://localhost:18181

建议：

• 用无痕窗口或新 profile
• 打开 DevTools，看网络请求里的 messages

3. 这次到底要验证什么

只验证 4 条：

1. 左侧“分析”只看左侧工作区，不引用右侧测试内容。
2. 右侧单结果“评估”只看当前列的执行快照。
3. 右侧顶部“对比评估”看的是多个执行快照，不再是旧 A/B 语义。
4. 请求体尽量最小化，不再重复塞工作区全文、重复渲染输入、resolvedPrompt 等旧冗余字段。

再补 2 条这轮新增回归检查：

5. 右侧 result / compare 只认当前工作区，不允许回退到左侧原始提示词。
6. 当已有评估结果但当前输入条件已失效时，评估入口应保留可查看，但禁止重跑。

4. 抓包时只看这些点

优先看模型请求里的 messages[0].content 和 messages[1].content。

左侧分析应满足

• 只有当前工作区目标
• 必要时带最小设计态上下文
• 不应出现右侧测试文本
• 不应出现右侧测试输出
• pro-variable 不应出现变量值

右侧单结果评估应满足

• 有且只有一次公共测试输入
• 有当前列的 执行提示词
• 有当前列的 输出
• 不应再额外出现 ## 当前工作区提示词
• 不应混入别的列输出

右侧对比评估应满足

• 公共测试输入只出现一次
• 至少两个快照
• 每个快照只带自己的：
  • 执行提示词
  • 输出
  • 推理（如果有）
  • 模型 / 版本信息
• 不应退回旧 original / optimized
• 不应再默认出现：
  • ## 当前工作区提示词
  • 每个 variant 一整段重复输入快照
  • resolvedPrompt

5. 路由

6. 最小测试步骤

6.1 basic-user

A. 左侧分析

1. 输入一段用户提示词。
2. 不填写右侧测试区。
3. 点击左侧 分析。

通过标准：

• 可以返回分析结果。
• 请求里只出现当前工作区用户提示词。
• 不出现右侧测试文本、输出。

B. 右侧单结果评估

1. 先完成一次优化或测试，让右侧至少有一列结果。
2. 在某个结果卡片点击 评估。

通过标准：

• 请求里有当前列 执行提示词 和 输出。
• 没有别的列输出。
• 没有额外的 ## 当前工作区用户提示词。

C. 右侧对比评估

1. 让至少两列有结果。
2. 点击顶部 对比评估。

通过标准：

• 请求里出现多个快照。
• 不是旧 A/B 固定语义。
• summary 和建议应围绕快照差异，而不是空泛地说“都可以继续优化”。

D. 工作区为空时不应回退到原始提示词

1. 先完成一次优化和一次测试，确认右侧已经有结果。
2. 手动清空下方工作区内容。
3. 尝试点击某列 评估 或顶部 对比评估。

通过标准：

• 不应继续发起新的评估请求。
• 应提示当前没有可评估的工作区内容。
• 旧分数徽章如果之前已存在，可以继续查看，但不能偷偷拿左侧原始提示词继续评估。

6.2 basic-system

A. 左侧分析

1. 左侧输入 system prompt。
2. 右侧故意填一段明显可识别的测试文本。
3. 不跑测试，直接点左侧 分析。

通过标准：

• 分析请求不应带右侧测试文本。

B. 右侧单结果评估

1. 跑出至少一列结果。
2. 点击该列 评估。

通过标准：

• 请求里有：
  • 公共测试文本
  • 当前列执行提示词
  • 当前列输出
• 没有别的列输出。

C. 右侧对比评估

1. 跑出两列结果。
2. 点击顶部 对比评估。

通过标准：

• 请求里有公共测试文本一次。
• 每个快照只保留自己的执行提示词和输出。
• 不再默认注入当前工作区全文。

D. 清空测试文本后的旧评估处理

1. 先跑出两列结果，并完成一次单结果评估或对比评估。
2. 保留右侧已有输出不动。
3. 清空右侧测试文本。
4. 再观察已有评估徽章，并尝试从徽章或详情面板里重跑评估。

通过标准：

• 已有评估结果仍可查看。
• 徽章应保留，不应直接消失。
• 重新评估入口应被禁用，不能再继续发请求。
• 不应出现“按钮点了没反应”或直接报 core 校验错误。

6.3 pro-variable

建议提示词：

请根据{{任务描述}}，为{{目标用户}}编写一份{{文档类型}}，要求{{质量要求}}

A. 左侧分析

1. 填好 prompt。
2. 把变量值也填好。
3. 不跑右侧测试，直接点左侧 分析。

通过标准：

• 请求里可以看到变量结构。
• 不应看到变量具体值。
• 不应出现执行态渲染后的额外 prompt。

B. 分析后继续优化

1. 分析完成后关闭面板。
2. 点击 继续优化。
3. 输入一个简单优化方向并确认。

通过标准：

• 能正常进入下一版工作区。
• 不应出现 RecordNotFoundError。

C. 右侧单结果评估

1. 跑出至少一列结果。
2. 点击该列 评估。

通过标准：

• 请求里有一次性的变量值输入。
• 有当前列 执行提示词。
• 有当前列 输出。
• 不应再额外出现 resolvedPrompt。

D. 右侧对比评估

1. 跑出两列结果。
2. 点击顶部 对比评估。

通过标准：

• 公共变量输入只出现一次。
• 每个快照只保留自己的执行提示词和输出。
• 不应再出现每个 variant 都重复一整段渲染后输入。

6.4 pro-multi

建议最简单示例：

• system: 你是一个诗人
• user: 请你写一首关于{{主题}}的诗。

A. 左侧分析

1. 选中一条消息作为优化目标。
2. 让左侧工作区出现内容。
3. 点击左侧 分析。

通过标准：

• 请求里有最小会话位置上下文。
• 能看到 【当前工作区要优化的提示词】 之类的位置标记。
• 不应出现右侧测试输出。
• 不应出现完整 transcript JSON。

B. 右侧单结果评估

1. 跑出至少一列结果。
2. 点击该列 评估。

通过标准：

• 公共输入区只带一次会话快照。
• 当前列只带自己的执行提示词和输出。
• 不应再出现旧的 targetMessage + conversationMessages 原始 JSON。

C. 右侧对比评估

1. 跑出两列结果。
2. 点击顶部 对比评估。

通过标准：

• 共享会话输入只出现一次。
• 每个快照只保留自己的执行提示词和输出。
• 不应为每个快照重复整段会话输入。

7. 最终通过标准

如果下面 6 条都成立，就可以认为文本主线验收通过：

1. 左侧分析不吃右侧测试输入。
2. pro-variable 左侧分析不吃变量值。
3. 单结果评估只看当前列。
4. 对比评估按多个快照工作，而不是旧 A/B 语义。
5. 请求体已经瘦身，不再重复注入工作区全文或重复输入快照。
6. 分析 -> 继续优化 这条真实路径没有历史记录错误。

建议再补看 2 条：

7. 工作区为空时，右侧评估不会回退到原始提示词。
8. basic-system 在清空测试文本后，旧评估可看但不可重跑。

8. 如果发现偏差，优先怎么记

建议只记录这 3 类信息：

1. 哪个工作区
2. 哪个能力
   • prompt-only
   • prompt-iterate
   • result
   • compare
3. 实际多带了什么，或少带了什么

例如：

pro-variable / result
问题：请求里仍带了 resolvedPrompt
预期：只保留公共变量输入一次 + 当前列执行提示词 + 当前列输出

Source: docs/workspace/compare-evaluation-analysis/manual-acceptance.md