最近几年，AI 写代码的产出速度肉眼可见地变快了。一段需求丢给模型，几秒钟就能吐出几百行，单元测试、文档、重构样样都能做。但用着用着就发现一个怪现象：交付的速度上去了，落到生产环境的质量却没跟着上去。
代码能跑，但不敢合并；看着挺全，但经不起评审；测试覆盖有了，但每次回归都翻车。这是”快”和”烂”并存的真实写照。
今天开始，我想用一个系列文章把 addyosmani/agent-skills 这个开源项目拆开来讲。它做的事情很朴素：把一个高级工程师脑子里的工程纪律（spec → plan → build → test → review → ship），打包成 AI 编码代理能直接执行的”技能”。这个系列一共九篇，今天是开篇。
这个项目的来头
Addy Osmani 是 Google Chrome 的工程总监，长期负责前端工程效能。他把团队里资深工程师沉淀下来的工作流，写成了一套 24 个 Markdown 技能文件，配合 8 个 slash 命令（/spec /plan /build /test /review /code-simplify /webperf /ship），让 Claude Code、Cursor、Gemini CLI、OpenCode 等 70+ 工具能直接调用。
仓库目前已经攒下 27K+ ⭐，MIT 协议，社区在持续合入贡献。它不是某一家的产品，而是一套跨工具的”工程纪律清单”。
我把它克隆下来读了一遍，最大的感受是：作者关心的不是”AI 怎么写代码”，而是”AI 怎么不写烂代码”。这中间差出来的，就是一整套质量门控。
为什么 AI 写代码容易”又快又烂”
如果你用过 AI 写代码，下面的场景大概率眼熟：
- 改一个字段类型，模型顺手把另外 7 个不相关的函数也改了，因为它觉得”风格不统一”。
- 写完一段功能说”已经测试过了”，但其实只跑了 happy path，边界条件一个都没覆盖。
- 接到一个模糊需求，模型直接动手写，写到一半才发现核心 API 选错了。
- 重构时性能变差了，模型没察觉，因为没跑 benchmark。
- 上线前没加监控，第一个用户报 bug 时你只能对着日志猜。
这些不是模型的”能力问题”，而是流程问题。模型会顺着概率往下走，而工程纪律要求的是：在每一步停下来确认。当前 prompt 里写了什么，下一步就走什么——没人要求它停下来。
agent-skills 的思路是：把”停下来确认”这件事，写成显式的步骤和门控。每一个技能都自带”反合理化表”和”红色信号”，堵住模型找借口跳过流程的企图。这一点后文我会单独展开讲。
六阶段流水线长什么样
这是整个仓库最核心的一张图，我把它做成 mermaid 放出来：
flowchart LR
D["DEFINE
想法打磨"] --> P["PLAN
任务拆解"]
P --> B["BUILD
增量实现"]
B --> V["VERIFY
调试验证"]
V --> R["REVIEW
代码评审"]
R --> S["SHIP
上线发布"]
S -.反馈.-> D
六个阶段首尾相接，对应 8 个 slash 命令：
| 阶段 | 命令 | 一句话原则 |
|---|---|---|
| 定义 | /spec |
先写规约，再写代码 |
| 计划 | /plan |
拆成原子任务 |
| 构建 | /build |
一次只切一片 |
| 验证 | /test |
测试就是证据 |
| 评审 | /review |
改完再交 |
| 上线 | /ship |
可逆，可观察 |
其中 /build 还支持一个 auto 模式：在 plan 批准后，一次性把整个任务链跑完，中间不停下来催你”是否继续”。它省掉的是任务间的人工切换成本，没省掉的是任务内部的验证——每个原子任务仍然走 TDD，仍然单独提交。
24 个技能是怎么组织的
技能不是平均铺在六个阶段里，每个阶段的密度不一样。我做了一个分布图：
pie title agent-skills 的 24 个技能按生命周期分布
"DEFINE 定义" : 5
"PLAN 计划" : 1
"BUILD 构建" : 5
"VERIFY 验证" : 1
"REVIEW 评审" : 4
"SHIP 上线" : 4
"META 元技能" : 4
可以看到，DEFINE 和 BUILD 阶段是技能最密的两个地方。这和工程实践中的认知一致：需求定义不清是大部分返工的源头，而构建阶段的纪律（切片、TDD、API 设计、UI 工程）直接决定代码能不能落地。
24 个技能各自的归属阶段，可以先列在这里，后面几天会一篇篇拆开讲：
- DEFINE：interview-me、idea-refine、spec-driven-development、source-driven-development、doubt-driven-development
- PLAN：planning-and-task-breakdown
- BUILD：incremental-implementation、test-driven-development、frontend-ui-engineering、api-and-interface-design、context-engineering
- VERIFY：debugging-and-error-recovery
- REVIEW：code-review-and-quality、code-simplification、security-and-hardening、performance-optimization
- SHIP：shipping-and-launch、ci-cd-and-automation、observability-and-instrumentation、deprecation-and-migration
- META：using-agent-skills、documentation-and-adrs、git-workflow-and-versioning、browser-testing-with-devtools
这个系列想讲什么
整个 9 篇的安排是这样的：
- 今天这篇 · 8/1：开篇，你正在看。
- 8/2 · DEFINE 阶段：把”要什么”想清楚——interview-me / idea-refine / spec-driven-development。
- 8/3 · 反合理化机制：Anti-Rationalization 与 Red Flags 怎么堵住 AI 的偷懒借口。
- 8/4 · PLAN + BUILD：把大象切成薄片——原子任务、垂直切片、TDD。
- 8/5 · VERIFY + REVIEW：调试分诊、五维度评审、代码简化。
- 8/6 · SHIP：CI/CD、可观测性、上线清单与回滚。
- 8/7 · 多 Agent 安装实战：在 Claude Code / Cursor / Gemini / Codex 里怎么装、踩过哪些坑。
- 8/8 · 横评：agent-skills vs Superpowers vs Matt Pocock skills。
- 8/9 · 收官：从”能跑”到”可合并”——AI 时代的生产级标准是什么。
节奏上周末两篇轻一点，工作日四篇是深度技术文，再加周五的实操和周六的横评。让你每天的阅读负担别太重。
阅读前的两个约定
第一，agent-skills 不是给”完全不会写代码的人”准备的。它假设你已经会用 Claude Code 或类似的 AI 工具，它解决的是”工具有了，但工程纪律没跟上”的问题。
第二，这套技能不是替代你思考，而是替代你”忘记提醒模型要思考”。每一条规则背后都是有名字的工程实践，你不需要接受它，但应该知道它在防什么。
明天开始我们进 DEFINE 阶段，看看 agent-skills 是怎么让 AI 先问对问题、再动手的。
参考资料