title: “Skill 怎么设计：先判断值不值得写，再谈怎么写好” description: “最近 skill 很火，但很多分享更多只是传播广，真到落地时未必能有效满足需求。比起先背模式名，我更想讲的是：什么事情值得做成 skill，一个好 skill 到底该怎么写、怎么拆、怎么迭代。” date: 2026-03-28 20:10:00 +08:00 updated: 2026-03-28 20:10:00 +08:00 permalink: /2026/03/28/skill-zen-me-she-ji-xian-pan-duan-zhi-bu-zhi-de-xie-zai-tan-zen-me-xie-hao/ tags:

  • “工程治理”
  • “AI开发”
  • “Agent工程”
  • “Prompt工程”
  • “工作流设计”
  • “设计方法” series: “工程治理体系” series_buildable: true series_part: 23 series_intent: “围绕架构演进、工程规范、流程门禁与长期维护成本，整理一套可持续的工程治理方法。” draft: false published: true related_auto: false —

最近 skill 很火。

我也看到了非常多 skill 分享，但我感觉：很多 skill 的质量，很多时候只是传播广而已。名字看着很高级，文档也写得很满，可一到真实落地里，往往并不能有效满足需求。

有些 skill 看起来什么都考虑到了，结果根本触发不准。有些一上来就写得特别重，最后执行起来反而飘。还有一些，本质上只是把一篇理念文档换成了 SKILL.md 的格式，真跑任务的时候还是没有抓手。

这也让我想聊一件事：如果真想把 skill 写好，

先别急着写，先判断它值不值得做成 skill

这一段我只想压成一个判断：不是所有事情都值得做成 skill。

我现在主要看四件事：

  • 它是不是会反复出现。
  • 它的失败点是不是稳定。
  • 它有没有独立触发面。
  • 它值不值得长期维护。

这里面只要有两三项站不住，我一般就不会急着写。尤其是那种模型本来就擅长的通用知识、一次性脑暴，或者完全靠想象设计、但没在真实场景里落过地的东西，硬做成 skill 很容易只剩形式感。

真正一个好的 skill，核心在这几层

第一层是描述信息

这一层最核心的点，其实就是：什么时候触发。

现在很多 AI 工具在这一层已经做得不错了，但描述信息还是不能随便写。因为 skill 后面再复杂，触发错了，前面全白做。

所以我现在会把这层看得很直接：它到底能不能把该来的请求接进来，把不该来的挡在外面。

第二层是控制层

我觉得 skill 主体真正的重点都在这一层。

这一层我通常会围绕几个工作点去写：

  • 这次任务到底要完成什么目标。
  • 什么条件算门禁。
  • 输出要长成什么样。
  • 哪些事情不要做。
  • 什么时候该退出。

这里有一个我现在越来越坚持的原则：尽量写精确动作，不要只写原则。

像“注意上下文”“保持专业”“关注用户目标”这种话，它当然没有错，但它不具备执行性。真正稳的写法，是先干嘛，再干嘛，条件不到就不要做下一步。它更像函数，而不是口号。

skill 到了这一步，才开始真的能跑。

第三层是资产层

这一层我会尽量让它轻。

SKILL.md 本身最好只放最关键的控制信息，不要把所有边界、风格和资料都往里堆。更好的方式，还是做渐进式披露。

简单说就是：

  • 主文件放核心流程。
  • 引用文件放长规则和边界说明。
  • 资产文件放模板和固定骨架。
  • 脚本文件放确定性动作。

这里我想单独说一句，脚本真的很重要。

因为很多不确定的东西，最后都可以通过脚本去收敛成确定性输出。你一直靠自然语言提醒模型“注意这个、别漏那个”，它还是会飘。但如果这一步本来就已经能脚本化，那交给脚本会稳很多。

而 references/ 这种地方，更适合承载风格说明、边界说明、长 checklist。这一层的价值，本质上是把上下文做轻，不让模型变成“读了很多，但真正执行时抓不到重点”。

第四层是验证层

我一直认为：skill 最标准的形成方式，不是直接坐在那儿输出一份文档。

更真实的过程，往往是你在跟大模型不断交互的过程中，一次次发现它不按你要求做，慢慢把那些反例、失败面、误触发点收出来，最后再沉成 skill。

所以 skill 本质上就是一个迭代过程。

它不是你某天灵光一闪写出来，然后就永远不动了。它应该是你不断修正、不断补边界、不断让它更贴近真实任务的产物。只有这样，最后出来的东西才真有用。

skill 不要写得太重

第二个我特别想说的点，是 skill 尽量不要做得过于复杂。

很多人会觉得，规则越全，skill 越强。可真实情况经常不是这样。你写得越重，最后越容易飘；你写得越满，最后越可能把结果收敛到一种很同质化、很僵硬的地步。

这也是为什么我现在会更倾向于先做最小可用，而不是一开始就追求“大而全”。

skill 真正要解决的是稳定问题，不是展示你考虑得多全。过重的 skill，经常最后变成了另一个问题源。

skill 的拆和合，本质上像在定义函数

很多时候我们想做一件事情，脑子里其实是很多步骤混在一起的。这时候 skill 最容易犯的错误，就是想一次把所有事情全包进去。

但 skill 更像函数。一个工作流，最好先只做一件事。

那怎么拆？

我现在通常会看这几个条件：

  • 触发意图是不是不同。
  • 默认工作流是不是不一样。
  • 依赖的脚本和资产是不是完全不一样。
  • 输出契约差异是不是很大。

如果这些都明显不同，那就该拆。

那什么时候该合？

也很简单：

  • 触发本来就是同一类请求。
  • 任务只是名字不一样，流程其实没变。
  • 依赖的资产高度重合。
  • 强拆之后反而让触发更分散。

所以 skill 的拆和合，主要不是看主题本身像不像，而是看控制面和资产面是不是同一套。

我自己常用的几种设计思路

第一类，是补知识的

有些 skill 的重点，其实不是流程，而是把某一类专门知识在需要的时候补进来。

比如：

  • 某个框架的约束
  • 某套内部规范
  • 某个领域的固定知识

这种 skill 最怕的，不是信息不够，而是写成资料堆。真正要紧的是：什么时候该加载，加载以后拿它干什么。

第二类，是把输出结构定住的

这类 skill 的重点不是知识本身，而是让产物更稳定。

比如：

  • 文档
  • 报告
  • PRD
  • 审稿结果

这种场景的核心，不是讲很多原则，而是先把模板、字段和骨架定住，避免每次都写成另一种东西。

第三类，是做门禁和检查面的

还有一类 skill，它不是为了生成，而是为了检查。

比如：

  • 代码审查
  • 发布门禁
  • 安全门禁
  • 内容质量检查

这类 skill 最关键的，不是优美表达，而是检查项有没有分层，轻重缓急有没有拉开。不然 checklist 一长，很快又会退化成“什么都查，什么都不准”。

第四类，是帮你把问题问清楚的

有些 skill 最大的价值，就是让模型先停下来，不要急着往下做。

比如：

  • 需求访谈
  • 项目规划
  • 范围澄清

这类 skill 的重点，是强制模型先问，再做。它控制的不是输出格式，而是理解时机。

如果一定要再补一个通用角度，我会觉得有些 skill 本质上是在卡顺序，比如构建、发布、逐步确认这种流程。它跟门禁类很像，只是更强调阶段不能跳。

真正让 skill 有价值的，很多时候不是技术名词，而是失败面

说到底，我觉得，skill 最值钱的地方，很多时候根本不是你给它起了什么名字。

真正让 skill 有价值的，往往是你有没有把最容易翻车的点写进去。

比如：

  • 它最容易越权的地方在哪里。
  • 它最容易提前下结论的地方在哪里。
  • 它最容易漏掉哪道门禁。
  • 它最容易把哪一步做重。

这些东西，比空讲理念重要得多。

所以我现在会特别强调一件事：很多时候，skill 正面的流程其实已经够了，真正缺的是负向约束。不要做什么，很多时候比要做什么更关键。

最后说几个常见坑

最后我想收在几个最常见的坑上。

第一个坑，是整篇都在解释理论，却没有把触发、工作流、反模式和输出讲清楚。

第二个坑，是只写“怎么做”，不写“什么时候别做”。这个看起来像小事，实际上很重要。很多 skill 真正的问题，就出在这里。

第三个坑，是一上来就想做一个又大又全的 skill。最后结果通常不是更强，而是更飘。

第四个坑，是没有验证。没有真实基线，也没有固定回归，你最后很难判断这个 skill 到底是更稳了，还是只是写得更长了。

# skill 这个概念确实还很新，但真正高价值的地方其实没那么玄。先判断值不值得写，再把触发、控制、资产、验证这几层收好，最后再去谈拆分和设计思路，事情就会顺很多。反过来，如果这些地方没想清楚，名字起得再高级，最后大概率还是那个结果：看着挺像回事，真用起来也就那样。