代码智能体的训练和持续评测，不只需要问题描述，还需要可运行的软件状态、开发工具与可靠验证。Change2Task 的思路是从已合并的拉取请求中提取开发证据，再将其转换为能够在同一仓库较新、健康版本上执行的任务，从而持续补充任务数据。
从历史变更重建任务
仓库会持续演进，历史 PR 对应的代码状态未必能直接用于现代环境。Change2Task 会把历史证据与演进后的代码对齐，并通过三种方式重建任务状态：补丁反转、代码映射和智能体重建。材料没有展开三种方法各自的适用条件，但其共同目标，是在维护中的仓库版本上恢复一个待完成状态，同时保留开发者真实变更提供的任务依据。
系统还会验证完整生命周期：先确认基础版本处于健康状态，再进入包含待解决问题的任务状态，最后检查应用解决方案后的恢复状态。这使任务不只是静态补丁或文字说明，而是带有环境和验证流程的可执行样本。多个任务可以复用维护中的环境，以减少重复搭建、存储和任务制作成本。
五类任务与构造结果
论文覆盖五种常见代码智能体任务：缺陷修复、功能增加、测试生成、API 迁移和安全修复。从 1,130 个符合构造条件的源变更出发，Change2Task 的验证任务构造成功率为 79.6%。在匹配的候选集合上，它比基于拉取请求的构造基线多恢复了 29.2% 的验证任务。
在智能体评测中，历史案例与重建案例的匹配结果一致率最高达到 98.0%。这里的“最高”不能视为所有任务族或全部样本都达到同等水平，但至少说明部分重建任务能够较好保留原始案例的评测结果。
我的判断
这项工作的价值，在于把仓库历史转化为可重复利用的任务生产线，而不是再提出一个孤立基准。它尤其适合拥有持续维护、测试与合并记录的项目，可用于训练数据扩充、基准构建和连续评测。
边界也很明确：79.6% 的成功率意味着仍有一部分变更无法完成验证构造；结果依赖仓库健康状态、历史证据质量以及验证流程。摘要也没有给出不同任务族的细分成功率、失败原因和大规模运行成本，因此暂时不宜据此判断它能覆盖所有仓库或显著提升智能体能力。