万字长文 | Skill 的前世今生和设计哲学
Skill 这个东西，最近是真的出圈了。2025 年 10 月它还只是 Claude 发布会上的一个新名词，一年不到，Gemini CLI、GitHub Copilot、OpenClaw 这些名字都出现在了它的兼容列表里，连 Databricks、Snowflake 这种做数据平台的也来认这个格式。国内的教程也铺开了，标题一个比一个大，什么三分钟精通、一文吃透。
于是一种熟悉的操作又出现了：攒。把网上看来的提示词一股脑存成 SKILL.md，一个文件夹塞几十上百个，名字起得都很威风，全能写作、万能分析、神级修图。别跟我说存起来总有用，我可以负责任的告诉你，照这么攒下去，半年后你还会打开的不超过五个，因为那不是 skill，那是收藏夹，收藏夹的宿命就是吃灰。
我自己仓库里躺着三十来个 skill，生图的、排版的、发公众号的、写作的、审稿的，串起来是几条天天在跑的生产线。这篇文章分两半：前一半讲清楚 Skill 的来龙去脉，它从哪儿来、凭什么一年就长成了行业标准，材料以 Anthropic 官方资料为准，出处都在文末；后一半聊设计哲学，是我拿自己踩过的坑，对照官方最佳实践和 Warp 这类公司的一线实践，整理出来的几条判据。万字预警，可以先收藏，但我更建议你直接往下读，毕竟收藏夹的宿命刚说过了。
01 前世：Skill 出现之前
把时间倒回去看，Skill 要解决的问题一直存在：怎么把"你的知识"交给一个通用模型。这条线上的每一站，我基本都踩过。
最早是堆系统提示词。把规范、术语、案例全塞进 prompt，模型确实听话了，代价是每次请求都背着几千上万 token 的包袱，改一条规则要在一大坨文本里找位置，改完谁也不知道会不会影响别的。然后是 RAG，把知识切片进向量库，按相关性捞。检索对付事实性资料还行，对付"流程和做法"就很吃力：一个流程被切成八片，捞回来三片，模型按残缺的流程办事，错得还很自信。再往后是 MCP 和工具热，把能力包成接口给模型调。这条路解决的是"能不能做"，解决不了"该怎么做"：接口给了，什么时候该用、用的时候有什么讲究、你们团队的口径是什么，还是没地方放。到 2025 年，大家把这些经验归拢成一个词，上下文工程，重心从"怎么把上下文堆进去"挪到了"怎么管理上下文"。
Skill 就是在这个节点上出现的。它回答的正是前面几站都没答好的那个问题：过程性知识，放哪儿。
02 今生：一个文件夹被扶正
Anthropic 正式发布 Agent Skills 是 2025 年 10 月 16 日。定义简单得可疑：skill 就是一个文件夹，里面放一个 SKILL.md，文件头部用 YAML 写两个必填字段，name 和 description，正文写指令，旁边可以捆脚本、模板、参考资料。没了。
有意思的是，这东西发布前就已经在干活了。当年 9 月 Claude 上线了文档生成能力，能直接产出 Excel、PPT、Word、PDF，后来大家才知道，这套能力底下全是用 skill 实现的。Simon Willison 在官方发布前六天就通过逆向把这个机制扒了出来，发布当天他又写了一篇，标题很直接：《Claude Skills are awesome, maybe a bigger deal than MCP》。他点出了最关键的那个设计：启动时模型只读每个 skill 的 name 和 description，一个 skill 只占几十个 token，几百个装在身上也不压秤，正文只在任务匹配时才加载。
官方工程博客把这个机制叫渐进式披露，分三层。第一层，启动时只装元数据，够模型判断"什么时候该用它"；第二层，任务匹配了，读整个 SKILL.md；第三层，SKILL.md 里引用的其他文件，用到哪个读哪个。像一本编得好的手册，先给目录，再给章节，最后才翻附录。配上文件系统和代码执行，一个 skill 能挂的知识量实际上没有上限，反正不读进上下文就不占地方。
写它的三位工程师在博客致谢里留了一句自我介绍，说他们仨都很喜欢文件夹。这句玩笑其实就是整个设计的底色：不发明新格式，不搞新协议，就用 Markdown 和文件夹，谁都会写，git 直接管版本。Simon 那篇文章有个小标题说得更狠：简单本身就是重点。
03 出圈
2025 年 12 月 18 日，Anthropic 把 Agent Skills 发布成开放标准，建了 agentskills.io，同时上线了组织级管理和一个官方技能目录。这步棋直接把 skill 从"Claude 的一个功能"变成了"行业的一种格式"。
到今天（2026 年 9 月）你去 agentskills.io 看兼容客户端列表，阵容已经不太像一个厂商的私有格式了：Gemini CLI 在，GitHub Copilot 在，Roo Code、OpenClaw、Ona 在，Databricks 和 Snowflake 的编码产品也在。一次编写、到处运行这句老话，这回落在了一个 Markdown 文件上。
为什么是它？我的判断是三个原因，按重要程度排。第一，token 的账算得过来：前面说的几十 token 元数据成本，让"多装几个"没有负担，这是所有采用方最容易算清的一笔账。第二，格式门槛低到几乎没有：会写 README 就会写 skill；对比 MCP 要起服务、定协议、管鉴权，采纳成本差了一个量级。这也是两者的分界，MCP 管"连上外面的系统"，skill 管"教会里面的做法"，官方自己的说法是互补，一个给工具，一个教工作流。第三，也是最容易被忽略的：它把知识资产变成了可版本控制的文件。你的团队规范第一次可以走 PR、可以 review、可以回滚。这一条为后面 08 节要讲的自我进化埋下了伏笔。
04 官方的设计哲学
官方文档里有一篇《Skill authoring best practices》，加上前面提到的工程博客，构成目前最权威的设计指南。内容不少，我挑三条讲，因为这三条我都用真实项目验证过，确实是承重墙。
第一条，上下文窗口是公共品。官方原话是 the context window is a public good：你的 skill 和系统提示词、对话历史、其他 skill 的元数据挤同一个窗口，每个 token 都在跟别的信息抢模型的注意力。所以文档给的默认假设很直接：Claude 已经很聪明了，只写它不知道的。文档里有个对比例子，同一个"提取 PDF 文本"的说明，啰嗦版 150 个 token，从 PDF 是什么讲起；精简版 50 个 token，一行说明加一段代码。多出来的 100 个 token 不是无害的废话，是在稀释注意力。我自己的写作 skill 改到现在，删掉的字比留下的多，越删触发越准。
第二条，自由度要分级。官方的比喻是把模型当成走路的机器人：两边是悬崖的独木桥，就给死指令，一条命令都不许改，比如数据库迁移；开阔的平地，就给方向性的原则，让模型自己找路，比如代码审查。翻译一下：脆弱且必须一致的环节，用脚本钉死；依赖语境判断的环节，写原则。很多人写 skill 只用一种力度，要么全是死规则，模型碰到没覆盖的情况直接傻掉；要么全是"保持专业"式的空话，等于没写。
第三条，从评估开始，跟着轨迹迭代。官方建议的起点不是写，是先让 agent 裸跑几个代表性任务，看它到底在哪儿栽跟头，再针对性补 skill；写完之后盯着它的真实使用轨迹看，重点盯 name 和 description，因为触发靠的就是这两行。这条跟我自己的体感完全对上：我所有 skill 里改动最频繁的就是 description，它是 skill 跟模型签的第一句合同，第一句没写清，后面写得再好也没有出场机会。
05 写判据，不写感受
从这节开始是我自己的东西，跟官方的不冲突，算往下再拧一圈。
先讲一次打脸。今年 6 月我在折腾"AI 稿怎么写得像真人"，拿一篇过了检测的真文逐句对比出一张纹理表，照着重写了一篇稿，检测从"100% 疑似 AI"降到"0% AI 特征"，零人工编辑。我立刻把它写进了写作 skill，当成可复用的结论。结果多轮复现全部失败，控制变量实验做下来，检测判的是 token 级指纹，检测分约等于真人句子占比，我那次就是个孤例。那条规则被撤掉，原位置挂了一行更正：已证伪，勿再依赖。从那以后我给规则分三种状态：假设，待在讨论里；单例观察，可以进文件，但标"挂起，待二次确认"；控制变量复现过的，才配叫铁律。
这次打脸立下的规矩是：skill 里写的不是知识，是判据。"图要有质感"是感受，写进去等于没写；"涂色不能均匀、必须留白、允许涂出界"才是判据。我的手绘风格库里有个蜡笔风格，一开始自觉调得挺像，发给一个朋友，他不满意，理由怼的我没有脾气：他拿出他家女儿真实的蜡笔涂抹作品，我们生成的涂得太均匀、太满，一眼假。最后改进 skill 的不是"更像小孩"这句愿望，是上面那三条能执行的判据。
这里可能有人要抬杠：Warp 不是说要写原则、别写死规则吗（这是 08 节的主角，先剧透一句），官方也说高自由度场景给方向就行，这跟"写判据"矛盾吗？不矛盾，它们说的是同一件事的两端，正好用官方的自由度框架对齐：原则管方向，用在语境多变的地方，"寻找重复代码"就是原则；判据管验收，用在结果必须可判真假的地方，"把文中的作品名换掉这段还成立，就判平台平均稿，打回"就是判据。真正的反面不是原则也不是判据，是感受，"要有温度""要专业"这种话，既指不了方向，也验不了收。
06 先写"不要做什么"，职责窄到一句话
官方说"只写模型不知道的"，我在这条上再加半条：先写"不要做什么"，再写"要做什么"。
今年做口吻蒸馏 skill，把自己六个来源约 25 万字的语料统计了一遍，本来冲着攒特征词去的，最后发现最值钱的产出是排除表。给个数字：在 23.7 万字的作者语料里，"我觉得"一共出现 2 次；"说白了""换句话说""事实上"这类 AI 最爱的转接词，加起来 5 次。往稿子里放一个，浓度立刻是本人的十倍以上。判断一段话像不像一个人，写错一个他从不用的词，比少用十个他常用的词伤害大得多。这个道理放大到所有 skill 都成立：模型的本能是做加法，加修饰、加强调、加总结，你不立"不要做什么"的墙，它会把词库里每个词都当任务完成，写出来的不是那个人，是那个人的模仿秀。所以我的审稿 skill 通篇是黑名单，写作 skill 专门有一节叫红线区，命中即删，没有例外。
职责上我有个很土的自查办法：用一句话说清这个 skill 管什么、不管什么，说不清的，后面一定出事。我仓库里最省心的是接 codex 生图的那座桥，只干三件事，调生图、去 EXIF、归一尺寸，prompt 不归它写，发布不归它管，上线到现在几乎没改过，因为它没有理由坏。前阵子做口吻 skill，最初想塞进写作 skill 省一个入口，最后还是拆开了：写作 skill 管整篇，全是结构规则；口吻 skill 恰恰要求不碰结构，只管一句话一段话，混在一起，两套规则早晚互相污染。一个 skill 只回答一类问题，有两类问题就拆两个，宁可多一次跳转，不要一本什么都管的圣经。官方对 name 的建议细到了词性，推荐动名词，processing-pdfs、analyzing-spreadsheets 这种，图的就是"它是干什么的"从名字上一眼可判。
顺着这个还有一条取舍阶梯：能用一条命令解决的，不写提示词；能用一段提示词的，不上 skill；能用一个 skill 的，不拆子代理。每往上走一层，都要多养一层东西，多一层出错的地方。工具的层级不是越高级越好，是够用就停。
07 把做不到的写进合同
Skill 圈有个心照不宣的毛病：介绍自己的时候全是能干什么，绝口不提干不了什么。我的经验恰好反过来，一个 skill 最值钱的几行，经常是承认做不到的那几行。
我的口吻 skill 里专门有一节叫检测边界，白纸黑字：AI 转换出来的句子，读起来再像本人，检测器照样判 AI；这个 skill 管"读者觉得像"，不管"检测器判人"。这不是谦虚，是 05 节那次打脸实验的直接产物，不写清楚，用的人早晚拿它去干它干不了的事，最后骂的还是这个 skill。写作流水线还有一条硬规矩：每次执行先出一份短报告，说清这次的材料是什么等级、风险在哪、能不能产出正式稿，不能就直接给 BLOCK，绝不假装终稿可发。skill 的输出不该只有成品一种形态，"这次做不了"也是合格输出，而且常常是更负责的那种。
官方在安全这块的提醒同样属于"合同"：skill 是带代码执行权力的东西，装一个第三方 skill，等于给模型发了一把能在你环境里跑代码的钥匙。官方的建议是只装可信来源的，装之前把里面的文件和脚本通读一遍，特别注意有没有让模型连外部网络的指令。反过来看，这也是对 skill 作者的要求：你的 skill 要经得起别人这么审。
08 进化问题：Skill 怎么自己变好
进化是 Skill 这个体系里最值钱、也最没被讲透的问题：skill 写完不是终点，用的过程中会持续暴露新场景、新坑，谁来改它？
这个问题我自己实验过两次，结论一好一坏。好的那次是一个反编译 JS 代码的 skill（decode-codex 项目里的 deobfuscate-javascript），我在 skill 里写了一节自我改进协议：每次 Agent 反编译遇到新场景，解决了，就把经验更新回 skill 本身：脚本的 bug、值得自动化的手工步骤、没见过的 npm 包，修进对应位置，并且必须和还原产物分开提交。效果还不错，能一直优化，就是 skill 文件越来越大。坏的那次是写作的自我进化 skill，那个就一言难尽，因为写作没有自己统一的标准，模型自己评自己改，经常负优化，越写越糟糕。两次放在一起，答案的形状其实已经出来了：有客观标准的领域，自我进化能跑；没有客观标准的领域，让模型自己当裁判就是灾难。
今年 8 月底，Claude 官方博客发了一篇《How Warp builds self-improving agents on Claude》，讲的正是这个问题的一套工程化解法，我看完还是挺有收获。Warp 是个挺有名的终端工具，如今每月有 80 万开发者在用，他们内部尝试用 Agent 做代码审查，一开始效果并不理想：Agent 不了解你的项目，不知道团队规范，不知道历史的经验教训，你指出来问题，它下次还是记不住。简单说，没有记忆。初期他们采取了不少补救：手动根据失败案例改系统提示词，完善项目的 AGENTS.md（有意思的是，这篇博客是 Claude 官方发的，里面用的是 AGENTS.md 而不是 CLAUDE.md，倒也不奇怪，Warp 的 agent 跑在自家 harness 上，认哪个上下文文件是 harness 说了算，AGENTS.md 这两年已经是跨工具的通用约定）。但效果都不理想：一方面依赖人主动去做，成本高；另一方面，工程师平时在 PR 里写的高质量评论，完全没被用上。Warp 对病根的定位很准：反馈会随着会话结束而消失，关键上下文就这么一次次漏掉了。
他们的方案是两个 skill 加一个人。基础 skill 负责干活，代码审查的领域知识都在这儿；改进 skill 是个观察者，定期跑而不是每次跑，把这段时间人类工程师的评论收集起来，尤其是对 Agent 审查结果的评论，对照"agent 当时怎么说、人怎么回"，给基础 skill 提一个小而聚焦的修改，走正常的 PR 流程，人审核、合并，下一次运行自动继承改进。换句话说，它不靠模型自己改进自己，而是 Agent 根据人类对模型产出的标注去改技能。这一下正好绕开了我那个写作 skill 的死穴。
最妙的是摩擦力被压到了极低。不需要人手工收集整理评论，不用填任何问卷，工程师只要像平常一样在 PR 和 issue 下面写评论，剩下的事全由 Agent 自动完成。博客里有个现成的例子：他们的 issue 分诊 agent 漏打了一个 ready to spec 标签，维护者直接在 issue 下面留言，说清楚了期望什么、为什么；改进 skill 定时跑起来，用自带的脚本拉取近期带反馈的 issue，识别出这条信号，开了个 PR 给基础 skill 补上对应规则，PR 描述里写明是哪些信号促成了这次修改，人审核合并，这一圈就走完了。
这可能正是当下人机协作的最佳分工之一：人负责高维度的标注、评论、反馈，Agent 负责执行，Agent 再根据人类的反馈去改进 skill。顺带说一句，官方工程博客的结尾其实早写了这个愿景，让 agent 自己创建、编辑、评估 skill；Warp 等于把官方的期货提前交割了，用的还全是普通的文件和 PR，没有任何黑魔法。
09 反馈的质量、权限与防错
Warp 团队顺手总结了六条经验，我逐条对照过自己的实践，整理如下。
一，写原则，不要写死规则。编 skill 要像在指导一个聪明人，不是在给计算机编程，写"寻找重复代码"，比列一堆详尽的变量命名规则更有效。记得跟 05 节的自由度框架合着用：这条适用于语境多变的判断类环节，脆弱环节该钉死还得钉死。
二，解释为什么。给出规则背后的理由，模型才能针对问题推理，而不是机械执行，也才举一反三。这条我体会很深，我的写作 skill 里每条红线后面都跟一句为什么，"少排比"后面跟的是"真人的判断长在具体事上，不长在节奏里"。
三，让反馈毫不费力。在人们本来就工作的地方收集反馈，直接评论 PR 或 issue，收集过程自动发生，不增加任何额外步骤。Warp 创始人 Zach Lloyd 那句话说得很透：低摩擦才能让信号持续流动，反馈太麻烦，你就收不到反馈，也就无从改进。
四，保持 skill 精简，用渐进式披露。好的 skill 文件不大，引用资源文件和脚本，而不是把所有内容一次性塞进上下文。这是 02 节那个官方设计在进化场景里的延续。
五，反馈质量大于数量，但数量也有帮助。一位资深工程师给的少量、详细、领域相关的反馈，比大量草率的点赞点踩值钱，因为赞成反对说明不了为什么；只要反馈来自掌握领域知识的人、足够详细，小样本也有好信号。当然，优质信号的语料越大越好，Warp 现在拿这套循环管理整个开源仓库，几百个贡献者，几千次代码审查。
六，把改进 skill 本身做好，它可以复用到别的 skill 上。除去领域知识那部分，改进机制高度通用，代码审查 agent 的改进 skill，换个领域照样能用。论投入产出比，这是最高的一条。
然后是所有人都会问的问题：反馈本身是错的怎么办？Warp 的答案是三道防线。第一，永远不让 Agent 盲目接受反馈，给它足够的上下文做基本的合理性检查；第二，限制谁的反馈有权影响 skill 更新，不是所有人的意见都同等重要；第三，人始终留在环里，改进以 PR 形式出现，人审核了才合并。再往下拆一层，看你的领域可不可验证：有标准答案的，比如代码过没过测试、部署成没成功，先建验证基准，让 Agent 对着基准自己跑；没有标准答案的，比如代码风格、文档质量，就只收领域专家的判断，不要开放给所有人随意反馈。这两条分界，恰好解释了我那两次实验的一好一坏：反编译有客观标准，代码跑不跑得通、还原完不完整，摆在那里，所以裸的自我进化也能收敛；写作没有，所以要么引入外部的人类标注，要么干脆别让它自我进化。
还有一处细节我想单独说。Warp 特别提醒别把 skill 和记忆搞混：skill 是过程性的、稳定的，"怎么做 X"，跟单次运行无关，改动应该是深思熟虑的；记忆是 agent 推理时自动写的，一直在变。我那个反编译 skill 文件越长越大的病根就在这儿，我把很多本该进参考文件的单例经验全灌进了主文件。按渐进式披露的正确姿势，主文件保持精简，经验沉到 references 里按需加载，改进 skill 定期做一次清理。这条已经列进我自己的翻修清单了。
10 边界
按惯例，说了一万字，最后给它降降温。
这套哲学服务的是长期跑的生产线：你打算反复用、出了错要能查到哪条规则头上的那种 skill。如果只是让 AI 帮你干个一次性的活，别搞这套，直接说话最快，为一个用一次的任务写判据、建排除表、做复现实验，成本收不回来。判断标准一句话：这东西你会用第二次、第十次吗？会，才值得按这篇说的来。
进化那套同理，别急着给每个 skill 都配改进循环。Warp 有一条特别清醒的提醒：一两个 agent，各配各的改进循环没问题；上百个，就该共享一套模板化的基础循环，再叠领域知识。他们管部署节奏叫 crawl-walk-run，翻译成人话：先手动改，再半自动，最后才全自动，每一步都确认上一步真的成立，不跳级。
我自己仓库那三十来个 skill 也不是个个达标，有几个老的判据松、验证欠，排队等翻修，现在清单上又多了两条：把反编译 skill 那个越长越胖的主文件按渐进式披露拆薄；给写作流水线补一个只收我自己标注的改进 skill。规则文件里那条被证伪的更正我一直留着，不是纪念，是提醒：下一条铁律，也可能是下一次打脸，到时候再写一篇。
以上。判据来自我自己的生产线，带着我的场景和偏见；官方资料和 Warp 的实践都给了出处，放在下面，值得点开原文看一遍。有不同的实测结论，欢迎补充。