结论先说#

如果一类任务你已经反复做了几次，那最值得优化的通常不是继续临场发挥，而是把它沉淀成 Skill。

我现在判断要不要做 Skill，基本看这 3 个信号：

• 同类任务重复了 3 次以上
• 任务本身是多步骤、多依赖、多边界的串联流程
• 你希望它长期保持稳定输出，而不是每次都看发挥

说得直接一点，Skill 的价值不在“让 Agent 更像人”，而在把一次性的经验，变成能复用的工作流。

Skill 到底是什么#

在大多数 Agent 系统里，Skill 本质上都不是一句 prompt，而是一套围绕具体任务组织起来的标准作业包。

常见结构一般包含这些东西：

1. SKILL.md：入口说明、适用场景、决策树、执行步骤
2. references/*.md：规则细节、风格约束、操作手册
3. scripts/*：适合脚本化的步骤

我会把它理解成：

把人脑里的隐性经验，整理成显性、可复用、可审计的流程。

这件事看起来像文档整理，但真用起来差别很大。因为没有 Skill 时，很多任务都依赖“我大概记得该怎么做”；一旦换人、隔几天再做，或者需求有点变化，细节就容易漂掉。

什么情况下值得单独做一个 Skill#

不是所有事情都要封装。封装本身也有成本，所以我一般会先判断它值不值。

NOTE

不要一开始就想做大而全。先把最常做、最容易出错的一条链路封装好，收益通常最高。

我自己比较常见的一个感受是：写作、发文、资料整理、社区巡检这类任务，最消耗人的不是某一步本身，而是每次都要重新想“顺序是什么、边界是什么、哪些地方不能自动做”。这正是 Skill 最该接手的部分。

一个好 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：至少给一组可复制的示例

我不太建议把 Skill 写成大段说明文。真正好用的 Skill，一定是“遇到任务时能直接顺着走下去”，而不是读完觉得很懂，执行时还是得临场判断一大堆。

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

很多 Skill 之所以不好用，不是内容不够，而是入口太模糊。

比如下面这种写法就很容易误触发：

• 当用户提到文档时使用

更稳的写法应该是：

• 当用户提到 Feishu docx 链接、云文档写入、批量追加文档内容时使用

差别看起来只是更具体了一点，但实际效果会稳定很多。因为你把“什么时候该用”描述清楚后，路由准确率会高，后面也更容易维护。

最佳实践 2：先决策，再执行#

这是我很在意的一点。

很多 Skill 写得像流水账：第一步做什么，第二步做什么，第三步做什么。但真正执行时，经常不是缺步骤，而是缺判断。任务一旦出现分支，整条链路就开始卡。

所以我更建议先把决策树写清楚，比如：

• 新建文章 → 创建新文件 → 写作 → 封面 → 发布
• 改稿 → 编辑现有文件 → 保留 frontmatter → 视情况重做封面
• 只改封面 → 不动正文 → 只更新 image

这样做的好处很直接：

• 执行路径更可预测
• 出问题时更容易定位是哪个分支没写全
• 新需求也更容易挂到现有结构上继续长

我自己在做博客流程时，就很吃这个结构红利。因为“新写一篇”“重写旧文”“只换封面”看起来都是发文，但处理逻辑其实完全不一样。如果不先决策，执行阶段就会一路补判断，最后很乱。

最佳实践 3：把可执行片段直接写进 Skill#

如果一份 Skill 只有概念，没有可执行片段，最后大概率还是会退回“凭印象做”。

所以我现在一般会要求每个 Skill 至少有这 3 类内容：

• 一段可执行命令，或者脚本调用示例
• 一段配置样例，比如 YAML / JSON
• 一段风险提示和回滚建议

例如：

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

这类片段的意义不是“好看”，而是让 Skill 真正具备可复制性。你隔一周回来看，或者换一个人接手，都能快速知道该怎么落地。

WARNING

只要涉及外部发布、推送、公开发言这类动作，我都不建议默认自动执行。最后一步最好显式确认，不然边界很容易失手。

最佳实践 4：质量门禁要写成可检查的条目#

“检查一下有没有问题”这种话，基本没有执行价值。

我现在更倾向把质量门禁写成最小 checklist，例如：

• 必填字段完整，比如 frontmatter
• 关键链接可访问
• 构建通过，没有报错
• 变更文件清单清晰
• 交付信息完整，包含路径、哈希和下一步建议

你会发现，一旦门禁写成这样，很多“交付看着差不多，但总觉得不稳”的问题会少很多。因为它不再依赖主观感觉，而是有明确的完成标准。

最佳实践 5：坑不要只记在脑子里#

很多团队在自动化这件事上反复踩同一个坑，本质上是因为经验没有沉淀。

常见的坑其实都很具体：

• 环境变量名写错
• 路径约定不一致
• 发布前忘了 build
• 图片格式、尺寸、命名规则不统一

我的做法很简单：踩一次坑，就补一条 reference。

这不是文档洁癖，而是为了减少未来重复沟通。因为一旦坑只存在于个人记忆里，下一次它几乎一定还会再来。

这些反模式我会尽量避开#

如果要反过来说，下面几种 Skill 设计方式我一般不太建议：

1. 大而全 Skill：一个 Skill 想包所有任务，最后谁都不敢动
2. 流程无边界：从读取到发布全自动，完全没有确认点
3. 只有步骤没有判定：写起来很完整，真正执行时频繁卡住
4. 没有版本意识：Skill 更新了，但没记录变更，回归问题很难排查

这些问题最麻烦的地方在于，前期不一定立刻爆，往往是你开始依赖它之后，维护成本突然上来。

如果你想一周内把 Skill 真用起来，我建议这样落地#

我现在更倾向一个很朴素的推进顺序：

1. 先挑一个高频任务做 MVP Skill，不要超过 1 条主链路
2. 用真实任务跑 3 次，把失败点记下来
3. 根据失败点补 references 和 Quality Gate
4. 再决定哪些步骤值得脚本化
5. 最后再扩到第二条相邻任务

这个顺序的好处是，你做出来的 Skill 通常不是纸面方案，而是真的能跑的东西。

最后的建议#

如果你现在还是每次都从头描述需求、从头试命令、从头补边界，那其实已经说明这个流程适合做成 Skill 了。

我的建议一直很简单：先从你最常做、最容易返工的一条流程开始。

先把一个 Skill 做稳，再谈规模化。只要第一条链路跑顺了，后面很多事都会自然变轻。