“重构用户模块、增加分页、加入缓存并优化查询”包含多个独立风险，难以审查和回滚。更好的拆分是：
- 明确一个用户可见行为或缺陷。
- 建立能够证明当前行为的测试或运行证据。
- 实施最小修改。
- 运行目标检查与相邻回归。
- 审查 diff 后再进入下一个行为。
小步不等于不思考整体架构，而是让每一步都能说明目的、风险和验证结果。
AI 编程助手倾向于多做一点：增加配置开关、提前抽象、顺手升级依赖、扩大防御逻辑或清理周围代码。这些修改可能没有即时 Bug，却会永久增加阅读、测试和维护成本。
任务契约应明确：
- 只实现已要求的行为。
- 列出不会修改的模块和非目标。
- 不增加没有当前使用者的抽象或配置。
- 不格式化、重命名或升级无关内容。
- 新依赖必须说明标准库和现有依赖为何不足。
Review 时逐项询问：“这处修改与需求有什么直接关系？”无法回答的改动应删除或拆成独立任务。
写代码前先读相邻实现。命名、错误处理、状态管理、依赖注入、日志、测试夹具和目录边界应优先沿用现有做法。只有当现有模式直接导致当前问题时，才把针对性重构纳入方案。
避免两种极端：
- 为了“一致”复制已知错误或安全缺陷。
- 为了“更先进”在一个局部引入全新架构和依赖。
需要偏离现有模式时，用一句话写明证据和取舍，并评估迁移范围。
Bug 修复应先建立能够稳定复现问题的失败测试。新功能先定义对外行为、错误和边界，再写最小实现使测试通过。这样测试回答的是“系统应该做什么”，而不是事后描述“刚写的实现做了什么”。
测试变绿后才进行命名或去重等整理，并持续保持测试通过。不要通过删除断言、扩大 mock、批量更新快照或跳过用例制造绿色结果。
以下情况不应继续强行完成原计划：
- 实际调用链与计划假设不一致。
- 公共契约、数据迁移或权限边界需要改变。
- 工作区出现来源不明的并发修改。
- 验证环境缺少关键依赖，无法证明完成。
- 最小修复会触发明显更大的架构变化。
此时回到调查阶段，说明新证据、受影响范围和备选方案。停止并澄清通常比堆叠补丁更快。