拆解 Addy Osmani 的增量实现 SKILL：五条让 AI 不跑偏的纪律

系列第二篇：Google 工程师如何稳住 AI 开发节奏

程序员李白继续拆解 Google Chrome 工程总监 Addy Osmani 的 skills 仓库（addyosmani/agent-skills，81K ⭐）。上一篇拆的是创意精炼术 idea-refine，这次拆的是代码增量实现 SKILL——专门管一件事：怎么让 AI 写代码时，别一口气堆出整个系统。

Vibe Coding 时目标明确后往往就是实现代码，这时候最容易犯的错就是让 AI 一次性把代码全部实现完。结果一改就是几百行，测也测不清，回滚更痛苦，白白消耗大量 Token。Addy 这份 Skill 盯住的正是这个冲动。

五条可直接应用的心法

1. Loop 先行：定义一个规范开发流程

普通人让 AI 干活常常毫无章法，而这份 Skill 要求每一片都落到可运行、可验证的状态，才允许往前走。

文件给 AI 设计了一个主循环：做 → 测 → 验 → 提交，每一步执行完才进入下一个实现。它还写死了一条触发条件：你一想写超过 100 行再测，就该启用这份 Skill。边界很清楚，诱惑一冒头，流程就接管。

2. 切片要垂直：一次跑通一条完整路径

最推崇的实现方法叫垂直切片（Vertical Slice）——一上来先别横向铺功能，而是把功能点定义成一个个切片（Slice），逐个实现。

比如实现一个网站需求：

Slice 1 就让 AI 从数据库到 API 再到基础 UI 整条路径跑通
Slice 2 再做列表
Slice 3 再做编辑

每一片结束，用户手里多的是一段真能用的能力。半成品和零件堆满仓库，这份 Skill 不认账。当前后端需要并行开发时，它还给出契约优先策略：先把接口契约固定下来，两边各自按契约推进，最后再集成。

3. 简单优先，不要过度设计

写代码之前先问自己：能工作的最简单方案是什么？

代码能否更精简？
这些抽象是否配得上当前复杂度？
你是在完成当前任务，还是在为假想设计？

如果只有三行相似代码，先忍受重复。先落地那个「显然正确」的朴素方法，等到正确性被测试证明之后，再考虑优化。这对 AI 尤其有效——模型天生倾向于「看起来规范优雅」的写法，这条规则等于提前关掉了过度设计的开关。

4. 实现范围纪律

这是全文件里最严格的一条规则：顺手清理隔壁文件、顺手删除看不懂的注释、顺手添加东西——这些行为全被禁止。

但有意思的是，如果在实现过程中看到了这种错误，也不要忽略，而是要求 AI 记录到「注意到的问题」清单（某文件有个 bug、某个注释写的不匹配），留给独立修复。发现与修改，必须解耦。

5. 杜绝 AI 偷懒：反模式表

文件后半段有一张常见辩解表，这才是 Skill 的灵魂——它预判了人和 AI 可能给自己找的各种理由，然后逐一明确禁止：

AI 的借口	现实
「最后一起测」	Slice 1 的 bug 会污染后续每一个切片
「一次性做完更快」	一旦出错，你根本不知道是哪 500 行里引发的
「改动太小不用单独提交」	小提交几乎零成本，大提交才代价高昂
「重构很小，塞进这次也行」	功能和重构捆绑，code review 和回滚都会更艰难

好习惯仅靠临场提醒是不够的，规则必须提前写定才有效。

为什么这份 Skill 值得抄

五条心法——loop 先行、垂直切片、简单优先、范围纪律、反模式预写——本质上都在做同一件事：把 AI 的一次性大爆炸输出，拆成可验证的小步，并在每一步设下验收关卡。

这与我们之前在 Wiki 里沉淀的 [[vertical-slice-development]]（垂直切片开发法）完全同源，只是 Addy 把它编码成了一个可执行的 SKILL。模型负责聪明，纪律负责让它不跑偏。

仓库：https://github.com/addyosmani/agent-skills