🦸 Agent Skill 科普讲义
glmos-code-explain
给公司运营15分钟分享 Skill ，用🦞生成的内容和 PPT，挺方便的。agent-skill-科普讲义.pptx
🦸 Agent Skill 科普讲义
《技能卡：让 AI 变成你专属助手》
约 15 分钟 · 非技术人员向
一、开场：你们遇到的真实困境（2分钟）
用提问开场，拉近距离：
"你们有没有遇到过这样的情况——让 AI 帮你做个事，它说'我没有权限访问这个系统'，或者每次都要重新解释一堆背景，非常麻烦？"
痛点清单（现场举手互动）：
- ✋ 问了 AI 半天，还是要自己去系统里手动操作？
- ✋ AI 每次都不知道你们公司的流程和术语？
- ✋ 感觉别人都在用 AI，自己却不知道从哪下手？
- ✋ 听到"Agent""Skill"就头大，感觉自己要被落下了？
这节课就是专门解决这些问题的。不讲原理，只讲能用、会用、用好。
二、先搞清楚三个概念的关系（2分钟）
很多人一听"大模型、Agent、Skill"就晕，其实类比一下就清楚了：
┌─────────────────────────────────────────────────────────┐
│ 一个厉害的新员工 │
│ │
│ 大模型 (LLM) = 这个人的大脑、知识储备 │
│ （ChatGPT、Claude、文心等） │
│ │
│ Agent (智能体) = 这个人会自己想、自己干 │
│ （不只回答问题，还能主动执行任务） │
│ │
│ Skill (技能卡) = 给他的"工作手册+工具箱" │
│ （告诉他怎么干我们公司的活） │
└─────────────────────────────────────────────────────────┘
一句话总结：
大模型是大脑，Agent 是行动力，Skill 是让它干你具体业务的说明书。
三者是层层递进的关系——有了大脑，有了行动力，还差最后一块：知道怎么干你这里的活。Skill 就是补上这块的。
三、Skill 到底是什么？（3分钟）
3.1 最直观的对比
光说概念太抽象，先看两个场景感受一下：
没有 Skill 的 AI：
你 ──→ "帮我查一下这个订单状态"
AI ──→ "我无法访问您的订单系统，请提供订单号和
系统地址……" 😩（然后你还得自己去查）
有了 Skill 的 AI：
你 ──→ "帮我查一下这个订单状态"
AI ──→ [自动登录系统] → [查询] → "订单 #12345 已发货，
预计明天到，物流单号 SF1234567890" ✅
没有 Skill 的 AI（写周报）：
你 ──→ "帮我写本周工作总结"
AI ──→ "请告诉我你本周做了什么……"
（你还得手动整理一遍，那写它干嘛）
有了 Skill 的 AI（写周报）：
你 ──→ "帮我写本周工作总结"
AI ──→ [自动读取你的日历] → [读取你的任务系统]
→ [读取你提交的文档] → 生成一份初稿
直接发你，只需你确认修改 ✅
差别不在于 AI "聪不聪明"，在于它有没有一本针对你业务场景的操作手册。
3.2 Skill 里有什么？
通俗来讲，一个 Skill 就是一张"工作流卡片"，里面包含：
| 内容 | 类比 | 示例 |
|---|---|---|
| 这个技能是干嘛的 | 岗位职责 | "帮用户预订会议室" |
| 碰到什么情况启动 | 触发条件 | "用户说'帮我订会议室'时" |
| 用哪些工具、接哪些系统 | 工具箱 | "会议室预订系统、日历" |
| 按什么步骤做 | SOP 流程 | "查空闲→确认人数→提交预订" |
| 注意什么 | 注意事项 | "超过10人需提前1天预约" |
3.3 Skill 的文件结构长什么样？
一个 Skill 是一个文件夹，SKILL.md 是必须有的，其余资源按需放：
room-booking/ ← Skill 根目录（文件夹名即 Skill 名）
├── SKILL.md ← 必须，触发器 + 操作指南
├── scripts/ ← 可选，封装好的可执行脚本
│ └── query_rooms.py │ （固定操作用脚本比文字描述更稳定）
├── references/ ← 可选，参考文档（按需加载，不占主上下文）
│ └── room-list.md │ （比如各楼层会议室清单、容量说明）
└── assets/ ← 可选，输出时用到的模板/文件
└── invite-template.txt │ （比如日历邀请的邮件模板）
💡 scripts / references / assets 都是可选的。对于大多数 Skill，一个 SKILL.md 就够了。资源目录是为了把"大块内容"从主文件里剥离出来，让 Agent 按需加载，避免一次性塞满上下文。
再看 SKILL.md 本身的结构——它分为两层：
SKILL.md
│
├── ── YAML Frontmatter（触发层）──────────────────────────
│
│ ---
│ name: room-booking
│ description: >
│ 帮用户预订公司内部会议室。当用户说"帮我订会议室"、
│ "预约会议室"、"找个空会议室"、"安排会议地点"时激活。
│ 支持按时间/人数/楼层查询空闲会议室，确认后自动提交
│ 预订并发送日历邀请。
│ ---
│
│ ← Agent 扫描 description，决定"要不要触发这个 Skill"
│ ← 触发条件必须写在这里，写在 body 里 Agent 看不见
│
└── ── Markdown Body（执行层）─────────────────────────────
# 会议室预订
## 执行步骤
1. 收集必要信息：会议时间、时长、预计人数、楼层偏好
（用户已提供的直接用，缺少的追问）
2. 调用 scripts/query_rooms.py 查询该时段空闲会议室
3. 向用户推荐最多3个选项，附容量和位置说明
4. 用户确认后提交预订，发送日历邀请
## 注意事项
- 10人以上会议需提前至少1天预约
- 所有会议室均满时，建议用户调整时间或换楼层
- 不确定时先告知用户，不要自行猜测提交
← body 只在 Skill 触发后才加载，写执行逻辑即可
← 触发条件不要在这里重复写，也不要堆参考细节
两层的分工一句话总结：
| 层级 | 位置 | 作用 | 何时加载 |
|---|---|---|---|
Frontmatter description |
YAML 头部 | 告诉 Agent何时触发 | 始终在上下文中 |
| Markdown body | 正文 | 告诉 Agent如何执行 | 触发后才加载 |
3.4 Skill 从哪来？
三个来源：
① 官方 Skill 广场 ──→ 直接安装即用 🛒
（公司审核上架的，安全合规，拿来就能用）
② 同事分享的 ──→ 拿来微调即用 🤝
（适合业务相似的团队互相复用）
③ 自己写的 ──→ 完全定制化 ✍️
（不需要写代码！写中文就行）
💡 类比购物：Skill 广场就像应用商店，大部分需求直接搜一下就有现成的；少数特殊需求才需要自己定制。
3.5 为什么有了 Agent 还需要 Skill？
理解了 Skill 是什么，再来看一个更底层的问题：Agent 本来就很聪明，为什么还要专门写 Skill？
因为 AI 的"默认思路"并不是你的业务思路。
大模型对代码、通用工具、标准流程已经有充分了解——但这不是你的部门，不是你的系统，不是你们的规矩。
Skill 真正的价值，是把 Agent 从通用默认路径推向你业务特有的正确路径：
没有 Skill 时，Agent 会：
┌────────────────────────────────────────────┐
│ 用户："查一下这个订单状态" │
│ │
│ Agent 默认思路： │
│ → 问用户"用什么系统？" │
│ → 或者猜一个通用方式 │
│ → 结果：慢、不准、还要用户补信息 │
└────────────────────────────────────────────┘
有了 Skill 之后，Agent 会：
┌────────────────────────────────────────────┐
│ 用户："查一下这个订单状态" │
│ │
│ Skill 告知 Agent： │
│ → 我们用内部 OMS 系统 │
│ → 接口是 /api/order/query │
│ → 订单号格式是 MT-XXXXXX │
│ → 结果：直接查，秒出答案 │
└────────────────────────────────────────────┘
Skill 在整个 Agent 运行中的位置：
用户发消息
↓
Agent 扫描所有 Skill 的 description
判断：这个请求该用哪个 Skill？
↓
找到匹配的 Skill → 加载 SKILL.md
↓
按 SKILL.md 的步骤执行（调用工具、查询系统…）
↓
返回结果给用户
没有 Skill，第二步找不到匹配，Agent 只能靠"通用直觉"瞎猜——能动，但不知道做你这里的活。
Skill 解决的三个本质问题：
- 记忆问题：你不需要每次都跟 AI 解释背景和规则，Skill 帮它记着
- 一致性问题：同一件事，100次都按同一个标准做，不会因为"理解偏差"产生不同结果
- 扩展问题：一个 Skill 写好，全团队都能用，不用每个人重新教一遍
💡 Skill 不是"教 AI 做事"，而是"把 AI 的注意力定向到你的业务场景"。即使只写几行说明，也能让 AI 的表现大不相同。
四、Skill 能帮你干什么？（2分钟）
光讲概念不够直观，来看看不同角色装上 Skill 之后，日常工作能变成什么样：
| 角色 | 没有 Skill | 有了 Skill |
|---|---|---|
| 📊 数据同学 | 每次手动查数、复制粘贴出图 | 一句话：AI 自动查数、生成周报初稿、发到群里 |
| 📅 运营同学 | 自己登系统预约会议室、填审批单 | AI 直接帮你预约+发审批，你只需确认 |
| 📝 产品同学 | 手动翻文档找信息做对比 | AI 自动读文档、提炼关键点、帮你写方案对比 |
| 👩💼 HR同学 | 重复回答同事问题（假期政策、报销规则） | AI 配置好知识库，自动回答常见 HR 问题 |
| 🔔 所有人 | 靠自己记着要做什么 | 让 AI 定时提醒+自动完成重复操作 |
找到你的候选场景：
问自己：我每周重复做3次以上、每次都很烦、但又没人能替我做的事是什么？
那就是你最适合用 Skill 解决的问题。
五、Skill 的几种书写模式（3分钟）
这是很多人不知道的：Skill 不只有一种写法，根据你的需求，有几种常见模式。
5.1 指令型——设定规则与风格（最简单，先从这个开始）
适合场景：你想让 AI 用特定风格、特定格式、按特定规则回答问题。
────────────────────────────────────────
指令型 Skill 示例：周报助手
你是一名专业的工作总结助手。
当用户提供本周工作内容时，你需要：
- 按"完成事项 / 进行中 / 下周计划"三段整理
- 每条控制在20字以内，简洁有力
- 开头加一句亮点总结（不超过30字）
- 结尾附"需要支持的事项"
风格：专业、简洁，避免废话
────────────────────────────────────────
特点：写起来最简单，就是给 AI 设定"人设"和"规则"，适合写文案、做总结、格式化输出。
5.2 流程型——定义操作步骤（最常用）
适合场景：有明确步骤顺序的任务，比如审批、查询、发送通知。
────────────────────────────────────────
流程型 Skill 示例：会议室预订（SKILL.md body 部分）
## 执行步骤
Step 1. 收集必要信息：时间、时长、人数、楼层偏好
（用户已提供的直接用，缺少的追问）
Step 2. 查询该时段可用会议室列表
Step 3. 推荐最多3个选项给用户确认，附容量说明
Step 4. 用户确认后自动提交预订
Step 5. 发送确认消息，附日历邀请
## 注意事项
- 超过10人的会议需提前1天预约
- 若所有会议室都满，建议用户调整时间或换楼层
- 不确定时先告知用户，不要猜测提交
────────────────────────────────────────
💡 注意：触发词（"帮我订会议室"等）写在 frontmatter 的 description 里，不在 body 里。body 只写执行逻辑。
特点：步骤清晰，AI 不会乱来，每步有明确动作。适合替代那些你熟悉但烦死人的重复流程。
5.3 知识库型——沉淀团队知识
适合场景：把团队知识、FAQ、政策文档"喂"给 AI，让它成为团队的"百科问答机"。
────────────────────────────────────────
知识库型 Skill 示例：HR 政策助手
你是公司HR政策助手，专门回答员工关于：
- 年假/调休/病假规则
- 报销流程和额度限制
- 福利政策（餐补/交通补贴等）
- 入职/离职流程
知识来源：[HR政策文档v2026.pdf]
回答规则：
- 只回答政策范围内的问题
- 不确定的内容说"请联系HR确认"
- 每次回答附上政策来源章节
────────────────────────────────────────
特点：一次配置，全团队受益。减少重复沟通，让 HR、法务、运营的知识变成"会说话的文档"。
5.4 自动化型——接入系统真正动手
适合场景：需要 AI 真正"动手"——登录系统、发消息、读写数据。
────────────────────────────────────────
自动化型 Skill 示例：日报自动生成
触发：每天 18:30
工具调用：
① 读取今日日历（工具：calendar-mcp）
② 读取今日任务完成情况（工具：ee-ones）
③ 整理成日报格式
发送目标：大象群「项目日报」
格式模板：
【日报 {日期}】
✅ 今日完成：{事项列表}
🔄 进行中：{事项列表}
📌 明日计划：{事项列表}
❓ 需协助：{如有}
────────────────────────────────────────
特点：这是最"魔法"的一种，AI 真的在帮你干活，而不只是写字。需要配合对应的工具接入，但一旦跑通，效率提升是数量级的。
5.5 四种模式横向对比
指令型 ──→ 设定规则/风格，适合文字输出类任务
流程型 ──→ 定义步骤，适合有固定流程的操作
知识库型 ──→ 沉淀知识，适合FAQ/政策/文档问答
自动化型 ──→ 接入系统，适合替代重复性手工操作
难度：指令型 < 流程型 < 知识库型 < 自动化型
效果：指令型 < 流程型 < 知识库型 < 自动化型
建议：从指令型开始，用好一个再升级 🚀
六、如何写好一个 Skill？（3分钟）
6.1 先破一个误区
❌ "写 Skill 需要会编程"
✅ 写 Skill 就是写中文说明书，像给新人写 SOP 一样
但"写 Skill"和"写好 Skill"之间，还是有差距的。以下是让 Skill 好用的关键原则：
6.2 原则一：description 是触发器，不是简介
这是新手最容易踩的坑，值得单独拿出来说。
Agent 在收到用户请求时，会扫描所有已安装 Skill 的 description 字段，用来判断："这个请求该用哪个 Skill？"
所以 description 写的是激活条件，不是功能描述：
❌ 错误写法（像产品介绍文案）：
"本 Skill 提供会议室预订功能，支持查询可用
时段、人数筛选、地点偏好设置，并可自动发
送日历邀请给与会者。"
→ 虽然说清楚了功能，但 Agent 看不出"什么时候该触发"
→ 用户说"帮我订个会议室"，Agent 不确定是不是这个 Skill
→ 结果：该用的时候没用，或者用错了
✅ 正确写法（写清楚触发场景 + 功能摘要）：
"帮用户预订会议室。当用户说'帮我订会议室'、
'预约会议室'、'找个空会议室'、'安排个会议
地点'时激活。支持查询空闲时段、确认人数与
地点、提交预订。"
→ Agent 能精准判断：用户说这些词 → 用这个 Skill
一个更直观的类比：
你手头有10本专业书（10个 Skill）
没有书名和目录（糟糕的 description）：
→ 每次找书要一本一本翻，或者根本找不到
→ Agent 也是，description 模糊就"盲目选 Skill"
有清晰书名和关键词（好的 description）：
→ 一眼找到"会议室预订"那本，直接翻开
→ Agent 精准命中，立刻加载正确手册执行
description 的黄金公式：
「[功能动词] + [明确对象]。当用户[说/做什么]时激活。支持[核心能力列表]。」
举例：
- ✅ "查询订单状态。当用户提到订单号、查订单、物流进度时激活。支持实时查询、异常提醒。"
- ✅ "自动写日报。当用户说'帮我写日报''生成今日总结'时激活。从日历和任务系统读取数据生成草稿。"
- ✅ "HR 政策问答。当用户询问假期、报销、福利、入离职相关问题时激活。基于内部政策文档回答。"
6.3 原则二：不要在 Skill 里陈述废话
AI 对代码、标准库、通用工具、常识性流程已经有充分了解。Skill 里不需要告诉它"HTTP 请求怎么发"或"表格排序怎么做"——它早就知道了，写了只会稀释真正有用的信息。
❌ 浪费篇幅的写法（AI 本来就知道）：
"使用 HTTP GET 请求调用接口，注意设置
Content-Type 为 application/json，
处理返回的 JSON 数据，解析其中的字段……"
→ 这些是常识，AI 看了等于没看
→ 更糟的是：这一段话多了，AI 反而分不清重点
❌ 另一种废话：解释"为什么要做这件事"
"订单查询对业务非常重要，能帮助用户
及时了解货物配送进度，提升用户满意度……"
→ 背景介绍也是废话，Agent 不需要"说服"，它需要"指令"
✅ 有价值的写法（业务特有信息）：
"调用内部 OMS 接口 /api/order/query，
需要在 Header 带上 X-Auth-Token
（从环境变量 OMS_TOKEN 读取）。
订单号格式固定为 MT-8位数字，
非此格式时提示用户确认。"
→ 接口地址、认证方式、格式规则——这些是 AI 不知道的
→ 写了才有意义，Agent 能直接用
一个判断废话的简单测试：
问自己："如果把这句话删掉，AI 还会正常工作吗？"
- 会 → 删掉，它是废话
- 不会 → 留着，它有价值
比如"要礼貌地回复用户"——删掉，AI 默认就会；"回复时用户名称统一称呼'同学'"——留着，这是你们特有的规范。
💡 Skill 的信噪比越高，AI 越专注在对的事情上。好的 Skill 往往比差的 Skill 更短，但更管用。
6.4 原则三：不要过度约束 Agent
Skill 提供信息和约束，但要留给 Agent 一定的判断空间。
写 Skill 的人往往有个本能冲动——把每一步都写死，生怕 AI 走偏。但这反而是个陷阱：
❌ 过度约束的写法（每步都是"必须"）：
Step 1. 必须先询问用户姓名
Step 2. 必须确认用户部门
Step 3. 必须验证用户权限
Step 4. 必须登录系统，等待页面加载完成
Step 5. 必须点击"新建预约"按钮
Step 6. 必须填写字段A，然后字段B，然后字段C
……（共23步，每步都是"必须"）
→ 用户一开始就告诉你了"我是市场部张三"，
Agent 还是会在 Step 1 重新问一遍：
"请问您的姓名是？"
→ 用户崩溃，体验极差
→ 更糟的情况：用户的问法稍有变化（比如说了
一个 Skill 没预料到的词），Agent 找不到
对应步骤，直接卡住不动了
✅ 留有空间的写法（给目标，不给剧本）：
"收集必要信息（姓名、部门、预约时间）——
用户已提供的直接使用，缺少的才追问。
信息完整后提交预订。遇到系统报错或
异常情况，优先告知用户并询问如何处理，
不要自行猜测继续执行。"
→ Agent 有了目标（收集信息、提交预订）
→ 有了判断依据（已提供的不追问）
→ 有了异常处理原则（报错先告知）
→ 剩下的路怎么走，Agent 自己判断
类比：给新员工的指导
过度约束（糟糕的上级）：
"8:59分到工位 → 9:00打开电脑 →
9:01登录邮箱 → 先看未读邮件 →
按时间顺序处理……"
→ 新员工遇到网络慢、邮箱登不上，立刻懵了
适度指导（好的上级）：
"每天上午优先处理紧急邮件，
下午专注项目执行，
遇到跨部门的事先跟我确认。"
→ 新员工理解了优先级和边界，
细节自己判断，反而能独立工作
💡 好的 Skill 像一个"负责任的上级"：给清楚目标，划清边界，但不微观管理每一个动作。这样 Agent 遇到边界情况时，能灵活处理而不是卡死。
6.5 原则四：目的要具体，不要抽象
❌ 不好的写法：
"帮我整理信息"
✅ 好的写法：
"当用户发来一段会议记录时，提取：
① 待办事项（谁负责、截止日期）
② 关键决策（是什么、谁决定的）
③ 下次会议时间
输出格式：表格"
原则：越具体，AI 越不会"自由发挥"。
6.6 原则五：步骤要有顺序，有判断
好的流程型 Skill 长这样：
Step 1. 先确认用户需求（不要直接就做）
Step 2. 如果信息不完整 → 追问补全
Step 3. 执行主要任务
Step 4. 输出结果前 → 自检（是否符合要求）
Step 5. 给用户呈现，并询问是否需要调整
原则：让 AI 像一个认真的人，而不是一个莽撞的执行机器。
6.7 原则六：划定边界，告诉 AI 什么不能做
❌ 没有边界的 Skill：
AI 可能越界、乱猜、做你不想让它做的事
✅ 有边界的 Skill：
"只处理本部门数据，跨部门数据不查"
"不确定时先问用户，不要猜测"
"涉及金额超过1000元的操作，必须人工确认"
原则：给 AI 划红线，比教它做什么更重要。
6.8 写 Skill 的三步法
第一步：想清楚"这个技能是干嘛的"
┌──────────────────────────────┐
│ 帮我每天早上9点 │
│ 汇总昨日数据 + 发到群里 │
└──────────────────────────────┘
第二步：描述"触发条件和步骤"
┌──────────────────────────────┐
│ 触发：每天 09:00 │
│ 步骤： │
│ 1. 登录数据系统查昨日数据 │
│ 2. 按模板格式整理 │
│ 3. 发送到运营群 │
└──────────────────────────────┘
第三步：加上"注意事项和边界"
┌──────────────────────────────┐
│ · 数据异常时先@我确认 │
│ · 周末不执行 │
│ · 发送前先预览 │
└──────────────────────────────┘
6.9 最容易上手的三种方式
- 从现成的 Skill 改：找个最接近你需求的，调整描述和流程，成本最低
- 跟 AI 对话来写：直接告诉 AI "帮我写一个 Skill，功能是……"，让它起草，你来审
- 用 Skill Creator：专门帮你写 Skill 的 Skill（套娃但好用，输入需求，自动生成）
💡 小技巧：先用自然语言描述你的需求，哪怕只是一句话，AI 通常能帮你把它变成 Skill 草稿。你只需要判断"对不对"，而不是"从零写"。
七、常见误区（1分钟快速扫）
7.1 使用误区（非技术向）
误区 ① "Skill 越长越好"
真相 ： 简洁清晰 > 面面俱到，太长 AI 反而抓不住重点
建议：一个 Skill 只干一件事
误区 ② "写一次就永久好用"
真相 ： Skill 需要迭代，用一次就优化一次，越用越好用
建议：用完记录"哪里不对劲"，下次改掉
误区 ③ "不会编程就写不了"
真相 ： 会写 SOP 就会写 Skill，逻辑比语法重要
建议：先用中文写，AI 帮你翻译成标准格式
误区 ④ "AI 理解你的意思就行，不用写细"
真相 ： 越具体越好用，模糊描述 = 模糊结果 = 你再改一遍
建议：把你觉得"理所当然"的步骤也写出来
误区 ⑤ "Skill 是技术部门的事"
真相 ： 业务人员最懂自己的流程，你才是最合适的作者
建议：技术同学帮你接系统，业务逻辑你来写
误区 ⑥ "用 AI 就应该什么都会，不需要 Skill"
真相 ： 没有 Skill 的 AI 就像没有说明书的工厂机器
能动，但不知道做什么、怎么做你这里的活
7.2 【进阶】SKILL.md 的三大写法陷阱
这部分给已经开始动手写 Skill 的人看，写出来能用是第一步，写对才是关键：
误区一：触发条件写在 SKILL.md 正文里
❌ SKILL.md 里写：
"当用户说'帮我预约会议室'时，使用本 Skill 处理……"
看起来没问题，但其实是无效的——
Agent 的工作顺序是：
先扫 description → 决定用不用这个 Skill
然后才加载 SKILL.md 正文
触发条件写在 SKILL.md 里，Agent 在"要不要用"
的决策阶段压根还没看到这个文件。
等它看到时，已经决定进来了，这句话就成了废话。
✅ 正确做法：
触发条件 → 写进 description 字段（安装/注册 Skill 时填的那里）
SKILL.md 正文 → 只写"怎么做"，不写"什么时候用"
误区二：把大量参考细节堆进 SKILL.md 正文
❌ SKILL.md 里写：
"参考文档详见：http://internal.wiki/api/v2/order
接口字段说明如下：
- order_id: 订单ID，类型 string，必填，格式 MT-XXXXXX
- status_code: 状态码，枚举值，0=待付款 1=已付款 2=已发货…
- logistics_company: 物流公司名称，string，可选字段
- created_at: 创建时间，Unix timestamp，单位秒
……（此处省略30行字段说明）"
→ SKILL.md 主干被细节淹没
→ Agent 读到一半就"分心"了，抓不住核心流程
✅ 正确做法：
核心流程写在 SKILL.md 主体
细节参考单独放进 references/ 目录下的文件：
references/
└── api-spec.md ← 接口文档、字段说明、枚举值……
SKILL.md 里只写一行引用提示即可：
"接口细节见 references/api-spec.md"
→ 主干清晰，Agent 按需加载细节，两者不互相干扰
误区三：用文字逐步描述"确定性操作"
这是最容易出问题的一类误区，也最难意识到。
❌ 用文字描述界面操作流程：
"先打开浏览器访问 http://oms.internal，
在登录框输入工号和密码，点击'登录'按钮，
等待页面跳转，找到左侧菜单中的'订单管理'，
点击展开，再点击'查询订单'，在搜索框输入
订单号，点击'搜索'按钮……"
问题一：AI 理解"点击"很模糊，
不同页面结构可能会点错地方
问题二：界面一旦改版，整个步骤描述就失效了
问题三：AI 执行时存在解读偏差，
结果不稳定，难以排查
✅ 封装成脚本或工具调用：
对流程固定、无歧义的操作，让技术同学封装好：
## 工具
使用 oms-query 工具：
输入：order_id（格式 MT-XXXXXX）
输出：订单状态、物流信息、预计到货时间
Skill 只管"做什么"（查订单），
不管"怎么点"（登录、找菜单、填表单）
→ 稳定、可维护、不怕页面改版
一句话总结这三条：
┌─────────────────────────────────────────────────────┐
│ │
│ 触发条件 → 写进 description（不是 SKILL.md 里） │
│ 参考细节 → 放进 References 区块（不是主流程里） │
│ 固定操作 → 封装成脚本/工具（不是文字步骤描述） │
│ │
│ 三层分工清晰，Skill 才能又准又稳、好维护 │
│ │
└─────────────────────────────────────────────────────┘
八、给非技术人员的行动建议（1分钟）
不要想"我要系统学 AI"，那太重了。先从一件具体的事开始：
本周就能做的三件事：
Day 1 ──→ 装一个 Skill 广场里的现成 Skill 用用
感受下"有 Skill"和"没 Skill"的区别
Day 2 ──→ 找一个你最烦的重复性工作，用自然语言
写下它的步骤（这就是 Skill 的草稿）
Day 3 ──→ 把草稿发给 AI，让它帮你格式化成 Skill
然后装上，跑一次，看看效果
九、Q&A 引导话术
准备几个高频问题的答案：
"我们的数据安全吗？"
Skill 只是流程说明，数据权限由系统层面控制。AI 能访问什么，取决于你给它开放了什么权限，不是 Skill 本身决定的。公司 Skill 广场的 Skill 都经过安全审核。
"Skill 出错怎么办？"
好的 Skill 设计会在关键步骤让你确认，不会闷头就做。出错了，你修改 Skill 描述，下次就会改进。这就是迭代。
"我不知道从哪开始"
找一个你每周重复做3次以上的事，那就是第一个 Skill 的候选。
"我的需求太特殊，Skill 广场肯定没有"
先搜一下，通常都有接近的。没有的话，让 AI 帮你写一个，比你想象的容易得多。
"我不会写，能让别人帮我写吗？"
可以！你口头描述业务流程，技术同学或 AI 帮你落成 Skill。你负责验收"对不对"，他们负责格式和接入。
📌 一张带走的总结卡
┌────────────────────────────────────────────────────────┐
│ 记住这两句话就够了 │
│ │
│ Skill = 给 AI 的 SOP 手册 │
│ │
│ 你写 SOP 的能力 = 你用 AI 的能力 │
│ │
├────────────────────────────────────────────────────────┤
│ 四种 Skill 模式 │
│ │
│ 📝 指令型 → 设风格规则（最简单，先从这个开始） │
│ 📋 流程型 → 定操作步骤（有SOP的任务首选） │
│ 📚 知识库型 → 沉淀团队知识（FAQ/政策问答） │
│ 🤖 自动化型 → 接系统干活（效果最强，逐步升级） │
├────────────────────────────────────────────────────────┤
│ 写好 Skill 的六条原则 │
│ │
│ 1. description 是触发器，写激活条件不是功能描述 │
│ 2. 不陈述废话，只写 AI 不知道的业务特有信息 │
│ 3. 不过度约束，给目标和边界，留判断空间 │
│ 4. 目的具体，越具体 AI 越不会自由发挥 │
│ 5. 步骤有顺序，有判断（含异常处理） │
│ 6. 划红线——不做什么，至少和做什么一样重要 │
├────────────────────────────────────────────────────────┤
│ 今天就能开始的第一步 │
│ │
│ "帮我每天/每周自动做______" │
│ 把这句话填完，你的第一个 Skill 草稿就有了 │
└────────────────────────────────────────────────────────┘
讲义版本：v2.6 · 2026-03-25 · 张天师整理
