本文来自微信公众号： 歸藏的AI工具箱 ，作者：歸藏的 AI 工具箱，原文标题：《万字长文：做了些爆款 Skills 以后，我对 Skills 的看法》
我最近几次聊Skills，有一个越来越明确的判断：
大家现在都在说Agent，但大多数人其实还没有真正理解Agent。
大众理解里的Agent，往往还是一个聊天框。
你输入一句话，它回答一段文字；你再输入一句，它继续回答。
这个视角下，AI好像天然会带来一种平权：以前不会写代码的人可以写代码，不会做PPT的人可以做PPT，不会剪视频的人可以剪视频。
只要模型足够强，大家的能力差距就会被抹平。
但我越来越觉得，这个判断是错的。Agent不是简单抹平能力差距，而是在放大能力差距。
头部用户已经默认理解Agent的组成：
文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱、上下文工程、定时任务、心跳、文件系统、代码执行和Skill。
但普通用户只知道"Agent能写代码""Agent可以调用Skill"，并不知道Agent的上限从哪里来，也不知道自己应该如何组织目标、资料和流程，才能让Agent真正工作。
Agent：这里指的不只是聊天机器人，而是能理解目标、规划步骤、调用工具并持续执行任务的AI系统。
Memory：Agent用来保存长期偏好、项目状态和历史决策的外部记忆，不等同于模型训练记忆。
Loop：Agent反复"思考、调工具、观察结果、再决定下一步"的执行循环。
这里就出现了一个很大的认知割裂：头部用户已经在搭系统，普通用户还在问聊天框。
目标清晰、上下文好、品味和判断强的人，会被Agent放大；目标混乱、没有文档、没有判断的人，也会被Agent放大混乱。
所以用户会出现K型分化。去年还可以靠产品设计、交互设计和用户教育降低一些门槛，今年我觉得已经很难靠简单UX弥合这个差距。
Skill则可以弥合Agent使用能力差距。
Skill是能力商品，不只是提示词
我现在对Skill的一句话定义是：
Skill是把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的Agent能力单元。
Skill：把提示词、流程、工具调用、模板、脚本、边界和经验打包起来的可复用能力单元。
它不是单纯的提示词，也不是传统意义上的App。
它更像Agent时代的"能力商品"。用户不需要理解底层的MCP、CLI、workflow、memory、loop、模型选择、代码执行和上下文工程，只需要知道：
它解决什么问题，产出什么结果，怎么使用，别人用得怎么样。
提示词本身很难成为产品。它容易被复制，难以分发，没有版本管理，也缺少安装和调用语义。
Skill把提示词、规则、示例、工具调用、文件结构、脚本、依赖和使用说明打包起来，让它变成一个可以安装、调用、迭代和传播的能力包。
所以Skill和Prompt本质上并非完全不同，但Skill的调用效率更高，分发和理解成本更低，也能承载更多工程化内容。
更重要的是，很多任务并不是一句提示词能解决的。
它们是一组稳定流程：读取材料，分析需求，选择模板，调用工具，生成产物，验证结果，修复问题，导出文件。
Skill把这套流程从一次性对话中抽出来，变成可以反复调用的工作流。
比如PPT Skill的流程不是"生成PPT"这么简单。
它要读取文章或大纲，询问主题、页数和配图，选择主题、颜色和版式，生成HTML PPT，自动后验检查常见问题，再修正缺属性、未居中、溢出、图片裁切、节奏重复等问题，必要时还要调用图像模型生成配图，最后输出可演示、可分享的文件。
这背后真正有价值的，是Skill把人的演示经验被外化了。
Skill的核心，是把人的经验外化
我做的设计类Skill很能说明这一点。
真正有价值的部分是把人的审美、版式判断、设计系统经验、模板选择、图片裁切规则、明暗遮罩规则、字体和颜色规则固化进去。
这要求创作者同时懂三件事：传统专业知识，AI的上下限，以及产品化思维。
传统专业知识决定你知道什么结果算好。比如设计、剪辑、写作、健身、法律、商业化投放，每个行业都有大量隐性判断。AI的上下限决定你知道模型什么能做、什么做不稳、什么必须工程化兜底。
产品化思维决定你知道用户场景、使用门槛、反馈路径和稳定性要求。
这也是我做几个Skill时最深的体会。
PPT Skill最开始不是为了"做一个Skill"，是因为我真的要做一场分享。
第一版基本成型后，我通过五六轮对话调整间距、字号、字体、颜色、配图、重复内容、WebGL背景等问题。
讲完之后发现大家最关心的不是分享本身，而是PPT怎么做，于是才把这套模板和流程沉淀成Skill。
社交媒体卡片Skill也不是凭空抽象出来的。它来自非常具体的内容分发需求：
3:4竖版图文卡片，适配小红书、公众号、Twitter等不同场景。它要处理11类内容，两套视觉系统，28个版式骨架，真实图片+Coding排版，还要规避AI图限流、文字不锐利、平台风格不匹配等问题。
Logo Generator Skill也是同一逻辑。它没有直接让图像模型一把梭生成Logo，因为图片模型的文字、结构和可编辑性不稳定。
它选择先生成SVG Logo变体，再生成展示图和WebGL背景，把Logo本体、展示场景和交互背景拆成不同层，分别用最适合的技术处理。
AI Desk Card则说明Skill的边界可以扩展到物理环境。
它让Agent接管屏幕边缘的物理信息位：固件烧录、Wi-Fi配置、信息推送、定时任务、memory、todo、日历、GitHub展示、墨水屏刷新，都可以被封装成一套Skill。
这些案例共同说明：Skill的核心是"人把什么经验变成了可调用的能力"。
用户不关心概念，用户关心结果
对普通用户来说，Skill、MCP、CLI、Plugin叫什么并不重要。
他们关心的是：这个功能能解决什么问题，适合什么场景，我点一下能不能用，需要输入什么材料，结果长什么样，别人用得怎么样。
MCP：Model Context Protocol，可以理解为让AI以统一方式连接外部工具、数据源和服务的协议。
CLI：Command Line Interface，命令行工具；对Agent来说，它常常是比图形界面更稳定、更容易自动化的操作入口。
因此，面向用户的产品层不应该堆术语。Codex把很多东西统一叫插件，我觉得就是一个正确方向：弱化概念，强调功能。
底层可以是Skill、MCP、CLI或原生Plugin；用户只需要知道它能干什么。
但对产品和创作者来说，这些底层形态的区别又很重要。
Skill适合承载相对垂直、可描述、可复用的工作，比如PPT、社交媒体卡片、文章配图、写作润色、视频包装、简历优化、数据可视化、某个行业SOP。
MCP更适合Agent架构中的原子服务和上下文连接，比如地图、浏览器、网盘、设计稿、数据库、企业API。
CLI则是目前很现实的通用Plugin形态：命令行、代码、Skill都可以封装进去，也不绑定单一Agent平台。
他只需要说"帮我把今天的智能纪要拉到笔记里"，Agent背后可以搜索云文档、读取妙记、下载逐句转写、写入本地Markdown、建立反向链接。
用户看到的是结果，Agent用的是工具，Skill封装的是流程。
这也是为什么Skill、CLI和MCP的关系不能只从技术概念上理解。
它们最终都要落到一个问题：怎么让普通用户用上头部用户已经验证过的能力。
好Skill的架构：中心短，辐射厚
很多人会把Skill理解成一个SKILL.md文件，这只说对了一半。
SKILL.md：很多Skill的入口说明文件，用来告诉Agent什么时候加载这个能力、按什么流程执行、哪些坑不能踩。
好的Skill往往是一个目录。SKILL.md只是入口，旁边还可以有scripts/、references/、assets/、模板、schema、配置文件、子Skill和特殊案例。
复杂Skill不怕有复杂内容，怕的是把复杂内容一次性塞给模型。文件系统本身就是一种上下文工程。
上下文窗口：AI一次能"看见"和处理的信息范围，文档、代码、聊天记录和工具说明都会占用它。
好Skill的信息架构应该是"中心短，辐射厚"。
SKILL.md只放高信号流程和判断；references/放重文档和领域材料，按条件读取；scripts/放确定性逻辑，让Agent调用而不是重写；assets/放模板、schema、示例、字体、主题和版式骨架；配置文件或稳定数据目录放首次配置、偏好和历史记录。
这里有个很关键的点：Skill的description不是宣传语，也不是功能摘要，是路由触发器。
好的description应该描述用户什么时候需要它，最好来自真实用户表达；坏的description只是解释"这个Skill做什么"。
比如一个PPT Skill，不应该写"这个Skill可以生成漂亮PPT"。
它应该写"当用户需要把文章、大纲或演讲内容转成可演示HTML PPT时加载"。前者是广告，后者是Agent的判断条件。
这能解释为什么"把所有能力塞进一个大Agent"不是好方向。
大而全的harness会把工具定义、协议细节和长文档塞满上下文，带来更高延迟、更高token成本和更多误用。
反过来，薄harness只提供最小运行环境，Skill作为按需加载的能力包，才能让系统长期复利。
Harness：运行Agent的外层程序，负责模型循环、文件读写、上下文管理和安全边界。
更稳的架构是Thin Harness,Fat Skills：harness保持薄，负责跑模型循环、读写文件、管理上下文、执行权限和安全边界；
Skill变厚，承载流程、判断、领域知识、模板、脚本、资产、gotchas和eval；
确定性工具下沉给CLI、scripts或API；模型留在理解、判断、综合、取舍和表达这些更适合它的部分。
Thin Harness,Fat Skills：让Agent底层运行环境保持轻，把具体流程、领域知识、模板、脚本和失败经验放进按需加载的Skill里。
Skill质量要像代码质量一样维护
好Skill不是一次写完。它需要维护，而且要像代码质量一样维护。
一个比较可靠的生命周期是：
1.
先用无Skill的Agent跑真实任务，找到它会错在哪里；
2.
基于真实query写eval，包括正例、反例和forbidden load；
3.
先调description，确保该加载时加载，不该加载时不加载；
4.
写主体时删除显而易见的内容，只保留会改变模型行为的判断；
5.
把失败案例追加到gotchas，而不是不断加长主流程；改description或路由边界时补eval；
6.
再做跨模型测试，看不同编排模型对Skill触发和执行的差异。
Eval：用一组真实或模拟任务测试Skill是否按预期触发、执行和交付结果。
Gotchas：从真实失败里总结出来的"别这么做"清单，往往比正向说明更能提升Skill稳定性。
每个Skill都是一种税。
它进入索引后，每个会话、每个用户都在为它的name和description付上下文成本；
它被加载后，后续对话都在为主体内容付成本。
所以每一句都要问：没有这句，Agent会不会做错？如果不会，就删。
gotchas是最高价值内容，因为它们来自真实失败。
正向原则往往模型已经知道，负面边界才是专家经验。
设计Skill中"不要纯白纯黑""连续三页相同节奏是P0错误""文字不能压脸""AI图只在无合适真实图时使用"，都属于gotchas或强约束。
这也解释了为什么完全自动生成Skill只能做初稿。
模型可以帮你起草结构，但它无法凭空拥有你的失败样本、审美判断、行业边界和用户反馈。
真正有价值的是人把经验注入进去，再通过eval和gotchas让它持续变厚。
设计Skill的本质：把品味变成约束
设计类Skill不是简单的"AI会画图"。
它需要解决模型不稳定、图像限流、文字不锐利、排版不可控、风格一致性难判断等问题。
设计Skill的核心是把专业品味变成模型可执行的限制。
模型默认会收敛到一些平庸模式：
Tailwind大色块、紫色渐变、emoji堆砌、Inter字体、发光、过度圆角、无意义动效、信息密度失控。这不是模型没有审美素材，而是没有稳定的取舍原则。
所以设计Skill里最有价值的是主观但明确的约束：
•
不使用纯白和纯黑，降低刺眼和廉价感；
•
不让用户任意输入hex，只提供经过验证的主题色板；
•
不用紫色多彩渐变、发光和大面积blur作为主视觉捷径；
•
动画只在必要时使用，且只动transform和opacity；
•
图文卡片优先真实摄影和截图美化，AI生图只是兜底；
•
版式骨架先被人工验证，AI负责填充、组合和微调；
•
文字必须根据图像主体、明度和可读区域自适应落点、字色、遮罩和断行。
这些规则看起来限制自由，实际是在保护输出下限。设计类Skill的质量来自"替用户排除绝大多数会变丑的选项"。
好看不是玄学，而是可拆解、可编码、可检查的行业常识。
Skill的价值，就是把这些常识压进SKILL.md、模板、checklist、主题变量和后验检查里。
PPT Skill和社交媒体卡片Skill的一个共同方法，是把AI的任务从"自由设计"降级成"在高质量骨架里填充"。
PPT Skill里，10种页面布局、5套主题色、字体三级分工、7:5/6:6/8:4网格、hero与non-hero的节奏交替，构成了一个稳定的演示系统。AI不需要从零发明版式，只需要根据内容选择合适页面类型并填进去。
社交媒体卡片Skill进一步把场景校准到手机信息流：
3:4是主战场，1秒决定停不停下。它不是把PPT截图成竖图，而是重新定义了图文品类、版式比例、断行规则和素材优先级。
11个内容品类、两套视觉系统、28个版式骨架、截图美化、地图组件、真实图库和克制AI生图，共同构成了"内容平台视觉Skill"。
Logo Generator Skill也是同一逻辑：
不直接让图像模型一把梭生成Logo，因为图片模型的文字、结构和可编辑性不稳定；
它是先生成SVG变体，再做展示图和WebGL背景。这里把Logo本体、展示场景、交互背景拆成不同层，分别用最适合的技术处理。
人工沉淀审美系统，模型理解内容和语义，代码负责稳定排版和导出，图像模型只处理适合它的视觉部分。
这比单纯"让AI画一张图"更慢一点，但可控、可改、可复用，也更适合内容创作者长期使用。
Skill生态不能做成仓库列表
如果一个Skill能被图文、案例、评价、使用数据、作者、应用场景反向链接起来，它就不只是一个工具，而是一个社区节点。
反向链接：从使用案例、文章、图文或项目页面反过来链接到某个Skill，让人能看到它被谁用、怎么用、效果如何。
当前很多Skill展示的问题是：
列表很长，像GitHub仓库名；图标都一样；没有结果展示；没有评价指标；
多模态Skill也只用文本展示；用户不知道哪个适合自己。
推荐10个或20个精选Skill，并讲清楚怎么用，远好过给用户几千个列表。
每个Skill都应该像一个软件功能页。页面应该说明：
它解决什么问题，适合什么场景，需要输入什么，输出长什么样，典型提示词是什么，生成结果截图或视频，谁用过、怎么评价，有哪些常见失败情况，如何安装和修改。
这本质上需要强运营。
不是把名字列出来，而是一个一个挑、一个一个写介绍、展示结果，最好还有视频讲解。
GitHub是代码型Skill的天然托管地，因为Skill往往包含代码，需要版本管理；
GitHub有生态位、版权声明和分发基础；AI也熟悉Git和GitHub操作；开源还能覆盖所有Agent平台，不绑定单一产品。
但小红书适合做视觉内容和使用案例分发。
小红书的优势是内容感知、视觉展示、用户审美和评论体系。
PPT Skill和社交媒体卡片Skill都已经在小红书之外的人群中传播，比如咖啡馆主理人、数码测评、活动策划、餐厅、三线城市分享场景。这说明Skill能跨出AI圈。
应用商店式Skill分发也有潜力：更精准推荐、更低使用门槛、可能给创作者分成。
但对创作者来说，如果只在一个平台上架，就等于押注这个平台能做好产品、生态、分发和市场占领。
更稳的策略可能是：GitHub做基础分发和跨平台覆盖，平台Skillhub/应用商店做体验优化、运营推荐和商业转化。
未来的Skill平台，本质上会同时是App Store、GitHub、社区种草页、评价系统和Agent工具层。
普通用户真正卡在哪里
AI圈外的人并非不能用Skill。
实际观察中，咖啡馆主理人、数码测评、活动策划、健身教练等都能用出好结果。
真正卡点是交互心智。
很多人仍然用传统软件思维，以为一次生成就该完成：
不习惯通过chat连续调整；不知道可以要求AI改颜色、改字、修溢出、换图；不知道如何提供上下文和素材；也不知道如何从自己的工作流中抽Skill。
因此，Skill产品不仅要提供安装，还要提供使用教育。
行业Skill会是一个很重要的方向。很多行业有非常好的经验和客户洞察：
健身、法律、餐饮、活动策划、教育、商业化投放等。但行业专家不一定知道如何做Skill，也担心分享后被盗。
这里的关键不是把Skill作为服务添加项。
健身教练可以用Agent维护会员饮食、训练、有氧、提醒和反馈，提高客户粘性和服务效率。
法律从业者可以把琐碎文本处理、条文审查、格式检查做成辅助Skill，但核心判断仍由人完成。
餐饮和活动行业可以用图文Skill把真实图片和故事包装成可传播内容。
AI不能替代线下履约，但可以提高获客、沟通、维护和复用效率。
这类行业用户只需要基础启蒙：带他做一次需求分析，落地成一个Skill，他就知道边界在哪里。
每个行业都有先锋用户：有创造力、有好奇心、想用AI获得竞争优势。先服务这些人。
内容Skill：文章、产品和案例互相喂养
从我已有文章看，我正在形成一条很清晰的内容Skill路线：
不是为某个抽象AI概念写文章，是先做出一个能用的Skill，再把制作过程、设计判断和使用场景写成传播内容。
这类内容有几个特点。
PPT Skill最初来自一次AI和组织分享，观众问得最多的是PPT怎么做，于是从一次交付沉淀成开源Skill。这是副产品变主产品。
文章本身像说明书，但不是README。
它要讲清楚为什么这样设计、适合谁、边界在哪、真实效果如何，降低用户理解门槛。
产品演示本身就是内容资产。PPT截图、图文卡片、Logo展示图、Desk Card场景图，都可以成为传播素材。
Skill反过来也提升写作效率。社交卡片Skill可以把文章段落直接转成更适合小红书、公众号或Twitter的视觉卡片。
每篇文章都在扩展Skill的语义边界。
PPT是演示，Social Card是内容分发，Logo是项目品牌资产，Desk Card是硬件和环境UI，夜巡录则指向游戏demo工作流。
这说明Skill不只是"工具产品"，也是内容创作者的表达基础设施。
过去文章和产品是分开的：先做产品，再写推广。现在Skill、文章、案例、开源仓库、社交反馈会互相喂养。
这就是个人产品在Agent时代的复利飞轮。
Skill的边界会继续扩大
过去"插件"通常意味着软件里的一个按钮。现在Skill的边界可以明显更大。
浏览器是大众最熟悉的工作环境，如果Skill能以"现成脚本/使用案例/一键执行"的方式出现，会比裸露CLI或GitHub仓库更容易被理解。
硬件Skill则说明AI可以接管环境UI。
AI Desk Card的价值在于它把Agent的能力延伸到了物理环境：
安装固件、配置Wi-Fi、写cron、读取Memory、选择widget、刷新墨水屏，全流程由AI引导。用户不再面对App设置页，AI本身就是设置页。
游戏Skill代表更长链路的创作流程。
夜巡录开发手记里提到的"独立游戏demo Skill"，从玩法母题、原型、素材采集、绿幕抠图、contact sheet、视频生成、音乐、Electron打包、GitHub Actions到Release。
封装是一套跨程序员、美术、动画、作曲和运维的生产流水线。它的价值是把"做个原型"和"独立交付完整作品"之间的墙变薄。
Skill的未来不只会局限在聊天框里，它会扩展到浏览器、桌面、本地文件、硬件、内容平台、游戏引擎和真实工作环境。
Skill与Gene：手写经验和自动进化的边界
还有一个值得保留但需要谨慎使用的对比：Agent Skill与GEP Gene。
Skill更像人类预先沉淀的能力包：有明确创建者、明确边界、明确流程和版本。
Gene/Capsule这类概念强调运行中从成功经验里自动长出能力：带成功率、变异历史、适用上下文和自动修复机制。
Gene/Capsule：这里指从Agent反复执行中的成功路径里沉淀出的可复用经验单元，强调自动演化而不是人工手写。
这两者不是简单替代关系，是不同的层级。
Skill适合承载人的专家经验、审美、行业SOP、工具不变式和明确交付标准；
Gene适合从重复执行中捕捉成功路径，把临时试错变成可复用经验；Capsule类似把多个Gene组合成更长工作流。
从当前产品现实看，Skill仍是更可落地的单位，因为它能被写、被审、被发布、被解释、被传播。
但长期看，自动沉淀Skill/Gene化经验会成为方向：Agent先用通用工具试错，成功后把路径写回Skill或生成新的子能力。
这也回应了"自动沉淀Skill"的讨论。系统可以自动发现重复流程，但是否值得沉淀、如何命名、边界在哪里、哪些失败要写进gotchas，仍然需要人的判断。
真正理想的形态不是完全自动，也不是完全手写，而是人定义品味和边界，Agent负责收集证据、提出改动、补充eval和维护长尾经验。
盗用不是靠藏，防御方式是持续分发
Skill很难靠闭源防盗。即便不开源，只要看到产出结果，试用几次，也可能被复刻。
所以防御方式不是"藏起来"，而是开源覆盖更多平台，用影响力威慑过分盗用者，做自媒体让用户知道源头是谁，用持续迭代建立领先，用社区案例和评价体系形成品牌资产。
在产品壁垒降低的时代，个人产品如果没有渠道、资源和营销，就必须自己做宣发。以前自媒体是可选项，现在是基础设施。
平台真正该做什么
如果要做Skill平台，不能只押Skill。用户下载独立端的理由，首先是Agent基础体验足够好：
漂亮好用的客户端，多模型支持，尤其国产模型；文件、项目、memory、CLI、MCP、Skill管理；
权限和安全沙箱；长程任务和状态延续；多设备流转，手机控制桌面，桌面反向控制手机；官方高质量插件开箱即用。
一些高频、必须、常见的能力应该内置并打磨好，不要让用户自己折腾安装。
官方插件强，会形成壁垒。多设备、云端和本地互控，也会形成壁垒。
Skill与本地环境强相关时，移动端需要遥控PC。
Skill可跨端通用，但依赖本地文件、脚本、浏览器、CLI的Skill在移动端很难直接跑。
移动端适合轻量级从0到1创作；桌面端适合重任务和本地环境调用。
这个方向成立，但好Skill仍需要业务SOP、品味、测试和迭代。自动生成可以做初版，真正能稳定交付的Skill需要打磨。
一个完整Skill生命周期
如果把前面的判断收束成一条路径，一个完整Skill生命周期大概是这样的。
1
先发现真实需求，从自己或行业用户的重复工作开始。
2
再做一次高质量产物，不要先抽象，先用Agent解决真实任务。
3
然后抽象流程，识别可复用步骤、输入、输出、约束和工具。
4
接着工程化模板，把审美、版式、调用、验证和修复机制固化。
5
再做跨模型测试，好模型看上限，差模型保下限。
6
之后才是封装发布，GitHub托管，配README、示例和安装方式。
7
再做内容分发，用小红书、Twitter、公众号、视频展示结果。
8
然后收集反馈，从issue、评论区、用户案例和平台数据里找真实问题。反馈还要筛选，只吸收能提升泛化和稳定性的部分。
这条路看起来长，但它的本质很简单：
每一次真实任务，都不只是在完成任务，而是在积累下一次能调用的能力资产。
Agent时代最稀缺的是可复用的能力组织方式。
Skill之所以重要，是因为它第一次让人的经验、工作流和品味，有机会变成一种可以分发、调用、评价和持续迭代的商品。
这可能才是Agent生态里真正的大机会。