Incremental Implementation Zh

---
name: incremental-implementation-zh
description: 增量实现、薄切片交付、按计划逐个任务落地。当用户说「这个功能怎么一步步做」「别一次写太多」「按任务清单开始实现」「先做哪一片」「特性开关下逐步合并」「一个任务太大不知从哪下手」时，或者你即将一口气写超过 100 行代码时使用。核心：实现→测试→验证→提交→下一片的循环；垂直切片优先，契约先行切片、风险优先切片；规则 0 简单优先、0.5 范围纪律、一次一件事、随时可编译、未完成功能用开关、安全默认、可回滚。也覆盖「开始实现」「各自验证的几片」「按增量方式推进」这类说法。改编自 addyosmani/agent-skills 的 incremental-implementation（MIT）。
author: Captain
version: 0.1.1
display_name: "增量实现（薄切片）"
display_name_en: "Incremental Implementation (zh)"
description_zh: "把功能切成可独立验证的薄片，实现→测试→验证→提交循环推进；垂直/契约先行/风险优先三种切法；简单优先与范围纪律；未完成功能放开关后面。"
description_en: "Slice features into thin, independently verifiable increments and loop implement→test→verify→commit; vertical, contract-first and risk-first slicing; simplicity and scope discipline; unfinished work behind flags."
tags:
  - "增量实现"
  - "薄切片"
  - "incremental"
  - "垂直切片"
  - "特性开关"
  - "范围纪律"
examples_zh:
  - "按计划里的任务 3 开始实现，先只做 schema 和接口"
  - "这个功能太大，帮我切成能各自验证的几片"
  - "我总想一口气写完，帮我按增量方式推进"
examples_en:
  - "Start task 3 from the plan, schema and API only"
  - "This feature is too big, slice it into verifiable pieces"
  - "I keep writing everything at once, drive this incrementally"
metadata:
  { "openclaw": { "requires": { "bins": ["git"] }, "os": ["darwin", "linux", "windows"], "emoji": "🧱" } }
---

# 增量实现（薄切片）

一次实现一片、测一片、验一片，再扩展。每个增量都让系统停在**可工作、可测试**的状态。这是让大功能变得可控的执行纪律。

用于任何多文件改动、按任务清单做功能、重构，以及你想在测试前写超过 ~100 行的时候；单文件单函数的小改动不需要。

## 增量循环

实现最小的完整功能片 → 跑测试（没有就先写）→ 验证（测试过、构建过、手工查）→ 提交（描述性信息）→ 下一片（接着来，不推倒）。

## 三种切法

- **垂直切片（首选）**：一条完整路径贯穿全栈。片 1 创建任务（库 + 接口 + 基本 UI）→ 片 2 列表 → 片 3 编辑 → 片 4 删除。每片都能端到端演示。
- **契约先行**：前后端并行时——片 0 定契约（类型、接口、OpenAPI）→ 1a 后端按契约 + 接口测试 / 1b 前端按契约用 mock → 片 2 联调。
- **风险优先**：最不确定的先做——先证明 WebSocket 能通，再做实时更新，再做离线重连。片 1 失败你就不会在片 2、3 上浪费投入。

## 规则

- **规则 0 简单优先**：写之前问"最简单能工作的是什么"；写之后查：能更短吗？抽象值回它的复杂度吗？资深工程师会不会说"你直接……不就行了"？在为假想需求造东西吗？三行相似代码好过过早抽象；先写显然正确的朴素版本，测试证明正确后再优化。
- **规则 0.5 范围纪律**：只碰任务需要的。不顺手清理邻近代码、不整理没改的文件的 import、不删不懂的注释、不加规格外的功能、不现代化只读到的文件。看到范围外值得改的，**记下来不动手**："注意到但没碰：…要不要我建任务？"
- **一次一件事**：一个增量一件逻辑上的事；加组件、重构旧组件、改构建配置是三个提交。
- **随时可编译**：每个增量后必须能构建、现有测试通过；片与片之间不留坏状态。
- **未完成功能放开关后面**：功能没准备好但要合增量时用环境变量/开关隐藏，小增量照样能进主干。
- **安全默认**：新代码默认保守、关闭、需要显式打开。
- **可回滚**：每个增量可独立回退——新增优先；对现有代码的修改小而聚焦；迁移有回滚；删与替换分开提交。

## 指挥 Agent

明确每个增量的范围内与范围外："做计划里的任务 3。先只做 schema 变更和接口，UI 下个增量再做。做完用仓库自己的测试和构建命令验证。"

## 每个增量后的检查

```
- [ ] 这一片做了一件事并做完整　- [ ] 现有测试全过（用仓库自己的命令）　- [ ] 构建成功
- [ ] 类型检查通过（如有）　- [ ] lint 通过　- [ ] 新功能按预期工作　- [ ] 已提交且信息清楚
```
一次成功的运行后，代码没变就别重复跑同一条命令——重复跑不增加信息。

## 合理化借口对照

| 借口 | 现实 |
|---|---|
| "最后一起测" | bug 会叠加：片 1 的 bug 让片 2–5 都错 |
| "一次做完更快" | 感觉更快，直到坏了却在 500 行里找不到原因 |
| "这么小不值得单独提交" | 小提交免费；大提交藏 bug、回滚痛苦 |
| "开关以后再加" | 没完成的功能就不该对用户可见；现在加 |
| "这个重构小，顺手包进去" | 重构混功能让两者都难评审难排查 |

## 红灯

写了 100 多行没跑测试；一个增量里多件不相关的事；"顺便再加个这个"；为了快跳过测试/验证；增量之间构建或测试是坏的；未提交改动越攒越多；第三个用例出现前就建抽象；"既然来了"碰范围外文件；为一次性操作建工具文件；代码没变重复跑同一条命令。

## 验收

- [ ] 每个增量都单独测试并提交　- [ ] 全量测试通过　- [ ] 构建干净　- [ ] 功能端到端符合规格　- [ ] 没有未提交改动

---
改编自 [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) 的 `incremental-implementation`（MIT）。改动见 ATTRIBUTION.md。