什么是skill？
本文假设读者已经了解skill的具体定义，不再赘述。
简单地说，skill的主体是markdown文件（SKILL.md，带有frontmatter），可选地包含任意种类的文件（一般是辅助脚本、文档）等。agent根据skill description决定是否读取skill的 SKILL.md ，如果读取，则会按照其中的instruction执行。
一般而言，skill会为模型提供新的知识或指令，让agent按照指令完成任务，看起来就好像它“拥有了某种新的技能”。从实用角度来说，把skill理解成“给agent的SOP”比较贴切。
什么样的skill值得写？
如果你想写出持久有效的、跨模型通用的、主要用于前沿模型 1 的skill，我的观点是，满足下面任何一点就可以认为这个skill值得写：
- 为独属于你的任务撰写skill；
- 能在skill中写出独属于你的观点或视角，而不是总结为机械的流程。
这里的“独属于你”指的是“不存在于公共领域的、不存在于LLM训练数据中的”。
下面是我这么认为的原因。
skill在初期是作为agent能力的扩展出现的，让agent能够完成训练时未见的任务。 skill出现后不久，由于它本身容易分享、使用门槛低，因此出现了另一种skill的用法，通过skill让agent“更好地完成某个常见任务”。 这类skill大多是由某领域内的专家总结、撰写的，将他的理解固化为skill，供agent效仿，随后分享给普通的用户。 这个时期，agent的能力相对弱，难以完成复杂任务，通过这类skill可以固化工作流、“拷贝”大佬的工作流，从而增强agent的能力。
例如，给agent设计复杂的软件开发工作流，强制它按照“调研、规划、并行执行(wave)、总结”这样的顺序执行软件开发任务，有的skill还会严格规定每个阶段的结构化产出，确保agent遵守流程。 这是这个时候的主流skill。
gsd,openspec等都属于这类。
这类skill的火热并没有持续多久，LLM能力的进步覆盖了这类skill提供的额外能力，甚至最终使得这类skill变为LLM高效完成任务的阻碍。
一个自然的问题是“什么样的skill会被LLM的能力进步覆盖”，显然“能通过训练被LLM获得的能力”是会被覆盖的，而这类能力大多数是“存在于公共领域的、数据可被获取的”能力。
一方面，我因此认为“独特”是我设计skill的标准，让agent完成独特的任务、获取我独特的观点，这些几乎无法被公共领域知识触及； 另一方面，我也认为，即便将来会被LLM能力覆盖的skill也可能有写的必要，只不过需要权衡时间成本，以及“能不能在这个skill中加入一些我的认识，让它变得独特”。
如何写skill？
skill的设计思路
满足上面条件的skills很难借助LLM撰写，大概率需要我自己手写。但是我显然不想写冗长而复杂的文档，简洁而有效是我的追求。
根据我的观察，详尽的操作指南和严格的限制很难达到目的，这可能导致agent产出的同质性很高、不够灵活、大概率也效果也不够理想，并且要求撰写skill的人写很多字、反复测试才能获得好的效果（这倒适合让agent来迭代优化skill，但对于人来说太不划算了）。
有效的核心方法是“你如何理解任务、看待做法”，包括
- 提供新的想法、观点、视角，给出insights，进行概括描述；
- 指出任务的目的，让agent恰当理解任务，或者重新定义任务。
可以额外添加
- 有代表性的示例（当“容易通过示例说明，但是难以通过描述讲清楚”时）
- 可能的错误理解（如果agent理解有误再去补充，或者通过对比的方式更清晰地说明你的观点）
应当避免
- 低层级的总结、陈列各种具体的规则
- 提供详细的操作指南，列举各种情况下应该怎么做
其实上面给出的skill写法不一定比那种指南式的skill效果更好，但这种方法写出的skill更简洁、更好写，比较节省时间。 而且，越是上面说的“独特的任务和insights”，这种方法的效果就越好。
一些例子
我过去写过的一些skills可以作为例子给出，作为参考。
- 避免LLM生成文档时“AI味很浓”
- 好的：使用直接的叙述方式，避免使用过多复句，避免使用不必要的对比，避免使用比喻
- 坏的：禁止用“不是……而是……”“……不能代表……”
- 制作slides
- 好的：做slides的目的是将最近一段时间内的研究进展进行汇报、向导师提出当前阶段的问题、希望获取老师对后续研究的看法和指导。slides的展示重点是开展实验的动机、结果对总体脉络的价值，体现我对研究问题的探索，具体的指标提升位于其次。结合项目的代码，采访用户以了解研究过程中思路和当前存在的困惑。
- 坏的：禁止写实验的具体设置，禁止添加防御性描述（比如某个实验不完全代表什么结论，尚未进行统计检验等），强调思路而非实验结果，整理出一个研究脉络。
- 网页设计
- 好的：网页应当区分内容主次，仅将用户需要了解的内容呈现在网页上，背后的实现、说明等用户不必了解的内容仅体现在文档。用户的目的是体验网页的能力，而不是了解背后的原理和项目解释。优先使用原生的、简洁的组件。
- 坏的：禁止在网页上说明假设、采用的框架、内部实现细节等。保证网站内容简洁。使用基础的组件构造网页，避免渐变色、圆角矩形。
碎碎念
我认为上面给出的设计skill方法还有额外的好处，它会要求你在撰写skill时产生思考：如何看待这个问题，如何把具体的现象概括成本质，如何解释清除你的动机、目的，等等。或许在这个过程中，你本身就会对“你在做什么”产生更深的认识。
有些问题是写skill无法解决的，比如“写文档有AI味”（防御性写作）这个问题。这类问题往往是LLM参数知识的一部分，难以通过提示词解决；并且“AI味”本身就很难被概括表达，只能尝试从现象累积规律。
我认为防御性写作这个问题的存在也很有趣，它似乎是一种训练目标的偏差，导致LLM没有和人类文本对齐。防御性写作是LLM对“不论是否需要的全面记录”。 LLM的写作可以视为思考的固化或延伸。文本这一载体信息量天然不如思考，因此LLM只能把思考尽可能表达为文本，从而使后续的会话/其他agent能通过文本充分了解情况，这就要求它进行防御性写作从而避免理解偏差。 片面地说，防御性写作可能是LLM能力强的一个天然的、容易做到的要求。
根据以上分析，我认为可能缓解防御性写作的一个路径是，区分“给agent看的文本（LLM思考的延伸）”和“给人类看的文本”（最终呈现的结果）。让agent自主区分这二者可能有难度，或许可以让人来手动指定给人类看的文本。 当然，我猜测以此撰写skill的效果可能不够好，这种防御性写作可能是存在于LLM参数化知识中的。或许应当期望之后的训练过程考虑这个区别。
另外，我认为上面关于防御性写作的观点足够扩展成一篇短文。或许以后有时间时我会把它独立出来。
Footnotes
这类模型的能力足够强，不需要人为给它详尽的instructions。↩︎