企业官网建设流程全解析

如果你最近在 Claude Code、Codex、OpenCode 这类 AI 编码代理上花的时间足够多，那大概率绕不开一个词：skills。从社区里疯传的 superpower skills，到数学建模选手为华为杯自制的建模套件，再到前端同学每天在用的组件开发规范，背后都是同一套机制——把一个专业领域的做法沉淀成 agent 能自动读取、自动执行的能力包。

第一次接触的人可以把 skills 理解为“给 AI 写的一本岗位手册”。手册里不只有口号，还有流程、有模板、有检查清单，甚至带脚本。AI 拿到手册后，遇到对应场景就知道按什么步骤干活，而不是每次从零乱猜。这篇文章不做概念科普，我把这阵子在 GitHub 上手动装 skills、自己写 skills，以及在数学建模竞赛、前端项目、AI 漫剧创作里实际用 skills 的经验，按实操顺序整理出来。新手可以照着一路搭下来，老手可以直接跳到第 4 节看场景选型，再翻第 5 节的清理方法论。

1. Skills 到底是什么——从“会写代码”到“会办事”

1.1 Skills 的身世：提示词工程演化的下一站

很多人的 AI 编码之路是从写提示词开始的。最早的玩法是把项目规范写进项目根目录的 CLAUDE.md、AGENTS.md 这类文件里，让模型每次开启任务时都读一遍。项目少的时候还好，项目一多就露馅了：同一套规范得反复复制粘贴，文件越写越长，模型看完前半段就已经把重点忘了。

Skills 解决的就是这个问题。它不是一段单纯的提示词，而是一个有结构的目录包：里面有 SKILL.md 作为主文档，可以附带脚本、模板、示例、参考文件。agent 只在任务匹配到这个技能时才会加载它，不匹配就不读，既不占上下文，也不会干扰其他任务。

打个比方，普通提示词像是给新员工口头交代“你按照老张那套方法做”；而 skills 像是递给他一本标准作业指导书，里面连第一步做什么、每步产出什么格式、最后要检查哪些点都写清楚了。AI 拿到的是“可执行的流程”，而不是模棱两可的期望。

另外，skills 的流行也和 AI 代理（agent）形态的成熟直接相关。工具调用只能让模型执行一个函数，但一个完整任务通常是一连串决策和操作的组合。比如“给这份比赛数据建一个线性规划模型并写出论文片段”，这背后需要理解题目、做假设、选模型、写代码、分析结果、组织语言。skills 给 agent 提供的是这一整条链路的“行动剧本”。

1.2 Skills 和普通提示词、插件、工具链的区别

很多人会问：有了 MCP、有了插件系统，为什么还需要 skills？这里得把概念掰开。

简单说，插件和 MCP 解决的是“手不够长”的问题，让模型能访问数据库、浏览器、设计稿；skills 解决的是“脑子不够清楚”的问题，让模型知道某个领域里专业的人是怎么一步步把事做完的。两者不冲突，甚至是配合关系。一个数学建模 skill 里可以写明“第一轮先用 Python 的 scipy 做数据清洗，第二轮若有大规模整数规划需求再调用 Gurobi 求解器”，这就是 skill 管流程、工具管执行。

还有一个容易混淆的概念：很多 Agent 框架里的“工具”（tools）是让模型能调用某个函数，而 skill 里也可以声明自己依赖哪些工具。但从使用者的视角看，两者最大的差异是：工具是被动等待调用的 API，skills 是主动指导行动的流程包。你写一个“前端代码审查 skill”，它会告诉模型审查时看哪些文件、用什么标准、产出什么格式的报告；至于要不要真的跑一次构建命令，那是它内部调用工具的事。

2. 动手写一个 Skill：结构、命名与常见格式

2.1 一个最简 SKILL.md 的解剖

现在主流的 AI 编码工具基本都沿用类似的约定：一个技能就是一个目录，目录里放一个核心的 SKILL.md 文件，可以有辅助文件和子目录。拿 Claude Code 生态来说，常见结构长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── data_clean.py └── references/ └── paper_template.md

SKILL.md 本身一般由两部分组成：YAML 格式的元信息开头，和 Markdown 格式的正文。元信息里最关键的字段是 name 和 description，description 写得好不好，直接决定 agent 能不能在正确的时机想起这个技能。

--- name: math-modeling description: 当用户需要用数学建模方法解决问题，例如竞赛题目分析、优化建模、数据拟合、模型检验与论文写作时使用。 --- # 数学建模技能 ## 适用场景 - 数学建模竞赛题目（如华为杯、国赛、美赛） - 常见工程问题中的优化、预测、评价类任务 ## 执行步骤 1. 解析问题，明确目标、约束和可用数据 2. 列出假设并说明合理性 3. 选择模型类型，说明理由 4. 编写求解脚本并运行 5. 对结果做敏感性分析 6. 输出可放进论文的结论段落 ## 输出要求 - 给出模型假设清单 - 给出核心代码和关键结果 - 给出论文可直接引用的文字片段

看到没，正文写的就是“给 agent 的标准作业流程”。模型读到这个文件，会把它当成一个权威的流程规范来执行，而不是把它当成一段可以随意发挥的聊天内容。

写 description 有个细节：要用第三人称描述“什么时候该用”，不要用“你需要”这种命令句式，而要写“当用户……时使用”。因为 agent 是靠匹配 description 来决定是否加载技能的，如果描述太窄，模型可能根本想不起它；如果描述太宽，它会频繁误触发。

2.2 把“数学建模套路”写进 Skill

我自己在准备华为杯时攒了一个建模技能，这里把我的写法拆给大家。竞赛建模的通用套路其实很固定：审题、假设、建模、求解、检验、写作。一个合格的建模 skill 就要把这六步写成模型能直接照做的命令。

首先是审题环节。很多 AI 拿到竞赛题目后容易犯一个错：题目还没读完就开始写代码。所以我会在 skill 里强制要求“先输出问题拆解，再输出数据清单，最后才能进入建模阶段”。这一步能拦下大半无效工作。

其次是假设环节。建模题不给假设，后面全白搭。我会让 agent 把所有假设一条条列出来，并标注哪些假设是为了简化计算、哪些假设直接影响结论可信度。这样到了写论文时，假设部分直接有素材，不用再回去补。

然后是模型选择。这个环节最容易看出 skill 的价值。没有 skill 的 model 可能会给每个问题都套神经网络，而好的 skill 会引导它先判断问题的类型：是预测就用回归或时间序列，是分类就用判别或聚类，是优化就用线性规划或整数规划，是评价就用层次分析或熵权法。这不是说模型不懂这些方法，而是 skill 给了它一套判断顺序，它输出会更稳定。

求解环节我会在 skill 里写死“优先用 scipy、pulp、ortools 等常见库，不要自己造轮子”，同时声明“如果问题规模超过 1000 个变量，优先考虑启发式算法，并在论文中说明复杂度”。这些细节都是竞赛拿分的关键。

最后是论文写作。别以为模型不会写论文，其实模型写出来的中文论文往往过于“通顺”但缺少学术感。我会在 skill 里放一个 references/paper_template.md，里面写好摘要、问题分析、模型假设、模型建立、模型求解、模型检验这几个章节的骨架，让模型照着填空。

2.3 评估一个 Skill 质量的经验判据

写过几个 skill 之后，我总结了几条判断标准，也分享给我团队的人用了：

1. 目标单一。一个 skill 只解决一类问题，不要想做“全能助手”。你把代码审查、文档生成、测试编写塞进同一个 skill，最后的结果是每个任务都干得不够专业。
2. 触发条件清晰。description 里要写明用户说什么话、遇到什么场景时该用。含糊的描述等于没有描述。
3. 步骤可执行。正文里不要出现“深入分析”“全面考虑”这种正确的废话，每条指令都得是 agent 能具体执行的动词：读取、列出、计算、对比、输出。
4. 包含输出模板。好的 skill 一定会规定产出格式。哪怕只是列个清单，也比让模型自由发挥强十倍。
5. 有反例或禁忌。把不该做的事写进去，比如“不要在没有数据支撑的情况下给出结论”“不要在建模前直接上深度学习”。限制条件越明确，模型的发挥越稳定。

3. GitHub 上的 Skills 怎么手动装进你的 Agent

3.1 手动安装的通用套路

社区里最常被问的问题就是：“GitHub 上有那么多 skills 仓库，到底怎么弄到本地来用？”我以手动安装为例，说一个通用流程，Claude Code、Codex、OpenCode 都适用，只是目录位置有差异。

第一步，去 GitHub 找到你要的 skills 仓库。下载方式有两种：一种是用 git clone 拉到本地，另一种是直接下载 zip 包。git clone 的好处是后续更新方便，直接 git pull 就行。

git clone https://github.com/某个用户/skills仓库.git cd skills仓库

第二步，看仓库的 README。这一步千万别跳过。有些仓库是单体仓库，里面包含十几个独立 skill；有些是单仓库单 skill。你要看明白它的目录约定，是要求装到全局目录，还是装到项目目录。

第三步，把 skill 目录复制到你的 agent 能识别的位置。以 Claude Code 为例，如果只想在某个项目里用，就放到项目根目录的.claude/skills/下；如果想全局都能用，就放到~/.claude/skills/下。放好后的结构应该是：

.claude/skills/ └── 某技能名/ ├── SKILL.md └── scripts/...

注意，SKILL.md不能直接放在.claude/skills/根目录下，必须再套一层以技能名命名的目录。这个错误我见过无数次，包括我自己第一次装 superpower skills 时也栽过跟头。

第四步：重启或重载。Claude Code 里通常是重启会话，或者用加载相关命令让它重新扫描技能目录。Codex、OpenCode 也各有各的重载方式，看官方文档就行。

第五步：验证。这是很多人会忽略的。装完之后不要直接开始干活，先试探性地问一下 agent：“你现在有哪些技能？”或者干脆用一句能触发技能的描述性需求，看它有没有按照技能里的要求来输出。这一步能确认你前面的目录结构有没有放对。

3.2 安装后的激活与使用检查

装好之后，agent 不会自动把 skills 加载到上下文里。它是按需读取的，所以会出现“装了但感觉没变化”的错觉。有些小伙伴就以为安装失败，其实是触发条件没写对。

我常用的验证方法有两种：一种是主动确认法，在对话里直接问 agent 是否识别到了某个技能，如果识别到了，它可以讲出这个技能大致是做什么的。另一种是任务触发法，用一个典型的任务句子让它干活，然后观察输出风格。比如你装了一个偏学术写作的 skill，那就给它一个普通的写作任务，看它在回答里有没有主动套用论文结构。

另外，部分 agent 工具支持在消息中通过约定语法强制指定技能，比如在消息里写上技能名。这种方式适合你想精确控制某个任务使用哪个技能的场景，不需要靠模型自己判断。如果遇到那种“说了半天它也没自动用上”的情况，可以先用强制语法救急，之后再回来修 description。

3.3 手动安装最容易踩的三个坑

第一个坑是目录套错层级。很多人把 zip 解压后直接整个拖进.claude/skills/，结果就有了.claude/skills/xxx-main/SKILL.md，这其实也能跑，因为 agent 会递归扫描子目录，但有些 agent 只扫描一层，会导致某些技能读取不到。稳妥的做法是把仓库里真正代表技能的那一层目录放进 skills 目录，而不是把仓库解压后的外层目录放进去。

第二个坑是辅助脚本没有执行权限。skill 里如果带了.py或.sh脚本，而你的 agent 是本地代理进程，脚本可能需要加上可执行权限。我在 Linux 和 macOS 上遇到过好多次，明明 skill 写得很完整，可一执行就报 permission denied。解决方案很简单：

chmod +x ~/.claude/skills/某技能/scripts/*.py

第三个坑是版本不匹配。GitHub 上很多 skill 仓库是跟着 Claude Code 的特定版本走的，元信息字段和运行方式可能已经变化。有些老仓库里的 SKILL.md 还写着旧版格式，装到新版工具里会出现无法加载的情况。遇到这种问题，与其自己瞎猜，不如去仓库的 Issues 里搜关键字，基本都能找到别人已经踩过坑的记录。

4. 按场景选 Skills：建模、前端、漫剧与开源合集

4.1 数学建模场景：如何配一套“竞赛武器库”

每次到了华为杯、国赛或者美赛的备赛季，就会有一批人到处搜“数学建模 skills 推荐”。其实竞赛建模对 AI 的需求高度集中在几个阶段：审题拆解、数据清洗、模型选型、代码实现、论文输出。对应的 skills 也可以按这五个环节来搭。

我自己的竞赛配置是这样的：一个“数学建模总控”技能负责整个流程的编排，一个“数据清洗与探索”技能负责处理各种脏数据，一个“优化建模”技能专门处理线性规划、整数规划、动态规划，一个“论文生成”技能负责把建模过程转成规范的学术论文。总共四个技能，互相配合又互不干扰。

这里要特别说一下“优化建模”技能。数学建模竞赛里大量题目其实是运筹优化问题，这类问题最关键的不是会调库，而是能正确地把业务约束翻译成数学约束。如果模型没搞懂约束，那它跑出来的最优解就毫无意义。所以我会在这一类技能里明确要求：先列出所有约束条件，逐个标注是否转换成线性约束，再说明选择的求解器类型。这一招在实战里非常管用，能让模型少犯“约束漏掉”的低级错误。

另外提醒一句，竞赛场景千万别贪多。技能装得越多，模型反而更容易在错误的场景用上错误的技能。我见过有人一口气装了十几个建模技能，结果比赛时模型一会儿按这个技能的要求输出、一会儿按那个技能的风格说话，效果极差。竞赛就四天时间，技能栈越精简越好。

4.2 前端开发场景：从组件生成到整体工程

前端大概是 skills 落地最多、最成熟的领域之一。因为前端开发有大量的“重复套路”：组件怎么写、样式怎么组织、状态管理怎么拆分、性能优化要检查什么，这些都是高度流程化的知识。

前端开发技能的形态很丰富。我见过最有用的一个“组件开发技能”，专门处理“让 AI 按项目既有风格写新组件”的问题。它的做法是让 AI 先读取项目里已有的几个组件作为风格参考，再读取设计稿或者需求描述，最后按照固定格式输出一个包含组件、样式、测试的完整 MR。这样出来的代码，比直接让 AI 根据一句话生成的要贴合得多。

另一个很常见的是“代码审查技能”。前端代码审查其实有一套标准流程：先看依赖是否合理、再看组件拆分是否恰当、然后看是否有不必要的重渲染、最后看样式是否规范。把这一套写进技能里之后，AI 每次做代码 review 都会按同样的标准输出，不会这次看性能、下次突然盯起文案来了。对于团队来说，这种“可复现的审查标准”价值极高。

还有个方向是“HTML 转框架代码”技能。设计师给一个静态 HTML 页面，AI 需要把它转成 Vue 或 React 组件。没有技能约束时，AI 经常会出现把 inline style 直接搬过去、遗漏事件绑定、不处理响应式布局等问题。有了技能之后，转换过程就变成了固定流水线：先分析布局结构，再拆分组件树，再生成模板和样式，最后检查交互。每一步都有章可循。

前端开发 skills 的另一个好处是特别适合团队沉淀知识。团队里如果有一套自己的前端规范，完全可以把规范文档结构化成 SKILL.md，这样任何人在这个项目里用 AI 写代码，写出来的风格都是统一的。这对大项目来说价值非常大。

4.3 AI 漫剧与内容创作场景

“AI 漫剧”这个词最近在内容创作圈非常火，本质上就是用 AI 生成漫画风格的连续剧集内容，包括分镜、角色、配音、脚本等。这个场景看起来和写代码没关系，但实际运营的人会发现，AI 漫剧最头疼的就是一致性：同一个角色下一秒脸就变了，同一个场景换个画风，观众直接出戏。

这时候 skills 就派上用场了。一个“角色一致性”技能，可以要求 AI 在生成任何画面之前先输出角色的完整描述卡，包括发型、眼睛颜色、服装细节、常用表情，然后要求所有后续生成的画面必须引用这张描述卡里的关键标签。这会最大限度地减少角色漂移问题。

再比如“分镜脚本”技能，可以规定 AI 按照“景别—镜头运动—画面描述—台词—字幕—时长”的格式来产出分镜脚本。这种格式化的输出能直接喂给后面的绘图工具和配音工具，剪辑师也能照着脚本直接对素材，省去大量沟通成本。

内容创作场景的技能和编程场景有个显著区别：编程技能可以非常依赖脚本和命令行，而创作技能更多靠的是“输出结构”和“标签体系”。所以你在写这类技能时，重点不是教 AI 调工具，而是给它一套专业创作者的工作流程和输出模板。模板定了，流程顺了，AI 的产能就能稳定释放。

我建议做漫剧的同学先从一个最小技能包开始：一个角色库、一个分镜模板、一个画风控制条款。这三个技能可以覆盖掉漫剧制作 80% 的重复劳动。等跑顺了再去加配音指导、剪辑节奏之类的进阶技能。

4.4 值得关注的几个开源 Skills 集合

社区里已经有不少整理得很好的技能集合，这里说说我实际接触过、并且觉得有参考价值的几类。

superpower skills 应该是知名度最高的一个合集。它由社区开发者维护，里面包含了几十个技能，覆盖了从代码开发到项目管理的各种场景。它最值得学习的地方不是技能本身，而是它的目录结构和编写规范写得非常清晰。即便你不直接使用它，光看它的 SKILL.md 怎么组织，就能学到非常多东西。安装它时需要手动下载到本地，具体的目录要求以仓库 README 为准，不同版本有过调整，不要硬套网上教程的路径。

Codex 生态里最近也冒出了不少 skills 仓库，比如有人把一些自然语言处理能力封装成套件，起了类似 codex nature skills 的名字。这些仓库多半是个人开发者针对自己的使用习惯整理的，质量参差不齐。判断标准很简单：看 SKILL.md 里的步骤是不是够具体，有没有可执行的命令或检查清单。如果全是抽象描述，那基本就是个凑热闹的仓库。

TypeScript 生态里有一个方向很有意思，叫 typesafe ai skills，核心思路是用 TypeScript 的类型系统来约束技能的输入输出参数。比如一个“数据清洗”技能，输入是什么类型的数据、输出是什么格式的结果，都用类型定义写清楚。这样做的好处是在大型团队里复用技能时，不会出现“传错参数”的问题，代码补全也能提供更好的提示。这个思路比较适合那些想把 skills 工程化、体系化的团队借鉴。

还有些偏流程编排的工具，比如你们可能听说过 cola skills，或者各种带网页端的 agent 工具。这些产品往往在网页控制台里做了技能市场，用户点一点就能安装启用，不需要碰命令行。这解决的正是“手动 clone 太麻烦”的痛点，适合刚好在用这类工具、又不想深究文件结构的朋友。

5. Skills 的维护：清理、更新与冲突治理

5.1 为什么要定期清理 Skills

很多人的 skills 目录会逐渐膨胀。今天看到一个好的就装一个，明天觉得那个有用又装一个，慢慢地，目录里躺着几十个技能。问题也随之而来。

首先，大量的技能并不会一起发挥作用，但是会影响 agent 的决策效率。每次 agent 需要判断“该不该用技能、用哪个技能”时，它都会扫描一遍技能描述。如果技能描述互相交叉、语义接近，模型就会陷入纠结，甚至选错。其次，维护成本也会上升：更新一个工具后，某些旧技能可能就失效了；依赖冲突、命令失效，让人焦头烂额。

这就好比你把所有工具都塞进同一个工具腰带，干活的时候你以为自己能随手抽出需要的那把，其实更多时候是在一大堆相似工具里翻找。技能不是收藏品，它是要被实际调用的，所以必须定期清理。

判断一个技能该不该留，可以看三个指标：一是触发频率。如果连续一个多月都没触发过，说明它对你日常工作没有助力，删掉不心疼。二是内容是否已经被别的技能覆盖。如果新装的一个技能已经包含了旧技能 80% 的能力，是时候合并或删除了。三是维护意愿。如果这个技能已经两次因为版本升级而失效，而你每次都得花时间修，那它带来的麻烦已经超过了价值。

5.2 社区里常见的清理思路

我在社区里看到不少优秀的维护方法论，印象比较深的是一个叫 Tibo 的开发者分享的清理手段。他的核心观点是：把 skills 当 npm 依赖来管理，而不是当收藏夹管理。听起来很朴素，但这是两种完全不同的心智模型。

依赖模型关心三个问题：这个包是否被我的项目引用？版本是否兼容？是否有更优的替代？收藏夹模型只关心一个问题：我是不是曾经收藏过它？按依赖模型去审视自己的 skills 目录，你会发现很多技能根本不该出现在那里。

具体操作上，可以先给每个技能标注“最近一次触发日期”和“所属项目”。然后按项目维度来评估，而不是按单个技能来评估。比如你最近在做数学建模，那就只需要保留建模相关的技能，那些之前做前端时装的组件技能可以先移出全局目录，放到项目技能目录里。等到再回到前端项目时，技能会自动出现。

清理之后还不够，我建议对全局 skills 目录做一次“标准化”：统一命名、统一补上 description、删除掉没有 SKILL.md 的空目录。这一步看起来费时间，实际是在为你后续使用铺路。一个结构清晰的 skills 目录，远比一堆堆叠起来的“大招”更实用。

6. 常见问题排查与避坑记录

6.1 装完不生效、提示不到技能

这是最高频的问题。现象往往是你明明按教程装好了技能，但和 agent 对话时它完全不按技能里写的来。排查看三板斧：

先确认目录位置对不对。技能必须放到 agent 指定的目录层级，且 SKILL.md 要在正确的位置。很多工具对大小写敏感，目录输错一个字母就废了。

再检查 description 的触发词。回想一下你测试时说的话，是不是真的能和技能描述匹配上。description 写得过于狭窄的话，模型很难把它和真实需求关联起来。常见的修正方式是把“当用户要求进行线性规划求解时使用”改成“当用户需要进行数学建模、优化求解、资源分配、生产计划等问题时使用”，覆盖范围一下宽了很多。

最后看有没有重载会话。有些 agent 在加载技能目录后不会热更新，需要你重启会话或者执行重载命令。这个细节经常被人忽略，但确实是最容易解决的。

6.2 多个技能互相打架

当你有多个技能覆盖相似场景时，就会出现冲突。典型表现是：你让 AI 做技术方案设计，结果它一会儿按前端技能的思路走、一会儿按架构技能的思路走，输出内容风格混乱。

这种情况我一般先看这两个技能的 description 是否有重叠。有重叠就直接改 description，给每个技能划出清晰边界。比如“前端性能优化”和“通用性能排查”就很容易冲突，可以把前者限定为“只处理浏览器端运行时性能问题”，把后者限定为“处理后端接口和数据库性能问题”，一下就不冲突了。

还有一种情况是技能之间的脚本互相覆盖，比如两个技能都定义了.claude/skills/下的scripts/preprocess.py，但内容完全不同。这种问题只能靠目录规范解决：每个技能必须把脚本放在自己的子目录里，不允许引用其他技能的相对路径。

6.3 上下文太长、费用上升

把多个技能同时加载进对话会占用大量上下文，尤其是技能里带了一堆参考文件、模板、示例之后。上下文长了，token 消耗自然就上去，费用也跟着涨。如果你发现最近跑任务的成本明显增加，可以先检查是不是一次会话里加载了过多技能。

收敛的办法有几个：一是精简技能内容，把 SKILL.md 里的废话删掉，只保留操作性指令和必要模板。二是把低频技能从全局目录挪到项目目录，让工具在无关项目里扫描不到它。三是利用工具的“按需读取”机制，不要为了让技能“更强大”而把所有参考资料都堆在主页里。真正需要时，再让 AI 读取 references 目录下的详细文件，比一次性全部塞进上下文里省得多。

我个人在实际操作中的体会是，skills 这套机制真正的分水岭不在“会不会装”，而在“会不会剪”。能写出一个精简、边界清晰、触发准确的技能，比安装十个大而全的技能有用得多。而且 skills 这东西是需要养的，不是装完就完事。工具版本会升、业务流程会变、工作场景会换，每隔一两周花十分钟整理一下自己的技能目录，比临时抱佛脚翻各种“技能合集”要有效得多。最后一个小建议：给自己常用的工作流写一套专属技能，哪怕只有两三个文件，它的顺手程度也远超过任何网上流传的大合集——因为没人比你更清楚你自己干活时真正需要遵守的套路。