进阶编程
用 AI 重构代码且不破坏上下文
用 AI 做重构的受控流程，避免把整个仓库交给模型或接受不可审查的大改动。
适合谁
- 在真实仓库使用 AI 的开发者。
- 重构前补测试的团队。
- 想要小 diff 的工程师。
不适合谁
- 没有测试或版本控制的仓库。
- 无法审查代码的人。
- 极端时间压力下的生产热修。
工作流步骤
步骤 1
定义重构边界
明确要重构的函数、模块或行为，并说明哪些不能改变。边界模糊时 AI 重构容易失败。
示例输入
只重构 parseInvoiceDate，不改变公开 API 或日期语义。
期望输出
窄范围重构 brief。
常见失败
模型因为觉得相关而修改邻近代码。
人工检查
先看 diff 文件列表，再看代码。
步骤 2
捕获当前行为
改代码前，让 AI 推断当前行为并识别缺失测试，围绕边界情况补测试。
示例输入
列出该函数当前行为和缺失测试。
期望输出
行为摘要和测试计划。
常见失败
AI 改了行为却声称只是重构。
人工检查
重构前后都跑测试并比较失败。
步骤 3
先要计划再改代码
让助手提出重构计划、预期修改文件和风险，拒绝过大的计划。
示例输入
给三步重构计划，暂时不要改代码。
期望输出
改代码前可审查的计划。
常见失败
模型直接改代码并隐藏取舍。
人工检查
只批准能达成目标的最小计划。
步骤 4
生成最小 diff
要求生成最小补丁，并解释每处修改原因，让审查可控。
示例输入
做保持行为并通过测试的最小 diff。
期望输出
有限补丁。
常见失败
补丁包含格式噪音或无关清理。
人工检查
拒绝无关修改，即使看起来不错。
步骤 5
审查、测试和记录
运行测试、审查 diff，并让 AI 总结风险点，人工审查后再提交。
示例输入
审查这个 diff 的行为变化、边界情况和缺失测试。
期望输出
最终审查说明。
常见失败
测试通过在覆盖不足时造成虚假信心。
人工检查
检查测试是否真正覆盖重构行为。
人工审查清单
- 检查 AI 输出是否真正解决 AI-assisted refactoring，而不是变成泛泛回答。
- 核验事实、日期、名称、数字、链接和引用内容。
- 删除无依据结论、空话、重复衔接和过度自信表达。
- 发布或发送前，对照读者、渠道和格式检查。
- 记录提示词、工具、输入材料、人工修改和最终判断，方便复用。
常见错误
- 用模糊提示词开始 AI-assisted refactoring，没有验收标准。
- 还没给来源、限制、示例和审查规则，就要求模型直接给最终答案。
- 把流畅回答当正确答案，没有检查来源覆盖、隐藏假设和边界情况。
- 研究、写作、审查和最终编辑都用同一个提示词。
- 因为第一版看起来顺，就跳过人工检查。