一、前言
上一小节我们聊了 agent 宪法。
agent 宪法解决的是：AI 在这个项目里应该遵守什么规矩。它更像项目级规则，告诉 AI 什么能做、什么不能做，遇到冲突时听谁的，什么情况算完成，什么情况不能交付。
但这里有一个问题：你不可能把所有东西都写进 agent 宪法。
因为 agent 宪法往往会长期进入上下文。也就是说，只要 AI 在这个项目里工作，它就很可能一直带着这份规则。如果你把需求梳理、开发计划、bug 排查、页面验收、代码审查、发布流程、交接流程全部塞进去，最后不只是内容会变成长篇大论，还会持续消耗上下文和 token。
看起来很完整，实际上 AI 反而更容易抓不住重点，你的钱也花得更快。
所以我们还需要第二个东西：skill。
skill 解决的不是“再写一份更长的规范”，而是把一套专业工作流程，变成 AI 可以按需调用的技能。它通常是语义命中后才加载，所以更适合承载那些具体、复杂、但不是每次都需要的流程。
它主要解决三个问题：
第一，让 agent 宪法保持简洁，不要什么都往里面塞。
第二，让 AI 在 Vibe Coding 过程中减少漂移，不要每次都自由发挥。
第三，让小白也能借用高手的工程经验。
很多开源 skill，本身就是有经验的工程师把自己的工作方法、排查流程、验收习惯沉淀出来的结果。你使用这些 skill，本质上不是多了一段提示词，而是把一套成熟经验接进自己的 AI IDE 里。
二、什么是 skill？
很多小白刚开始 Vibe Coding 的时候，最常见的状态是：所有事情都靠一句话硬推。
想做功能，就说“帮我加一个登录”；遇到报错，就说“帮我修一下”；页面不好看，就说“帮我优化一下 UI”；项目跑不起来，就把报错贴过去，让 AI 继续改。
这种方式前期看起来很爽，因为 AI 反应很快，也确实能写出东西。但问题是，AI 每次都在根据当前这句话自由发挥。
你没有告诉它做功能前要不要先拆需求，改代码前要不要先看项目结构，遇到 bug 要不要先复现，页面改完要不要打开浏览器验收，完成前要不要跑测试。于是它很可能这次是一个做法，下次又换一个做法。遇到问题就猜，猜错了就继续改，改到最后代码越来越乱，你也不知道它到底验证过没有。
而有经验的软件工程师之所以更专业，不只是因为他会写代码，而是因为他遇到这些问题时有一套稳定流程。
skill 就是把这些流程交给 AI。
你可以把 skill 理解成 AI 的专项能力包，也可以理解成：敲代码遇到某一类问题时，AI 应该采用的处理思路和执行流程。
如果说 agent 宪法是项目员工手册，那么 skill 就像岗位 SOP。agent 宪法告诉 AI 这个项目的长期原则，skill 则告诉 AI 遇到某一类具体任务时，应该按什么流程执行。
所以 skill 的本质，不是一段普通提示词，而是一套可复用的专业流程。
三、skill 和 agent 宪法有什么区别？
agent 宪法和 skill 很容易混在一起，但它们解决的问题不一样。
agent 宪法管长期原则，skill 管专项流程。
agent 宪法应该短、硬、清楚，写的是项目里长期有效的规则。比如架构优先、不要乱补丁、不要跳过验收、不要破坏项目边界。
skill 则承载具体流程。比如 bug 到底怎么查，页面到底怎么验收，代码审查到底看哪些风险，完成任务前到底怎么证明真的完成。
换句话说，agent 宪法告诉 AI “必须这样做”，skill 告诉 AI “具体怎么做”。
如果你把所有“具体怎么做”都写进 agent 宪法，宪法就会越来越长，最后变成一份 AI 抓不住重点的大杂烩。更麻烦的是，agent 宪法往往会长期占用上下文，所以这些不一定每次都用得上的流程，会在每一次任务里反复消耗 token。
而 skill 的价值，就是把这些复杂流程拆出去，让它们在需要的时候再被加载。
当然，skill 也不是完全不消耗 token。如果一个 skill 本身写得很长，或者带了大量参考资料、模板、代码和脚本，真正加载的时候一样会消耗上下文。
所以好的 skill 也应该克制。该写流程写流程，该引用资料引用资料，不要把无关内容都塞进去。
四、skill 为什么重要？
skill 的第一个作用，是减少 AI 漂移。
Vibe Coding 里有一个很常见的问题：一开始你让它做的是 A，聊着聊着它开始做 B；一开始项目架构是这样，改着改着它开始按另一套思路写；一开始要求先验收再完成，后面它又开始写完就说完成。
这就是漂移。
漂移的原因很多，其中一个重要原因是：AI 每次都在当前上下文里临时组织做法。上下文一长，任务一复杂，它就容易忘掉前面的约束，也容易把流程做变形。
skill 的作用，就是把某一类任务的标准做法固定下来。当 AI 需要处理这类任务时，IDE 或 Agent 可以根据用户语义自动选择对应 skill，把这套流程加载进来。这样它不是每次都临时发挥，而是回到一套稳定的工作流程里。
skill 的第二个作用，是复制高手经验。
很多新手真正缺的，不只是代码能力，而是工程经验。你不知道需求应该怎么拆，不知道 bug 应该怎么查，不知道代码审查要看哪些风险，不知道上线前要验证什么，也不知道哪些改法会给后期埋雷。
但很多开源 skill，本身就是有经验的工程师把自己的工作方法沉淀出来的结果。它可能来自一个长期写代码的人，也可能来自一个长期做工程实践的团队。里面沉淀的是他们处理某一类问题的方法论。
所以使用 skill，不只是多了一段提示词，而是让 AI 在当前任务里加载了一套更成熟的经验。你自己可能还不是编程大师，但你可以让 AI 按编程大师总结出来的流程工作。
当然，这不代表装了 skill 你就真的变成大师了。你还是需要判断目标、理解风险、看最终结果。但至少 AI 不再是完全自由发挥，而是在一套更专业的流程里做事。
五、skill 通常怎么使用？
这里要注意，skill 不是让你每次手动排顺序。
不是说你要先告诉 AI 用哪个 skill，再告诉它下一步用哪个 skill。很多时候，AI IDE 会根据你的表达自动判断该用哪个 skill。
你说要排查问题，它可能会匹配调试类 skill；你说要写开发计划，它可能会匹配计划类 skill；你说要检查页面，它可能会匹配浏览器或前端验收类 skill。
当然，你也可以主动点名某个 skill，让 AI 按那个 skill 执行。
所以更准确地说，skill 是一套可以被 IDE 自动调度、也可以被用户主动点名的能力模块。你真正要理解的，不是死记调用顺序，而是知道自己有哪些 skill，它们分别解决什么问题。
另外，skill 也不是普通提示词。
一个 skill 通常会有自己的说明文档，告诉 IDE：这个 skill 叫什么，什么时候应该使用，解决什么问题，执行时要遵守什么流程，最后应该输出什么结果。
有些 skill 还会带参考资料、模板、脚本，甚至专门的命令。
这一点很重要。因为有些任务不是靠文字说明就能完成的。比如安装 skill、创建插件、启动浏览器验证、检查项目规范，这些场景往往会有配套脚本或命令。
所以使用 skill 的时候，不要只靠猜。你可以直接问 IDE：当前有哪些 skill？某个 skill 是干什么的？它有没有命令或脚本？如果我要做这个任务，应该触发哪个 skill？
这比自己乱猜靠谱得多。
六、普通人怎么安装和理解 skill？
对普通人来说，安装 skill 其实不一定复杂。
很多时候，你不需要自己研究目录结构，也不需要手动复制文件。你可以直接把 skill 的链接丢给你的 AI IDE，然后告诉它：帮我把这个 skill 安装好，并确认它能被当前工具识别。
如果你不知道这个 skill 适不适合当前项目，也可以直接问 IDE：这个 skill 适合我现在这个项目吗？它会解决什么问题？会不会和现有 agent 宪法冲突？安装之后应该怎么触发？有没有命令或脚本需要注意？
这比自己看半天文档更适合新手。
因为 skill 本身就是给 AI 用的，你完全可以让 AI 帮你读它的设计文档，解释它的使用方式，再判断它适不适合当前项目。
如果一个 skill 是通用的，但你的项目比较特殊，比如前端框架不同、后端语言不同、部署方式不同，你也可以让 IDE 帮你做适配。比如让它根据当前项目的技术栈、目录结构和 agent 宪法，判断这个 skill 应该怎么用，哪些规则需要调整，哪些命令不能直接跑。
也就是说，普通人不需要一开始就把 skill 机制全部研究透。
你只要知道三件事：
第一，看到合适的 skill，可以把链接丢给 IDE，让它帮你安装。
第二，不知道怎么用，可以让 IDE 解释它的用途、触发方式、命令和注意事项。
第三，不确定适不适合当前项目，可以让 IDE 结合项目情况做判断和适配。
这也是 AI IDE 的价值。它不只是帮你写代码，也可以帮你理解和管理这些工程工具。
七、我目前常用的 skill
这里不瞎推荐，就按我自己电脑上实际有的 skill 来说。
我目前常用的工程类 skill，主要有：
brainstorming、writing-plans、systematic-debugging、verification-before-completion、requesting-code-review、dispatching-parallel-agents、browser 和 sliver-engineering-workflow。
它们不是让你按顺序一个一个手动执行，而是覆盖 Vibe Coding 里最容易翻车的几个场景。
1.brainstorming： 偏需求和设计，避免 AI 一上来就写代码。
2.writing-plans 偏开发计划，把需求拆成可执行任务。
3.systematic-debugging 偏系统化排查，核心是不要猜，要先找根因。
4.verification-before-completion 偏完成前验收，防止 AI 写完代码就直接说完成。
5.requesting-code-review 偏代码审查，用另一个视角检查风险。
6.dispatching-parallel-agents 偏多 agent 并行，适合多个独立任务同时推进。
7.browser 偏浏览器验证，适合前端页面、交互、截图和本地服务检查。
8.sliver-engineering-workflow 更像一套完整工程流，强调架构优先、真源优先、严格验收、不漂移、不乱补丁。
你不需要死记它们的调用顺序。你只需要知道它们大概解决什么问题。真正执行的时候，IDE 往往会根据你的语义自动选择；如果你想强制使用，也可以直接点名。
八、最后
如果说 agent 宪法解决的是：AI 在这个项目里应该遵守什么规矩。
那么 skill 解决的是：AI 遇到具体任务时应该按什么专业流程执行。
宪法管原则，skill 管流程。宪法防止 AI 乱来，skill 防止 AI 瞎做。
更重要的是，skill 可以把高手经验变成 AI 能反复调用的能力。对没有代码基础的人来说，这一点非常关键。因为你不一定知道专业程序员怎么拆需求、怎么排 bug、怎么做验收、怎么防止项目漂移，但你可以让 AI 使用这些已经沉淀好的 skill。
同时，skill 也能让 agent 宪法保持简洁，把复杂流程按需加载，而不是每次都塞进上下文里持续消耗 token。
所以，skill 不是 agent 宪法的重复，也不是普通提示词的升级版。
它是把专业经验流程化，再交给 AI 按需调用的一种方式。
这也是 Vibe Coding 想真正做出可维护项目时，非常重要的一块工程底座。
