docs/workspace/compare-evaluation-analysis/history/overall-reframing.md
这份文档不是在补充某个局部细节，而是把这次讨论整体收成一个新框架。 核心目的只有一个：以后不要再把左侧“分析”和右侧“评估”当成同一种结构的不同变体。
状态说明（2026-03-14）： 这份文档的核心边界定义仍然有效，但其中部分“接下来要做”的内容，当前代码已经落地了一部分。 最新实现状态请优先参考：
current-analysis-feature-map.mdprogress.md进一步说明：
- 文本 workspace 的
result / compare / prompt-*主语义已经基本落地。- 文中凡是把“当前实现”写成 A/B only、
original / optimized、或“单结果评估只覆盖 A/B”的段落，应理解为前期问题背景，而不是当前代码事实。- 当前真正还没完全收口的，主要是 compare 结构还没有继续演进到
inputs[] + variants[]，以及 image 模式右侧评估链路。
当前功能在产品表面上都叫“分析 / 评估”，但从结构上看，后续应该明确拆成 3 类并列能力：
它们不是一个大接口的 3 个小分支，而是：
这点在“评估要升级成支持多个测试变体”之后会更加明显。
基于最新讨论，这轮主任务可以收成下面 3 条：
再补一个实现原则：
在旧模型里，大家容易把它们混在一起，是因为：
EvaluationType 话语体系但如果评估真的要支持：
那右侧评估天然就会长成“测试变体集合”的结构。
而左侧分析不会。
左侧分析更像：
右侧评估更像：
右侧对比评估更像：
所以从这一步开始，再把“分析”和“评估”强行塞回同一请求结构里，成本会越来越高。
后续建议用下面这套边界统一全局。
分析回答的是：
分析默认应具有这些特点：
分析应该主要消费：
单结果评估回答的是：
单结果评估默认应具有这些特点：
单结果评估应该主要消费：
对比评估回答的是：
对比评估默认应具有这些特点：
对比评估应该主要消费：
为了避免后面再把“测试文本”“变量值”“prompt 结构”“输出结果”混在一起，建议先把输入分成 3 层。
这层输入是给分析用的，典型包括：
它回答的是：
这层输入是给评估用的，典型包括：
它回答的是：
这层输入是评估和对比评估都要看的，典型包括：
它回答的是：
映射起来就是：
这是这次梳理里一个很重要的新结论。
当前 context-user 左侧分析会带：
variablesrawPromptresolvedPrompt这说明当前实现确实会把变量实例值喂给左侧分析。
但这更像历史实现结果，不适合直接固化成目标设计。
原因是：
更合理的边界是：
也就是说：
从接口角度，建议后续至少拆成 3 类请求。
它代表左侧分析。
export interface PromptAnalysisRequest {
type: 'prompt-only' | 'prompt-iterate'
target: {
mode: 'basic-user' | 'basic-system' | 'context-user' | 'context-system' | 'image'
original?: string
current: string
}
context?: {
conversation?: unknown
variableSchema?: Array<{
name: string
source: 'predefined' | 'global' | 'temporary'
required?: boolean
}>
}
iterateRequirement?: string
}
关键点：
它代表右侧单列评估。
export interface SingleTestEvaluationRequest {
type: 'single'
snapshot: {
id: 'a' | 'b' | 'c' | 'd'
label: string
model: {
key: string
providerId?: string
modelId?: string
}
prompt: {
mode: string
content: string
}
executionInput: {
mode: string
summary: string
body: string
}
output: {
kind: 'text' | 'image'
content: string
reasoning?: string
}
}
}
关键点：
snapshot它代表右侧多测试对比评估。
export interface MultiVariantCompareEvaluationRequest {
type: 'compare'
inputs: Array<{
id: string
fingerprint: string
mode: string
title: string
summary: string
body: string
}>
variants: Array<{
id: 'a' | 'b' | 'c' | 'd'
label: string
model: {
key: string
providerId?: string
modelId?: string
}
inputId: string
output: {
kind: 'text' | 'image'
content: string
reasoning?: string
}
}>
}
关键点：
original/optimizedinputs[] + variants[]可以共用一些底层能力，但不应共用同一层业务 builder。
原因是：
所以更合理的方向是：
analysis/*evaluation/*compare/*而不是继续把三者都塞进一个“泛 evaluation builder”。
这套新框架落到当前项目，意味着几件事。
prompt-only / prompt-iterate这个小节描述的是重构前的问题背景：当时 original / optimized 只挂在 A/B 上。
后续如果真的支持多测试，应该理解成：
也就是说，今天的：
originaloptimized更像是“历史 UI 触发语义”，不是未来最稳定的领域模型。
这是这次改造最核心的一块：
original/optimizedvariants + deduped inputsuseEvaluationHandler 后续更像协调层，不应继续承担全部抽象后面它更适合做：
而不是自己既处理分析、又处理单结果评估、又处理多结果对比评估的全部输入建模。
这里建议刻意保持简单：
这样做的目的是：
如果按“风险最小”的方式推进，建议顺序是：
这个顺序的好处是：
如果要把这次整体梳理收成一句话，可以直接用这句：
再补一句更具体的：
这就是为什么后续这两者应该越拆越清楚，而不是继续揉在一起。