# 模块 3：从 Commands 到 Skills

<div class="mt-6 text-sm">

Commands 解决高频输入，Skills 解决可复用交付。两者都不是“把 Prompt 存起来”这么简单，而是把团队经验变成可触发、可验收、可维护的资产。

</div>

<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
<div class="font-bold mb-2">Commands</div>

- 固定入口
- 固定输入
- 固定输出
- 低风险、短流程
</div>
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
<div class="font-bold mb-2">Skills</div>

- 多步流程
- 可带模板和检查清单
- 可沉淀项目经验
- 适合交付给团队或客户
</div>
</div>

<!--
这一页要先帮学员纠偏：Command 和 Skill 都不是“更长的 Prompt”。
Command 的核心是减少重复输入，让同一类轻量任务有统一入口。
Skill 的核心是把完成任务所需的判断流程、输入要求、输出标准、模板和检查清单放在一起。
所以今天讲能力封装，不是为了多造几个文件，而是让团队经验以后可以被重复触发、重复验收、重复维护。
-->

---

# Commands 适合什么？

<div class="mt-6 text-sm">

| 判断标准 | 适合 Command 的特征 | 示例 |
|---|---|---|
| 问法固定 | 每次提问差异很小 | 生成 PR 说明 |
| 输入固定 | 只需要 diff、日志或单个文件 | 总结当前变更 |
| 输出固定 | 表格或固定段落即可 | commit message |
| 风险较低 | 不直接改核心逻辑 | 生成日报 |
| 不需要多步判断 | 不需要跨多个规则来决策 | 格式化说明 |

</div>

<div class="mt-4 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
Command 的关键价值是降低重复输入成本，并让轻量任务输出稳定。
</div>

<!--
这里要把 Command 的边界讲清楚。
它适合“同一句话每天都要说”的场景，比如总结 PR、生成 commit message、提取 CI 日志摘要。
但是如果一个任务需要先读项目规则、再判断风险、再套模板、最后给验收标准，Command 就不够了。
不要把所有事情都做成斜杠命令，否则命令库会变成另一种噪声。
-->

---

# Command 的坏味道

<div class="mt-6 text-sm">

| 坏 Command | 问题 | 更好的方向 |
|---|---|---|
| `/检查代码` | 范围太大，输出不可控 | `/代码生成Review` |
| `/优化一下` | 没有目标和验收标准 | `/按性能规则检查列表页` |
| `/生成文档` | 不知道文档对象和读者 | `/生成PR说明` |
| `/帮我看看` | 没有输入边界 | 改成带输入材料的 Skill |

</div>

<!--
这一页可以直接拿来点评学员写的命令。
坏 Command 的共同特点是“看起来方便，实际上不可控”。
AI 收到 `/检查代码` 以后，可能检查格式、可能检查 bug、可能检查权限，也可能给一段空泛评价。
进入团队资产库的 Command 必须收敛：什么时候用、需要什么输入、输出什么格式、怎么验收。
-->

---

# Skills 的两个升级

<div class="grid grid-cols-2 gap-6 mt-8 text-sm">
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
<div class="font-bold mb-2">按需加载</div>

Agent 先看 Skill 描述，任务相关时再读取完整说明。
</div>
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
<div class="font-bold mb-2">携带资源</div>

Skill 可以带模板、Prompt、检查清单、反例和脚本。
</div>
</div>

<div class="mt-6 p-3 rounded-xl bg-gray-500/10 border border-gray-500/30 text-sm">
Skill 不是单个 Markdown，而是一组能被复制、安装和维护的工作流资产。
</div>

<!--
Skills 的关键升级有两个。
第一是按需加载，避免把所有团队知识一次性塞进上下文。
第二是携带资源，避免每次都重新发模板、检查清单和示例。
所以 Skill 更适合企业培训后的标准化落地：它把老师讲过的流程变成团队以后可以继续使用的能力包。
-->

---

# 什么值得做成 Skill？

<div class="mt-5 text-sm">

| 判断问题 | 是，就更适合 Skill |
|---|---|
| 是否需要多步判断？ | 权限、状态、审计、异常态、看板需要串起来 |
| 是否需要项目证据？ | 需要读源码、配置、规则和验收记录 |
| 是否需要多个输出？ | 矩阵、清单、Review 报告、修复记录 |
| 是否需要资产复用？ | 客户或团队下次还会做类似任务 |
| 是否有质量门槛？ | 必须能验收，不只是生成文字 |

</div>

<!--
这一页是判断标准。
表格、清单、Prompt 本身不一定要做成 Skill。
真正适合 Skill 的，是“怎么判断、怎么生成、怎么验收、怎么闭环”。
例如 RBAC 权限矩阵只是一个模板；但“复杂业务模块设计”需要先定角色、再定权限、再定状态、再补审计和看板，这就是 Skill。
-->

---

# Skill 交付结构

<div class="mt-5 text-sm">

```text
skill-name/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── assets/
    ├── templates/
    ├── checklists/
    ├── prompts/
    └── examples/
```

</div>

<div class="mt-5 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
给客户交付 Skill 时，交付的是完整文件夹，不是单个 `.md`。
</div>

<!--
这一页补一个非常落地的知识点。
客户拿到 Skill 后，不应该只拿到一段 Prompt，而应该拿到完整目录。
SKILL.md 说明什么时候触发、怎么执行、输出什么。
agents/openai.yaml 是工具识别和展示用的元数据。
assets 里放模板、检查清单、Prompt、反例和案例。
这也是为什么培训产物最后可以打包给客户，而不是只发聊天记录。
-->

---

# Skill 的三种交付形态

<div class="grid grid-cols-3 gap-4 mt-6 text-sm">
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
<div class="font-bold mb-2">知识型</div>

- 项目约束
- 编码规范
- 业务口径
</div>
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
<div class="font-bold mb-2">流程型</div>

- 复杂业务设计
- 阶段 Review
- 修复闭环
</div>
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
<div class="font-bold mb-2">工具型</div>

- 脚本
- CLI
- 测试和报告
</div>
</div>

<!--
原来的二分法课堂里容易理解，但交付给客户时不够工程化。
这里改成三种交付形态：知识型、流程型、工具型。
项目约束生成属于知识型，复杂业务模块设计和 Review 属于流程型，自动跑测试或生成报告属于工具型。
企业团队通常三类都会有，但不要混在一个 Skill 里。
-->

---

# MCP 与 CLI 思维

<div class="mt-5 text-sm">

| 接入方式 | 适合场景 | 选择依据 |
|---|---|---|
| Command | 固定话术、固定格式 | 降低重复输入 |
| CLI | 命令稳定、脚本成熟 | 优先轻量封装 |
| MCP | 交互式工具、结构化能力描述 | 适合平台化接入 |
| Skill | 需要流程、模板、检查清单和示例 | 适合团队复用 |

</div>

<!--
底层理念是：只要工具能被命令行或接口驱动，Agent 就能接入。
MCP 是一种协议形态，CLI 是一种执行方式，Command 是轻量入口，Skill 是知识和流程封装。
课堂里要帮助学员判断，不是所有能力都上 MCP，也不是所有能力都做 Skill。
-->

---

# 能力封装决策表

<div class="mt-5 text-sm">

| 需求 | 推荐封装 | 理由 |
|---|---|---|
| 每天生成日报 | Command | 固定话术、固定格式 |
| 项目约束生成 | Skill | 需要扫描源码、配置、规则并输出验收清单 |
| 复杂业务模块设计 | Skill | 权限、状态、审计、看板需要串联判断 |
| 内部平台查询 | CLI 或 MCP | 取决于现有接口形态 |
| 代码审查报告 | Skill | 需要规则、模板、反例和风险分级 |

</div>

<!--
这个练习让学员把封装方式和交付物对应起来。
可以提醒大家：最后客户能复用的不是“今天课堂上写过的某一句 Prompt”，而是一组可安装、可复制、可维护的 Skill 包。
判断标准是任务复杂度、资源依赖、团队复用、工具接入方式和验收成本。
-->