第六章：行内改动与重构：小步修改、可回滚、可审阅

6.1 行内修改的正确姿势：一次只改一个“意图”

行内修改最常见的失败模式是“顺手改太多”：修 bug 的同时改命名、改目录、改风格。结果就是：

• diff 不可读
• 回滚困难
• 测试失败时很难定位

更稳的方式是拆成三轮：

• 第一轮：只修 bug 或实现功能（最小可用）
• 第二轮：补测试与边界条件
• 第三轮：重构清理（可选）

6.2 让 Cursor 先说“改哪几行”，再动手

你可以在行内改动前先要求：

先不要直接改代码。
请先指出需要改动的最小位置（文件/函数/行附近），并解释为什么改这里。

这一步会把很多“改错文件”的风险挡在外面。

6.3 重构的三条硬约束

当你让 Cursor 做重构时，建议你写死三条约束：

约束：
1) 行为不变，对外 API 不变
2) 不要全仓库格式化，不要大规模重命名
3) 每次只做一类重构，并确保测试通过

6.4 审阅清单：你应该看什么

行内改动也要按工程标准审阅：

• 是否只改了目标相关代码？
• 是否引入了新的边界问题（空值/异常/大数据）？
• 错误处理是否更清晰？
• 是否出现硬编码导致环境耦合？
• 是否需要补测试？

6.5 本章小结

行内改动与重构想要“稳”，核心是：

• 一次只改一个意图，避免混合主题
• 先定位最小位置，再动手修改
• 重构三条硬约束（行为不变、小步、可验证）

下一章我们进入跨文件任务：如何用 Composer 做多文件改动，同时保持范围可控、审阅可读。