企业官网建设流程全解析

最近AI圈子里最热的一个词，就是skills。从 Anthropic 官方发布 Claude Agent Skills，到 OpenAI Codex 把 skills 当作默认扩展机制，再到 GitHub 上冒出一堆“superpowers”“awesome-skills”之类的合集仓库，几乎一夜之间，所有人都在讨论“怎么给 AI 装外挂”。

我前阵子把一个写了很久的内容生成流程全部改造成 skills 体系，顺手把几个前端项目里的重复性工作也封装成了技能，实测下来效率提升非常明显。今天就把我对 skills 的理解、上手过程、踩过的坑、以及目前值得关注的下载平台和资源，完整整理出来，希望能帮到正在观望或已经入坑的同学。

先给一个定义，方便对得齐频道：skills 是面向 AI Agent 的可复用技能包，本质上是把“一段提示词 + 若干参考脚本/数据文件 + 使用说明”打包成一个标准目录，让 Claude、Codex 这类编程智能体在不改代码的情况下，学会执行某个具体任务。它不是插件，不是 API，更像是一种“给 AI 看的使用说明书 + 工具箱”。

1. 为什么 skills 突然就火了

1.1 从“聊天”到“干活”：AI 工作流的范式转移

过去两年大家用 AI 的主要方式是对话：打开对话框，把需求打进去，AI 给你一段代码、一篇文章、一个方案。这种方式适合“问问题”，但干不了“重复性的复杂活儿”。举个很直观的例子，我想让 AI 帮我做一份前端项目的代码规范审查，每次都要把规则、目录结构、检查项重新描述一遍，AI 还不一定理解到位，输出水准忽高忽低。

skills 解决的就是这个问题。相当于你把“如何做代码规范审查”这个过程，包括审查清单、检查脚本、报告模板、典型问题库，一次性打包成技能。之后无论何时需要，AI 都能稳定复现这套流程，输出质量稳定、风格统一，而且不需要你反复解释需求。

这就是工作流的范式转变：从“每次重新描述”到“一次封装、反复使用”。这跟我们以前写函数、封装组件的思路一模一样——编程领域早就证明了“复用”的价值，AI Agent 领域现在正在走同样的路。

1.2 skills 和插件、工具调用的本质区别

刚接触 skills 的人最容易困惑：它跟插件（Plugin）、工具调用（Function Calling）有什么不一样？

我用一个生活化的类比解释。插件相当于你给 AI 装了一个“新器官”——比如装了浏览器插件，AI 就有了“眼睛”能看网页；装了代码执行器，AI 就有了“手”能跑代码。每个插件都对接了具体的 API 或运行时能力。

而 skills 更像是“操作手册 + 工具箱”。它不一定调用新 API，更多时候是教 AI 如何更好地使用已有的能力。比如我有一个“代码审查” skill，里面没有调用任何外部服务，只是提供了一套完整的审查方法论、规则列表、评分标准和示例报告，AI 用自己的语言理解能力加上这套方法论，就能输出高水准的审查结果。

本质上，插件解决“能不能做”，skills 解决“怎么做更专业”。两者可以配合使用：插件提供能力底座，skills 定义专业流程。理解了这一点，你就能明白为什么 skills 对多数普通用户和开发者来说门槛更低——你不需要会写 API 集成，只需要会写文档，就能做出一个很有用的技能。

1.3 为什么 Claude 和 Codex 都在押注 skills

Anthropic 在 2025 年公开了 Claude Agent Skills 规范，紧接着 OpenAI 的 Codex 也把 skills 作为官方推荐的扩展方式。巨头们不约而同押注同一件事，说明这不是临时起意的功能点，而是 Agent 时代的底层基础设施。

往深了说，这背后有一个共识：大模型的通用能力已经很强了，但“专业能力”必须靠外部知识来补充。模型再大也不可能记住所有领域的全部方法论，而 skills 恰好提供了一种低成本、高灵活性的外部知识注入方式。不用微调、不用向量数据库、不用重新训练，写几个 Markdown 文件就能让 AI 变专业，这是所有厂商都愿意支持的轻量方案。

对我们普通用户来说，这也意味着 skills 是一个值得长期投入的技能方向。今天学会的技能，明天换一个 Agent 平台大概率还能用，学习成本不会浪费。

2. skills 的核心原理：第一性原理解读

2.1 SKILL.md：一份“给 AI 看的使用说明书”

所有 skills 的核心都是SKILL.md文件。这个名字起得很直白：SKILL 点 MD，就是技能说明书。我最初以为这玩意儿玄机很深，看完规范才发现，它本质上就是我们再熟悉不过的 Markdown 文档，只是按特定结构组织。

一份规范的SKILL.md通常包含几个部分：

• 技能名称与简述：让 AI 快速理解这个技能是干什么的；
• 适用场景：什么时候该用、什么时候不该用，避免 AI 误触发；
• 工作流程：一步步列出执行步骤，AI 会严格按照这个顺序操作；
• 输入要求：需要用户提供哪些信息，格式是什么；
• 输出规范：最终产物应该长什么样，包含哪些部分；
• 注意事项：边界、禁忌、容易出错的地方。

你可以把它理解成一份“给 AI 看的操作 SOP”。大语言模型的强项就是读文档，你把流程写得越清晰，它执行得就越准确。这也解释了为什么 skills 的官方规范里反复强调“用自然语言写清楚步骤”，而不是写代码——AI 是靠语义理解的，不是靠函数调用。

2.2 目录结构与文件组织：一个技能一个文件夹

除了SKILL.md，一个完整的 skills 还包含其他资源文件，组织方式非常朴素：一个文件夹就是一个技能，文件夹里放着说明文档和配套资源。

我见过一个写周报的技能，结构大致是：

• weekly-report/SKILL.md：技能说明书；
• weekly-report/templates/：周报模板；
• weekly-report/examples/：几份优秀的周报示例；
• weekly-report/checklist.md：自查清单。

这种“一个文件夹承载一个完整技能”的设计，带来两个巨大好处。第一，分发极其简单，拷贝文件夹就能分享；第二，迭代极其方便，想改进技能，直接改文件就行，不需要任何编译或构建流程。这种极简设计背后其实体现了非常好的工程判断：想让人人都能创造和分享，门槛必须足够低。

2.3 触发机制：AI 怎么知道“该用技能了”

这是我自己琢磨了很久的一个问题：我装了 50 个技能，AI 怎么知道在什么场景用哪个？

目前的实现方式主要是“靠模型自主判断”，或者说叫“语义触发”。AI 在读取系统提示或了解自身能力清单时，会看到所有可用技能的简述。当对话内容与之匹配时，模型会自动检索并调用对应的技能。比如你让 AI“帮忙审查这段代码”，它看到"代码审查"技能的描述是“检查代码质量、发现潜在问题、给出规范建议”，就会自动把技能内容加载进来，然后按里面的流程执行。

这种机制很像人类专家的知识调用：记忆里存了很多方法论，遇到具体问题时调出对应的方法。好处是灵活，不需要用户手动指定；但代价是描述质量决定触发准确度——如果你的技能描述写得模棱两可，AI 就容易在错误的场景调用它。

所以我的经验是：给技能写“适用场景”和“不适用场景”时，宁可多写几句，也别用太模糊的话。后面讲开发实战的部分，我再展开聊这个细节。

3. 从零上手：安装、启用、管理 skills 的实操全流程

3.1 Claude 官方市场的安装路径

如果你用 Claude，上手 skills 最直接的方式就是官方市场。操作路径非常清晰：打开 Claude 客户端或 Claude Code，进入设置里的 Skills 或能力市场，浏览分类列表，选中需要的技能，一键启用。

我在第一次安装时其实犯了个小错误——没有注意技能是否需要在特定目录下生效。后来弄清楚了：Claude 的 skills 默认放在用户目录下的某个.claude/skills文件夹里，你也可以在项目里放.claude/skills实现“仅对当前项目生效”。这是个特别有用的特性：全局技能处理通用事务，项目技能处理特定代码库的专属任务。

安装第三方技能时，最常见的方式是把技能目录手动拷贝到.claude/skills下，然后重启会话。注意是新开一个会话才生效，已经开着的会话不会自动加载新技能。这个细节我踩过，还以为是技能写错了，排查了半天。

3.2 Codex 环境下的 skills 引入

OpenAI Codex 支持 skills 的方式跟 Claude 大同小异，同样是目录扫描加语义识别。把技能文件夹放进 Codex 指定的 skills 目录，新会话里 AI 就能看到并调用。

我个人的体会是，Codex 在技能发现和加载的“透明感”上做得更激进一些，你甚至可以直接在对话里问 AI“你有哪些可用技能”，它会列出当前环境加载的技能清单。这个能力用来排查问题特别有用：比如技能没生效，你一问就知道是根本没加载，还是加载了但没被触发。

如果你经常在 Claude 和 Codex 之间切换，建议保持两套技能目录都指向同一个文件夹，或者用同步脚本把技能目录推送到两边。我目前是维护一个主技能目录，用一个小脚本同步到各个 Agent 环境，方便统一管理。

3.3 手工安装第三方技能：正确姿势与避坑

从网上下载的第三方技能包，安装步骤其实很死板，但很多人第一步就搞错了。正确做法是：首先解压或克隆技能仓库，检查里面是否包含SKILL.md文件——如果连这个都没有，那它就不是一个标准技能包，装了也没用。

然后，把整个技能文件夹（注意是包含SKILL.md的那层目录，而不是仓库根目录）放到 Agent 对应的技能目录里。这里有个特别容易混淆的地方：很多技能仓库里还有README.md、LICENSE、示例代码等无关文件，你只需要拷贝包含技能定义的那部分即可，别一股脑全塞进去。

最后，重启会话测试。测试时不要直接提完整需求，而是先用一句话喊出技能目标，比如“使用代码审查技能分析 src 目录下代码”，看 AI 是否进入了对应的工作流。确认生效后再逐步提升任务复杂度。

一定要认准技能文件的格式和 Agent 平台的兼容性。有些技能是为 Claude 定制的，里面用到了 Claude 特有的 prompt 技巧，放到 Codex 下效果可能打折。反之亦然。选技能时不能只看标题炫不炫，要看它的设计对象。

4. 自己动手开发一个 skills：完整实战记录

4.1 选场景：什么样的任务最适合做成技能

不是所有任务都值得做成技能。我的判断标准很简单：这个任务是否具有“可重复的专业流程”。比如“帮我写一段 Python 代码”就不适合，太泛了；但“帮我给 API 接口写 OpenAPI 文档，并附上每个字段的说明样例”就非常适合，因为接口文档有固定的结构规范和检查项。

初次尝试时，建议从“你本人非常熟悉、且流程高度标准化”的任务入手。因为 skills 的核心是输出你的方法论，只有你自己最懂这件事的完整流程和常见坑点。我这个“代码审查”技能，就是从自己平时 review 代码的清单里梳理出来的，前后花了大概两小时，第一版就很能打。

我强烈不建议为了做技能而做技能，去网上找一个冷门流程文档翻译一下就当技能用。那样做出来的东西，AI 执行起来很木，因为你本身不了解里面的细节，遇到边界情况根本不知道该给 AI 补充什么。

4.2 编写 SKILL.md：一份能“指挥” AI 的说明书

有了场景之后，最核心的工作就是写SKILL.md。我写这份文件的原则是“像给刚入职的实习生写操作手册”，每一步都要明确、无歧义。

下面是我实际用的一个精简示例，基于“前端代码审查”技能：

--- name: frontend-code-review description: 对前端项目进行代码质量审查，检查组件设计、依赖使用、可访问性、性能隐患，并输出分级问题清单。 --- # 前端代码审查 ## 适用场景 - 用户要求对某个前端项目/目录进行代码审查 - 用户提交了一段 React/Vue 组件代码，要求给出改进建议 - 希望在上线前发现潜在问题 ## 不适用的场景 - 用户只要求解释代码含义，不涉及质量评估 - 用户要求自动修改代码（那是另一个技能） ## 执行流程 1. 先查看项目根目录下的 package.json，了解技术栈和脚本命令 2. 扫描目标目录下的所有 .tsx/.ts/.vue 文件，排除 .test. 文件 3. 按以下检查维度逐项审查： - 组件拆分：是否超过 200 行？是否需要抽离子组件 - 依赖引用：是否有未使用的 import？是否有引入整个库但只用了个别函数的情况 - 可访问性：img 是否有 alt？按钮是否有可读文本 - 性能：是否存在不必要的内联函数重复创建、大列表渲染 4. 生成审查报告，按 [严重/一般/建议] 分级输出

这个文件看起来简单，但它已经说清楚了“什么时候用、不用在哪儿、先做什么后做什么、重点查什么、输出什么”。AI 照着执行，查出来的问题往往比我口头提示它时更全面。

这里我特别想强调描述（description）字段的分量。它写在文档开头的 YAML 头里，是模型判断“何时触发技能”的主要依据。我第一次写的时候只写了“前端代码审查”，后来发现 AI 经常在读代码时不戴上这个技能。改成上面这种带场景细节的描述后，触发准确率提升非常明显。

4.3 配套资源与示例：把“经验”固化下来

只有SKILL.md的技能能干活，但离“好用”还有距离。真正让技能产生质变的，是配套资源。我通常会在技能文件夹里加一个examples目录，放入 2 至 3 份“优秀的输出样例”。这些样例对 AI 的约束作用比任何文字描述都强，相当于给模型一个“照着这个样子输出”的锚点。

举个例子，我的“接口文档生成”技能里放了两个示例文档：一个是简洁版、一个是详细版。AI 生成新文档时会自觉匹配其中一种风格，而不是自己发挥出一版格式奇怪的东西。这在调模型输出一致性时是最省力的手段。

另外，如果任务涉及重复的机械判断，强烈建议把判断逻辑写成一个脚本放到scripts目录里。比如审查技能里，我放了一个check-unused-deps.js，AI 可以调用它快速扫描未使用的依赖。这比让 AI 一行行读代码靠谱得多——人眼读一万行会累，AI 的注意力窗口也是有限的。

4.4 迭代与测试：像调参一样打磨技能

技能做出来不是一劳永逸的。我每次用技能，只要发现 AI 有理解偏差或产出质量不达标，就回去改SKILL.md，把歧义句改得更细，把遗漏的步骤补上。这种“用后即改”的迭代，一周下来技能就会变得极其顺手。

测试阶段我建议准备一个“最小化测试集”：3 至 5 个不同难度的任务，每次修改技能后全部跑一遍，看输出是否稳定。这其实跟做软件开发一个思路，要有回归测试意识。否则你今天改好了 A 场景，很可能把 B 场景改坏了，自己还没察觉。

5. skills 生态与下载平台：去哪里找现成的技能

5.1 官方与半官方渠道：最省心的选择

我先说渠道优先级，能走官方就走官方。Claude 的官方市场聚合了大量经过审核的技能包，质量和安全都有一定保障，适合新手。OpenAI 的 Codex 同样内置了技能浏览能力，可以直接在界面上查找启用。这些官方渠道的另一个好处是更新及时，会跟随模型能力的变化而优化技能写法。

除官方市场外，Anthropic 和 OpenAI 的官方 GitHub 仓库里也公开了不少示例技能。这些示例往往结构非常规范，非常适合新手当作“活教材”来学习——我自己就是通过读官方示例学会了SKILL.md的标准写法。如果你是技能开发者，逛这些仓库的收益比逛什么教程都大。

5.2 社区聚合平台：量大但需要筛选

社区生态是我目前找技能的主战场。GitHub 上搜 “awesome-skills” 或 “skills collection” 能翻到大量聚合仓库，里面按场景分类整理了成百上千个技能包。还有几个专门收录 AI Agent 技能的镜像站点和导航站，做得像当年的插件商店，浏览体验很好。

使用社区技能时，我强烈建议看看三个指标：

• 更新时间：超过半年没更新的技能，大概率跟不上当前模型能力，慎重；
• Star 数/下载量：不是绝对标准，但能反映其他用户的试用反馈；
• 作者后续维护记录：看作者是否在持续修问题，而不是一次性发布就消失。

我把常用的下载来源整理成了一个小表格，方便快速对照：

5.3 怎么判断一个技能值不值得装：我的筛选清单

网上技能这么多，看到标题感兴趣就装，很快你的技能目录就变成垃圾场了。我总结了一套筛选办法，分享给大家。

第一，看SKILL.md的前 30 行。如果前 30 行里没有写清楚触发条件、使用流程、输出规范之一，那么这个技能的沉淀程度基本不够，装了大概率不好使。真正高质量技能，一定会在开头就把“什么时候用、怎么用”说明白。

第二，看有没有示例输出。我自己发布技能时必然带examples，所以我也要求别人发布的技能带示例。没示例的技能，AI 输出全凭想象，质量波动很大。

第三，上手测试时先用“玩具数据”。不要一上来就把核心工作交给它。让 AI 用技能处理一个极小的简化任务，看它的行为是否符合预期。这个 5 分钟测试能省下后面一整天的返工时间。

6. 高频踩坑与排查技巧实录

6.1 技能装了半天不生效：先查这几个地方

这是新手遇到最多的问题，我把它放在第一位。技能不生效，八成不是技能本身的问题，而是环境问题。

优先排查路线如下：

• 技能文件是否放在了正确的目录层级？很多技能包解压后外层多套了一层父文件夹，导致 Agent 扫描不到；
• 是否重启了会话？前面说过，已开启的会话不会加载新技能，必须新开会话；
• 技能文件夹里是否有SKILL.md？没有这个文件，整个文件夹会被忽略；
• 是否有重名技能互相覆盖？两个同名技能放一起，系统可能只加载其中一个。

我还遇到过一种极具迷惑性的情况：技能部分生效。AI 能说出技能的名字，但执行流程不对。后来发现是我在调用时需求描述里给了太多额外信息，把技能流程覆盖了。这种情况下，你只要明确说一句“严格按 XX 技能的流程执行”，通常就能拉回来。

6.2 技能冲突与目录污染：如何管理一大堆技能

技能装多了，冲突问题就会浮现。最常见的冲突是“功能相似但方法论不一致”——比如装了三个写周报的技能，每个要求的输出格式都不一样，AI 触发时不知道选哪个或者混着用。

我的管理方案是分类子目录。把所有技能按“写作 / 编程 / 数据分析 / 研究检索 / 生活管理”分成几个大类，每类只保留 1 至 2 个最顺手的技能。这个做法有两个好处：一是减少 Agent 扫描时的选择混淆；二是降低冲突概率，同类技能只留一个最强方案。

另一个容易忽略的问题是“技能幻觉”：AI 描述自己有某个能力，其实那个技能文件早已被删除或失效。每次遇到这种情况，我会让 AI 列出当前可用的技能清单，跟磁盘上的实际文件对照一遍，清掉失效条目。

6.3 上下文窗口与性能：技能不是越多越好

一个不常被讨论但其实很关键的点：技能会消耗模型的上下文窗口。Agent 在会话开始时加载技能描述，加载得越多，留给实际对话内容的空间就越少。有段时间我装了 20 多个技能，结果发现 AI 聊天质量明显下降，回答变得泛泛而谈。排查后发现就是技能描述把上下文挤占了。

这背后的逻辑不复杂，但值得想透：模型处理上下文的能力是有限的，你塞给它的系统知识太多，它就没有足够的余地来处理你的具体问题。所以做减法很重要。一个会话场景下，让 AI 加载的技能控制在 5 个以内，质量是最稳的。其他技能让它按需动态加载就好。

6.4 安全问题：别什么技能都往自己环境里装

老实说，skills 的安全风险比大多数人意识到的要大。因为技能天然包含“指引 AI 执行一系列操作”的能力，恶意技能完全可以诱导模型去执行危险的命令、读取敏感文件、外传信息。

我的安全底线是三条：

• 不装来源不明的技能，尤其是不认识的小号发布的、只有 README 没有代码审阅记录的技能；
• 不装需要联网回传数据的技能，即使要用，我也会先读一遍它的脚本和输出逻辑；
• 对技能目录做定期审查，每个月清理一次不认识的、不再用的技能。

另外要特别提醒：前阵子安全圈分析了一些恶意技能包，表面上是“自动挖洞”“脱壳”之类的工具，背后却夹带了数据收集逻辑。这类所谓“黑客专用技能”一方面是合规风险高，另一方面安全质量毫无保障。碰都别碰。

最后分享一点个人体会

我做完整个 skills 体系改造后回头看，发现它给我最大的收益其实不是“效率提升”那部分，而是倒逼我把自己的工作方法论给整理了出来。写SKILL.md的过程，就是把你脑子里模糊的、跳步的、靠感觉的做事习惯，变成清晰、步骤化、可传授的经验。这件事本身的价值，甚至比让 AI 干活还要大。

所以如果你今天只打算做一件事，我建议不要把时间花在到处下载技能上，而是选一件你每天都在做的重复性工作，把它写成一个技能。哪怕写得粗糙，哪怕只给自己用，这个过程会让你以一种全新的视角审视自己的工作方式。

下一次再遇到什么“XX 又出了新技能合集”的热搜，你也不用焦虑了。技能这种东西，就像工具屋里的一把把螺丝刀，真正值钱的不是攒一大堆，而是你手里那几把最趁手、最懂自己活路的好家伙。