工作流
让 AI 把重命名与行为改动拆成两次交付
先审机械修改，再审业务语义。
资料核验2026.11.12 · 编码助手 · 可用于现有软件仓库
一个任务既重命名订单模块，又修改了退款条件。结果一份差异有几百行，看不出真正改变用户行为的是哪两行。让助手先完成机械移动，审查会轻很多。
交给编码助手的任务
给助手一项同时涉及订单模块改名和退款条件变化的需求，要求第一段只改路径和引用并跑原有测试。第二段用明确的退款金额与状态样本验证业务规则。
给两段工作各一个结束条件
第一段只改路径和引用，旧测试必须通过。第二段再写新的退款条件和验收样例。分成两个提交后，审查者能单独核对每段，也可以只撤掉行为变化。
如果生成文件随目录移动，要确认生成工具读的是新路径。真正影响运行时的配置留给第二段单独解释。
拆分以能验证为准。如果第一段注定无法运行，就重新找一个能保持行为的中间状态。
先准备一个对照样例
第一步将 orders 模块移动到新路径，原退款样例仍应得到原结果。第二步只调整退款状态允许范围，新增一条原本失败的新行为样例。维护者可以只还原第二步，验证路径仍然正确。
用这些结果验收
- 第一段可独立构建，结果与原实现相同。
- 第二段只有必要的业务差异。
- 单独撤销第二段时路径仍正确。
审查时容易漏掉什么
拆分以可运行的中间状态为准。某些生成文件或构建配置确实必须随路径一起改，这些应归在第一段。第二段评审才重点看业务行为和边界输入。
改名阶段尽量保持公共 API、构建命令和测试期望不变。若重命名同时改变外部路径，应另列兼容处理。让审查者先看可机械确认的差异，再看业务逻辑，这样回退第二段时不会失去第一段的可读性改进。
