祖传代码渐进式重构
🎯 解决什么问题
有个 5 年没人敢动的模块，逻辑绕、没测试、改一行崩三处。智能体先为它生成表征测试锁定现有行为，再按小步重构：拆长函数、去重、补类型注解，每步跑测试验证行为不变。你负责 review 每个 PR，而不是亲手改。
😣 那个五年没人敢碰的模块，业务还天天依赖它；每次需求都绕着走、补丁叠补丁，新人入职第一课就是“别动那块代码”，技术债利息越滚越高。
💡 不敢动的祖传模块 2 周内变得可维护
🛠 操作步骤（共5步）
1
生成表征测试锁定行为智能体先为模块的公开函数写高覆盖的表征测试（pytest/Jest），全部跑通作为“行为基线”——这是重构的安全网，没有它不动手。
2
画出依赖与调用图谱分析模块的出入参、全局状态和外部依赖，标出高风险耦合点，决定重构顺序：先外围、后核心。
3
小步重构、逐个 PR每次只做一件事：拆长函数、消除重复、补类型注解；每步跑测试，红了立刻回滚，一个 PR 只含一个改动意图。
4
人工 review 每个 PR你只看 diff 和测试结果，不亲手改；业务语义存疑的地方打回，让智能体补充注释说明“为什么这样写”。
5
沉淀重构日志每轮记录改了什么、为什么这么改，写进仓库的 REFACTOR_LOG.md，后人接手不再靠“考古”。
📋 提示词模板（复制即用）
你是一名资深重构工程师。目标模块是 [模块路径]，业务背景是 [一句话说明它干什么]。约束：1）先为现有公开函数生成表征测试并全部跑通；2）每次重构只改一处，保持测试全绿；3）禁止改变任何对外行为；4）输出每个 PR 的改动说明和风险点。现在开始第一步：生成表征测试。
🧰 用到工具
Muse · GitHub · pytest
⚠️ 注意事项
- 没有测试的重构就是赌博，表征测试必须先行，哪怕它写得丑，先有再优。
- 单个 PR 的 diff 别超过 300 行，否则 review 形同虚设，风险也失控。
- 遇到“看不懂但测试过了”的代码，先让智能体加注释解释再动，别凭感觉删。