7 WHO、WHAT、 HOW TO SKILL

1 背景

我们常说大模型的"记忆"是有限的，而且越长的记忆越昂贵。但你可能不知道，真正的瓶颈并非在于"填满"它。一旦上下文窗口的占用率超过60%到70%（以128K模型为例，即70K左右），模型的表现就会大打折扣，不仅变慢 、变贵 ，还容易出错（总想提前结束没有完成的任务！）。这不仅是资源问题，更是算法工程必须攻克的难关。

除此之外，在实际应用中，你是否也遇到过这种尴尬：用 Al 写周报，每次都要重复交代格式、结构、语气、禁忌⋯漏说一条，质量就掉一截本质问題：每次开新对话，都像重新培训一次实习生。

这种低效的重复令人抓狂。于是，SKILL诞生了。它的核心理念很简单：把这些零散的模块固定下来，打包成一个成熟的"技能单元"，让AI不再需要每次都重新"学习"基础指令。

2 Skill是什么人物

核心定义：从"指令"进化为"能力容器"

SKILL 绝非简单的提示词堆砌，而是 AI 工程化中的持久化、可加载、可组合的能力单元。它将非结构化的自然语言指令升级为标准化的执行模块。

SKILL就是你的一套组合拳，遇到相似的问题，大模型会直接"锤"，而不是你还要再次打磨。

SKILL = 结构化提示词＋参考资料＋脚本工具 ＋按需加载机制

打回"原形"就是一个文件夹，如下：

my-skill/
├── SKILL.md      # 必需：元数据（头） + body
├── scripts/      # 可选：可执行代码
├── references/   # 可选：文档资料，API文档、业务规则
└── assets/       # 可选：模板、logo、样板代码

---
name: developer-skill
description: 高级前端开发助手
---

## 🎯 目标
帮助用户快速生成符合公司规范的 React 代码。

## 前置条件
-。。
- 。。。
- 。。。

## 🛠️ 能力与工具 (Capabilities)
- **代码生成**: 使用 `assets/react-template.tsx` 作为基础模板。
- **图片优化**: 当检测到图片过大，调用 `scripts/optimize.js`。

## 📚 知识库 (Knowledge Base)
- **UI 规范**: 颜色、字体请严格参考 `references/design-system.md`。
- **API 定义**: 后端接口定义见 `references/api-docs/` 目录。

## ⚙️ 运行规则
1. 每次生成代码前，先检查 `references/linting-rules.md`。
2. 不要臆造 API 字段，必须查阅 `references/` 下的文档。

容易踩的坑：

1. references、assets、scripts 里的文件必须在SKkILL.md 中被引用，否则 AI 根本不知道有这个东西存在；

1. reterences 是给 Al 读的（用来理解怎么做），assets 是给 Al 用的（会出现在最终输出里），别放反了；

SKILL.md 是导航图 ，它负责指路；assets、references 和 scripts 是目的地，只有当 AI 真正走到那里时，才需要加载里面的具体内容。

2.1 按需加载机制-渐进式披露-懒惰加载-动态加载

按需加载的好处：省钱、避免上下文污染（无关信息不要）避免目标偏移；

插一句，如果你了解小深或者维护新表，为什么需要大家维护表的基础描述信息我们就是在做渐进式加载。skill2025年10月16日正式推出为大家熟知，但是小深在去年6月份就已经有了，所以实现方式不同但是思想是相同的。

怎么动态加载呢？

1. 第一层（启动时）：元数据 → Agent 知道"我会Web测试"

1. 第二层（需求匹配时）：读取完整 SKILL.md → 决策树判断路径（静态HTML? 动态服务?）

1. 第三层（执行时）：按需加载 scripts/ + examples/ → 确定性执行

2.2 怎么使用别人的 Skill

• 获取：社区仓库（AnthropicSkills Repo）→ 上万个现成 Skill（https://github.com/anthropics/skills/tree/main/skills）

不同的工具可能有不一样的使用方法，多数是放在skills目录下的。

公开 Skill 最大的价值不是直接拿来用而是学习别人的写法，再结含自己的业务改造一真正好用的 Skill，一定是你自己从实战中磨出来的。

2.3 怎么创建自己的 Skill

2.3.1 从模仿开始（最快上手路径)

1. 模仿：找官方仓库中类似需求的 Skill（如 github.com/anthropics/skills）

1. 复制 + 改名/描述/逻辑 → 放入 ~/.claude/skills/

1. 跑一遍，看效果，不行就调。

2.3.2 从自己的 SOP 出发

1. 第一步：梳理你的 SOP；

1. 第二步：写最简版本的 SKILL.md

1. 第三步：根据实际表现逐步补充；（反复迭代验证！）

写好 Skill 的关键原则：

1. 写好元数据

1. 一个Skill 只做一件事

1. SKILL.md 控制在200行以内；

1. 区分开放任务和确定性任务；

1. 写Al 不知道的东西，而不是它已经知道的；

2.3 SKILL 设计方向

编号	设计方向（类型）	解决的核心问题	核心思路	关键实践要点（数据分析师可落地）	案例
01	知识注入型 （Tool Wrapper）	AI 通用知识不够精准，缺乏领域专业性（如：不知道"销售新客"的业务定义）	将"只有你知道的"专业经验打包为 references/ 文件，AI 按标准自动加载执行	• 在 references/ 中存放： - 业务规则文档（如 sales_rules.md） - 术语表 / 口径说明 • SKILL.md 中显式 load: references/xxx.md • 适用于：写分析结论、演讲稿、合规报告等需强业务约束的场景	--- name: writing-speech description： 技团队风格写演讲稿。当用户要求写演讲稿、分享精、路 演稿时敿活。 --- AI 的通用如识不路精准，需要注入"只有你知道的" 专业知识 把你的专业经驗打包成 reterences 文件，Al 在需要时自动加裁，按你的标 淮菜做事 ＞你是演讲稱助手。写内容前先加裁 references/top-speeches.md. 学习 这些高质量演讲的结构和表达方式。 #＃ 我们团队的演讲规范 （AI 不知道的部分） ＞一风格是"真人表达"，不是"官方童读"，避免生硬和书面化表达 一开场必须用问題或真实场景切入，不能直接讲主題 一每段控制在2-4句话，避免长段雄硼 - 优先使用短句，允许口语连接词（比如"其实"但问题是"） 一 每个核心观点必须配一个具体例子或经历 一结尾需要有一句可以让人记住的话（类似金句） #＃ 输出结构要求 1.开场（场景/ 提问/ 共鸣） 2. 背景铺望（为什么要讲这个） 3. 核心内容（分点讲，每点有例子） 4. 总结升华（一句话收束）
02	模板生成型 （Generator）	AI 输出格式不一致、结构飘忽（如：日报有时3段，有时5段；漏掉"阻塞项"）	在 assets/ 中预置结构化模板，AI 仅填充内容，不自由发挥	• 模板文件存于 assets/template-report.md • 明确字段占位符（如 {``{date}}, {``{metric_change}}） • 要求：每段≤4句、必须含数据、禁用模糊词（"可能""大概"） • 适用于：日报、周报、AB测试总结等标准化输出
03	审查打分型 （Reviewer）	AI 直接输出结果，但质量不可控（如：归因错误、忽略关键异常）	让 AI 先当"审查员"：按清单逐项检查 → 分类严重性 → 输出结构化报告	• 检查清单放入 references/checklist-sales.md • SKILL.md 定义流程： 加载清单 → 逐项检查 → 按严重度分类 → 输出报告 • 适用于：模型结果复核、报表质检、合规审计等高风险环节
04	反向采访型 （Inversion）	AI 在信息不足时盲目执行，导致结果偏离目标（如：没问清"环比 vs 同比"，直接算错）	翻转交互：AI 先提问澄清，确认无误后再行动	• 在 SKILL.md 中定义"必问问题清单" • 示例流程： 用户说"分析Q3增长" → AI 问：<br> 1. 对比基准是Q2还是去年Q3？<br> 2. 是否剔除大促影响？<br> 3. 关键指标是GMV还是订单量？ • 适用于：需求模糊、多口径业务场景（如财务、运营分析）
05	流水线型 （Pipeline）	任务复杂、步骤多，AI 易跳步或遗漏关键环节（如：清洗→建模→验证→可视化，漏掉验证）	将任务拆解为严格阶段，每步有明确输入/输出/检查点，上一步未通过则禁止进入下一步	• 在 SKILL.md 中定义阶段流： 1. 数据加载 → 2. 异常值检测 → 3. 特征工程 → 4. 模型拟合 → 5. 结果验证 • 每阶段后加 assert: ... 检查（如 count > 0） • 适用于：完整分析项目（如用户分群、预测建模、归因分析）

2.4 如何系统打磨

Skill 不是"写一次就完事"的提示词，而是一个微型软件模块 ------需要像开发产品一样：定义问题 → 设计测试 → 构建最小可行版本 → 持续迭代

2.4.1 建基线，发现问题

1. 写： 根据背景设计自己的SOP，然后先让AI帮我们优化，当然也有针对写SKILL的SKILL。

1. 测试： 明确 AI 在哪些环节不稳定？

• 同样输入 → 结果时好时坏？（随机性）

• 输入微调 → 输出歧义/偏移？（理解偏差）

• 是否在不该主动时"自作聪明"？（越界行为）

  • 关键动作：记录3~5次失败案例，标注"哪里错了 + 为什么错"

2.4.2 反复优化打磨

根据第一步识别的问題，设计 3-5个具体的用例。

• 每个用例有明强的"通过"和"失败标准

• 优先覆盖 Al 最客易犯错的场景

把跑基线时发现的误触发场景写进去，作为第一道防线（禁止如何。。。）

• 用最少的步票描述核心流程，确保最基本的蝓入能得到稳定的输出；

• 一个Skill 只解决一个明确的问题；

3 SKILL的适用性

AI 负责：模糊推理、语言生成、意图理解、知识联想；

代码负责：条件判断、循环、状态管理、错误恢复、数据校验；

1. 警惕过度膨胀。 如果你的SKILL超过了200行（根据模型能力调整）并且包含3条以上的禁止指令的时候（束缚大模型自由发挥），说明你的SKILL已经承载了过重的工程逻辑，必须向代码迁移。

1. **确定性逻辑交给代码。**如果是确定性的逻辑（if ... else...）,使用代码控制，而不是AI；

1. **大模型不可靠，关键路径需兜底。**大模型是不可靠的，因此很多需要代码去处理，来负责状态的传递，路由的选择和异常处理。

最后，SKILL应该是大模型能力的一个轻量化补丁，而不是一个复杂的工作流编排系统。最有价值的还是使用脚本做主干控制，让大模型做他最擅长的语义处理。

我看过这么一个例子，大模型是一匹难以驯服的野马，为了更好的驾驭我们给它套上缰绳（skill、memory、tools and so on）,拿起你的小皮鞭驾驭它吧！让它更好的与你对话。

附件：

【2】AnthropicSkills Repo（上万个现成 Skill）（https://github.com/anthropics/skills/tree/main/skills）