企业官网建设流程全解析

最近我一直在折腾 AI Skills 这个新东西，越用越觉得这玩意儿是个被低估的宝藏。简单说，AI Skills 是让 Claude、Codex 这类 AI 编程代理快速掌握某个专业技能的“技能包”，它通常由一份说明文件和一个脚本目录组成，AI 在遇到对应任务时会自己把说明读进来、按步骤执行。前两个月我还在靠提示词硬堆“PDF 转 PPT”的需求，现在直接装一个技能，一句话就能让模型自己完成提取、排版和生成，效率完全不在一个量级。这篇就来整理一下我实际用过的 4 个 AI Skills 工具与网站，有官方仓库、有命令行工具、也有聚合发现站，照着操作基本都能上手。

1. 先搞清楚：AI Skills 到底是什么

1.1 从“会聊天”到“会干活”

很多人第一次听到 AI Skills 都会以为它和 GitHub 上那个教学用的 GitHub Skills 是一回事，其实完全不一样。这里的 Skills 是今年开始流行的一种 Agent 能力封装方式，最早出圈是 Anthropic 在 Claude 里推的 Agent Skills。它解决的核心问题是：模型怎么知道自己该按什么流程干活，以及干活时用什么现成脚本。

在没有 Skills 之前，我们想让 AI 处理一份 PDF，需要在提示词里写“第一步用 Python 读取 PDF，第二步提取文本，第三步按段落清洗，第四步总结”……这个流程每次都要写一遍，换个任务又要重新写。Skills 的做法是把这个流程固化成一套文件，放进指定目录，模型遇到“总结 PDF”“做 PPT”“整理 Excel”这类请求时，会先自动读取对应的 SKILL.md，然后按里面的步骤执行，甚至可以直接调用里面附带的脚本。

我自己的理解是：提示词像口头交代，说得再清楚也容易漏；Skills 像给员工发了一本 SOP 手册外加一个工具箱。它把“专业经验”拆成了可执行的段落，每一步该做什么、什么时候停、什么时候让用户确认，都写得清清楚楚。这也是为什么社区里出现了大量现成 Skills，从 PDF 处理到前端开发、论文写作、测试用例生成，几乎覆盖了高频工作流。

1.2 Skills 与 MCP、插件的分工

刚开始接触时，我很容易把 Skills 和 MCP（Model Context Protocol）搞混，后来用多了才理清楚。MCP 解决的是“连接”问题，让 AI 能访问外部数据源和工具，比如连上数据库、文件系统、浏览器；Skills 解决的是“怎么干活”的问题，它更像一套任务流程和内置脚本库。两者可以配合使用：MCP 负责把外部信息拿进来，Skills 负责告诉 AI 拿到之后怎么处理。

插件则是更传统的软件扩展概念，通常带有完整的界面和集成逻辑，适合在固定应用里使用。Skills 更轻，不需要独立安装包，本质就是 Markdown 加一段脚本。你可以把 SKILL.md 理解成“说明书”，把 scripts 目录理解成“现成的轮子”，模型是“照着说明书使用轮子的人”。

它们的取舍也很明显。插件能力最完整但最重，MCP 连接能力最强但不管流程，Skills 正好卡在中间：足够灵活，又能把专业经验沉淀下来。实际项目中我见过不少团队同时用 MCP 拿数据、用 Skills 做数据处理和报告生成，两套机制互不冲突，反而互补。

1.3 为什么值得专门去找工具和网站

一个很现实的原因是，官方内置能力永远赶不上社区需求。你可能只是想把发票 Excel 批量转成 PDF，或者想把几十个 Markdown 文件合并成一本电子书，这些需求模型不是不能做，而是每次都要重新理解格式、重新写代码，效果不稳定。社区里有人已经把这些场景做成了 Skills，你装上就有一整套成熟流程，出错概率小很多。

另一个原因是 AI 编程门槛正在快速下降。过去想让 Claude 或者 Codex 干活，得自己熟练掌握提示词工程；现在只要会安装一个 Skills，就能让模型拥有“前端开发”“数据分析”“论文格式整理”这类专项能力。这也是我写这篇文章的初衷，把我挖到的 4 个渠道分享出来，少走弯路。

2. 第一个必看：Anthropic 官方 Skills 仓库

2.1 官方仓库装了哪些能力

Anthropic 官方把一批第一方 Skills 放到了 GitHub 仓库里，这是我最早接触、也最推荐新手先看的资源。里面包含 PDF 处理、PPTX 生成、DOCX 文档操作、XLSX 表格处理、SVG 图形生成等能力，每个技能都是独立目录，里面有一个 SKILL.md 说明文件和若干辅助脚本。

我安装的第一个官方技能是 PDF 处理。当时手头有几十份合同要提取关键条款，原来靠手动复制粘贴花了三个小时，后来把 PDF Skill 装进 Claude Code，直接说“读取这几份 PDF，逐份提取合同金额、期限和违约责任”，模型自动调用技能里的脚本完成了批量提取，误差率比人工还低。从这个体验之后，我就开始关注官方仓库每次更新，因为它代表的是官方验证过的实现，适合打基础。

官方仓库最大的价值不是某一个脚本，而是一套质量标准。社区 Skills 质量参差不齐，但官方仓库里的每个技能都遵循同样的目录结构、说明格式和脚本规范，新手照着拆一个，基本就能学会怎么写自己的 Skills。这也是我为什么强烈建议先看它，而不是一开始就到处下载第三方 Skills。

2.2 安装姿势与路径选择

官方仓库的安装方式很简单，核心就是把对应技能目录放到 Claude Code 能读取的路径。Claude Code 默认会读取两个位置的 Skills：一个是用户级的~/.claude/skills，一个是项目级的.claude/skills。用户级的全局可用，项目级的只对当前项目生效，我建议优先用项目级，方便团队共享，也避免技能冲突。

下面是我常用的安装命令：

git clone https://github.com/anthropics/skills.git mkdir -p ~/.claude/skills cp -r skills/skills/pdf ~/.claude/skills/

如果仓库里目录结构有调整，先ls看清楚再复制。复制完成后重启 Claude Code，让它重新扫描技能目录。这里有一个很容易踩的坑：有些人把技能目录直接复制成了~/.claude/skills/skills/pdf这种多套一层目录的结构，结果模型死活识别不到。正确做法是让 Skill 的根目录直接包含 SKILL.md，也就是~/.claude/skills/pdf/SKILL.md，而不是~/.claude/skills/skills/pdf/SKILL.md。

如果你用的是团队项目，建议把.claude/skills提交到 Git 仓库。这样同事拉下代码后不需要额外安装，只要模型配置正确，打开就能用同一个技能版本，对于团队协作非常方便。

2.3 装上之后怎么验证

安装完不要急着开始正式工作，先做个快速验证。我通常会在 Claude Code 里输入/skills查看当前已加载的技能列表，确认目标技能出现在里面。接着准备一个测试文件，比如一个 5 页的小 PDF，让模型“用 PDF 技能读取并总结这个文件”，如果模型能够正确调用脚本并返回结果，说明技能已经生效。

如果技能没有出现，先看路径；如果路径没问题，再看 SKILL.md 里的name字段和文件名是否匹配。还有个容易被忽略的问题：技能目录名称不要带空格和特殊字符，比如“pdf skill”这种目录名，模型解析起来容易出问题，最好改成pdf-skill或pdf。验证通过后再正式投入业务，能省掉后面很多排查时间。

3. 第二个入口：Claude Code 自带技能管理

3.1 /skills 命令与官方文档

除了官方仓库，Claude Code 本身的技能管理入口也非常值得掌握。它允许你在交互界面里直接查看、加载和管理已安装的技能。我最初是在一个项目里装了三四个技能后，发现每次都要靠记忆确认装没装，后来才养成了先敲/skills看一眼的习惯。

这个命令的最大价值是让你快速定位问题：模型没有按预期调用技能时，先看它到底有没有被加载；如果被加载了但没触发，问题多半出在技能描述上；如果根本没加载，直接检查路径和目录结构。这种“从入口排查”的思路，比盲目改提示词高效得多。

官方文档里还有一套技能开发规范，包括 SKILL.md 的写法、目录结构要求、命名建议、脚本放哪里、怎么设置依赖等。很多第三方教程只教你安装，不教你规范，所以我建议你至少把官方文档翻一遍，不需要全记住，只要知道“规则长什么样”，以后调试时就有据可依。

3.2 从零开始管理本地技能

用好技能管理，先得把目录规划清楚。我目前本地的~/.claude/skills结构是这样的：

~/.claude/skills/ ├── pdf/ ├── excel/ ├── report/ └── slide/

每个目录都对应一种技能，目录名就是技能名。这里面有个原则：一个技能一个文件夹，SKILL.md 必须放在该文件夹根目录，脚本放在子目录scripts/或reference/里。官方推荐的实践是，如果技能包含大量参考资料，可以放在reference/，模型在需要时按需读取，避免占用太多上下文。

我还会用一个单独的 Git 仓库管理整个skills目录。每次装了新技能或改了脚本，就提交一次，出了问题可以git diff对比改动，也能回滚到之前可用的版本。这种习惯在技能数量变多以后特别重要，不然你根本不知道上次调坏的脚本是哪一个。

3.3 官方文档里容易忽略的细节

有几个细节我在实际使用中吃过亏，值得单独拎出来讲。

第一个是技能描述（description）的写法。很多官方示例里的描述都写得很具体，比如“当用户需要把 PDF 文档转换成结构化摘要时使用，适用于论文、合同、报告”。描述写得越具体，模型越容易判断该不该调用；写得太宽泛，比如“用于处理 PDF”，会导致模型在很多不合适的场景下也尝试调用，反而降低回答质量。

第二个是 SKILL.md 正文的结构。官方推荐先写“这个技能做什么、什么时候用”，再写执行步骤，最后写边界和注意事项。模型读取技能说明时是线性阅读的，开头就清楚说明适用条件，后面的步骤才不容易被理解偏。

第三个是依赖环境。有些技能脚本依赖 Python 库或 Node.js 包，安装前要看清脚本头部和说明里的依赖清单，别装完技能才发现环境里缺库，白白浪费排查时间。我现在的做法是每个技能都在目录里放一个requirements.txt或者说明文档，把依赖固定下来，避免版本漂移。

4. 第三个方向：Codex 的 Skills 生态

4.1 Codex Skills 与 Claude Skills 的差异

大多数人聊 AI Skills 都默认指 Claude，其实 OpenAI 的 Codex 生态里也在快速普及同类能力。Codex 本身就是很强的编程代理，Skills 机制让它从“能写代码”进化到“能按规范完成整套任务”。

两者最大的差异在定位上。Claude 的 Skills 更偏通用办公和内容处理，官方技能里 PDF、PPT、Excel 占大头；Codex 的 Skills 更偏代码仓库和工程流程，常见的是代码生成、测试、重构、文档维护。另一个差异是读取方式：Claude Code 通过/skills或自动扫描技能目录来加载，Codex 则会结合仓库根目录的AGENTS.md来判断该用哪些技能，和项目的结合更深。

这不代表两者只能选一个。我目前在同一个项目里就用 Claude Code 管文档类任务，用 Codex 管代码重构和测试任务，各用各的长处。它们遵循的技能格式都是“Markdown 说明 + 脚本”，大部分编写经验是通用的。

4.2 用 AGENTS.md 组织仓库级技能

Codex 的 Skills 使用方式通常是以仓库为单位。社区里比较流行的结构是在项目根目录维护AGENTS.md，然后在里面声明仓库有哪些技能、哪些场景该用哪个技能。比如：

project/ ├── AGENTS.md ├── src/ └── skills/ └── weekly-report/ ├── SKILL.md └── scripts/ └── build_report.py

skills/weekly-report/SKILL.md里照常写名、描述和执行步骤。Codex 在扫描仓库时会读取这些信息，遇到“生成周报”相关任务时，自动套用技能流程。这种做法的好处是技能跟着项目走，换人、换机器，只要仓库还在，技能配置就不会丢。

我实际测试过用 Codex Skill 做“自动化测试生成”，效果比单纯让它“写测试”稳定太多。因为技能里明确了测试框架、命名规则、覆盖率要求、禁止修改哪些文件，模型不用临场发挥，产出的代码风格非常统一。这种仓库级技能组织方式，对于中大型项目尤其有效。

4.3 社区里那些热门技能值得试

Codex Skills 的社区热度正在上涨，常见的包括前端开发技能、测试开发技能、论文写作技能、代码审查技能。前端类的技能通常会封装一套组件规范、样式规范和可用性检查逻辑；测试类的技能会定义测试目录、命名规则和 Mock 策略；论文写作类的技能则专注于引用格式、章节结构和语言风格。

不过要注意，Codex 的技能生态迭代非常快，今天的教程到下周可能就过时。我的经验是不要追求“最新最全”，而是先去看官方openai/codex仓库里有没有相关说明和示例，再结合社区里高 star 的仓库挑选。装之前先想清楚自己要解决什么具体问题，不要为了装技能而装技能，否则只会给模型增加干扰。

5. 第四个帮手：聚合站与精选清单

5.1 我常用的三个类型入口

除了官方渠道，第三方聚合站是“挖宝”的主要战场。这些站点专门收集整理各种 Skills，按类型、适用模型、热度排序，省得你自己在 GitHub 里一家一家翻。我平时主要用三类入口。

第一类是 AI 工具聚合目录站，比如 Glama 这类平台，里面有专门的 Skills 浏览页面，可以按 Claude、Codex 等模型筛选，也能看到社区评分和更新时间。第二类是 GitHub 上的 awesome 清单，搜索“awesome agent skills”“awesome claude skills”就能找到一堆精选列表，里面按官方、社区、工具链分类，质量普遍比随手搜出来的高。第三类是直接搜“SKILL.md”文件，在 GitHub 代码搜索里能找到大量真实仓库中的技能，看别人项目里怎么落地，比看包装过的教程更直观。

这三类入口各有用途：着急安装看聚合站，系统性学习看 awesome 清单，研究真实用法直接搜文件。我建议你把三类都收藏一个入口，因为这类站点存活时间不稳定，今天收藏的地址可能明天就改版了。

5.2 判断技能质量的标准

从聚合站下载技能，最怕的不是技能不好用，而是不知道它好不好用。我总结了一套快速判断标准，按重要程度排序：

• 说明文档是否清晰：SKILL.md 是否写清楚了适用场景、执行步骤、边界条件。
• 是否附带辅助脚本：纯靠模型临场发挥的技能稳定性有限，有脚本才算完整。
• 更新时间是否近期：超过半年没更新的技能，很可能已经不适合当前模型版本。
• 维护者是否可靠：官方账号、知名开发者或高星项目优先。
• 依赖是否可控：依赖包越少越好，最好只在脚本内部使用常用库。

这些条件不需要全部满足，但至少前三项要过关。我一般会先打开 SKILL.md 通读一遍，再扫一眼 scripts 目录里的脚本，确认没有可疑代码，才继续安装。这一步花不了几分钟，但能过滤掉大部分质量低下的技能。

5.3 搜索与下载的安全底线

这里必须说一条硬底线：任何 Skills 本质上都是代码加提示词，下载别人的技能，相当于让模型按别人写的指令执行。有些恶意技能会故意诱导模型输出危险操作、窃取环境变量、执行任意命令，或者请求模型关闭日志记录。官方技能和有信誉的开发者的技能风险可控，来路不明的技能风险完全不可控。

我在社区里见过一些号称“无限制”“一键破解”的技能包，这类东西不仅违反平台规则，多数还夹带了恶意 Payload。看到这种标题，直接跳过，不要好奇下载。安装第三方技能前，逐个打开脚本文件读一遍，看不懂的代码不装；要求设置敏感环境变量的技能，一律先隔离测试。使用 AI 编程代理时，也尽量不要用管理员权限运行，给模型能接触到的最小权限就够了。

6. 自己动手写一套可用 Skills

6.1 最小技能结构长什么样

看了那么多工具和网站，最终还是要落到自己写技能上。不用等成为专家再动手，一个最小可用的技能非常简单：一个目录、一个 SKILL.md、一个可选脚本目录。

--- name: pdf_summarizer description: 当用户需要总结 PDF 文件时使用本技能，适用于论文、合同和报告。 --- # PDF 摘要技能 当用户要求总结 PDF 时执行以下步骤： 1. 确认文件路径，并检查文件是否存在。 2. 运行脚本 `scripts/extract_text.py <pdf_path>` 提取文本。 3. 清洗文本，去掉页眉页脚和重复空行。 4. 按“文档主旨、核心要点、关键数据、待确认事项”四部分输出摘要。 ## 注意事项 - 扫描版 PDF 需要 OCR，不要强行总结。 - 超长文档分段提取，避免截断。

name是技能内部标识，description是模型决定是否调用的判断依据，这两项是必需的，YAML 格式也不能写错。正文部分可以写得口语化一些，因为它是给模型读的，重点是把执行步骤列清楚。

6.2 实例：写一个 PDF 摘要技能

为了方便你直接复制，我放一个完整的例子。首先准备脚本scripts/extract_text.py：

#!/usr/bin/env python3 import sys from pypdf import PdfReader def main(): path = sys.argv[1] reader = PdfReader(path) output = [] for i, page in enumerate(reader.pages, 1): text = page.extract_text() or "" output.append(f"\n--- Page {i} ---\n{text}") print("".join(output)) if __name__ == "__main__": main()

记得给脚本加执行权限：

chmod +x scripts/extract_text.py

然后把这个文件夹放到~/.claude/skills/pdf_summarizer/，重启 Claude Code，技能就生效了。我实测下来，pypdf 对电子版 PDF 的提取效果不错，扫描版会提示需要 OCR，这个技能在设计时就写清楚了边界，模型不会硬生成错误结果。

这里的一个经验是：脚本宁可功能简单，也不要把逻辑写得太复杂。AI 编程代理最擅长的是“调用工具、按步骤执行”，而不是“理解复杂代码的意图”。脚本输入输出越明确，调用成功率越高。

6.3 调试技能时最常见的四个坑

自己在写技能的过程中，我踩过不少坑，整理出来给你参考。

第一个坑是目录多套了一层。很多人把技能文件夹整个复制进 skills 目录，结果变成了“技能目录/技能目录/SKILL.md”，导致模型识别不到。检查方法很简单：看 SKILL.md 是不是正好位于“技能名文件夹”的根目录下。

第二个坑是 frontmatter 写错。name或description缺少、冒号后面没加空格、YAML 里用了不合规的特殊符号，都会让解析失败。这类问题最好在编辑器里用 YAML 校验插件先过一遍，不要在模型里反复试。

第三个坑是脚本没有执行权限或者缺少依赖。常见表现是模型调用了脚本，但报“Permission denied”或“ModuleNotFoundError”。提前在终端里手动执行一次脚本，确认能跑通，再让模型调用。第四个坑是技能描述与实际行为不匹配，也就是模型经常触发不了这个技能。解决办法是重新写 description，把触发场景和关键词写明确，越具体越好，不要贪多把无关场景全塞进去。

最后再分享一个经验

我现在给自己定了几条规矩：技能数量控制在五个以内，先精后多；每次安装第三方技能前，先读 SKILL.md 和 scripts 目录，确认它只干它声称的那件事；官方仓库每周更新一次，保持技能版本同步。AI Skills 最吸引我的地方，是把很多“老师傅知道该怎么做”的经验，变成了可以被模型反复调用和传承的规范流程。你在实际操作中如果遇到技能不生效、调用不准的情况，不要急着删掉重装，先回到技能描述和目录结构上排查，八成问题都在那里。