7.5 设计原则与常见误区
面向经管学生、研究者与从业者的 AI 智能体设计教材
并不是所有常用任务都值得做成 Skill。适合封装为 Skill 的任务，通常同时满足三个条件：
- 触发场景稳定——能用清晰的短语描述何时使用
- 处理步骤可复用——流程相对固定，不需要每次重新设计
- 输出标准明确——产出结果有清楚的格式或质量要求
满足这三个条件，Skill 才能真正减少重复劳动。不满足，则可能把混乱固化下来。
适合与不适合的对照
| 适合做成 Skill | 不适合做成 Skill |
|---|---|
| 会议纪要整理（高频、结构稳定） | 头脑风暴新商业模式（探索性强） |
| 固定格式研报摘要（输出标准明确） | 处理一次性临时材料（不会重复） |
| 季度财报分析流程（步骤可复用） | 所有写作都交给一个 Skill（边界过宽） |
| 合规检查清单（流程固定） | 开放式研究讨论（流程不稳定） |
六条设计原则
| 原则 | 含义 | 反例 |
|---|---|---|
| 单一职责 | 一个 Skill 只做一类事 | 把摘要、改写、校对塞进同一个 Skill |
| 描述可判别 | description 能让系统准确匹配 | 写成一个有用的写作 Skill |
| 正文可执行 | 步骤足够具体，智能体能照做 | 正文只写请认真完成任务 |
| 边界可说明 | 清楚什么不属于这个 Skill 的范围 | 把所有相关功能都往里塞 |
| 可组合 | 多个 Skill 并存时不互相冲突 | 两个 Skill 争抢同一类任务的触发权 |
| 可移植 | 跨平台使用时行为一致 | 依赖特定环境变量而不在 compatibility 中声明 |
前四条是基础原则，确保单个 Skill 能独立工作。后两条是协作原则，确保 Skill 在多 Skill 环境和跨平台场景下依然可靠。
可组合意味着你的 Skill 不应假设自己是唯一被加载的能力。Claude 可以同时加载多个 Skill，每个 Skill 应当在自己的职责范围内工作，不与其他 Skill 产生歧义。
可移植意味着同一个 Skill 应当在 Claude.ai、Claude Code 和 API 中产生一致的行为。如果 Skill 依赖特定环境（如某个系统包或网络条件），应在 frontmatter 的 compatibility 字段中明确声明。
常见误区
误区速查
| 误区 | 问题 | 正确做法 |
|---|---|---|
| Skill 越大越好 | 边界模糊，触发失真 | 保持单一职责，一个 Skill 只做一类事 |
| 没有脚本就不算 Skill | 混淆了最小层和增强层 | 只有 SKILL.md 也能成立 |
| description 越宽泛越好 | 系统无法准确匹配 | 写清具体的触发场景和否定条件 |
| 先收集 Skill 再学原理 | 缺乏判断力，无法评估质量 | 先掌握设计原则，再决定复用 |
核心判断
一个任务是否适合封装为 Skill，取决于三个条件：触发场景是否稳定，处理步骤是否可复用，输出标准是否明确。如果三个条件都满足，从最小结构（只有 SKILL.md）起步，验证触发和执行效果后再逐步增强。
最后回到本章的边界。本章讨论的 Skill 都是基础层面的：一个 SKILL.md，一套触发和执行规则，最多配合少量辅助文件。当 Skill 开始连接脚本、编排多工具调用、嵌入复杂验证逻辑时，它就从说明书进一步发展为可执行工作流。