如何写好 Skill：一份终极实战经验手册

如何写好 Skill：一份终极实战经验手册 如何写好 Skill：一份终极实战经验手册 Modified June 8 Code block Plain Text Copy 1. 确认 Skill 已加载 → 路径对不对、格式有没有错 ↓ 2. 确认触发正确 → Description 是否匹配用户意图 ↓ 3. 确认指令清晰 → 逐步检查 AI 输出与预期的偏差点 ↓ 4. 确认脚本可执行 → 权限、依赖、路径、平台兼容性 ↓ 5. 加检查点缩小范围 → 在关键步骤之间插入验证命令 ↓ 6. 对比测试定位问题 → 有 Skill vs 无 Skill，看差异出在哪 💡 经验之谈 ：大多数问题（估计 70% 以上）出在前两步——要么 Skill 没加载成功，要么 Description 写得不够好导致没触发。先查这两个，能省很多时间。 十一、Skill 的生命周期管理 11.1 版本控制 每个 Skill 在元数据里标好版本号： Code block Plain Text Copy metadata: author: TeamName version: "2.1" 什么时候升版本号？看改动大小： 11.2 跨项目复用 做好的 Skill 如果其他项目也能用，就同步到用户级目录，这样所有项目都能享受： Code block Plain Text Copy 将项目级 Skill 同步到用户空间 cp rf ./project/.codebuddy/skills/my skill /.codebuddy/skills/ 或通过包管理器安装社区 Skill（以 Claude Code 为例） npx openskills install anthropics/skills 11.3 团队协作与分享 Skill 是团队知识资产，协作管理很重要： • 像代码一样 Review ：新 Skill 或重大修改通过 PR 提交，团队成员 Review 后合入 • 维护变更日志 ：在 Skill 目录下维护一个简单的 CHANGELOG，记录每次变更的原因和内容 • 避免冲突 ：多人编写同一个 Skill 时，按功能模块分工，各写各的子 Skill，最后在主 Skill 中编排 • 定期清理 ：不再使用的 Skill 及时归档或删除，避免 Level 1 的 Token 浪费 11.4 持续迭代优化 Skill 不是写完就不管了。用的过程中肯定会发现问题，定期打磨一下，作为资产持续维护： • 记下来哪里出过问题 ：AI 跑 Skill 的时候犯了什么错、偏了什么方向 • 找找规律 ：同一类错误反复出现？那就是 Skill 写得不够清楚 • 从个案中提炼通用规则 ：别头痛医头脚痛医脚，找到根因再改 • 精简内容 ：一句话说清楚的，就别写三句，保持 SKILL.md 精练 几条实用的改进思路 ： 1. 从具体反馈中总结规律 ——别只修一个 case，要想想同类问题怎么一劳永逸 2. 越精简越好 ——多余的说明不但浪费 Token，还可能误导 AI 3. 解释原因 ——让 AI 理解"为什么"，而非死记"怎么做" 4. 发现重复操作就封装 ——测试的时候如果每次都要做同样的准备工作，直接写进 Skill 十二、别踩这些坑——常见反模式 在审查过大量 Skill 之后，我们总结了最常见的几种"写了但不好使"的模式。对照看看自己有没有中招。 反模式 1：大杂烩 Skill 表现 ：一个 Skill 里塞了三四件不相关的事情——既做代码审查，又管项目初始化，还顺带处理部署配置。 问题 ：AI 不知道该用哪部分，经常张冠李戴；SKILL.md 超过 1000 行，Token 成本飙升。 正确做法 ：一个 Skill 只管一件事。如果有关联，拆成主 Skill + 子 Skill（见第四章）。 反模式 2：Description 写成内部黑话 表现 ： Code block Plain Text Copy ❌ description: 处理 TCC 的 v3 迁移，适配 QCMS 的新规范 AI 完全不知道 TCC、QCMS 是什么，自然无法正确匹配。 正确做法 ：用通用语言描述功能，辅以具体的技术关键词： Code block Plain Text Copy ✅ description: 将项目中的旧版事务补偿组件迁移到 v3 版本。 适用于 Go 项目中使用了 TCC（Try Confirm Cancel）模式， 需要对接新版内容管理系统 API 的场景。 反模式 3：只有指令，没有示例 表现 ：SKILL.md 里全是"做这个、做那个"的文字描述，一个代码示例都没有。 问题 ：AI 理解文字描述的能力不如理解具体代码示例。没有 Few Shot，输出格式和细节全靠猜。 正确做法 ：每个关键操作至少配一个 Before/After 示例（见 3.4 节和 3.5 节）。 反模式 4：步骤之间没有验证点 表现 ：列了 5 个步骤，一口气做完才检查结果。中间某步出了问题，后面全白干。 问题 ：错误被放大，排查困难，AI 也不知道自己哪步跑偏了。 正确做法 ：关键步骤之间插入检查点命令： Code block Plain Text Copy Step 2: 替换 import 路径 ...（具体操作） 检查点 ：确认替换完毕 反模式 5：写死具体数值而非提供判断规则 表现 ： Code block Plain Text Copy ❌ 超时时间设置为 30 秒。缓冲区大小设为 4096。 问题 ：换个项目、换个场景，这些数值就不对了。AI 只会死搬硬套。 正确做法 ：给出判断规则和参考范围： Code block Plain Text Copy ✅ 超时时间根据下游服务的 P99 响应时间设定，一般为 P99 2， 最小不低于 5 秒，最大不超过 60 秒。 通过以下命令查看下游 P99： 反模式 6：SKILL.md 当 Wiki 写 表现 ：大段的背景介绍、历史沿革、架构演进……写了 300 行还没进入正题。 问题 ：AI 的注意力是有限的。前面的"噪音"越多，后面真正重要的指令被遵循的概率就越低。 正确做法 ：背景信息放到 references/ 目录，SKILL.md 只保留"做什么"和"怎么做"。需要 AI 了解背景时，在步骤中显式引用： Code block Plain Text Copy 背景 详见 架构演进说明。 操作步骤 （直接进入正题） 反模式速查表 反模式 一句话症状 解法指引 大杂烩 Skill 一个 Skill 干三件事 拆分（第四章） Description 黑话 全是内部术语 用通用语言 + 技术关键词（3.1 节） 没有示例 纯文字描述 加 Few Shot（3.4、3.5 节） 没有验证点 做完才检查 关键步骤加检查点（9.1 节） 写死数值 硬编码配置 给判断规则和参考范围 当 Wiki 写 背景 300 行正文 50 行 背景放 references/（5.2 节） 十三、总结：写好 Skill 的核心检查清单 写的内容对不对 • 目标明确 ：做什么、为什么做、什么时候触发 • Description 精准 ：AI 能不能在合适的时候自动匹配到 • 语气直接吗 ：是不是在直接下指令，而不是绕弯子 • 讲了为什么吗 ：不只是说"必须这样做"，还解释了原因 • 例子够不够 ：有没有 3 5 个 Before/After 对比或者示例 • 场景考虑全了吗 ：多种情况都覆盖到了，有决策树或分支处理 • 坑标出来了吗 ：容易犯的错误和注意事项是否标注了 • 能验证吗 ：有验证清单和能跑的检查命令 结构合不合理 • YAML 元数据完整 ：name 和 description 都填了，description 足够详细 • 篇幅合理 ：SKILL.md 正文控制在 500 行以内 • 模块化拆分 ：超过 500 行的要拆成主 Skill + 子 Skill • 依赖明确 ：清楚声明前置条件和相关 Skill • 可视化表达 ：善用表格、ASCII 流程图组织信息 工程结构合不合理 • 版本控制 ：版本号合理，改了什么有迹可循 • 可独立使用 ：拆出来的子 Skill 脱离主流程也能跑 • 持续迭代 ：定期根据反馈优化 • 评估验证 ：通过测试用例验证了效果 • 团队协作 ：通过 PR Review 合入，维护变更日志 安全过关了吗 • 无硬编码密钥 ：文件中没有 API Key、密码、Token 等敏感信息 • 危险操作有确认 ：删除、覆盖、DDL 等操作有确认机制或备份步骤 • 输入有校验 ：脚本中的用户输入做了验证，不会被注入 • 路径安全 ：文件路径操作没有使用未经验证的变量拼接 • 网络请求安全 ：使用 HTTPS，并设置了合理的超时 可维护性够好吗 • 避免了常见反模式 ：对照" 常见反模式 "逐条检查 • 脚本跨平台兼容 ：在 macOS / Linux 上都能正常运行 • 关键步骤有检查点 ：不是一口气跑完才验证，中间有自检 十四、附录 附录 A：核心术语速查 术语 含义 首次出现章节 Level 1/2/3 Skill 的三层渐进式加载机制：元数据 → 正文 → 脚本资源 1.3 Few Shot 在 Skill 中提供多个输入/输出示例，让 AI 模仿学习 3.5 Before/After 改动前后的代码对比，让 AI 清楚知道"改什么"和"改成什么" 3.4 常见反模式 💡 经验之谈 ：大多数问题（估计 70% 以上）出在前两步——要么 Skill 没加载成功，要么 Description 写得不够好导致没触发。先查这两个，能省很多时间。 十一、Skill 的生命周期管理 11.1 版本控制 每个 Skill 在元数据里标好版本号： 什么时候升版本号？看改动大小： 11.2 跨项目复用 做好的 Skill 如果其他项目也能用，就同步到用户级目录，这样所有项目都能享受： 11.3 团队协作与分享 Skill 是团队知识资产，协作管理很重要： • 像代码一样 Review ：新 Skill 或重大修改通过 PR 提交，团队成员 Review 后合入 • 维护变更日志 ：在 Skill 目录下维护一个简单的 CHANGELOG，记录每次变更的原因和内容 • 避免冲突 ：多人编写同一个 Skill 时，按功能模块分工，各写各的子 Skill，最后在主 Skill 中编排 • 定期清理 ：不再使用的 Skill 及时归档或删除，避免 Level 1 的 Token 浪费 11.4 持续迭代优化 Skill 不是写完就不管了。用的过程中肯定会发现问题，定期打磨一下，作为资产持续维护： • 记下来哪里出过问题 ：AI 跑 Skill 的时候犯了什么错、偏了什么方向 • 找找规律 ：同一类错误反复出现？那就是 Skill 写得不够清楚 • 从个案中提炼通用规则 ：别头痛医头脚痛医脚，找到根因再改 • 精简内容 ：一句话说清楚的，就别写三句，保持 SKILL.md 精练 几条实用的改进思路 ： 1. 从具体反馈中总结规律 ——别只修一个 case，要想想同类问题怎么一劳永逸 2. 越精简越好 ——多余的说明不但浪费 Token，还可能误导 AI 3. 解释原因 ——让 AI 理解"为什么"，而非死记"怎么做" 4. 发现重复操作就封装 ——测试的时候如果每次都要做同样的准备工作，直接写进 Skill 十二、别踩这些坑——常见反模式 在审查过大量 Skill 之后，我们总结了最常见的几种"写了但不好使"的模式。对照看看自己有没有中招。 反模式 1：大杂烩 Skill 表现 ：一个 Skill 里塞了三四件不相关的事情——既做代码审查，又管项目初始化，还顺带处理部署配置。 问题 ：AI 不知道该用哪部分，经常张冠李戴；SKILL.md 超过 1000 行，Token 成本飙升。 正确做法 ：一个 Skill 只管一件事。如果有关联，拆成主 Skill + 子 Skill（见第四章）。 反模式 2：Description 写成内部黑话 表现 ： AI 完全不知道 TCC、QCMS 是什么，自然无法正确匹配。 正确做法 ：用通用语言描述功能，辅以具体的技术关键词： 反模式 3：只有指令，没有示例 表现 ：SKILL.md 里全是"做这个、做那个"的文字描述，一个代码示例都没有。 问题 ：AI 理解文字描述的能力不如理解具体代码示例。没有 Few Shot，输出格式和细节全靠猜。 正确做法 ：每个关键操作至少配一个 Before/After 示例（见 3.4 节和 3.5 节）。 反模式 4：步骤之间没有验证点 表现 ：列了 5 个步骤，一口气做完才检查结果。中间某步出了问题，后面全白干。 问题 ：错误被放大，排查困难，AI 也不知道自己哪步跑偏了。 正确做法 ：关键步骤之间插入检查点命令： bash grep rn "old http client" . include=" .go" | wc l 预期输出：0 反模式 5：写死具体数值而非提供判断规则 表现 ： 问题 ：换个项目、换个场景，这些数值就不对了。AI 只会死搬硬套。 正确做法 ：给出判断规则和参考范围： bash curl s https://monitor.example.com/api/p99?service=xxx 反模式 6：SKILL.md 当 Wiki 写 表现 ：大段的背景介绍、历史沿革、架构演进……写了 300 行还没进入正题。 问题 ：AI 的注意力是有限的。前面的"噪音"越多，后面真正重要的指令被遵循的概率就越低。 正确做法 ：背景信息放到 references/ 目录，SKILL.md 只保留"做什么"和"怎么做"。需要 AI 了解背景时，在步骤中显式引用： 反模式速查表 反模式 一句话症状 解法指引 大杂烩 Skill 一个 Skill 干三件事 拆分（第四章） Description 黑话 全是内部术语 用通用语言 + 技术关键词（3.1 节） 没有示例 纯文字描述 加 Few Shot（3.4、3.5 节） 没有验证点 做完才检查 关键步骤加检查点（9.1 节） 写死数值 硬编码配置 给判断规则和参考范围 当 Wiki 写 背景 300 行正文 50 行 背景放 references/（5.2 节） 反模式 反模式 一句话症状 一句话症状 解法指引 解法指引 大杂烩 Skill 大杂烩 Skill 一个 Skill 干三件事 一个 Skill 干三件事 拆分（第四章） 拆分（第四章） Description 黑话 Description 黑话 全是内部术语 全是内部术语 用通用语言 + 技术关键词（3.1 节） 用通用语言 + 技术关键词（3.1 节） 没有示例 没有示例 纯文字描述 纯文字描述 加 Few Shot（3.4、3.5 节） 加 Few Shot（3.4、3.5 节） 没有验证点 没有验证点 做完才检查 做完才检查 关键步骤加检查点（9.1 节） 关键步骤加检查点（9.1 节） 写死数值 写死数值 硬编码配置 硬编码配置 给判断规则和参考范围 给判断规则和参考范围 当 Wiki 写 当 Wiki 写 背景 300 行正文 50 行 背景 300 行正文 50 行 背景放 references/（5.2 节） 背景放 references/（5.2 节） 十三、总结：写好 Skill 的核心检查清单 写的内容对不对 • 目标明确 ：做什么、为什么做、什么时候触发 • Description 精准 ：AI 能不能在合适的时候自动匹配到 • 语气直接吗 ：是不是在直接下指令，而不是绕弯子 • 讲了为什么吗 ：不只是说"必须这样做"，还解释了原因 • 例子够不够 ：有没有 3 5 个 Before/After 对比或者示例 • 场景考虑全了吗 ：多种情况都覆盖到了，有决策树或分支处理 • 坑标出来了吗 ：容易犯的错误和注意事项是否标注了 • 能验证吗 ：有验证清单和能跑的检查命令 结构合不合理 • YAML 元数据完整 ：name 和 description 都填了，description 足够详细 • 篇幅合理 ：SKILL.md 正文控制在 500 行以内 • 模块化拆分 ：超过 500 行的要拆成主 Skill + 子 Skill • 依赖明确 ：清楚声明前置条件和相关 Skill • 可视化表达 ：善用表格、ASCII 流程图组织信息 工程结构合不合理 • 版本控制 ：版本号合理，改了什么有迹可循 • 可独立使用 ：拆出来的子 Skill 脱离主流程也能跑 • 持续迭代 ：定期根据反馈优化 • 评估验证 ：通过测试用例验证了效果 • 团队协作 ：通过 PR Review 合入，维护变更日志 安全过关了吗 • 无硬编码密钥 ：文件中没有 API Key、密码、Token 等敏感信息 • 危险操作有确认 ：删除、覆盖、DDL 等操作有确认机制或备份步骤 • 输入有校验 ：脚本中的用户输入做了验证，不会被注入 • 路径安全 ：文件路径操作没有使用未经验证的变量拼接 • 网络请求安全 ：使用 HTTPS，并设置了合理的超时 可维护性够好吗 • 避免了常见反模式 ：对照" 常见反模式 "逐条检查 常见反模式 • 脚本跨平台兼容 ：在 macOS / Linux 上都能正常运行 • 关键步骤有检查点 ：不是一口气跑完才验证，中间有自检 十四、附录 附录 A：核心术语速查 术语 含义 首次出现章节 Level 1/2/3 Skill 的三层渐进式加载机制：元数据 → 正文 → 脚本资源 1.3 Few Shot 在 Skill 中提供多个输入/输出示例，让 AI 模仿学习 3.5 Before/After 改动前后的代码对比，让 AI 清楚知道"改什么"和"改成什么" 3.4 术语 术语 含义 含义 首次出现章节 首次出现章节 Level 1/2/3 Level 1/2/3 Skill 的三层渐进式加载机制：元数据 → 正文 → 脚本资源 Skill 的三层渐进式加载机制：元数据 → 正文 → 脚本资源 1.3 1.3 Few Shot Few Shot 在 Skill 中提供多个输入/输出示例，让 AI 模仿学习 在 Skill 中提供多个输入/输出示例，让 AI 模仿学习 3.5 3.5 Before/After Before/After 改动前后的代码对比，让 AI 清楚知道"改什么"和"改成什么" 改动前后的代码对比，让 AI 清楚知道"改什么"和"改成什么" 3.4 3.4 检查点（Checkpoint） 在关键步骤之间插入的验证命令，用于及时发现偏差 4.3、10.3 Description YAML 头信息中的描述字段，决定 Skill 何时被自动触发 3.1 MCP Model Context Protocol，专为 AI 设计的标准化工具协议 6.1 主 Skill / 子 Skill 模块化拆分后的编排层和执行层 4.2 反模式 常见的"写了但不好使"的模式，应当避免 十二 十五、参考资源 资源 说明 链接 Anthropic 官方 Skills 仓库 包含官方示例和 Skill Creator 元技能 github.com/anthropics/skills Skill Creator Anthropic 官方的"创建 Skill 的 Skill" skill creator/SKILL.md OpenSkills 生态 通用的 Skills 加载/管理工具 github.com/openskills MCP Server 列表 已有的 MCP Server 生态 github.com/modelcontextprotocol/servers OpenAI Tokenizer 在线 Token 计数工具 platform.openai.com/tokenizer github.com/anthropics/skills skill creator/SKILL.md github.com/openskills github.com/modelcontextprotocol/servers platform.openai.com/tokenizer 资源 资源 说明 说明 链接 链接 Anthropic 官方 Skills 仓库 Anthropic 官方 Skills 仓库 包含官方示例和 Skill Creator 元技能 包含官方示例和 Skill Creator 元技能 github.com/anthropics/skills github.com/anthropics/skills github.com/anthropics/skills github.com/anthropics/skills Skill Creator Skill Creator Anthropic 官方的"创建 Skill 的 Skill" Anthropic 官方的"创建 Skill 的 Skill" skill creator/SKILL.md skill creator/SKILL.md skill creator/SKILL.md skill creator/SKILL.md OpenSkills 生态 OpenSkills 生态 通用的 Skills 加载/管理工具 通用的 Skills 加载/管理工具 github.com/openskills github.com/openskills github.com/openskills github.com/openskills MCP Server 列表 MCP Server 列表 已有的 MCP Server 生态 已有的 MCP Server 生态 github.com/modelcontextprotocol/servers github.com/modelcontextprotocol/servers github.com/modelcontextprotocol/servers github.com/modelcontextprotocol/servers OpenAI Tokenizer OpenAI Tokenizer 在线 Token 计数工具 在线 Token 计数工具 platform.openai.com/tokenizer platform.openai.com/tokenizer platform.openai.com/tokenizer platform.openai.com/tokenizer 写 Skill 这件事，说到底就是把你脑子里"知道怎么做"的经验，变成 AI 也能"照着做"的格式。第一版肯定不完美，但没关系，用着用着就知道哪里需要改了。好的 Skill 都是在实际使用中一点点打磨出来的。 🔗 原文链接： https://mp.weixin.qq.com/s/SZv3pDXP... https://mp.weixin.qq.com/s/SZv3pDXP... 原创 腾讯程序员 腾讯程序员 腾讯技术工程2026年6月5日 17:36 广东 作者：jackjchou 这篇文章把我们写 Skill 踩过的坑、总结出的经验，再加上 Anthropic 官方的一些好做法，整理到了一起。希望能帮你少走弯路，把团队积累的知识真正"喂"给 AI，让它干活更靠谱。 本文示例以 Go 语言为主，兼顾 Python、Java 等语言，所有原则和技巧适用于任何编程语言。 阅读建议 文章比较长，不同背景的读者可以按需跳读： 你的情况 推荐阅读路径 从没写过 Skill，想快速上手 一 → 二（重点看 2.5 Quick Start）→ 三 → 八 写过但效果不好，想提升质量 三 → 五 → 十二（反模式）→ 十三（检查清单） 负责团队 Skill 规范和管理 四 → 七 → 十一 → 十二 想了解 MCP 和外部服务集成 六 Skill 跑不通，想排查问题 九 → 十 你的情况 你的情况 推荐阅读路径 推荐阅读路径 从没写过 Skill，想快速上手 从没写过 Skill，想快速上手 一 → 二（重点看 2.5 Quick Start）→ 三 → 八 一 → 二（重点看 2.5 Quick Start）→ 三 → 八 写过但效果不好，想提升质量 写过但效果不好，想提升质量 三 → 五 → 十二（反模式）→ 十三（检查清单） 三 → 五 → 十二（反模式）→ 十三（检查清单） 负责团队 Skill 规范和管理 负责团队 Skill 规范和管理 四 → 七 → 十一 → 十二 四 → 七 → 十一 → 十二 想了解 MCP 和外部服务集成 想了解 MCP 和外部服务集成 六 六 Skill 跑不通，想排查问题 Skill 跑不通，想排查问题 九 → 十 九 → 十 一、先搞清楚 Skill 是什么 1.1 Skill 到底是啥 说白了，Skill 就是给 AI 编程助手（Claude Code、CodeBuddy 等）"加装"的能力包。本质上，它是一种 结构化的 Prompt Engineering ——通过标准的文件格式，把分散在人脑中的领域知识、操作流程和最佳实践，转化为 AI 可理解、可执行的指令集。 物理上看，它就是一个文件夹，里面放一个 SKILL.md 文件，再加上一些可选的脚本和参考资料。核心就三样东西： • 指令（Instructions） ：告诉 AI 该怎么干活，按什么步骤来 • 上下文（Context） ：给 AI 补课，告诉它你的项目背景、团队规范这些它不可能凭空知道的东西 • 工具（Tools） ：一些辅助脚本、配置模板，AI 可以直接拿来用 打个比方：裸着的 AI 就像一个刚入职的新人，啥都得问；装了 Skill 之后，就像拿到了老员工整理的操作手册，照着就能干。 1.2 为什么要写 Skill 做过项目的人都有体会，以下这些问题经常遇到： 痛点 实际表现 Skill 怎么解决 知识太散 经验藏在 TAPD、Wiki、代码注释、甚至某个人的脑子里 全部整理进 Skill，将知识结构化封装为标准技能包 重复搬砖 同样的活反复干，每次都要手动来一遍 写成 Skill 让 AI 自动跑 做出来的东西不统一 张三做一个样，李四做另一个样 用 Skill 固定流程，谁来做都一个标准 新人上手慢 来个新人得教半天，对方还不一定记得住 Skill 本身就是最好的培训材料 人走知识也走 核心成员一离职，很多"部落知识"就没了 把经验沉淀进 Skill，知识完整留存 痛点 痛点 实际表现 实际表现 Skill 怎么解决 Skill 怎么解决 知识太散 知识太散 经验藏在 TAPD、Wiki、代码注释、甚至某个人的脑子里 经验藏在 TAPD、Wiki、代码注释、甚至某个人的脑子里 全部整理进 Skill，将知识结构化封装为标准技能包 全部整理进 Skill，将知识结构化封装为标准技能包 重复搬砖 重复搬砖 同样的活反复干，每次都要手动来一遍 同样的活反复干，每次都要手动来一遍 写成 Skill 让 AI 自动跑 写成 Skill 让 AI 自动跑 做出来的东西不统一 做出来的东西不统一 张三做一个样，李四做另一个样 张三做一个样，李四做另一个样 用 Skill 固定流程，谁来做都一个标准 用 Skill 固定流程，谁来做都一个标准 新人上手慢 新人上手慢 来个新人得教半天，对方还不一定记得住 来个新人得教半天，对方还不一定记得住 Skill 本身就是最好的培训材料 Skill 本身就是最好的培训材料 人走知识也走 人走知识也走 核心成员一离职，很多"部落知识"就没了 核心成员一离职，很多"部落知识"就没了 把经验沉淀进 Skill，知识完整留存 把经验沉淀进 Skill，知识完整留存 1.3 Skill 怎么运作的 ⚠️ 以下加载机制以 Claude Code 为参考。不同 AI 编程工具（CodeBuddy、Cursor 等）的 Skill 加载策略可能有差异，请以各平台官方文档为准。 Anthropic 设计了一个"渐进式加载"机制，分成三层： 各层的作用和约束 ： 层级 加载时机 内容要求 Token 成本参考 Level 1 常驻（每次对话都在） name + description，控制在 100 字以内 约 50 150 Token / 个 Skill Level 2 匹配触发时一次性加载 SKILL.md 正文，建议不超过 500 行 约 2,000 5,000 Token Level 3 执行中按需读取 脚本、参考文档、模板等 按实际引用大小计算 层级 层级 加载时机 加