企业官网建设流程全解析

如果你用过Claude Code、Codex或者opencode这类AI编程助手，多半会遇到一个特别尴尬的场面：明明是同一个仓库，昨天刚让AI按团队风格写了一个模块，今天让它改个bug，它却像第一天入职一样，把项目里约定俗成的命名规范、提交格式、TODO写法全忘了。直到我把skills这个功能认真收拾明白，情况才彻底改观。

先说人话解释一下：skills就是给AI助手准备的“岗位手册+工具箱”。它不是一个需要联网调用的神秘接口，而是一个有固定结构的目录，里面装着SKILL.md说明文件、参考文档、可执行的脚本。只要装进Claude Code、Codex这类工具的配置目录，AI就会在遇到相关任务时自动翻出对应手册，照着里面的规范干活。这篇文章我会从“什么是skills”讲起，写清楚怎么手动安装GitHub上的skills、有哪些靠谱的skills源和场景推荐，最后也把自己开发skills的模板和踩坑记录一并分享出来。如果你是第一次接触这个概念，按文章的步骤走一遍基本就能上手；如果你已经装过几个技能包但觉得不好用，重点看第4、5节的写法原则和排查思路。

1. AI Skills到底是什么：给AI助手的“专业手册+工具箱”

1.1 一个解决“AI有知识但没规矩”的方案

我最早接触skills这个概念，是在一次重构老项目的时候。项目里有套很老但必须兼容的数据格式转换逻辑，我在对话里把格式文档、转换规则、禁止踩的坑都贴给了Claude Code，它干活还算靠谱。可到了第二天，新开一个会话继续改另一个文件，它又把规则忘得一干二净。当时我的第一反应是“模型记忆力不行”，后来才意识到：问题不在模型，在我没给模型一个稳定的知识载体。

skills的核心思路，就是把那些“每次都要重新粘贴、每次都要口头强调”的知识，沉淀成固定的文件目录。它本质上是一个带有结构化说明的技能包：SKILL.md里描述了这项技能是干什么的、什么时候该用、具体按什么步骤执行，旁边还可以带上scripts脚本和references参考文档。AI助手根据当前对话的任务描述，自动判断是否需要激活某个技能。这个机制解决的是LLM最常见的毛病——它掌握通识知识，但不懂你所在团队、你手头项目里的隐性规则。

打个比方你就明白了。普通prompt是你在路边拦下一个资深工程师，临时口述需求，他凭经验干活；MCP像是给这位工程师办了一张工牌，让他能调用公司内部系统和数据库；而skills则是一本《老员工入职手册》，里面写了公司的代码规范、评审流程、哪些坑绝对不能碰。三者不是竞争关系，而是从“一次性指令”到“工具接入”再到“领域方法论”的三个层次。

1.2 和prompt、MCP到底有什么区别

很多人一上来会混淆skills和MCP，我也一样。后来我用一张对比表才彻底理清：

从这个表能看出来，skills真正解决的是“可复用、可沉淀、可分享”。MCP解决的是“能不能连上”，skills解决的是“会不会干好”。

我在实际使用中还有一个感受：skills对多文件项目尤其有用。AI处理一个任务的时候往往要连续接触好几个文件，如果你只在某个文件头部写了注释，它处理另一个文件时大概率看不到；但如果把规范写进一个skill，任务一触发，整套规范都会被加载进上下文。这也解释了为什么社区里很多“superpower skills”这类技能库要设计成十几个技能包的形式——它们想把每个细分场景的规范都固化下来，而不是塞进一段超长prompt里。

2. 手动安装GitHub上的Skills：完整实操记录

2.1 安装前先搞懂目录约定

手动安装skills，本质就三件事：把仓库代码拿到本地、按目标工具的目录约定放进去、让配置正确加载出来。但很多人恰恰卡在第二步，因为不同工具对skills目录的约定并不一样。

以我日常在用的几个工具为例：

• Claude Code：项目级技能放在.claude/skills/目录下，用户级放在~/.claude/skills/（macOS和Linux）或对应用户主目录里。装进去之后，在支持命令的版本里可以直接用/skills之类指令查看列表。
• OpenAI Codex：支持在.codex/skills/目录中定义技能，也可以在项目说明文件里声明路径。查看当前技能状态也有对应的交互命令。
• OpenCode：同样支持skills机制，它的目录约定和TypeSafe AI那一套工具链相关，具体以仓库README为准。

还有一点要提醒：同一个技能包，在Claude Code里能用，不代表换个工具就能直接识别。目录对了，还要确保SKILL.md里的frontmatter字段和目标工具兼容。不同工具的约定细节有差异，手动安装前一定要去看目标工具官方文档里关于skills的说明，别想当然。

2.2 手动安装的四个步骤

第一步，找到合适的skills仓库。GitHub上搜索“awesome claude skills”、“codex skills”、“superpower skills”、“nature skills”都能找到大量技能库。挑的时候别只看star数，我一般看三个东西：最近提交时间是否在半年内、仓库里是不是真有SKILL.md文件、README里有没有清楚的目录结构和使用说明。长期没人维护的仓库，技能大概率跟不上新版本的模型能力。

第二步，下载。两种方式任选：直接Download ZIP，或者用git clone拉下来。图省事就下载压缩包，但后续想更新还得重新下一次；想长期跟进某个技能库就clone到本地，更新的时候在仓库目录里pull一下就行。

第三步，放到正确位置。这里有个关键细节：把压缩包解压后，里面往往还有一层仓库文件夹，例如superpower-skills-master/superpowers/skills/...。不能直接把最外层文件夹塞进skills目录，而要把里面真正包含SKILL.md的那个子文件夹拷到目标配置目录。如果目标仓库是一个“一仓库多技能”的结构，那你只需要复制用到的几个技能子目录，不必整仓搬过去。

第四步，验证是否加载。重新打开一个AI编程会话，用一句和该技能强相关的描述发个任务，看AI给出的回答有没有体现技能里的规范。比如装了一个“代码审查”技能，就让AI“按技能规范审查当前分支的改动”。如果AI明显使用了技能里的术语、流程或格式要求，说明加载成功。在Claude Code里也可以直接输入管理命令查看当前技能是否出现在列表中。

2.3 装完不生效的常见原因

如果验证时发现“石沉大海”，先别急着骂工具，大概率是下面几个问题：

• 目录层级不对。最常见的是多套了一层目录，SKILL.md没有被直接放在技能根目录。
• 技能目录名和SKILL.md里的name不一致。很多工具是认文件夹名或认name字段的，两边最好保持一致。
• 没有重启会话。技能加载发生在会话初始化阶段，老会话里可能还是旧的上下文。
• 触发的描述写得太模糊。AI判定“是否激活该技能”主要靠description和当前任务文本的语义匹配，如果你描述的任务偏离了技能说明，它就不会调用。

这些坑我在第5节会展开讲，先记得一点：手动安装不是“文件放进去就结束”，验证和语义匹配同样重要。

3. 值得收藏的Skills源与按场景推荐

3.1 几个口碑不错的skills源仓库

现在GitHub上skills仓库很多，但质量参差不齐。我建议你重点参考这几类：

第一类是综合型技能库，比较有代表性的是superpower skills这类项目。它把开发中常见的代码审查、重构、测试生成、文档编写等场景都封装成了独立技能包，结构统一、模板清晰，很适合作为学习和安装的起点。第二类是特定工具或特定团队维护的技能集，比如TypeSafe AI相关的skills仓库，它们往往和opencode这类工具链结合得更紧密。第三类是聚合类“awesome”仓库，这类仓库本身不直接提供技能，而是把散落在各处的优质技能源收录在一起，适合按图索骥。

我个人的建议是：优先选综合型技能库，先把两三个核心场景跑通，比如“代码审查”和“提交信息生成”。不要一上来就装二十个技能，技能包越多，AI在上下文里做匹配的时候噪音越大，反而容易误触发。

3.2 按场景推荐的skills组合

结合我自己和身边朋友的实际使用，不同场景适合装的技能方向大致如下：

拿数学建模举例。参加华为杯这类比赛的时候，你大概率既要写数据处理代码，也要排LaTeX论文，还要画图表。装一个“数据清洗规范”技能，AI处理缺失值、异常值的时候就不会随手drop一整列；装一个“论文排版”技能，AI输出的LaTeX片段会符合你事先定义的模板；再配一个“图表配色”技能，所有图的风格就能保持统一。这些事如果靠每次手动在prompt里写，基本坚持不过第二天。

AI漫剧方向同理。漫剧创作者最头疼的是角色一致性——同一张脸在不同分镜里经常漂移。把“角色描述生成”和“画面提示词规范”封装成skills后，AI画分镜时能参考同一套角色设定，至少不会在同一个项目里画出两张脸。这种场景里，skills的潜力其实比写普通prompt大得多，因为技能可以跨会话持续生效。

4. 开发自己的Skills：从SKILL.md开始

4.1 SKILL.md的frontmatter和正文结构

自己开发skills没有想象中复杂，核心就是写一个高质量的SKILL.md。

SKILL.md的开头是YAML格式的frontmatter，最关键的字段是name和description。name要短，能代表这项技能；description则是灵魂，它决定AI什么时候激活这个技能。写description要具体，给出触发场景、任务类型和输入输出特点。一个合格的description应该像这样：

当用户要求对TypeScript代码进行代码审查、检查潜在bug、发现性能问题或评估架构合理性时，使用此技能。适用于PR review、代码走查等场景。

注意这里的描述要“窄而准”。你写“处理代码相关任务”这种泛化描述，AI几乎随时都会尝试加载它，效果反而很差。

正文部分不要写成大段的理论。我建议用这种结构：先写核心原则，用三到五条不可妥协的规则；再写执行步骤，按顺序列出每一步要做什么，最好配上输入输出示例；然后写禁忌清单，明确告诉AI哪些事绝对不要做。这样做的好处是，技能的约束从“规则”到“流程”再到“边界”，三层下来AI执行起来基本不会跑偏。

4.2 一个可以直接抄的模板

我把自己一直在用的SKILL.md模板简化了一下，你可以直接抄走改成自己的：

--- name: frontend-component-review description: 当需要审查前端React组件代码、评估组件可维护性与可访问性、检查状态管理逻辑时使用。 --- # 前端组件审查规范 ## 核心原则 1. 组件必须保持单一职责，一个组件只做一件事。 2. 禁止在组件内部写超过200行的逻辑；超出的部分必须拆分。 3. 所有交互元素必须考虑键盘可达性和ARIA标签。 ## 执行步骤 1. 先阅读组件整体入口，确认Props类型定义。 2. 梳理状态：区分组件内部state与外部store数据。 3. 检查渲染逻辑：列表渲染是否有稳定key，条件渲染是否有兜底。 4. 输出审查结果，按“问题-定位-修改建议”的格式列出。 ## 输出格式 每个问题用三级标题呈现，包含： - 所在文件和行号 - 问题类型（可维护性/可访问性/性能） - 修改建议代码片段 ## 禁忌 - 不要只提问题不给修改建议。 - 不要展开与本次审查无关的重构讨论。 - 不要使用console.log作为调试替代方案。

模板里最关键的不是内容本身，而是它体现了“具体到能执行、严格到不跑偏”的原则。写的时候多想想：一个AI拿到这份文档，能不能不需要额外解释就把活干出来？如果它还来问你“这个组件的边界跟header组件重叠怎么办”，说明你的文档还需要补充更多边界情况。

4.3 让skills“好用”的五个原则

写了不少skills之后，我总结了五个原则，分享给你参考。

第一个原则是示例驱动。AI最擅长的就是模仿，与其写一百句抽象的“要优雅”，不如给一个“优雅”和“不优雅”的对比示例。第二个原则是边界清晰。description里说清楚“什么情况下用”，正文里再补一段“什么情况下不用”，可以大幅降低误触发率。第三个原则是保持可验证。每次改完SKILL.md，用一个真实小任务去验证它有没有生效，不要凭感觉判断。第四个原则是用git管理你的skills目录。我自己的技能库就是一个独立仓库，需要的人可以直接clone来用。第五个原则是定期做减法。功能重复的技能只留一个，效果不明显的直接删掉，别心疼。

5. 常见问题排查与Cleanup经验

5.1 装不上、不加载、乱触发怎么办

按我的经验，skills相关的问题基本可以分三类。

第一类，装不上。通常是目录放错了或者缺少SKILL.md。检查顺序：目标工具是不是支持skills -> 目录路径对不对 -> 技能文件夹里有没有SKILL.md -> frontmatter字段格式对不对。这四个环节排查一遍，九成问题能解决。

第二类，不加载。主要是语义匹配的问题。你可以在对话里明确提到技能名称，比如“用代码审查技能检查这个文件”，这样比隐晦的描述更容易触发加载。如果这样还是不加载，把技能note里的description改得更贴近你的常用说法。

第三类，乱触发。比如你明明只让AI改个小bug，它却非往“架构重构技能”上靠。这类问题多半是description写得范围太大，需要把触发条件收窄，加上“仅当用户明确要求评估架构时使用”之类的限定。

5.2 技能冲突与加载优先级

当装了多个技能时，可能会遇到两个技能描述相近、上下文重叠的情况。我的建议是尽量精简技能库。一次维护两三个高频技能，比堆二十个技能更可靠。

万一真的遇到冲突，先在SKILL.md的description里增加互斥条件，明确“本技能不适用于XX场景”。如果还不行，就停用其中一个。大多数工具加载技能是按目录扫描的，直接把冲突技能目录改名或移到备份目录即可，不必删除。

5.3 关于清理：什么时候该删、怎么删

网上讨论skills清理方法的帖子不少，我也强烈建议定期清理。我的经验是：一段项目结束后，把那些只服务这一个项目的技能移出用户级目录，只保留项目级配置里；连续两周没用过的通用技能，考虑删除；安装超过三个同类技能但效果都一般的，全部删掉，只留一个最顺手的。

清理本身很简单：删目录、改配置、重启会话三步。但要提醒一点，删除前看一眼SKILL.md里有没有值得保留的内容，比如某些示例代码片段，可以先存到自己的笔记里。很多人的技能库越用越乱，核心原因是舍不得删，而不是不会装。

我自己现在的做法是：通用技能只保留代码审查、commit信息生成、CHANGELOG维护这三样，其他的全部按项目放在项目级目录里。项目结束，目录一删，环境干净。

最后再分享一个心得：skills这个机制最妙的地方，不在于它能让AI多聪明，而在于它能逼着我把自己的经验、团队的规范、项目的边界想得更清楚。你写得越具体，AI执行得越稳；反过来，它也会让你发现自己所谓的“经验”里，有多少其实是模糊的直觉。试着把最常做的那个任务写成一份SKILL.md，你大概率会回来感谢这个功能的。