从评测结果到产品迭代

V1 面向本人日常科研绘图，把数据处理和绘图流程提前固定，模型只负责把自然语言转换为受限参数。

使用真实科研数据反复完成导入、绘图、修改和导出，并把任务范围从本人固定需求扩展到实验室中的其他绘图需求。

固定需求中的提效已经成立，但每增加一种数据整理方式或图类都需要重新编写流程，产品难以扩展。输出以 Python 图为主，也降低了 Origin 用户继续尝试和编辑的意愿。

V2 不再只优化一条固定流程，而是把目标改为扩充覆盖面：增加自动化数据处理，并探索通过参考图自主创建绘图模板。

这一阶段的证据来自本人和实验室场景，能够说明固定流程的适用范围，不能代表更大规模用户的需求。

为了扩充覆盖面，V2 尝试让程序根据不同任务进入预设的数据处理流程，再把整理结果交给绘图模块。

使用开发时未见过的冻结数据，检查真实模型能否识别多级表头、多区域表格、多工作表和语义歧义，并在全部任务完成后才读取评分答案。

首轮 11 个案例只通过 8 个，版式留出集只通过 2 / 4。真实数据的结构和语义变化无法穷举；继续增加预设流程，只会让产品覆盖面和维护成本一起增长。

自动化数据处理被保留，但从预设流程改为让模型观察数据、调用受控工具并在歧义时追问。修复后的另一组 11 个冻结案例全部通过，证明这项能力可以继续进入 V3。

不同案例的模型调用次数为 1 至 12 次，单个案例最长 193.1 秒。评测证明了正确性，没有证明所有数据都能以稳定成本完成。

V2 希望用户提供参考图后，系统能够理解图形结构、创建新模板、安装并复用于同类数据，以此覆盖预设图类之外的长尾需求。

先用 14 个 Origin 参考图检查结构识别，再把参考图理解、数据准备、模板创建、双后端出图、复用和自然语言修改放进端到端任务；最后加入开发时未见过的留出案例。

参考图首轮只通过 5 / 14，端到端任务首轮完成 9 / 12，新图类留出集完成 3 / 5。开发样例最终可以达到 12 / 12，但需要大量模型调用和复杂的多阶段状态。该路线能够演示，却不足以成为稳定、成本可控的用户功能。

V3 取消自主模板创建，改为覆盖常见 Origin 模板，用较低实现成本扩大可用范围。模型编排也从多条固定流程和多模型角色收敛为 Pi Agent Runtime（单一模型工具循环运行时：代表一次可以连续调用受控工具的模型任务；承载当前上下文、工具清单、预算和每步结果；在流程中根据程序反馈继续选择下一项动作）。

这些通过率来自不同批次，不能合并成一个准确率。它们用于比较产品路线是否适合继续投入，不代表参考图生成在所有场景中不可行。

V3 已经收缩到常见 Origin 模板和单一模型运行时，接下来的判断是核心绘图任务通过后能否生成 Windows 公开测试版本。

分别执行确定性状态测试、正式 Windows 黑盒、真实模型长任务、Origin 新会话读回和公共编辑检查。代码修改后不继承旧结论，而是冻结新的发布候选重新评测。

固定范围的真实模型任务曾经全部通过，但更长任务仍暴露图类冲突、部分成功收口、修订确认和取消恢复问题。确定性黑盒达到 52 / 52 后，真实模型又在用户没有指定图类时直接猜图。用户需要的不只是成功出图，还包括任务可以确认、恢复、纠错和安全结束。

任务状态和确认结果改为由 Core（确定性任务内核：代表项目的权威执行层；承载对象身份、数据版本、权限和任务状态；在流程中校验模型计划、执行动作并记录结果）统一管理。图类来源成为每个创建任务必须提交的信息，只有真实歧义才向用户追问。

新冻结候选最终通过真实模型与运行时、Origin 原生对象和公共编辑三组发布门槛，并生成 Windows 公开测试安装包。发布结论只适用于该候选和既定功能范围。