小步增量实现

要解决的问题

多文件改动、新功能开发和重构有一个共同的陷阱：一次性写完所有逻辑，最后一次性验证。

当你花了几个小时写完 500 行代码才第一次运行测试，出错时面对的是一整片改动，很难定位到底是哪一处引入了问题。更糟的是，如果中途 Bug 不断累积，Slice 1 的缺陷会让后续所有切片都建立在错误基础上，返工成本指数级上升。

这类问题的根因不是技术能力，而是执行纪律：缺少清晰的增量边界和验证节奏。

核心方法

这个技能的原则是 Build in thin vertical slices —— 每次只实现最小的完整功能片段，验证通过后再进入下一切片。

单次增量循环

每个切片按以下步骤执行：

• 实现：只写当前切片所需的最小功能，不多写一行
• 测试：运行已有测试套件，没有测试就先补一个
• 验证：确认测试通过、构建成功、行为符合预期
• 提交：用描述性消息记录本次增量，便于回溯和回滚
• 推进：进入下一切片，不重启、不推翻已有工作

切片策略

三种常用方式：

• 纵向切片（首选）：每片都走通完整链路，端到端可用
• 契约先行：前后端并行开发时，先定义接口契约再各自实现
• 风险优先：先做最不确定的部分，如果失败能在投入更多资源前发现

实施规则

技能内置了一组工程规则来约束每次增量：

• Rule 0: 简单优先 —— 写代码前先问"最简单的可行方案是什么"；三行重复代码胜过过早的抽象
• Rule 1: 一次只改一件事 —— 每个 commit 只对应一个逻辑变更，不要把重构、新功能和构建配置混在一起
• Rule 2: 保持可编译 —— 每次增量后项目必须能构建、已有测试必须通过
• Rule 3: 功能开关 —— 未完成的功能用 feature flag 包裹，合并到主干时不暴露给用户
• Rule 4: 安全默认值 —— 新代码默认行为应当保守
• Rule 5: 易于回滚 —— 每个增量可独立回退，数据库迁移要配套回滚脚本

与 Agent 协作

当指挥 Agent 增量实现时，明确指出当前增量范围内做什么、不做什么，避免 Agent 自行扩大范围。

适用边界与注意点

适合使用的场景：

• 涉及多个文件的改动
• 从任务拆解构建新功能
• 重构现有代码
• 任何让你在测试前想写超过 ~100 行代码的情况

不适合的场景：

• 单文件、单函数的极小改动

常见误区：

• "最后一起测试更快" —— Bug 会复利累积，切片 1 的问题会让切片 2-5 全部出错
• "这些小改动不值得单独提交" —— 小 commit 零成本，大 commit 会掩盖 Bug 且难以回滚
• "顺便把旁边的代码也清理一下" —— 范围扩散会让 review 和调试都变难，发现范围外的改进记下来但不动手

红旗信号 一旦出现以下情况，说明增量纪律已经破防：连续写超过 100 行未测试、单个增量混入多个不相关变更、构建或测试在切片间处于破损状态、为一次使用创建新工具文件、在代码没变的情况下重复运行同一个验证命令。

增量实现不是放慢速度，而是让每一次验证都有明确的归因范围。