先给重构方案，别直接上手改
配方模板 · 尚未在本站完成实测
本页是配方模板，尚未在本站完成实测。运行记录、token与耗时会在复测后补上；在那之前不填任何估算数字。
适用场景
一块代码想重构，但怕直接改会牵一发动全身；想先拿到一份能评审的方案。
准备
- 宿主版本
- 待填（实测时记录具体rc版本号）
- 模型
- 待填
- 模式 / 权限
- 建议先用标准模式 + 工作区内修改
- 需装插件
- 无（如用到插件，在实测后补齐名称与版本）
- 输入材料
- 放在独立工作区，原始文件先备份
完整指令
针对【目标文件 / 模块】，先出重构方案，不要修改任何代码。
方案包含：
1. 现状问题：现在哪里别扭、为什么难维护（带文件:行号）。
2. 目标结构：重构后长什么样，画关键调用关系。
3. 分步计划：每步做什么、动哪些文件、如何保证不破坏现有行为。
4. 风险与回滚：哪步最容易出错、出错怎么退。
5. 验收标准：怎么证明重构成功且没引入回归。
要求：每步都要能独立提交、能回滚；不要一次大改写。运行记录
| 项目 | 数值 | 备注 |
|---|---|---|
| 耗时 | 待实测 | |
| 结果 | 待实测 | |
| 输入 / 输出token | 待实测 | |
| 残留 | 待实测 |
产物
跑通后在这里给出文件清单与截图，并说明原始文件有没有被改动。
验收清单
点一下可勾选，用来逐条核对。
- 方案未改动任何代码
- 每步可独立提交与回滚
- 标出了风险最高的一步
- 给了可执行的验收标准
失败与边界
- 方案不等于批准执行，需要人评审
- 大模块先小范围试点再全量
- 卡在哪：同code-review：需要真实仓库与真实技术债。给自造代码出的重构方案看起来都对，因为本来就没有坑。