企业官网建设流程全解析

如果你也经历过这样的对话——让AI写一个登录表单，先解释校验规则，再补一句UI风格，最后还得加一条"错误提示文案要友好一点"；换到下一个项目，同样的内容又要从头讲一遍——那你大概率已经听说过"skills"这个词了。Claude Code、Cline、OpenCode甚至Codex都在往这套机制上靠，最近数学建模群和前端群里讨论得尤其热闹，从"skills推荐"到"技能库网址"再到"手动装GitHub上的skills"，热度明显不是一两天的趋势。

这篇文章是我这段时间把skills从零玩到能稳定产出的实操记录。干货集中在六个方向：skills到底算什么、怎么从GitHub手动安装、怎么写自己的SKILL.md、哪些技能包值得收藏、数学建模/前端/AI漫剧这些场景怎么选技能，以及最后怎么清理和维护技能库。老读者都知道我写东西不爱绕弯子，原理会讲但一定配合能直接抄的步骤和踩坑记录，这篇文章也一样。

1. skills不是插件也不是提示词：它是一份给AI的"岗位操作手册"

先说结论：skills最准确的定位是AI可自主读取的结构化操作手册。它不是一段每次要手动粘贴的提示词模板，也不是需要写代码的插件扩展，而是一整套以SKILL.md文件为核心、可以携带脚本和参考资料的能力包。AI在对话里根据你话中的触发点，自动匹配技能、读取里面的完整说明，然后按说明一步步执行。

为什么这套东西偏偏在最近火起来？核心原因是模型的上下文窗口和Agent能力都到位了。早几年你给AI塞一份5000字的操作手册，它读到后面早就忘了前面；现在上下文动不动几十万token，AI完全可以自己打开一个目录、读完说明、照着做事。于是"把老师傅的方法论交给AI按步骤执行"这件事，第一次变得技术可行且成本极低。

1.1 为什么是现在：上下文变长后，方法的传递方式变了

换个角度理解：以前我们跟AI协作的方式是"口头交代"，每次都要把领域知识、约束条件、输出格式从头说一遍。上下文窗口变大之后，交互方式变成了"让它自己去读资料"。skills正好卡在这个位置上——它不是存放在你的记忆里，而是存放在项目目录或全局配置里，AI发现当前任务匹配某条技能描述时，会主动去读SKILL.md，再结合当前对话完成任务。

这和"多轮对话里不停追加要求"有本质区别。追加要求是瞬时记忆，这一轮有效下一轮就丢；skills是长期记忆，写在文件里，下一次对话依然有效。我在团队里推广skills时用的比喻是：以前你是带实习生，每天重复交代流程；现在你给每个实习生发一本岗位手册，AI就是那个愿意每次开工前先把手册从头翻一遍的实习生。

1.2 和插件、MCP、提示词模板的区别

很多人把skills和插件、MCP、提示词模板混在一起聊，但它们解决的问题完全不同，我整理了一个对照表：

MCP和skills是最容易被搞混的两个。简单区分：MCP解决的是"AI能调用什么工具"，比如读数据库、操作浏览器；skills解决的是"AI在某个任务里应该用什么样的流程和标准来思考"，比如数学建模里拿到赛题先做什么、再做什么。两者可以配合：skill里完全可以写"建模前先用数据分析MCP工具读一遍数据统计特征"。

1.3 一个真实例子：从"每次强调"到"一句话触发"

我在前端项目里最常用的一条技能是表单生成。以前让Claude Code做一个注册页，要在提示词里写清楚：用户名规则、密码强度、手机号格式、校验时机、错误提示的文案风格，有时候还得补一句"不要用alert，用我们组件库里的Message"。写完这条功能，下一次做订单表单，以上内容原样再来一遍。

后来我把这些沉淀成一条名叫register-form-checker的skill，里面写好了字段校验的常见规则、组件库的错误提示用法、以及一个登录表单的完整示例。从此只需说一句"新增一个带手机号和密码的表单"，AI就会自动加载这条技能，按既定流程输出。省下来的不是那一两分钟，而是每次沟通质量的波动——提示词写详细点，输出质量就高；写粗略点，AI就自由发挥。技能把这个问题彻底消灭了。

2. 从GitHub手动安装skills：Claude Code与Cline的完整操作

很多人一听到"手动装GitHub上的skills"就觉得麻烦，其实流程比装插件还简单。因为skill本质上就是一个包含SKILL.md的文件夹，所谓安装，就是把这个文件夹放到工具认得到的目录里。下面以Claude Code为主，Cline和OpenCode思路一样但目录约定略有差异。

2.1 装之前先搞清楚三件事

第一，确认目标skill的目录结构。一个合格的skill仓库通常长这样：

some-skill/ ├── SKILL.md ├── reference/ # 参考资料、示例代码 └── scripts/ # 可选的辅助脚本

有的仓库根目录就是SKILL.md，有的是一个仓库里塞了好几个技能。安装前先搞清楚你要装的是整个仓库还是其中一个子目录。

第二，决定装到哪里。Claude Code有全局和项目级两个位置：全局技能放在~/.claude/skills/，所有项目都能用；项目级技能放在项目根目录的.claude/skills/，只对当前项目生效。需要团队共享的技能，走项目级；自己的通用提效技能，走全局。

第三，检查SKILL.md的YAML头是否完整。至少要包含name和description两项，description写得好不好直接决定技能能不能被正确触发。有些仓库的description写得非常宽泛，装完发现怎么叫都不触发，这种后面我会讲怎么改。

2.2 以Claude Code为例：完整安装步骤

手动安装的本质就是"把技能文件夹放到正确位置"，全程在终端执行，不涉及图形界面。我的流程是：

# 1. 创建全局技能目录（如果不存在） mkdir -p ~/.claude/skills # 2. 把仓库克隆到临时目录 git clone https://github.com/xxx/some-skill-repo.git /tmp/some-skill-repo # 3. 把目标技能文件夹复制到技能目录 cp -r /tmp/some-skill-repo/some-skill ~/.claude/skills/some-skill # 4. 验证安装结果 cat ~/.claude/skills/some-skill/SKILL.md

如果你只想装仓库里的某一个技能子目录，第三步是关键，只复制那个子目录而不是整个仓库。装完之后重启Claude Code，然后在对话里用接近skill描述的说法描述任务，正常情况下AI会自动加载。

项目级安装同理，只要把第三步的目标目录换成项目根目录下的.claude/skills/即可。我的习惯是：新技能先在项目级试用一周，稳定后再提升到全局目录，避免一个不成熟的技能污染所有项目。这种的做法后期维护成本最低。

2.3 Cline与OpenCode的相似思路

Cline和OpenCode近年也都跟进了SKILL.md格式。Cline的Skills功能需要在设置里先开启，技能目录通常放在项目的.cline/skills/下，或者通过设置面板指定全局技能文件夹。OpenCode的社区实现一般遵循~/.config/opencode/skills或项目.opencode/skills的约定。

我并不建议死记这些路径，理由很简单：这些工具都在快速迭代，目录约定说改就改。正确的做法是去翻官方文档里的"Skills"章节，以文档写明的路径为准。你只需要理解安装的本质是"把SKILL.md所在的文件夹放进工具的识别范围内"，路径变了看一眼文档就能跟上。

2.4 手动安装时最容易踩的四个坑

按我帮别人排查问题的经验，下面这几个坑占了九成：

第一个坑是复制层级出错。很多人clone下来之后直接执行cp -r repo ~/.claude/skills/，结果技能目录变成了~/.claude/skills/repo/SKILL.md，工具根本识别不到。正确做法是确保SKILL.md的上一级目录就是技能目录：~/.claude/skills/some-skill/SKILL.md。

第二个坑是frontmatter没写对。SKILL.md开头必须有---包裹的YAML，name不能带空格，description不能为空。我用过一个技能因为name里带了空格，工具始终识别为无效目录，去掉空格立刻正常。

第三个坑是description写得太泛。比如description写"处理文件"，那AI几乎在所有任务里都可能触发它，白白吃掉上下文。description要精确到场景和触发词，这部分我会在下一节展开讲。

第四个坑是权限问题。Windows用户尤其容易在复制文件夹时遇到只读属性，导致AI无法读取或修改技能内的脚本。复制完顺手执行一次chmod -R +r或者右键检查只读属性，能省掉不少排查时间。

3. 自己动手写一条skills：格式拆解、写作顺序与实践避坑

会装技能不算真本事，能写出让自己和团队效率翻倍的技能，才是这套东西的核心价值。别怕规范复杂，SKILL.md就是一份带固定头部的Markdown文档，半小时能学会。

3.1 第一步是写description，不是写步骤

我的顺序和大多数人相反：先写description，再写步骤，最后补示例。原因是description决定了你的技能什么时候被触发，step写再好，触发不了就全是白搭。

description不是功能简介，而是"触发条件说明书"。我用过一个失败案例，description写的是"帮助用户进行代码审查"，结果我让人家"看一下这段代码有没有问题"时，技能触发了；让人家"评估一下这个功能的风险"时也触发了；甚至有时候闲聊都会被它劫持。问题就出在触发条件太宽。

后来我改成这样："当用户要求进行代码审查、评审Pull Request、或检查合并请求中的并发安全/错误处理/SQL注入风险时使用。其他普通代码提问不要使用。"效果立刻改善。核心经验是：把会触发它的场景列进去，把不该触发的场景明确排除。

3.2 一个可以直接抄的SKILL.md模板

下面是我常用的模板，结构上保留最核心的四个部分：触发信息、背景、步骤、规则。

--- name: math-model-proposal description: 当用户给出数学建模赛题、需要拆分问题并建立初步模型框架时使用。适合国赛、华为杯等建模竞赛场景。若用户只是问某个模型的概念，不要使用本技能。 --- # 数学建模问题拆解与建模方案 ## 背景 本技能用于在拿到建模题目后，快速产出问题拆解、建模思路和求解计划的初稿。 ## 步骤 1. 通读题目，提取背景、数据、需要预测或决策的目标。 2. 输出问题拆解，每个子问题标注数据类型和难度。 3. 对每个子问题推荐候选模型，写明推荐理由和适用前提。 4. 检查数据是否满足模型假设，不满足的给出预处理建议。 5. 输出建模求解工作计划，包含里程碑和时间点。 ## 规则 - 每个模型必须写明至少一个适用的前提条件。 - 不编造数据，缺失数据用[缺]标注。 - 输出格式为Markdown，包含一个表格汇总模型清单。 ## 示例 输入: "预测某城市未来一周共享单车需求量" 输出: 问题拆解 → 时间序列/回归模型候选 → 数据粒度检查 → 工作计划

注意几个细节：步骤要可执行，每步都有明确输入输出；规则里写的是"硬约束"，相当于给AI划了红线；示例不需要很完整，够说明"输入→输出"的走向即可。

3.3 让技能从"能跑"到"好用"的三个细节

第一个细节是给步骤加验收标准。比如"输出问题拆解"这一步，可以补一句"每个拆解出的子问题必须包含数据类型、规模、与目标的关系三个信息"。验收标准让AI不再敷衍，让输出质量可控。我以前写的技能步骤只有一句话，AI执行起来千奇百怪，后来我学乖了：每步都要能自检。

第二个细节是把"判断条件"显式写出来。比如"数据量小于100条且特征维度低于10时，优先考虑统计模型而不是深度学习模型"这类条件，本质上是在帮AI把隐性的专家经验变成显性规则。模型不知道什么时候该用什么算法，你要在技能里替它把决策树画清楚（文字描述清楚，不是真正画图）。

第三个细节是擅用reference目录。SKILL.md正文不用写太长，把完整的案例、代码、规范文档丢进reference或scripts目录，在正文里指引AI"遇到X情况时去读reference/xx.md"。这样技能保持轻量，需要深度信息时又能调用完整资料。

3.4 我写废过三条技能，总结出的写作顺序

最开始我习惯一次性写一大份技能文档，写完发现逻辑混乱，不是步骤缺东西就是规则和示例对不上。后来调整成四步走：

1. 先列任务清单：把自己实际做这类任务时的动作按顺序写下来，不用管格式。
2. 再标出判断点：例如"如果数据量超过10万行，先做抽样"，这是技能里最值钱的部分。
3. 接着只写规则和红线：防止AI做出不可逆操作或产出格式混乱。
4. 最后才动手写步骤和示例：因为你已经知道每一步要什么输入和输出。

这样写出来的技能文档顺序自然，AI执行起来不会前后矛盾。我早期写废的大多都是倒过来：先写了漂亮的步骤，发现卡在判断条件和规则上，最后只能推倒重来。

4. 哪些skills值得装：官方示例、社区合集与筛选标准

现在GitHub上打着"AI skills"旗号的仓库非常多，从官方的演示技能到个人分享的领域技能应有尽有。但装得多不等于用得好，我在第6节会讲清理问题，这里先给出来源和筛选方法论。

4.1 值得收藏的几类来源

第一类是官方示例仓库。Anthropic在GitHub上有一个skills的官方示例集，里面涵盖PDF处理、文档生成、SVG设计等基础技能，非常适合用来理解SKILL.md的规范写法。这类仓库的价值不在"多好用"，而在"这是标准答案"，遇到格式疑问直接用它们对照。

第二类是社区合集型仓库。GitHub上搜索"awesome ai skills"或者"工具名+skills"，能翻到不少整理好的技能合集。比如社区里流传较广的superpowers技能包，把很多实用技能打包在一起，适合愿意花时间研究原理的进阶玩家。需要注意的是，合集型仓库里的技能质量参差不齐，我通常只在里面挑单条迁移到自己仓库，而不是整体引入。

第三类是具体工具的skills市场或插件面板。Claude Code、Cline等工具的市场面板上能按热度排序看技能，带下载量、更新时间和用户评价。相比GitHub，面板上的技能经过一轮筛选，踩坑概率低一些。

第四类是技术博客和实战分享里贴出的单条技能。很多博主会在文章末尾附上自己常用的SKILL.md全文，这类往往带着真实的场景理解，质量常常高于仓库里的万能模板。

4.2 筛选skill时的五个检查点

我下载任何技能前会过五道检查，全部过关才值得装：

• description是否足够具体？会不会和已有的技能冲突？
• 步骤是否带判断条件和验收标准？还是只有笼统的"分析数据""生成报告"？
• 是否依赖外部脚本或API？依赖项的维护成本你能否承受？
• 最近更新时间是什么时候？半年以上没更新的技能，大概率跟不上模型能力变化。
• 目录结构是否规范？SKILL.md是否在技能文件夹的根目录？

拿这五条去筛，能过滤掉至少一半的"搬运式技能"。社区里很多合集把几年前的提示词模板套个壳就叫skill，装进去用起来还不如自己重新写。

4.3 我目前的技能库配置组合

我自己的技能库保持在15条左右，按使用频率分成三层：

基础层：文件整理、Markdown规范检查、代码错误分析。这三条几乎每天都在用，比如"整理这个文件夹里的临时文件"会自动触发文件整理技能。

场景层：前端表单生成、API对接、数学建模论文结构器、AI漫剧分镜脚本。这一层对应我不同阶段的主要工作内容，做完一个项目会淘汰掉一批。

实验层：新发现值得试的技能，先装进来跑一周。实验层技能不放在全局目录，而是放在特定项目的.claude/skills/下，验证稳定后再提升。

强烈不建议一次性装几十条技能。模型是根据description来决定是否加载的，装太多只会让它的选择越来越随机，上下文也被无效尝试吃干净。

5. 按场景组合skills：数学建模、前端开发与AI漫剧

不同领域对skill的需求差异非常大。我挑了近期讨论热度最高的三个场景展开，分别是数学建模（竞赛）、前端开发和AI漫剧内容创作，每个场景都给出组合思路和推荐方向。

5.1 数学建模与竞赛场景：让整个流程都有章法

数学建模竞赛（包括国赛、华为杯这类赛事）特别适合用skills，因为参赛流程高度标准化：读题拆解、数据清洗、模型选择、求解验证、论文写作，每一步都可以沉淀成单独技能。

我在备赛项目里配过一条组合拳。第一条是"赛题拆解"，负责把题目转成问题清单，标注数据特征和约束条件；第二条是"数据预处理"，专门处理缺失值、异常值、归一化这些脏活；第三条是"模型推荐"，根据问题类型、数据规模给出候选模型列表并解释理由；最后一条是"建模论文结构器"，按标准格式生成论文章节骨架，省去排版初稿的时间。

用下来的体会是：建模赛场上真正耗时间的不是算法，而是把问题拆清楚和把结果写清楚。前面两条技能负责前者，最后一条负责后者。至于中间调包求解的部分，靠模型本身的能力就足够，不用刻意做成技能。

有人会问，Codex这类工具里的skills在建模场景能不能直接用？答案是能，但需要按比赛流程重写一遍适合赛题的技能。从GitHub下载的通用数学技能通常偏学术，直接套进竞赛场景会发现缺了"论文写作""结果可视化"这些比赛刚需模块。

5.2 前端开发场景：把重复沟通固化成技能

前端大概是skills受益最明显的领域，因为UI开发里的"重复感"极强。一个项目中要写十几个表单页面，模型每次都要重新理解校验规则、组件库风格、错误提示语法，而这些都是可以在技能里固定下来的。

我配的前端技能组合是：表单生成、API接口对接（包含错误处理约定）、组件样式规范化、可访问性检查。表单生成技能里，我会注明"电话号校验使用正则xx，错误提示统一用组件库的Message模式"；API对接技能里，会写明"接口错误码分类处理规则"。

比较反直觉的一点是：前端skills的价值不在于帮忙写代码，而在于统一代码之外的口径。团队里两名开发者用同一个技能生成表单，产出的代码风格一致，Code Review成本直线下降。如果只是自己一个人开发，技能的价值反而没那么大——你本来就知道自己要什么，但是团队协作时，技能就是团队规范的"可执行版本"。

5.3 AI漫剧与内容创作：稳定才是第一位的

AI漫剧这类内容创作场景，最大的痛点是角色一致性和分镜统一性。同一角色在第五集和第一集长得不一样，观众立刻出戏。skills在这里扮演的是"创意流水线的质检员"角色。

针对漫剧，我会把技能拆成角色设定卡生成、分镜脚本生成、场景描述规范三个技能。角色设定卡技能负责在每次生成角色图时，强制输出包含外貌特征的完整描述串，保证后续生成沿用同一套描述；分镜脚本技能负责把剧本切分成可生成的分镜表格，标注情感动作和景别；场景描述规范则统一了场景的环境词和视角词。

内容创作类技能的写作风格和编程类有明显区别。编程技能里的规则可以写"禁止修改xxx文件"，内容创作技能里的规则要写"必须保持XX角色的语气一致""不得在没有明确场景描述时生成空镜"。前者约束行为，后者约束风格。这类技能的description尤其要写清边界，否则你让AI想个分镜，它可能把整个漫剧的角色设定都给你吐出来。

5.4 组合策略：小技能拼流水线，而不是追求万能包

三个场景讲下来你会发现，我的思路始终是：把一条完整的生产流程拆成多个单点技能，用几条技能拼成流水线，而不是用一个万能包解决所有问题。

万能包的问题在于：它内部塞了大量判断逻辑，AI在加载时很难判断该按哪条路径执行，结果往往是谁的description更靠前谁就被执行，资源的浪费比效率提升更明显。相比之下，小技能各管一段，description边界清晰，AI可以在不同任务阶段加载不同技能，组合出来非常灵活。

我建议每个场景控制在四到六条技能。多了，加载判断会乱；少了，覆盖不全，总会回到手写提示词的老路上去。

6. 技能库的清理、升级与版本管理：避免越装越乱

最后聊一个很多人忽略的问题：技能库的维护。装技能一时爽，装完之后如果不管，技能库会越来越乱，最终变成一个新的负担。社区里关于"清理skills的最佳方法"一直有讨论，我自己也折腾过好几轮，下面是沉淀下来的流程。

6.1 出现这些迹象，就该清理了

最明显的信号是：同一类任务，AI开始触发错误的技能，或者一条技能明明没有匹配，AI却强行调用。这通常意味着多个技能的description存在重叠区域，模型判断不准了。

第二个信号是加载速度变慢。技能目录里文件太多，每次对话AI都要扫描一遍description列表，虽然扫描速度本身不慢，但模型在选择时花在校验上的token量是实打实的。

第三个信号是你发现自己手动补充提示词的频率越来越高。这说明现役技能已经偏离你的实际需求，或者任务流程变了，旧技能跟不上新流程。

6.2 一套可复用的清理流程

我的清理流程很简单，三个命令加一次Review：

# 列出所有已安装的技能 find ~/.claude/skills -maxdepth 2 -name SKILL.md | sort # 看每个技能的大小，找出异常膨胀的 du -sh ~/.claude/skills/*/ | sort -h # 把不用的技能移到归档目录（不是直接删除） mkdir -p ~/archive-skills mv ~/.claude/skills/unused-skill ~/archive-skills/

用"移到归档目录"而不是"删除"，是我踩过坑之后养成的习惯。有一次我把一条旧的数据清洗技能直接删了，半个月后新项目需要类似功能，想找回来已经来不及。归档目录会保留技能的完整历史，确认真的用不上后再批量清空也不迟。

每季度我会留出半小时做一次技能Review，对着技能清单问自己三个问题：最近一个月有没有触发过？如果没触发过，是场景没遇到还是description写得不到位？这个技能下次使用还需要调整什么？Review完再决定升级还是归档。

6.3 用Git管理整个技能库的进阶玩法

技能本质上就是文本文件，天然适合用Git管理。我会把所有的技能收进一个独立仓库，然后在工具的技能目录里用软链接指过去：

# 初始化技能仓库 mkdir ~/my-skills cd ~/my-skills git init # 在技能目录里建立软链接 ln -sfn ~/my-skills/frontend-form ~/.claude/skills/frontend-form

这样做的收益非常大。技能的每一次改动都有记录，改坏了可以直接回滚；换了新电脑，clone一下仓库再重新建软链接，十分钟恢复整套工作环境；团队协作时，直接把技能仓库作为共享库，所有人技能版本一致。

升级技能方面，我建议谨慎使用git pull直接覆盖。如果Skill来自第三方仓库，你先做过本地修改，pull之后可能会冲突。我的习惯是先把本地修改提交到一个私有分支，再合并上游更新，解决冲突时能清楚地看到哪些是自己改的内容。

6.4 社区清理思路和我的改良

之前看社区里有人分享过一套清理思路，核心主张是"先禁用、后删除、定期评审"。禁用的意思是把技能目录移出工具识别范围，但保留文件；定期评审是每月检查一次技能使用率。这套思路的优点是稳妥，缺点是比较被动，只清理了"从来不用的技能"，没解决"description互相打架"的问题。

我在这个基础上做了两点改良。第一点是动手改description而不是直接禁用。两个技能触发冲突时，先看是不是描述语句太宽泛，把边界写清楚往往能解决冲突，而不用整个技能下线。第二点是建立技能使用日志，每次AI实际加载了某条技能，就在对话记录里看得到。季度Review时不是靠回忆，而是翻日志统计，用数据决定保留还是归档。

这轮折腾下来，我的技能库从顶峰时期的40多条降到了现在稳定的15条左右，但效率反而提高了不少。与其说是清理技能的功劳，不如说是想清楚了一件事：技能的价值从来不在于数量，而在于它是否精确覆盖你反复遇到的场景。我现在换新电脑时，只需要clone自己的技能仓库再重建软链，以前那些"我好像装过这个功能但找不到"的尴尬一次都没再出现过。如果你也开始积累自己的技能库，我建议从今天起就用Git管理起来——这是唯一一个我从第一天开始做、至今没后悔过的决定。