企业官网建设流程全解析

AI编程圈子里的热度，几乎全被skills这个词承包了。无论是Claude Code、Codex还是OpenCode，大家都在讨论怎么给自己的AI助手装上一套可复用的“专业技能包”。我最早接触skills是在折腾Claude Code自动写前端页面的时候——同一套组件规范、同样的视觉风格，每次都要在提示词里重新交代一遍，累得不行。后来发现skills机制可以把这些固定流程打包成一个个独立文件夹，AI在合适的时候自动调用，效果比想象中稳定得多。这篇文章不聊抽象概念，我会从安装、编写、推荐到清理，把我实操中验证过的方法完整过一遍，适合所有想把AI助手用得更有深度的人。

1. Skills 到底是什么：先把它当成AI的“专业外挂”

1.1 一个skills包长什么样

先说个最直观的结论：skills本质上就是“给AI看的说明书+配套脚本的文件夹”。它不是一个宏大的框架，更不是什么需要重新训练的模型。你完全可以把它理解成一个标准的项目目录，只要按约定放好文件，AI就能在需要时读取，并按照里面的指示来完成特定任务。

以我目前主力使用的Claude Code为例，一个最普通的skills包长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── generate_report.py └── assets/ └── template.md

核心是那个SKILL.md。它用Markdown写成，开头有一段YAML格式的元信息，包括技能名称、功能描述、允许使用的工具等，后面则是具体的操作指引。AI在对话时读到这个文件，就会根据描述决定“现在该不该调用这个技能”。

这里的关键在于：skills不是让AI背规则，而是给AI提供一份“操作手册”。就像你给实习生一份带步骤的SOP，他照着做就能完成一项完整工作，而不是每次都要从头解释。

1.2 为什么superpower skills能爆火

很多人第一次听说skills，都是因为superpower skills这个开源项目。其实它的原理并不复杂，真正打动人的是“打包思维”。以前我们让AI干活，靠的是每次在对话里写一大段提示词；现在把这些提示词整理成结构化的文件，放进一个标准目录，AI就能在不同项目里反复调用。

我个人的体会是，superpower skills真正牛的地方，是把那些“人人都能用、但需要花时间总结”的通用工作流沉淀了下来。比如代码审查、文档撰写、复杂问题拆解、任务规划，这些技能在多个项目里都能复用，节省下来的时间非常可观。

而且这个项目带火了一个概念：skill也可以是“组合拳”。一个技能里面可以串联多个步骤，比如读取代码、分析边界条件、生成测试用例、执行测试、输出报告，整个过程被串成一条流水线。AI不再只是“回答一句话”，而是“完成一个项目环节”。

1.3 适用场景与使用边界

那是不是所有场景都适合用skills呢？并不是。我自己用下来的经验是，最适合skills的场景有三类：

• 重复性高、流程稳定的任务：比如前端项目的组件规范检查、数学建模比赛中的数据处理模板。
• 需要专业领域知识的内容：比如AI漫剧的分镜设计、角色一致性描述，这些知识很难靠临时对话说清楚。
• 跨项目复用的通用能力：比如代码评审、README生成、Git提交信息规范。

但如果是那种“一次性的、个性化极强”的任务，比如“帮我把这个文案改得更幽默”，特意写一个skill反而画蛇添足。判断标准很简单：这个任务我会不会重复做三次以上？如果会，才值得做成skills。

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

2.1 先搞清安装路径：项目级与用户级

从GitHub安装一个现成的skills，听起来挺简单，但第一步就经常有人搞错：到底放到哪个目录？

不同的AI工具约定不同，但大方向是一致的。以Claude Code为例，官方支持两种层级：

• 用户级全局目录：~/.claude/skills/，所有项目都能用，适合放通用类技能。
• 项目级本地目录：.claude/skills/，只在当前项目生效，适合放与这个项目强绑定的技能。

我的建议是：个人开发阶段先用项目级目录，因为改动方便、不会污染全局环境；一段技能彻底稳定之后，再移到全局目录。比如我在做一个React项目时，会专门写一个“组件规范检查”的skill放在项目里，项目做完发现其他项目也用得上，再复制到全局去。

2.2 clone、拷贝、软链：三种安装方式的取舍

从GitHub手动安装一个skills，具体有几种方法，我按实用程度排序。

方法一：git clone到临时目录再拷贝

git clone https://github.com/yourname/awesome-skill.git mkdir -p ~/.claude/skills cp -r awesome-skill/skill-name ~/.claude/skills/ rm -rf awesome-skill

这种方式的优点是干净，不会在本地留下多余的git仓库。缺点是如果原作者更新，你需要重新拉取再拷贝，升级比较麻烦。

方法二：直接把仓库克隆到位

git clone https://github.com/yourname/awesome-skill.git ~/.claude/skills/awesome-skill

这样后续更新直接用git pull就行。缺点是这个目录会保留.git信息，如果你用某些AI工具扫描技能目录时把它当成普通文件，偶尔会多出一些噪音。

方法三：软链接（我个人最推荐）

git clone https://github.com/yourname/awesome-skill.git ~/dev/skills/awesome-skill ln -s ~/dev/skills/awesome-skill ~/.claude/skills/awesome-skill

这样你开发skills时可以直接在原始仓库里改，改完立即生效，不需要反复拷贝。对频繁调试skill的人来说，这几乎是最高效的方式。我写自己的skills集时，全程都是用软链，改完文件不用重启AI环境，新对话里就能用上。

如果你用Codex或者OpenCode，安装路径可能会有一点差异，但思路完全一致：先找到对应工具的全局或项目级技能目录，然后把skill文件夹放进去。这一步是最核心的，路径找对了，后续就顺了。

2.3 装完怎么验证：让AI真正用上这个技能

很多人以为把文件夹放进去就算装好了，其实还没完。我见过不少新手装完后，发现AI完全没有反应，于是怀疑skills没用。

其实安装完成后要做的第一件事是“确认AI能看到它”。以Claude Code为例，你可以直接问AI：“当前项目里有哪些可用的skills？”让它列出目录内容。再用一个能触发该技能的任务去测试，比如装了一个前端代码审查的skill，就随便打开一个前端文件问“帮我按团队规范审查一下”。如果AI开始引用skill里的步骤，说明安装成功。

另外要注意的是，很多AI工具不会在每次对话里自动加载所有skill，而是根据任务描述去匹配。如果你装完发现AI“没反应”，先别急着怀疑安装问题，很可能是当前的query不够“触发”这个技能。后面我专门写一节排查技巧。

2.4 踩坑：目录名、权限、版本不同步

手动安装这件事，踩过的坑比想象中多。这里集中列一下：

• 目录名不能乱改：有些skill内部会有相对路径引用和自身目录相关的资源，比如assets/里的文件。你如果为了让名字好看，改掉了文件夹名，很可能导致资源加载失败。所以手动安装时尽量保留原始目录名。
• 不要漏掉隐藏文件：很多skill会包含.gitignore或者.env.example，拷贝时如果用了cp -r但没开通配符，隐藏文件可能丢。最简单的办法是直接进入目录后再拷贝。
• 检查执行权限：如果skill里带了scripts/*.sh，可能要执行chmod +x才能被调度。我遇到过一次shell脚本无法执行，查了半天才发现是权限位不对。

这些坑在官方文档里很少写，但一旦踩到会浪费不少时间。

3. 自己写Skills的正确姿势：从模板到落地

3.1 SKILL.md 的 frontmatter 怎么写

如果你想真正用上这项能力，光会装是不够的，一定要学会自己写。自己写最大的好处是完全贴合自己的工作流，不用去迁就别人的思路。我从一个小小的前端规范检查skill开始，到现在已经积攒了二十多个自己的skill，每次写完都有一种“给AI派了份固定工作”的踏实感。

先看最基础的部分：frontmatter。它决定了AI何时使用这个技能。

--- name: frontend-a11y-check description: 检查项目中的前端可访问性问题，包括图片缺少alt、按钮无aria-label、表单缺少label等。当你需要评估web页面或组件时使用。 allowed-tools: grep, read, list ---

name不需要花哨，机器可读即可。真正重要的是description，因为AI是靠它来判断“当前任务是否匹配这个技能”。你不能光写“可访问性检查”，要写清楚“在什么场景下用、具体覆盖哪些问题”。我建议在description里加入触发条件词，比如“当你需要评估web页面或组件时”，这样匹配概率会大幅提升。

allowed-tools是告诉AI执行这个技能时需要哪些工具，这能避免它在检查过程中随意使用危险操作。不过也不要限制太死，至少保留读取和搜索类工具。

3.2 正文body的书写原则：让AI能“看懂并执行”

frontmatter下面是正文。正文的写法直接决定技能质量。我总结出几个原则：

• 用步骤，不要用概念。不要写“检查代码的可维护性”，而要写“1. 打开目标文件。2. 定位所有函数声明。3. 检查是否存在超过50行的函数，若有则记录。4. 检查重复代码块，若有则标记具体行号。”
• 给出判断标准。比如“当图片标签没有alt属性时，视为错误”，这比“注意图片可访问性”有效得多。
• 提供输出模板。让AI按固定格式输出，比如用表格列出问题等级、文件位置、修改建议。这样你一看结果就知道下一步该做什么。

还有一个容易被忽略的点：允许AI在遇到边界情况时跳出skill。写一句“如果发现某种情况不在上述流程中，请根据常识处理并备注”，可以避免AI生硬地按脚本执行，显得很蠢。

3.3 结合scripts：把模块化脚本包进去

纯文本的skill只能指导AI做事，但如果想让AI真正执行某些重复性高的动作，还得靠配套脚本。比如我自己写过一个“生成项目目录树”的skill，里面就放了一个Python脚本，用来递归扫描目录并输出指定格式的树状图。

#!/usr/bin/env python3 import os, sys def print_tree(root, prefix="", ignore=[".git", "node_modules", "__pycache__"]): entries = sorted([e for e in os.listdir(root) if e not in ignore]) for i, entry in enumerate(entries): connector = "└── " if i == len(entries)-1 else "├── " path = os.path.join(root, entry) print(prefix + connector + entry) if os.path.isdir(path): print_tree(path, prefix + (" " if i == len(entries)-1 else "│ "), ignore) if __name__ == "__main__": print_tree(sys.argv[1] if len(sys.argv) > 1 else ".")

然后把脚本的调用方式写在SKILL.md里，AI就可以在需要时自己运行。这里有个关键点：脚本路径要写相对路径，最好基于SKILL.md所在目录来解析。因为很多AI工具执行脚本时，工作目录可能是项目根目录而不是skill目录，如果你用绝对路径，换个环境就废了。

3.4 测试与发布：先本地验证，再上传GitHub

写完skill后，我强烈建议按照下面这个流程走一遍：

1. 单文件测试：先用一个最小项目，把skill放在项目级目录里，手动触发一次，看输出是否符合预期。
2. 边界测试：故意给AI一个“不太像该用这个skill”的任务，看它会不会错误调用。如果错误调用频繁，就说明description写得太宽。
3. 换场景测试：把skill移到全局目录，换一个完全不同的项目再试一次，确保没有依赖隐藏路径。
4. 发布：确认稳定后，上传到GitHub。README里要写清安装方式，最好附带示例输出。

发布这件事很多人不重视，觉得“我自己用就行了”。但我的经验是，发布到GitHub不仅能让别人受益，还能倒逼你把描述和目录结构整理得更清晰。事实上我大部分skill的第一次重构，都是发生在准备发布的时候——写README时发现自己有些说明根本讲不清楚。

4. 常用Skills资源推荐：前端、数学建模、内容创作怎么选

4.1 前端开发skills：代码生成、评审、重构

前端是skills应用最热门的领域之一，因为前端项目的模式化程度很高，重复任务多。我在前端开发里最常用的几个skills方向是：

• 组件规范生成：根据团队约定生成React/Vue组件文件，自动带上样式、类型定义、基础测试。
• 代码评审：从性能、可访问性、语义化、依赖大小等维度进行评审，并给出修改建议。
• 样式系统治理：用于扫描CSS中的魔法数字、重复色值，并建议提取为设计变量。

选前端skills时，我建议优先选“描述清晰、自带脚本”的。有些skill只给一段泛泛的提示词，这样的技能包价值不高。真正好用的前端skill会告诉你它具体检查哪些规则，而不是说“请提升代码质量”。

4.2 数学建模skills（华为杯/国赛向）

其实不只是华为杯，各类数学建模比赛这两年都开始流行给Codex或Claude Code配数学建模skills。因为这些比赛时间紧、任务重，如果能用AI快速完成数据清洗、特征工程、结果可视化，甚至按论文模板生成LaTeX，就能节省大量时间。

我印象比较深的有几个方向：

• 数据预处理模板：自动识别缺失值、异常值，做分布分析，并生成数据探索报告。
• 建模思路库：根据不同题目的特征，推荐适合的模型。比如预测类问题给时间序列/回归方案，优化类问题给规划/启发式算法方案。
• 论文排版助手：导入比赛论文模板，按结构生成标题、摘要、章节，并插入图表引用。

这类skills在使用时要注意：比赛环境离线很多，不能依赖AI实时联网。所以我在给比赛准备skill时，会刻意把资料、模板全部放在skill目录里，让AI在本地就能完成大部分工作。

4.3 内容创作/AI漫剧skills：分镜、角色一致性、画面提示词

AI漫剧是最近很火的应用方向，很多人在做漫画改编、动态漫、短视频漫剧。这个领域的skills，核心是解决“角色一致”和“分镜稳定”两大痛点。

常见的AI漫剧skills包括：

• 角色设定管理：保存每个角色的外貌、服装、性格标签，在生成画面时复用，避免同一角色出现两张不同面孔。
• 分镜脚本生成：输入剧情文本，输出分镜编号、景别、运镜、画面说明和对应提示词。
• 画风统一：把指定画风的描述词内置，比如“厚涂、赛璐璐、水墨、3D渲染”，生成任何画面时都附加统一风格约束。

我自己试用过几个内容创作类skill，感觉最有用的是“角色一致性”这种。因为它不是靠一次生成完成的，而是需要在多轮对话中持续绑定角色描述，如果没有skill，你很难在一部长篇漫剧里保持所有画面里的角色形象一致。

4.4 社区资源站点与检索技巧

想找更多现成的skills，无非就是几个渠道，我习惯这么搜：

• GitHub搜索：直接搜claude skills、codex skills、awesome skills，注意看stars和最近更新日期。
• Awesome 列表：有一些专门的仓库收录了优秀skills，比如awesome-claude-skills之类，里面通常有分类和简介。
• 个人博客/推文：很多作者会写“我常用的skills推荐”，这种内容往往包含真实的适用范围和踩坑描述，比仓库README更有参考价值。

检索时有个小技巧：不要只看stars，要看issues。如果一个skill仓库的issues里有很多人反馈各种路径问题，说明它适用范围有限，但同时也说明它确实有人用，使用场景明确。最怕的是那种几百个stars但一年不更新的仓库，装上去大概率要踩坑。

5. Skills的日常管理与清理：像维护工具箱一样维护技能库

5.1 查看已装skills与目录体量

skills装多了之后，最直接的问题是“乱”。有时候你都不知道自己装过什么，更别提AI还要在这么多候选里找到最合适的。我最早一度装了几十个skill，结果AI经常调用错误的那个，气得我全部删掉重新来。

建议你先做个“技能盘点”。在终端里跑一下这些命令：

ls -la ~/.claude/skills/ du -sh ~/.claude/skills/* | sort -h

第一行看有哪些技能，第二行看每个技能占用多大空间。往往能发现一些体积异常大的“技能”——比如有人不小心把模型权重文件放进了assets目录，一个skill占几个GB，完全不合理。

5.2 更新、回滚与去重

技能更新是个常被忽略的问题。用GitHub仓库直接克隆的skill，更新还算简单，git pull就行。但你会遇到一个问题：原作者改了目录结构，而你本地已经基于旧版本做了一些自定义修改，一pull就冲突。

我现在的习惯是：尽量不直接改第三方skill，如果要改，就把修改记录写在skill目录里的 CHANGELOG.md 中。这样即使pull发生冲突，也能根据记录快速决定是保留本地版本还是用上游版本。

还有一个容易被忽视的点：去重。很多skills功能是重叠的。比如三个代码审查skill，一个查安全，一个查性能，一个查风格，但它们都会在“帮我看看代码”时被触发，AI可能选错。我的解决办法是统一维护一个“技能清单表”，记录每个技能的适用场景、冲突项、最后使用时间。当我发现某个skill连续一个月没被调用，就会考虑清理。

5.3 自制清单脚本：统计哪些skills最常用

为了判断哪些skill该清理，我写了一个简单的Python脚本，统计AI工具日志中各个skill被调用的次数。大致思路是：读取工具日志文件，按skill名称做计数，然后输出排序。

import re from collections import Counter from pathlib import Path logs = Path("~/.claude/").glob("*.log") name_counter = Counter() for log in logs: text = log.read_text(errors="ignore") for skill_name in re.findall(r"skill:([a-zA-Z0-9\-_]+)", text): name_counter[skill_name] += 1 for name, count in name_counter.most_common(): print(f"{name}\t{count}")

这个脚本并不复杂，关键思想是：不要凭感觉管理skills，要让数据说话。看完统计结果，我往往能发现几个“我以为很常用、其实一次没调过”的技能，可以直接删掉。

5.4 给新手的建议：少而精，别囤货

关于skills管理，我最想给新手的建议就四个字：少而精。

你不需要跟风装一堆似乎很酷的skills，更不应该看到“superpower skills”就整个仓库克隆下来。因为你很难理解每个子技能在什么场景下起作用，只会增加AI的匹配负担。我见过太多人装了100个skill，结果AI平均响应变慢，还老是调错。

正确的做法是：

1. 从一个你当前最痛、最频繁的任务开始，先手动写一个skill。
2. 把它用到顺手，逐步往里面补充细节。
3. 确定稳定后，再考虑从社区找2-3个同类型的佼佼者来对比参考。
4. 每装一个新skill，就删掉一个不再用的旧skill。

我自己现在保持的活跃技能数量大约在8-12个，这个体量既能覆盖大部分场景，又不会让AI“选择困难”。有时候，与其追求技能数量和功能覆盖面，不如专注把少数几个做深。

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

6.1 agent总是忽略我的skill，怎么办

这是我在各种社区里看到最多的问题。装好了skills，但AI就是不用。最常见的三个原因：

• description写得太模糊，AI在匹配时无法确定这个skill是否适用。解决方法是把触发场景写具体，比如“当你需要生成一个React组件时”，而不是“可以用来生成前端代码”。
• 技能目录层级不对。有些工具要求每个skill直接是skills目录下的一个子目录，不能再嵌套一层。你放成~/.claude/skills/xxx/my-skill/，AI可能只扫到了外层xxx，而外层没有SKILL.md文件，自然无法识别。
• 全局/项目级冲突。如果项目级目录里有一个同名skill，它可能会覆盖全局同名skill。遇到“明明更新了全局skill，却还是旧行为”的情况，先检查项目里有没有同名文件。

6.2 description描述不清，导致匹配失败

我调试过一个自己的“生成周报”skill，一开始description写的是：

生成周报。

结果AI在用户问“帮我总结一下这周的事情”时完全没有调动它。后来我改成：

生成项目周报。当用户要求总结本周工作进展、列出完成事项、规划下周安排时使用。输入是本周的工作记录列表。

改动之后，AI的匹配率立刻上来了。这说明description的核心不是“它是什么”，而是“在什么情况下使用它”。

6.3 相对路径、工具权限、模型版本问题

安装和编写之外，还有几个容易忽略的“技术坑”：

• 相对路径失效：SKILL.md里写的脚本路径，如果用的是./scripts/xxx.py，实际执行时可能因为当前工作目录是项目根目录而找不到文件。建议在skill里统一约定：所有相对路径都相对于SKILL.md所在目录，并在正文中显式写“先定位到当前技能目录”。
• allowed-tools 限制过严：如果你只在frontmatter里允许了read，但技能步骤里需要执行python脚本，AI会因为权限不足而拒绝执行。我通常会至少写上read, list, run, edit, grep。
• 模型版本低：有些老模型可能没有接受过skills相关训练，或者不支持复杂的技能调用。如果你发现某个skill在上一版本模型里好用、升级后变迟钝，可以先去工具的官方changelog里看看是不是有配置开关需要重新开启。

6.4 快速自查清单

最后，我把踩过坑之后总结出来的“安装-运行-调试”检查清单放在这里，每次遇到问题照着走一遍，基本能解决九成的问题：

• [ ] 技能目录是否直接位于skills根目录下，且包含SKILL.md？
• [ ] frontmatter中name是否与目录名一致？
• [ ] description是否包含足够的触发条件词？
• [ ] 技能引用的脚本、资源是否存在，且路径写法是基于SKILL.md的相对路径？
• [ ] 是否有同名skill存在于项目级目录，造成覆盖？
• [ ] 工具是否给AI授予了执行脚本的权限？
• [ ] 用最简单的场景测试，AI是否输出了预期结果？

我自己在实际操作中还有个习惯：每次调试skill时，都会在旁边打开技能目录，实时看AI的思维链和它读取了哪些文件。一旦发现它没读SKILL.md，马上就能定位到匹配问题。这类问题大部分不是功能缺陷，而是“人没写清楚、AI不知道该用”。技能技能，关键就在于你怎么把经验结构化地表达给AI。你写得越清楚，AI就越像你的资深同事。