用途
Refactor Codebase 用于以增量方式重构代码库。它的核心理念是：永远不要试图一次性完成整个重构，而是先规划阶段，再逐个执行，并在每一步之间保持系统可运行。
两种模式
- 仅规划模式：访谈 → 微小提交计划 → GitHub issue。到此停止。
- 执行模式：规划（同上，或基于已有 issue）→ 逐阶段运行。
工作流程
1. 审计当前结构
阅读代码库，关注：文件夹布局与模块边界、耦合热点（被到处导入的文件、上帝模块）、职责混杂、测试覆盖率（重构风险）、构建/检查/测试工具。询问用户要解决什么痛点（导航、可扩展性、构建时间、团队扩展），以及明确不在范围内的内容。
2. 定义目标与范围
写一段简短的问题/目标陈述，包含目标文件夹/模块草图、约束（保持绿灯、不改变行为、仅增量）、非目标。就用户考虑过的替代方案进行访谈，敲定确切范围。如果覆盖率不足，商定一个 Phase 0 安全网（见 REFERENCE.md）。
3. 拆分为微小阶段
遵循 Fowler 的原则：每一步都足够小，使程序始终可运行。每个阶段必须：
- 只涉及一个关注点（例如“移动 auth 模块”“提取共享工具”）
- 可独立验证（阶段中指明测试/构建/检查命令）
- 可安全停止——没有半迁移状态
- 不超过约 20 个文件；更大的要拆分
每个阶段记录：移动/更改什么、迁移策略（先复制后删除、再导出垫片、codemod——见 REFERENCE.md）、验证命令。
仅规划模式：将计划作为 GitHub issue 提交，包含以下部分：问题陈述、解决方案、提交（微小，每个都让代码库保持可运行）、决策文档（模块、接口、架构——不含文件路径或代码片段，它们会过时）、测试决策、范围外。返回 issue URL 并停止。
4. 一次执行一个阶段
- 阅读范围内每个文件。
- 进行结构更改；更新所有导入（如有 codemod 则使用）。
- 运行该阶段的验证命令。
- 提交（refactor: phase N – <title>）；优先使用 git mv 保留历史。
- 在计划中标记该阶段完成，记录意外情况，在下一阶段前汇报。
护栏
- 结构重构期间绝不改变行为——记录 bug，不要在同一提交中修复。
- 先移动，在单独阶段重命名。
- 未经用户确认，不要连续执行多个阶段。
参考
REFERENCE.md——架构模式、迁移策略、Phase 0 安全网、验证命令、危险信号。