任务计划：测试区自动迭代一轮

目标

在当前 basic-system 工作区右侧测试区中，新增一个“自动迭代”入口，让用户只需选择：

• 目标模型
• 参考模型

系统就能自动生成 4 槽位对比预设，并完成一次完整的自动迭代闭环：

1. 用同一组测试输入运行 4 个槽位
2. 分析 目标/workspace 与其他 3 个参考槽位的差异
3. 提取可迁移的目标锚点与改进方向
4. 仅改写当前 workspace 提示词
5. 重新执行 4 槽位测试，展示一轮后的结果

当前阶段

Phase 8（实施拆分与落地顺序设计完成，等待按新方案重新实现）

阶段与状态

Phase 1：需求收口与方案边界（已完成）

• 明确不做独立 SPO 实验页，优先复用现有测试区
• 明确 V1 只做“自动迭代一轮”，不是多轮自动代理
• 明确核心配置仅保留 目标模型 与 参考模型
• 明确自动形成 4 槽位预设，而不是要求用户手工逐列配置

Phase 2：现状调研与能力映射（已完成）

• 确认当前 basic-system 已支持 2/3/4 列测试布局
• 确认当前 session 已持久化 testVariants
• 确认当前对比评估链路已支持多 snapshot 输入
• 确认现有通用 A/B 状态工具不是本次主入口，主入口在 BasicSystemWorkspace

Phase 3：交互与架构设计（已完成）

• 设计测试区顶部的“自动迭代”按钮与配置弹窗
• 设计 4 槽位自动预设规则
• 设计一轮自动迭代的编排流程
• 设计防过拟合与回归保护规则
• 输出相关设计文档

Phase 4：实现准备（已完成）

• 明确 session 中是否持久化自动迭代配置
• 抽离自动迭代编排逻辑，避免继续膨胀 BasicSystemWorkspace.vue
• 定义“本轮总结”数据结构，用于展示本轮学习点、改动点、风险点
• 对接现有迭代/改写链路，确保只写回 workspace

Phase 5：实现与验证（未开始，先前试验实现已回滚）

• 测试区顶部接入自动迭代入口
• 完成 4 槽位预设生成
• 完成首轮执行、对比评估、智能重写、复测闭环
• 补充针对 basic-system 的验证用例
• 浏览器手工验证 2/3/4 列、空历史链、模型缺失、执行失败等场景
• 浏览器手工验证“测试输入变化时不产生样例特化规则”的约束场景

Phase 6：Structured Compare 与通用智能重写（已完成设计）

• 明确 compare evaluation 应拆分为 Generic Compare 与 Structured Compare
• 明确 target / baseline / reference / referenceBaseline / replica / auxiliary 角色模型
• 明确 compare evaluation 只依赖结构化角色语义，不直接依赖 SPO 设置
• 明确“根据整份评估结果自动重写”应作为通用能力，而不是 SPO 私有能力
• 输出工作区设计补充文档
• 输出架构设计补充文档

Phase 7：薄 SPO 的 UI / 停止规则 / 多轮编排（已完成设计）

• 明确 SPO 只负责 preset、loop、stop 和结果展示
• 明确不增加 SPO 专属 judge LLM 调用
• 明确停止条件优先依赖 compare evaluation 的通用 stop signals
• 设计 SPO 按钮、设置弹窗、运行卡、结果卡、详情抽屉
• 设计 最终采用轮次 与 最后执行轮次 的区分规则
• 输出工作区设计补充文档
• 输出架构设计补充文档

Phase 8：实施拆分与落地顺序（已完成设计）

• 明确 compare stop signals 的类型扩展位置
• 明确 structured compare config 与 SPO config 的状态边界
• 明确 session 持久化状态与运行时状态的拆分
• 明确 BasicSystemWorkspace 的最小接入点
• 明确推荐新增的 composable 与 UI 组件列表
• 输出实施拆分文档

当前实现状态补充

• 当前主干代码里还没有按本目录最新设计落地的自动迭代实现。
• 先前试做过一版 V1 demo，但因为：
  • compare intelligence 与 SPO 编排耦合过深
  • “根据评估结果智能重写”没有真正下沉为通用能力
  • 停止条件与 accepted round 依据没有设计完整 所以已回滚，后续会按最新设计重新实现。
• 当前 compare evaluation 的外部返回结构在下一阶段仍建议保持不变：
  • summary
  • improvements
  • patchPlan
  • score
• 下一阶段的重点不是继续堆叠 SPO 专属逻辑，而是把 compare evaluation 的通用增强收口为：
  • Generic Compare / Structured Compare
  • 基于整份评估结果的通用智能重写
  • 面向 SPO 与其他自动化入口通用可消费的 stop signals
  • 一套可按阶段落地的实施拆分
• 已达成的循环抽象是：
  1. 运行测试
  2. 对比评估
  3. 根据评估结果智能改进
  4. 继续执行测试 其中多轮 SPO 的 accept / stop 判定以后续的 compare 通用增强为准。

目标验收标准（待实现）

• 用户可以在测试区内打开自动迭代弹窗，不需要跳转新页面
• 用户只配置 目标模型 和 参考模型，系统自动生成 4 槽位
• 自动迭代明确以 目标模型 / workspace 为优化对象
• 自动迭代只改动工作区草稿，不直接覆盖历史版本
• 一轮结束后，用户能看到新的 workspace 结果与“上一版本”、参考模型的对比
• 本轮结论中必须包含防过拟合说明，不能只以单次测试分数提升作为成功标准
• 本轮结论必须明确说明“改动针对系统提示词结构，而不是针对当前测试输入内容打补丁”

关键决策（摘要）

• 复用现有测试区与多槽位能力，不新增独立实验台。
• 将“目标识别”收敛为“目标槽位 + 提示词内显式约束 + 差异证据”的组合锚点，而不是额外要求用户填写目标说明。
• 历史参考统一称为“上一版本（previous version）”；它在实现上对应当前工作区本轮改写前的最近稳定版本，若不存在则退化为 v0。
• 自动改写只写回 workspace，历史链仍由用户决定是否保存，降低误操作成本。
• 首期聚焦 basic-system，优化对象是系统提示词，而不是测试输入内容。
• compare evaluation 的未来增强方向是 Structured Compare，其角色依赖于结构化 compare 语义，而不是硬绑定 SPO。
• “根据评估结果智能重写”应下沉为所有评估面板共用的基础能力，SPO 只负责调用与编排。