当前任务定义
状态说明（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还有 sharedproContext残留，就否定本轮“分析 / 评估 / 对比评估”主结构已经成立 - 这些问题应记录为 后续精度修正项，而不是继续抬升为本轮必须全部做完的 blocker
边界
- 本工作区覆盖分析 / 评估 / 对比评估的语义划分、输入边界、接口设计与分层改造方向。
- 可以给出按层次组织的实施顺序，但不展开到逐文件编码 checklist。
- 重点聚焦当前项目已有的 LLM 主观分析 / 评估体系，不讨论通用 promptfoo / 客观断言路线。
关注点
- 分析与评估的边界到底如何稳定下来
- 单结果评估的最小必需输入是什么
- 多测试对比评估如何摆脱
original/optimized二元语义 - 不同模式下哪些属于设计态输入，哪些属于执行态输入
- 如何在不引入版本绑定复杂度的前提下，让评估结果仍然可用于左侧工作区修改
非目标
- 不建立评估结果到历史版本分支的绑定关系
- 不实现版本回放或历史快照重放系统
- 不提供本次改造的具体实施任务列表
- 不提供 UI 视觉方案
- 不在本轮文档中直接产出代码提交
- 不把
pro模式 per-variant 上下文精度问题与 image 右侧评估链路，一起并入本轮“主语义重构完成度”的判断标准
Source: docs/workspace/compare-evaluation-analysis/history/task_plan.md