企业官网建设流程全解析

1. skills到底是什么：从“一次对话”到“可复用能力”的跃迁

最近这半年，AI编程工具圈里“skills”这个词出现的频率高得吓人。前端开发skills、数学建模skills、AI漫画剧skills、superpower skills……GitHub上各种skills仓库刷屏，Claude Code、Codex、OpenCode这些工具也都在往这个方向发力。说实话，我第一次听说这个概念的时候也懵了一下：这不就是prompt吗？跟插件又有什么区别？直到自己真正用了一两个月，才明白这东西为什么能火。

你可以把skills理解成“给AI助手的岗位说明书+操作手册”。以前我们写prompt，是在对话里临时告诉AI“你要怎么怎么做”；而skills，是把一套完整的工作方法、规范、注意事项、示例都打包成一个文件，放到AI工具指定目录下。之后AI只要识别到当前任务属于某个skills的能力范围，就会自动加载这套方法论来执行。它跟普通prompt的本质区别在于三点：一是可复用，不用每次敲一遍；二是可分享，别人写好你拉下来就能用；三是可校验，AI会严格按照里面定义的步骤和规则去走，而不是靠上下文自由发挥。

这个模式之所以在Claude Code、Codex这一波工具里爆发，核心原因是它们不再满足于“帮人写代码”这个单一场景。数学建模要做数据分析和论文排版，前端要做组件调试和性能优化，AI漫剧要批量生成分镜脚本和角色设定——这些都不是一两句prompt能覆盖的，需要一套完整的工作流。Skills正好补上了这块：把零散经验固化成结构化文件，让AI在下一次遇到同类任务时直接照章办事。

我自己的体会是，真正用好skills的人，其实都在做两件事：一是筛选适合自己的现成skills，二是把脑子里那套“我平时怎么干活”的经验写成skill文件。前者解决效率问题，后者解决个性问题。这篇文章我就把这两块都说透，从安装、推荐到自研，全流程过一遍。

2. 热门的skills推荐：哪些技能值得装，哪些是智商税

GitHub上打着“skills”旗号的仓库越来越多，质量参差不齐。我刷了几个星期，装了删删了装，最后能稳定留下来的其实就那么几种。按场景分类说会比较清楚，这也是我推荐的筛选方式——先想清楚自己要干什么，再去找对应技能，而不是看到热门就装。

2.1 前端开发类

前端场景的skills是实用性最强的一批。典型的有组件生成、样式规范、性能分析、无障碍检查这几个方向。组件生成类技能的核心能力是：你给它一个设计稿描述或者一段业务需求，它能按项目里既定的组件库风格生成完整代码，包括Props定义、事件处理、样式文件，甚至自动补充Storybook示例。我之前试过一个Vue组件相关的skill，生成的代码风格跟团队代码规范保持了一致，缩进、命名、注释习惯都匹配得上，省掉的返工时间不是一星半点。

性能分析类的skill也值得重点看。它的做法通常是：先读你的打包配置和关键页面代码，然后按一套检查清单逐项排查，比如首屏体积、路由懒加载、图片格式、缓存策略等。最后输出一份带优先级的优化报告。这个比你在浏览器里一个个看Network面板直观得多。装这一类skill的时候要留意它的检查项是不是针对你当前的技术栈——同样是性能分析，React项目需要关心的东西和Vue项目不完全一样。

无障碍检查类的skill则更适合做组件库或公共产品的团队。它会把WCAG的标准转化成具体可执行的检查动作，对生成的代码逐条核对，比如按钮是否有可访问名称、颜色对比度是否达标、焦点管理是否正确。这类skill胜在标准化程度高，AI发挥空间小，输出稳定，属于装了不亏的类型。

2.2 数学建模与竞赛场景

华为杯、国赛这类数学建模比赛，目前是codex/Claude Code skills最活跃的领域之一。我看了不少参赛者分享的配置，高赞的skills基本集中在三个痛点：数据清洗、模型选型、论文排版。

数据清洗类skill会封装一整套处理流程：缺失值判断、异常值检测、分布偏态检查、编码方式建议，每一步都有明确的输出标准和下一步操作指引。它的价值和普通“帮我看一下数据”的prompt完全不同——skill里会内置“先做变量分布直方图再决定填充方式”“离群值不能随便删要看业务含义”这类实战规则，AI不会贸然给你一个没有依据的处理结果。

模型选型类的skill，通常内置了决策树式的提问逻辑。它会先问你样本量、特征维度、目标变量类型、可解释性要求，然后根据回答推荐候选模型，并给出每个模型的适用场景和潜在陷阱。对参赛队伍来说，这个skill相当于团队里坐了一位有经验的算法顾问，能有效避免上来就无脑堆XGBoost的问题。注意选这类skill的时候尽量挑那些明确写了模型适用边界和局限性说明的，说明作者确实有实战背景，不是拿文档敷衍。

论文排版技能则是被很多人低估的存在。它会按数学建模论文的常见结构（问题分析、模型假设、模型建立、求解、敏感性分析、优缺点）来组织内容，并且内置了公式规范化、图表编号、三线表制作等规则。直接用普通对话让AI排版论文，经常出现公式风格不统一、表格格式混乱的问题，换上skill之后稳定性明显提升。

2.3 AI漫剧与创意生产场景

AI漫剧这个方向比较新，但需求量大到超出想象。相关skills的核心功能是批量生成分镜脚本、角色一致性设定、场景描述和配音文稿。我见过比较靠谱的漫剧skill，会内置一套完整的叙事结构模板，从开场钩子到冲突升级再到反转收尾都有约束，不会让AI生成一堆平铺直叙的流水账。

角色一致性是这类skill的难点，好的技能会在文末维护一个角色信息表，包含外貌特征、性格标签、说话风格、禁忌事项，每次生成前都会重新加载这些信息。这么做的好处是，AI在不同分镜里对角色的描述能保持稳定，不会第一集是黑发第二集变成棕发。我自己测试下来，装了这类skill之后，角色设定部分的返工率至少降了一半。

另外补充一个容易被忽略的点：创意类skills非常讲究“就地取材”。如果你只在对话里丢一句“生成一个分镜”，AI产出的东西大概率千篇一律，因为缺乏具体的戏剧情境。好的漫剧skill会要求你先提供题材类型、核心冲突、篇幅目标这些输入参数，然后才展开工作。所以选这类skill时，重点看它的输入引导设计是否完善，而不是看它承诺的最终效果有多炫。

2.4 Skill管理类工具

除了具体场景的skills，还有一类“元工具”值得关注，最典型的就是superpower skills。它的定位不是某个具体功能，而是一套更底层的skill管理和使用框架，帮你对已有skills做分类、检索、组合调用。tibo在分享里提到过他对清理废弃skills的方法，核心思路是定期审查使用频率、检查description与实际能力的匹配度、对重叠功能的技能做合并。我实践下来，这确实是维护skill库最实用的做法——不要傻傻地积攒几十个技能，最后发现一半是重复的，另一半是当初装完就没用过的。

3. 从GitHub手动安装skills：Claude Code实操全流程

很多从热词点进来的人，搜的是“claude code怎么手动装github上的skills”，这一节我就专门把这个过程掰开揉碎讲清楚。这里的“手动”，指的是不用官方市场或自动脚本，直接从GitHub拉仓库然后自己放到正确位置。之所以要手动，一是因为很多优质skills根本没上官方渠道，只存在个人仓库里；二是手动装能让你确切知道自己装了什么，对后续维护心里有数。

3.1 先搞清楚skills文件放在哪

Claude Code的skills存储路径分两个层级：项目级和用户级。项目级路径是项目根目录下的.claude/skills/，只对当前项目生效，适合放跟业务强相关的技能，比如“某组件库开发规范”。用户级路径是你电脑的用户目录下的~/.claude/skills/，对所有项目全局生效，适合放通用的技能，比如“代码review”“git提交信息规范化”。

这里有个容易踩的坑：有人会把skill文件直接扔进项目根目录，或者放在.claude/下面但是没有skills/子目录，结果AI完全没反应。Claude Code对路径的判断很严格，识别不到skills/目录就直接忽略。所以第一步动作别嫌啰嗦：先确认目录名对不对，路径拼错了后面全白搭。

3.2 下载并解压到目标目录

从GitHub装skill的常规流程是先找到仓库页面，点Code按钮选择Download ZIP，下载后解压。解压出来的文件夹往往带了仓库名和分支名之类的后缀，比如my-skill-main，你需要把它改名成真正的skill名称，然后整个文件夹丢进.claude/skills/（或~/.claude/skills/）下面。

我见过有人直接把解压目录整个拷贝进去，结果里面除了skill的md文件还包含README、LICENSE、示例目录等杂物。严格来说不是不能用，Claude Code只会读取符合格式的md文件，其他文件不影响运行，但目录一乱就不好维护了。建议只保留核心文件，把说明文档、示例代码和skill本体分开存放。

3.3 目录命名与SKILL.md的关系

这里有一个很重要的细节：每个skill目录下必须有一个SKILL.md文件，这个文件就是skill的核心定义，相当于技能的主入口。你从GitHub下载的skill仓库，大概率已经包含这个文件。目录名要和SKILL.md的frontmatter里定义的name保持一致，否则可能出现加载异常。我自己就遇到过目录名是hello-skill-main，文件里name字段写的是hello-skill，结果AI加载时行为不稳定，改回同名后才恢复正常。

如果你拿到手的仓库不是标准结构——比如把SKILL.md直接放在仓库根目录而没有独立文件夹——你可以自己在skills目录下新建一个文件夹，把SKILL.md放进去。文件夹命名建议用小写字母加连字符，比如code-review、math-modeling，避免用空格或中文，减少不必要的兼容性问题。

3.4 验证安装是否成功

安装完成后怎么确认生效？最直接的方法是在对话里用带skill关键词的指令触发它。比如装了一个代码审查skill，你就让AI“按code-review的规范对当前代码做一次审查”，如果它回复的内容明显包含skill里定义的步骤和检查项，说明加载成功。如果AI一脸茫然，回复的只是一般性回答，那多半是路径错了或者frontmatter里的description写得有问题，导致AI没有把这个skill跟当前任务关联起来。

另一种验证方式是直接在对话里问AI“你现在加载了哪些skills”，有些版本的Claude Code会列出当前可用的技能清单。不过说实话，这个功能在不同版本里表现不稳定，有些版本只列项目级的，有些版本什么都不显示，所以最靠谱的还是实测触发。

4. 自己动手写一个skills：格式拆解与开发要点

装了一堆现成的skills，你迟早会动一个念头：自己写。不要觉得这事门槛高，实际上一个能用的skill可能只需要几段话。但要把skill写好，让AI真正按你的工作流输出高质量结果，还是要摸清里面的门道。

4.1 SKILL.md的基本结构

一个标准的SKILL.md有三块内容：YAML格式的frontmatter、正文说明、示例（可选）。

frontmatter里最关键的字段是name和description。name是这个技能的ID，加载时用；description的作用是给AI做意图匹配，它决定了AI在什么情况下会激活这个skill。description写得越精准，AI越不会乱触发。比如你写“用于生成React组件的代码”，AI可能在“写一个按钮组件”的场景就激活了；但如果你写“用于从设计稿描述生成符合项目组件库规范的React组件完整代码”，AI就只会在你明确给出描述性需求时才调用。

正文部分才是核心。建议按“角色定位 — 工作流程 — 输出规范 — 注意事项 — 禁用事项”的顺序组织。角色定位一句话说清楚这个skill的职责边界；工作流程是分步骤的指令，告诉AI先做什么后做什么；输出规范明确要求AI以什么格式交付；注意事项和禁用事项则是防止AI自由发挥出你不想要的结果。

4.2 把“你的经验”转成“AI能执行的规则”

很多人写不好skill，是因为总是写得太宏观，比如“分析数据时要严谨”。这也算规则，但AI执行起来跟没写一样——什么叫严谨？它不知道。好的写法是“数值型变量缺失率超过30%时，不得直接剔除，必须说明可能的偏倚风险并给出插补方案”。这才是AI愿意执行的规则。

我常用的一个技巧是“反面清单”。正面描述告诉AI该做什么，反面清单告诉AI不能做什么，两个结合起来才完整。比如你写一个前端代码生成skill，正面是“生成符合项目规范的业务组件”，反面就是“禁止引入未在package.json中声明的第三方依赖”“禁止生成内联样式代替样式文件”“禁止修改与需求无关的现有代码”。这些禁令能大大减少AI在边角料上的“自由发挥”。

4.3 迭代调试，像调prompt一样调skill

skill写完之后不可能一次就完美，至少跑个三五次才能稳定。我自己的调试方式是拿同一个任务分别用“裸prompt”和“带上skill”去跑，对比输出差异，看skill到底加了多少分。如果带skill和裸prompt输出差不多，说明skill里的规则大部分是废话，需要做减法；如果带skill的输出偏离预期，那要检查是不是某个流程步骤写得太严格，限制了AI的合理判断。

还有一个很实用的技巧：把失败的案例直接写进skill的禁用事项里。比如你发现AI老是在回复里附带“以下是优化建议”这类多余内容，就把“禁止在交付代码之外附带优化建议”写进去。每一次返工，都是给skill打补丁的机会。迭代个十几次之后，这个skill就真的变成你的“数字化分身”了。

4.4 版本管理与分发

等你写的skill被同事或者网友看上了，就涉及分发问题。规范做法是把skill作为一个独立目录推送到GitHub，目录里至少包含SKILL.md，推荐附带README和示例文件。README给人类看，SKILL.md给AI读，角色清晰。版本管理直接用git就行，每次改动提交一次，方便回溯。

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

用skills的时间长了，踩过的坑基本都能汇总成一张问题速查表。这里挑几个最高频的来说。

5.1 装了skill但AI没有按skill执行，怎么回事

这是最让人头大的问题。原因通常出在三个环节：路径不对、description不匹配、对话上下文干扰。

路径问题前面已经说了，检查是否在正确的skills目录下，目录名和frontmatter里的name是否一致。

description不匹配是更隐蔽的原因。AI是根据description来判断什么场景该激活什么skill的。如果你的description写得过于宽泛，比如“这是一个数据分析工具”，AI会在很多不相干的场景试图加载它，结果上下文被打乱，反而降低输出质量。反过来，description如果太窄，AI可能压根识别不出来。我的建议是针对具体任务类型写description，嵌入触发场景和关键词，不要写职业名称。

对话上下文干扰的意思是，你在一段很长的对话里中途换了新任务，AI可能还沉浸在之前的上下文状态里，没有正确切换到新的skill模式。解决方法是新开一个会话再试。这也是我日常使用中做得最多的操作——宁可多开几个会话，也不要在一个上下文里混着跑多个skill。

5.2 skill加载了但效果比裸prompt还差

这种情况也是有的。原因多半是skill里的规则过于僵化，把AI限定在了一套并不适用于当前任务的流程里。比如你装了一个“严格按五步走”的数据分析skill，但在一个只需要快速计算的任务里强制走五步，反而拖慢速度且输出冗余。

处理方法很简单：给skill加一个“模式开关”。在SKILL.md里写清楚“遇到简单查询类任务时，可以跳过步骤2-4，直接输出结果”。这样做的好处是保留skill的应用灵活性，同时不牺牲规范性。我现在写skill，固定会在末尾加一段“在不违背核心原则的前提下，允许AI根据任务复杂度自行调整执行步骤”，这句话能避免很多生硬问题。

5.3 多个skill之间的冲突怎么解决

当你的skill库大起来之后，不同的skill可能会对同一个任务给出不同指示。比如一个通用代码生成skill和项目专属组件生成skill同时加载，AI可能不知道该听谁的。我目前的实践经验是：项目级skill优先级高于用户级skill，Claude Code在路径设计上本来就体现了这个逻辑。所以如果你发现冲突，优先把业务相关的规则下沉到项目级skills里，把通用能力放在用户级，让项目级覆盖用户级。

另外一个排查思路是精简skill数量。tibo分享的清理方法论我实际跑了一遍，确实有效：把全量skills列个清单，标注最近30天你有没有真正用过，凡是没用的先禁用一个星期，看工作流有没有受影响，没有就删。这套流程做完，我的skill库从二十几个精简到十个左右，日常启动速度和响应准确率都提升了。

5.4 从哪找更多靠谱的skills

最后聊一下资源获取渠道。GitHub自然是最大来源，搜索关键词建议用“claude skills”“opencode skills”“codex skills”，或者直接搜具体场景，比如“math modeling skills”“frontend skills”。另外很多工具本身的官方配置仓库里也会附带一批经过验证的skills，比如一些知名的类型安全团队开源了内部使用的skill集，质量普遍比个人仓库高。下载时记得看一眼stars和近期commit记录，长期不维护的老仓库，规则的时效性很可能跟不上当前工具版本的迭代。

我个人还有一个“抄作业”路径：去社交平台上搜别人分享的skill配置文章，先看目录结构和SKILL.md写法，然后自己重写一版适配自己需求的。完全照搬别人的配置往往不合用，因为人家的description、禁用事项都是基于自身工作流写的，你硬套只会觉得别扭。借鉴思路、重写细节，才是最高效的上手方式。

6. 写在最后：skill库本质上是你工作经验的数字化沉淀

把skills玩了一个多月之后，我最大的感受是：这玩意儿的价值不在于装了多炫的技能，而在于它逼着你去复盘“我到底是怎么把一件工作做好的”。我以前觉得自己写代码靠的是直觉，真要把它写成给AI看的流程规则，才发现很多步骤其实是模糊的、跳跃的、甚至前后矛盾的。一遍遍打磨SKILL.md的过程，其实就是在把自己的隐性经验显性化。

所以如果你看完这篇文章只记住一件事，我希望是：不要为了用skills而用skills。“Skills”这个概念真正改变我的，是让我开始像设计产品一样设计AI的工作方式。先把流程想清楚，再让工具去执行，这样的习惯放到任何工具上都不会过时。后续我还会继续扩充自己的skill库，重点往团队协作和跨项目复用方向走，到时候有新心得再来分享。