企业官网建设流程全解析

最近在折腾AI编程助手的同学，应该没少听人提skills这个词。点开GitHub搜一下，跟skills相关的仓库成百上千：前端开发skills、数学建模skills、AI漫剧常用skills，甚至还有人专门整理了一套superpower skills合集。但大部分人在第一步就卡住了——找来一个skills仓库，不知道往哪里放，不知道怎么让Claude Code、Codex这些工具认出来，更别说自己动手写一个。

这篇文章把我自己从“装skills装到怀疑人生”到“能一口气写出三个能用skills”的全过程整理了一遍。不扯虚的，直接讲清楚三件事：skills到底是什么机制、怎么装、怎么写。顺便把之前搜罗到的、实测过确实好用的skills清单和踩坑记录一并放出来，给正要入坑的同学省点时间。

1. 先搞清楚skills是什么：AI助手的“技能包”到底解决了什么问题

1.1 从提示词到技能包：skills机制的演进

很多人第一次接触skills，第一反应是：这不就是一段提示词吗？功能上有点像，但底子完全是两码事。普通的提示词是你每次会话都塞给模型的一段“临时说明”，说完就忘，下次还得重新讲。而skills更像给代码仓库里放进了一套“可复用的能力模块”，模型在对话开始前就能感知到这些技能包的存在，并且知道自己应该用它们完成什么任务。

拿Claude Code来说，它的skills机制会在项目里建立一个.claude/skills目录，每个技能包对应一个子目录，目录里放一个SKILL.md文件，再加若干辅助脚本、模板、参考文档。模型启动时会预扫描这个目录，遇到相关任务就主动加载对应的技能定义。Codex这边也有类似的机制，包括一些社区工具干脆把skills做成了可以直接拉取的技能库。这个思路本质上就是把“一次性提示词”升级成“项目内置能力”，让AI从“你说一句它动一下”变成“看一眼项目就知道该按什么套路干活”。

这套设计的厉害之处在于，skills是跟项目走的。同一个技能包，放在不同项目里，模型会自动结合项目的上下文来使用。不像全局配置那样一刀切，也不像临时提示词那样每次都要重讲一遍。

1.2 skills到底解决了什么问题

先说结论：skills解决的是AI工具的“稳定输出”问题。你用Claude Code写了几天代码，最深的感受应该是：同一个问题，换个问法，结果差出十万八千里。这不是模型笨，而是缺少一个结构化的执行框架。

举个实际场景。你想让AI帮你写一份前端组件，如果只丢一句话“帮我写一个表格组件”，模型大概率会按自己训练数据里的“平均印象”来发挥，用到的技术栈、命名风格、目录组织方式可能跟你项目完全不合拍。但如果你装了一个“前端组件开发skills”，里面写了完整规范：组件放src/components下、用TypeScript、样式用CSS Modules、必须导出类型定义、单测覆盖核心交互，模型加载这套规则后会明显精准很多。

再比如数学建模场景。竞赛里时间紧、任务急，最怕AI给你东一榔头西一棒子。一个建模比赛专用skills如果提前定义好“数据清洗→EDA分析→特征工程→模型训练→论文图表输出”的完整流程，模型就会按这个流程往下走，省掉大量反复拉扯。

所以skills真正解决的问题有三个：一是把经验沉淀成规范，让AI有章可循；二是降低任务拆分成本，不用每次重新跟模型描述你想要的执行方式；三是让跨项目复用成为可能，团队里一份skills，所有人共享。

1.3 一个典型的SKILL.md长什么样

不亲眼看一下SKILL.md的结构，很难理解skills为什么能影响模型的行为。这里给一个最简化的例子，实际项目里会复杂很多：

--- name: frontend-component description: 按项目规范生成前端组件，包含类型定义、样式文件与基础单测。 --- # 前端组件生成规范 ## 使用场景 - 需要新增一个React/TypeScript组件时 - 需要为现有组件补充样式或测试时 ## 执行步骤 1. 确认组件用途与props接口，先写类型定义 2. 在 src/components/{ComponentName} 目录下创建组件文件 3. 样式文件使用 CSS Modules，类名遵循 BEM 风格 4. 用 Vitest 编写核心交互的基础用例 ## 完成后检查 - 组件是否有类型错误 - 样式是否覆盖主要状态 - 测试是否通过

你可以看到，这个文件本质上是用模型最容易理解的方式，把“什么时候用、按什么步骤做、做完怎么验收”讲清楚了。模型看到这个文件，相当于拿到了一份岗位说明书，自然比瞎猜你意图要靠谱得多。

2. 手动安装GitHub上的skills：一步步完整流程与避坑要点

2.1 找对仓库：怎么判断一个skills值得装

GitHub上搜skills，确实一搜一大把，但质量参差不齐。我装了几十个之后总结出来的筛选标准，基本就三条。

首要看SKILL.md是否规范。一个靠谱的skills仓库，每个技能包必须有自己的说明文件，最好还带name和description的frontmatter。只有一堆脚本没有说明的，模型根本不知道什么时候该用，装了也白装。其次看维护活跃度。最后更新时间超过半年的，基本可以跳过，AI工具迭代太快，旧定义很快失效。第三看项目文档里有没有 “installation” 或 “quick start” 一节，作者写清楚安装方式，说明他真的在真实环境里跑过。

另外推荐一个思路：先看热门集合型仓库，比如superpower skills、common skills这类被社区验证过的合集，再按需去逐个找细分技能。合集的好处是生态活跃、相互兼容，不容易出现依赖冲突。

2.2 Claude Code手动安装skills的3种方式

第一种：直接进项目目录，把整个skills文件夹拉进来。这也是最朴素、最不容易出错的方式。先在你项目根目录建好.claude/skills文件夹，然后把你想要的技能包目录整个复制进去。例如：

mkdir -p .claude/skills cp -r ~/Downloads/some-skill/ .claude/skills/

这种方式的好处是依赖关系全靠目录自包含，不会污染全局环境。坏处是每个项目都要手动复制一次。

第二种：用符号链接，把技能包软链到项目目录。适合你自己维护了一批常用技能，想同步更新多个项目。

ln -s ~/skills-collection/some-skill .claude/skills/some-skill

好处是改一处，多处生效。坏处是换机器、换环境时链接容易断，团队协作时别人clone你的项目会拿到一个失效的链接。

第三种：直接改全局配置目录。Claude Code支持在用户级别配置skills，具体路径不同平台有差异，常见的就是~/.claude/skills。放全局的好处是所有项目都能用，但副作用也很明显：项目一多，模型扫描的技能数量暴涨，反而容易出现“模型不知道选哪个技能”的尴尬。

我个人的建议：能放项目局部就放局部。skills这玩意儿跟依赖库一样，精确到项目级别才能发挥最大价值。

2.3 Codex等其他工具的安装差异

Codex的skills安装路径跟Claude Code不完全一样。很多开源skills仓库支持多种平台的安装脚本，但原理大同小异：把技能包放到指定目录，让模型启动时能扫到。个别工具还支持通过配置文件指定skills源路径，这样技能包可以放在项目内，也可以单独放一个目录统一管理。

社区比较活跃的还有opencode、TypeSafe AI的skills方案，它们的共同趋势是标准化：SKILL.md作为技能定义的事实标准已经逐渐普及，区别主要在扫描目录和加载方式上。所以学习成本并不高，只要搞懂一个工具的目录约定，其他工具迁移过去也就是改个路径的事。

我最想提醒的反而是：别为了追新工具而频繁迁移skills。你手里那几十个技能包，花时间重新整理一遍目录结构，真不如多花点时间写几个好用的新技能。

2.4 安装完成后的验证清单

装完skills最怕的就是“看着装上了，模型根本不鸟你”。我一般用下面这个清单快速验证：

• 目录结构是否正确，SKILL.md是否在技能包目录的根下
• frontmatter 里的 name 和 description 是否存在，且描述是否清楚
• 新开一个会话，再用与该技能相关的问题触发，看模型是否提到这个技能
• 主动问模型“你有哪些可用的skills”，看它能否正确列出来

如果模型列出来了，但用起来还是不带劲，大概率是SKILL.md写得不够细。这个后面讲怎么写的时候会展开。

3. 手把手写一个自己的skills：从目录结构到实测调优

3.1 目录结构与命名规范

写skills这事，动手比看教程管用。但动手之前，先把目录结构定下来。推荐的最小结构如下：

my-skill/ ├── SKILL.md ├── scripts/ │ └── run.sh ├── templates/ │ └── example.txt └── references/ └── docs.md

SKILL.md是主文件，描述整个技能何时用、怎么用。scripts放辅助脚本，templates放输出模板，references放补充资料。如果技能本身很简单，不涉及脚本和模板，只有SKILL.md也是完全可以的。但一旦技能复杂度上来，全部塞进SKILL.md会让文件变得很臃肿，模型读取效率下降。

命名上，技能目录名尽量用kebab-case（小写加短横线），比如code-review-helper而不是CodeReviewHelper。frontmatter里的name也保持一致。description要写清楚触发条件，别写“一个有用的技能”这种废话，要写“当用户需要检查代码变更时，提供按规范执行代码评审的流程”，这样模型才能准确匹配。

3.2 SKILL.md的写作要点：前置条件、执行步骤、校验规则

我写过十几个SKILL.md之后，发现最有效的写法是：先写“什么时候不要用这个技能”，再写“什么时候用”。你可能会奇怪，为什么先写不适用场景？因为模型对边界条件的理解往往比适用条件更重要。比如一个“数据分析”技能，如果不说明“只处理表格数据、不处理图片”，模型就可能拿着这个技能硬套所有问题。

执行步骤要尽量原子化，每步只做一件事。比如“先读取目录下所有csv文件格式，再统一列名风格，再做缺失值统计”，这比“清洗数据”这种概括性描述好一百倍。模型理解粒度越细，执行越稳定。

校验规则是很多人会漏掉的部分。写完步骤后，一定要加一个“完成标准”：比如“输出文件包含三列” “脚本返回0” “测试覆盖率不低于80%”。没有校验规则，模型做完就停，根本不检查自己做得对不对。

3.3 把skills“教”给模型的技巧

写完SKILL.md只是第一步，真正让模型形成肌肉记忆，还得靠补充示例。我在技能包里放一个examples/目录，每个技能至少配一个输入输出示例。示例不用多，一两个就够，但必须覆盖最常见的场景。你用自然语言跟AI描述一百遍，都不如给一个“这就是我想要的结果”的样例直接。

另一个技巧是让SKILL.md开头的description里包含关键词触发词。一个数学建模技能，description里就写“竞赛、建模、数据清洗、论文图表、baseline模型”这些关键词。别怕被说是堆砌关键词，对模型来说，这反而是一种无监督的分类标签，能显著提高技能匹配准确率。但注意关键词要真实反映功能，千万别写跟实际无关的词来凑数。

3.4 实测用例与迭代

新写的技能不能一次成型，我通常会用三个测试用例来验证。第一个是标准场景用例，就是按你预想的主要场景问一遍。第二个是边缘场景用例，故意少给一些信息，看看模型会不会主动找你要。第三个是恶意场景用例，故意给一个完全不相干的问题，看看技能会不会被错误触发。

跑完三个用例后，基本能发现SKILL.md里描述不清晰的地方。最常见的场景是：标准场景下模型表现很好，但边缘场景下模型直接跳过了你定义的步骤。这时候我会回看描述是不是写得太绝对，然后把边缘情况的处理方式补进去。迭代两三轮之后，技能基本就稳定了。

4. 常用skills分类与实战推荐：前端、建模、漫剧都能用

4.1 前端开发：必须装的那几个类型

前端是skills应用得最密集的领域。为什么？因为前端工程化本身就有一堆重复规范：组件目录组织、样式方案、状态管理、代码提交格式，这些都是高度流程化的事，最适合写成技能。

我前端项目里常驻几个skills：一个是“组件生成器”，严格按照项目技术栈输出组件代码，带好类型、样式、单测；一个是“项目脚手架”，能快速拉一个新页面并接好路由、状态、接口层；还有一个是“代码审查助手”，按团队规范review变更内容，特别擅长挑命名和逻辑一致性的毛病。

前端AI应用有个老问题：模型往往“太聪明”，会用各种奇怪的语法糖。技能包里写死技术栈约束，能明显压制这种自由发挥。比如“禁止在无必要情况下引入新npm包”这种规则写进SKILL.md，实测下来能省掉大量没用依赖的审查时间。

4.2 数学建模与数据分析：竞赛党可以省下大量重复工时

数学建模是skills另一个很值得玩的领域，尤其华为杯这类时间紧张的比赛。建模流程从数据清洗到论文成稿，中间大量工作是可以标准化的。我现在看到建模场景下最有价值的skills有三类：数据处理类、图表绘制类、论文排版类。

数据处理类技能可以定义好完整规范：缺失值怎么处理、异常值怎么检测、数值列和类别列怎么识别。图表绘制类技能则固定视觉风格，比如统一使用matplotlib或seaborn，颜色主题、标注格式全部写死，保证论文里图表风格一致。论文排版类技能更硬核，直接把LaTeX/Markdown模板放进去，模型生成的内容起点就是“半成品”，而非一片乱码。

竞赛场景还有一个隐形痛点：AI生成代码第一次往往跑不通。一个建模技能如果能内置“运行前检查清单”，比如所有路径相对化、依赖包安装完整、随机种子固定，能帮你少走大量弯路。

4.3 AI漫剧与创意生产：把工作流变成技能包

很多人以为skills只能用在代码场景，其实不是。AI漫剧、短视频脚本这类创意生产工作，同样能沉淀成技能包。你日常做漫剧，肯定有一套固定的流程：写脚本→生成分镜→逐帧出图→配音→剪辑前对时间轴。这套流程完全可以写成一个创意生产skills。

我见过做得不错的漫剧类skills，SKILL.md里定义了每张分镜要包含的“机位、景别、人物表情、背景描述”，这样AI生成的脚本就能直接喂给绘图工具，不用人为二次加工。还有人在技能里内置了分镜表模板，模型按表格逐行生成内容，结构极其工整。

这类技能最大的价值是稳定“风格”。你做AI漫剧最怕风格飘忽，今天这种画风明天那种画风。把画风描述、色彩倾向、角色一致性要求写进技能包，输出就能稳定在一个调子上。创意行业里“可复用的审美标准”，用skills来固化其实是个很妙的应用。

4.4 常用的skills源网站与整理清理方法

找skills除了直接在GitHub搜，还可以关注几个社区聚合站点。有些开源项目把常用技能打包成合集，比如superpower skills这类大合集，安装一个就能用上几十个技能，类型覆盖广泛。社区里也常有“awesome skills”风格的整理列表，里面按领域分门别类，适合按需翻找。

但装了太多skills之后会碰到另一个问题：目录越来越乱，模型扫描负担越来越大。这时候就要定期清理。社区开发者tibo分享过一个清理思路，我按照那个思路实践后觉得非常实用，大致是这几步：先用一个会话让AI列出所有已安装skills，统计哪些技能从未被触发过；接着按“最后使用时间”和“是否被项目引用”两个维度分类；确定要淘汰的技能直接删掉或移到archive目录；保留的则统一规范化命名和描述。我清理过一轮之后，明显感觉到模型响应速度更快了，误触发也少了。

5. 装完不生效？维护混乱？问题排查与整理实录

5.1 装完skills完全没反应，先别重装

第一类高频问题：技能包明明放进去了，模型就跟没看见一样。遇到这种情况，我的建议是按顺序排查：先确认目录路径，再看SKILL.md文件名大小写，最后检查frontmatter。

真实案例里，文件名大小写不统一是最常被忽略的坑。有些仓库的文件写的是skill.md，而工具只认SKILL.md，大小写不对，模型直接跳过。另外frontmatter的name字段有没有写错也很关键，有的AI工具有特定的技能声明格式，不写或写错都不会被索引。

还有一点容易被忽略：模型上下文长度有限，如果项目里技能包太多，或者某个SKILL.md写得特别长，模型可能因为上下文放不下而丢弃部分技能定义。这种情况的解法是精简SKILL.md，把大段内容挪到references目录里，只保留核心信息在主线文件里。

5.2 多个skills互相冲突，模型不知道选哪个

第二个高频问题：技能装多了，模型开始精神分裂。你的项目里有一个“数据分析”技能，又有一个“建模比赛全流程”技能，都声称覆盖数据清洗环节。模型遇到任务时可能随机选一个执行，输出风格就不稳定。

解决冲突的核心思路是“职责单一”。每个技能只负责一个专业场景，描述中明确圈定边界。如果两个技能确实有交叠，就在其中一个的适用场景里写上“若用户明确要求建模比赛流程，请优先使用另一技能”。这听起来有点笨，但实测对模型选型很有帮助。我更推荐的还是定期合并同类项，把功能相似的技能整合成一个更通用的技能包。

5.3 模型不按SKILL.md的步骤走，怎么办

第三类问题最恼火：技能加载成功了，模型也承认有这个技能，但执行时就是不走你写的流程。最常见的原因是步骤写得过于抽象，模型“理解”了但不知道怎么转化为具体操作。

比如你写“检查代码质量”，模型可能会觉得代码能跑就算质量合格。但如果你写“检查代码中是否存在console.log残留、错误边界是否覆盖、异步请求是否有超时处理”，它就知道你要的具体是什么了。所以遇到不按步骤走的情况，先别怪模型，回头看看你写的步骤是否足够具体可操作。

如果步骤已经很具体但模型还是坚持自己的做法，那就要考虑是不是其他技能或系统提示词里的某些内容影响力更大。我遇到过一次，项目里有另一个工具链配置跟我的技能定义打架，模型每次都在两者之间摇摆。排查了半天，最终把工具链配置里跟技能重复的约束去掉才解决。

5.4 版本更新带来的兼容性：GitHub仓库更新后我踩过的坑

最后一个提醒，skillsp包的更新兼容性问题。GitHub上很多开源skills会不定期更新，拉新版本回来之后旧目录没删干净，新旧两份同时存在，模型加载了重复定义，行为变得很诡异。

我的习惯是：每次更新技能前，先把旧技能目录彻底删掉，再重新复制新版本。别迷信“直接覆盖”会更干净，覆盖往往留下旧文件残骸。用软链方式管理的话，更新就更简单了，直接更新源目录内容就行，但要注意先停掉正在使用的会话，避免模型用加载中的旧定义做了一半。

还有个更隐蔽的坑是主题和大版本升级。有些skills明确写了“适用于Claude Code某个版本”，升了大版本后可能失效。装之前先看一下仓库说明里的兼容性表，别等用了半天发现模型完全不理会技能定义才回头查文档。

聊到这，我把这段时间积累的skills经验基本都倒出来了。这里分享一个我自己最常用的顺手做法：我会单独建一个名为 “daily-routine” 的技能包，把写代码前最常做的动作都放进去——比如优先读取项目README、检查当前分支、确认测试命令、梳理changelog。每天早上开新会话第一件事，就是让模型先加载这个技能，把项目状态过一遍。不用它解决什么高级问题，但能保证一上来就和项目同步，后面交互明显顺滑很多。这个技巧说起来简单，我自己用下来受益很大，推荐你试试。