2025年下半年开始AI编程圈子里冒出一个高频词Skills。GitHub上以skills命名的仓库几乎每天都有新星冒出来Claude Code、OpenCode、Codex、Cursor这些主流工具全都在往这个方向发力吴恩达专门为Agent Skills写了教程中文社区里的baoyu skills、superpowers这类合集项目动辄几千星。圈子里聊天的内容也变了以前是“你用的哪个模型”现在是“你给它配了哪些skills”。这篇文章就把这个新东西从里到外讲清楚Skills到底是什么、为什么突然这么火、现成有哪些值得装、怎么自己写一个、以及它和MCP工具到底怎么配合。适合正在用或者准备用AI编程助手的开发者也适合想给团队沉淀一套AI工作流的人参考。我尽量多用实际操作中碰到的例子少讲虚的。1. Skills赛道爆发从Claude到OpenCodeAI能力交付方式正在变天1.1 Agent Skills从哪来2025年年中Anthropic在Claude Code里正式引入了Agent Skills机制。它用一种叫SKILL.md的文件格式把“提示词执行步骤规则模板参考材料”打包成一个可复用的技能单元。没过多久OpenCode、Codex、Cursor这些工具也陆续跟进同一套思路整个生态一下就热闹起来了。这场爆发的导火索我觉得有三根。第一根是吴恩达专门写了Agent Skills的教程把skills从一个工程小技巧拔高到了Agent落地方法论层面。他提出的观点很直接大模型的通用能力已经很强但要让Agent在特定场景稳定干活必须给它“专门训练过的行为规范”而Skills正是这种规范最轻量的载体。这个观点一出很多原本只关注模型原理的开发者开始认真研究这个东西。第二根是superpowers这类高质量合集的出现。它把Claude Code的能力扩展做到了近似开箱即用的程度——代码审查、调试排错、文档生成、架构分析几十个实用技能打包维护装上就能明显感觉到AI“变懂事了”。口碑一传开大家才发现原来补上skills之后效果差这么多。第三根是中文社区的快速跟进。baoyu skills这类项目把优质skills集结成册做了大量中文本地化处理特别是PPT制作、结构图生成这些办公场景拿过来就能用。国内开发者的参与度大大提升也让skills话题在中文技术社区迅速破圈。1.2 为什么“会写提示词”变成了“会写Skills”早期用AI编程大家的习惯是临时写一段prompt把需求说清楚让模型自由发挥。这种方式的问题在于模型每次都是“零经验上岗”。同一个项目里你上周让它生成测试用例它写得还行这周换个说法它又写得东一榔头西一棒子。根本原因是对话式prompt没有状态模型记不住你偏好的输出格式、你团队的规范、你踩过的坑。Skills的思维方式跟prompt完全不一样。它更像给AI办入职培训把岗位职责、操作规范、常见问题处理办法、输出模板全部写成文档放到指定目录AI在遇到匹配场景时自动翻出说明书照着做。这样即使换了对话上下文甚至换了项目只要skill还在模型的输出水平就能保持稳定。我自己最深的感觉是prompt决定AI的下限Skills决定它的上限。没有skill的情况下你每次都要把需求从头到尾描述一遍AI的表现完全取决于你这次的措辞够不够精准有了skill它心里有了一套固定的操作框架你只需要说一句“按老规矩办”它就知道该走哪条流程、按什么格式交活。1.3 生态现状值得关注的热门skills项目GitHub上的skills资源已经多到需要整理的程度了。我大致分成几类。一类是“全家桶型”合集比如superpowers作者把几十个实用技能打包维护覆盖代码审查、文档撰写、调试排错、架构分析这些高频场景。这种集合适合同时提升多个方面的AI表现装完立刻能感受到整体变化。一类是“场景特化型”比如数学建模skills、测试用例skills这种针对单一任务的精细包。它们的特点是流程非常聚焦一个skill只干一件事但干得特别深。还有一类是“元技能型”比如skills creator专门用来辅助编写新skill。你可以指挥它分析你现有的工作流帮你设计SKILL.md的结构相当于“制造工具的制造工具”适合有一定基础后自己动手时使用。中文社区这边baoyu skills这类项目特别适合入门它对英文场景做了大量本地化办公场景直接拿过来用效果就很明显。mattpocock的skills则更聚焦TypeScript和前端工程质量如果你主力写前端他的包值得仔细研究。还有一些命名让人摸不着头脑的个人项目比如“前任skills”纯粹靠名字先出圈内容反而成了次要的——这也能看出skills赛道的热度有多高什么风格的创作者都涌进来了。2. Agent Skills的核心机制一个Skill包到底装了什么2.1 SKILL.md的骨架frontmatter和正文要理解Skills最好的方法是直接拆开一个SKILL.md看看。一个标准的skill其实就是一个目录目录里最核心的文件叫SKILL.md此外还可以带脚本、模板、参考文档等附属资源。SKILL.md开头是一段YAML格式的frontmatter里面有name和description两个字段。name是这个技能的名字description则是一段“什么情况下应该启用这个技能”的自然语言描述。这里有个特别关键的细节AI代理判断是否调用某个skill靠的不是用户明确说出技能名而是拿用户的请求和description做语义匹配。也就是说description写得准不准直接决定了这个skill会不会在正确的时候被触发。很多新手写的skill不生效问题往往就出在description太模糊。写“用于代码审查”模型根本不知道该不该在你让它“帮我看看这个PR”的时候触发改成“当用户要求检查代码质量、发现bug、评估可维护性或对Pull Request提出改进建议时使用”触发率立刻就上来了。正文部分则是技能的核心内容一般包含这么几块触发场景的进一步说明、完成任务的详细执行步骤、必须遵守的约束规则、输出结果的格式模板、可参考的示例。有些skill还会引用目录里的其他文件比如一份团队的代码规范、一组常用正则模板、一个自动化脚本。这些附属资源会在AI执行任务时被一并读取补充上下文。2.2 Skills的加载与触发逻辑不同工具对skills的存放位置要求略有差异但思路差不多一种是放在用户级全局目录比如~/.claude/skills对所有项目生效一种是放在项目级目录比如.claude/skills只对这个仓库生效。我个人建议把通用的、跟业务无关的技能放全局把和具体业务强相关的技能放项目级避免项目上下文被无关技能污染。加载机制上多数工具的做法是在对话开始时扫描所有可见的skill目录读取每个SKILL.md的frontmatter但不会把完整的skill正文全部塞进上下文而是先让模型知道“有这些技能可用”。等到用户请求和某个description匹配才把对应的完整内容和附属资源加载进来。这种“先看目录、按需取用”的设计是为了省上下文窗口。几百个skill的正文如果一次性全加载Token消耗根本扛不住AI真正执行时也容易被无关内容干扰。理解了这个机制你就会明白为什么description的精准度那么重要——它是AI决定“要不要完整读取这个文件”的唯一依据。2.3 Skill和普通Prompt、MCP的本质区别这里容易混淆三个概念。普通Prompt是一次性的对话指令用完即弃没有结构、没有复用性。Skill是把固定流程和规范固化成文件可以跨会话、跨项目复用并且能被AI自主识别和触发。MCP则是给AI提供“动手能力”让它能调用外部工具、访问外部数据。打个比方Prompt是口头交代一句“帮我把这个文件整理一下”Skill是甩给AI一本《文件整理SOP手册》MCP则是给了AI一双手——能打开文件柜、能操作电脑。三者不是替代关系而是配合关系。很多人在网上搜“skills如何调用MCP工具”本质上就是在找这两者配合的接口规范这个我后面专门用一章聊。2.4 用“部门SOP手册”来理解Skill如果觉得上面的技术描述有点绕可以换个职场场景来理解。一个新人入职光靠聪明是干不好活的得有部门SOP客户投诉怎么办、日报怎么写、代码提交之前要跑哪些检查。公司的SOP就相当于skill新人相当于AI代理。没有SOP新人每次处理问题都全凭临场发挥做得对不对看运气有了SOP他能稳定地按正确路径执行而管理者要做的只是在SOP里写清楚“什么情况适用哪份文档”。AI代理不是神它就是一个需要SOP约束的新人Skills提供的就是这套SOP。理解了这层关系后面的选型、开发、避坑就都好说了。3. 按场景挑选现成Skills前端、PPT、测试、建模、安全巡检的实用清单3.1 前端开发类从设计稿还原到移动端适配前端是我认为Skills收益最明显的领域因为前端工作里“格式化输出”的比例特别高给我一张设计稿还原成页面给我一个需求写出组件给我一个接口文档生成TypeScript类型。社区里讨论度最高的一类skill是“图片还原设计稿”你只要把UI设计截图丢给AI它就能按像素级别还原出可运行的HTML/CSS代码。这类skill的工作流通常是先让视觉模型分析图片里的布局结构、颜色、字体再结合前端框架规范生成组件代码最后还附带一段自检清单让AI逐个检查间距、圆角、响应式断点是否与设计稿一致。实测下来配合这类skill把一张中等复杂度的登录页设计稿变成能跑的React代码基本就是一两分钟的事。Cursor用户问“前端有哪些好用的skills”这类图片还原技能基本是必推的。移动端开发也有对应的skills推荐主要解决的是“适配规范”问题不同屏幕尺寸的适配方案、rem/vw单位换算规则、iOS安全区域处理、触控区域最小尺寸限制。你把这些规则写进skillAI生成的移动端页面就不会再出现“按钮只做了一半大”这种低级错误。实际项目里哪怕只是把团队的适配规范整理成一个skill都比每次重复口头交代要靠谱得多。3.2 PPT、结构图与办公文档类办公文档是Skills被严重低估的战场。GitHub上有不少专门做PPT的skills比如配合Claude Code生成PPT的项目整个过程是你告诉AI主题和提纲它先生成内容大纲再调用脚本把内容填入模板最终产出可直接演示的PPT文件。这里skill真正解决的不是“能不能做PPT”而是AI知道怎么排版、怎么控制字体层级、怎么分配每页信息量——这些都是光靠prompt很难稳定复现的隐性知识。很多人以为做PPT主要靠模板其实排版规范和内容密度控制才是AI最容易翻车的地方写进skill之后稳定得多。结构图类skills同样实用。你可以让AI根据一段文字描述自动生成架构图、流程图、思维导图输出mermaid或draw.io格式再通过MCP工具渲染成图片。只需要把需求说明白从“画一个用户登录流程的时序图”到“把整个系统微服务架构图画出来”AI都能按统一风格产出。做技术方案、写设计文档的时候这类skill的效率提升非常明显。3.3 测试用例类让AI按方法论输出可执行用例测试用例生成是另一个被反复提起的场景。好的测试用例skill不会只是让AI“写几个用例”而是会内置一套测试设计方法论等价类划分、边界值分析、场景法、错误推测法并且强制要求输出用例编号、优先级、前置条件、操作步骤、预期结果。如果配合Pytest或Jest的模板它还能直接生成可执行的测试代码。我见过一个团队把自家核心业务流程的需要覆盖点整理成skill之后每次需求变更AI都能按这个基线自动补齐影响范围内的测试用例人工只需要做最后审核。这个场景最能体现skills“沉淀团队经验”的价值——老测试员的测试思路被固化成了文件新项目、新同事都能直接复用。3.4 数学建模类从题目到论文的全流程规范数学建模是我无意中发现的高价值场景。数学建模skills推荐里比较成熟的做法是把建模流程规范成“问题理解→模型选择→模型建立→模型求解→结果分析→论文撰写”六个阶段每个阶段都有明确的输出要求。更重要的是这类skill会把常用算法库的信息带进去比如线性规划、神经网络、遗传算法的适用条件和代码模板省去AI在建模过程中频繁“自己发明轮子”的尴尬。对参加数学建模比赛的同学来说配合这类skill从拿到题目到产出完整论文的效率能提升一个档次。这套流程同样适用于做研究报告、写方案论证文档的场景原理是相通的。3.5 代码库分析与Codex场景在OpenAI Codex这类工具里skills常被用来做“项目体检”。比如“分析项目的skills”这类包会自动引导AI完成仓库结构梳理、依赖关系分析、技术债评估、性能瓶颈定位、安全风险排查等动作最后输出一份结构化的项目健康报告。和人工分析相比它最大的优势是可重复。同一个项目在不同时间跑同一份skill能形成前后对比方便追踪“上次发现的问题是否解决”“有没有引入新的风险”。Codex常用skills里那些定位为“项目分析”的基本都遵循这个设计思路先扫描仓库再输出结构化报告最后给出建议优先级。这种能力对新接手一个项目、或者做代码审计的场合特别有价值。3.6 安全评估类只能在授权范围内使用渗透测试相关的skills在圈内讨论热度一直很高。严格说的话这类技能应该叫“安全评估辅助技能”更准确——它面向的是有授权前提下的安全测试场景帮助安全工程师提升效率比如信息收集、漏洞检测流程标准化、渗透测试报告自动生成。这类skill会把安全测试的过程规范化强制要求先确认授权范围和测试边界再按步骤执行并自动生成格式合规的评估报告。如果你所在的团队做安全相关工作注意只在合法、授权的项目范围内使用这类技能排查边界一定要设定清楚。毕竟工具本身没有立场使用者必须守住底线。下面把上面几类场景做一个汇总方便你按图索骥场景推荐技能类型核心能力典型项目/示例前端开发设计稿还原、移动端适配图片转代码、适配规范约束图片还原设计稿、mattpococks skills办公文档PPT制作、结构图生成内容结构化排版、架构图绘制claude code ppt skills、结构图skills测试测试用例生成测试方法论可执行代码输出测试用例skills数学建模建模全流程问题分析算法选型论文输出数学建模skills代码分析项目健康体检架构梳理、技术债评估、风险排查codex常用skills安全授权环境安全评估流程规范化、报告自动生成渗透测试skills需授权4. 手把手开发自己的第一个Skill从需求拆解到发布复用的完整链路4.1 选一个高频重复的痛点场景开发skills的第一步不是写文件而是找场景。选场景的标准很简单这件事你是不是每周都要干当前AI每次干得是不是都不尽如人意如果两个答案都是肯定的就值得固化成skill。我建议新手从“小而痛”的场景入手先别做那种试图覆盖整个岗位职责的“超级技能”。做一个“当用户要求生成数据库表结构的DDL建表语句时使用”的精准技能比做一个“负责整个后端开发”的万能技能有效得多。我把选场景的过程拆成四步。第一记录你最近两周里反复让AI做的同类任务哪怕每个任务只是稍有变化。第二挑出输出格式相对固定、判断标准相对明确的那一类。第三把你平时要求AI的那些“潜规则”全部显式写下来比如“表名用下划线命名”“必须有created_at和updated_at字段”“所有字段加注释”。第四考虑让skill自动带上生成模板比如建表语句的标准模板这样AI就不是从零开始写而是填充模板。4.2 description是灵魂花一半时间写它前面反复提过description直接决定触发准确性所以值得投入足够精力。好的description应该包含三要素什么时候用触发条件、给谁用适用对象、不包含什么排除边界。举例来说一个写数据库建表语句的skilldescription可以写成“当用户要求创建数据库表、设计数据模型、生成DDL语句或调整已有表结构时使用。适用于MySQL和PostgreSQL。不适用于数据迁移脚本或ETL任务。”这段描述既说了触发场景又划了排除边界模型就不会在用户问“帮我迁移用户表数据”时错误触发。写description的时候有个细节要多写几个同义表达。AI做语义匹配时描述里覆盖的同义说法越多命中率越高。比如“生成DDL”和“设计表结构”和“建表”在用户嘴里可能是同一件事你都要写进去。很多人抱怨skill“该触发时不触发不该触发时乱触发”八成就是description写的同义表达太少排除边界又没划清楚。4.3 编写SKILL.md主体步骤、规则、模板SKILL.md的正文部分是执行说明书我的经验是遵循“步骤可执行、规则可检查、输出有模板”三个原则。步骤要拆到让AI不需要“动脑”的程度。比如“分析需求”这种步骤就太抽象AI不知道分析到什么程度算完更好的写法是“第一步列出需求中出现的所有实体及属性第二步识别实体间的一对多、多对多关系第三步标注主外键和索引需求”。你拆得越细输出越稳定。规则部分要显式化。别指望AI“应该”知道你的团队规范。凡是要求就写成检查清单全表必须有主键字符串长度超过256的字段必须用TEXT类型金额字段用DECIMAL(10,2)日期统一用DATETIME。检查清单的价值在于AI可以在输出完成后逐条自检你审阅时也能对着清单快速核对。输出模板是保证格式一致性的利器。给AI一个标准模板让它“填空”而不是自由发挥。模板里把必填字段、注释格式、通用选项都预留好。实测下来有模板的skill输出和没模板的格式规范程度完全是两个水平。尤其当输出要给团队其他人看的时候格式统一本身就省掉大量沟通成本。4.4 加入参考文件别把所有东西塞进一个文件很多新手写skill喜欢把内容全塞进一个SKILL.md结果文件越来越大动辄上万字既浪费上下文又让AI抓不住重点。更好的做法是“主文件附件”结构SKILL.md只写触发条件和核心流程把详细规范、模板、示例代码放到同目录的独立文件比如schema.md、template.sql、examples/目录在SKILL.md里用相对路径引用即可。这样做还有一个额外好处附件可以被多个skill共享。比如你的团队有一套统一的代码风格规范完全可以把它做成一个独立文件让多个skill各自引用而不是在每个skill里复制一份。维护的时候只改一处所有skill同步生效这是我自己非常推荐的做法。4.5 本地安装与测试写完skill之后要本地验证。以Claude Code为例全局skills放到~/.claude/skills/你的技能名/目录下项目级skills放到项目根目录的.claude/skills/里。目录名就是技能名建议用连字符小写命名比如db-schema-builder。放好之后重启会话让工具重新扫描skill目录。测试skill时我有一套固定的验证方法。第一轮用description里写到的典型场景发请求比如“帮我建个用户订单表”看是否触发、输出是否符合预期。第二轮用边缘场景发请求比如“帮我写一个数据迁移脚本”确认它不会错误触发。第三轮故意给一些不完整的需求看AI能否通过skill里的步骤主动追问或自行补齐。三轮都过了这个skill才算基本可用。4.6 发布与迭代验证通过的skill可以推到GitHub上。发布时记得在README里写清楚这个skill解决什么问题、适用哪些工具、安装方法、目录结构、注意事项。很多人忽略README但它是别人是否愿意试用你skill的第一道门。迭代方面我的做法是每次用skill发现输出不符合预期时马上记录问题定期集中修订SKILL.md而不是边用边改。频繁改动会导致你根本分不清当前的输出变化是因为改了什么。还有一点Skill和代码一样会过时工具升级、模型更新都可能导致原来的写法失效所以隔一段时间要重新跑一遍测试流程确认它还活着。5. Skills与MCP工具的分工配合什么时候用Skill什么时候用MCP5.1 MCP是“手”Skill是“操作手册”理解Skills和MCP的关系最准确的说法是MCP解决“能不能做”的问题Skills解决“怎么做才规范”的问题。没有MCPAI再懂流程也调不到外部工具没有SkillsAI即使能调外部工具也不知道什么时候该调、调完之后怎么处理结果。举个具体的例子。你希望AI能自动把数据可视化图表生成并发布到某个内部平台上。MCP部分负责提供能力连接数据库取数、调用图表渲染服务、对接发布接口。Skills部分负责定义流程先验证数据口径、选择图表类型、渲染检查、再发布。两者配合后AI才能真正完成一个“从取数到发布”的完整闭环。如果你只配MCP不给它skillAI可能只会“能调用工具”但不知道该按什么顺序调也不会校验输出物是否合格——这就是web前端mcp skills这类组合受欢迎的原因MCP提供浏览器自动化等能力skill规范前端页面检查的完整流程两者一配合AI能自己打开页面、看渲染效果、发现问题、再修改。5.2 实操中的分工判断标准我自己判断“这个能力该做成Skill还是MCP”时会问三个问题。第一这个能力需要访问外部系统吗需要走API、操作数据库、调浏览器那就考虑MCP不需要只是让AI按一定流程分析、组织、输出文本那就是Skill的范畴。第二这个流程会经常变化吗流程频繁变的适合做MCP因为外部工具的API一般稳定而流程本身可以在代码里灵活控制流程相对固定的适合做Skill因为写文档的成本远低于写代码。第三这个能力要多人共享吗需要给团队统一行为标准的Skill和MCP都要但一定通过skill来统一“动作规范”让所有人的AI助手按同一套标准干活。5.3 Skill调用MCP工具的常见模式“Skills如何调用MCP工具”是很多人搜的问题。实际上Skill本身不直接“调用”MCP而是在SKILL.md里写明“这个任务的哪些步骤需要使用哪些工具”AI在执行到对应步骤时会自行判断并调用已经配置好的MCP工具。所以你在写skill时只需在步骤描述里明确指出工具名称和调用时机比如“第3步使用playwright工具打开目标页面等待页面完全加载后截图保存”。AI看到这个指令就会在MCP工具列表中找到对应工具并执行。这里有一个容易被忽略的点如果MCP工具没配好、名字不对、或者返回的数据格式和skill里预期的不一致整个链路就会断掉。所以凡是涉及MCP调用的skill一定要在文档里写明“前置依赖”告诉使用者需要先配置哪些MCP服务器、环境变量怎么设。否则别人拿到你的skill却一直调不通体验会非常糟糕。5.4 资源成本与权限控制最后说下配合时的成本控制。一个skill里如果嵌入了大量工具调用指令AI可能为了“完成任务”连续调用很多次MCPToken和费用都会快速上升。我建议在skill里明确写清楚“尽量一次调用获取全部信息避免循环调用”这类约束。权限上也需要注意不是所有工具都要放开给AI用只配置执行任务真正需要的MCP服务器避免AI在误触发时操作到不该动的东西。这也是很多团队在实际落地时容易大意的地方——他们把所有MCP服务器一股脑配好结果AI在一个不相关的任务里调用了支付接口的测试工具虽然没出大问题但也够吓人的。6. 使用Skills最容易踩的坑与我的避坑建议6.1 坑一description写得不够准技能乱触发这是我在社区看到反馈最多的一个问题。有人给AI装了几十个skills之后发现AI经常答非所问——用户问的是普通问题AI却强行套用某个技能框架。原因基本都是description写得太泛或者多个skill的description之间存在语义重叠。比如两个skill的description里都写了“帮助用户分析业务问题”结果用户一提业务需求两个都被触发AI不知道该用哪个干脆混着来输出质量直接崩。解决办法是给每个skill划清边界description里一定要写排除条件比如“不适用于XX情况”“如果用户需求包含XX词请忽略本技能”。另外skills装得多不是好事我建议日常保持在20个以内覆盖真正高频的场景宁可少而精不要多而杂。装了一大堆冗余技能不仅浪费Token还会增加AI匹配时的困惑。6.2 坑二skills文件过重上下文被撑爆技能文件太大是第二个常见问题。很多人把整本方法论写进一个SKILL.mdAI一触发就加载海量内容不仅浪费Token而且关键指令被淹没在冗长文本里模型反而“看不过来”。上下文窗口就像办公桌堆的东西太多真正要用的工具反而找不到。我的建议是单个SKILL.md控制在200行以内能精简就精简长规范放附件由AI按需读取。同时把“核心步骤”放在正文最前面让模型优先看到把“详细示例”“备选方案”这类锦上添花的内容放后面。AI在上下文压力下会倾向“先看前面”你要把最重要的东西放在它最先看到的位置。6.3 坑三盲目信任社区skills不做验证社区推荐的skills质量参差不齐有些只是作者随手写的prompt套壳有些连description都没写好甚至还有和当前工具版本完全不兼容的。我见过有人下载了“数学建模skills大礼包”结果里面全是已经过时的算法模板让AI照着写出来的模型代码根本跑不起来。所以任何从网上下载的skill第一件事不是直接用而是先拆开看内容确认它里面的步骤、规则、模板是否适合你的场景。我的习惯是新下载的skill先放到一个试用目录跑一遍前面说的测试三轮法再决定是否正式启用。测试通过前不要让它进入你的全局skills目录否则它会影响所有项目的AI行为。6.4 坑四工具版本升级后skill失效Skills的时效性问题很少有人提但非常现实。模型更新、工具API调整、参考的外部服务变化都可能导致原本正常的skill突然失效。比如某个skill里引用了旧版MCP工具的工具名或者依赖某个外部命令的输出格式一旦上游变了skill的执行就会出错。应对办法是建立定期体检机制。我每个季度会抽半天把所有skills从头到尾跑一遍重点检查还有没有在用的场景步骤描述是否匹配当前工具版本引用的附件是否过期跑不动的直接删掉或重写。这种定期清理不仅避免失效技能坑人也能逼着你审视自己的工作流是否还有优化空间。6.5 我的个人建议最后分享几个我自己用下来的心得。第一先抄再写。刚开始不必急着从零开发先用社区里口碑好的成熟skill跑熟了自然知道好的skill长什么样再动笔写自己的。我自己第一个skill就是照着superpowers里某个技能的写法改出来的有参照物和没参照物完全是两回事。第二版本管理不能省。每个skill的变更要写清楚变更原因和日期有条件的话放进Git仓库方便回溯。Skills最大的价值是“可沉淀、可复用”如果连版本都不能追溯“复用”就是一句空话。第三别把skill当成万能药。它真正擅长的是固定流程加规范输出对于高度依赖创造性判断的任务比如从零做产品定义、设计核心算法skill的边际收益有限该靠人脑的还是靠人脑。最理想的状态是重复性工作交给skill创造性工作留给人类各司其职。我自己把这套方法用了一段时间后最大的感受是——以前每次让AI干活都要反复调教说清楚格式、说清楚步骤、说清楚边界现在很多活儿说一句话就能得到相当标准的产出。这种“稳定感”是单纯靠聊天式prompt很难获得的。如果你现在正被“AI输出忽好忽坏”困扰真心建议从一个小场景入手试着给它写一份SOP。等第一个skill跑通了你会回来感谢这个决定的。