结论先说#

如果你已经在反复做同一类任务（比如固定格式写作、发布流程、资料调研、社区巡检），最值得做的不是继续“临场发挥”，而是把它封装成 Skill。

我现在默认用这套判断：

• 重复 3 次以上的任务，开始考虑做 Skill
• 涉及多步骤、多依赖、多边界（比如外部发布）的任务，优先做 Skill
• 需要长期维护一致输出质量的任务，必须做 Skill

真正关键的不是“让 Agent 更聪明”，而是让流程更稳定、可检查、可迭代。

什么是 Skill（以及它不是什么）#

在各种 Agent 系统里，Skill 本质上是“面向任务的标准作业包”，通常包含：

1. SKILL.md：入口说明、适用场景、决策树、执行步骤
2. references/*.md：风格规范、规则细节、发布手册
3. scripts/*：需要脚本化的步骤（可选）

它不是“写一段提示词就完事”。

Skill 的价值在于：把人脑里的隐性经验，变成显性、可复用、可审计的流程。

什么时候应该做 Skill#

建议用这个快速判断表：

NOTE

不要一把梭。先把最常做、最容易出错的一条链路封装好，再扩展。

一个好 Skill 的结构模板#

下面这个结构我在项目里反复验证过，够实用：

1
skills/
2
  your-skill/
3
    SKILL.md
4
    references/
5
      style-profile.md
6
      rules.md
7
      runbook.md
8
    scripts/
9
      pipeline.py

SKILL.md 建议固定包含这 6 部分：

1. Overview：这个 Skill 解决什么问题
2. Decision Tree：用户不同诉求如何分支处理
3. Execute：每个阶段的操作步骤
4. Quality Gate：交付前必须通过的检查项
5. Safety：哪些动作要确认、哪些不能自动做
6. Examples：至少 1 组可复制执行示例

最佳实践 1：把触发条件写具体#

很多 Skill 用不好，不是能力不够，而是触发条件太模糊。

最佳实践 2：先决策再执行，不要边跑边想#

在 SKILL.md 里给出明确决策树，例如：

• 新建文章 -> 创建新文件 -> 写作 -> 封面 -> 发布
• 改稿 -> 编辑现有文件 -> 保留 frontmatter -> 可选重做封面
• 只改封面 -> 不动正文 -> 仅更新 image 字段

这样做的好处是：

• 输出路径可预测
• 复盘时能快速定位在哪个分支出问题
• 新需求可以挂在现有分支上增量迭代

最佳实践 3：把“可执行片段”写进文档#

我一般会要求每个 Skill 至少包含：

• 1 段可执行命令（或脚本调用）
• 1 段配置示例（如 YAML）
• 1 段风险提示与回滚建议

示例（YAML 配置片段）：

1
workflow:
2
  name: blog-pipeline
3
  stages:
4
    - write
5
    - cover
6
    - upload
7
    - verify
8
  safety:
9
    require_confirm_for:
10
      - publish
11
      - 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 Gate
4. 再决定是否加脚本自动化
5. 最后才考虑扩展到第二个相邻任务

这不是追新，是为了降低后续维护成本。

结尾建议#

如果你现在还在“每次都从头讲需求、从头试命令”，那就已经到了该做 Skill 的阶段。建议从你最常做、最容易返工的一条流程开始，把它写成可复用模板。

先把一个 Skill 做稳，再谈规模化。