霍格沃兹测试开发学社
好的 description 长什么样？包含触发短语：把用户可能说的话写进去定义使用场景：说明什么时候该用、什么时候不该用包含关键词：让 AI 在语义匹配时能命中差的 description 只有一句话“帮助做 API 测试”。AI 根本不知道什么时候该调它。可选的扩展字段还包括 allowed-tools（声明需要的工具权限）、references（声明最重要的参考文档）等。3.2 Markdown 正文：让 AI 知道怎么执行frontmatter 之后是 Markdown 正文。这是 Skill 的“操作手册”。正文写什么？核心就三件事：目标与边界：这个 Skill 做什么、不做什么执行步骤：具体的操作流程，可以是线性步骤、决策树或循环迭代输入输出规范：需要什么数据、产出什么结果正文应该尽量精炼。不是把所有能写的都写进去，而是只写 AI 必须知道的执行逻辑。更长的参考资料放在 references/ 目录下，按需加载。3.3 渐进式披露：三层加载模型这是 Skill 设计最核心的机制。这个设计解决了什么问题？上下文不膨胀：即使你有几十个 Skill，初始也只加载元数据，不占上下文加载更精准：只加载当前任务相关的 Skill 内容支持海量信息：Skill 可以包含大量脚本和文档，但只在需要时加载很多人把几百行内容全塞进 SKILL.md 正文，破坏了渐进式披露的设计意图。正确的做法是：正文只写核心执行逻辑，细节放 references，脚本放 scripts。四、拆解仓库结构：scripts、references、assets 各司其职一个标准的 Skill 仓库长这样：my-skill/├── SKILL.md # 必需：元数据 + 核心指令├── scripts/ # 可选：可执行脚本├── references/ # 可选：参考文档、规范、知识材料└── assets/ # 可选：模板、图片、资源文件每个目录有明确的职责。
发布于 北京
1
评论
赞
未登录
友善发言
评论
加载中
