增量实现法

先承认一个常见问题

接到一个跨多文件的功能时，容易先写几十上百行再跑测试。结果要么是测试积压到最后一次爆，要么是中途改接口后忘了同步前端，最后靠记忆补漏。

更麻烦的是回滚。如果一整块功能都压在同一个 commit 里，出问题只能整体 revert，连「哪一行引入的」都很难定位。

增量实现法怎么工作

核心思路：用薄薄的纵向切片推进。 每块只打通一条完整路径，比如 DB + API + 基础 UI，而不是先写完所有 DB、再写所有 API。每块都按同一循环走：

1. 实现一个最小完整功能——能用，但只覆盖当前路径。
2. 跑测试套件；缺测试就补，优先为这一小块写测试。
3. 验证：测试过、build 过、手动核查行为如预期。
4. 提交，写清这次改了什么。
5. 再进入下一块。

切片策略有三条：

• 纵向（首选）：一次打通一条端到端路径，每块都交付可测的功能，不出现「代码写完了但没法演示」。
• 契约优先：前后端并行时，先定 API 契约（类型 / 接口 / OpenAPI），后端按契约实现加测试，前端按契约 mock，最后集成。
• 风险优先：先啃最不确定的一块，早失败早暴露。

四条纪律贯穿始终：

• 简单优先：动手前问「最简单能跑通的是什么」；写完后复查能否更短。三行相似代码优于过早抽象。
• 范围纪律：只碰任务所需。发现无关问题（如未使用的 import）就记下来，不顺手修。
• 一次一件事：每个增量只改一个逻辑点，不同关注点分开提交。
• 保持可编译：每块后构建和既有测试都要过，绝不留下坏状态。

适用边界

适合多文件改动、从任务拆解构建新功能、重构既有代码。

不适合单文件、单函数或范围已经极小的改动——那种直接做就行，套增量流程反而增加负担。

需要合并但不该暴露的功能，用特性开关关掉（默认关闭、显式开启）。数据库迁移要带对应回滚，且不要在同一次提交里又删又建。

每块完成后会产出一份 IncrementLog，记录各切片是否测试通过、构建通过、已提交、是否用了开关、能否回滚。下游评审和发布流程可以直接消费这份记录，而不是重新问一遍「这次改了啥」。