1. 从“会聊天”到“能干活”AI能力范式正在发生什么变化过去两年大多数人用AI的方式还停留在“对话框里问一句、答一句”。你问它怎么写一封邮件它给你一段文字你问它怎么修一段代码它给你一个片段。这种方式本质上还是“顾问模式”——它只动嘴不动手。但从2025年下半年开始一个明显的变化正在发生AI开始真正“动手干活”了。这个变化的载体就是Claude Skills。所谓Skills你可以把它理解成给AI装上的“技能包”。一个Skill就是一套封装好的指令、流程和工具调用逻辑AI加载之后就能按照预设的专业流程完成特定任务——比如自动整理会议纪要并生成待办清单、按照公司规范审查合同条款、把一堆散乱的用户反馈归类成产品需求文档。它不再是“你问我答”而是“你说目标我来执行”。我接触这套东西大概是在它刚开放扩展机制的时候。当时第一反应是这不就是给AI写“操作手册”吗但真正用起来之后才发现它的价值远不止于此。Skills解决的是一个根本性问题——AI的能力边界不再由模型本身决定而是由你给它装了多少技能决定。这就像手机出厂自带的功能有限但装了App之后它能干的事情就完全不一样了。目前围绕Claude Skills已经形成了一个相当可观的生态34个开源项目、11个技能商店覆盖了从开发工具、办公自动化、数据分析到创意生产的各个方向。这篇文章不打算给你列一个干巴巴的清单而是想从“怎么理解这个新范式”“这些资源到底怎么用”“哪些坑我替你踩过了”这几个角度把这件事讲透。不管你是刚听说Skills这个概念的新手还是已经在尝试搭建自己技能库的开发者应该都能从中找到有用的东西。2. 拆解Claude Skills的底层逻辑它凭什么能“干活”2.1 Skill的本质一份写给AI看的SOP很多人第一次接触Skills的时候会困惑这不就是提示词吗跟我在对话框里写一大段指令有什么区别区别很大。普通的提示词是“一次性”的你这次写得好下次还得重新写。而且提示词很难处理复杂流程——比如“先读取文件、再分析内容、然后调用某个接口、最后把结果写到指定位置”这种多步骤任务光靠一段提示词很难稳定执行。Skill则不同它是一份结构化的、可复用的、带工具调用能力的操作手册。它通常包含几个核心部分触发条件什么情况下这个Skill应该被激活执行流程一步一步的操作指令类似SOP工具依赖需要调用哪些外部工具或API输出规范结果应该以什么格式呈现异常处理遇到错误时怎么回退你可以把它想象成给一个新员工写的岗位操作手册。新员工AI本身很聪明但不知道你们公司的具体流程。你给他一份手册他就能按照标准流程干活了。Skill就是这份手册。2.2 为什么是现在三个条件同时成熟了Skills这个概念其实不算全新但为什么偏偏是现在爆发我观察下来是三个条件同时成熟了。第一模型的指令遵循能力跨过了临界点。早期的模型你给它一份多步骤指令它经常跳步、漏步、或者自作主张。但现在的主流模型在遵循复杂指令方面的稳定性已经足够支撑“按手册执行”这种模式了。这是基础。第二工具调用协议标准化了。以前每个平台调用外部工具的方式都不一样开发者要适配各种接口。现在主流的工具调用协议趋于统一一个Skill写好后迁移成本大大降低。这直接催生了开源社区的爆发。第三真实场景的需求倒逼。企业和个人用户已经不满足于“AI帮我写一段话”了他们要的是“AI帮我把这件事从头到尾办完”。需求在那里供给自然就来了。这三个条件缺一不可。早两年做Skills模型能力跟不上做出来也是玩具晚两年做可能已经被别人占了先机。现在正好是那个“刚刚好”的时间点。2.3 一个Skill从加载到执行的完整链路为了让你更直观地理解我拿一个实际场景来拆解。假设你有一个“周报生成Skill”它的工作流程是这样的触发你输入“帮我生成本周周报”系统识别到关键词激活对应Skill数据收集Skill指示AI去读取你指定的数据源比如项目管理工具里的任务列表、代码仓库的提交记录信息整合AI按照Skill里定义的模板把收集到的信息分类整理——完成了什么、遇到了什么问题、下周计划格式化输出按照Skill里定义的格式比如Markdown表格、或者特定文档模板生成最终结果人工确认把结果呈现给你你确认或修改后Skill可以进一步执行“发送给相关负责人”的操作整个链路里AI做的不是“生成文字”而是“执行流程”。这是本质区别。文字生成只是其中一个环节真正有价值的是流程的自动化。注意Skill的执行链路越长对错误处理的要求就越高。一个三步的Skill出错概率还可控一个十步的Skill如果中间没有检查点很容易一步错步步错。这是设计Skill时最容易被忽视的地方。3. 34个开源项目里哪些真正值得你花时间3.1 开源Skills项目的三种类型我把目前能找到的34个开源项目大致分了三类这个分类不是按功能分的而是按“你拿过来能怎么用”分的。第一类即插即用型。这类项目已经封装得非常完整你下载下来按照README配置好就能直接用了。典型代表是那些做“文档处理”“数据清洗”“邮件分类”的Skill。这类项目适合不想折腾、只想快速看到效果的人。缺点是灵活性差你很难改它的行为逻辑。第二类框架模板型。这类项目提供的是一个骨架你需要往里填充自己的业务逻辑。比如一个“客服问答Skill框架”它定义了整体的对话流程、知识库检索逻辑、升级人工的触发条件但具体的知识库内容、话术风格需要你自己配。这类项目适合有一定开发能力、想做定制化的人。第三类教学示例型。这类项目的价值不在于“用”而在于“学”。它把Skill的设计思路、代码结构、调试方法都展示得很清楚你照着读一遍就能自己写一个类似的。对于想深入理解Skills机制的人来说这类项目其实最有价值。3.2 筛选开源项目的四个硬指标开源项目质量参差不齐我踩过几次坑之后总结了一套筛选标准。你拿到一个Skills项目先看这四个指标指标合格线说明最近更新时间3个月内超过半年没更新的大概率已经跟当前版本不兼容了Issue响应情况有维护者回复看最近几个Issue有没有人管没人管的直接跳过文档完整度有配置说明示例只有代码没有文档的学习成本极高依赖复杂度依赖不超过5个依赖越多环境配置越容易出问题这四个指标里我最看重的是最近更新时间。Skills这个领域变化太快了半年前的写法可能现在已经不适用了。我见过一个很不错的项目逻辑设计得很精巧但因为它依赖的一个接口已经改了整个项目跑不起来作者也没再维护非常可惜。3.3 我实际用过的几个高价值项目类型具体项目名称我就不列了避免广告嫌疑但可以告诉你哪几类项目我实际用下来觉得价值最高。代码审查类Skill是我用得最多的。它能在你提交代码前自动检查常见问题——命名规范、潜在的边界条件遗漏、重复代码。它不是替代人工Review而是把那些低级问题先过滤掉让人工Review聚焦在架构和逻辑上。这类Skill的ROI非常高配置一次长期受益。会议纪要类Skill也很实用。它的核心不是“把语音转成文字”而是“从对话中提取决策项、待办事项、责任人、截止时间”。这个提取逻辑才是Skill的价值所在。我试过几个不同的实现差异主要在于提取的准确率和漏报率。数据清洗类Skill适合做数据分析的人。原始数据往往有很多格式问题——日期格式不统一、空值处理方式不一致、重复记录。这类Skill可以按照你定义的规则自动清洗省掉大量手工操作。提示不要一上来就装十几个Skill。Skill之间可能会冲突——比如两个Skill都试图处理同一类输入系统不知道该激活哪个。建议先从1-2个最刚需的场景开始跑顺了再逐步增加。4. 11个技能商店的生态格局去哪里找、怎么选4.1 技能商店和开源项目的本质区别很多人会把技能商店和开源项目混为一谈其实两者的定位完全不同。开源项目是“源码”你拿到的是原材料需要自己加工。技能商店是“成品”你拿到的是已经打包好的、可以直接安装使用的Skill。这个区别决定了你的使用策略如果你有开发能力且需求特殊去开源社区找源码改如果你只想快速解决问题去技能商店找现成的。技能商店的另一个价值是“发现”。开源项目散落在各个代码托管平台上你得知道关键词才能搜到。技能商店则做了分类和推荐你可以像逛应用商店一样浏览——看看有哪些类别的Skill、每个Skill的评分和评价、安装量多少。这种“逛”的体验对于还不清楚自己需要什么的人来说非常有帮助。4.2 当前技能商店的三种运营模式我观察下来目前11个技能商店大致有三种运营模式。平台官方商店由底层平台自己运营审核最严格质量最有保障但数量相对少更新速度也偏慢。适合对稳定性要求高的场景。社区驱动商店由社区维护任何人都可以提交Skill审核相对宽松。数量多、更新快但质量参差不齐。你需要自己判断哪些靠谱。这类商店通常有用户评分和评论机制可以作为参考。垂直领域商店专注于某个特定领域比如法律、医疗、教育。这类商店的Skill数量不多但专业深度够。如果你正好在那个领域工作价值很高。三种模式各有优劣我的建议是日常通用需求去平台官方商店找特定功能去社区商店专业领域需求去垂直商店。不要只盯着一个来源。4.3 在技能商店里“淘金”的实操方法在技能商店里选Skill跟在网上买东西的逻辑差不多但有几个细节需要特别注意。先看更新日志。一个持续更新的Skill说明作者在维护。更新日志里如果写着“修复了XX场景下的错误”说明作者在真实使用中发现问题并解决了这种Skill通常比较靠谱。再看权限要求。有些Skill需要读取你的文件、访问你的网络、调用外部接口。权限要求越多的Skill潜在风险越大。如果一个“天气查询Skill”要求读取你的通讯录那肯定有问题。安装前一定要看清楚它要什么权限。最后看用户评价的具体内容。不要只看星级要看文字评价。特别是那些提到“在XX场景下不好用”的评价往往比好评更有参考价值。因为好评可能是刷的但具体的差评通常是真的遇到了问题。我自己的习惯是先在商店里搜关键词把评分4星以上的都看一遍然后挑2-3个功能重叠的分别装上实际跑一周留下最好用的那个。这个过程花时间但比随便装一个然后发现不好用再换效率高得多。5. 从零搭建你的第一个Skill完整流程与避坑指南5.1 先想清楚什么任务适合做成Skill不是所有任务都适合做成Skill。我见过有人把“帮我写一首诗”做成Skill这就有点过度设计了——这种一次性、创意性的任务直接用对话模式就好。适合做成Skill的任务通常有这几个特征重复性高同样的流程你每周甚至每天都在做步骤明确有清晰的操作顺序不是靠灵感发挥输入输出格式相对固定每次处理的东西类型差不多有明确的成功标准你能判断做得好不好举个例子“把用户反馈分类整理成产品需求文档”就非常适合做成Skill。而“帮我想一个产品名字”就不适合因为后者太依赖创意和上下文没有标准流程。5.2 写Skill文件的核心结构一个Skill文件通常包含以下几个部分。我用一个“竞品分析Skill”作为例子来说明。元信息部分定义这个Skill叫什么、干什么用的、什么时候触发。这部分要写得精准因为系统靠它来判断是否激活这个Skill。输入定义部分说明这个Skill需要什么输入。比如竞品分析Skill需要竞品名称、分析维度功能/价格/用户评价、输出格式要求。执行步骤部分是核心。它把整个任务拆成一步步的指令。比如根据竞品名称搜索并收集该竞品的基本信息按照指定维度逐项分析并记录关键发现将分析结果与自家产品对比找出差异点按照输出格式要求生成结构化报告输出规范部分定义最终结果的格式。可以是Markdown、表格、JSON等。格式定义得越清晰输出越稳定。异常处理部分定义遇到问题时怎么办。比如“如果搜索不到竞品信息则提示用户手动提供资料”。这五个部分里执行步骤是最需要花心思的。步骤要足够具体但又不能太死板。太具体了AI遇到稍微不同的情况就不知道怎么处理太死板了输出会变得机械。这个平衡需要反复调试。5.3 调试Skill的三个阶段写完Skill文件只是开始真正的功夫在调试。第一阶段单步验证。把Skill的每个步骤单独拿出来测试确认每一步都能正确执行。比如竞品分析Skill的第一步是“搜索竞品信息”你就单独测这一步看搜索结果是否准确、是否完整。不要一上来就跑完整流程那样出了问题你都不知道是哪一步的错。第二阶段全流程跑通。单步都验证通过后串起来跑完整流程。这时候重点关注的是步骤之间的衔接——上一步的输出是否能被下一步正确使用、有没有信息丢失、格式是否匹配。第三阶段边界测试。这是最容易被跳过但最重要的一步。故意给一些“不正常”的输入——空输入、格式错误的输入、超出预期范围的输入——看Skill怎么处理。一个好的Skill应该能优雅地处理这些情况而不是直接崩溃或者给出莫名其妙的结果。我自己的经验是调试一个中等复杂度的Skill写文件可能只花1小时调试要花3-4小时。这个时间投入是值得的因为调试充分的Skill后续使用中出问题的概率会低很多。5.4 我踩过的三个坑第一个坑步骤写得太抽象。最开始我写Skill的时候喜欢用“分析用户需求”这种大而化之的表述。结果AI执行的时候每次理解都不一样输出极不稳定。后来我改成“从用户反馈中提取问题描述、影响范围、紧急程度、建议方案”输出立刻就稳定了。给AI的指令要具体到“做什么动作”而不是“达到什么效果”。第二个坑忽略了上下文长度限制。有一次我设计了一个Skill需要一次性处理大量文本。测试的时候用的小样本没问题实际用的时候输入了几万字直接超出了上下文窗口Skill执行到一半就断了。后来我改成“分段处理汇总”的模式才解决了这个问题。设计Skill时一定要考虑最坏情况下的输入规模。第三个坑没有版本管理。我改Skill文件的时候经常是直接覆盖原文件。结果有一次改坏了想回退到之前的版本发现没有备份。从那以后我养成了习惯每次修改前先复制一份文件名加上日期和版本号。这个习惯看起来笨但关键时刻能救命。6. 技能组合的进阶玩法让多个Skill协同工作6.1 什么是Skill编排单个Skill能解决单一问题但真实的工作场景往往是多个任务的组合。比如“处理一份合同”这个任务可能涉及读取合同文件、提取关键条款、比对标准模板、标记风险点、生成审查报告。这五个步骤每一个都可以是一个独立的Skill。Skill编排就是把这些独立的Skill按照业务逻辑串起来形成一个完整的工作流。用户只需要说“帮我审查这份合同”系统自动依次调用相关Skill最后输出一份完整的审查报告。这个思路其实跟软件开发里的“微服务架构”很像——每个服务只做一件事但通过编排可以完成复杂的业务逻辑。好处是每个Skill可以独立开发、独立测试、独立更新不会互相影响。6.2 编排的两种模式串行与并行串行编排是最简单的模式Skill A执行完把结果传给Skill BB执行完传给C依次类推。适合有严格先后顺序的任务。比如“先提取文本再翻译再校对”就是典型的串行。并行编排则是多个Skill同时执行最后汇总结果。适合那些互不依赖的子任务。比如“分析一份财报”可以同时启动三个Skill一个分析营收数据、一个分析成本结构、一个分析现金流最后把三份分析合并成一份完整报告。并行编排能大幅缩短总耗时。实际应用中通常是串行和并行混合使用。比如先串行地完成数据收集和清洗然后并行地做多维度分析最后再串行地生成报告。6.3 编排中的状态传递问题编排最大的技术难点是状态传递——上一个Skill的输出怎么准确地传给下一个Skill。我遇到过几种典型问题格式不匹配。Skill A输出的是Markdown表格Skill B期望的是JSON。这就需要中间加一个转换步骤或者统一所有Skill的输出格式。信息丢失。Skill A提取了10个字段但Skill B只需要其中3个传递过程中如果不注意可能把另外7个字段丢了而后面的Skill C又需要那7个字段。所以设计编排时要规划好每个环节需要保留哪些信息。错误传播。如果Skill A执行失败了Skill B拿到的是空数据或者错误数据它可能会产生莫名其妙的输出而不是明确报错。所以每个Skill都应该有输入校验发现上游数据有问题时主动报错而不是硬着头皮往下执行。解决这些问题的办法我实践下来最有效的是定义一个统一的中间数据格式所有Skill的输入输出都遵循这个格式。这样不管怎么编排数据都能顺畅流转。这个格式不需要很复杂通常一个结构化的JSON就够了。6.4 一个编排实例自动化竞品监测工作流我搭建过一个竞品监测的工作流用到了四个Skill的编排可以作为一个参考。Skill 1信息采集。定期抓取竞品官网、社交媒体、应用商店的最新动态。输出格式结构化列表每条包含来源、时间、内容摘要。Skill 2变化检测。对比本次采集结果和上次的结果找出新增或变化的内容。输出格式变化项列表标注变化类型新增/修改/删除。Skill 3影响分析。对每个变化项分析它可能对自家产品产生什么影响。输出格式影响评估表包含变化项、影响程度、建议应对措施。Skill 4报告生成。把分析结果整理成一份可读的周报。输出格式Markdown文档包含概述、重点变化、影响分析、建议。这四个Skill串行执行每周自动跑一次。我只需要在最后看一眼报告确认有没有需要特别关注的内容。整个流程从原来的手工几小时压缩到了自动几分钟加人工几分钟。注意编排的复杂度不要一次性堆太高。先从两个Skill的串联开始跑顺了再加第三个。每增加一个环节调试的复杂度是指数级上升的。7. 资源库的维护与迭代让技能库持续产生价值7.1 建立自己的Skill分类体系当你积累了一定数量的Skill之后管理就成了问题。我一开始是随便放在一个文件夹里后来发现找起来很费劲。后来我建立了一个简单的分类体系效率提升了很多。我的分类维度是按使用频率和场景日常高频每天或每周都会用到的放在最顺手的位置项目专用特定项目期间才会用的项目结束后归档实验性还在测试阶段的单独放一个区域避免干扰正式使用的Skill参考模板不直接使用但设计思路值得参考的作为学习资料保留这个分类不需要很复杂关键是你自己能快速找到需要的Skill。分类体系是为你服务的不是反过来。7.2 定期清理和更新Skill库跟衣柜一样需要定期整理。我的做法是每个月花半小时做一次“Skill盘点”过去一个月没用过的Skill考虑归档或删除有更新版本的Skill评估是否升级使用中发现问题但还没修复的Skill列入待办新发现的值得尝试的Skill加入测试区这个习惯让我避免了一个常见问题Skill越装越多但真正在用的还是最初那几个。装而不用不仅是浪费还会增加系统负担和选择困难。7.3 从使用者到贡献者当你用了一段时间的Skill之后你可能会发现某些Skill不完全符合你的需求或者你有一个别人没有的场景需要解决。这时候你可以考虑自己写Skill并分享出去。我自己就是从使用者变成贡献者的。最开始只是改别人的Skill来适配自己的需求后来发现有些改动具有通用性就整理出来分享给了社区。这个过程收获很大——不仅帮助了别人也从别人的反馈中学到了很多。写Skill分享的时候有几个点要注意文档要写清楚适用场景和限制条件不要让别人装了半天才发现不适用依赖要尽量少依赖越多别人越难用起来要提供示例一个能跑通的示例比一千字说明都管用。8. 关于AI能力新范式我的一些真实体会用了大半年Skills之后我最大的感受是AI的价值正在从“生成内容”转向“执行流程”。生成内容的天花板是“写得好”执行流程的天花板是“办得成”。后者对工作和生活的改变要大得多。另一个体会是Skill的质量取决于你对任务的理解深度。如果你自己都说不清楚这个任务的步骤和标准写出来的Skill肯定也是模糊的。写Skill的过程其实是在逼你把隐性知识显性化——把你脑子里“我知道怎么做但说不出来”的东西变成清晰的、可执行的步骤。这个过程本身就很有价值。还有一个反直觉的发现不是越复杂的Skill越好。我见过一些Skill设计得非常精巧考虑了各种边界情况但实际用起来反而不好用——因为太复杂了AI执行的时候容易迷失。好的Skill往往是简单的、聚焦的、只做一件事的。复杂的需求应该通过编排多个简单Skill来实现而不是写一个巨大的复杂Skill。最后说一个实际的小技巧给Skill起一个好名字。名字要能准确反映它的功能而且要好记。我早期起的名字都是“skill_001”“skill_002”这种后来发现根本记不住哪个是哪个。改成“周报生成器”“合同审查助手”“数据清洗工具”之后找起来快多了。这个细节看起来小但实际使用中影响很大。 
长河君 · 2026/10/12 21:11:33 · 阅读 1.2k Claude Skills实战指南：从34个开源项目到技能编排的AI新范式
1. 从“会聊天”到“能干活”AI能力范式正在发生什么变化过去两年大多数人用AI的方式还停留在“对话框里问一句、答一句”。你问它怎么写一封邮件它给你一段文字你问它怎么修一段代码它给你一个片段。这种方式本质上还是“顾问模式”——它只动嘴不动手。但从2025年下半年开始一个明显的变化正在发生AI开始真正“动手干活”了。这个变化的载体就是Claude Skills。所谓Skills你可以把它理解成给AI装上的“技能包”。一个Skill就是一套封装好的指令、流程和工具调用逻辑AI加载之后就能按照预设的专业流程完成特定任务——比如自动整理会议纪要并生成待办清单、按照公司规范审查合同条款、把一堆散乱的用户反馈归类成产品需求文档。它不再是“你问我答”而是“你说目标我来执行”。我接触这套东西大概是在它刚开放扩展机制的时候。当时第一反应是这不就是给AI写“操作手册”吗但真正用起来之后才发现它的价值远不止于此。Skills解决的是一个根本性问题——AI的能力边界不再由模型本身决定而是由你给它装了多少技能决定。这就像手机出厂自带的功能有限但装了App之后它能干的事情就完全不一样了。目前围绕Claude Skills已经形成了一个相当可观的生态34个开源项目、11个技能商店覆盖了从开发工具、办公自动化、数据分析到创意生产的各个方向。这篇文章不打算给你列一个干巴巴的清单而是想从“怎么理解这个新范式”“这些资源到底怎么用”“哪些坑我替你踩过了”这几个角度把这件事讲透。不管你是刚听说Skills这个概念的新手还是已经在尝试搭建自己技能库的开发者应该都能从中找到有用的东西。2. 拆解Claude Skills的底层逻辑它凭什么能“干活”2.1 Skill的本质一份写给AI看的SOP很多人第一次接触Skills的时候会困惑这不就是提示词吗跟我在对话框里写一大段指令有什么区别区别很大。普通的提示词是“一次性”的你这次写得好下次还得重新写。而且提示词很难处理复杂流程——比如“先读取文件、再分析内容、然后调用某个接口、最后把结果写到指定位置”这种多步骤任务光靠一段提示词很难稳定执行。Skill则不同它是一份结构化的、可复用的、带工具调用能力的操作手册。它通常包含几个核心部分触发条件什么情况下这个Skill应该被激活执行流程一步一步的操作指令类似SOP工具依赖需要调用哪些外部工具或API输出规范结果应该以什么格式呈现异常处理遇到错误时怎么回退你可以把它想象成给一个新员工写的岗位操作手册。新员工AI本身很聪明但不知道你们公司的具体流程。你给他一份手册他就能按照标准流程干活了。Skill就是这份手册。2.2 为什么是现在三个条件同时成熟了Skills这个概念其实不算全新但为什么偏偏是现在爆发我观察下来是三个条件同时成熟了。第一模型的指令遵循能力跨过了临界点。早期的模型你给它一份多步骤指令它经常跳步、漏步、或者自作主张。但现在的主流模型在遵循复杂指令方面的稳定性已经足够支撑“按手册执行”这种模式了。这是基础。第二工具调用协议标准化了。以前每个平台调用外部工具的方式都不一样开发者要适配各种接口。现在主流的工具调用协议趋于统一一个Skill写好后迁移成本大大降低。这直接催生了开源社区的爆发。第三真实场景的需求倒逼。企业和个人用户已经不满足于“AI帮我写一段话”了他们要的是“AI帮我把这件事从头到尾办完”。需求在那里供给自然就来了。这三个条件缺一不可。早两年做Skills模型能力跟不上做出来也是玩具晚两年做可能已经被别人占了先机。现在正好是那个“刚刚好”的时间点。2.3 一个Skill从加载到执行的完整链路为了让你更直观地理解我拿一个实际场景来拆解。假设你有一个“周报生成Skill”它的工作流程是这样的触发你输入“帮我生成本周周报”系统识别到关键词激活对应Skill数据收集Skill指示AI去读取你指定的数据源比如项目管理工具里的任务列表、代码仓库的提交记录信息整合AI按照Skill里定义的模板把收集到的信息分类整理——完成了什么、遇到了什么问题、下周计划格式化输出按照Skill里定义的格式比如Markdown表格、或者特定文档模板生成最终结果人工确认把结果呈现给你你确认或修改后Skill可以进一步执行“发送给相关负责人”的操作整个链路里AI做的不是“生成文字”而是“执行流程”。这是本质区别。文字生成只是其中一个环节真正有价值的是流程的自动化。注意Skill的执行链路越长对错误处理的要求就越高。一个三步的Skill出错概率还可控一个十步的Skill如果中间没有检查点很容易一步错步步错。这是设计Skill时最容易被忽视的地方。3. 34个开源项目里哪些真正值得你花时间3.1 开源Skills项目的三种类型我把目前能找到的34个开源项目大致分了三类这个分类不是按功能分的而是按“你拿过来能怎么用”分的。第一类即插即用型。这类项目已经封装得非常完整你下载下来按照README配置好就能直接用了。典型代表是那些做“文档处理”“数据清洗”“邮件分类”的Skill。这类项目适合不想折腾、只想快速看到效果的人。缺点是灵活性差你很难改它的行为逻辑。第二类框架模板型。这类项目提供的是一个骨架你需要往里填充自己的业务逻辑。比如一个“客服问答Skill框架”它定义了整体的对话流程、知识库检索逻辑、升级人工的触发条件但具体的知识库内容、话术风格需要你自己配。这类项目适合有一定开发能力、想做定制化的人。第三类教学示例型。这类项目的价值不在于“用”而在于“学”。它把Skill的设计思路、代码结构、调试方法都展示得很清楚你照着读一遍就能自己写一个类似的。对于想深入理解Skills机制的人来说这类项目其实最有价值。3.2 筛选开源项目的四个硬指标开源项目质量参差不齐我踩过几次坑之后总结了一套筛选标准。你拿到一个Skills项目先看这四个指标指标合格线说明最近更新时间3个月内超过半年没更新的大概率已经跟当前版本不兼容了Issue响应情况有维护者回复看最近几个Issue有没有人管没人管的直接跳过文档完整度有配置说明示例只有代码没有文档的学习成本极高依赖复杂度依赖不超过5个依赖越多环境配置越容易出问题这四个指标里我最看重的是最近更新时间。Skills这个领域变化太快了半年前的写法可能现在已经不适用了。我见过一个很不错的项目逻辑设计得很精巧但因为它依赖的一个接口已经改了整个项目跑不起来作者也没再维护非常可惜。3.3 我实际用过的几个高价值项目类型具体项目名称我就不列了避免广告嫌疑但可以告诉你哪几类项目我实际用下来觉得价值最高。代码审查类Skill是我用得最多的。它能在你提交代码前自动检查常见问题——命名规范、潜在的边界条件遗漏、重复代码。它不是替代人工Review而是把那些低级问题先过滤掉让人工Review聚焦在架构和逻辑上。这类Skill的ROI非常高配置一次长期受益。会议纪要类Skill也很实用。它的核心不是“把语音转成文字”而是“从对话中提取决策项、待办事项、责任人、截止时间”。这个提取逻辑才是Skill的价值所在。我试过几个不同的实现差异主要在于提取的准确率和漏报率。数据清洗类Skill适合做数据分析的人。原始数据往往有很多格式问题——日期格式不统一、空值处理方式不一致、重复记录。这类Skill可以按照你定义的规则自动清洗省掉大量手工操作。提示不要一上来就装十几个Skill。Skill之间可能会冲突——比如两个Skill都试图处理同一类输入系统不知道该激活哪个。建议先从1-2个最刚需的场景开始跑顺了再逐步增加。4. 11个技能商店的生态格局去哪里找、怎么选4.1 技能商店和开源项目的本质区别很多人会把技能商店和开源项目混为一谈其实两者的定位完全不同。开源项目是“源码”你拿到的是原材料需要自己加工。技能商店是“成品”你拿到的是已经打包好的、可以直接安装使用的Skill。这个区别决定了你的使用策略如果你有开发能力且需求特殊去开源社区找源码改如果你只想快速解决问题去技能商店找现成的。技能商店的另一个价值是“发现”。开源项目散落在各个代码托管平台上你得知道关键词才能搜到。技能商店则做了分类和推荐你可以像逛应用商店一样浏览——看看有哪些类别的Skill、每个Skill的评分和评价、安装量多少。这种“逛”的体验对于还不清楚自己需要什么的人来说非常有帮助。4.2 当前技能商店的三种运营模式我观察下来目前11个技能商店大致有三种运营模式。平台官方商店由底层平台自己运营审核最严格质量最有保障但数量相对少更新速度也偏慢。适合对稳定性要求高的场景。社区驱动商店由社区维护任何人都可以提交Skill审核相对宽松。数量多、更新快但质量参差不齐。你需要自己判断哪些靠谱。这类商店通常有用户评分和评论机制可以作为参考。垂直领域商店专注于某个特定领域比如法律、医疗、教育。这类商店的Skill数量不多但专业深度够。如果你正好在那个领域工作价值很高。三种模式各有优劣我的建议是日常通用需求去平台官方商店找特定功能去社区商店专业领域需求去垂直商店。不要只盯着一个来源。4.3 在技能商店里“淘金”的实操方法在技能商店里选Skill跟在网上买东西的逻辑差不多但有几个细节需要特别注意。先看更新日志。一个持续更新的Skill说明作者在维护。更新日志里如果写着“修复了XX场景下的错误”说明作者在真实使用中发现问题并解决了这种Skill通常比较靠谱。再看权限要求。有些Skill需要读取你的文件、访问你的网络、调用外部接口。权限要求越多的Skill潜在风险越大。如果一个“天气查询Skill”要求读取你的通讯录那肯定有问题。安装前一定要看清楚它要什么权限。最后看用户评价的具体内容。不要只看星级要看文字评价。特别是那些提到“在XX场景下不好用”的评价往往比好评更有参考价值。因为好评可能是刷的但具体的差评通常是真的遇到了问题。我自己的习惯是先在商店里搜关键词把评分4星以上的都看一遍然后挑2-3个功能重叠的分别装上实际跑一周留下最好用的那个。这个过程花时间但比随便装一个然后发现不好用再换效率高得多。5. 从零搭建你的第一个Skill完整流程与避坑指南5.1 先想清楚什么任务适合做成Skill不是所有任务都适合做成Skill。我见过有人把“帮我写一首诗”做成Skill这就有点过度设计了——这种一次性、创意性的任务直接用对话模式就好。适合做成Skill的任务通常有这几个特征重复性高同样的流程你每周甚至每天都在做步骤明确有清晰的操作顺序不是靠灵感发挥输入输出格式相对固定每次处理的东西类型差不多有明确的成功标准你能判断做得好不好举个例子“把用户反馈分类整理成产品需求文档”就非常适合做成Skill。而“帮我想一个产品名字”就不适合因为后者太依赖创意和上下文没有标准流程。5.2 写Skill文件的核心结构一个Skill文件通常包含以下几个部分。我用一个“竞品分析Skill”作为例子来说明。元信息部分定义这个Skill叫什么、干什么用的、什么时候触发。这部分要写得精准因为系统靠它来判断是否激活这个Skill。输入定义部分说明这个Skill需要什么输入。比如竞品分析Skill需要竞品名称、分析维度功能/价格/用户评价、输出格式要求。执行步骤部分是核心。它把整个任务拆成一步步的指令。比如根据竞品名称搜索并收集该竞品的基本信息按照指定维度逐项分析并记录关键发现将分析结果与自家产品对比找出差异点按照输出格式要求生成结构化报告输出规范部分定义最终结果的格式。可以是Markdown、表格、JSON等。格式定义得越清晰输出越稳定。异常处理部分定义遇到问题时怎么办。比如“如果搜索不到竞品信息则提示用户手动提供资料”。这五个部分里执行步骤是最需要花心思的。步骤要足够具体但又不能太死板。太具体了AI遇到稍微不同的情况就不知道怎么处理太死板了输出会变得机械。这个平衡需要反复调试。5.3 调试Skill的三个阶段写完Skill文件只是开始真正的功夫在调试。第一阶段单步验证。把Skill的每个步骤单独拿出来测试确认每一步都能正确执行。比如竞品分析Skill的第一步是“搜索竞品信息”你就单独测这一步看搜索结果是否准确、是否完整。不要一上来就跑完整流程那样出了问题你都不知道是哪一步的错。第二阶段全流程跑通。单步都验证通过后串起来跑完整流程。这时候重点关注的是步骤之间的衔接——上一步的输出是否能被下一步正确使用、有没有信息丢失、格式是否匹配。第三阶段边界测试。这是最容易被跳过但最重要的一步。故意给一些“不正常”的输入——空输入、格式错误的输入、超出预期范围的输入——看Skill怎么处理。一个好的Skill应该能优雅地处理这些情况而不是直接崩溃或者给出莫名其妙的结果。我自己的经验是调试一个中等复杂度的Skill写文件可能只花1小时调试要花3-4小时。这个时间投入是值得的因为调试充分的Skill后续使用中出问题的概率会低很多。5.4 我踩过的三个坑第一个坑步骤写得太抽象。最开始我写Skill的时候喜欢用“分析用户需求”这种大而化之的表述。结果AI执行的时候每次理解都不一样输出极不稳定。后来我改成“从用户反馈中提取问题描述、影响范围、紧急程度、建议方案”输出立刻就稳定了。给AI的指令要具体到“做什么动作”而不是“达到什么效果”。第二个坑忽略了上下文长度限制。有一次我设计了一个Skill需要一次性处理大量文本。测试的时候用的小样本没问题实际用的时候输入了几万字直接超出了上下文窗口Skill执行到一半就断了。后来我改成“分段处理汇总”的模式才解决了这个问题。设计Skill时一定要考虑最坏情况下的输入规模。第三个坑没有版本管理。我改Skill文件的时候经常是直接覆盖原文件。结果有一次改坏了想回退到之前的版本发现没有备份。从那以后我养成了习惯每次修改前先复制一份文件名加上日期和版本号。这个习惯看起来笨但关键时刻能救命。6. 技能组合的进阶玩法让多个Skill协同工作6.1 什么是Skill编排单个Skill能解决单一问题但真实的工作场景往往是多个任务的组合。比如“处理一份合同”这个任务可能涉及读取合同文件、提取关键条款、比对标准模板、标记风险点、生成审查报告。这五个步骤每一个都可以是一个独立的Skill。Skill编排就是把这些独立的Skill按照业务逻辑串起来形成一个完整的工作流。用户只需要说“帮我审查这份合同”系统自动依次调用相关Skill最后输出一份完整的审查报告。这个思路其实跟软件开发里的“微服务架构”很像——每个服务只做一件事但通过编排可以完成复杂的业务逻辑。好处是每个Skill可以独立开发、独立测试、独立更新不会互相影响。6.2 编排的两种模式串行与并行串行编排是最简单的模式Skill A执行完把结果传给Skill BB执行完传给C依次类推。适合有严格先后顺序的任务。比如“先提取文本再翻译再校对”就是典型的串行。并行编排则是多个Skill同时执行最后汇总结果。适合那些互不依赖的子任务。比如“分析一份财报”可以同时启动三个Skill一个分析营收数据、一个分析成本结构、一个分析现金流最后把三份分析合并成一份完整报告。并行编排能大幅缩短总耗时。实际应用中通常是串行和并行混合使用。比如先串行地完成数据收集和清洗然后并行地做多维度分析最后再串行地生成报告。6.3 编排中的状态传递问题编排最大的技术难点是状态传递——上一个Skill的输出怎么准确地传给下一个Skill。我遇到过几种典型问题格式不匹配。Skill A输出的是Markdown表格Skill B期望的是JSON。这就需要中间加一个转换步骤或者统一所有Skill的输出格式。信息丢失。Skill A提取了10个字段但Skill B只需要其中3个传递过程中如果不注意可能把另外7个字段丢了而后面的Skill C又需要那7个字段。所以设计编排时要规划好每个环节需要保留哪些信息。错误传播。如果Skill A执行失败了Skill B拿到的是空数据或者错误数据它可能会产生莫名其妙的输出而不是明确报错。所以每个Skill都应该有输入校验发现上游数据有问题时主动报错而不是硬着头皮往下执行。解决这些问题的办法我实践下来最有效的是定义一个统一的中间数据格式所有Skill的输入输出都遵循这个格式。这样不管怎么编排数据都能顺畅流转。这个格式不需要很复杂通常一个结构化的JSON就够了。6.4 一个编排实例自动化竞品监测工作流我搭建过一个竞品监测的工作流用到了四个Skill的编排可以作为一个参考。Skill 1信息采集。定期抓取竞品官网、社交媒体、应用商店的最新动态。输出格式结构化列表每条包含来源、时间、内容摘要。Skill 2变化检测。对比本次采集结果和上次的结果找出新增或变化的内容。输出格式变化项列表标注变化类型新增/修改/删除。Skill 3影响分析。对每个变化项分析它可能对自家产品产生什么影响。输出格式影响评估表包含变化项、影响程度、建议应对措施。Skill 4报告生成。把分析结果整理成一份可读的周报。输出格式Markdown文档包含概述、重点变化、影响分析、建议。这四个Skill串行执行每周自动跑一次。我只需要在最后看一眼报告确认有没有需要特别关注的内容。整个流程从原来的手工几小时压缩到了自动几分钟加人工几分钟。注意编排的复杂度不要一次性堆太高。先从两个Skill的串联开始跑顺了再加第三个。每增加一个环节调试的复杂度是指数级上升的。7. 资源库的维护与迭代让技能库持续产生价值7.1 建立自己的Skill分类体系当你积累了一定数量的Skill之后管理就成了问题。我一开始是随便放在一个文件夹里后来发现找起来很费劲。后来我建立了一个简单的分类体系效率提升了很多。我的分类维度是按使用频率和场景日常高频每天或每周都会用到的放在最顺手的位置项目专用特定项目期间才会用的项目结束后归档实验性还在测试阶段的单独放一个区域避免干扰正式使用的Skill参考模板不直接使用但设计思路值得参考的作为学习资料保留这个分类不需要很复杂关键是你自己能快速找到需要的Skill。分类体系是为你服务的不是反过来。7.2 定期清理和更新Skill库跟衣柜一样需要定期整理。我的做法是每个月花半小时做一次“Skill盘点”过去一个月没用过的Skill考虑归档或删除有更新版本的Skill评估是否升级使用中发现问题但还没修复的Skill列入待办新发现的值得尝试的Skill加入测试区这个习惯让我避免了一个常见问题Skill越装越多但真正在用的还是最初那几个。装而不用不仅是浪费还会增加系统负担和选择困难。7.3 从使用者到贡献者当你用了一段时间的Skill之后你可能会发现某些Skill不完全符合你的需求或者你有一个别人没有的场景需要解决。这时候你可以考虑自己写Skill并分享出去。我自己就是从使用者变成贡献者的。最开始只是改别人的Skill来适配自己的需求后来发现有些改动具有通用性就整理出来分享给了社区。这个过程收获很大——不仅帮助了别人也从别人的反馈中学到了很多。写Skill分享的时候有几个点要注意文档要写清楚适用场景和限制条件不要让别人装了半天才发现不适用依赖要尽量少依赖越多别人越难用起来要提供示例一个能跑通的示例比一千字说明都管用。8. 关于AI能力新范式我的一些真实体会用了大半年Skills之后我最大的感受是AI的价值正在从“生成内容”转向“执行流程”。生成内容的天花板是“写得好”执行流程的天花板是“办得成”。后者对工作和生活的改变要大得多。另一个体会是Skill的质量取决于你对任务的理解深度。如果你自己都说不清楚这个任务的步骤和标准写出来的Skill肯定也是模糊的。写Skill的过程其实是在逼你把隐性知识显性化——把你脑子里“我知道怎么做但说不出来”的东西变成清晰的、可执行的步骤。这个过程本身就很有价值。还有一个反直觉的发现不是越复杂的Skill越好。我见过一些Skill设计得非常精巧考虑了各种边界情况但实际用起来反而不好用——因为太复杂了AI执行的时候容易迷失。好的Skill往往是简单的、聚焦的、只做一件事的。复杂的需求应该通过编排多个简单Skill来实现而不是写一个巨大的复杂Skill。最后说一个实际的小技巧给Skill起一个好名字。名字要能准确反映它的功能而且要好记。我早期起的名字都是“skill_001”“skill_002”这种后来发现根本记不住哪个是哪个。改成“周报生成器”“合同审查助手”“数据清洗工具”之后找起来快多了。这个细节看起来小但实际使用中影响很大。