Skills 是什么，为什么重要
从面试表达角度回答 Skills 在 AI 工程化中的定位，以及它如何把个人经验沉淀为团队资产。
[!info] related notes
Skills
Skills 可以理解成把高频任务的最佳实践、约束规则和工具链封装成可复用能力模块。它的价值在于把个人 prompt 经验升级成团队级可复用资产，提高输出一致性和使用门槛可控性。
关键特性：
- 渐进式披露
- 稳定工作流
Matt Pocock 的 mattpocock/skills 是一个很典型的工程化样本：它不是追求“更会写 prompt”，而是把需求澄清、TDD、debug、issue 拆分、架构 review、git 护栏等真实工程习惯封装成一组小 skill。
andrej-karpathy-skills 则代表另一类 skill 仓库：它不追求多流程覆盖，而是用一个高度压缩的 karpathy-guidelines skill 给所有编码任务加统一行为纪律。
Skills 到底是什么
最贴切的理解是：
Skill = 一组可复用的 instructions + optional files/code
它不是单纯一段 prompt，也不是单纯一个脚本仓库。
更像是“给另一个 ChatGPT 准备的操作手册 + 工具箱”。
适合做这些事：
- 把重复任务固化下来，比如周报、报告、数据分析
- 把团队规范固化下来，比如格式、语气、审校规则
- 把多步流程固化下来，比如“先查资料，再跑脚本，再按模板输出”
而且用户可以在 /skills 看到自己的 Skill 库，也可以直接在对话里说“帮我创建一个 skill”。这是 skill-creator 规范里明确写的。
一个 Skill 里通常有什么
标准结构大概是这样：
skill-name/
├── SKILL.md
├── agents/
│ └── openai.yaml
├── scripts/
├── references/
└── assets/1) SKILL.md
这是核心入口，必须有。
它分两部分：
- YAML frontmatter
namedescription
- Markdown instructions
- 具体告诉 ChatGPT 这个 Skill 该怎么做事
这里最重要的一点是：
Skill 最像“prompt”的东西，其实就是 SKILL.md。
所以如果你问“skills 里有 prompt 吗”，答案是：
有 prompt-like instructions，但主要不是单独叫 prompt.txt，而是写在 SKILL.md 里。
其中：
description决定 什么时候触发这个 Skill- 正文 instructions 决定 触发后怎么做
2) references/
这就是你说的 docs。
里面适合放：
- schema 文档
- API 说明
- 规则说明
- 团队规范
- 大段背景知识
- 示例输出格式
它的作用不是直接给用户看，而是当 Skill 被用到某一步时，ChatGPT 再按需读这些资料。
所以：
docs 在 Skills 里通常就是 references/。
而且官方建议不要把大块知识都塞进 SKILL.md，而是把 SKILL.md 当“控制面”，把大文档放进 references/，需要时再加载。
3) scripts/
这就是你说的 scripts。
适合放：
- Python 脚本
- Bash 脚本
- 一些确定性转换逻辑
- 容易反复写错的步骤
比如：
- 旋转 PDF
- 解析 CSV
- 批量改文件
- 固定格式的数据清洗
- 生成某种固定产物
一个很好记的原则是：
只要某一步“靠自然语言临场发挥不稳定”，就适合下沉成 script。
反过来，如果只是总结文本、改写文案、抽取要点，这类通常不需要脚本，直接让 ChatGPT 做就行。
4) assets/
这个不是 docs，也不是 scripts，而是输出要用到的素材。
例如：
- logo
- 模板文件
- 样式文件
- 示例表格
- 图片
- boilerplate 代码
它更偏“生产资料”，不是给模型拿来推理的主文档。
5) agents/openai.yaml
这是界面和元数据相关的配置。
比如：
- 显示名
- 简短描述
- 图标
- UI 元信息
它不是工作逻辑本身，但属于一个完整 Skill 的配套部分。
那么 Skills 里到底有没有 “prompt”
有，但要分两种理解。
第一种：广义的 prompt
如果你说的是“给模型的说明文字”，那当然有，而且核心就是 SKILL.md。
第二种：像 MCP 里那种正式的 Prompt 资源
Skills 本身不以“Prompts”作为核心协议对象来组织。
这是 MCP 世界里更明确的一种资源类型。
所以不要把：
- Skill 的 instructions
- MCP 的 prompts
- 普通 prompt engineering
这三件事混为一谈。
更准确地说：
- Skill 里有 prompt-like instructions
- Skill 也可以包含模板化示例
- 但 Skill 的主结构是
SKILL.md + references + scripts + assets
Skills 最关键的一个机制：渐进式加载
这是你前面已经摸到的重点。
Skill 不是一上来把全部内容都塞进上下文。
它是分层加载的：
第一层：metadata
先看 name 和 description
作用是判断：
- 这个 Skill 该不该触发
- 什么时候触发
第二层：SKILL.md
一旦选中了这个 Skill，才会读它的核心说明。
第三层：支持资源
比如：
references/scripts/assets/
这些一般是按需读取/执行，不是一开始全加载。
所以 Skills 的设计重点之一就是：
让大部分知识和资源在需要时才进入上下文。
这也是为什么官方建议：
SKILL.md保持精炼- 把大块知识放到 references
- 把脆弱步骤做成 scripts
Skill 和 prompt 工程的区别
你可以这样区分：
普通 prompt
一次性的对话说明。
Skill
可复用、可打包、可逐步加载的工作流资产。
也就是说，Skill 比 prompt 多了这几层：
- 结构化目录
- 元数据触发
- 外挂 docs
- 外挂 scripts
- 外挂 assets
- 可打包复用
所以它更像“工程化 prompt”。
Skill 最适合承载什么
最适合的是：
1. 固定流程
比如：
- 分析上传的访谈记录
- 输出标准产品洞察
- 生成固定格式周报
2. 领域知识 + 输出规范
比如：
- 某个团队自己的文案风格
- 某种固定法律/财务输出格式
- 某种产品分析框架
3. 需要辅助脚本的任务
比如：
- PDF 操作
- 文件批处理
- 数据转换
- 产出固定格式文档
Skill 不太适合承载什么
不太适合的是：
- 纯粹一个很小的工具接口
- 单个 API action
- 单个数据库查询函数
这种更像：
- function calling
- MCP tool
- connector
Skill 更偏“怎么做这类事”，而不是“某个单点能力本身”。
你可以把它记成一句话
Skill = Prompt 入口 + Docs 参考 + Scripts 执行 + Assets 素材。
但这四样东西里：
- Prompt 主体 在
SKILL.md - Docs 通常在
references/ - Scripts 在
scripts/ - Assets 在
assets/
一个最小例子
比如做一个 “customer-update” Skill：
customer-update/
├── SKILL.md
├── agents/openai.yaml
├── references/
│ ├── update-template.md
│ └── tone-guide.md
├── scripts/
│ └── normalize_notes.py
└── assets/
└── report_template.docx这里：
SKILL.md：定义什么时候用这个 Skill，流程怎么走references/update-template.md：输出格式模板references/tone-guide.md：措辞规范scripts/normalize_notes.py：把原始输入做标准化assets/report_template.docx：最终产物模板
这就是一个很完整的 Skill。
一个判断口诀
当你在想某段内容该放哪里时，可以这么分：
- “什么时候触发、怎么做” →
SKILL.md - “长说明、知识、规则、模板示例” →
references/ - “需要稳定执行的步骤” →
scripts/ - “最终输出要用的文件/素材” →
assets/