Files
TARE-Learn/slidev/pages/day3/m3-commands-skills-mcp.md
smart 67837df8d0 docs: 更新TRA编程培训课程材料、课件与AI技能交付包
- 新增全套考试卷、评估卷、参考答案与考试培训包模板
- 修正slidev培训课件:调整模块标题、链路图缩放,替换工单示例为通用业务对象
- 修正课堂红线表述为证据红线,将小组作业调整为个人作业要求
- 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块
- 整理AI工程技能交付包,迁移旧资产至客户专属交付包并统一术语
- 新增考试输出模板与TRAE使用记录文档
2026-08-08 11:00:36 +08:00

245 lines
8.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 模块 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 包。
判断标准是任务复杂度、资源依赖、团队复用、工具接入方式和验收成本。
-->