在 Module 1 你学会了构建和部署第一个 Skill。现在要实现真正的转变：

从单次使用的 Skills → 可扩展的智能自动化系统

技能多了之后，新问题会出现：Skill 之间冲突、任务需要计算而非指令、大量引用难以管理。

指令 vs 脚本：各司其职

目前你构建的一切都依赖纯文本指令。这适用于写作、格式化、分类、决策——但有些任务超出了语言范畴，需要计算、文件操作、数据处理、外部集成。这就是脚本的用武之地。

把 Skill 看作两个组件：

  • 指令（Instructions） → 处理推理和决策
  • 脚本（Scripts） → 处理执行和计算

用指令的场景： 任务涉及判断、输出依赖解释、语言质量重要（如"用专业语气重写"、"总结会议记录"、"分类反馈"）。

用脚本的场景： 需要精度、必须计算、需处理文件（如解析 CSV/XML、执行计算、调整图片大小、提取结构化数据）。

两者结合： 工作流同时需要逻辑和执行时——如"处理数据集（脚本）→ 生成人类可读摘要（指令）"。

Skill 结构演进

your-skill/ ├── SKILL.md ├── scripts/ │ └── ... └── references/

关键原则：

  1. 一个脚本 = 一个职责：避免把多个任务合并到一个脚本
  2. 用参数而非硬编码：脚本应动态接受输入（输入文件路径、输出文件路径），保持 Skill 灵活性
  3. 加错误处理：脚本应清晰传达失败情况（文件缺失、格式错误、数据无效），Claude 能读取并智能响应
  4. 文档化脚本：每个脚本顶部注明功能、输入要求、预期输出、可能错误

多 Skill 冲突：当两个 Skill 同时响应

创建多个 Skills 后，新问题浮现：

哪个 Skill 应该运行？

例：你说"起草邮件"，但"内容再利用"Skill 激活了。

机制：Claude 读取所有 Skill 描述 → 与请求对比 → 打相关性分数 → 最高分的 Skill 激活。没有达到阈值的 → 不运行。

冲突根源：

  • 触发短语重叠
  • 描述模糊
  • 边界缺失

解法：每个 Skill 有特定领域，无重叠；明确定义排除项（如"Do NOT use for email drafting"）；每个 Skill 有唯一激活短语。

如果错误 Skill 激活：检查 YAML 描述 → 识别重叠短语 → 收紧范围和排除项。大多数情况下问题不在逻辑，而在描述。

引用管理：选择性加载

Module 1 讲的是基本引用处理，但现实更复杂。

如果 Skill 需要：50 页品牌指南、30 页风格手册、多个模板，一次性加载所有内容会浪费上下文、降低性能。

正确做法：

  • 结构化引用逻辑
  • 只访问所需内容
  • 保持文件简洁专注

引用越有选择性，Skill 表现越好。