企业官网建设流程全解析

上个月我把一套 GitHub 上的 skills 装进 Claude Code 之后，整个干活节奏完全变了。以前处理“批量改文件编码”“整理一份 Markdown 表格”“按指定格式生成周报”这种重复活儿，我还要反复写提示词描述需求，现在是 AI 自己判断该调哪把“工具”，把指令和脚本一打包，说干就干。这东西就是最近 AI 编程圈里最热的skills。

所谓 skills，你可以把它理解成“给 AI 用的插件包”。它不是传统 IDE 插件那种 UI 层面的东西，而是一组 markdown 指令加脚本文件，在 Claude Code、Codex、OpenCode 这类 agent 型编程工具里运行。装上之后，AI 在对话过程中会自动识别“这个任务能用哪个 skill”，然后读取里面的说明、执行里面的脚本，把活儿干得又快又稳定。

这篇文章我打算直接进入实战，把下面这几件事讲透：skills 的运行机制到底是什么、怎么手动安装 GitHub 上的 skills、各个场景下值得装的 skills 有哪些、如何从零开发一个自己的 skills，最后再整理一份我踩过的坑和排查方法。不管你是前端、算法工程师，还是搞数学建模、做 AI 漫剧的内容创作者，这套东西基本都能用得上。

1. 先搞清楚 skills 到底是什么，它凭什么比插件更香

1.1 一句话说清 skills 的运行机制

我先用大白话解释一下。传统插件的逻辑是“人触发，工具执行”；skills 的逻辑则是“AI 判断，AI 执行”。你把一个 skill 放进项目目录后，AI 在对话中读到任务，会先去查这个 skill 的描述，如果匹配，就把 skill 里的 SKILL.md 作为临时的系统指令读进来，然后按照里面的步骤，调用同目录下的脚本去完成任务。

举个例子。我装了一个“整理会议纪要”的 skill，它的 SKILL.md 里写了“提取发言者、分段总结、输出待办事项”，scripts 目录里放了一个处理录音转文字的脚本。下次我直接把录音文件拖进对话，跟 AI 说“帮我整理一下”，它就会自动读取 skill、执行脚本、输出格式化纪要。整个过程不需要我再描述“你要先转文字、再分段、再总结”这种步骤。

这个机制的核心价值在于：把人的经验固化成 AI 可以自动检索和调用的资产。你不需要每次对话重新解释业务规则，AI 也不用从零摸索怎么做一件事。

1.2 skills 和 MCP、子 agent 到底什么关系

很多朋友一上来就被这几个概念搞混了。我自己刚开始也绕了一阵子，后来总结成一张对比表就清楚了：

所以说白了，三者解决的不是同一个问题。skills 是“把事做对”的方法论，MCP 是“能拿到外部数据”的连接能力，子 agent 是“谁来拆解和调度”的组织能力。实际干活时它们经常混着用：先靠 skills 判断处理流程，遇到要查数据库、调 API，就让 MCP 出场，任务太复杂，就把子 agent 拆出去。

1.3 一个标准 skill 包的文件结构

不同工具之间的 skills 规范略有差异，但核心结构大同小异。拿典型的 Claude Code skills 来说，目录结构长这样：

.claude/skills/ └── meeting-minutes/ ├── SKILL.md └── scripts/ ├── transcribe.py └── format.py

其中SKILL.md是灵魂文件，头部有一段 YAML frontmatter，里面写 name 和 description，正文则是非常具体的操作指引。这里有个关键点：description 写得好不好，直接决定 AI 会不会在正确时机调用这个 skill。因为 agent 检索 skills 的时候，看的就是 description 和当前任务的匹配度。

2. 从 GitHub 手动安装 skills 的完整流程

2.1 先想清楚：装到全局还是项目里

安装 skills 的第一步不是急着下载，而是先确定装在哪一层。以 Claude Code 为例，常见位置有两个：

• 项目级：.claude/skills/——只对当前项目生效，适合装跟这个项目业务强相关的 skill。比如你在跑一个数学建模竞赛项目，就只在这个项目里放建模相关的 skills，不污染其他项目。
• 用户级：~/.claude/skills/——对所有项目生效，适合装通用型 skill，比如“代码审查”“提交信息生成”“日志分析”这类跟具体技术栈无关的。

我个人的建议是：通用型 skill 放全局，场景型 skill 放项目。这样既免去了每个项目重复安装，又不会出现“我在写前端项目时，AI 莫名其妙地去调用建模 skill”这种跨上下文干扰。

2.2 手动安装的标准三步

从 GitHub 手动装一个 skill，其实就是三步：下载、放置、验证。

第一步，下载仓库或文件夹。一个 GitHub 仓库可能包含多个 skill，也可能只包含一个。如果你只想拿其中某个 skill，用一些在线工具可以单独下载子目录，或者直接把整个仓库 clone 下来再复制对应目录。

第二步，放到正确的目录里。以项目级安装为例：

# 进入你的项目目录 cd ~/projects/my-awesome-project # 创建 skills 目录 mkdir -p .claude/skills # 把下载的 skill 文件夹复制进去 cp -r ~/Downloads/skills/meeting-minutes .claude/skills/

这里有个细节要注意：复制进去的应该是一个包含 SKILL.md 的文件夹，而不是把 SKILL.md 直接丢进 skills 根目录。很多新手第一次装，把文件结构搞平了，AI 根本识别不到。

第三步，验证安装是否成功。最简单的方式是在对话里直接问 AI：“你有哪些可用的 skills？”。如果安装成功，它会列出 skill 的名称和描述；如果你在项目里且装了项目级 skill，优先看它是否出现在回答里。也可以直接尝试触发一次相关任务，看 AI 是否按 skill 里的流程执行。

2.3 网页版入口和常用源网站

除了从 GitHub 仓库手动拷贝，现在很多生态也在做“可视化安装”的入口。比如一些工具自带的 skills 市场、网页版配置界面，你可以在网页上搜索 skill、一键添加到项目配置。这类入口对不熟悉命令行的人友好很多，本质上还是帮你把 2.2 那三步的操作包掉。

我平时找 skills 比较常用的几个渠道：

• GitHub 上的 awesome 合集仓库：搜awesome claude skills、awesome codex skills，能找到社区整理的技能清单，按场景分类得非常细。
• 特定作者的 skill 库：有些开发者会维护一整套自用 skills，直接公开在 GitHub 上，质量通常比零散的仓库更靠谱。
• 官方示例仓库：Claude Code 和 Codex 各自有官方 skills 示例，作为起步参考非常合适。
• 社区分享帖：一些开发者会在博客或者社交平台发“我常用的 10 个 skills”，含金量常常比大而全的合集更高，因为那是经过实战筛选的。

我的建议是，不要贪多。看到一个大合集就全部装进去，最后的结果一定是 AI 经常在多个 skill 之间犹豫、甚至调错。一次装三五个跟当前工作强相关的，跑顺了再逐步增加，这个节奏最稳。

3. 按场景推荐一套我实测好用的 skills

3.1 数学建模场景：华为杯、国赛最实用的一套

数学建模是这次热词里非常集中的一类。仔细想想不奇怪——建模比赛时间紧、任务重，数据处理、模型求解、论文排版每一样都耗时，而 skills 正好能把很多“机械但繁琐”的环节自动化。

我参加过一次华为杯备赛，当时给 Codex 和 Claude Code 各配了一套 skills，分工是这样的：

• 数据清洗 skill：自动读取题目给的 csv、excel 文件，做缺失值处理、异常值检测、列名整理，最后输出数据探索报告。这玩意儿一场比赛下来能省两三个小时。
• 模型选择 skill：根据“预测/分类/优化”的任务类型，推荐候选模型，并且生成对应的 Python 或 MATLAB 代码框架。
• 论文排版 skill：把 Markdown 草稿转成符合模板的 LaTeX，公式编号、交叉引用、三线表全部帮你处理。

用下来的感受是，最具性价比的是“数据清洗”。因为建模题目的数据往往是“半成品”，办赛方故意留了不少坑，手写数据清洗代码耗时且容易漏，而 skill 里记录的检查流程是固定的，AI 执行起来稳定很多。

3.2 前端开发：从代码生成到评审闭环

前端是我看到 skills 生态里最成熟的领域之一。原因是前端任务高度结构化：搭组件、写样式、做状态管理、查兼容性，每个环节都有相对固定的最佳实践。

我自己常备的几个前端相关 skills：

• 组件生成 skill：输入“需要一个表单组件，包含校验、loading、错误提示”，它会按项目既定风格生成完整组件代码，而不是泛泛地从网上抄一段。
• 代码审查 skill：对指定文件或 diff 做 review，按性能、可访问性、语义化、TypeScript 类型安全几个维度逐个检查，最后输出问题清单和修改建议。
• 兼容性检查 skill：扫描项目中的 CSS 和 JS API 使用情况，标注哪些语法在目标浏览器版本里可能出问题。

这里有一个心得：前端 skills 最好绑定你团队自己的代码规范。比如你公司要求组件统一用函数式写法、样式用 CSS Modules、事件命名带 handle 前缀，把这些约定写进 SKILL.md，AI 生成的代码就直接符合团队规范，评审时少吵很多架。

3.3 AI 漫剧与内容创作：分镜脚本和角色一致性

AI 漫剧是另一个被反复提及的场景。做漫剧的人常常面临两个问题：一是分镜脚本写得慢，二是角色形象在不同镜头里容易“漂移”。前者是纯耗时问题，后者是稳定输出问题，巧的是 skills 对这两类问题都很对症。

针对分镜脚本，装一个“漫剧分镜 skill”，SKILL.md 里可以定义分镜的固定颗粒度：场景编号、景别、运镜方式、人物状态、台词、画面描述，甚至每个镜头的参考比例。AI 根据剧本自动产出分镜表，后续再按镜头逐一出图。

针对角色一致性，这个 skill 更多是“提示词工程+参考图管理”的组合。在 SKILL.md 里写清楚角色设定的描述词怎么组织、参考图放哪个目录、怎么引用统一风格关键词，出图的偏差就会小很多。

这类 skills 本质上不是让 AI 凭空绘画，而是把人的创作流程标准化。只要你的流程是稳定可复制的，就可以写成 skill。这也是为什么我觉得 skills 不光是程序员该学的东西，任何以“重复输出标准内容”为核心的工作，都值得思考一下能不能 skill 化。

3.4 日常开发效率：从整理文件到写周报

除了大场景，一些不起眼的小 skill 反而使用频率最高。我常驻的几个通用型 skill 包括：

• git 提交信息生成：根据 diff 生成符合 Conventional Commits 规范的提交信息。
• Markdown 表格整理：把一段杂乱的数据整理成立即能用的 Markdown 表格。
• 日志分析：读取错误日志，归纳错误类型、统计频率、给出修复建议。
• 周报生成：把本周的 commit 记录和任务清单汇总成周报。

这些东西看起来很简单，但日积月累省下的时间非常可观。尤其“日志分析”这种技能，以前遇到线上报错，我得自己一条条日志翻，现在直接丢给 AI 让它按 skill 的规则去归类，定位问题快了很多。

4. 手把手写一个自己的 skills

4.1 SKILL.md 的结构和写作技巧

用一个现成的例子来说。假设我想写一个“整理 Markdown 表格”的 skill，SKILL.md 长这样：

--- name: format-markdown-table description: 当用户需要将杂乱的文本数据整理为 Markdown 表格时使用。适用于日志、CSV 片段、爬虫结果等场景。 --- # 整理 Markdown 表格 ## 操作步骤 1. 识别原始数据的分隔符（逗号、Tab、空格等）。 2. 判断每一列的含义，补充合理的列名。 3. 将数据逐行填充进 Markdown 表格，注意对齐。 4. 如果存在明显异常值，在旁边用括号标注。 ## 输出格式 - 使用标准 GFM 表格语法。 - 第一行为表头，第二行为分隔行。 - 内容超过 20 个中文字符时，保留原文，不做截断。 ## 注意事项 - 不要把数字改成文本格式。 - 不要自作主张地排序，保持原始顺序。

写 SKILL.md 有四个核心技巧：

1. description 一定要写“触发条件”。不要只写“整理表格”，要写“当用户需要将杂乱的文本数据整理为 Markdown 表格时使用”，让 AI 能准确匹配触发时机。
2. 步骤要拆细。AI 不是人，不会自动补足隐含步骤。你把步骤写得越明确，输出越稳定。
3. 给出输出格式的边界。告诉 AI 什么能做、什么不能做，比告诉它“要专业”有效得多。
4. 保持精简。SKILL.md 不是文档中心，塞太多内容会稀释重点，AI 读起来也慢。一般来说控制在 200 行以内最合适。

4.2 把脚本封装成可复用 skill

纯指令类的 skill 只能约束 AI 的思考流程，真正的“杀手锏”是让 skill 带上可执行脚本。这里我以一个“批量压缩图片”的场景为例，展示完整的封装思路。

首先，在 skill 目录下建一个compress.py，接收输入输出路径参数：

# scripts/compress.py import sys from PIL import Image input_path = sys.argv[1] output_path = sys.argv[2] quality = int(sys.argv[3]) if len(sys.argv) > 3 else 85 img = Image.open(input_path) img.save(output_path, optimize=True, quality=quality) print(f"compressed: {input_path} -> {output_path}")

然后在 SKILL.md 里显式说明脚本的调用方式：

当用户给出图片路径时： 1. 使用 `python scripts/compress.py <input> <output> 85` 压缩图片。 2. 压缩后检查输出文件大小，如果仍大于 500KB，自动用 quality=70 重试。 3. 将原图大小和压缩后大小反馈给用户。

这样做的价值在于：脚本负责确定性高的“脏活”，AI 负责判断和编排。既保证结果可复现，又保留了 AI 的灵活性。

脚本类 skill 有几点需要注意：

• 脚本尽量写成命令行工具的形式，从参数读取输入输出，不要写死路径。
• 做好错误处理，至少捕获KeyError、FileNotFoundError这类常见异常。
• 在 SKILL.md 里写明运行脚本需要的依赖（比如 Python 包），否则换个环境就失灵。

4.3 测试和迭代的注意事项

skill 写完之后，一定要测试，而且要测三种场景。

第一种是“直接触发”：你主动让 AI 执行这个 skill，确认基本流程能跑通。第二种是“间接触发”：你开着对话，用接近但略带变化的描述提需求，看 AI 是否能识别出来。第三种是“干扰触发”：故意在一个不太相关的对话里提到一点相关内容，看 AI 会不会过度调用。

我之前写过一个小 skill，description 里写了“当用户需要处理数据时使用”，结果测试发现，用户问“今天几点开会”它都要去调用一遍，明显是 description 写得太阳了。后来改成“当用户需要清洗/转换/聚合本地结构化的数据文件时使用”，才正常。

迭代的时候建议每次只改一个地方，改完立刻重测。因为 SKILL.md 里任何措辞变化都可能改变 AI 的调用行为，不一点点验证，你都不知道是哪个词导致它“发疯”。

5. 常见问题与排查技巧实录

5.1 装了半天，AI 就是不调用 skill

这是新手问得最多的一类问题。排查步骤我按优先级排列如下：

1. 确认目录位置正确。项目级 skill 必须在项目根目录下的.claude/skills/（或.codex/skills/），大小写都不能错。
2. 确认 SKILL.md 有有效 frontmatter。name 和 description 缺一不可，少了任何一个，某些工具就会直接跳过这个 skill。
3. 确认 description 与当前任务匹配。如果 AI 认为你正在做的事和 skill 描述的场景无关，它当然不会调用。你可以主动问一句“你有可用的 skills 吗”，看它列出的列表里有没有这个 skill，有就说明安装成功，只是触发条件没碰上。
4. 确认没有同名冲突。如果全局和项目里存在同名 skill，有些工具会以项目级为准，但另一些可能因为重复而忽略。解决办法是给 skill 起一个足够独特的名字。

5.2 多个 skills 之间互相打架

skills 装多了之后，会遇到一个很尴尬的情况：AI 可能把两个 skill 的指令混着执行，或者反复在两个 skill 之间犹豫，导致结果四不像。

我的解决办法是“最小化原则”：同一时间只保留一个场景下最核心的几个 skills。比如做前端项目时就只开前端相关的，建模比赛时才切到建模 skills。如果确实需要同时使用多个 skills，那就在 SKILL.md 的 description 里明确加上“本 skill 仅适用于 XXX，不适用于 YYY”，尽可能划清边界。

另外，给每个 skill 的 frontmatter 加一个version字段也很有用，后续更新时能快速确认当前用的是哪个版本，排查问题少走很多弯路。

5.3 清理没用的 skills 也是必修课

之前在社区里看到有开发者专门分享过一套清理方法论，核心思路不是“把不用的删掉”这么简单，而是做“分层治理”。

具体操作分三层：

• 废除层：长期不用、触发错误率高的 skill，直接删除。删之前看一眼它的使用频率，低于一周一次的可以考虑淘汰。
• 休眠层：暂时不用但未来可能需要的，移出 skills 目录，备份到一个单独文件夹里，比如~/skills-archive/，需要时再放回去。
• 活跃层：正在高频使用的 skill，保持精简和更新。

我按照这个思路整理过一次，把原来的 40 多个 skill 精简到 12 个，AI 的调用准确率提升了一大截。清理的意义不只是省空间，更是减少 AI 做“选择题”的负担。每多一个 skill，模型在判断调用时机时就要多考虑一个选项，噪音多了，准确率自然下降。

5.4 几个值得知道的小坑

最后补充几个我实际踩过的坑，这些细节文档里一般不写。

• 不要在 SKILL.md 里写绝对路径。你的机器路径换到别人机器上就是错的。要用相对路径，或者让 AI 从上下文推断。
• 脚本依赖要提前声明。如果 skill 依赖某个 Python 包，SKILL.md 里必须写清楚，否则 AI 执行时报 ModuleNotFoundError，它还不一定知道怎么装。
• 大文件不要塞进 skill 目录。skill 目录里如果放了动辄几十 MB 的参考文件，每次 AI 扫描 skills 都会变慢。大文件放进仓库或单独的资源目录，在 SKILL.md 里用链接引用即可。
• 升级工具版本后要重新验证 skills。Claude Code、Codex 这类工具更新频率很高，每次大版本升级，建议把最重要的三五个 skill 重新跑一遍测试用例，以免底层行为变化导致 skill 失效。

我在实际使用中最大的体会是：skills 这个东西，装十个不如精三个。它真正的价值不在于“集邮式”地收集多少技能包，而在于让你反复做的事情变得越来越快、越来越稳。一个项目的 skill 打磨得越细，你节省的时间就越可量化。如果你还没有用过，建议今天就挑一个简单的、重复性最高的任务，试着写成第一个 skill，跑通一次，后面就停不下来了。