# Incremental Impl

> 已确认改动需要协调多个完整结果、交付依赖或迁移中间状态时使用；单一明确结果不因跨文件而触发。

- Skill: `ben2pc/incremental-impl` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ben2pc/incremental-impl`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ben2pc/incremental-impl/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ben2pc (https://skillmd.com/u/ben2pc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ben2pc/incremental-impl

---


# 增量实现

本技能的核心产物是**需求改动的实施拆分**：把已确认方案变成一组边界完整、完成标准明确的实施单元。单写者、代理派发和工作树只是拆分完成后的执行选择，不能反过来决定单元边界。

## 1. 确认改动边界

- 读取用户最新决定、验收契约、已确认的 `arch_design.md` 和当前计划作为实现约束，复用仍有效的上下文。依据最新用户决定与适用规则识别已失效记录，修正当前依据或引用；无法消解且影响范围、行为或结构的冲突交回用户，只暂停依赖它的工作。
- 提取本次必须实现的需求结果、必须保持的不变量、明确非目标和已有依赖。
- 有现成计划时按完整单元定义就地补齐结果、依赖和完成证据；拆分不完整时调整，不另建一份任务清单。
- 不在实现阶段重新决定产品范围、模块边界或迁移形态。

## 2. 定义完整实施单元

**完整实施单元**是在依赖已满足的前提下，可以独立交付一个连贯需求结果或一个合法迁移状态的最小改动集合。它包含证明结果成立所需的实现、行为保护和必要配套变更；完成后仓库处于可验证、可继续集成且必要时可回退的状态。

一个单元必须同时满足：

1. **结果完整**：对应一条验收标准或一组不可分割的验收标准。结果所需的各层代码、测试、配置、数据变化和必要文档同步都包含在内，不留下只能依靠未来单元才能成立的半成品。
2. **边界内聚**：单元内的改动因同一个需求结果或技术不变量而同时变化。共享同一行为、事务边界、公共契约或必须原子生效的改动不能为了缩小任务而拆开。
3. **可独立验证**：有明确证据能判断整个结果是否完成，包括自动化测试、构建检查、运行信号或必要的人工验证；一条验收标准可以对应多个验证用例。
4. **依赖明确**：只依赖已经存在或排在前面的稳定结果，不依赖其他未完成单元中的临时签名、隐藏状态或口头约定。
5. **中间状态合法**：完成后项目应可构建、可测试并保持现有行为；迁移任务可以停在设计已允许的兼容状态，但必须写清保护方式、退出条件和后续清理归属。

“修改某个文件”“增加一个数据类型”“补测试”或“交给某个代理”本身通常不是完整单元；只有它能独立完成一个需求结果或合法迁移状态时才算。文件数、代码行数、提交数量和写入者都不是单元边界。

## 3. 拆分需求改动

1. 将验收标准、技术质量目标和行为保护要求映射到具体结果。
2. 把必须同时成立的实现、测试和配套变化合并为一个单元。
3. 只有当两个结果能够分别验证、分别集成且其中一个完成后不依赖另一个的半成品时，才拆成不同单元。
4. 按依赖关系排序；依赖允许时优先验证风险最高或最不确定的单元。不要为制造并行机会改变边界。

拆分记录复用当前计划的承载位置；只有没有可用位置时才新建下表，不要求已有计划改成固定格式：

| 单元 | 需求结果 | 包含范围 | 依赖 | 完成证据 |
|---|---|---|---|---|
| `<name>` | `<完成后成立的需求结果>` | `<代码、测试与配套变化>` | `<已完成结果或无>` | `<如何证明整个单元完成>` |

拆分后按完整单元定义复核；发现半成品、独立结果混杂或不可集成时，调整边界或顺序。

常见组织方式不是硬规则：功能与缺陷通常按端到端行为拆分；跨切面修改按能独立验证和回退的作用域分组；架构迁移按已确认设计中的合法中间状态拆分。

## 4. 增量执行与集成

- 默认单写者按依赖顺序实施。只有拆分完成后，确认候选单元的文件所有权互不重叠、输入输出边界稳定，且彼此不存在未满足依赖，才考虑并行写入。有前后依赖的单元必须等待前置结果完成并集成，不能用“集成顺序明确”代替依赖独立。
- 多写者时记录每个单元的写入者、模型或推理强度、工作树、文件所有权和验证命令。模型与推理强度默认继承，确有需要时使用运行时支持的参数覆盖，不写死型号。
- 并行写者使用运行时原生工作树，或由主代理预先创建并传入路径。共享工作树须同时确认文件所有权与共享状态可隔离：检查 Git 索引、锁文件、生成物、运行端口及其他实际共享资源；暂存、提交等共享操作由协调者串行处理，目录不重叠本身不足以保证安全。独立工作树仍需检查端口等工作区外共享资源。无法建立等价隔离时改为串行。
- 可以使用运行时提供的代理间通信，但正确性不能依赖临时消息。权威接口、决定和进度必须能从仓库或持久计划验证。
- 写入代理收到单元结果、权威资料、工作目录、文件所有权、禁止范围、依赖、验证方式和期望证据。发现契约冲突或无法守住边界时暂停受影响写入并报告，由协调者按第 1 节处理。
- 每个单元结束时核对完整性定义和验证证据，再按依赖顺序集成。交付验证按 `../spec-design/references/validation-results-template.md` 及时登记。委派写入只返回变更结果、验证证据和未解决问题，由主代理汇总，避免争写；内联实现不生成额外的固定交接模板。
- 按 `git-workflow` 在有意义的语义边界提交，不强制每个实施单元对应一个提交。新行为、缺陷修复和重构的测试纪律交给 `test-driven-development`；异常转入 `systematic-debugging`。
- 只有全部单元集成且整体验收完成后才能声明任务完成；按结果模板核对覆盖并向用户汇报验证结果、缺口和范围外发现。