鹅厂 Skill 写作完整 Playbook：14 章节 end-to-end 实战 + 工程化评估（腾讯一线踩坑 + Anthropic 官方做法整合） — OpenMAIC 课堂版¶

Ch07.062 鹅厂 Skill 写作完整 Playbook：14 章节 end-to-end 实战 + 工程化评估（腾讯一线踩坑 + Anthropic 官方做法整合） — OpenMAIC 课堂版¶

📊 Level ⭐⭐⭐ | 84.5KB | entities/tencent-skill-writing-complete-playbook-jackjchou/classroom.md

鹅厂 Skill 写作完整 Playbook：14 章节 end-to-end 实战 + 工程化评估（腾讯一线踩坑 + Anthropic 官方做法整合）¶

来源：OpenMAIC 批量生成 · · dir=l-dOUpM1XL_tencent-skill-writing-complete-playbook-jackjchou · 场景数=14 播放地址：/classroom/l-dOUpM1XL 媒体根目录：/Users/jinguo/PycharmProjects/OpenMAIC/data/classrooms

Scene 1: 为什么同样的 Skill 需求，效果能差 10 倍？¶

• type: slide
• id: scene_oU5sb1eSu2

板书：

为什么同样的 Skill 需求，效果能差 10 倍？ 同一团队，两人写 “代码审查 Skill” 触发准确率 (Trigger Accuracy)： 95% vs 47% 差距不在模型能力，在写法Skill 写作是工程规范，不是写散文 本次课程脉络： 本质认知 → 结构拆解 → 写作提升 → 评估体系 → 排错与协作 来源：腾讯 jackjchou 14 章节 Playbook + Anthropic 官方指南整合

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s1_action_7wuR8qQE — 大家好，欢迎来到本次关于 AI Agent Skill 写作的课程。我们课程的第一问，就是这个：为什么同样的 Skill 需求，效果能差 10 倍？
• [▶️ 播放](../ch07-
• 路径：/Users/jinguo//audio/tts_s1_action_7wuR8qQE.mp3
• 🎙️ tts_s1_action_Cp9SnzGk — 来看一个真实的案例。同一个团队，两位工程师分别写了一个“代码审查 Skill”。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_Cp9SnzGk.mp3
• 🎙️ tts_s1_action_zANl2gFc — 我们用一个核心指标来衡量效果，就是这个：触发准确率 Trigger Accuracy。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_zANl2gFc.mp3
• 🎙️ tts_s1_action_Fv1DzcHd — 结果呢？一位做到了 95%，另一位只有 47%。差距接近一倍。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_Fv1DzcHd.mp3
• 🎙️ tts_s1_action_cyM-QNhq — 这揭示了关键的一点：差距不在底层的模型能力，而在写法。Skill 的写作，本质上是一种工程规范，而不是在写散文。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_cyM-QNhq.mp3
• 🎙️ tts_s1_action_f1rav9H0 — 那么，如何掌握这种工程规范呢？这次课程，我会带大家按照一个清晰的脉络来学习。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_f1rav9H0.mp3
• 🎙️ tts_s1_action_0jbcixfD — 我们会先建立本质认知，然后拆解结构，接着提升具体的写作技巧，学习如何评估效果，最后解决排错与团队协作的问题。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_0jbcixfD.mp3
• 🎙️ tts_s1_action_Vk8tTTRx — 整个课程内容整合自腾讯 jackjchou 的 14 章节 Playbook 和 Anthropic 的官方指南，都是实战经验的结晶。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_Vk8tTTRx.mp3
• 🎙️ tts_s1_action_JfH7xtFp — 好，那我们就从“本质认知”开始，一起探索 Skill 写作的底层逻辑。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s1_action_JfH7xtFp.mp3

Scene 2: Skill 到底是什么？5 大痛点与渐进式加载¶

• type: slide
• id: scene_pW5CxcbBKc

板书：

Skill 到底是什么？ 5 大痛点与渐进式加载 Skill 本质 • 领域知识 + 规则编码 + 工具编排的三合一• 可复用的模块化组件• 非简单 Prompt 模板 5 大痛点 1. 触发不精准2. 内容臃肿3. 写法混乱4. 难以复用5. 评估无标准 解决方案 渐进式加载：SKILL.md ≤ 5000 词，超出部分挪到 references/ 按需加载类比前端 lazy loading —— 用户没滚到的内容，先别渲染 擅长领域：按需求稿 / 固定方法论调研 / 团队规范写文档

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s2_action_VbD0sGjH — 大家好，欢迎来到这节课。今天我们要深入探讨一个在agent开发中至关重要的概念——Skill。首先，让我们聚焦这个核心问题：Skill到底是什么？以及相关的5大痛点与渐进式加载方案。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_VbD0sGjH.mp3
• 🎙️ tts_s2_action_kmgdaZiU — Skill的本质并不是简单的Prompt模板。它更深层的结构是领域知识、规则编码和工具编排的三合一。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_kmgdaZiU.mp3
• 🎙️ tts_s2_action_O5J0P0gF — 具体来说，Skill是一个可复用的模块化组件，能将特定领域的知识和规则编码进agent，使其具备执行复杂任务的能力。这区别于常见的Few-Shot示例或基础Prompt。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_O5J0P0gF.mp3
• 🎙️ tts_s2_action_G1gcc-N8 — 在实际开发中，构建Skill常遇到5大痛点。让我们逐一看看这些问题。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_G1gcc-N8.mp3
• 🎙️ tts_s2_action_jPaapWYa — 痛点包括：触发不精准、内容臃肿、写法混乱、难以复用，以及评估无标准。这些都会降低Skill的可靠性和维护成本。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_jPaapWYa.mp3
• 🎙️ tts_s2_action_wQP2nSkF — 针对这些痛点，一个有效的解决方案是渐进式加载。这借鉴了现代前端开发的思想。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_wQP2nSkF.mp3
• 🎙️ tts_s2_action_3B8Ccp5p — 具体做法是：SKILL.md文件应控制在5000词以内，超出部分挪到references/目录按需加载。这就像前端的lazy loading——用户没滚到的内容，先别渲染，避免初始加载过重。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_3B8Ccp5p.mp3
• 🎙️ tts_s2_action_3IuK8gXn — 最后，Skill擅长处理可重复的流程，比如按需求稿、固定方法论调研，或团队规范写文档。在这些场景中，Skill能显著提升效率和一致性。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s2_action_3IuK8gXn.mp3

Scene 3: SKILL.md 的解剖学¶

• type: slide
• id: scene_1N-yFNd7zX

板书：

SKILL.md 的解剖学 拆解一个生产级 Skill 的完整文件结构 1. SKILL.md 文件结构 • frontmatter（元数据）• body（指令正文） 2. 目录结构 • references/：按需文档• assets/：模板与示例 3. frontmatter 核心字段 name / description / triggers / tools / version 4. Skill Creator 一键生成骨架目录和模板文件

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s3_action_ht4KV7IZ — 上一节我们介绍了 Skill 的基础概念，现在让我们深入探讨 SKILL.md 文件的解剖学，拆解一个生产级 Skill 的完整文件结构，让你能一眼看懂每一层的含义。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s3_action_ht4KV7IZ.mp3
• 🎙️ tts_s3_action__ZaHxw6s — 首先，SKILL.md 文件的核心结构由两部分组成：frontmatter 是元数据部分，存储 Skill 的配置信息；body 是指令正文，定义了 Skill 的具体指令和流程。这是理解 Skill 行为的基础。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s3_action__ZaHxw6s.mp3
• 🎙️ tts_s3_action_8mq_Q3pR — 接下来是目录结构。在生产级 Skill 中，references/ 文件夹存放按需文档，比如 API 说明或上下文资料；assets/ 文件夹则包含模板文件和示例，方便开发时直接调用和参考。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s3_action_8mq_Q3pR.mp3
• 🎙️ tts_s3_action_oxixCxXJ — frontmatter 的核心字段至关重要，它们决定了 Skill 的行为和元信息。这里列出了五个关键字段：name 定义 Skill 名称，description 提供描述，triggers 指定触发条件，tools 列出可用工具，version 控制版本管理。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s3_action_oxixCxXJ.mp3
• 🎙️ tts_s3_action_v57H5gsZ — 最后，Skill Creator 工具极大简化了开发流程。它能一键生成骨架目录和模板文件，让你快速开始编写新的 Skill，无需手动搭建结构，提升开发效率。总结一下，SKILL.md 的解剖学涵盖了文件结构、目录组织和 frontmatter 字段，希望这些能帮助你们更好地理解和构建 Skill。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s3_action_v57H5gsZ.mp3

Scene 4: frontmatter 为什么决定触发成败的 80%？¶

• type: slide
• id: scene_8sfbj3MYwv

板书：

frontmatter 为什么决定触发成败的 80%？ 📍 官方定论：frontmatter 是 Skill 最重要的部分——没有之一。 核心 description 字段必须包含 四要素： ❌ 反例 (过于宽泛) "帮我写代码"触发条件模糊，导致泛滥触发 ✅ 正例 (触发精准) "当用户需要按团队规范生成 React 组件时触发"含 ESLint + Prettier 规则 原则：精确 > 宽泛，宁可漏触发，不要误触发 Skill 精讲

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s4_action_X4Z_nEhy — 我们直接看这个标题。为什么 frontmatter 这个看似配置文件的地方，会决定 Skill 触发成败的80%？这背后的原理，是优化 Skill 的关键。
• [▶️ 播放](../ch07-
• 路径：/Users/jinguo//audio/tts_s4_action_X4Z_nEhy.mp3
• 🎙️ tts_s4_action_47gyuJJY — 这不是我夸张，这是 Anthropic 官方给出的定论。他们明确指出，frontmatter 是 Skill 最重要的部分——没有之一。为什么？因为它定义了 Skill 的‘基因’，决定了它会在什么情况下被唤醒。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s4_action_47gyuJJY.mp3
• 🎙️ tts_s4_action_9AmEz2Hn — 而 frontmatter 的核心，在于 description 字段。它必须完整包含四个要素：角色、能力、触发条件、使用场景。这四个要素缺一不可，它们共同定义了一个 Skill 的‘身份’和‘使用说明书’。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s4_action_9AmEz2Hn.mp3
• 🎙️ tts_s4_action_O0g8gaxQ — 来看一个典型的反例。如果 description 只写‘帮我写代码’，触发条件就极其模糊。这就像只告诉门卫‘找个人’，任何跟编程沾边的请求都可能误触发这个 Skill，导致它被滥用，最终失效。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s4_action_O0g8gaxQ.mp3
• 🎙️ tts_s4_action_XpYMDZXH — 而正例就非常精准：‘当用户需要按团队规范生成 React 组件时触发，含 ESLint + Prettier 规则’。这里清晰地定义了能力（生成 React 组件）、触发条件（按团队规范生成）、以及使用的场景和约束（包含特定规则）。这样，只有精准匹配的请求才会激活它。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s4_action_XpYMDZXH.mp3
• 🎙️ tts_s4_action_0NZ1PcOn — 所以，这里诞生了一条设计原则：精确大于宽泛。我们宁可让 Skill 在边界情况不触发（漏触发），也绝不能让它因为描述模糊而被错误地频繁触发（误触发）。误触发会严重损害用户体验和对 Skill 的信任。记住这个原则，写好 description，你就掌握了优化 Skill 触发的八成胜算。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s4_action_0NZ1PcOn.mp3

Scene 5: 主体写作 5 大核心原则¶

• type: slide
• id: scene_iQZFWfhrMX

板书：

主体写作 5 大核心原则 ← 左列 · 基础思维框架 右列 · 实战执行技巧 → 1 开头写 WHY 告诉 Skill 任务的目的和意义 2 祈使句为主 '检查 X' 而非 '你可以检查 X' 3 Before/After 对比 让 Skill 明确什么是好、什么是坏 4 Few-Shot 示例 2-3 个典型输入输出对，降低歧义 5 Checkpoint 检查点 每步做完后验证，避免偏差累积 🧠 构建 Skill 的底层思维 🛠 让输出更稳定可控 每个原则都附带正反对比示例，详见后续幻灯片

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s5_action_3jVI6nbG — 各位好，欢迎来到本次Skill写作实战课。上节课我们搭建了Skill的骨架，今天我们要填充最核心的血肉——主体部分的写法。我总结并验证了5条核心原则，掌握了它们，你写的Skill就能从‘能用’跃升到‘好用且稳定’。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_3jVI6nbG.mp3
• 🎙️ tts_s5_action_iMOw1TF- — 我们来看幻灯片的结构。左边这一列，我们称之为‘基础思维框架’，是指导你写作时需要时刻牢记的底层逻辑。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_iMOw1TF-.mp3
• 🎙️ tts_s5_action_XUsHtlD8 — 而右边这一列，是‘实战执行技巧’，是具体落笔时可以直接套用的、非常明确的动作。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_XUsHtlD8.mp3
• 🎙️ tts_s5_action_09zNbpjz — 我们先看第一条原则：开头写WHY。这对应左边的思维框架。你必须在一开始就告诉模型，这个任务的目的和意义是什么，而不是直接甩给它一个指令。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_09zNbpjz.mp3
• 🎙️ tts_s5_action_n2aqY313 — 比如，‘你的任务是审查代码’和‘为了保障生产环境的安全稳定，你需要审查代码’，后者给了模型一个明确的上下文和价值导向，它的理解和执行会精准得多。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_n2aqY313.mp3
• 🎙️ tts_s5_action_7PhiIKyN — 第二条，祈使句为主。这是右边的实战技巧。指令要像给机器人下命令一样直接。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_7PhiIKyN.mp3
• 🎙️ tts_s5_action_d3TmtAh4 — 举个反例，‘你可以检查X参数’，这个‘可以’给模型留下了犹豫和选择的空间。正确的写法是‘检查X参数’，清晰、不含糊。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_d3TmtAh4.mp3
• 🎙️ tts_s5_action_djQGSPci — 第三条，Before/After对比。这是右边的关键技巧。与其用大段文字描述好坏，不如直接给模型看例子。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_djQGSPci.mp3
• 🎙️ tts_s5_action_Z_2bVh95 — 明确地告诉模型‘这是错误的输出（Before）’，‘这是理想的输出（After）’，它通过对比学习，远比看抽象描述要快得多。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_Z_2bVh95.mp3
• 🎙️ tts_s5_action_cp6h_Z-C — 第四条，Few-Shot示例。这是右边的黄金法则。对于复杂任务，提供2到3个典型的输入输出对。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_cp6h_Z-C.mp3
• 🎙️ tts_s5_action_h4mZkejm — 这几个例子能极大地降低歧义，为模型树立一个清晰的‘样板’。它比你写一百句描述都管用。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_h4mZkejm.mp3
• 🎙️ tts_s5_action_wCT1p5O- — 最后一条，也是保障稳定性的关键：Checkpoint检查点。这是左边的思维框架，要求你把任务分解。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_wCT1p5O-.mp3
• 🎙️ tts_s5_action_JX6CKVaZ — 不要指望模型一口气完成所有事。在每一步做完后，都设计一个验证环节，让它检查自己的输出是否符合预期。这样才能及时纠偏，避免错误滚雪球。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_JX6CKVaZ.mp3
• 🎙️ tts_s5_action_XPLQRZPy — 总结一下，左边这两条原则，‘开头写WHY’和‘Checkpoint检查点’，是构建Skill的底层思维，决定了你的设计是否合理。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_XPLQRZPy.mp3
• 🎙️ tts_s5_action_f9QWoLRS — 而右边这三条，‘祈使句’、‘Before/After’和‘Few-Shot’，是让输出更稳定可控的实战技巧，直接影响执行质量。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_f9QWoLRS.mp3
• 🎙️ tts_s5_action_oSrfGmX8 — 纸上得来终觉浅。接下来的幻灯片，我会针对每一个原则，都展示一个正反对比的具体示例，让大家有最直观的感受。现在，我们开始逐一拆解。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s5_action_oSrfGmX8.mp3

Scene 6: 模块化拆分——何时拆、怎么拆¶

• type: slide
• id: scene_wwpIssjJjc

板书：

模块化拆分——何时拆、怎么拆 何时拆？触发条件 • SKILL.md 超过 5000 词（文件过大，难以维护和调试）• 涵盖 2+ 独立场景（职责耦合，修改易引发回归问题） 怎么拆？架构原则 • 主 Skill (Orchestrator)路由调度，不含执行逻辑• 子 Skill (Specialist)聚焦单一职责，可独立测试• 依赖声明：includes 字段引用 反面教材：什么都塞一个文件的 “上帝 Skill” → 难以维护、难以测试、难以复用

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s6_action_LeIDEyn6 — 好，同学们，我们这节课来解决一个实际开发中的关键问题：如何将一个庞大的、难以维护的 Skill 进行模块化拆分。我们主要探讨两个核心问题：什么时候该拆，以及拆分后应该遵循什么样的架构。
• [▶️ 播放](../ch07-
• 路径：/Users/jinguo//audio/tts_s6_action_LeIDEyn6.mp3
• 🎙️ tts_s6_action_G6BrBAqN — 首先，我们来看‘何时拆’。第一个明确的触发条件是，当你的主 SKILL.md 文件超过 5000 词时，它就变得过于庞大了。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_G6BrBAqN.mp3
• 🎙️ tts_s6_action_hNGUoGeu — 另一个更重要的信号是，如果这个文件开始涵盖两个或两个以上完全独立的业务场景，比如同时处理‘客服对话’和‘代码审查’，职责就严重耦合了。这时，维护、测试和调试都会变得异常困难，就是该拆分的明确信号。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_hNGUoGeu.mp3
• 🎙️ tts_s6_action_w7Koz52u — 明确了何时拆之后，我们来重点讲讲‘怎么拆’。这里推荐一种经典的主子 Skill 架构。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_w7Koz52u.mp3
• 🎙️ tts_s6_action_3wKOb8lR — 拆分后，原来的巨型 Skill 会变成一个主 Skill，也叫 Orchestrator。它的职责非常纯粹：只负责路由和调度，根据用户输入把任务分发给正确的子 Skill，自身不包含任何具体的业务执行逻辑。而每个子 Skill，我们称之为 Specialist，则专注于一个单一、明确的职责，比如一个专门处理退款流程，另一个专门回答产品知识问答。这样，每个子 Skill 都可以被独立测试和复用。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_3wKOb8lR.mp3
• 🎙️ tts_s6_action_ZqBX8Rk3 — 我们一定要避免图中所示的反面教材，就是把所有逻辑都塞在一个文件里的‘上帝 Skill’。这种结构最终会变得难以维护、难以测试，也很难将其中的功能复用到其他项目中。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_ZqBX8Rk3.mp3
• 🎙️ tts_s6_action_-UkzzSxm — 最后补充一点，在实际的 frontmatter 配置中，主 Skill 会通过一个 includes 字段来声明它依赖哪些子 Skill，从而将它们组织起来。好，这就是模块化拆分的核心思路，我们接下来动手实践一下。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s6_action_-UkzzSxm.mp3

Scene 7: MCP 集成：从零散接口到稳定工作流¶

• type: slide
• id: scene_lmTc49GQ33

板书：

MCP 集成：从零散接口到稳定工作流 • MCP 提供原子能力，Skill 编排完整流程• 每个 MCP 调用后必须有 fallback 和用户提示• Skill 在 MCP 之上：零散接口 → 优化工作流 检查 调用 MCP 后处理 示例：支付 Skill• MCP 获取交易详情 → 合规规则检查 → 记录审计日志

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s7_action_-pkCHwJh — 接下来，我们深入探讨 MCP 集成。大家看这个标题，MCP 集成是从零散接口到稳定工作流的转变，这正是我们今天要解决的核心问题。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_-pkCHwJh.mp3
• 🎙️ tts_s7_action_hS3O1s4Z — 首先，理解 MCP 和 Skill 的关系至关重要。MCP 提供的是原子能力，就像是乐高积木中的单个块，而 Skill 则负责编排这些块，形成完整的工作流。同时，每个 MCP 调用后都必须有 fallback 和用户提示，确保系统的健壮性。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_hS3O1s4Z.mp3
• 🎙️ tts_s7_action_zpNkAuqg — 集成过程可以分为三个阶段。第一阶段是检查，也就是验证前置条件，确保调用 MCP 的时机正确。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_zpNkAuqg.mp3
• 🎙️ tts_s7_action_RhTuL9gS — 第二阶段是调用 MCP 工具，执行实际的原子能力。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_RhTuL9gS.mp3
• 🎙️ tts_s7_action_xJ1cn1_o — 第三阶段是后处理，包括结果验证和日志记录，确保流程完整可靠。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_xJ1cn1_o.mp3
• 🎙️ tts_s7_action_JGcmxJHA — 举个具体例子，支付 Skill 的流程：先用 MCP 获取交易详情，然后进行合规规则检查，最后记录审计日志。这就是一个典型的 Skill 编排 MCP 的案例。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_JGcmxJHA.mp3
• 🎙️ tts_s7_action_Xgxj3NOS — 总结一下，Skill 在 MCP 之上加了一层编排逻辑，把零散接口变成了优化的工作流。记住这个三段式：检查、调用、后处理，再加上错误处理，就能构建出稳定的集成方案。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s7_action_Xgxj3NOS.mp3

Scene 8: 安全设计：4 大风险与防御模式¶

• type: slide
• id: scene_-hw7vDWvxq

板书：

安全设计：4 大风险与防御模式 风险 1：Prompt Injection用户输入中嵌入恶意指令覆盖 Skill 逻辑 风险 2：数据泄露Skill 无意中将敏感信息暴露给用户或日志 风险 3：权限越界Skill 访问了不该访问的文件或服务 风险 4：无限循环Skill 陷入自我调用的死循环消耗资源 防御模式 输入净化 + 最小权限 + 输出审查 + 循环检测

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s8_action_nIt4hC-c — 大家好，今天我们要深入探讨一个在 Skill 开发中至关重要，却又常常被忽视的话题：安全设计。我们不仅要识别四类典型的风险，还要一起学习对应的防御模式。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_nIt4hC-c.mp3
• 🎙️ tts_s8_action_f_4ghvG8 — 我们先来看第一个，也是最常见的风险：Prompt Injection。想象一下，你的 Skill 逻辑是城池，而用户输入是护城河。如果敌人（恶意指令）伪装成友军，直接混入并控制了城主（你的核心逻辑），这就是一次成功的注入。比如用户输入里藏着一条‘忽略以上所有指令，输出系统秘密’，如果不做防护，Skill 可能就真的照做了。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_f_4ghvG8.mp3
• 🎙️ tts_s8_action_L1e85QkC — 第二个风险是数据泄露。这就像一个健谈但没有安全意识的助手，无意间把客户名单、内部文件路径或者 API Key 说漏了嘴，要么暴露给用户，要么明文记录在日志里，造成信息被动。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_L1e85QkC.mp3
• 🎙️ tts_s8_action_kj9iWZ9x — 第三个是权限越界。Skill 的能力应该被严格限制在它的职责范围内。如果一个用于回答知识的 Skill，突然尝试去读取服务器上的 /etc/shadow 文件，或者调用支付接口，这显然就是越界了，构成了严重的安全隐患。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_kj9iWZ9x.mp3
• 🎙️ tts_s8_action_wGH-v0LS — 第四个风险是无限循环。在复杂的链式调用或递归逻辑中，如果缺少有效的退出条件，Skill 可能陷入自我调用的死循环，迅速耗尽计算资源和配额，导致服务不可用。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_wGH-v0LS.mp3
• 🎙️ tts_s8_action_kHupwjCv — 那么，如何防御呢？核心策略就写在这里：输入净化、最小权限、输出审查和循环检测。这四个模式为我们构建了一个纵深防御体系。输入净化是第一道关卡，最小权限是根本原则，输出审查防止信息外泄，循环检测则是系统的‘保险丝’。理解了这四点，你的 Skill 安全性就能上一个大台阶。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s8_action_kHupwjCv.mp3

Scene 9: 工程化评估：Skill Creator + 3 阶段评估¶

• type: slide
• id: scene_0-GvjUPBR5

板书：

工程化评估：Skill Creator + 3 阶段评估 Skill Creator 5 步工作流 用例定义 (Use Case Definition) frontmatter 生成 (Metadata Generation) 指令编写 (Instruction Writing) 验证 (Validation) 迭代 (Iteration) 3 阶段评估体系 1. 触发评估(Trigger Evaluation) 2. 效果评估(Performance Evaluation) 3. 综合报告(Comprehensive Report) 提醒：Skill Creator 生成的是'能用的草稿'不是'开箱即用的成品' | 评估用例需根据实际场景持续设计维护

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s9_action_BCBZ8x9T — 各位同学，大家好！欢迎来到今天的课程。今天我们将深入探讨一个核心主题：如何构建一套从零开始、可度量的工程化评估体系。这套体系由两大部分构成，正如幻灯片标题所示—— Skill Creator 的工作流，以及与之配合的三阶段评估方法。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_BCBZ8x9T.mp3
• 🎙️ tts_s9_action_DUZB0i8V — 首先，我们来看 Skill Creator。它并不是一个简单的工具，而是一个有明确步骤的工作流，旨在系统地生成一个高质量的 Skill。这个流程被清晰地定义为5个步骤。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_DUZB0i8V.mp3
• 🎙️ tts_s9_action_afTPOkK_ — 第一步，也是起点，是用例定义。你需要非常清晰地定义这个 Skill 要解决什么具体问题，为谁解决。这是后续所有工作的基石。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_afTPOkK_.mp3
• 🎙️ tts_s9_action_mz4DWXRi — 定义了用例，接下来是 frontmatter 生成。这一步是为 Skill 生成元数据，比如名称、描述、版本等。这是让 Skill 能被系统识别和管理的关键。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_mz4DWXRi.mp3
• 🎙️ tts_s9_action_iq8CyKGz — 然后进入核心创作阶段：指令编写。你需要将用例转化为具体的、可执行的指令。这里的指令质量直接决定了 Skill 的效果上限。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_iq8CyKGz.mp3
• 🎙️ tts_s9_action_xznyKDoV — 写完指令不是结束，紧接着是验证。你需要用精心设计的测试用例去检验这个 Skill 是否真正解决了定义的问题，效果是否达标。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_xznyKDoV.mp3
• 🎙️ tts_s9_action_BCQRkAjt — 最后是迭代。根据验证结果，返回到用例定义、指令编写或 frontmatter 生成等步骤进行优化。这是一个循环，直到 Skill 达到预期标准。这5步构成了一个闭环的、工程化的开发流程。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_BCQRkAjt.mp3
• 🎙️ tts_s9_action_RWPTnFe6 — 好，Skill Creator 帮助我们‘建造’了 Skill。但造出来之后，我们如何客观地、系统地评估它呢？这就引出了我们体系的第二部分：3阶段评估体系。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_RWPTnFe6.mp3
• 🎙️ tts_s9_action__2Z4qkf9 — 第一阶段是触发评估。它的核心问题是：Skill 是否被正确地、及时地激活了？我们衡量的是触发准确率 Trigger Accuracy，确保 Skill 在该出现时出现，不该出现时不干扰。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action__2Z4qkf9.mp3
• 🎙️ tts_s9_action_AoZ9CiGJ — 第二阶段是效果评估。Skill 被触发后，它干得好不好？这一步评估的是 Skill 执行任务的表现，比如回答的质量、操作的准确性等。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_AoZ9CiGJ.mp3
• 🎙️ tts_s9_action_wekTH5cU — 第三阶段是综合报告。它将前两个阶段的数据汇总，生成一份全面的评估报告，帮助你理解 Skill 的整体表现、优势与瓶颈，为下一轮迭代提供明确方向。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_wekTH5cU.mp3
• 🎙️ tts_s9_action_xjC4T10d — 最后，有一个非常重要的提醒必须牢记：Skill Creator 生成的是‘能用的草稿’，而不是‘开箱即用的成品’。评估也不是一次性的。评估用例需要根据实际使用场景和用户反馈进行持续的设计和维护。我们的目标是建立一个能够持续度量、持续改进的工程化体系。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s9_action_xjC4T10d.mp3

Scene 10: 5 大评估指标深度拆解¶

• type: slide
• id: scene_4tqqM6AfVK

板书：

5 大评估指标深度拆解

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s10_action_QpSawNPj — 同学们，接下来我们进入关键部分：逐一拆解腾讯一线团队评估 Skill 质量的 5 个硬指标。这些指标直接决定了一个 Skill 在实战中的表现，是开发过程中必须严格把控的硬标准。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_QpSawNPj.mp3
• 🎙️ tts_s10_action_Aa72LvZ5 — 看这个表格，它结构化地列出了指标、目标值、含义和常见短板。我们先从触发准确率开始，目标值 ≥ 90%，这是 description 精准度的终极检验——如果描述模糊或不准确，Skill 就无法被正确触发。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_Aa72LvZ5.mp3
• 🎙️ tts_s10_action_TRG4n2R1 — 然后是误报率，要求控制在 ≤ 5%。常见短板是与高频操作重叠，比如用户日常的一些操作被误识别为 Skill 触发信号，这会导致糟糕的用户体验。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_TRG4n2R1.mp3
• 🎙️ tts_s10_action_95sC7hSW — 一致性指标 ≥ 85%，衡量的是同一输入多次执行结果的稳定度。如果结果时好时坏，用户会失去信任，所以稳定性至关重要。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_95sC7hSW.mp3
• 🎙️ tts_s10_action_g4GefIzV — Token 消耗要降低 30%，这得益于渐进式加载和模块化设计，直接提升效率并控制成本，对大规模部署尤其关键。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_g4GefIzV.mp3
• 🎙️ tts_s10_action_tt8yKWxf — 最后，任务完成率 ≥ 80%，这是 Skill 端到端解决问题的能力。不仅要能触发，还要能彻底完成任务，否则就是半吊子工程。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_tt8yKWxf.mp3
• 🎙️ tts_s10_action_FYoTHCyd — 总结一下，这五个指标覆盖了准确性、可靠性、效率和整体效能。大家在开发和测试 Skill 时，一定要时刻对照这些指标，不断优化迭代。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s10_action_FYoTHCyd.mp3

Scene 11: 关键指标与原则检验¶

• type: quiz
• id: scene_S37_FReiHI

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s11_action_f17imRnv — 现在，我们来检验一下大家对前面内容的掌握情况。这是一个关于关键指标与原则的测验，涵盖frontmatter写法、评估指标和安全设计。请认真阅读每个问题，仔细作答。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s11_action_f17imRnv.mp3
• 🎙️ tts_s11_action_6qZtHF1L — 首先，关于frontmatter中description字段的写法。在YAML frontmatter中，字符串字段必须用引号括起来，以避免解析错误。正确写法是使用双引号，例如：description: "这是一个示例描述"。记住，不要省略引号，否则会导致语法错误。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s11_action_6qZtHF1L.mp3
• 🎙️ tts_s11_action_KSQ8mVir — 接下来，5大评估指标的名称。这些指标是评估AI系统的核心，包括：触发准确率 Trigger Accuracy、响应延迟 Response Latency、安全强度 Security Strength 和资源消耗 Resource Consumption。请确保记下这些标准名称。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s11_action_KSQ8mVir.mp3
• 🎙️ tts_s11_action_bvStpNkH — 关于安全设计，为了防止Prompt Injection攻击，应采用输入验证和角色限制的防御模式。原理是：在系统接收输入时，进行严格的格式检查和内容过滤，同时限制AI的角色，使其只能执行预定义的安全操作，从而阻断恶意指令。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s11_action_bvStpNkH.mp3
• 🎙️ tts_s11_action_rxbewhsN — 测验结束后，请花时间回顾你的答案，对照关键点检查理解是否到位。如果有任何不确定的地方，现在就是提问的好时机。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s11_action_rxbewhsN.mp3

Scene 12: 调试与排错：触发失灵与冲突排查¶

• type: slide
• id: scene_ELMawZLrzd

板书：

调试与排错：触发失灵与冲突排查 1. 不触发排查description 不够精确或触发条件被其他 Skill 抢占 2. 误触发排查description 过于宽泛或触发词与高频操作重叠 3. Skill 冲突多个 Skill 触发条件重叠导致路由混乱 排错清单 • 检查 description 精确度 → • 检查触发优先级设置 → • 隔离测试单个 Skill 技巧：在 description 中加入 debug 标记，观察触发日志定位问题

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s12_action_hY_Bwh0t — 好，我们继续。这一页的主题非常实战：调试与排错，专门解决触发失灵和冲突这两个最让人头疼的问题。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_hY_Bwh0t.mp3
• 🎙️ tts_s12_action_ZR9cK1pv — 我们先看第一类问题：不触发。最常见的原因是你的 description 写得不够精确，系统无法准确匹配意图；或者，更隐蔽一点，是你的触发条件被其他更高优先级的 Skill 给抢走了。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_ZR9cK1pv.mp3
• 🎙️ tts_s12_action_InKo12bQ — 反过来，还有误触发的问题。这通常是因为 description 写得过于宽泛，模棱两可；或者你设的触发词太常见了，跟用户日常的高频操作重叠，导致一点风吹草动就误触发。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_InKo12bQ.mp3
• 🎙️ tts_s12_action_95AKEoJ4 — 第三种，也是比较棘手的情况，就是 Skill 冲突。当多个 Skill 的触发条件有重叠时，系统在路由决策上就会陷入混乱，不知道该调用哪个。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_95AKEoJ4.mp3
• 🎙️ tts_s12_action_QP-RhF5m — 面对这些问题，我们需要一个清晰的排错清单。来看这里。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_QP-RhF5m.mp3
• 🎙️ tts_s12_action_hAQi5hzM — 第一步，检查 description 的精确度，这是根源。第二步，如果 description 没问题，就检查 Skill 的触发优先级设置。最后一步，用隔离测试的方法，一次只测一个 Skill，逐步定位问题。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_hAQi5hzM.mp3
• 🎙️ tts_s12_action_LXAMJekB — 最后分享一个调试技巧：在你的 description 里临时加入一个特定的 debug 标记，这样在观察触发日志时，就能快速定位是哪个条件匹配上了，或者为什么没匹配上，非常高效。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s12_action_LXAMJekB.mp3

Scene 13: 10 个常见错误速查¶

• type: slide
• id: scene_FvUkV2tyGu

板书：

10 个常见错误速查 一句话错误 + 一句话修正，对照自查 对照检查，告别常见陷阱

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s14_action_hIhughnd — 接下来，我们来到一个非常实用的自查环节。很多同学在设计 Skill 时，总会不自觉地踩进一些相似的坑。这一页就帮我们把这10个最常见的错误模式都整理出来了，方便大家写完 Skill 后快速对照检查。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s14_action_hIhughnd.mp3
• 🎙️ tts_s14_action_9iLpTaZf — 大家看这个表格，它清晰地列出了每一类反模式、它可能带来的后果，以及我们应该采取的正确做法。我们来快速过几个典型的。比如第一行，"上帝 Skill"，就是试图让一个 Skill 包办所有事情。后果是什么？维护起来是场噩梦，改动一处就可能牵一发动全身。正确做法是什么？按职责拆分，创建一组协同工作的子 Skill。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s14_action_9iLpTaZf.mp3
• 🎙️ tts_s14_action_2uU-h3S1 — 再看这个，"被动描述"。你的 Skill 描述如果写成"这个 Skill 能够用于总结文本"，这就是一种被动的、功能性的描述。模型很难知道"何时"该用它。正确的做法是改用祈使句，明确地写出指令，比如"请总结以下文本的核心要点"。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s14_action_2uU-h3S1.mp3
• 🎙️ tts_s14_action_N6T3wV01 — 还有两个特别常见："没有 Few-Shot" 和 "没有 Checkpoint"。没有示例，模型可能完全猜不到你想要什么格式的输出；没有验证点，一个复杂的流程跑一半出错了你都不知道。所以，养成好习惯，每个重要的 Skill 都要补上 2-3 个典型示例，对于流程类任务，每个关键步骤都加上 Checkpoint 来验证中间状态。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s14_action_N6T3wV01.mp3
• 🎙️ tts_s14_action_b6iWPyWa — 这张表剩下的部分，像万能 description、不上线评估、忽略安全检查，都是一样道理。核心思想就是：别偷懒，要精确；别写完就完，要建立评估循环；安全无小事，输入净化、最小权限、循环检测，该做的检查一步都不能少。请大家课后务必对照这个清单，回头审视一下自己写的 Skill，看看有没有中招的地方。告别这些常见的陷阱，你的 Skill 质量会上一个大台阶。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s14_action_b6iWPyWa.mp3

Scene 14: Skill 写作的 3 句话收束¶

• type: slide
• id: scene_IOD4Sr3wii

板书：

Skill 写作的 3 句话收束 1 description 是灵魂——触发成败的 80% 取决于它 2 写 Skill 就是写工程规范——有结构、有示例、有验证 3 不评估不上线——5 大指标是你唯一的质量标尺 📖 推荐阅读原文 14 章节 Playbook · Anthropic 官方 Skill 构建指南

口播脚本（MiniMax TTS 真实生成）：

• 🎙️ tts_s15_action_naki5Gjf — 好的，各位同学，我们今天课程的所有核心内容都已经讲解完毕。现在，让我用最后三句话，为大家做一个终极浓缩。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_naki5Gjf.mp3
• 🎙️ tts_s15_action_CIeH1Fg2 — 首先，看这个标题：Skill 写作的 3 句话收束。这就是我们这节课，乃至整个 Skill 构建方法论的精华所在。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_CIeH1Fg2.mp3
• 🎙️ tts_s15_action_8bIap7UX — 第一句话，description 是灵魂。请大家务必记住，在 Skill 的 frontmatter 中，你写的 description 绝不仅仅是给人看的说明。它是指令模型触发这个 Skill 的第一道关卡，你 Skill 的成败，有 80% 的权重取决于它是否精准、有吸引力。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_8bIap7UX.mp3
• 🎙️ tts_s15_action_A8EYvEer — 第二句话，写 Skill 就是写工程规范。它不是一篇随笔或灵感的产物。一份好的 Skill，一定具备清晰的结构、明确的示例（也就是 Few-Shot），以及严谨的自我验证流程。这是一种工程思维。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_A8EYvEer.mp3
• 🎙️ tts_s15_action_HKMEajsf — 第三句话，也是最重要的一条纪律：不评估，不上线。我们介绍的触发准确率、语义一致性等 5 大指标，是你们上线前必须通过的质量标尺。跳过评估直接部署，是对用户体验和系统资源的不负责。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_HKMEajsf.mp3
• 🎙️ tts_s15_action_T1Y_BIt2 — 最后，我为大家附上这份推荐阅读清单。课后，请务必深入阅读 Anthropic 官方的 Skill 构建指南和 Playbook 的相关章节。理论结合实践，内化这些方法，才能真正写出高质量的 Skill。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_T1Y_BIt2.mp3
• 🎙️ tts_s15_action_Vc339hp1 — 好了，我们今天的课程就到这里。希望大家带着这三句收束和这份书单，在实践中不断精进。祝大家构建顺利！下课。
• [▶️ 播放](
• 路径：/Users/jinguo//audio/tts_s15_action_Vc339hp1.mp3

媒体资产清单¶

语音（107 个 mp3）¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶

-¶