AI 写的代码能跑，但总觉得”差点意思”——没有测试、没文档、边界情况不思考、上来就硬编码。

你让它写个接口，它给你返回一个 JSON；你让它加个功能，它给你改坏三个旧功能。不是说 AI 能力不行，而是它”没规矩”——不知道什么时候该写 spec，什么时候该加测试，什么时候该做 code review。

Google 的 Addy Osmani 出了一个新项目，直接解决了这个问题。

它不是一堆提示词，而是一套”工程操作系统”

Agent Skills 的核心思路很简单：把资深工程师的工程纪律，编码成 AI 能执行的技能。

传统方式下，你跟 AI 说”帮我写个好代码”，它凭感觉写。 Agent Skills 的方式是这样的：

  DEFINE          PLAN           BUILD          VERIFY         REVIEW          SHIP
 ┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐      ┌──────┐
 │ Idea │ ───▶ │ Spec │ ───▶ │ Code │ ───▶ │ Test │ ───▶ │  QA  │ ───▶ │  Go  │
 │Refine│      │  PRD │      │ Impl │      │Debug │      │ Gate │      │ Live │
 └──────┘      └──────┘      └──────┘      └──────┘      └──────┘      └──────┘
  /spec          /plan          /build        /test         /review       /ship

7 个斜杠命令，对应软件开发的完整生命周期。每个命令会激活一组预定义的技能，自动执行相应的工程流程。

20 个技能，都覆盖什么？

这是整个项目最硬核的部分。每个技能都是一个完整的 Workflow，有步骤、有检查点、有退出标准：

Define（定义阶段）：

• idea-refine：用结构化思维把模糊想法变成具体提案
• spec-driven-development：写 PRD，涵盖目标、命令、结构、代码风格、测试、边界

Plan（计划阶段）：

• planning-and-task-breakdown：把 spec 拆成可验证的小任务

Build（构建阶段）：

• incremental-implementation：薄垂直切片实现，特性开关，安全默认值
• test-driven-development：红-绿-重构，测试金字塔，80/15/5 原则
• context-engineering：在正确的时间给 AI 正确的信息
• source-driven-development：每个框架决策都要基于官方文档
• frontend-ui-engineering：组件架构、设计系统、响应式、WCAG 2.1 AA
• api-and-interface-design：契约优先设计、Hyrum's Law、单版本规则

Verify（验证阶段）：

• browser-testing-with-devtools：Chrome DevTools MCP 实时调试
• debugging-and-error-recovery：五步 triage 法

Review（审查阶段）：

• code-review-and-quality：五轴审查，变更大小约 100 行
• code-simplification：Chesterton's Fence，500 行规则
• security-and-hardening：OWASP Top 10、三层边界系统
• performance-optimization：Core Web Vitals、测量优先

Ship（发布阶段）：

• git-workflow-and-versioning：基于主干的开发、原子提交
• ci-cd-and-automation：左移、质量门、特性开关
• deprecation-and-migration：代码即负债思维
• documentation-and-adrs：架构决策记录
• shipping-and-launch：预发布检查表、分阶段发布、回滚

三个最值钱的亮点

1. Anti-Rationalization（反理性化）

这是我见过最狠的设计。每个技能都有一个表格，列出 AI 常用的”借口”和对应的反驳：

• “我后面再补测试” → “测试是证据，不是可选项”
• “这个需求很简单，不需要写 spec” → “最简单的需求往往有最复杂的边界”
• “先上线再说，后面优化” → “技术债务的利息比本金增长快”

AI 也会偷懒，这个设计直接堵住了”抄近路”的路。

2. Verification is non-negotiable（验证不可协商）

每个技能最后都有”证据要求”：不是”测试通过”，而是”pytest 显示 95% 覆盖率，类型检查无错误，lint 通过”。

“看起来没问题”在 Agent Skills 里是不存在的。

3. 来自 Google 的工程文化

项目文档里明确说了，许多理念来自《Software Engineering at Google》这本书：

• Hyrum's Law（API 兼容性）
• Beyonce Rule（测试）
• 测试金字塔
• 左移（Shift Left）
• 代码即负债
• 变更大小约 100 行

这相当于把 Google 十几年的工程实践，蒸馏成了 AI 能执行的技能。

总体评价

谁适合用：

• 团队用 AI 做生产级开发（不只是原型）
• 对代码质量有要求的项目
• 想让 AI 遵循统一工程规范的个人开发者

谁不适合用：

• 快速原型验证
• 一次性脚本
• 只是玩一玩 AI 编程

需要注意的：

• 学习曲线：20 个技能、7 个命令，需要花时间理解
• 不是所有 AI 工具都支持（主要支持 Claude Code、Cursor、Gemini CLI、Windsurf）
• 技能是”opinionated”的，有些团队可能不认同某些规范

使用提议

适合：

• 生产级项目开发
• 团队统一代码规范
• 想学习 Google 工程实践的开发者

不适合：

• 快速原型
• 简单的一次性任务

最佳实践：

1. 先安装 /spec /plan /build /test /review /ship 六个核心命令
2. 从简单项目开始试用，理解每个技能的触发时机
3. 可以根据团队需求自定义技能（都是 Markdown 文件）
4. 配合 GitHub Copilot 或 Claude Code 使用效果最好

一句话总结：Agent Skills 不是让 AI 写更多代码，而是让 AI 学会”怎么写好代码”——这才是生产级开发和原型开发的本质区别。

你用 AI 写代码时，最头疼的问题是什么？是质量不稳定、还是缺少测试、或者代码难以维护？欢迎在评论区聊聊。如果觉得有用，提议收藏，下次给 AI 设定工程规范时翻出来看看。