导语GitHub上面有一个名叫Skills的项目在差不多一周的时间里涨了一万多的Star。不少人看到这个项目之后反应也就只有一个字那就是收藏。这和当年大家收藏Prompt模板的情况可以说是一模一样的。但说实话Skills这个东西光靠收藏其实没什么太大的用处。倒不是Skills本身没有用而是“收藏”这个动作本身其实并没有多少实际的意义。因为Skills并不是一段简简单单的文字内容而是一整套完整的做事方式。你所缺少的并不是别人已经整理好的文件而是你自己其实都没有想清楚这件事到底应该如何去做。一、AI 编程现在最烦的地方不是它不会写代码我现在越来越怕一种AI。你刚把需求讲完它就已经动手去写代码了。这样的场景看起来确实挺爽但实际上却暗藏着不小的风险。在真实开展的项目里面代价最高昂的错误往往不是代码编写的速度不够快而是从最开始的时候整个项目的方向就出现了偏差。比如说你让人工智能工具去修复一段代码里的漏洞它往往只是快速扫了一眼系统弹出的报错信息就立刻开始着手进行修改。它可能只改动了三个相关的代码文件然后运行了一次测试程序接着就告诉你这个漏洞已经被成功修复好了。你去检查的时候会发现原本的报错确实不再出现了但原本可以正常运行的旁边一个功能模块却莫名其妙地出现了故障。这并非AI不够聪明。是它跳过了真实工程当中最土、最烦、也最要命的一步先要把问题到底是什么搞清楚之后再动手去开展相关的工作。我最近这段时间一直都在留意一个事儿叫 Skills。这既不是什么Prompt也不是MCP更不是又一个AI圈子里造出来的玄乎词。我查看了 GitHub 每周热门趋势榜单mattpocock/skills 这个项目目前总共获得了 143766 颗星标仅在过去一周就新增了 11784 颗星标。在我这次查询到的当周热门项目榜单里它是涨幅最为突出的项目。仓库的描述仅有一句话Skills for Real Engineers. Straight from my .claude directory.我先是翻了翻评论区还有Reddit、Hacker News上面的讨论内容结果发现了一个挺有意思的现象。不少人在看到这个项目的时候第一反应往往就是把它给收藏起来。先把 star 给点上再说。这可是个不错的东西之后可以慢慢拿来看。等我哪天有空了就去好好研究一下。这个反应跟当年Prompt火起来的时候简直一模一样。2023年还有2024年这两年大伙都在疯狂地收藏Prompt模板。GitHub上面随便一个叫Awesome ChatGPT Prompts的仓库都能拿到好几万的star。结果到底怎么样呢大多数人收藏完了之后转头就给忘了。真到了要用的时候还是随手就打一句帮我写个周报。如今和技能相关的内容算是火了起来类似的这种情况又一次上演了。我今天想聊的并不是Skills具体指的是什么、要怎么去进行安装又有哪些值得去推荐的相关内容。这些相关的信息你随便去网上搜索一下都可以轻轻松松地找到。我想聊的是另外一个问题为什么你收藏了再多的Skills也未必就能用得好AI编程这其中的缘由其实就只有一个但大多数人并没有真正意识到这一点。二、Skills 到底是什么我们可以先来快速对齐一下相关的概念。Skills 这一特性其实是 Anthropic 在 2025 年 10 月份的时候在 Claude Code 上面所支持的相关内容。等到了同年的 12 月他们就把 Skills 作为开放标准给推了出来在这之后各类工具也就陆陆续续地接入了这一特性。Anthropic 工程博客上的原话是Agent Skills 是一组有组织的文件夹当中包含 instructions、scripts、resourcesagent 可以动态发现并加载以此来更好地完成特定任务。要把这个事情讲明白Skills 其实并不是一段 Prompt它本质上就是一个文件夹。这个文件夹里面不光会有说明文档说不定还会有脚本甚至可能还会有一些参考资料。Agent 在真正需要用到它的时候再去加载就行并不会一股脑地把所有内容都塞进上下文当中。这里有个关键设计叫作progressive disclosure翻译过来也就是渐进式披露。换个说法就是不要一口气把所有内容都塞给AI先给出一个目录等它觉得用得上的时候再往下翻。你平时点外卖也是这样的——先看商家列表点进去之后再看菜单选好菜品之后再看详情。不会有人一打开App就把200道菜全部铺在你面前。这么设计的初衷其实很直白也就是为了节省Token。在和大模型进行交互的整个过程里对话的内容越长模型的表现就会越差那些使用过AI进行编程的人大多都有过类似的使用体感。Token在Agent架构的设计环节当中真可谓是寸土寸金。好关于这个概念的讲解也就到此为止了。咱们现在来聊聊重点大多数人其实都是怎么去运用这些技能的呢他们打开了GitHub之后就看到了mattpocock/skills这个仓库顺手就给它点上了一颗star。接着他们挑了几个看起来比较顺眼的技能把它们复制到自己的.claude/skills目录里面之后就没有再进行后续的操作了。这和当年我们收藏那些Prompt模板的情况其实并没有什么太大的差别。二者其实并没有什么本质上的区别。你换了个格式换了个目录换了个名字。行为模式其实都一模一样把东西收藏起来放在一边到最后就落了灰。问题出在哪三、你所缺少的其实并不是Skill文件我给你讲一个相当具体的例子。在 mattpocock/skills 这个项目当中有一项被命名为 diagnosing-bugs 的技能。这项技能具体的执行流程大致是这样的首先需要去完成问题的重现紧接着要完成代码或者场景的最小化处理随后再针对性地提出相关假设之后再开展工具调试的工作再之后进行修复操作最后完成回归测试这一步骤。我们可以先把这个bug给完整复现出来接着再把排查的范围给逐步缩小随后列出与之相关的各项假设再搭配上对应的观测手段来开展验证工作之后再去完成修复操作最后补上回归测试的相关工作。这套流程土不土其实挺土的。任何一个拥有丰富经验的工程师在修复程序漏洞的时候都是按照这样的步骤来开展工作的。但其实相应的问题也就跟着出现了。要是你自己修复bug的习惯是先看一眼报错内容再去猜测可能出现的缘由接着修改一行代码之后运行一下看看有没有报错要是没报错就直接提交那把这个技能装上去能起到什么样的作用呢并不是说完全没有用处。Agent 确实会按照既定的流程来开展工作它会先尝试去进行复现之后再逐步缩小范围接着再列出相关的假设。但要是你根本不知道什么才算是“好的假设”、什么叫“有效的观测手段”、什么才是“足够小的复现范围”那么你就连判断 Agent 做得好不好都做不到。你只会看到它运行了一堆步骤输出了一堆文字然后告诉你“修好了”。你也不清楚它是不是真的把问题修好了还是仅仅只是把报错信息给藏起来了。你甚至不会意识到自己其实判断不了。你以为它已经修好了。这才是最要命的。Skills 其实是流程的放大器。要是你所搭建的流程足够清楚明白它就会把这份清楚的流程进一步放大。要是你的流程本身存在着混乱的情况它就会把这份混乱的流程同样给放大。它并非是外挂程序。它不会平白无故地给你一套你原本就不具备的工作方法。四、五个技能就是五个工程层面的判断我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单而是希望能让你看明白每一个技能的背后其实都藏着一项需要结合实际情况去做出的工程判断。第一个grill-with-docs追问别急着写代码。我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单而是希望能让你看明白每一个技能的背后其实都藏着一项需要结合实际情况去做出的工程判断。它不会帮你写哪怕一行代码。它所做的那些事会让人觉得相当烦人就是会追着你去不停询问。这个字段到底包含的意义是什么这两个概念之间具体存在着什么样的关系它的边界条件具体又是指什么内容要是用户发起了退款的申请我们又该如何去进行对应的处理要是你跟普通的AI说一句“帮我做一个用户邀请返利功能”它马上就会开始动笔编写。像是邀请关系能不能设置成多级退款之后返利该怎么计算自己邀请自己的情况该如何处理老用户补绑邀请人的话又该怎么办这些问题它全都没有询问到。等到代码写完之后你再去看就会发现整体的方向已经出现了偏差。grill-with-docs 所具备的价值其实并不是让 AI 的运行速度变得更快而是要让它慢下来慢在那些应该慢下来的正确环节当中。但这里有一个前提你得清楚什么样的问题是值得去追问的。要是你自己都没有思考过“退款后返利怎么算”这个问题那你也就不会觉得Agent追问这个问题有什么意义你只会觉得它有些烦人。第二个diagnosing-bugs别猜先复现。前面讲过了。它的流程是 reproduce → minimise → hypothesise → instrument → fix → regression-test。这项技能背后藏着一个很朴素的工程层面的判断很多程序漏洞没法顺利修复并不是因为漏洞本身有多复杂而是负责修复的人没有搞清楚这个漏洞到底是怎么一回事。AI修复程序漏洞时最容易出现的问题就是太过喜欢去做猜测。比如只是扫了一眼报错弹出的信息立刻就锁定到某一行具体的代码修改完成后再运行测试一遍随后就直接告诉对方“漏洞已经修复好了”。但在真正的工程场景之中这类修复方式往往很容易就会引入新的程序漏洞。diagnosing-bugs的价值是把别猜这两个字写进了流程。但同样的要是你自己在修复bug的时候从来不记录复现的步骤、不去缩小排查的范围也不补充做回归测试那么你安装这个skill也很难判断它每一步的输出是否正确。第三个tdd测试根本不是为了给自己找台阶下。这个技能运用的是red-green-refactor循环也就是先编写无法通过测试的测试用例再去实现能够满足需求的最小可用功能最后再对代码进行重构操作。TDD 对于人类来说其实都挺反直觉的更不要说 Agent 了。要是没有流程上的约束Agent 很有可能一口气就把测试和实现这两件事都做完了。等到做完之后测试倒是能全部通过但偏偏就没测到那些关键的风险。说白了测试其实仅仅只是证明“我写的代码可以正常运行”而已。tdd这项技能真正限制住的其实是智能体也就是 Agent 的操作流程。我们得先动手编写测试用例通过这种方式逼着自己想清楚这段代码到底应该达成什么样的目标之后再正式开展代码实现的相关工作。但这里又存在一个前提你得清楚什么是好的测试。边界条件具体是什么异常路径具体是什么关键业务逻辑具体是什么要是你自己写测试的习惯只是“跑通了就行”那么Agent按照TDD流程写出来的测试你也没办法辨别它的好坏。第四个handoff长上下文不是无限用的。这项技能所起到的作用就是将当前正在进行的对话内容整理压缩成一份可以用于交接的文档以此方便让另一个智能体接手继续推进后续的相关工作。但凡使用过AI编程工具的开发者都明白在一场持续时间较长的对话过程中所调用的Agent往往会出现性能下滑的情况。当聊天交互进行到两百轮之后它就会逐渐遗忘掉最开始做出的那些决策进而使得最终输出内容的质量出现明显的下降。handoff解决的是一个很现实的问题怎么把一个快撑爆的上下文交给下一轮继续干。但这项技能其实存在一个隐藏的前提也就是你当下的对话质量需要达到合格的标准。要是当前的对话已经陷入混乱的情况那么所谓的handoff仅仅只是把这种混乱的状况打包转移而已。下一轮Agent所拿到的将会是一份充满混乱的交接文档只会让整体的情况变得比之前更加混乱。第五个codebase-design别让 AI 把项目越改越烂。这个技能聚焦于深度模块也就是那些在小型接口背后还隐藏着更多操作行为的部分要是把这些模块安置在边界清晰且规整的环境里就能够通过接口测试来完成相关验证。AI最容易产出一类看起来可以正常运行但模块会越来越浅、文件会越来越碎、逻辑也会越来越散的垃圾。每当需要添加新功能的时候大多都是在一个已经显得有些杂乱的模块上再额外贴上一块。codebase-design的价值是在 Agent 动手改代码之前先让它想清楚模块边界。要是你自己从来都没有认真琢磨过“这个模块的边界到底在哪”“什么样的内容应该暴露出来、什么样的内容应该隐藏起来”那你也就不会真正理解这个技能究竟是在做些什么。怎么说呢看完这五个技能之后你会发现这样一件事。它们都不是在教AI拥有什么新的能力而是在对AI的行为进行管控。五、真正用好 Skills 的人做对了一件事在把这五个技能都讲解完了之后你应该能够慢慢察觉到其中藏着的一个规律。每一项称得上有价值的技能其实背后并没有什么特别高深的技术。它本质上就是创作者自己平日里一直在使用的工作方法。创作者会把这套方法完整地记录下来拆分成一个个具体的步骤再添加上检查环节以及应对失败的相关内容之后告知智能体以后再碰到这类任务的时候就按照这个流程来开展执行。所以真正能够把Skills用好的那些人其实做对了一件事他们其实并不是在单纯使用Skills而是在把自己平日里摸索出来的工作方法仔细地封装成一个个Skills。这两件事之间所存在的区别其实还是比较明显的。“使用 Skills”也就是运用技能的行为属于消费行为。你看到他人撰写完成的内容再将其拿过来使用。使用的效果好坏取决于他人提供的内容是否适宜你自身的需求。“封装 Skills”其实属于一种生产行为。你完全可以把自己每周重复三次以上的那些任务把具体的步骤、需要遵循的标准、划定的边界以及应对失败的相关处理内容都写清楚把它转变成一个Agent能够直接执行的工作包。前者是收藏。后者是建设。这其实就是为什么我要跟你讲你哪怕是收藏了足足一百个skill也不见得就真的能够把AI编程给用好。你所收藏的其实是别人的工作方法、别人的工程习惯、别人的项目结构还有别人的团队规范。这些内容要是直接放到你的项目当中大概率会出现水土不服的情况。六、Prompt、Skills以及MCP不要再混着来聊了不少人到现在还在把这三个词混着用。概念大白话解决什么不解决什么Prompt当场交代一句话临时指令、单次任务长期复用、复杂流程Skills给 Agent 的工作手册固化流程、规范、检查清单外部系统连接MCP给 Agent 接工具的接口连接外部系统、调用工具告诉 Agent 怎么干活Agent执行任务的人规划、调用工具、执行步骤没有好流程时也会乱干一句话Prompt管的是要说什么内容Skills管的是具体要怎么做MCP管的是可以去到哪些方向或者范围Agent管的是具体由谁来执行这项工作。Skills 其实并不是 Prompt 的替代品。Prompt 还会在很长一段时间里持续存在只是它并不太适合用来承载那些比较复杂、需要反复执行以及相对稳定的流程。MCP 其实也算不上是 Skills 的竞品。MCP 所要处理的其实是 AI 能不能够访问你的数据库、文件系统以及第三方 API 这类问题。而 Skills 要解决的则是当访问到这些资源之后它应该按照什么样的规矩来开展工作的问题。这二者其实是互补的关系并不是相互排斥的。Anthropic 的工程博客其实已经说得很清楚了Skills 和 MCP 这两者之间其实是属于互相补充的关系。七、四个演示场景下面这几个场景是我设计的演示并非真实的公司案例但它们所反映的是真实存在的痛点。场景一要是需求还没有彻底想明白的话就不要让AI直接动手去写代码。要是打算做一个“用户邀请返利”功能直接让AI来写的话普通AI很快就能产出一堆代码。不过像邀请关系能不能设置成多级退款之后返利该怎么计算自己邀请自己的情况该如何处理老用户补绑邀请人的问题该怎么解决还有风控方面要怎么去处理这些内容AI全都没有提及。在使用 grill-with-docs 之后Agent 并不会直接去编写代码。它会先进行追问比如邀请关系是单级还是多级返利是固定金额还是比例退款场景要怎么处理以及边界条件是什么。同时还会把这些决策记录进 CONTEXT.md 当中。优质的AI工作流其第一步往往并非直接去编写代码而是要把相关的问题给询问清楚。场景二AI 修复 bug 不要靠猜测。线上出现了报错的情况有某个接口会偶发地出现500的问题。普通的AI一般会直接去查看报错的内容以此来修改代码。它会先修改三个文件接着运行一次测试之后就会告诉你“修好了”。你去查看之后会发现这个bug确实不再报错了但旁边的一个功能却出现了损坏。在使用diagnosing-bugs之后Agent首先会去尝试把问题给复现出来接着会慢慢缩小排查的范围之后会列出和这个问题相关的一些假设再去添加日志或者开展测试来进行验证最后完成修复的工作还会补上回归测试的这个环节。在真实的工程场景之中最让人头疼的其实并不是bug难以被解决而是有人一边凭借着自己的猜测一边就去进行修改操作。场景三让AI来写测试其实并不是让它自己去自导自演。将测试工作交给AI来给支付模块进行补充。普通的AI或许会把实现和测试放在一起完成到最后测试可以全部通过但却没有对关键风险进行测试。所谓的测试仅仅只是能够证明“自己所编写的代码可以正常运行”。运用 TDD 之后Agent 会先编写失败测试再进行最小实现最后开展重构工作。要是不按照这样的方式来管理开发流程那么就很容易写出看起来似乎十分完整但实际上仅仅只是证明自身代码可以正常运行的测试。测试的价值不是覆盖率数字是它有没有测到真正会坏的地方。场景四长任务中断后不要让上下文烂尾。我们已经和AI进行了足足两百轮的聊天整个项目的修改工作也推进到了一半的进度要是再这样继续下去模型就会开始变得模糊不清。用handoff之后Agent 把当前状态压缩成 handoff 文档哪些做完了哪些没做关键决策是什么坑在哪里。下一轮对话直接读这个文档继续。长上下文不是无限用的资源。知道什么时候该交接比硬撑更靠谱。八、泼几盆冷水写到这里我泼几盆冷水哈。第一所谓的Skills其实并不能替代工程层面的实际能力。你不会因为装了一个diagnosing-bugs就突然会修 bug 了。你不会因为装了一个codebase-design就突然会做架构了。Skills 帮你执行流程但判断流程对不对、输出好不好还是你的事。第二Skill 写得烂Agent 只会稳定地烂。一个质量欠佳的Skill要比完全没有Skill来得更加危险。如果只是没有Skill的话Agent至少还能够自由地发挥自身的空间。可要是拥有了质量并不合格的SkillAgent就会稳定地依照错误的流程去执行相关的操作。第三安全风险不能忽略。Skills 是文件夹里面可以有脚本、命令、文件操作。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸而是在给 AI 提供一个可以执行特定动作的工作包。有意思的是这次 GitHub weekly trending 里还有一个项目叫NVIDIA/SkillSpector描述是Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks.连 NVIDIA 都在做 Skills 安全扫描了。说明这个问题不是杞人忧天。第四工具兼容性不要替读者做承诺。mattpocock/skills的描述里写了.claude directory。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸而是在给 AI 提供一个可以执行特定动作的工作包。第五团队没有流程Skills 救不了。这可以说是最根本的一条。所谓Skills其实只能用来固化已经存在的流程没办法凭空生成出新的流程来。要是你的团队连代码审查的规范都还没有建立起来、连测试策略都没能达成统一的对齐、连需求文档都没有人专门来负责撰写的话就算装上再多的Skills其实也发挥不了什么实际的作用。第六Skill 不是写完就扔。你的工作方法在变项目在变工具也在跟着升级那么Skill也得跟着做出相应的调整。你可以把它当成代码的一部分该进行重构的时候就进行重构。Skills所固化的其实是你当前的工作方法如果你的方法本身需要进行迭代记得定期回头去修改Skill别把它当成一成不变的圣旨。九、普通人到底该怎么开始不要去收藏一百个。每天只做这一个。找一个你每周重复 3 次以上的任务。怎么判断值不值得做三个标准你每周做 3 次以上、步骤基本固定、做错了有后果。符合两个就值得封装。不符合的临时 Prompt 够了。像修复程序漏洞的具体流程、整理每周工作进展报告的框架、审核代码时需要关注的检查要点、编写项目说明文档的标准模板还有在开展需求评审之前需要提前准备好的各项清单。把你的要求、步骤、输出格式、失败处理写下来。不用写得很复杂。5 个步骤3 个检查点1 个输出模板够了。然后放进你的 Skills 目录。跑几次。看它有没有真的减少你的返工和废话。做完这一个当它运行起来的那一瞬间你就会懂。Skills 的价值不在收藏在复用。明天你会开始想做第二个。后天你会想把所有重复的流程全都搬进去。到那一步你就不是在使用 Skills了。你是在把自己的经验变成 Agent 能执行的资产。十、别收藏了今天就来实实在在做一个。Prompt 时代大家所比拼的其实是谁更能够去提出问题。在Skills时代当中大家开始比拼谁更会去整理自己的工作流。这件事可比单纯收藏Prompt要难上不少而且它的价值也要更高一些。其实Prompt说白了就是一句话。Skills呢则是一整套用来把事情做好的具体方式。模型的能力确实会变得越来越强这一点可以说是确定无疑的。不过话说回来模型越是强大也就越容易暴露出来另一个值得我们思考的问题你到底是不是真的清楚自己想要什么又到底该怎么做才行。模型固然可以帮你写出任何一段代码但它没办法替你决定到底什么样的代码是值得去写的。往后在AI编程这一领域双方之间所存在的差距可能不只是停留在模型这个层面上的差距更有很大概率是在整体的流程层面所存在的差距。能够把自身所拥有的经验拆解成智能体可以执行的具体步骤的这类主体也就更容易将人工智能当作一种实用工具来加以使用而不是把它当成一个话比较多的实习生。别再忙着收藏了。今天就来实实在在做一个。
为什么你收藏了 100 个 Skills，也未必能用得好 AI 编程？
发布时间：2026/6/25 17:26:04
导语GitHub上面有一个名叫Skills的项目在差不多一周的时间里涨了一万多的Star。不少人看到这个项目之后反应也就只有一个字那就是收藏。这和当年大家收藏Prompt模板的情况可以说是一模一样的。但说实话Skills这个东西光靠收藏其实没什么太大的用处。倒不是Skills本身没有用而是“收藏”这个动作本身其实并没有多少实际的意义。因为Skills并不是一段简简单单的文字内容而是一整套完整的做事方式。你所缺少的并不是别人已经整理好的文件而是你自己其实都没有想清楚这件事到底应该如何去做。一、AI 编程现在最烦的地方不是它不会写代码我现在越来越怕一种AI。你刚把需求讲完它就已经动手去写代码了。这样的场景看起来确实挺爽但实际上却暗藏着不小的风险。在真实开展的项目里面代价最高昂的错误往往不是代码编写的速度不够快而是从最开始的时候整个项目的方向就出现了偏差。比如说你让人工智能工具去修复一段代码里的漏洞它往往只是快速扫了一眼系统弹出的报错信息就立刻开始着手进行修改。它可能只改动了三个相关的代码文件然后运行了一次测试程序接着就告诉你这个漏洞已经被成功修复好了。你去检查的时候会发现原本的报错确实不再出现了但原本可以正常运行的旁边一个功能模块却莫名其妙地出现了故障。这并非AI不够聪明。是它跳过了真实工程当中最土、最烦、也最要命的一步先要把问题到底是什么搞清楚之后再动手去开展相关的工作。我最近这段时间一直都在留意一个事儿叫 Skills。这既不是什么Prompt也不是MCP更不是又一个AI圈子里造出来的玄乎词。我查看了 GitHub 每周热门趋势榜单mattpocock/skills 这个项目目前总共获得了 143766 颗星标仅在过去一周就新增了 11784 颗星标。在我这次查询到的当周热门项目榜单里它是涨幅最为突出的项目。仓库的描述仅有一句话Skills for Real Engineers. Straight from my .claude directory.我先是翻了翻评论区还有Reddit、Hacker News上面的讨论内容结果发现了一个挺有意思的现象。不少人在看到这个项目的时候第一反应往往就是把它给收藏起来。先把 star 给点上再说。这可是个不错的东西之后可以慢慢拿来看。等我哪天有空了就去好好研究一下。这个反应跟当年Prompt火起来的时候简直一模一样。2023年还有2024年这两年大伙都在疯狂地收藏Prompt模板。GitHub上面随便一个叫Awesome ChatGPT Prompts的仓库都能拿到好几万的star。结果到底怎么样呢大多数人收藏完了之后转头就给忘了。真到了要用的时候还是随手就打一句帮我写个周报。如今和技能相关的内容算是火了起来类似的这种情况又一次上演了。我今天想聊的并不是Skills具体指的是什么、要怎么去进行安装又有哪些值得去推荐的相关内容。这些相关的信息你随便去网上搜索一下都可以轻轻松松地找到。我想聊的是另外一个问题为什么你收藏了再多的Skills也未必就能用得好AI编程这其中的缘由其实就只有一个但大多数人并没有真正意识到这一点。二、Skills 到底是什么我们可以先来快速对齐一下相关的概念。Skills 这一特性其实是 Anthropic 在 2025 年 10 月份的时候在 Claude Code 上面所支持的相关内容。等到了同年的 12 月他们就把 Skills 作为开放标准给推了出来在这之后各类工具也就陆陆续续地接入了这一特性。Anthropic 工程博客上的原话是Agent Skills 是一组有组织的文件夹当中包含 instructions、scripts、resourcesagent 可以动态发现并加载以此来更好地完成特定任务。要把这个事情讲明白Skills 其实并不是一段 Prompt它本质上就是一个文件夹。这个文件夹里面不光会有说明文档说不定还会有脚本甚至可能还会有一些参考资料。Agent 在真正需要用到它的时候再去加载就行并不会一股脑地把所有内容都塞进上下文当中。这里有个关键设计叫作progressive disclosure翻译过来也就是渐进式披露。换个说法就是不要一口气把所有内容都塞给AI先给出一个目录等它觉得用得上的时候再往下翻。你平时点外卖也是这样的——先看商家列表点进去之后再看菜单选好菜品之后再看详情。不会有人一打开App就把200道菜全部铺在你面前。这么设计的初衷其实很直白也就是为了节省Token。在和大模型进行交互的整个过程里对话的内容越长模型的表现就会越差那些使用过AI进行编程的人大多都有过类似的使用体感。Token在Agent架构的设计环节当中真可谓是寸土寸金。好关于这个概念的讲解也就到此为止了。咱们现在来聊聊重点大多数人其实都是怎么去运用这些技能的呢他们打开了GitHub之后就看到了mattpocock/skills这个仓库顺手就给它点上了一颗star。接着他们挑了几个看起来比较顺眼的技能把它们复制到自己的.claude/skills目录里面之后就没有再进行后续的操作了。这和当年我们收藏那些Prompt模板的情况其实并没有什么太大的差别。二者其实并没有什么本质上的区别。你换了个格式换了个目录换了个名字。行为模式其实都一模一样把东西收藏起来放在一边到最后就落了灰。问题出在哪三、你所缺少的其实并不是Skill文件我给你讲一个相当具体的例子。在 mattpocock/skills 这个项目当中有一项被命名为 diagnosing-bugs 的技能。这项技能具体的执行流程大致是这样的首先需要去完成问题的重现紧接着要完成代码或者场景的最小化处理随后再针对性地提出相关假设之后再开展工具调试的工作再之后进行修复操作最后完成回归测试这一步骤。我们可以先把这个bug给完整复现出来接着再把排查的范围给逐步缩小随后列出与之相关的各项假设再搭配上对应的观测手段来开展验证工作之后再去完成修复操作最后补上回归测试的相关工作。这套流程土不土其实挺土的。任何一个拥有丰富经验的工程师在修复程序漏洞的时候都是按照这样的步骤来开展工作的。但其实相应的问题也就跟着出现了。要是你自己修复bug的习惯是先看一眼报错内容再去猜测可能出现的缘由接着修改一行代码之后运行一下看看有没有报错要是没报错就直接提交那把这个技能装上去能起到什么样的作用呢并不是说完全没有用处。Agent 确实会按照既定的流程来开展工作它会先尝试去进行复现之后再逐步缩小范围接着再列出相关的假设。但要是你根本不知道什么才算是“好的假设”、什么叫“有效的观测手段”、什么才是“足够小的复现范围”那么你就连判断 Agent 做得好不好都做不到。你只会看到它运行了一堆步骤输出了一堆文字然后告诉你“修好了”。你也不清楚它是不是真的把问题修好了还是仅仅只是把报错信息给藏起来了。你甚至不会意识到自己其实判断不了。你以为它已经修好了。这才是最要命的。Skills 其实是流程的放大器。要是你所搭建的流程足够清楚明白它就会把这份清楚的流程进一步放大。要是你的流程本身存在着混乱的情况它就会把这份混乱的流程同样给放大。它并非是外挂程序。它不会平白无故地给你一套你原本就不具备的工作方法。四、五个技能就是五个工程层面的判断我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单而是希望能让你看明白每一个技能的背后其实都藏着一项需要结合实际情况去做出的工程判断。第一个grill-with-docs追问别急着写代码。我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单而是希望能让你看明白每一个技能的背后其实都藏着一项需要结合实际情况去做出的工程判断。它不会帮你写哪怕一行代码。它所做的那些事会让人觉得相当烦人就是会追着你去不停询问。这个字段到底包含的意义是什么这两个概念之间具体存在着什么样的关系它的边界条件具体又是指什么内容要是用户发起了退款的申请我们又该如何去进行对应的处理要是你跟普通的AI说一句“帮我做一个用户邀请返利功能”它马上就会开始动笔编写。像是邀请关系能不能设置成多级退款之后返利该怎么计算自己邀请自己的情况该如何处理老用户补绑邀请人的话又该怎么办这些问题它全都没有询问到。等到代码写完之后你再去看就会发现整体的方向已经出现了偏差。grill-with-docs 所具备的价值其实并不是让 AI 的运行速度变得更快而是要让它慢下来慢在那些应该慢下来的正确环节当中。但这里有一个前提你得清楚什么样的问题是值得去追问的。要是你自己都没有思考过“退款后返利怎么算”这个问题那你也就不会觉得Agent追问这个问题有什么意义你只会觉得它有些烦人。第二个diagnosing-bugs别猜先复现。前面讲过了。它的流程是 reproduce → minimise → hypothesise → instrument → fix → regression-test。这项技能背后藏着一个很朴素的工程层面的判断很多程序漏洞没法顺利修复并不是因为漏洞本身有多复杂而是负责修复的人没有搞清楚这个漏洞到底是怎么一回事。AI修复程序漏洞时最容易出现的问题就是太过喜欢去做猜测。比如只是扫了一眼报错弹出的信息立刻就锁定到某一行具体的代码修改完成后再运行测试一遍随后就直接告诉对方“漏洞已经修复好了”。但在真正的工程场景之中这类修复方式往往很容易就会引入新的程序漏洞。diagnosing-bugs的价值是把别猜这两个字写进了流程。但同样的要是你自己在修复bug的时候从来不记录复现的步骤、不去缩小排查的范围也不补充做回归测试那么你安装这个skill也很难判断它每一步的输出是否正确。第三个tdd测试根本不是为了给自己找台阶下。这个技能运用的是red-green-refactor循环也就是先编写无法通过测试的测试用例再去实现能够满足需求的最小可用功能最后再对代码进行重构操作。TDD 对于人类来说其实都挺反直觉的更不要说 Agent 了。要是没有流程上的约束Agent 很有可能一口气就把测试和实现这两件事都做完了。等到做完之后测试倒是能全部通过但偏偏就没测到那些关键的风险。说白了测试其实仅仅只是证明“我写的代码可以正常运行”而已。tdd这项技能真正限制住的其实是智能体也就是 Agent 的操作流程。我们得先动手编写测试用例通过这种方式逼着自己想清楚这段代码到底应该达成什么样的目标之后再正式开展代码实现的相关工作。但这里又存在一个前提你得清楚什么是好的测试。边界条件具体是什么异常路径具体是什么关键业务逻辑具体是什么要是你自己写测试的习惯只是“跑通了就行”那么Agent按照TDD流程写出来的测试你也没办法辨别它的好坏。第四个handoff长上下文不是无限用的。这项技能所起到的作用就是将当前正在进行的对话内容整理压缩成一份可以用于交接的文档以此方便让另一个智能体接手继续推进后续的相关工作。但凡使用过AI编程工具的开发者都明白在一场持续时间较长的对话过程中所调用的Agent往往会出现性能下滑的情况。当聊天交互进行到两百轮之后它就会逐渐遗忘掉最开始做出的那些决策进而使得最终输出内容的质量出现明显的下降。handoff解决的是一个很现实的问题怎么把一个快撑爆的上下文交给下一轮继续干。但这项技能其实存在一个隐藏的前提也就是你当下的对话质量需要达到合格的标准。要是当前的对话已经陷入混乱的情况那么所谓的handoff仅仅只是把这种混乱的状况打包转移而已。下一轮Agent所拿到的将会是一份充满混乱的交接文档只会让整体的情况变得比之前更加混乱。第五个codebase-design别让 AI 把项目越改越烂。这个技能聚焦于深度模块也就是那些在小型接口背后还隐藏着更多操作行为的部分要是把这些模块安置在边界清晰且规整的环境里就能够通过接口测试来完成相关验证。AI最容易产出一类看起来可以正常运行但模块会越来越浅、文件会越来越碎、逻辑也会越来越散的垃圾。每当需要添加新功能的时候大多都是在一个已经显得有些杂乱的模块上再额外贴上一块。codebase-design的价值是在 Agent 动手改代码之前先让它想清楚模块边界。要是你自己从来都没有认真琢磨过“这个模块的边界到底在哪”“什么样的内容应该暴露出来、什么样的内容应该隐藏起来”那你也就不会真正理解这个技能究竟是在做些什么。怎么说呢看完这五个技能之后你会发现这样一件事。它们都不是在教AI拥有什么新的能力而是在对AI的行为进行管控。五、真正用好 Skills 的人做对了一件事在把这五个技能都讲解完了之后你应该能够慢慢察觉到其中藏着的一个规律。每一项称得上有价值的技能其实背后并没有什么特别高深的技术。它本质上就是创作者自己平日里一直在使用的工作方法。创作者会把这套方法完整地记录下来拆分成一个个具体的步骤再添加上检查环节以及应对失败的相关内容之后告知智能体以后再碰到这类任务的时候就按照这个流程来开展执行。所以真正能够把Skills用好的那些人其实做对了一件事他们其实并不是在单纯使用Skills而是在把自己平日里摸索出来的工作方法仔细地封装成一个个Skills。这两件事之间所存在的区别其实还是比较明显的。“使用 Skills”也就是运用技能的行为属于消费行为。你看到他人撰写完成的内容再将其拿过来使用。使用的效果好坏取决于他人提供的内容是否适宜你自身的需求。“封装 Skills”其实属于一种生产行为。你完全可以把自己每周重复三次以上的那些任务把具体的步骤、需要遵循的标准、划定的边界以及应对失败的相关处理内容都写清楚把它转变成一个Agent能够直接执行的工作包。前者是收藏。后者是建设。这其实就是为什么我要跟你讲你哪怕是收藏了足足一百个skill也不见得就真的能够把AI编程给用好。你所收藏的其实是别人的工作方法、别人的工程习惯、别人的项目结构还有别人的团队规范。这些内容要是直接放到你的项目当中大概率会出现水土不服的情况。六、Prompt、Skills以及MCP不要再混着来聊了不少人到现在还在把这三个词混着用。概念大白话解决什么不解决什么Prompt当场交代一句话临时指令、单次任务长期复用、复杂流程Skills给 Agent 的工作手册固化流程、规范、检查清单外部系统连接MCP给 Agent 接工具的接口连接外部系统、调用工具告诉 Agent 怎么干活Agent执行任务的人规划、调用工具、执行步骤没有好流程时也会乱干一句话Prompt管的是要说什么内容Skills管的是具体要怎么做MCP管的是可以去到哪些方向或者范围Agent管的是具体由谁来执行这项工作。Skills 其实并不是 Prompt 的替代品。Prompt 还会在很长一段时间里持续存在只是它并不太适合用来承载那些比较复杂、需要反复执行以及相对稳定的流程。MCP 其实也算不上是 Skills 的竞品。MCP 所要处理的其实是 AI 能不能够访问你的数据库、文件系统以及第三方 API 这类问题。而 Skills 要解决的则是当访问到这些资源之后它应该按照什么样的规矩来开展工作的问题。这二者其实是互补的关系并不是相互排斥的。Anthropic 的工程博客其实已经说得很清楚了Skills 和 MCP 这两者之间其实是属于互相补充的关系。七、四个演示场景下面这几个场景是我设计的演示并非真实的公司案例但它们所反映的是真实存在的痛点。场景一要是需求还没有彻底想明白的话就不要让AI直接动手去写代码。要是打算做一个“用户邀请返利”功能直接让AI来写的话普通AI很快就能产出一堆代码。不过像邀请关系能不能设置成多级退款之后返利该怎么计算自己邀请自己的情况该如何处理老用户补绑邀请人的问题该怎么解决还有风控方面要怎么去处理这些内容AI全都没有提及。在使用 grill-with-docs 之后Agent 并不会直接去编写代码。它会先进行追问比如邀请关系是单级还是多级返利是固定金额还是比例退款场景要怎么处理以及边界条件是什么。同时还会把这些决策记录进 CONTEXT.md 当中。优质的AI工作流其第一步往往并非直接去编写代码而是要把相关的问题给询问清楚。场景二AI 修复 bug 不要靠猜测。线上出现了报错的情况有某个接口会偶发地出现500的问题。普通的AI一般会直接去查看报错的内容以此来修改代码。它会先修改三个文件接着运行一次测试之后就会告诉你“修好了”。你去查看之后会发现这个bug确实不再报错了但旁边的一个功能却出现了损坏。在使用diagnosing-bugs之后Agent首先会去尝试把问题给复现出来接着会慢慢缩小排查的范围之后会列出和这个问题相关的一些假设再去添加日志或者开展测试来进行验证最后完成修复的工作还会补上回归测试的这个环节。在真实的工程场景之中最让人头疼的其实并不是bug难以被解决而是有人一边凭借着自己的猜测一边就去进行修改操作。场景三让AI来写测试其实并不是让它自己去自导自演。将测试工作交给AI来给支付模块进行补充。普通的AI或许会把实现和测试放在一起完成到最后测试可以全部通过但却没有对关键风险进行测试。所谓的测试仅仅只是能够证明“自己所编写的代码可以正常运行”。运用 TDD 之后Agent 会先编写失败测试再进行最小实现最后开展重构工作。要是不按照这样的方式来管理开发流程那么就很容易写出看起来似乎十分完整但实际上仅仅只是证明自身代码可以正常运行的测试。测试的价值不是覆盖率数字是它有没有测到真正会坏的地方。场景四长任务中断后不要让上下文烂尾。我们已经和AI进行了足足两百轮的聊天整个项目的修改工作也推进到了一半的进度要是再这样继续下去模型就会开始变得模糊不清。用handoff之后Agent 把当前状态压缩成 handoff 文档哪些做完了哪些没做关键决策是什么坑在哪里。下一轮对话直接读这个文档继续。长上下文不是无限用的资源。知道什么时候该交接比硬撑更靠谱。八、泼几盆冷水写到这里我泼几盆冷水哈。第一所谓的Skills其实并不能替代工程层面的实际能力。你不会因为装了一个diagnosing-bugs就突然会修 bug 了。你不会因为装了一个codebase-design就突然会做架构了。Skills 帮你执行流程但判断流程对不对、输出好不好还是你的事。第二Skill 写得烂Agent 只会稳定地烂。一个质量欠佳的Skill要比完全没有Skill来得更加危险。如果只是没有Skill的话Agent至少还能够自由地发挥自身的空间。可要是拥有了质量并不合格的SkillAgent就会稳定地依照错误的流程去执行相关的操作。第三安全风险不能忽略。Skills 是文件夹里面可以有脚本、命令、文件操作。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸而是在给 AI 提供一个可以执行特定动作的工作包。有意思的是这次 GitHub weekly trending 里还有一个项目叫NVIDIA/SkillSpector描述是Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks.连 NVIDIA 都在做 Skills 安全扫描了。说明这个问题不是杞人忧天。第四工具兼容性不要替读者做承诺。mattpocock/skills的描述里写了.claude directory。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸而是在给 AI 提供一个可以执行特定动作的工作包。第五团队没有流程Skills 救不了。这可以说是最根本的一条。所谓Skills其实只能用来固化已经存在的流程没办法凭空生成出新的流程来。要是你的团队连代码审查的规范都还没有建立起来、连测试策略都没能达成统一的对齐、连需求文档都没有人专门来负责撰写的话就算装上再多的Skills其实也发挥不了什么实际的作用。第六Skill 不是写完就扔。你的工作方法在变项目在变工具也在跟着升级那么Skill也得跟着做出相应的调整。你可以把它当成代码的一部分该进行重构的时候就进行重构。Skills所固化的其实是你当前的工作方法如果你的方法本身需要进行迭代记得定期回头去修改Skill别把它当成一成不变的圣旨。九、普通人到底该怎么开始不要去收藏一百个。每天只做这一个。找一个你每周重复 3 次以上的任务。怎么判断值不值得做三个标准你每周做 3 次以上、步骤基本固定、做错了有后果。符合两个就值得封装。不符合的临时 Prompt 够了。像修复程序漏洞的具体流程、整理每周工作进展报告的框架、审核代码时需要关注的检查要点、编写项目说明文档的标准模板还有在开展需求评审之前需要提前准备好的各项清单。把你的要求、步骤、输出格式、失败处理写下来。不用写得很复杂。5 个步骤3 个检查点1 个输出模板够了。然后放进你的 Skills 目录。跑几次。看它有没有真的减少你的返工和废话。做完这一个当它运行起来的那一瞬间你就会懂。Skills 的价值不在收藏在复用。明天你会开始想做第二个。后天你会想把所有重复的流程全都搬进去。到那一步你就不是在使用 Skills了。你是在把自己的经验变成 Agent 能执行的资产。十、别收藏了今天就来实实在在做一个。Prompt 时代大家所比拼的其实是谁更能够去提出问题。在Skills时代当中大家开始比拼谁更会去整理自己的工作流。这件事可比单纯收藏Prompt要难上不少而且它的价值也要更高一些。其实Prompt说白了就是一句话。Skills呢则是一整套用来把事情做好的具体方式。模型的能力确实会变得越来越强这一点可以说是确定无疑的。不过话说回来模型越是强大也就越容易暴露出来另一个值得我们思考的问题你到底是不是真的清楚自己想要什么又到底该怎么做才行。模型固然可以帮你写出任何一段代码但它没办法替你决定到底什么样的代码是值得去写的。往后在AI编程这一领域双方之间所存在的差距可能不只是停留在模型这个层面上的差距更有很大概率是在整体的流程层面所存在的差距。能够把自身所拥有的经验拆解成智能体可以执行的具体步骤的这类主体也就更容易将人工智能当作一种实用工具来加以使用而不是把它当成一个话比较多的实习生。别再忙着收藏了。今天就来实实在在做一个。
