维护调查与对照验证

它不是“一键自动修复”。每个阶段的结论都保存为可审阅的记录，执行前需要你确认，交付前需要你判断。

入口#

维护调查总是从具体上下文进入，不是独立的侧栏页面：

前提条件#

• 默认模型：调查会多轮调用模型，点击前会提示“此操作会调用已配置模型”。
• 维护 Agent Worker 在线：调查在后台进行，离开页面后仍可恢复。服务未连接时，已有记录仍可查看，但不能开始新的模型操作。
• 隔离执行（执行对照时需要）：Docker 沙箱已启用，复现 Worker 在线。

调查流程#

页面顶部的“修复与验证流程”显示当前阶段，并给出唯一的下一步按钮：

随时可以：

• 在“补充线索或调整方向”中填写实际运行环境、补充步骤或需要核对的实现，点击“补充并继续”；
• 点击“停止调查”，已有方案与记录会保留，之后可以“恢复当前调查”；
• 把某条已核实的发现“确认并记为项目约定”，后续调查会沿用，也可以随时停用。

审阅候选补丁#

候选补丁显示新增和修改的文件、文件差异，以及方案引用的依据。补丁只保存在 RepoCare 中，没有应用到仓库，也没有提交；如需采用，请下载补丁后在对应版本的开发分支中审阅和测试。

需求对照#

准备需求对照时，RepoCare 会把问题拆成逐条要求，并为每条要求对应：

• 原文：引用问题中的精确原文；
• 生产改动：补丁中对应的修改；
• 同一目标测试：两个版本共用的测试命令；
• 原版预期断言：在原始版本上应该出现的失败信号。

此外还会安排额外回归命令，检查正常行为在两个版本上都能通过。

确认并执行对照#

1. 在“审阅与执行两版计划”中查看完整计划：固定提交、环境、依赖、准备步骤、验证步骤和需要注意的事项。可以展开“查看要写入沙箱的文件内容”。
2. 处理“执行前置条件”。真正缺少的环境或需求信息需要先补齐；如果某项只影响结论范围、不妨碍当前命令执行，可以在“核对阻塞与范围”中逐项复核，并写下至少 8 个字的理由。复核会保留记录，不会忽略环境预检发现的真实阻塞。
3. 支持的计划可以点击“检查运行环境”：静态核对版本声明、选定测试和相关 conftest，不安装依赖、不运行代码。
4. 勾选确认项（已核对补丁 Diff 和共同使用的测试、同意在隔离环境执行仓库代码），点击“确认执行此计划”。
5. 执行结束后点击“读取结果并继续”，整理实际结论。

解读对照结果#

“需求与改动验证”区域回答两个问题：目标有没有改善？其他行为验证到哪里？

额外回归命令显示“两版全部通过”“存在失败”“待执行”等状态。

添加人工验收测试#

模型准备的测试可能和补丁出自同一思路。为提高说服力，可以在“人工验收对照”中添加独立的 pytest 验收测试：

1. 至少选择一条需要验收的要求。
2. 粘贴顶层 test_ 函数，或读取本地 .py 文件（最多 20KB）。测试应导入项目的公开接口。
3. 填写目标测试函数名和原版预期失败标记（断言中实际会出现的文本），以及至少一个正常行为测试函数名。
4. 说明测试来源与覆盖范围，并声明测试是否提供给了生成候选的模型。
5. 原计划缺少依赖准备时，可以补充受支持的 pip 准备命令，它们同样要经过校验与预检。
6. 点击“保存待审阅的验收方案”。保存不调用模型、不执行代码，之后仍要逐条审阅并确认执行。

系统会保存你的声明和实际执行依据，但无法据此证明测试的独立作者身份或盲测条件。

导出记录#

对照记录可以导出为 Markdown 和 JSON，包含仓库、原始提交、计划指纹、规则版本、每条要求的原文与测试、额外回归、执行前置条件和范围限制。导出内容属于固定版本，不会自动查询最新的 GitHub 内容。