docs/workspace/compare-evaluation-analysis/history/findings.md
本文档已经按 2026-03-14 当前代码重写。 2026-03-16 补充：测试区版本来源已统一为
workspace / v0 / vN，latest仅保留为旧 session 迁移输入。 它不再把“旧实现问题”和“未来方案”混在一起，而是拆成：
- 当前已经落地的结构
- 仍然存在的真实偏差
- 后续如果继续推进，最值得做的下一层改造
这轮重构的大方向已经基本成立：
对应到代码层面：
EvaluationType 已经收成 result / compare / prompt-only / prompt-iteratevariantId 工作workspacePrompt? + variants[]所以，最核心的语义纠偏已经完成了。
这里需要刻意做一个收口判断：
当前代码状态更适合这样理解：
result / compare / prompt-* 跑起来inputs[] + variants[] 去重模型所以现在不应该把问题表述成：
而应表述成：
这条判断很重要，因为它直接决定后面的工作策略：
当前 core 里的核心请求结构已经是：
export type EvaluationType =
| 'result'
| 'compare'
| 'prompt-only'
| 'prompt-iterate'
export interface ResultEvaluationRequest extends EvaluationRequestBase {
type: 'result'
prompt: string
testResult: string
testContent?: string
resultLabel?: string
}
export interface CompareEvaluationRequest extends EvaluationRequestBase {
type: 'compare'
workspacePrompt?: string
variants: CompareEvaluationVariant[]
}
export interface CompareEvaluationVariant {
id: string
label: string
prompt: string
output: string
reasoning?: string
modelKey?: string
versionLabel?: string
input?: {
label: string
content: string
summary?: string
}
}
这说明：
inputs[] + variants[] 去重模型，已不再视为当前 blocker。当前 useEvaluationHandler 已经把三类输入拆开了：
interface UseEvaluationHandlerOptions {
analysisOriginalPrompt?: Ref<string> | ComputedRef<string>
analysisOptimizedPrompt: Ref<string> | ComputedRef<string>
analysisContext?: Ref<ProEvaluationContext | undefined> | ComputedRef<...>
resultTargets?: Ref<Record<string, ResultEvaluationTarget>> | ComputedRef<...>
comparePayload?: Ref<CompareEvaluationPayload | null> | ComputedRef<...>
proContext?: Ref<ProEvaluationContext | undefined> | ComputedRef<...>
}
这层拆分的意义是：
variantId 获取目标comparePayload当前 4 个文本 workspace 的主链路都已经切到了新语义：
basic-userbasic-systemcontext-usercontext-system共同点：
>= 2 个 ready variantsoriginal / optimized 评估语义已经被拿掉这件事不是文案层面的改名，而是实际接线已经改了：
尤其是 context-user：
analysisContext这是本轮最重要的输入边界修正之一。
当前 compare payload 里，每个 variant 已经会带：
idlabelpromptoutputreasoning?modelKey?versionLabel?input?这已经足够让 compare 模板不再把问题理解成“优化前后对比”。
这部分是目前最值得在文档里明确写出来的，不然很容易误以为这轮已经完全收口。
context-user 的 compare 已补上 per-variant input snapshot当前 ContextUserWorkspace.vue 中：
analysisProContext右侧单结果评估现在已经会按当前列构造 proContext：
{
rawPrompt,
resolvedPrompt,
variables: buildUsedVariables(..., {
includeValues: true,
predefinedOverrides: { currentPrompt: rawPrompt, userQuestion: rawPrompt }
})
}
右侧 compare 现在也会给每个 variant 明确带：
当前 context-user compare payload 会带：
label = Rendered Contentcontent = 当前列渲染后输入summary = 当前列变量值摘要这说明当前 context-user compare 的真实状态已经变成：
basic-* / context-system 那样，把执行态输入快照明确表达出来inputs[] + variants[]context-system 的单结果评估上下文已经补齐，compare 相对更完整context-system 现在的状态更接近目标结构：
targetMessageconversationMessagesConversation Snapshot所以它当前更像是：
当前 image 模式：
useEvaluationHandler 只被用来处理 prompt-onlyevaluation-prompt-only所以现在不应该把 image 写成“只是还差一点 compare”。
更准确的说法是：
例如：
ConversationTestPanel.vueContextUserTestPanel.vueTestAreaPanel.vue内部 tool-call 分桶仍在使用：
COMPARE_BASELINE_VARIANT_IDCOMPARE_CANDIDATE_VARIANT_ID这不影响当前主语义，但说明“内部彻底去旧 compare 化”还没完全做完。
另外：
usePromptTester.tsuseConversationTester.tsuseContextUserTester.ts这些旧测试 helper 仍然在仓库里，虽然当前文本 workspace 主链路已经不再依赖它们。
如果后续模型或开发者要快速判断“现在代码到了哪一步”，建议按下面这套口径理解：
inputs[] + variants[] 去重模型这里不再写大而全的终局方案，而只写当前代码基础上最自然的下一步。
在进入这些下一步之前，建议先明确一个判断标准：
目标：
后续最好二选一：
result / compare 模板和接线这包括：
这一步不是当前功能正确性的 blocker，但能减少后续维护成本。
如果按“不继续复杂化当前任务”的原则，下一步工作建议按下面顺序推进：
目标：
pro 精度问题与 image 扩展不是这轮 blocker这是为了避免后续工作继续失焦。
原因：
建议拆成两个小步：
inputs[] + variants[]原因：
像这些内容：
COMPARE_BASELINE_VARIANT_IDCOMPARE_CANDIDATE_VARIANT_ID更适合作为“收尾清理”，而不是下一步第一优先级。
目标：
但当前这一步已经明确不是主线 blocker，更适合作为后续精修项。
如果要把现在的状态收成一句话，可以直接写：
workspace / v0 / vN；当前主线剩余问题主要是 image 模式右侧评估链路缺失，compare 去重建模属于可选后续优化。