46,000 Star 的 AI 编程技能包：让 AI 按工程流程工作，而不只是写代码_边学边练

46,000 Star 的 AI 编程技能包：让 AI 按工程流程工作，而不只是写代码

如果你用过 Claude Code、Cursor 或 Gemini CLI 做过真实项目，你一定遇到过这个体验：

AI 很聪明，但它不会"按流程做事"。

需求还没说清楚，它就开始写代码；测试没补，它说"看起来没问题"；改动越来越大，你却不知道它到底改了什么；上线风险没评估，它就急着让你 merge。

addyosmani/agent-skills 就是来解决这个问题的。

GitHub 地址：https://github.com/addyosmani/agent-skills

它已经获得 46,000+ Star，5,000+ Fork。作者 Addy Osmani 长期在 Google 负责 Chrome、开发者体验和 AI 相关工作。

它到底是什么

一句话：这是给 AI 编程助手用的工程技能包。

普通提示词解决的是"这次怎么回答"，agent-skills 解决的是"以后遇到这类任务该怎么干"。

它把软件开发拆成了一套套可复用的 Skill：需求澄清、方案设计、增量实现、测试驱动、代码审查、安全加固、性能优化、CI/CD、发布上线……

AI 拿到的不是一句"帮我写代码"，而是一套完整的工程流程约束。

这才是它真正厉害的地方。

7 个核心 Slash Commands

项目提供 7 个覆盖完整开发生命周期的核心命令：

命令	作用	关键行为
`/spec`	需求澄清与规格定义	不让 AI 直接写代码，先把目标、边界、接口、风险说清楚
`/plan`	任务拆解规划	把大任务拆成可验证的小步骤，防止 AI 一次改十几个文件
`/build`	增量实现	薄切片（thin slice）实现：先做一小块，跑测试，再继续
`/test`	测试驱动开发	围绕行为写测试，用测试证明代码真的工作，不是假测试
`/review`	代码审查	Staff Engineer 级别的 Review 清单：正确性、可维护性、安全性
`/code-simplify`	代码简化	防止 AI 写"能跑但很绕"的代码，能删就删，能直白就直白
`/ship`	发布准备	系统性检查上线风险，清单化的发布前确认

Mermaid Diagram

为什么是 7 步而不是 1 步

这 7 个命令，本质上复刻了高级工程师的工作方式。

任何优秀的技术团队都不会"直接上代码"。他们会先想清楚再动手（/spec），拆小了再做（/plan），一小块一小块验证（/build + /test），上线前再过一遍（/review + /ship）。

agent-skills 把这套流程沉淀成了 AI 可以执行的约束。

这解决了 AI 编程的根本问题：AI 的问题从来不是"写不了代码"，而是"不知道什么时候该停、该问、该验证"。

⚠️ 核心排坑：不要一次把所有 7 个命令都加载进去。上下文越多，AI 越容易抓不到重点。推荐从 /spec、/plan、/build 三个开始，用熟以后再逐步添加。

23 个专项 Skill：更细粒度的工程能力

除了 7 个核心命令，项目还提供 23 个专项 Skill，覆盖更细粒度的工程场景：

最值得关注的 4 个

test-driven-development：强制 AI 先写测试再写实现，测试必须覆盖真实行为，不允许写没有意义的"假测试"。对后端接口、工具函数、复杂业务逻辑特别有价值。

code-review-and-quality：把 Staff Engineer 的 Review 清单塞给 AI。它关注的是正确性、可维护性、测试覆盖率、潜在风险边界，而不是"代码风格看起来不错"。

security-and-hardening：专为安全敏感场景设计。如果你的代码涉及登录、权限、用户输入、数据库、文件上传、第三方接口，这个 Skill 是必要的质量门。AI 写业务代码时常常遗漏安全细节，有专门的安全检查流程会稳很多。

code-simplification：防止 AI 写"很绕"的代码。它的原则是：不为了显得聪明而复杂，能删就删，能直白就直白。代码是写给人看的，不是给 AI 看的。

怎么实际用起来

典型工作流示例

假设你要做一个新功能，推荐的流程：

第一步：/spec
→ AI 不会立刻写代码
→ 而是问你：目标是什么？用户是谁？边界在哪里？
→ 强制你先把需求说清楚

第二步：/plan
→ AI 把任务拆成 5-8 个小步骤
→ 每步都可以单独验证
→ 防止后期翻车不知道哪步出的问题

第三步：/build（循环执行直到完成）
→ 每次只实现一小块
→ 跑测试验证
→ 确认没问题再继续下一块

第四步：/test
→ 补全测试覆盖
→ AI 会问"这些边界情况你测试了吗"

第五步：/review
→ 模拟 Staff Engineer Review
→ 发现遗漏的问题

第六步：/ship
→ 发布前清单检查
→ 确认上线风险可控

安装方式（各工具支持）

Claude Code：通过插件安装
Cursor：把 SKILL.md 放到 rules 目录
Gemini CLI：通过 skills 安装命令
Windsurf / OpenCode / Copilot Agent / Codex：放入系统提示词或指令文件

本质上，Skill 就是 Markdown 文件。任何支持规则文件、系统提示词或 Agent 指令的 AI 编程工具，都可以使用。

工程建议：在团队中推广时，可以把关键 Skill（如 security、review、test）作为"强制项"，其他 Skill 作为"可选项"。这样既保证底线质量，又不过度约束每个开发者的工作方式。

它适合谁，不适合谁

三类最适合的人

经常用 AI Coding Agent 的开发者：你会明显感觉 AI 没那么"飘"了，做事更有步骤，翻车成本低很多。

团队负责人：可以把这些 Skill 当成团队 AI 编程规范，让大家用同一套质量门槛。避免不同成员用 AI 产出质量差异过大的问题。

想学习工程方法的人：哪怕不用 AI，单看这些 Skill 文件，也能学到很多高级工程师的工作习惯——这套方法论本身就有价值。

不适合的场景

❌ 只是写一个小脚本、临时工具，过度工程化
❌ Token 预算非常有限，7步流程消耗比较高
❌ 需要极快速出结果的原型验证（可以跳过 /spec，直接 /build）

为什么 46,000 Star 不奇怪

agent-skills 最打动人的地方，是它把一件事想明白了：

AI 编程的瓶颈，从来不是 AI 不会写代码，而是 AI 不知道应该怎么工作。

普通提示词优化，是在帮 AI 把某一次任务做得更好。而 agent-skills 做的是把"工作方式"沉淀成可复用的流程约束——让 AI 在每次任务中都按工程规范行事，而不是随机发挥。

这个思路，和软件工程几十年来的最佳实践高度一致：标准化流程，不依赖个人能力的高低。

AI 编程的下一阶段，拼的可能不只是模型能力，而是谁能把工程经验沉淀成可复用的流程。

agent-skills 踩在了这个点上。

局限与注意事项

⚠️ Skill 只能约束工作方式，不能保证结果永远正确。复杂业务逻辑、生产数据、安全权限、上线发布，仍然需要人来最终判断。

⚠️ Skill 越多，上下文负担越重。不要把所有 23 个 Skill 都加载进去，AI 会变慢、变啰嗦，甚至抓不到重点。按需加载，场景匹配。

⚠️ 它不是银弹。任何流程约束都有被"绕过"的可能——AI 如果被指令冲突，可能会走捷径。定期审查 AI 的实际输出，确认 Skill 规则在真实执行。

参考资源

GitHub：https://github.com/addyosmani/agent-skills
作者：Addy Osmani（Google Chrome Developer Experience）
适配工具：Claude Code、Cursor、Gemini CLI、Windsurf、OpenCode、GitHub Copilot Agent、Kiro、Codex

公众号二维码