Appearance
Incremental Implementation 解决的是 AI 一口气写太多、写完不好查的问题。它要求把功能切成薄片：实现一小步，验证一小步，再继续下一步。这样 diff 更小，错误更容易定位，回退成本也更低。
AI 写代码怎么小步推进：Incremental Implementation 怎么用
下载 incremental-implementation 中文版 Skill ZIP
AI 最容易让人上头的地方，是它能一下子写很多代码。
AI 最容易让项目出问题的地方，也是它一下子写很多代码。
一个大功能如果一次性生成完，表面上进展很快。等你 review 时才发现：有些逻辑没接上，有些边界没处理，有些文件被顺手重构，测试也不知道该怎么补。
incremental-implementation 这个技能的重点是小步推进。
不是慢，是稳。
什么叫薄切片
薄切片不是把功能按文件切开，而是按可见结果切开。
比如要做“用户可以保存 API Key”，不要这样切：
- 写类型。
- 写接口。
- 写组件。
- 写样式。
- 写测试。
这种拆法看起来工程化，实际每一步都很难单独验证。
更好的切法是：
- 页面先显示一个输入框和保存按钮。
- 按钮点击后能调用已有保存函数。
- 保存成功后显示状态。
- 保存失败后显示错误。
- 再补测试或手动走完整路径。
每一步都能打开页面看见变化。AI 做错了，也容易知道错在哪一步。
小步推进不是只写少量代码
有时候一步会改几个文件，这没问题。
关键不是文件数量，而是这一小步有没有清晰目标。
比如“新增一个字段并从后端传到前端显示”，可能会改类型、接口、组件、测试。它仍然是一个薄切片，因为目标明确，验证路径明确。
相反，“整理用户模块代码”可能只改两个文件，也可能很危险，因为目标太虚。
判断一小步是否合格，可以问三句话：
- 这一步完成后，用户或测试能看到什么变化？
- 这一步失败时，能不能快速定位？
- 这一步能不能单独回退？
答不上来，就还需要拆。
每一步都要停下来验证
AI Agent 很容易连续执行：写文件、继续写、再继续写，然后在末尾告诉你完成了。
这不是增量实现。
增量实现的节奏应该是：
text
选一个小目标
↓
改最少的代码
↓
运行对应验证
↓
看结果
↓
再决定下一步如果你正在修 bug，验证可以是一条失败测试变绿。如果你正在写页面，验证可以是浏览器里走一次操作。如果你正在改文档，验证可以是链接和 frontmatter 检查。
不要等十个文件都改完才发现第一步方向错了。
什么时候要阻止 AI 继续扩写
看到这些信号，就该停一下：
- AI 开始改无关文件。
- AI 自己新增了你没要求的抽象层。
- AI 为了兼容旧方案加了一堆 fallback。
- AI 把“顺手优化”当成当前任务。
- AI 还没验证，就继续写下一块。
这时不要继续夸它“很好，继续”。应该把范围拉回来：
md
停一下。当前任务只做 [具体目标]。
不要继续重构其他文件。
先验证刚才这一步是否通过，再决定下一步。这类提醒很有用，尤其是在长任务里。
小步推进和提交有什么关系
如果你在正式项目里写代码，薄切片最好能对应小提交。
一个提交只表达一个意图：修一个 bug、加一个可见行为、补一组测试。这样回滚时不会连带撤掉一堆无关改动。
个人项目也可以不每步都提交，但心里要有“可回退点”。至少在大改前看一下 git status，知道哪些文件已经改过。
AI Agent 不会天然珍惜你的工作区。你要自己管理节奏。
古法编程怎么理解增量实现
古法编程的 P2 是受控实现。
受控不是不用 AI，而是一次只让 AI 做一个可验证动作。Prompt 越清楚，切片越小，AI 越像工具；任务越大，边界越虚，AI 越像黑盒。
真正稳定的 AI 编程，不是“让它一口气做完”，而是让每一步都能被人看懂。
你可能还需要
同类技能：
如果你已经开始实现，下一步要盯住验证节奏：每完成一个小目标，就停下来证明它真的可用。