09 · 各家怎么落地
这本书不绑定任何一家。但 Skill 这件事必须落到具体工具上，所以这一章给一张对照表：名字各不相同，形状是一样的。
这一章最容易过期
产品名、菜单位置、文件路径，随时会变。记形状，别记路径——具体位置以你所用工具的官方文档为准。
形状是什么
不管在哪家，一个 Skill 都由这三样组成：
- 一个标识（名字）
- 一段说明：这是干什么的 + 什么时候用它
- 一段正文：具体怎么做
区别只在于：这三样存在哪、由谁触发、能不能带附件。
对照表
| 形态 | 在哪儿 | 触发方式 | 能带附件吗 |
|---|---|---|---|
| 文件式 Skill | 一个文件夹，里面放一个说明文件（常见命名是 SKILL.md）；个人的放用户目录，项目的放项目目录 | AI 自己按说明匹配 | 能，还能带脚本 |
| 上传式 Skill | 网页版产品的设置里上传（通常打包成 zip） | AI 自己按说明匹配 | 通常能 |
| 自定义助手 / 智能体 | 产品里"创建智能体 / 应用 / GPTs"，把正文贴进说明框 | 你手动选中那个助手 | 通常能传知识文件 |
| 项目规则文件 | 项目根目录的一个约定文件名（各家不同） | 打开这个项目就自动生效 | 一般不能 |
| 企业内部平台 | 建一个"应用"，贴进配置 | 看平台设计 | 看平台 |
四种形态各自的取舍
文件式：最适合团队
优点：跟代码放一起，能提交、能 diff、能 review、能回滚。改了谁都看得见。附件和脚本支持最好。
缺点：得有个能读文件系统的工具（命令行或 IDE 里的那类）。纯网页用户用不了。
适合：产研团队、有代码仓库的场景、需要多人共用同一版的场景。
上传式：网页用户的对应物
优点：网页版就能用，不需要本地环境。
缺点：版本管理靠你自己。多数产品是每个人各传一份——同事那份和你这份很容易走散。
适合：个人高频使用；团队用的话，要额外约定一个"哪份是权威版本"的地方。
自定义助手 / 智能体：最容易上手
优点：几乎每家都有，界面化，五分钟能建一个。
缺点：通常要你手动选中它，而不是 AI 自动判断。这跟真正的 Skill 有本质区别——你得先想起来"这活该用那个助手"。
适合：第一次尝试；或者你本来就习惯"先选工具再干活"。
项目规则文件：作用域最清楚
优点：打开这个项目就生效，不用触发，不会漏。
缺点：它更像项目级的 System Prompt 而不是 Skill——每次都全量生效，不是按需加载。所以只该放"在这个项目里干什么都适用"的规矩，不能塞具体流程。
适合：项目约定、代码规范、术语表。
一个跨平台的现实问题
Skill 通常不跨平台同步
你在网页版传的 Skill，命令行工具里读不到；命令行里的文件式 Skill，网页版也看不见。同一个 Skill 想在几个地方用，多半要各放一份。
这不是谁的设计缺陷，是它们的存储位置本来就不同。
应对办法：把正文当成唯一的源。
在你的仓库或共享盘里存一份权威版本（就是那份 Markdown），需要用在哪个平台，就从这份复制过去。
改的时候改源，再同步。别在各个平台上分别改——那是走散的开始。
一份能到处用的正文
不管落到哪个平台，这份正文是通用的——你只是把它放到不同的地方：
# [Skill 名]
## 什么时候用
[什么情况下适用；什么情况下不适用]
## 流程
1. …
2. …
## 输出模板
[模子]
## 规则
- …
## 示例
[至少一组，含边界情况]
## 检查清单
- [ ] …上面这段贴进"自定义助手"的说明框，也贴进 SKILL.md 的正文，只是前者要在开头补一句"什么时候用我"，后者写进 description 字段。内容一模一样。
关于 Skill 的"标准"
目前最标准化的一种形式，是用一个文件夹 + 一个带 YAML 头的 SKILL.md：
---
name: meeting-notes
description: 做什么 + 什么时候用
---它的价值不在于哪家发明的，而在于它把"触发说明"和"正文"分开了，这才有了按需加载。其他形态或多或少都在往这个方向走。
所以：你按这个形状写正文，将来搬到哪儿都不亏。