当前任务定义

状态说明（2026-03-14）： 本文档仍然作为“目标定义”有效。 当前代码已经完成其中一大部分文本 workspace 重构进度； 最新实现状态与剩余偏差请优先参考 progress.md 与 current-analysis-feature-map.md。

核心任务

1. 明确区分“分析”和“评估”的语义、结构与 UI 文案

• 左侧能力统一定义为“分析”
• 右侧单结果能力统一定义为“评估”
• 右侧多结果能力统一定义为“对比评估”
• 相关按钮文本、面板标题、空态文案、结果文案都应跟着统一

2. 矫正分析功能的输入边界

• 分析默认只允许使用左侧工作区的设计态信息
• 分析不准引用右侧测试文本
• 分析不准默认引用右侧测试变量实例值
• 如果未来确实需要“结合当前变量值排障”，应定义成显式诊断模式，而不是默认分析

3. 重构评估功能，支持多测试的结果导向评估

• 单结果评估应基于一次真实测试快照
• 对比评估应支持多个真实测试快照
• 评估对象应是测试快照，而不是左侧“优化前/优化后”的编辑器语义
• 对比评估应支持多测试输入 + 多测试输出，而不再只限 A/B 二元 compare

一个关键实现原则

• 评估基于测试快照，修改统一面向左侧当前工作区。

这句话展开后，含义是：

• 评估时要知道“这次实际怎么测的、测出了什么”
• 但不建立“这个结果属于 v1 / v2 / 某个版本分支”的强绑定关系
• 所有“应用建议 / 应用 patch”都统一尝试作用到左侧当前工作区
• 如果当前工作区内容已变化、导致无法应用，就直接失败或跳过

当前收口判断

这轮任务不应继续被“实现精度残留”拉成一个无限扩大的重构。

当前更合理的判断是：

• 文本 workspace 的主语义重构是本轮主任务
• pro 两个 workspace 的 per-variant 右侧上下文精度，这轮已经补齐，不再是当前剩余主问题
• image 模式右侧评估链路，是单独的后续扩展问题

也就是说：

• 不能因为 context-user / context-system 还有 shared proContext 残留，就否定本轮“分析 / 评估 / 对比评估”主结构已经成立
• 这些问题应记录为 后续精度修正项，而不是继续抬升为本轮必须全部做完的 blocker

边界

• 本工作区覆盖分析 / 评估 / 对比评估的语义划分、输入边界、接口设计与分层改造方向。
• 可以给出按层次组织的实施顺序，但不展开到逐文件编码 checklist。
• 重点聚焦当前项目已有的 LLM 主观分析 / 评估体系，不讨论通用 promptfoo / 客观断言路线。

关注点

• 分析与评估的边界到底如何稳定下来
• 单结果评估的最小必需输入是什么
• 多测试对比评估如何摆脱 original/optimized 二元语义
• 不同模式下哪些属于设计态输入，哪些属于执行态输入
• 如何在不引入版本绑定复杂度的前提下，让评估结果仍然可用于左侧工作区修改

非目标

• 不建立评估结果到历史版本分支的绑定关系
• 不实现版本回放或历史快照重放系统
• 不提供本次改造的具体实施任务列表
• 不提供 UI 视觉方案
• 不在本轮文档中直接产出代码提交
• 不把 pro 模式 per-variant 上下文精度问题与 image 右侧评估链路，一起并入本轮“主语义重构完成度”的判断标准