简体
经过修整的 REODE 原有角色：戴藏青色耳机和青色镜片、面带微笑的奶油色与粉色美西螈脸
返回展厅

REODE

Code migration

修复之前，先找共同原因。

一个 Java/Spring 代码迁移智能体。

2026.03 — 2026.04

工作项目 · 迁移与验证体系

  • CLI已实现 · 工作项目

把修复依据与验收分开的迁移循环。

先记录原始构建状态并应用基于规则的转换，再在修复前收集源码与 POM 证据。模型修改后，再次检查 build、test 与测试完整性；因达到上限或停滞而结束的运行与成功分开报告。

它将基于规则的转换与模型辅助修复结合起来，并用 build 和 test 检查改动后的代码。工作项目。

仓库中的 REODE 工作；pinxlab 合作期 March 16, 2026 to May 26, 2026

在工作中使用的 CLI 工具。

修复循环结构图 · 依据非公开实现记录
REODE 迁移修复循环原始构建状态作为基线保留，应用基于规则的转换后，由 build 和 test 验证结果。失败时，先收集源码、注解与 POM 证据再修复，已知模式以确定性方式修复并重新构建。若重新构建通过，不调用模型；若失败，由模型依据收集到的证据和修复指引修复，并再次验证结果。因达到迭代上限或停滞而结束的运行进入测量，但不计为成功；评分卡只有在五项验收条件全部通过时才评定等级。源码 · POM非公开迁移输入评分卡 · 等级不是部署失败 · 停滞报告不计为成功原始检查原始状态 · 编译运行状态基线 · 未知值不测量恢复记录修复前检查点同一错误的先前修复转换计划 → 基于规则的转换修复前探索原因证据 · 3 个源文件 · POM确定性修复修复已知模式重新构建检查模型修复依据证据 · 指引修复验证build · test · 迭代 +1下一步继续 · 测量 · 最多 3 次测量规则占比 · 测试 · 覆盖率5 项验收条件输入 · 基线恢复记录转换 · 修复验证 · 退出1源码 · POM2原始编译3规则转换4build · test5结果 · 迭代次数6通过 · 上限 · 停滞7基线比较8评定等级1结果 · 迭代次数2失败 · 重试3修复前保存4证据 · 错误分组5通过 · 跳过 LLM6重新构建失败7先前的修复8再次验证1通过 · 上限 · 停滞2基线比较3评定等级4删除 · 排除 · 失败5上限 · 停滞退出

规则转换

原始状态作为基线保留；规则转换后由 build 和 test 验证，运行继续进入测量。

  1. 源码 · POM源码 · POM原始状态 · 编译原始检查

    接收待迁移的 Java/Spring 源码和 POM。不展示客户代码和界面。

  2. 原始状态 · 编译原始检查原始编译基线 · 未知值不测量运行状态

    转换前先选定运行时并编译原始代码，因此原本就已损坏的构建会保留在基线中。基线中 test 与覆盖率的默认值并非测量值。

  3. 原始状态 · 编译原始检查规则转换计划 → 基于规则的转换转换

    运行图依次为：原始检查 → 转换计划 → 基于规则的转换 → 验证。能由规则完成的转换先行应用。

  4. 计划 → 基于规则的转换转换build · testbuild · test · 迭代 +1验证

    build 和 test 验证转换后的代码，迭代次数加一。结果返回运行状态。

  5. build · test · 迭代 +1验证结果 · 迭代次数继续 · 测量 · 最多 3 次下一步

    build 是否成功、test 通过率和迭代次数决定下一步。

  6. 继续 · 测量 · 最多 3 次下一步通过 · 上限 · 停滞规则占比 · 测试 · 覆盖率测量

    当 build 和 test 均通过、达到迭代上限，或检测到停滞（若尚未尝试，则先再尝试一次恢复）时，运行进入测量。进入测量并不意味着成功。

  7. 基线 · 未知值不测量运行状态基线比较规则占比 · 测试 · 覆盖率测量

    测量读取运行状态中保存的基线，不是新的基线运行。

  8. 5 项验收条件测量评定等级评分卡 · 等级

    build 成功、test 通过率 100%、覆盖率变化不低于 −5（仅在基线已知时）、删除的测试为 0、surefire 排除为 0。只有五项全部通过才评定等级。

基于原因的修复

修复前先收集证据，确定性修复优先。重新构建通过则跳过模型；否则由模型依据证据和指引修复，并再次验证结果。

  1. build · test · 迭代 +1验证结果 · 迭代次数继续 · 测量 · 最多 3 次下一步

    build 是否成功、test 通过率和迭代次数决定下一步。

  2. 继续 · 测量 · 最多 3 次下一步失败 · 重试原因证据 · 3 个源文件 · POM修复前探索

    若 build 失败或 test 通过率低于 100%，且未达到迭代上限（默认 3 次），运行进入修复。

  3. 原因证据 · 3 个源文件 · POM修复前探索修复前保存修复前检查点恢复记录

    修复前保存检查点。这是尽力而为：保存失败不会中止修复，保存也不能作为成功的依据。

  4. 原因证据 · 3 个源文件 · POM修复前探索证据 · 错误分组修复已知模式确定性修复

    收集出错的 Java 文件、最多三个源文件的开头部分、注解、POM 与注解处理器设置，以及深度为 2 的 import。这是有界的样本，不等于理解整个代码库。

  5. 重新构建检查确定性修复通过 · 跳过 LLMbuild · test · 迭代 +1验证

    若确定性地修复某个已知模式（例如 Lombok 配置）后重新构建通过，就不调用模型。运行仍会回到验证，因此这并非最终验收。

  6. 重新构建检查确定性修复重新构建失败依据证据 · 指引修复模型修复

    若重新构建失败，收集到的证据和修复指引会交给模型修复。读代码可见，一并传递的错误文本是最初的 build 错误，而不是重新构建产生的新错误，因此不应理解为“只传递剩余错误”。这不是在运行中复现的缺陷。

  7. 同一错误的先前修复恢复记录先前的修复依据证据 · 指引修复模型修复

    查找并附上以同一错误签名记录的先前修复。这是附加到输入中的记录，而非模型训练。

  8. 依据证据 · 指引修复模型修复再次验证build · test · 迭代 +1验证

    模型通过结构化的 architect/editor 路径修复；该路径不可用或处于恢复中时，改用工具使用提示词修复，随后 build 和 test 再次验证。模型的修改本身并不等于 build 通过。

通过与停滞的区分

评定等级需要全部五项条件；删除或排除测试，以及因上限或停滞退出，都不计为成功。

  1. 继续 · 测量 · 最多 3 次下一步通过 · 上限 · 停滞规则占比 · 测试 · 覆盖率测量

    当 build 和 test 均通过、达到迭代上限，或检测到停滞（若尚未尝试，则先再尝试一次恢复）时，运行进入测量。进入测量并不意味着成功。

  2. 基线 · 未知值不测量运行状态基线比较规则占比 · 测试 · 覆盖率测量

    测量读取运行状态中保存的基线，不是新的基线运行。

  3. 5 项验收条件测量评定等级评分卡 · 等级

    build 成功、test 通过率 100%、覆盖率变化不低于 −5（仅在基线已知时）、删除的测试为 0、surefire 排除为 0。只有五项全部通过才评定等级。

  4. 5 项验收条件测量删除 · 排除 · 失败失败 · 停滞报告

    通过删除测试或 surefire 排除获得的通过，以及 build 或 test 失败，都仍是失败。删除与排除检查在无法读取 Git 或 POM 时计为 0，因此不能证明每项违规都会被发现。

  5. 继续 · 测量 · 最多 3 次下一步上限 · 停滞退出失败 · 停滞报告

    因达到上限或停滞而结束的运行仍会经过测量，但不报告为成功。这是报告上的区分，而不是绕过测量的捷径。

所有连接以相同粗细显示。选择一个流程，即只突出显示其路径，并标出步骤编号。

  • 实线 · 输入、结果与记录的流向
  • 虚线 · 运行、判定、请求
  • 长点线 · 观测与报告，独立于判定
  • 短虚线 · 失败、停止、上限
  • 粗黑线 · 所选流程；数字表示顺序
  • 方框 · 代码或状态边界，标题栏注明名称
  • 内层小框 · 该边界中的组件
  • 点线框 · 该边界之外
  • 橙色轮廓 · 模型作出判断之处
  • 流水线步骤 · 修复
  • 验证 · 路由 · 验收
  • 状态 · 记录
  • 修复前探索

依据非公开的实现与开发记录绘制。名称采用通用的公开名称；不展示代码路径和客户信息。

重新构建失败后的输入
模型修复会收到收集到的证据和修复指引，但一并传递的错误文本是最初的 build 错误，而不是重新构建产生的新错误。这一点通过读代码确认；未在运行中复现，源码也未修改。
验收条件的局限
若覆盖率基线未知，则跳过该项。surefire 检查统计的是当前 POM 中的排除项，而不是与基线的差异。删除与排除检查在无法读取 Git 或 POM 时计为 0。
案例与数字
约 40 个 setter 错误追溯到同一个原因（Lombok 与 POM 配置），这是当时记录的诊断，并非吞吐量、准确率或最终交付数据。