Skills 正式成为工业级协议——Angular 官方下场，Vibe Coding 的下半场开始了

2026 年 6 月 26 日，谷歌 Angular 团队往 GitHub 上传了一个仓库。

这事本身没什么稀奇——大厂每天开源的项目多了去了。但这个仓库叫 angular/skills，它的出现把一件事彻底坐实了：智能体 Skills 不再是个别极客的提效玩具，而是被主流前端框架官方背书的工业级协议。

Vibe Coding 的下半场，从今天开始。

什么是 Skills？一份合约，不是建议

先把概念说清楚。

Skills 是 Anthropic 定义的一种结构化指令文件，按需加载，告诉 AI Agent 在特定任务里该怎么做、用什么约定、跑什么验证。简单说，Skills 不是 prompt（建议书），而是 spec（合同书）。

Prompt 说"你最好用 @if 代替 *ngIf"。Agent 可能听，可能不听，可能这次听下次忘。

Skill 说"你必须用 @if，写完立刻跑 ng build，编译不过就重写。"

这是两种完全不同的东西。一个是建议，一个是契约。一个靠运气，一个靠仓库。

Angular 这套 Skill 自带自动验证环——Agent 生成代码后，强制跑 ng build，构建失败就得回去改。社区把这机制评价为"比纯 prompt 优越的关键点"。

这就像你给外包团队的不只是需求文档，还附带了一个会自动检查代码提交、不合格直接打回的 CI 流程。 只不过这次，接受这份合约的是 LLM。

Angular 为什么这时候下场？

时间点很微妙。

之前 Skills 是社区在玩。analogjs 的 angular-skills、alfredoperez 的 angular-best-practices，好几个包并存，各有各的约定，各有各的粉丝。这是典型的草莽阶段——谁嗓门大、谁更新勤快，Agent 就用谁的规矩。

现在 Angular 官方亲自下场了。装上官方 Skill，社区包会被要求主动 skills remove。游戏规则变了：官方仓库优先，社区包要么跟进标准，要么出局。

Angular 为什么选这时候？我的判断是两个字：v20。

Angular v20 是一次约定大更新。@if 取代 *ngIf，standalone: true 成为默认所以直接移除冗余声明，全面偏好 signals、linkedSignal、resource。这些不是"建议升级"，是框架的新基线。

问题来了——怎么让全球数百万开发者、以及越来越多的 AI 编码 Agent 都切换到新约定？

靠文档？文档永远有人不看。靠 Lint 规则？Lint 只能检查语法，管不了"用 signals 还是用老办法"这种架构选择。靠视频教程？更新速度追不上框架迭代。

官方的答案就是 Skills。把"在 Angular v20 下怎么正确写代码"这件事，从一份需要人类主动阅读的文档，变成一份 Agent 必须遵循的契约文件。开发者不需要学 v20 的所有变化，Agent 会替你遵守。

四层架构：Skills 的可工程化

同一天，QoderWork 技术团队公开了他们的 Skills 开发实践，提出了一个四层分离架构：

• 编排层（SKILL.md）：定义"做什么"
• 参数层（config.yaml）：定义"怎么配"
• 实现层（scripts/）：定义"怎么验证"
• 知识层（references/）：定义"参考什么"

这个架构的妙处在于，它让 Skill 从"一篇写给 AI 看的文章"变成了"一套可版本化、可 diff、可团队协作的工程文件"。

更关键的是，这套设计跨平台通用。QoderWork、Claude Code、Codex、Antigravity，同一个 Skill 包到处都能用。开发者不需要为不同 Agent 平台写不同的规则文件——协议统一了。

npx skills add <仓库地址> 一键安装，npx skills check 检查更新，npx skills remove 卸载。锁文件可以 diff，可以进版本管理。这套工具链已经成熟到可以直接进企业 CI 流水线。

Skills 正在变成前端工程化的新图层。 以前是文档层、Lint 层、模板层各管各的。现在这三层被打包进一份 Skill 文件，Agent 一口吃掉，自动遵守。

未标准化，但已成事实

这里得说一个关键缺口。

Angular 的 npx skills CLI 和 Vercel 的 react-best-practices 之间，有没有一个 RFC 级别的统一规范？没有。

现在的局面是社区自发达成的事实一致——各家 CLI 命令长得差不多，Skill 文件结构也趋同，但没有哪个标准组织出来说"这就是 Skills 协议 v1.0"。

这事有好有坏。好处是迭代快，Angular 今天想出自动验证环，明天就能上线，不用等委员会开三个月会。坏处是，万一哪天谷歌和 Anthropic 对 Skill 格式的定义出现分歧，生态可能会分裂。

但分裂的风险不大。Skills 的价值不在格式本身，而在"官方仓库 + 自动验证"这套组合拳。 格式可以调，机制才是核心。

Hacker News 上有人抬杠，说"你假装 LLM 会严格遵循规则，但实际上它并不完美"。社区回了一句很到位的话——不让完美成为足够好的敌人。

Skills 把"如何在某个框架下正确写代码"这件事从"靠运气"变成了"靠仓库"。Agent 不完美？它遵循 Skill 时犯的错，远少于靠 prompt 时犯的错。这就够了。

下半场：谁能把领域知识变成契约

Angular 这步棋，不只是为了 v20 迁移。

Google 在赌一件事：未来的 AI 编码 Agent 不是通用型 prompt 通吃天下，而是按需加载各领域的 Skill 包。 框架官方发布 Skill，就是在抢 Agent 的"默认行为定义权"。

一个 Angular 项目，Agent 不知道该用 @if 还是 *ngIf，这是 Angular 官方的失职。现在官方直接把标准答案塞进 Skill 里，Agent 不用猜，开发者不用教。

推而广之，这事绝不只是前端框架的玩法。数据库团队可以发布 SQL 编写 Skill，安全团队可以发布代码审计 Skill，运维团队可以发布部署配置 Skill。每个领域知识都能变成一份可被 LLM 严格遵循的契约文件。

Vibe Coding 的上半场，拼的是个人会不会写 prompt。下半场，拼的是团队能不能把自己的领域知识固化成 Skill 协议。

还在靠"口口相传"教新人写代码的、还在指望 AI 自动理解你们那套隐性规则的——现在该紧张了。

Angular 已经把车开上了这条路。下一个下场的是谁？React？Vue？Spring Boot？还是你们公司内部的框架团队？

协议不等人。你不把自己的规矩写成 Skill，别人的规矩就会成为你团队的默认行为。