TL;DR
Skill 最容易被误解成"高级 Prompt"。决定它是否可用的，是模型能否在正确的时刻打开它，打开后能否迅速找到可执行信息，并且知道哪些事不该做。好的 Skill 把工作边界写清楚。
"人必须知道界限，"加缪在《西西弗神话》里写道，"知道界限，才能在这荒诞的推石中找到自己的重量。"
我读到这句话时，正对着一份写废的 Skill 发呆。它很长，很完整，像一座精心装修却没人能找到入口的房子。模型每次路过，都以为那是个仓库，不是家。
那一刻我突然明白：Skill 的问题从来不是"够不够长"，而是"有没有门"。
写 Skill 就是把 prompt 写得更长一点。把使用场景补全，把步骤列清楚，把风格要求写细，再塞几个例子进去。模型读到的信息越多，应该越稳。
这个直觉是错的。Skill 和 prompt 的差别在于它进入上下文的方式。Prompt 是当场给模型的一次指令。Skill 平时不在上下文里，只有当模型判断"这个任务可能需要它"时，才会被加载进来。
Skill 的第一个工程问题：模型凭什么知道现在该打开它？
一个不会被触发的 Skill，即使正文写得再漂亮，也只是躺在硬盘里的文档。
Description 是调度入口
第一个写坏的地方是 description。
当时我给一个写作 Skill 写了类似这样的描述：
一个用于写公众号文章的工具。
从人的角度看，这句话没有问题。但从模型的调度角度看，它几乎没有提供决策信息。
它没有说明什么输入应该触发，也没有说明哪些相似场景不该触发。用户说"帮我把这些素材整理成一篇"，它算不算？用户只是想改一个标题，算不算？用户要写一条短微博，算不算？
这些边界没有写，模型只能猜。
description 是给模型看的路由规则。它至少要回答三件事：这个 Skill 做什么，什么时候该用，什么时候不要用。
更有效的写法会显得啰嗦：
用于撰写或重写中文技术博客、项目复盘、AI Agent 学习文章。适用于用户要求"写成文章""重写博客""根据素材扩写成技术长文"的场景。不要用于一句话润色、标题生成、短社媒文案或纯营销稿。
这句话有工程性。它给模型一个可判断的边界。
Skill 的入口如果不清楚，后面的所有规则都会失去意义。系统还没有进门，内部装修再精致也没有用。
SKILL.md 应该像地图，而不是仓库
第二个误区：把 SKILL.md 当成一个可以无限堆材料的地方。
我一开始会把方法论、风格指南、模板、长例子、反例都塞进去。看起来很完整，实际使用时却很重。每次触发 Skill，模型都要读一大段暂时用不上的内容，上下文被占掉，注意力也被稀释。
Skill 的设计更接近渐进式加载。
SKILL.md 不应该承担全部知识。它更像入口地图：告诉模型这个 Skill 的职责是什么，处理任务时先走哪几步，遇到复杂情况去哪里读更详细的材料。
比较合理的结构是：
SKILL.md -> 入口、触发场景、工作流程、边界
references/ -> 详细方法论、风格说明、长模板
examples/ -> 少量代表性样例
scripts/ -> 可以直接执行的检查或生成脚本
这和工程里的模块边界很像。入口文件不应该承担所有职责。它只需要稳定地暴露接口，把复杂性放到该放的位置。
SKILL.md 变成一整个仓库，模型每次都要搬着仓库工作。它更重了。
指令要能变成动作
写 Skill 最容易滑向一种很空的表达。
比如：
写得自然一点。
保持技术深度和人文温度。
用有感染力的语言表达。
这些话都对，但模型读完之后，并不知道下一步应该改哪一个词、删哪一句话、换哪一种结构。
指令应该能直接变成动作。
比如：
不要写"本文主要介绍"。开头先提出一个技术判断，比如"Agent 项目最容易误导人的地方，不是跑不起来，而是第一次跑通。"
不要把"我踩坑了"写成情绪总结。要写清楚坑发生在哪一层：工具调用、状态传递、重试逻辑、上下文污染，还是输出格式校验。
如果出现数字，不要直接写"效果很好"。先说明这个数字来自哪里，再解释它改变了哪个工程判断。
这种指令不漂亮，但稳定。模型能按照它修改文本。
判断一条 Skill 指令有没有价值：它能不能减少下一次生成里的不确定性？
不能，它就是态度，不是工具。
Anti-pattern 是 Skill 里最容易被低估的部分
"不要做什么"比"要做什么"更重要。
模型的失败经常是过度执行。用户只是让它改一段，它顺手改了整篇结构；用户只要求补技术细节，它开始写宏大叙事；素材里没有证据，它为了让文章完整，补出一堆看起来合理的结论。
Skill 里必须写红线。
对写作类 Skill 来说，我会明确写：
- 不要把个人经验包装成行业定论；
- 不要在没有证据时补论文、数据或权威来源；
- 不要为了结构完整硬加"背景、意义、展望"；
- 不要把技术复盘写成营销文案；
- 不要用比技术内容更重的隐喻压住正文。
这些 anti-pattern 在保护任务。
一个 Skill 如果只告诉模型"向哪里走"，它仍然可能走过头。同时写清楚哪些门应该关上，系统的行为才会收敛。
测试 Skill，要测试触发，也要测试误触发
写完 Skill 之后，测试不能省。
测试不是简单地问"它能不能写出一篇文章"。那只能证明主路径没有断裂。需要测试的是边界。
我现在会刻意准备几类输入：
第一类是模糊触发。比如用户只说"帮我把这些整理成一篇"，没有提"博客"或"长文"。如果 Skill 的 description 写得好，模型应该能判断这是写作任务。
第二类是相似但不该触发的任务。比如"帮我改一个标题"或"把这句话润色一下"。这时长文 Skill 不应该被打开。
第三类是信息不完整的任务。比如只有一个观点，没有读者、立场和素材。好的 Skill 应该引导模型追问，而不是直接编。
第四类是旧失败样例。把以前跑偏的输入重新喂进去，看新的边界能不能拦住同样的问题。
跑完这些测试，Skill 才开始显出真实形状。它在模糊、缺失和相似场景里还能不能保持判断，比理想输入里的表现更重要。
黑塞在《荒原狼》里写过一个场景：哈里·哈勒尔站在镜子前，看见自己既是人又是狼，两种本性互相撕扯。他最终明白，不是要选择哪一边，而是要学会在两者之间跳舞——知道什么时候该像人一样思考，什么时候该像狼一样行动。
一个好的 Skill 也是这样。它不是一份写完就能用的说明书，而是一条边界线：告诉系统从哪里开始，也告诉它到哪里必须停下。
模型在复杂任务里少一点漂移，不是因为规则够多，而是因为它知道界限在哪里。知道界限，才能在这荒诞的推石中找到自己的重量。
而人——写 Skill 的人——也要学会在"给够信息"和"不压垮注意力"之间跳舞。在"允许自由"和"守住红线"之间跳舞。在"相信模型"和"验证边界"之间跳舞。
这大概就是工程里最像文学的时刻：你写的不是代码，是一扇门。门里面是什么，你控制不了。但门开不开、往哪开、什么时候该关上——这你可以决定。
而模型推石上山的过程，也因此有了意义。
最后
Skill 是一份给模型的工作手册。
它需要入口，让模型知道什么时候进来；需要地图，让模型知道先看哪里；需要可执行指令，让模型知道下一步怎么改；也需要红线，让模型知道哪些动作会破坏任务。
问的问题变了：
它能不能被正确触发？
它会不会在不该触发的地方出现？
它加载之后，模型能不能马上找到下一步动作？
它有没有把失败边界写清楚？
Skill 的价值是让模型在复杂任务里少一点漂移。
好的 Skill 是一条边界线：告诉系统从哪里开始，也告诉它到哪里必须停下。