几乎每个后端项目都会走到这样一个阶段：功能还能跑，但代码越来越厚，职责开始漂移，评审越来越难看清重点。团队通常卡在两个担心之间，一边知道该重构，一边又担心“改大了出事”。AI 在这一课最有用的地方，不是推动大规模优雅重写，而是帮助你更早发现热点、更稳地切最小安全改动，并把审查意见组织成可执行结论。
真实研发场景
真正阻碍重构的不是懒，而是不确定性
很多代码大家都知道“不太对”，例如职责开始堆在一起、重复逻辑到处出现、异常语义越来越散。但真正要动它时，团队常常又停下来，因为没人敢确保改动不会影响既有行为。于是代码继续累积，直到某次需求不得不碰它，风险更大。
AI 能在这里帮上忙，是因为它很适合先做“热点扫描”和“风险预判”。但前提仍然是：你必须先知道什么行为不能变。
本课核心是“先锁行为，再做最小安全改动”
重构真正应该追求的，不是一次性变得更优雅，而是每次都能明确回答：
- 这次改的是哪一块
- 哪些行为必须保持不变
- 风险主要在哪里
- 改完后用什么证据证明安全
传统做法的痛点
代码审查最常见的问题是“只看风格，不看风险”
| 常见做法 | 表面上完成了什么 | 实际遗漏了什么 |
|---|---|---|
| 讨论命名和格式 | 看起来很认真 | 没看行为是否变化 |
| 给出“大改建议” | 看起来很先进 | 没考虑改动范围和验证成本 |
| 看到重复就想合并 | 看起来在去重 | 没确认重复逻辑是否真同构 |
| 审查意见很长 | 看起来覆盖很多 | 没有按风险和优先级排序 |
重构和审查阶段最值钱的信息，不是“哪里不优雅”，而是“哪里会出风险”。
最常见的三个重构误区
- 没有测试或行为锚点，就直接开始改结构
- 让 AI 给出“大而全重构方案”，却没有分批切片
- 审查意见停留在抽象描述，没有变成可执行结论
AI 能提效到哪一步
AI 最适合做的重构与审查辅助
- 热点识别：指出长方法、重复逻辑、职责漂移和边界不清的区域
- 方案候选：给出几个更小的改动切法，而不是只给终态设计
- diff 风险筛查：从行为变化、异常路径、权限边界角度扫风险
- 审查意见整理：把零散观察变成带优先级的结构化结论
不适合直接交给 AI 的动作
| 动作 | 原因 |
|---|---|
| 在没有测试时主导大规模重构 | 缺少安全护栏 |
| 直接采纳“更优雅”的终态方案 | 可能和当前业务节奏不匹配 |
| 把审查意见原样贴进 PR | 模型的合理性不等于准确性 |
一个实用原则是：AI 最适合告诉你“先改哪里、先防什么”，不适合替你决定“一次改到什么程度”。
推荐工作流
先锁定行为，再讨论结构
重构前先准备：
- 现有关键测试或最小行为说明
- 你认为最痛的热点区域
- 这次能接受的改动范围
- 明确不打算顺手处理的内容
五步最小安全改动法
| 步骤 | AI 产出 | 人工要做什么 | 验证方式 |
|---|---|---|---|
| 1. 锁行为 | 不可改变行为清单 | 补关键测试或说明 | 是否有明确安全边界 |
| 2. 扫热点 | 候选重构点与风险 | 选择最小切片 | 是否能单独提交和验证 |
| 3. 做改动 | 局部重构建议或 diff 风险清单 | 只做这一刀该做的事 | diff 是否可控 |
| 4. 跑验证 | 回归测试、关键用例、行为对照 | 确认无行为漂移 | 真实运行结果 |
| 5. 写审查结论 | 结构化 review 备注 | 只保留高价值结论 | 团队是否可复用 |
一个适合审查阶段的输出格式
发现：
影响范围：
风险等级：
建议动作：
需要的验证：
这个格式能逼 AI 和工程师都不要停留在“这里可以优化一下”这种空话上。
与仓库代码和模板的映射
- 工具注册边界：
../demo/src/main/java/com/example/ainative/agent/tool/ToolRegistry.java适合讨论职责单一的组件为什么更容易安全重构。 - 工作流链路：
../demo/src/main/java/com/example/ainative/workflow/KnowledgeWorkflowService.java适合练习多步骤逻辑如何先锁行为再重构。 - 安全规则边界：
../demo/src/main/java/com/example/ainative/ai/safety/SafetyPolicy.java适合讨论“风格优化”和“安全行为”谁更不能改。 - 行为测试：
../demo/src/test/java/com/example/ainative/workflow/KnowledgeWorkflowServiceTest.java、../demo/src/test/java/com/example/ainative/ai/safety/SafetyPolicyTest.java适合说明为什么重构必须绑着测试走。 - 对应练习：
../课后练习/第8课/练习.md
常见误用与风险
误用一：没有测试就让 AI 给大重构方案
没有行为护栏时，越“漂亮”的改法越危险。
误用二：把代码审查做成风格检查
风格问题可以以后再谈，行为风险和边界风险必须先谈。
误用三：把 AI 审查意见原样发给同事
审查意见需要人工筛选和排序，否则只会制造噪音。
误用四：重构后不记录为什么这样改
没有结构化结论，团队无法把这次经验复用到下一次相似场景。
课后练习
建议直接在 ../课后练习/第8课/练习.md 中完成本课练习，并使用 ../课后练习/通用提交模板.md 保留 AI 输入、人工删改和验证结果。
如果你只做最小版交付，也至少保留四样东西：结构化输入、AI 产出摘要、人工判断记录、最终验证结果。
基础题
找一个你认为“该重构但不敢动”的类或方法，先写出不可改变的行为清单。
进阶题
让 AI 给出 2 到 3 个更小的改动切片，再人工选择最安全的一刀并说明理由。
挑战题
对这次改动输出一份结构化审查结论，至少包含发现、风险等级、建议动作和验证结果。