Skill不是提示词：机制维护与分发

来源：X @op7418

在制作多个爆款 Skill 后，作者得出一个与直觉相反的结论：Agent 不仅没有缩小能力差距，反而放大了它 ^[0]。普通用户将 Agent 视为更聪明的聊天框——输入一句话，得到一段文字；而高级用户已经在使用文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱、上下文工程和 Skill 搭建系统 ^[0]。作者提出的弥合方案是 Skill：将专家经验、工作流、品味和工具调用封装为可分发、可复用、可迭代的 Agent 能力单元 ^[0]。本文沿着这条主线，拆解 Skill 的核心机制（渐进式披露）、维护方法（eval 与 gotchas）和分发生态，说明它为何不是”高级提示词”。

Agent 放大差距，而不是抹平

这一判断基于作者观察到的认知割裂：普通用户只知道”Agent 能写代码""Agent 可以调用 Skill”，却不知道 Agent 的能力上限从何而来，也不知道如何组织目标、资料和流程 ^[0]。在作者看来，目标清晰、上下文组织良好、品味和判断力强的人会被 Agent 放大；目标混乱、没有文档、缺乏判断力的人，其混乱同样会被放大，用户因此呈现 K 型分化 ^[0]。他认为，去年还能依靠产品设计、交互设计和用户教育降低门槛，今年则很难通过简单的 UX 弥合这一差距 ^[0]。Skill 的角色，就是在这道差距上架一座桥。

Skill 不是提示词，是一个目录

Skill 与 Prompt 的区别首先体现在形态上。提示词只是一段文字：容易被复制、难以分发、没有版本管理，也缺少安装和调用语义 ^[0]。Skill 则是一个目录：SKILL.md 是必填的入口文件，references、scripts、assets 等附属资源按需存在 ^[42,47,51]。SKILL.md 以 YAML frontmatter 开头，包含 name、description 等元数据，正文才是给模型的流程与判断 ^[47,51]。目录里的脚本在上下文窗口之外执行，只有输出进入上下文 ^[31,45]。更重要的是，很多任务并非一句提示词能解决，而是一组稳定流程：读取材料、分析需求、选择模板、调用工具、生成产物、验证结果、修复问题、导出文件 ^[0]。素材中的 PPT Skill 就是这样：读取文章或大纲，询问主题、页数和配图，选择主题、颜色和版式，生成 HTML PPT，自动后验检查并修正缺属性、未居中、溢出、图片裁切、节奏重复等问题，必要时调用图像模型生成配图 ^[0]。

这个形态差异背后是两种上下文策略的对立：MCP 是”急切加载”，把全部工具元数据一次性塞进上下文；Skill 是”惰性加载”，只在相关时按需载入 ^[28,48]。现实中的 MCP 实现往往将每个功能包装成一个工具并附上详细描述，导致提示词爆炸 ^[40]。飞书 CLI 是”Skill 封装流程”思路的一个注脚：用户无需理解 200 多条命令，也不用知道背后是哪个 API，只需说”帮我把今天的智能纪要拉到笔记里”，Agent 就能在背后搜索云文档、读取妙记、下载逐句转写、写入本地 Markdown ^[0,9,10]——官方将其定位为”built for humans and AI Agents”，把 200+ 命令封装成 26 个 Agent Skills，用户以自然语言驱动即可 ^[14,12]。

中心短、辐射厚：渐进式披露

如果 Skill 只是”更长的提示词”，上下文窗口早已被撑爆。Anthropic 在 2025 年 10 月推出的 Agent Skills 框架，将答案落在渐进式披露（Progressive Disclosure）上——官方文档和社区分析均认为这是 Skill 机制的核心创新 ^[30,28,41]。信息分三层按需加载：第一层是元数据（name 和 description），始终在上下文中，每个技能约消耗 100 个 token，装 50 个技能初始也只有约 5000 个 token；第二层是 SKILL.md 正文，技能被触发后才加载；第三层是 references、scripts、assets 等资源，执行时按需读取 ^{[28,43,46,47,51]}。上下文窗口是一种公共资源：塞得越多，Token 消耗越快，上下文退化和错误响应的概率越高 ^[43]。

这也解释了素材强调的”中心短，辐射厚”为何成立 ^[0]：SKILL.md 只放高信号流程和判断；references/ 放重文档和领域材料，按条件读取；scripts/ 放确定性逻辑，让 Agent 调用而不是重写；assets/ 放模板、schema、示例、字体和版式骨架 ^[0]。脚本只执行、不进入上下文 ^[45,42]，因此复杂 Skill 不怕内容多，怕的是把复杂内容一次性塞给模型——文件系统本身就是一种上下文工程 ^[0]。反过来，把所有能力塞进一个大而全的 harness，会把工具定义、协议细节和长文档塞满上下文，带来更高延迟、更高 token 成本和更多误用 ^[0,40]。更稳的架构是 Thin Harness, Fat Skills：harness 保持薄，负责跑模型循环、读写文件、管理上下文、执行权限和安全边界；Skill 变厚，承载流程、判断、领域知识、模板、脚本、资产和 gotchas ^[0]。渐进式披露正是这套分工能成立的前提——Claude Code、Codex CLI、Gemini CLI 等平台都按这个接口实现按需加载 ^[49]。

description 是路由开关，不是广告语

三层披露中，第一层的 description 承担最关键的一步：它是 Agent 判断”何时加载这个 Skill”的触发条件 ^[31,43]。官方对 Skill 的指导同样强调，description 不是简介，而是告诉 Agent 什么时候该用这个 Skill——写得太宽泛，Skill 就会乱触发或不触发 ^[55]。素材的表述更具体：好的 description 应该描述”用户什么时候需要它”，最好来自真实用户的表达；坏的 description 只是解释”这个 Skill 做什么” ^[0]。比如 PPT Skill 不应写”这个 Skill 可以生成漂亮 PPT”，而应写”当用户需要把文章、大纲或演讲内容转成可演示 HTML PPT 时加载”——前者是广告，后者是判断条件 ^[0]。

路由是自然语言匹配，坑很细：trigger 里”generate report”和”generate-report”是两个完全不同的触发条件，多余的空格会被视为非法字符，导致整个 trigger 解析失败 ^[57]。这也是 eval 存在的理由：Skill 评测必须包含正例和反例，验证”该触发时触发、不该触发时不触发” ^[0,36,37]。OpenAI 的实践将 eval 定义为”prompt → 记录运行轨迹与产物 → 一组检查 → 一个可比较的分数”，并明确要求负例控制 ^[37]；Google 的评测教程则用 Inspect 框架对一组 Skill 跑自定义 prompt 评测 ^[34]。

像维护代码一样维护 Skill

好 Skill 不是一次写完的，它需要像代码质量一样维护 ^[0]。素材给出的生命周期是：先用不带 Skill 的 Agent 跑真实任务，找到它会错在哪里；基于真实 query 写 eval（含正例、反例和 forbidden load）；先调 description，确保该加载时加载、不该加载时不加载；写主体时删除显而易见的内容，只保留会改变模型行为的判断；把失败案例追加到 gotchas 而不是不断加长主流程；改路由边界时补 eval；最后做跨模型测试，看不同编排模型对触发和执行的差异 ^[0]。

这个周期里最值钱的是 gotchas——从真实失败中总结的”别这么做”清单 ^[0]。正向原则往往模型已经知道，负面边界才是专家经验 ^[0]。开源社区已出现这种做法的成熟产物：豆瓣备份 Skill 内置 7 种被拒抓取方案的完整失败日志，Terraform 排障 Skill 的每一条都是”确切报错 → 根本原因 → 修复”三元组，来自真实事故 ^[52]。eval 的衡量也不止”能不能触发”：还要看功能是否达成、执行是否符合你设定的规则 ^[36]。

跨模型测试并非可有可无。Skill 的触发依赖模型的意图识别和工具调用能力，同样的 Skill 在能力强的模型上运行流畅，在 GLM-4.7、DeepSeek 这类模型上却经常”卡壳”或”乱答”，复杂推理链（思考→选工具→看结果→再思考）容易中途断裂 ^[53]。素材的概括是”好模型看上限，差模型保下限” ^[0]。这也解释了为何完全自动生成 Skill 只能做初稿：模型可以帮你起草结构，但无法凭空拥有你的失败样本、审美判断和行业边界 ^[0]。维护还要算成本账：每个 Skill 都是一种税——进入索引后，每个会话都为它的 name 和 description 付上下文成本；被加载后，后续对话都在为主体内容付成本，所以每一句都要问：没有这句，Agent 会不会做错？不会，就删 ^[0]。

设计 Skill：把品味变成约束

设计类 Skill 是”经验外化”最直观的样本。素材观察到模型默认会收敛到一些平庸模式：Tailwind 大色块、紫色渐变、emoji 堆砌、Inter 字体、发光、过度圆角 ^[0]。“蓝紫渐变”背后有可查的机制：AI 的训练数据里大量现代网站采用 Tailwind，而 Tailwind 的默认主色调就是蓝紫色（bg-indigo-500），模型只是把训练数据里的常见样式当成了默认审美 ^[26,27]。

因此设计 Skill 的核心，是把专业品味变成模型可执行的限制：不用纯白纯黑、不让用户任意输入 hex 而只提供验证过的主题色板、不用紫色多彩渐变和发光当主视觉捷径、动画只在必要时使用且只动 transform 和 opacity、AI 生图只做兜底 ^[0]。这些规则看似限制自由，实际是在保护输出下限——设计类 Skill 的质量来自”替用户排除绝大多数会变丑的选项” ^[0]。素材的社交卡片 Skill 是这套方法的成品：内置 Editorial 和 Swiss 两套视觉系统、28 个版式骨架，支持截图美化和从 Unsplash 等图库自动找图，把文章、截图、笔记等内容转成小红书图文卡片与公众号封面 ^{[18,19,20,21,23]}；这套视觉系统和骨架是从 PPT Skill 沿用并重新校准过来的 ^[21,22]。它在 GitHub 上已有 5.9k 星标 ^[18]，为”爆款”提供了一个注脚 ^[0]。更一般的做法是技术分层：Logo Generator Skill 不让图像模型一把梭，而是先生成 SVG Logo 变体，再做展示图和 WebGL 背景，把 Logo 本体、展示场景和交互背景拆成不同层，分别用最适合的技术处理 ^[0]。

分发：从仓库列表到社区节点

能力商品要流通，还差分发这一环。素材的判断是：当前很多 Skill 展示像 GitHub 仓库名列表，图标雷同、没有结果展示、没有评价指标，用户不知道哪个适合自己；推荐 10 个精选 Skill 并讲清楚怎么用，远好过给用户几千个列表 ^[0]。每个 Skill 都应该像一个软件功能页：解决什么问题、适合什么场景、需要什么输入、输出长什么样、谁用过、有哪些常见失败、如何安装修改 ^[0]。

分发渠道各司其职。GitHub 是代码型 Skill 的天然托管地：Skill 往往包含代码、需要版本管理，AI 也熟悉 Git 和 GitHub 操作，开源还能覆盖所有 Agent 平台 ^[0]——飞书 CLI 正是以开源仓库形态分发，首月星标破万 ^[10,14]。小红书适合视觉内容和使用案例分发：社交卡片 Skill 的传播已经超出 AI 圈，触达咖啡馆主理人、数码测评、活动策划等群体 ^[0,23]。素材的判断是，未来的 Skill 平台会同时是 App Store、GitHub、社区种草页、评价系统和 Agent 工具层 ^[0]。普通用户真正的卡点不在安装，而在交互心智：很多人仍以传统软件思维，以为一次生成就该完成，不习惯通过 chat 连续调整，不知道可以要求改颜色、改字、修溢出、换图 ^[0]——所以分发必须带上使用教育 ^[0]。

Agent 时代最稀缺的是可复用的能力组织方式 ^[0]。Skill 之所以重要，是因为它第一次让人的经验、工作流和品味，有机会变成可以分发、调用、评价和持续迭代的商品 ^[0]——而这套”能力商品化”能否成立，取决于创作者是否把判断写进约束、把失败写进 gotchas，并接受渐进式披露那种”判断与执行分离”的机制。