增量实现法

要解决的问题

“先把几百行改动写完再跑测试”是日常开发中最容易翻车的习惯：bug 会随代码累积，切片1的偏差会让后续2~5个切片全错；一次性改动数百行，一旦出问题很难定位是哪一行引入；重构和功能更新混在一个提交里，排查和回滚都变得困难。这些场景最终往往导致推倒重写，反而更耗时。

技能的工作方式

该技能围绕增量实现法展开，核心是把大功能拆成薄而完整的垂直切片，通过固定循环推进：

• 每个切片先实现最小的完整功能，运行测试套件（无测试则补测试），验证功能正常、构建通过后提交，再推进下一个切片，避免跳步或重启；
• 内置多类切片策略：优先用垂直切片交付端到端功能，后端与前端并行开发时可用契约优先切片，也可直接优先攻克风险最高的部分，提前发现问题；
• 强制执行7条实现规则：

- 规则0：简单优先：写代码前先思考最简单的可行方案，三行重复代码优于过早抽象，先保证正确性再优化；
- 规则0.5：范围纪律：只修改任务要求的部分，不顺手清理周边代码、不重构无关文件；
- 规则1：一次只改一个逻辑点，避免混合关注点；
- 规则2：每次增量后保持项目可编译、现有测试通过；
- 规则3：未完成功能用 feature flag 控制，避免不完整代码暴露给用户；
- 规则4：新代码默认使用安全保守的行为；
- 规则5：每次增量独立可回滚，迁移需配套回滚方案。

适用边界与注意点

• 仅适用于多文件改动、新功能开发、代码重构等场景，单文件、单函数的极小改动无需遵循；
• 避免“最后统一测试”的侥幸心理，也不要让“顺手改一点”的范围膨胀，更不要在代码未变化时重复运行同一验证命令；
• 不要在第三次使用前构建抽象，不要为一次性操作创建工具类，也不要在增量中混入无关重构。