一天新增 670 stars，Addy Osmani 把工程流程写进了 AI Agent

GitHub Trending 的当天卡片显示，addyosmani/agent-skills 新增了 670 stars。我在 2026 年 8 月 9 日 22:50 左右按都柏林时间核验时，这个仓库的累计 stars 是 85,068；它刚在 8 月 4 日发布 v0.6.6，随后又在 8 月 7 日修复了所有 18 个 Skill 的参考资料链接，并为这类链接补上 CI 校验。

这个热度很容易被误读成“又一个 Agent Skills 合集”。但 agent-skills 的不同处不在于收录了多少提示词，而在于它试图把经验丰富的工程师平时会走的过程，写成一套能被 AI 编程工具重复执行、也能被检查的步骤：先定义，再计划，逐步实现，测试，评审，最后交付。

我想借 agent-skills 看看，为什么 AI 编程开始从“给模型一段规则”转向“给模型一条有验证点的工程路径”。期望对大家有所帮助。

它火的不是一个命令，而是一条开发路径

仓库的 README 把 24 个 Skill 组织成六段：DEFINE、PLAN、BUILD、VERIFY、REVIEW、SHIP。用户可以从 /spec、/plan、/build、/test、/review 等入口开始，也可以让工具根据任务自动选择相应 Skill。README 还提供了面向 Codex 的原生插件安装方式，而不是要求用户把长篇 Markdown 复制到某一个全局规则文件中。

这条路径背后的判断很朴素：模型写出代码不等于软件完成。真正容易出问题的地方，往往发生在需求还没有说清、修改范围没有拆开、测试没有对准风险，或者“性能优化”没有重新测量的时候。

想法
  ↓
规格 / 约束
  ↓
可验证的小任务
  ↓
实现与测试
  ↓
评审、测量与交付

这也是它和“把一份最佳实践放进 system prompt”最不一样的地方。后者希望模型在任何时候都记得一切；前者把当前任务需要的流程、检查项和停下来的条件交给一个特定 Skill。上下文更短，责任也更清楚。

一个性能 Skill，如何避免“优化了但没有变快”

拿仓库中的 performance-optimization 举例，它的核心不是列出 LCP、INP、CLS 的阈值，而是规定一条顺序：先测量，识别真实瓶颈，修复，再次测量，最后加上防回归措施。

MEASURE → IDENTIFY → FIX → VERIFY → GUARD

这听上去像常识，但对 Agent 很重要。模型特别擅长根据常见模式提出建议，例如“拆分 bundle”“加缓存”“用 memo”。如果没有基线和复测，它也同样容易把复杂度引入一个并不存在的瓶颈。

v0.6.6 把这个原则写得更硬：性能工作必须复用同一种测量方法；改动处于噪声范围或测试失败时，就应当回退，而不是把“可能有帮助”留在代码里。该版本的 release note 明确提到，这一步还会留下简短记录，避免同一个已被否定的优化反复出现。

这是一种很适合 AI 编程的分工。模型可以提出假设、定位候选位置、编写改动；是否保留改动，则由可重复的测量和测试决定。

为什么这周重新被推上 Trending

热度不是只靠 Addy Osmani 的名字。Osmani 的 GitHub 资料显示他曾在 Google 负责 Gemini 和 Google Cloud 相关工作，主页有 5 万以上关注者；这确实会让项目更容易被看见。但仓库本身也在持续把“工作流能否真的被执行”当作工程问题处理。

8 月 4 日的 v0.6.6 修复了 Claude Code 插件中四个 persona 没有被加载的问题，并继续完成跨语言的工作流表述；紧接着，维护者发现多个 Skill 中 references/ 的相对路径在单 Skill 安装后会失效。8 月 7 日的提交不只改掉了链接，还新增了专门的 CI 验证器来阻止同类问题回来。提交说明 把这个回归的范围写得很清楚：18 个链接在修复前都无法解析，修复后由 7 个单元测试保护。

这类更新不会像新模型那样制造演示效果，却很贴近 Agent Skills 的真实难点。一个 Skill 包只要安装后找不到它引用的材料，或者插件发现规则失效，写得再漂亮也不会进入用户实际工作的那一步。

同时，GitHub Trending 当天的 670 stars 是一个明确的短期动量信号。它表示的是 GitHub 当天榜单显示的增量，不是累计 stars，也不等于 skills.sh 的安装量。两种指标衡量的对象不同，不能混用。

对 Codex 用户，最有价值的是“按需加载”

项目支持把整个仓库作为 Codex plugin 安装，也支持通过 npx skills add 安装完整包或单个 Skill。前者适合团队想让流程统一，后者适合先验证一个高频环节，例如代码评审、测试驱动开发或性能优化。

真正值得借鉴的部分不在安装命令，而在选择范围。不要一开始就让 Agent 同时背上 24 个工作流。可以先挑一个最近反复失手的环节：

• 如果需求经常边写边变，先试 spec-driven-development
• 如果改动常常缺测试，先试 test-driven-development
• 如果评审意见太泛，先试 code-review-and-quality
• 如果性能优化总靠直觉，先试 performance-optimization

然后看它有没有改变实际结果：需求返工是否减少，测试是否覆盖了真正的失败路径，性能是否用相同口径重新测过。没有这些证据，Skill 就只是另一层文本。

安装前也有一个需要特别核实的限制。README 说明，通过 npx 单独安装某个 Skill 时，仓库根目录共享的 references/ 文件并不会随之复制；因此该 Skill 的主体仍可运行，但补充清单路径可能不可用。维护者已经记录了这个可移植性问题，使用单 Skill 安装时最好先检查它是否依赖共享资料。

agent-skills 这轮上涨给了一个很具体的信号：AI 编程的竞争点，正在从“谁能一次生成更多代码”移到“谁能让每一次改动经过更少猜测、更多验证”。对日常项目而言，先把一两个验证点变成默认流程，通常比再加一大段通用提示词更有用。

---

• 仓库：addyosmani/agent-skills