Agent Skills 介绍与最佳实践：把经验变成可复用工作流
#博客更新
结论先说
如果你已经在反复做同一类任务（比如固定格式写作、发布流程、资料调研、社区巡检），最值得做的不是继续“临场发挥”，而是把它封装成 Skill。
我现在默认用这套判断：
● 重复 3 次以上的任务，开始考虑做 Skill
● 涉及多步骤、多依赖、多边界（比如外部发布）的任务，优先做 Skill
● 需要长期维护一致输出质量的任务，必须做 Skill
真正关键的不是“让 Agent 更聪明”，而是让流程更稳定、可检查、可迭代。
----------------------
什么是 Skill（以及它不是什么）
在各种 Agent 系统里，Skill 本质上是“面向任务的标准作业包”，通常包含：
1.
2.
3.
它不是“写一段提示词就完事”。
Skill 的价值在于：把人脑里的隐性经验，变成显性、可复用、可审计的流程。
----------------------
什么时候应该做 Skill
建议用这个快速判断表：
----------------------
一个好 Skill 的结构模板
下面这个结构我在项目里反复验证过，够实用：
1. Overview：这个 Skill 解决什么问题
2. Decision Tree：用户不同诉求如何分支处理
3. Execute：每个阶段的操作步骤
4. Quality Gate：交付前必须通过的检查项
5. Safety：哪些动作要确认、哪些不能自动做
6. Examples：至少 1 组可复制执行示例
----------------------
最佳实践 1：把触发条件写具体
很多 Skill 用不好，不是能力不够，而是触发条件太模糊。
反例
● “当用户提到文档时使用”
正例
● “当用户提到 Feishu docx 链接、云文档写入、批量追加文档内容时使用”
触发条件越清晰，路由越稳定，误触发越少。
----------------------
最佳实践 2：先决策再执行，不要边跑边想
在
● 新建文章 -> 创建新文件 -> 写作 -> 封面 -> 发布
● 改稿 -> 编辑现有文件 -> 保留 frontmatter -> 可选重做封面
● 只改封面 -> 不动正文 -> 仅更新
这样做的好处是：
● 输出路径可预测
● 复盘时能快速定位在哪个分支出问题
● 新需求可以挂在现有分支上增量迭代
----------------------
最佳实践 3：把“可执行片段”写进文档
我一般会要求每个 Skill 至少包含：
● 1 段可执行命令（或脚本调用）
● 1 段配置示例（如 YAML）
● 1 段风险提示与回滚建议
示例（YAML 配置片段）：
----------------------
最佳实践 4：质量门禁要量化
不要只写“检查一下有没有问题”，要写成可验证条目。
推荐最小门禁清单：
● [ ] 必填字段完整（如 frontmatter）
● [ ] 关键链接可访问（HTTP 200）
● [ ] 构建通过（无报错）
● [ ] 变更文件清单清晰
● [ ] 交付信息完整（包含路径、哈希、下一步建议）
有门禁，才有“稳定复现”。
----------------------
最佳实践 5：把坑写进 references，而不是写进脑子
很多团队会反复掉进同一个坑：
● 环境变量名写错
● 文件路径约定不一致
● 发布前漏 build
● 图片格式和尺寸不统一
我的做法是：每次踩坑后，立刻补一条 reference 规则。这不是文档洁癖，是在降低未来沟通成本。
----------------------
常见反模式（建议避开）
1. 大而全 Skill：一个 Skill 包所有任务，最后谁都不敢改
2. 流程无边界：读写发布都自动执行，缺少确认点
3. 只有步骤没有判定：看起来很完整，实际执行时频繁卡住
4. 没有版本意识：更新后不记录变化，回归问题难定位
----------------------
我现在的默认落地流程
如果你想在一周内把 Skill 真正用起来，可以按这个节奏推进：
1. 先选一个高频任务做 MVP Skill（不要超过 1 条主链路）
2. 跑 3 次真实任务，记录失败点
3. 补齐
4. 再决定是否加脚本自动化
5. 最后才考虑扩展到第二个相邻任务
这不是追新，是为了降低后续维护成本。
----------------------
结尾建议
如果你现在还在“每次都从头讲需求、从头试命令”，那就已经到了该做 Skill 的阶段。建议从你最常做、最容易返工的一条流程开始，把它写成可复用模板。
先把一个 Skill 做稳，再谈规模化。
via 棒无
#博客更新
结论先说
如果你已经在反复做同一类任务（比如固定格式写作、发布流程、资料调研、社区巡检），最值得做的不是继续“临场发挥”，而是把它封装成 Skill。
我现在默认用这套判断：
● 重复 3 次以上的任务，开始考虑做 Skill
● 涉及多步骤、多依赖、多边界（比如外部发布）的任务，优先做 Skill
● 需要长期维护一致输出质量的任务，必须做 Skill
真正关键的不是“让 Agent 更聪明”，而是让流程更稳定、可检查、可迭代。
----------------------
什么是 Skill（以及它不是什么）
在各种 Agent 系统里，Skill 本质上是“面向任务的标准作业包”，通常包含：
1.
SKILL.md：入口说明、适用场景、决策树、执行步骤2.
references/*.md：风格规范、规则细节、发布手册3.
scripts/*：需要脚本化的步骤（可选）它不是“写一段提示词就完事”。
Skill 的价值在于：把人脑里的隐性经验，变成显性、可复用、可审计的流程。
----------------------
什么时候应该做 Skill
建议用这个快速判断表：
[!NOTE] 不要一把梭。先把最常做、最容易出错的一条链路封装好，再扩展。
----------------------
一个好 Skill 的结构模板
下面这个结构我在项目里反复验证过，够实用：
skills/
your-skill/
SKILL.md
references/
style-profile.md
rules.md
runbook.md
scripts/
pipeline.py
SKILL.md 建议固定包含这 6 部分：1. Overview：这个 Skill 解决什么问题
2. Decision Tree：用户不同诉求如何分支处理
3. Execute：每个阶段的操作步骤
4. Quality Gate：交付前必须通过的检查项
5. Safety：哪些动作要确认、哪些不能自动做
6. Examples：至少 1 组可复制执行示例
----------------------
最佳实践 1：把触发条件写具体
很多 Skill 用不好，不是能力不够，而是触发条件太模糊。
反例
● “当用户提到文档时使用”
正例
● “当用户提到 Feishu docx 链接、云文档写入、批量追加文档内容时使用”
触发条件越清晰，路由越稳定，误触发越少。
----------------------
最佳实践 2：先决策再执行，不要边跑边想
在
SKILL.md 里给出明确决策树，例如：● 新建文章 -> 创建新文件 -> 写作 -> 封面 -> 发布
● 改稿 -> 编辑现有文件 -> 保留 frontmatter -> 可选重做封面
● 只改封面 -> 不动正文 -> 仅更新
image 字段这样做的好处是：
● 输出路径可预测
● 复盘时能快速定位在哪个分支出问题
● 新需求可以挂在现有分支上增量迭代
----------------------
最佳实践 3：把“可执行片段”写进文档
我一般会要求每个 Skill 至少包含：
● 1 段可执行命令（或脚本调用）
● 1 段配置示例（如 YAML）
● 1 段风险提示与回滚建议
示例（YAML 配置片段）：
workflow:
name: blog-pipeline
stages:
- write
- cover
- upload
- verify
safety:
require_confirm_for:
- publish
- delete
[!WARNING] 涉及外部发布（推送、发帖、对外消息）时，不要默认自动执行。建议显式确认后再做最后一步。
----------------------
最佳实践 4：质量门禁要量化
不要只写“检查一下有没有问题”，要写成可验证条目。
推荐最小门禁清单：
● [ ] 必填字段完整（如 frontmatter）
● [ ] 关键链接可访问（HTTP 200）
● [ ] 构建通过（无报错）
● [ ] 变更文件清单清晰
● [ ] 交付信息完整（包含路径、哈希、下一步建议）
有门禁，才有“稳定复现”。
----------------------
最佳实践 5：把坑写进 references，而不是写进脑子
很多团队会反复掉进同一个坑：
● 环境变量名写错
● 文件路径约定不一致
● 发布前漏 build
● 图片格式和尺寸不统一
我的做法是：每次踩坑后，立刻补一条 reference 规则。这不是文档洁癖，是在降低未来沟通成本。
----------------------
常见反模式（建议避开）
1. 大而全 Skill：一个 Skill 包所有任务，最后谁都不敢改
2. 流程无边界：读写发布都自动执行，缺少确认点
3. 只有步骤没有判定：看起来很完整，实际执行时频繁卡住
4. 没有版本意识：更新后不记录变化，回归问题难定位
----------------------
我现在的默认落地流程
如果你想在一周内把 Skill 真正用起来，可以按这个节奏推进：
1. 先选一个高频任务做 MVP Skill（不要超过 1 条主链路）
2. 跑 3 次真实任务，记录失败点
3. 补齐
references 和 Quality Gate4. 再决定是否加脚本自动化
5. 最后才考虑扩展到第二个相邻任务
这不是追新，是为了降低后续维护成本。
----------------------
结尾建议
如果你现在还在“每次都从头讲需求、从头试命令”，那就已经到了该做 Skill 的阶段。建议从你最常做、最容易返工的一条流程开始，把它写成可复用模板。
先把一个 Skill 做稳，再谈规模化。
via 棒无
