王释易Vibe Coding这个词最近在技术圈已经被说烂了，但真正把它落到实处的人其实不多。往简单了说，Vibe Coding就是靠自然语言驱动AI生成代码，开发者从"逐行手写代码"变成"定义意图、审查结果、调整方向"，像开车一样，你把握的是方向盘和整体氛围，发动机怎么转是AI的事。但等你真上手几天就会发现，问题不在"AI听不懂人话"，而在你每天都在用不同的措辞重复交代同一批背景信息，"你是一个资深Python后端工程师""请遵守我们团队的命名规范""不要用第三方库，用标准库重写"——这些话说一遍两遍还行，十遍二十遍就纯属浪费生命。
skills.sh和find-skills就是冲着这个痛点来的。简单说，前者是一个管理AI"技能包"的CLI工具，负责把那些高频复用的提示词、代码规范、架构约束整理成可加载、可版本管理、可共享的Skill文件；后者是一个技能检索工具，帮你在社区和官方仓库里快速找到现成的技能包，装完即用。这篇文章我按自己的真实使用路径来写，从概念讲清楚，到安装初始化，到手写第一个Skill，最后聊团队协作和排坑，希望能帮你少走我踩过的那些弯路。
1. Vibe Coding 到底是什么：从"手写代码"到"驾驶氛围"
1.1 这波热度是怎么来的
Vibe Coding这个词能火，背后其实是AI编程能力的质变。早几年让AI写代码，它只能补全一个函数、生成一段样板，你仍然需要逐行校对逻辑。而现在的主流AI编程工具，已经能在一次对话里理解一个完整的需求文档，然后生成十几个文件、几十个函数，甚至能自己判断该用哪个设计模式。这时候问题不再是"AI会不会写代码"，而是"你能不能把需求描述得让AI一次写对"。
圈内人对Vibe Coding有个很形象的说法：你不再是握着笔写字的人，而是握着方向盘带路的人。你要做的是告诉AI目的地在哪里、中途走哪条高速、避开哪些堵点，然后握着方向盘，随时准备纠偏。一个需求进去，AI咣咣给你生成一整个服务端框架，你只需要看关键决策点有没有跑偏，然后让它迭代修改。这种开发方式在个人项目、内部工具、原型验证这些场景里，效率提升非常夸张。
1.2 Vibe Coding 不等于不用写代码
很多人一听Vibe Coding就以为程序员要失业了，我自己用下来反而觉得，它不会写代码的人根本玩不转。说穿了，你得懂得判断AI交付的代码质量，才能做出有效纠偏。你得能看出它用的ORM方案在数据量上来之后会炸，得能发现它处理并发的方式有竞态条件，得能在它生成的300行代码里精准指出"这里逻辑不对，换成策略模式重写"。
所以我的理解是，Vibe Coding本质上把程序员的工作重心从"生产代码"上移到了"定义标准和验收结果"上。以前你写代码，每一行都是你亲手敲的，质量下限由你的水平决定；现在你用AI写代码，每一行都是它生成的，质量下限由你的"验收标准"决定。这就是技能包存在的意义——把你脑子里的标准、团队的规范、项目的约束，变成AI能稳定读取和执行的输入，而不是靠临场发挥的prompt。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么需要 skills.sh 与 find-skills
2.1 先解决一个痛点：AI 的"会话失忆"
跟AI协作时间一长你就会发现，它最大的毛病是记性太差。每次开一个新会话，它都像第一天入职的实习生，什么都要你从头交代。你上周告诉过它"项目里时间统一用UTC存储、展示时再转本地时间"，这周换了会话它又老老实实给你写了一大堆datetime.now()。
我自己有一段时间是在每次写需求前，先复制粘贴一大段"项目背景说明"，大概几百字，里面有技术栈、目录结构、命名规范、禁止事项。这个方法有用，但很蠢：一来浪费tokens，二来不同人复制粘贴的版本不一致，团队协作时质量忽高忽低，三来这段背景本身也需要维护，代码重构了它却没人更新。
这就引出了核心需求：能不能把AI需要知道的"背景知识"和"行为准则"永久固化下来，像配置文件一样挂在项目里，每次会话自动加载？这就是Skill机制想解决的事。
2.2 skills.sh 与 find-skills 到底做了什么
skills.sh本质上就是一个面向"AI技能包"的生命周期管理工具。你在项目里初始化之后，它会生成一个标准的技能目录结构，每个技能就是一个带元信息的Markdown文档，里面写清楚：这个技能在什么场景下生效、需要AI遵守哪些规则、提供哪些代码示例。CLI负责帮你安装、卸载、列举、切换、发布这些技能。
find-skills则是配套的发现渠道，功能上像"技能版的npm search"。你输入关键词，它会去检索社区贡献的技能包仓库，返回名称、描述、适用标签、Star数、最近更新时间，然后你可以一键装回本地。
我最开始也不理解为什么要把这么简单的事做成一个工具，直到我在两个项目里分别维护了三套不同的上下文说明，有一天下班前发现自己已经记不清哪套是最新的了。后来我把所有规范沉淀成Skill包，用git管理，每个技能一个版本号，谁改了代码规范、谁补充了部署约束，全部有迹可循。这时我才意识到，技能管理真正解决的其实是一个"工程化"问题——让AI的上下文不再是散落在每个人聊天框里的临时信息，而是像代码一样可管理、可跟踪、可协作。
2.3 跟 Cursor Rules、Claude Skills 的区别
之前也有不少人在项目里写RULES.md、Cursor Rules、Claude Skills这类东西，那skills.sh跟它们到底有什么区别？我的理解是这样的：
| 方案 | 生效范围 | 管理方式 | 适合场景 |
|---|---|---|---|
| Cursor Rules | 仅限Cursor编辑器 | 项目目录放文件，手动维护 | 单人使用、轻量约束 |
| Claude Skills | Claude系工具 | 按官方格式编写，依赖特定工具解析 | Claude生态内 |
| skills.sh + find-skills | 跨工具、可迁移 | CLI管理版本、支持发布与拉取 | 团队协作、多模型混用 |
Cursor Rules我试过，简单粗暴，但它的格式和解析逻辑跟Cursor绑定死了，一旦团队里有人用别的工具，就没办法共享。skills.sh走了另一条路——它核心定义的是"技能包"的目录结构和Markdown格式，然后用CLI做管理，至于最终哪个AI工具去读取这个技能包，可以由各工具自己的适配层去处理。所以同一个技能包，今天放在Claude Code里用，明天放到别的支持自定义指令的工具里，只要格式兼容，几乎零迁移成本。
3. 完整上手指南：安装、初始化、找到第一个技能
3.1 环境准备
我目前的工作环境是macOS + Node.js，用的AI编程工具是Claude Code为主、Cursor作为辅助，这套流程在Linux和Windows的WSL环境下也跑过，没遇到什么障碍。动手之前建议先确认三件事：
- 本机安装了Node.js 18以上版本。skills.sh的CLI是Node写的，用
node -v可以查看版本。 - 安装了git，并且已经配置好
user.name和user.email，因为技能包的发布和同步默认走git仓库。 - 你手上至少有一个支持自定义指令或技能加载的AI编程工具。如果你目前只是用网页版ChatGPT，那技能包能发挥的作用有限，建议先装一个本地编程工具再继续。
确认完环境，就可以开始装了。
3.2 安装 skills.sh 与 find-skills
官方给的安装方式有两种，一个是npm全局安装，一个是curl脚本安装。先说我推荐的方式，npm全局安装：
bash复制npm install -g skills-cli find-skills
装完跑一下版本号验证：
bash复制skills --version
find-skills --version
如果看到版本号输出，就说明CLI已经正常上车了。npm这套方式的优点是后续升级方便，npm update -g skills-cli一条命令搞定，缺点是如果本机Node版本偏老，可能遇到依赖安装失败。遇到的话优先升级Node，不要硬装。
不想用npm的话，也可以用官方脚本：
bash复制curl -fsSL https://skills.sh/install | bash
但用脚本安装我个人不太推荐用在公司电脑上，因为脚本来源没法像npm包那样做完整审计。安全第一，我在公司项目里一律走npm。
3.3 初始化项目
现在找一个真实项目或者新建一个空目录做测试。我这边新建了一个临时目录来演示：
bash复制mkdir demo-workspace
cd demo-workspace
skills init
初始化完成后，用tree看一下目录结构：
text复制demo-workspace/
├── .skills/
│ ├── skills.json
│ └── registry.lock
└── skills/
└── README.md
解释一下目录里这几个文件的作用：
.skills/skills.json是本地技能注册表，记录当前项目安装过哪些技能、各自版本是多少，类似package.json。.skills/registry.lock是锁定文件，保证团队同步时大家安装的技能版本一致，类似锁文件的定位，不细看内容也没关系。skills/目录用来放项目自定义的技能文件，后面我们手写的Skill就放在这里。
如果你的项目本身已经用git管理，初始化后记得把skills/目录提交上去，这样团队成员拉代码时能一起拉到技能定义；.skills/这个目录建议加入.gitignore，因为它是本地状态，每个人的内容会略有不同。
3.4 find-skills 找一个"能直接用"的技能
初始化完成，重头戏来了：用find-skills去社区里找一个现成的技能包。
第一次用的时候，可以先跑一下不带参数的全量热榜：
bash复制find-skills --hot
它会返回当前社区里安装量靠前的一批技能，内容包括技能名、一句话描述、标签、Star数和最近更新时间。我这边第一次搜的时候看到的技能五花八门，有React组件规范、Python FastAPI模板、数据库索引设计建议、Git提交信息规范之类的，找一个跟你当前项目技术栈相关的先试试。
比如我想找个Python后端的代码规范包：
bash复制find-skills "python backend best practice" --tag python --sort stars
--tag按标签过滤，--sort stars按Star数排序。输出大概长这样：
text复制python-backend-best-practice ⭐ 328 updated 2d ago
Python后端工程的代码规范、模块划分、异常处理与测试建议
fastapi-project-template ⭐ 214 updated 1w ago
基于FastAPI的项目结构模板与分层规范
python-clean-code ⭐ 89 updated 3w ago
Clean Code在Python工程中的落地建议
锁定目标后，直接用管道命令安装：
bash复制skills use python-backend-best-practice
安装完看一下本地列表：
bash复制skills list
Installed Skills in demo-workspace:
python-backend-best-practice v1.2.0 enabled
到这里，一个技能包就已经进入你的项目了。它会出现在skills/目录下，被你的AI工具按需加载。我一开始用的时候以为装完就完事了，后来才知道缺了一步：你要告诉你的AI工具"参照skills/目录下的技能来干活"。不同工具配置方式不一样，有的在配置文件里声明，有的在启动时指定。拿Claude Code举例，我会在项目启动时明确告诉它"加载本地技能包"，然后在对话里问一句"这个项目有哪些技能可用"，看它能不能准确说出技能内容，能说出来就说明生效了。
这一步看起来简单，但很多人卡在这里。后面第4章我会专门讲怎么验证技能真正生效。
4. 手写第一个 Skill：把团队规范装进 AI 脑子里
4.1 Skill 文件的核心结构
现成的技能包可能不完全贴合你所在团队的规范，更常见的情况是团队有自己的一套约定，网上根本搜不到。这时候就得自己写Skill。别担心，写一个Skill本质上就是写一份给AI看的、结构化的Markdown文档，没有任何编程门槛。
先创建骨架：
bash复制skills new python-team-rule
命令会在skills/下生成一个同名目录，里面有一个主文件SKILL.md。打开这个文件，模板长这样：
markdown复制---
name: python-team-rule
description: 用于生成符合团队规范的后端 Python 代码
tags: [python, backend, fastapi]
version: 0.1.0
author: your-name
---
# 团队 Python 后端开发规范
## 适用场景
(在这里写这个技能在什么情况下应该被AI自动调用)
## 必须遵守
(在这里写AI生成代码时必须遵守的硬性规则)
## 推荐做法
(在这里写推荐但不强制的实践)
## 示例
(在这里放一段符合规范的代码示例)
每个部分都不长，但作用巨大。我逐个说。
name是技能的唯一标识，全小写加中划线，后面安装、更新、卸载都靠它定位。description是我觉得最重要的字段，因为AI工具会读取它来决定"什么时候激活这个技能"。如果你的描述写"Python代码规范"，那AI只有在识别到Python任务时才可能加载；如果写"适用于FastAPI项目的所有后端开发场景，包括API设计、数据模型、Service层划分"，那它被触发的机会就大得多。tags用于检索过滤，version建议遵循语义化版本，改动小修version的小位，结构性变更升大位。
再往下是正文。正文才是AI真正依赖的行为准则，这里有个关键点：AI不会像人一样把全文逐字读完，它更倾向于根据任务的上下文"重点检索"相关内容。所以你写的规范必须结构清晰、用词准确、宁可多举例也不要只写抽象原则。比如"代码要清晰易懂"这种描述AI没法执行，你要写清楚"函数命名必须包含动词（如getUserById），禁止使用data1、temp这类无意义命名"。
4.2 实战示例：Python 后端代码风格包
下面我拿自己的团队规范举个例子，你可以照着改。这份Skill我实际用在FastAPI后端项目里，核心解决的是两个问题：AI生成代码风格漂移，以及不同成员让AI写出来的代码风格不统一。
markdown复制---
name: python-team-rule
description: 适用于 FastAPI 项目的 Python 后端开发规范，覆盖模块划分、数据库会话处理、异常处理、日志规范
tags: [python, fastapi, backend, sqlalchemy]
version: 0.2.0
author: dev-team
---
# Python 后端开发规范
## 适用场景
- 生成新的 Python 后端代码或修改现有后端代码时
- 涉及 FastAPI 路由、SQLAlchemy 模型、Service 层
- 涉及异常处理、日志、数据库会话管理
## 必须遵守
1. 时间字段一律使用 UTC 存储，输出时由前端负责本地化。
2. 所有数据库查询必须走 Service 层，禁止在 Controller 中直接操作 session。
3. 除 get 外的方法必须校验权限，权限校验统一使用 `require_permission` 装饰器。
4. 禁止使用 `print` 输出日志，统一使用 `logging` 模块，日志必须包含 request_id 字段。
5. 新增第三方依赖必须先在技术评审中讨论，禁止直接安装随意版本。
## 推荐做法
- 路由函数保持薄，逻辑尽量下沉到 Service。
- SQLAlchemy 查询尽量使用 select() 写法，避免字符串拼接。
- 类型注解必须完整，接口函数禁止使用裸 `dict` 作为返回类型。
## 示例
参考仓库 `backend/service/order_service.py` 中的类设计与分层方式。
这份文档写完后，AI在生成FastAPI相关代码时就会自觉避开常见的时序和权限坑。注意最后一条我并没有把完整代码贴进去，而是指明了参考仓库里的一个文件。原因很实际：技能文件里塞太多代码会占用大量上下文窗口，而指向仓库内已有文件，既省tokens又让AI"按图索骥"，效果更好。
4.3 怎么确认 Skill 真的生效了
很多人在这一步卡住：写好了技能包，AI却像没看见一样。我建议按下面的顺序排查。
先在对话里直接问AI："当前项目加载了哪些技能？"如果它答不上来，说明技能压根不在它的"视野"里。再问它一个跟技能内容强相关的问题，比如"获取订单详情时，要不要做权限校验？"如果回答里出现了你技能中规定的装饰器用法，那就说明技能生效了。如果AI回答得含糊，可能的原因有两个：一是它加载了技能但没有被触发，二是触发规则跟你的description写得不匹配。
第二个问题最常见。AI工具触发技能的机制通常是根据对话上下文来做语义匹配，它匹配的主要依据就是description字段。如果你写的描述过于狭窄，比如"仅用于订单模块代码生成"，那如果你问"怎么给用户列表加分页"，它可能觉得跟订单模块无关，就不加载了。我的经验是：描述写宽一点，覆盖场景写全一点，宁可过度匹配也不要匹配不上。
4.4 发布与团队共享
个人能用的技能只是第一步，团队协作才是重头戏。skills.sh通过skills publish把技能发布到远程仓库，或者推送到团队私有的Git仓库里，成员用skills use拉取，跟npm包的发布与安装逻辑完全一致。
推荐的做法是用skills package校验格式、用skills push推送到团队远程仓库，然后在团队的代码规范文档里写清楚：每个新项目初始化后第一件事就是安装团队标准技能包。版本管理靠version字段。如果后端框架升级导致规范变革，就升一个大版本，成员在skills list里能看到本地版本和远程版本不一致，提醒他们更新。
这里有一个坑：很多人会把技能包直接提交进业务代码库，结果业务代码重构时技能包也跟着被误删。我个人的做法是给技能包单独建一个仓库，业务仓库通过skills use引用它，实现解耦。本质上，技能包维护者和业务开发者的职责是不同的，混在一起迟早出问题。
5. 团队协作里怎么玩 Vibe Coding
5.1 从"个人手感"到"团队水位"
Vibe Coding一个人的时候靠手感，两个人的时候靠默契，一旦成队，就必须靠标准。为什么？因为同一句需求，不同的人会描述成不同的样子，AI产出的质量自然参差。有人擅长拆需求，能给出详细步骤，AI一次就把框架写对了；有人就一句"帮我写个登录接口"，AI只能自己猜，生成的代码跟团队规范完全是两码事。
技能包就是来解决这个水位差的。团队把所有"AI应该知道的事情"固化到标准技能包里，不同成员AI产出的基线水平就被拉齐了。核心需求、技术约束、代码规范这些信息通过技能包一次性注入，每个人的起点都是"熟悉团队规范的工程师"，而不是"需要从头教的新人"。
5.2 建议的协作流程
我自己团队跑顺的流程大致是这样：
第一步，由技术负责人维护一套核心技能包，涵盖代码规范、项目结构、基础架构约束，标签覆盖团队所有主流技术栈。
第二步，每个业务域维护自己的业务技能包，比如订单域、支付域、用户域各一个，里面写的是这个域特有的业务规则、模型设计约定、调用关系。核心技能包和业务技能包分层管理，避免一个大包里什么都有、改起来还容易互相影响。
第三步，每个迭代开始时，用需求模板描述要开发的功能，模板里明确要求必须包含：用户故事、验收标准、涉及模块、约束条件。开发者将需求输入AI的同时，确保技能包已加载，然后让AI产出实现方案和代码。
第四步，Code Review时不仅要审查AI生成的代码，也要审查技能包本身。团队成员发现AI产出的代码有某类共性问题，应该去技能包里找根因，是因为约束没写明，还是触发规则不对。把问题反馈给技能包维护者，让下一次全队人受益。
这套流程跑起来之后，效果是逐步累积的。第一个月大家还在抱怨"每次都要提醒AI"，第二个月技能包完善了，很多人描述完需求，AI自动就能带出符合团队规范的代码，Review基本只需要看业务逻辑是否符合预期，而不需要逐行纠风格问题。
6. 常见问题与排查技巧实录
6.1 技能加载不生效
这类问题占到我实际遇到问题的一半以上。最终的排查顺序：先确认技能确实安装在正确目录里（skills list能显示）、再确认SKILL.md文件名和大小写正确、再确认front matter里的name和description字段存在且格式正确、最后确认AI工具的加载配置指向了skills/目录。
有个细节我踩过坑：YAML front matter要求字段顶格写，前面一个空格都不能有。有次我复制模板时，name行前多了一个空格，解析器静默跳过了整个文件，技能列表里看不到，AI也完全不理会。
其次是编号问题。正文里的"必须遵守"如果写成"注意事项123"这种没有编号的格式，AI执行的优先级感知会变弱。用明确编号和置顶表述，AI会更倾向于遵守。
6.2 find-skills 搜索不到或下载失败
搜索不到结果先看是不是关键词太偏。比如搜"电商秒杀系统高并发库存扣减方案"这种长尾词，基本搜不到东西，换成"python high concurrency"或者直接搜技术栈关键词会更可行。另一个常见原因是tag过滤太严格，我建议先不加--tag搜一轮全量，再根据结果缩小范围。
下载失败一般是网络问题或者版本冲突。网络代理问题我不展开，但在公司内网环境下，建议配置registry镜像或直接走git仓库安装。版本冲突则是有同名技能已经装过了，skills list看下版本号，用skills update或者强制重装解决。
6.3 团队同步时冲突
多人一起维护技能包，git merge冲突很容易出现，尤其是description和tags字段。这个问题没有特别好的根治办法，我的实践是：技能包仓库禁止直接merge到主分支，所有改动必须提PR过评审。评审人重点看技能变更是否会影响AI的触发行为。如果两个成员改了同一个技能的description，再merge时必出幺蛾子，这时候逐字读一下两边意图然后合并即可。
6.4 同一个技能在不同工具下表现不一致
我自己在Claude Code、Cursor等多个工具之间切换，同一份技能包在不同工具上生效程度确实不同。原因主要有两个：一是不同AI模型对长指令的遵循能力有差异，二是不同工具的技能触发机制不同。
这种情况下我建议把"必须遵守"条款写得足够强硬，多加"禁止"和"必须"，减少模糊表述。另外，如果某个工具对技能的触发不符合预期，可以在每次会话启动时手动指明"注意加载skills目录下的技能包"，把工具自动触发失败的兜底做在前面。
最后分享一个我个人的小习惯：技能包不是一次写好就完事，要把它当成代码来维护。每个迭代结束后，我会让团队里所有人都反馈一个"AI这次最让我不满意的地方"，攒够三个共性问题就更新一次技能包，版本号加一个小位。一个月下来，AI在团队项目里的表现会明显上一个台阶，那种"每次都要重新教一遍"的疲惫感也能明显降低。工具只是载体，真正让Vibe Coding跑起来的是你把经验沉淀成标准、把标准注入到AI上下文里的那个闭环。