企业官网建设流程全解析

我最早对"skills"这个词产生强烈印象，是从前端开发群里看到有人晒"superpower skills"开始。大家都在讨论怎么把 GitHub 上的 skills 装进 Claude Code，又说数学建模比赛用它写出了一等奖论文草稿；没过几天，AI 漫剧圈的人也开始整理分镜、角色一致性用的 skills 清单。这个热度不是虚的，它背后确实是 AI 编程助手用法的一个转折点——从"每次重新描述需求"变成了"把方法论直接封装给 Agent 用"。

那 skills 到底是什么？简单说，它是一种给 AI 助手准备的能力包：文件夹里放一份说明文档和若干参考文件，告诉模型在什么场景下、按什么步骤、输出什么格式来处理任务。效果相当于你给一个智商在线但缺乏经验的新人，塞了一本"老员工操作手册"。这篇文章我就围绕 skills 的安装、编写、场景案例和排错方法，把我自己实际操作中验证过的经验完整写出来，希望能帮刚接触这个概念的读者少走弯路。

1. 先把概念掰开：skills 到底在解决什么问题

1.1 从"工具调用"到"能力沉淀"的转变

我习惯把 AI 编程助手的使用分成三个阶段。第一阶段是"聊天问答"，你问一句它答一句，上下文一换就失忆；第二阶段是"工具调用"，接入终端、文件系统、搜索接口，它能替你执行命令，但每次都要说清楚"你要干什么、按什么规矩干"；第三阶段就是现在热门的能力包方式——把频繁用到的任务流程固化成一份技能描述，Agent 在需要时自动加载并照着执行。

skills 属于第三阶段。它不是一段可以执行的外部插件，而是一份"带格式的指令集"加若干参考资料。模型读到这份指令后，会按照里面写的背景、规则、步骤、示例去完成任务。我举一个生活化的例子：你让一个实习生去整理会议室，你告诉他"把桌子擦干净、白板写好下次议题、椅子归位"——这是一次性的口头指令。如果你把"会议结束后如何整理会议室"写成一份带检查清单的 SOP 手册，以后每次开完会都让他照着做，这就是 skills 的思路。

所以安装一个 skills 本质上是"给 AI 输入了一本岗位说明书"，它能确保输出质量稳定，而不是依靠模型的临场发挥。

1.2 skills 和 MCP、插件、Prompt 的区别

聊 skills 一定会碰到 MCP、插件这些词，很多人容易混。MCP（Model Context Protocol）解决的是"模型怎么连接外部数据和工具"的问题，它像是一个 USB 接口标准，让模型能读写文件、调数据库、操作浏览器。skills 解决的是"模型拿到工具之后，怎么按最优路径完成任务"的问题，它更像是使用说明书。一个负责通路，一个负责方法论。

插件的概念更偏传统 IDE 生态，往往带有完整 UI 和固定功能面板；skills 没有界面，它就是文本加文件。而普通 Prompt 是一次性的、当次会话有效，skills 是持久化的、按需触发的。你可以把 skills 理解成"结构化、可复用、可共享的超级 Prompt"。

这个区别很关键，因为决策路径完全不同：如果我要接一个第三方数据库，我会考虑 MCP 服务；如果我要让 AI 稳定输出比赛论文结构，我会选 skills。

1.3 superpower skills 为什么能火

社区里传播最广的"superpower skills"，本质是 Jesse Vincent 等人维护的一套高质量技能包合集。它的核心价值在于把资深开发者的经验拆成了可复用的步骤。举个例子，普通用户让 AI 写代码时只会说"实现一个登录页"，而 superpower 里技能会要求 AI 先确认需求边界、列出技术选型、输出文件结构，再逐文件实现，最后自查一遍错误处理。

这套流程和资深工程师做需求的方式高度一致。所以它一出现，很多人的观感都是"AI 突然像一个靠谱的同事了，而不是一个答题机器"。这也解释了为什么"skills 推荐""skills 网址"这类搜索会这么密集——大家不是找不到技能，而是想找那种能改变工作质量的技能。

2. 安装动手：从 GitHub 把 skills 搬进本地 Agent

2.1 手动安装前的准备工作

这里我不把命令写死在某一个工具上，因为 Claude Code、Codex、OpenCode 的目录结构类似，逻辑完全一致。你要做的准备工作很简单：第一，在本地找到一个适合放技能包的目录，比如~/.claude/skills；第二，确认你的 Agent 版本支持 skills 机制，一般最近半年的版本都支持；第三，准备一个 Git 环境，用来从 GitHub 拉取技能仓库。

以安装某个 GitHub 上的技能为例子，常规路径是这样：先克隆仓库到你喜欢的临时目录，然后查看里面的目录结构，一般情况下每个技能是一个独立文件夹，文件夹内部有SKILL.md文件。这个文件是技能的核心，你把它放进 Agent 能扫描到的 skills 目录即可。

注意：别把整个仓库一股脑扔进 skills 目录。很多仓库包含一堆示例、测试文件和文档，技能目录只需要保留"技能文件夹"和必要的参考文件，否则会白白消耗模型上下文，也容易造成技能加载混乱。

2.2 Claude Code 场景下的安装路径

如果你用的是 Claude Code，常见的技能目录是~/.claude/skills/，项目级技能也可以放到.claude/skills/下。手动安装一个 GitHub 技能包的步骤大致如下：

# 先把仓库克隆下来 git clone https://github.com/your-name/awesome-skills.git # 查看仓库里有哪些技能 ls awesome-skills/ # 进入技能包目录 cd awesome-skills/some-skill # 把技能文件夹复制到全局技能目录 cp -r some-skill ~/.claude/skills/

复制完成后，重启当前的 CLI 会话，新技能就会被加载。有些 Agent 还支持热加载，只要在对话里用触发词唤起即可。判断是否安装成功，最直接的方法是打开技能文件夹里的SKILL.md，看描述中声明的触发场景，然后在对话里用类似的需求测试一次。

2.3 Codex 和 OpenCode 的 skills 生态

Codex 类的工具现在也可以使用 skills，只是路径名称从.claude换成了.codex，例如~/.codex/skills/或者项目里的.codex/skills/。安装方式同样是复制文件夹，不一定需要额外的注册步骤。OpenCode 也出现了 skills 相关目录约定，社区里的做法是在项目根目录下创建.opencode/skills，里面同样放SKILL.md结构。

不管你用哪款工具，核心都是同一套规范：技能以目录为单位，目录里的SKILL.md是入口文件。所以我个人的建议是，不要执着于"某个工具怎么装"，而是理解这个通用结构。这样你就不会被某个具体工具的新版本绑定，无论生态怎么迁移，你都会安装。

2.4 常用的 skills 源网站和检索技巧

很多人问我"去哪里找质量高的 skills"。我的经验是三个渠道最靠谱：GitHub 上的 awesome 类合集仓库、知名开发者维护的技能包合集、以及各类 AI Agent 官方文档列出的社区示例。

在 GitHub 里检索可以用这些关键词组合："skills SKILL.md"、"awesome agent skills"、"claude skills"、"codex skills"。搜索结果里，优先看最近三个月有更新的仓库，说明维护者在持续跟进模型能力的变化；再看 README 里是否有清晰的使用说明和目录结构图。比起标题花哨的仓库，我更信任那些把SKILL.md示例直接贴出来的仓库，因为你可以一眼看出这个技能是不是真能落地。

还有一点经验：下载量不能代表一切，有些小众技能反而在特定领域非常精准。数学建模比赛里，往往是一个十个人的小仓库里的"灵敏度分析技能"比几千 star 的通用技能更有用。

3. 手把手开发：写一个自己的 skills

3.1 理解 SKILL.md 的标准结构

开发技能说难不难，但有一个格式前提必须先掌握。SKILL.md通常是 Markdown 文件，开头是 YAML 格式的元信息区，声明技能的name和description。这个description非常关键，因为 Agent 是靠它来判断"当前任务是否应该调用这个技能"的，写得太泛，模型该用的时候不用；写得太窄，不该用的时候乱用。

文件主体部分没有强制统一的模板，但我实践下来最有效的结构是五段式：背景说明、适用场景、操作步骤、输出格式、示例与禁忌。背景说明告诉模型为什么需要这套流程；适用场景写清楚触发信号；操作步骤尽量用编号列表，步骤粒度控制在"每一步能直接执行"的程度；输出格式写明最终交付长什么样；示例和禁忌负责减少模型的自由发挥空间。

注意：SKILL.md不是越长越好。技能说明文件过长会占用大量上下文窗口，反而拖慢响应速度。我的经验是单个技能文件控制在 150 到 400 行之间，配套的参考数据放在同目录的附件里，按需读取。

3.2 实操案例：写一个数学建模比赛技能

数学建模相关的 skills 在比赛季非常热，我以"数学建模论文写作技能"为例，演示一个简化但完整的技能包应该长什么样。创建目录math-modeling-writing，里面放一个SKILL.md：

--- name: math-modeling-writing description: 数学建模论文写作辅助技能。当用户需要完成数模论文的问题分析、模型建立、结果分析或排版优化时使用。 --- # 数学建模论文写作技能 ## 背景 数学建模论文有固定评审偏好，需要结构完整、假设清晰、求解过程可复现、结论有说服力。 ## 适用场景 - 用户手中有数学建模题目和求解结果，需要生成论文 - 用户已有论文草稿，需要按竞赛标准重写 - 用户需要针对某个图表进行描述性分析 ## 操作步骤 1. 先输出论文结构大纲，包括摘要、问题重述、模型假设、模型建立、模型求解、结果分析、模型评价。 2. 摘要部分单独强调：写清楚用了什么方法、得到什么结果，不超过 300 字。 3. 模型建立部分必须列出变量符号表。 4. 模型求解部分保留关键代码片段，并解释每一步的数学含义。 5. 结果分析部分用数据说话，必须有敏感性分析或误差分析。 ## 输出格式 论文正文按标准竞赛模板分段输出，专业术语统一，数学公式使用 LaTeX 书写。 ## 示例与禁忌 - 示例摘要见 references/abstract_example.md - 禁止出现口语化表达 - 禁止只给结论不给推导过程 - 禁止过度夸大模型精度

这个技能看起来文字不多，但它把评审老师关注的点全部固化了。比赛场上时间紧迫，你不需要每次重新嘱咐 AI"摘要要写清楚方法"，技能会自动生效。

3.3 开发技能时的调试和迭代技巧

写完一个技能，第一件事不是急着放进正式环境，而是先用一个测试目录，拿一个代表性任务跑三遍。我会重点看三件事：是否被正确触发、步骤是否被完整执行、输出是否稳定。

调试技巧里有一条很实用：在SKILL.md的描述里加入明确的触发信号词。比如"数学建模""数模论文""竞赛论文"这些词，比"写文档"更容易被模型捕获。另外，我习惯在主技能之外放一个"自检技能"，专门检查前面技能的输出质量。很多问题不是单技能没写好，而是缺少质量闭环。你可以在开发技能时，同时在技能目录下添加references/文件夹，把典型优秀输出放进去，模型会拿它作为风格基准。

迭代方面，我建议用 Git 管理每个技能的版本，每改一次就在技能说明的元信息里更新版本号。这样万一哪天修改后效果反而变差，你可以随时回滚到之前的稳定版。

3.4 一个技能包内部如何拆分子能力

我见到不少人想一步到位写个大而全的技能，反而效果不好。更合理的做法是"主技能加子技能"结构。比如数学建模这个大场景，可以拆成"问题理解技能""模型选择技能""论文写作技能""图表绘制技能"。每个技能负责一个小环节，主技能负责判断当前处于哪个环节，然后调用对应的子技能。

这种做法的好处是上下文更省、每个技能更精准、调试更容易。如果某个环节出了问题，你只需要修那一个子技能，不会牵连整个流程。这就像开发软件时拆模块，内聚低耦合，放 skills 世界里同样成立。

4. 场景实战：数学建模、AI 漫剧、前端开发的技能配置

4.1 数学建模比赛的高价值技能清单

结合比赛场景，我会建议按以下清单准备技能包：

比赛期间我最深的一个体会是：不要只装一个"写论文技能"，一定要把"模型结果复述技能"也准备好。很多队伍在论文里花大篇幅推导，却在结果分析部分草草带过，白白丢分。如果提前装好一个"结果分析技能"，AI 会自动检查每个图表是否都有对应文字说明，这会在紧张的比赛节奏下帮你守住基本盘。

4.2 AI 漫剧常用的 skills 配置思路

AI 漫剧这个场景最近也很热，核心痛点是角色一致性和分镜连贯性。普通的对话式 AI 很容易在第二次生成时改变角色外貌，这时候 skills 能做的不是直接修复模型，而是把"角色卡档案"和"分镜脚本规范"固定成技能，每次生成前强制模型参考。

一个实用的 AI 漫剧技能包应该包含三个子技能。第一个是"角色卡生成技能"，输入角色设定，输出包含外貌细节、性格关键词、禁忌元素的结构化描述文件；第二个是"分镜脚本技能"，把剧本拆成景别、镜头运动、台词、情绪标记组成的结构化表格；第三个是"画面描述技能"，将每个分镜转换成适合图像模型使用的长提示词，并自动追加角色卡中的一致性描述。

这三个技能组合使用，效果比我手动写提示词稳定得多。实际上"AI 漫剧常用 skills"里大家分享的，很多就是这类把漫画制作流程拆解成规范步骤的技能，让 AI 在脚本、分镜、画面三个环节各司其职。

4.3 前端开发场景的技能搭配

前端开发 skills 在热搜里也占了很大比例。实用的方向主要是代码审查、重构、可访问性自查。代码审查技能可以规定"每次审查代码时必须检查错误处理、内存泄漏、性能瓶颈、样式兼容性"四类问题，并给出修复建议。重构技能则可以定义"小步重构、每步跑测试"的流程，避免 AI 一次给你重写几百行代码。

可访问性自查技能是很多团队忽略的，但它能让页面真正满足不同人群的使用需求。技能内容可以是检查清单式的，比如图片必须有 alt 文本、键盘操作必须能到达所有交互元素、颜色对比度必须达标。你只需要在技能里把这些规则写清楚，AI 每次写完界面组件就会自己跑一遍清单，这种体验比自己反复提醒要省心得多。

4.4 怎么判断一个技能包值得长期保留

技能装多了以后，最大的成本不是硬盘空间，而是上下文资源和决策干扰。一个经常无法触发或者输出质量差的技能，会在任务过程中反复被模型"试用"，浪费大量 token。所以我筛选技能包有三个硬标准：第一，看description是否清晰，模糊的技能直接淘汰；第二，看操作步骤是否可验证，比如"输出 JSON 文件"比"优化内容"更容易确认结果；第三，看有没有示例参考，没有示例的技能，模型很容易跑偏。

还有一条判断标准要留意维护状态。AI 领域模型能力迭代非常快，半年前的技能可能需要更新才能适配新的模型。如果一个仓库已经一年多没更新，除非它是纯文档型技能，否则我一般会降级处理。

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

5.1 技能明明装了却不生效

这是我被问得最多的问题。装完技能，对话里让 AI 做对应任务，结果它完全无视技能，还是按默认方式回答。遇到这种情况，我按照下面的顺序排查：

第一，检查技能目录路径是否在 Agent 的加载范围内，不同工具加载范围不同，有的只看全局目录，有的只认项目目录，还有的会忽略隐藏目录。第二，检查SKILL.md的文件名是否大小写正确，很多 Agent 对文件名大小写敏感。第三，检查description里的触发词是否与你的实际提问相差太远，如果你说"帮我写个数模论文"而 description 里写的是"数学建模竞赛写作辅助"，匹配度就可能不够。第四，确认当前会话是否在技能安装之后启动的，没重启会话就测技能，大概率无效，因为部分工具不会实时扫描新目录。

一个重要经验：触发词的写法会影响匹配效果。在技能描述里同时写上同义短语很重要，比如"写论文""生成论文""论文草稿"都写进 description，而不是只写一个"论文写作"。

5.2 多个技能互相覆盖或频繁误触发

技能多了以后，最尴尬的情况是做一个普通需求，结果两三个技能同时"抢活"，模型甚至把技能 A 的规则套到了技能 B 的任务上。这通常是 description 写得过于宽泛导致的。例如一个技能描述是"处理所有文本任务"，那就等于没有边界，几乎每次都会被触发。解决方法是收敛范围，在 description 里明确写出"当用户需要 X 且不涉及 Y 时使用"这种条件性表述。

另一个办法是引入"门禁技能"。在主技能开头写一段判断逻辑，先确认用户需求是否真的属于本技能范围，如果不属于，直接输出"此任务不需要本技能介入"并结束调用。这样能有效避免技能之间互相干扰。

5.3 无用技能的清理套路

热搜里有一条"tibo 关于清理 skills 的方法推荐"，我看过类似的思路后自己也整理了一套可落地的清理流程。整体分三步：列出清单、标记使用频率、分类归档。

第一步，把你安装的所有技能文件夹列出来，并记录每个技能的触发场景。第二步，通过对话历史或日志统计每个技能在过去两周内被触发的次数，使用频率低不代表一定要删，但至少标记出来。第三步，把不常用的技能移出加载目录，放在一个skills_archive备份文件夹里，既不占用加载资源，又保留随时恢复的可能。

清理时还要注意一件事：有些技能之间存在依赖关系，删除主技能可能导致子技能无法正常被调用。我建议每次清理后，花几分钟跑一个小的冒烟测试，确认核心技能没受牵连。这个方法我已经用了几轮，效果很稳定，既不会误删有用技能，又能保持工作目录干净。

5.4 SKILL.md 里的常见低级错误

写技能时最常犯的低级错误有三个，出现频率非常高。第一个是 YAML 元信息区格式错误，比如description后面少了冒号、多了一个空格，导致整个文件解析失败。第二个是步骤说明含糊，写"分析数据"却不写用什么方法、输出什么格式，等于把问题又抛回给模型。第三个是技能文件里塞了太多绝对化表述，比如"永远不要"、"绝对必须"，这类表述很容易让模型在边界情况下的判断僵硬，最后输出不合逻辑的内容。

我的一个习惯是写完技能后，把它交给一个"技能测试专用会话"，问一句"这个技能文件哪里有问题"，让模型从第三人称视角帮忙检查。模型往往能找出我自己看不见的逻辑漏洞和格式错误，这个小技巧帮我节省了大量调试时间。

6. 从"装了一堆技能"到"真正用好技能"的个人体会

如果非得说一个我踩过最深的坑，可能就是最初盲目装了大量技能，导致 AI 每次回复前都要花很长时间扫描技能目录，还经常用错。后来我把技能数量压缩到日常高频的五六个，剩下全部归档，整个使用体验立刻顺畅了一个档次。我现在主要保留的是一套数学建模辅助技能、一个前端代码审查技能、一个写作风格规范技能和一个自检技能，数量不多，但每一项都在关键时刻能顶上。

还有一个体会是，skills 的真正威力不在单点功能，而在组合编排。单个技能只是操作手册，但如果你能把"需求理解技能"和"输出审查技能"连起来用，AI 就不只是一个会干活的帮手，更像是一条有质量闭环的流水线。我花了不少时间专门研究不同技能之间的衔接方式，比如让写作技能的输出格式明确适配自检技能的输入要求，这种细节设计带来的稳定提升，远比继续堆技能数量更值得。

最后分享一个小技巧，如果你准备深入玩技能，尽量为每个技能都配一段"失败回退指令"，比如在SKILL.md末尾写上"如果上述步骤无法完成，请明确告知用户缺少什么条件"。这看起来很不起眼，但它能避免最让人抓狂的情况：AI 没有按技能执行，却假装执行完了，给你交付一份格式完美但内容全错的结果。我经历过一次之后，就再也不敢省略这个兜底机制了。