Agent Skills 实测：一条命令给 AI 编程工具装上工程素养
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
AI 编程 agent 有个通病：能省的步骤它都想省。不写 spec 直接写代码，不写测试直接提交，review 一步直接跳过——这不是哪家模型的问题，是"抄近路"本身就是默认行为。
Addy Osmani（Chrome 团队出身，写过《Learning JavaScript Design Patterns》）开源的 agent-skills，就是想把这个毛病治一治。它把资深工程师做软件时真正在用的工作流、质量门槛和最佳实践，打包成 AI agent 能读懂的技能包，装进 Claude Code、Cursor、Codex、Windsurf 这些工具里，让 AI 每一步都按流程走，而不是凭感觉抄近道。
这篇文章讲清楚三件事：agent-skills 到底是什么、怎么用；它和另一个更早、更火的 superpowers 有什么本质区别；两个能不能同时装，日常又该怎么选。
为什么突然冒出一堆"技能包"项目
Skill 这个概念这两年才成为 AI agent 的标准能力。简单说，它是一份 Markdown 文件，里面写清楚"遇到什么场景，该走什么流程，每一步验证什么"，agent 在合适的时机自动读取并遵循。跟传统的 system prompt 比，skill 的好处是可以按需加载——不用一次性把所有规则塞进上下文，用到哪个场景才拉哪个技能进来，省 token 也更精准。
这个机制一旦标准化，就出现了两类项目：一类是"技能工具箱"，你按需取用；一类是"方法论框架"，它接管你整个开发流程。agent-skills 和 superpowers 正好分别是这两类的代表，搞混了会直接影响你的选择。
agent-skills 是什么，怎么用
一句话概括：agent-skills 是一套按软件生命周期分类的工程技能库，覆盖 Define（定义）、Plan（规划）、Build（构建）、Verify（验证）、Review（审查）、Ship（发布）六个阶段，一共 24 个技能，外加 4 个专家人设（代码审查员、测试工程师、安全审计师、性能审计师）和 7 份参考清单（Definition of Done、安全清单、无障碍清单等）。
写这篇文章时（2026-08-16）这个仓库有 87,587 star、9,385 fork，MIT 协议，主要维护者除了 Addy Osmani 本人，还有 nucliweb 和 federicobartoli 两位常驻贡献者。
安装方式，最省心的是官方给的通用 CLI，支持号称 70+ 个 agent 工具：
如果你用 Claude Code，走插件市场更原生：
装完之后，项目提供 8 个开箱即用的斜杠命令，对应软件生命周期的每一步：
命令 | 对应阶段 | 作用 |
/spec | 定义 | 先把需求写清楚，不让 AI 猜 |
/plan | 规划 | 拆成可执行的任务清单 |
/build | 构建 | 一次只做一小块，增量实现 |
/test | 验证 | 用测试证明功能是对的 |
/review | 审查 | 合并前的质量门槛 |
/webperf | 审查 | Core Web Vitals 性能审计 |
/code-simplify | 审查 | 复杂度收敛，别过度设计 |
/ship | 发布 | 走完 CI/CD，正式上线 |
个人觉得最实用的设计是
/build auto：一次批准后，agent 自动生成计划并按 TDD 节奏逐个任务提交，不用你每一步都盯着按 yes。核心理念是"process, not prose"——技能文件里不是泛泛的建议，而是具体到步骤的操作手册，还带着"反理性化表"：把 AI（以及人）想跳过某一步时常用的借口列出来，逐条给反驳理由，逼着流程真正执行，而不是走个形式。每个技能都有明确的验收标准，要求给出证据（测试通过截图、构建日志、真实运行数据），而不是一句"应该没问题"。
好处很直接：你不用自己从头写 CLAUDE.md 规范工程流程，也不用在每个项目里重复造轮子；技能是模块化的，只在当前任务相关时加载，不会把上下文塞满；覆盖面从需求定义一路到上线部署，比市面上大多数只做代码审查或只做测试的单点技能包完整得多。
superpowers 是什么，跟 agent-skills 差在哪
superpowers 是 obra（Jesse Vincent）做的项目，同样 MIT 协议，写文章时 star 数是 272,610，比 agent-skills 还夸张，说明这类"给 agent 立规矩"的需求确实旺盛。
它和 agent-skills 最大的不同，不在技能数量，而在强制程度。agent-skills 更像一个分类清晰的工具箱，你缺哪个拿哪个；superpowers 更像一套完整的方法论操作系统，一旦装上，它会通过一个叫
using-superpowers 的元技能，逼着 agent 在做任何事之前先检查"有没有相关技能可用"——原文写得很硬："如果有 1% 的可能性某个技能适用，你就必须调用它，这不是可以商量的。"superpowers 的核心是一条七步串联的流水线：
- brainstorming —— 用提问逼你把需求想清楚，而不是拿到需求就动手
- using-git-worktrees —— 建隔离工作区，跑通测试基线再开工
- writing-plans —— 把任务拆到 2-5 分钟粒度，每步都有文件路径和验证方式
- subagent-driven-development —— 派子 agent 独立执行，完成后做两阶段审核
- test-driven-development —— 严格 RED-GREEN-REFACTOR，不写测试不让写代码
- receiving-code-review —— 对着计划逐条核对，按严重程度分类问题
- finishing-a-development-branch —— 决定合并、提 PR、保留分支还是直接丢弃
装法跟 Claude Code 插件生态一致：
也支持 Cursor、Gemini CLI、GitHub Copilot 等平台，装法大同小异。
两者的差异可以归纳成一张表：
维度 | agent-skills | superpowers |
定位 | 分阶段技能工具箱 | 端到端强制方法论 |
触发方式 | 8 个显式斜杠命令为主 | 元技能强制 agent 主动检查 |
覆盖范围 | 需求到上线全生命周期，含性能/安全/无障碍清单 | 聚焦分支隔离、计划拆解、TDD 闭环 |
适合场景 | 单点补强某个环节 | 接管整个开发节奏 |
跨工具支持 | 通用 CLI，官方号称 70+ 工具 | 各平台原生插件命令，同样覆盖广 |
简单说：agent-skills 回答的是"这一步该怎么做才专业"，superpowers 回答的是"整个开发过程该怎么组织"。前者是内容，后者是流程骨架。
能同时装吗，日常怎么选
技术上可以同时装。 两者都是标准的 Claude Code 插件，技能按插件名做了命名空间隔离，不会互相覆盖文件。真正需要注意的不是"能不能装"，而是"装了会不会打架"。
两个项目都有
test-driven-development 这种同名技能，细节流程不完全一致。同时装上之后，如果 superpowers 的强制检查机制生效，agent 可能会在同一个场景里看到两份措辞不同的 TDD 指令，容易增加上下文噪音，甚至出现两边流程细节打架的情况。这不是硬故障，但会消耗多余 token，也可能让 agent 的执行不够一致。我自己的用法，也是推荐给你的组合：
- 把 superpowers 当默认操作系统。 平时开发新功能，让它接管 brainstorming、worktree 隔离、计划拆解、TDD 这条主线，agent 的行为节奏交给它管。
- 从 agent-skills 里挑 superpowers 没覆盖的专项技能补进来，比如
performance-optimization、security-and-hardening、browser-testing-with-devtools、accessibility相关清单——这些是 superpowers 偏 git/TDD 流程里没有深入覆盖的领域。
- 装 agent-skills 时不用全装，按需拉：
npx skills add addyosmani/agent-skills --skill security-and-hardening，避免技能库互相冲撞。
一个简单的判断标准：如果你希望 AI 帮你把整个开发节奏管起来，从需求澄清到分支怎么收尾都替你想好，选 superpowers；如果你已经有自己的工作习惯，只是想在某个环节（比如 review 或性能审计）补上专业清单，选 agent-skills 里对应的单个技能。两个都装，只装你真正需要的部分，别图省事全量塞进去。
技能这套机制刚从 Claude 生态扩展到 70+ 个 agent 工具，接下来一年大概率还会冒出更多细分方向的技能包。与其等一个"大而全"的方案，不如先想清楚自己团队缺的到底是"流程骨架"还是"某个环节的专业度"，再对症下药。
2026.08.16 20:30
沪·赵巷