企业官网建设流程全解析

我最早对 skills 不以为意，觉得不过是把提示词换了个马甲，塞进一个目录里而已。直到有一次，我把一个数学建模老手的技能包塞进 Codex，原本计划花两小时整理数据、贴公式、排版论文的工作，四十分钟全跑完，我才意识到这玩意儿比单个提示词整整高一个维度。现在社区里最火的说法叫 superpower skills，翻译过来就是“给 AI 装上可复用的超能力”，我觉得一点都没夸张。

你手里的 Claude Code、Codex、OpenCode 其实都已经是相当强的 Agent，但默认情况下它们更像一个“什么都会一点但不够专”的实习生。你给它们一份前端开发的 skill，它就会按团队的代码规范写页面；你给它们一套数学建模的 skill，它就知道赛题数据该怎么做清洗、相关性分析、模型对比、论文排版。换句话说，skills 解决的是“AI 懂通用知识，但不懂你的行业规矩和项目套路”这个核心问题。

这篇文章我打算聊透几件事：skills 到底是什么、为什么值得当超能力用；如何手动安装 GitHub 上的现成技能包；前端开发、数学建模、AI 漫剧这几个热门场景分别怎么挑技能；最后从零手写一个 skill，分享我在实际使用和清理维护中踩过的坑。无论你是刚接触 Agent 编程的新手，还是已经在折腾技能库的老手，应该都能在里边找到能直接抄作业的东西。

1. 什么是 AI Skills，为什么会被当成“超能力”

1.1 从 Prompt 到 Skill：AI 工作方式的转变

纯 Prompt 的方式是这样的：你每次跟 AI 说“帮我写一个 React 组件，遵循公司规范，要测试用例”，AI 只能靠它训练时的记忆去猜“公司规范”长什么样。如果你换了项目、换了模型、换了会话窗口，这些要求都得重新说一遍。信息是碎片化的，模型每次都在“盲猜”。

Skill 走的是另一条路：把一份完整的“岗位说明书 + 操作手册 + 范例 + 校验脚本”打包成目录。Agent 在干活之前会先扫描目录里的 SKILL.md，读一读描述，判断当前任务跟哪个技能匹配。一旦匹配上，它就把整套手册读进上下文，然后按手册里的步骤执行。同样写一个 React 组件，这时候它手里已经拿着你们团队的目录结构、组件命名规则、测试断言风格、甚至历史优秀代码片段。

打个比方：Prompt 是你在电话里口头叮嘱“到了现场看着办”，Skill 是直接甩给对方一本带图纸、带清单、带验收标准的施工手册。你能放心让施工队干的事，完全不是一个量级。

1.2 Skills 的本质是“给模型一套可执行的操作手册”

一个标准的 skill 不像一个函数那样只有一个文件，它通常是一个有结构的目录：

my-skill/ ├── SKILL.md ├── scripts/ │ └── validate.py ├── templates/ │ └── report-template.md └── references/ └── style-guide.md

其中 SKILL.md 是入口，头部有一段 YAML 格式的元信息，下面是正文：

--- name: frontend-component-generator description: 生成符合项目规范的前端组件，包含样式、测试、Storybook 示例。 --- 当用户要求创建新组件时，按以下步骤执行： 1. 先读取 references/component-patterns.md 2. 在 src/components 下按 PascalCase 命名...

为什么说它“可执行”？因为这些步骤不是写给人看的建议，而是模型会被要求逐条遵守的操作指令。更关键的是，整个目录里还可以放脚本。模型在完成代码生成后，可以自己跑一遍校验脚本，检查生成的组件是否满足规范。出错就自动修，修完再跑，直到通过。

这种设计解决了一个根本问题：模型上下文窗口是有限的，你没法把一百个技能的所有细节一股脑塞进去。平时每个技能只暴露一段描述，等 Agent 判断“这个任务可能需要它”的时候，才把完整手册加载进来。这就好比一个大型公司不会让所有员工背诵全部 SOP，而是每个岗位只保留自己的那份流程手册，接到对应工单才翻开看。

1.3 为什么“superpower skills”突然这么火

GitHub 上出现了一批高星项目，名字都起得很张扬，最常见的标签就是 superpower skills。我观察到的原因有三个：

第一，工具链终于支持了。Claude Code、Codex、OpenCode 陆续开放了自定义技能目录，社区立刻跟进，各种技能包呈井喷式增长。以前“给 AI 装技能”只是个概念，现在复制一个文件夹进去就能用。

第二，真实收益太明显。前端开发场景里，一个团队把组件规范、代码 review 要点、提交信息格式做成 skill，AI 生成代码的一次通过率肉眼可见地提高；数学建模场景里，赛题数据处理、论文排版这些“不聪明但繁琐”的活，技能包能做到标准化交付。效率提升一倍不夸张，自然口口相传。

第三，分享门槛足够低。一个 skill 本质上就是一个带说明文档的目录，GitHub 上 clone 下来就能用，改起来也简单。于是出现了大量“常用 skills 源网站”、聚合仓库、各类榜单，还有人专门做“skills 网页版进入”，让你在浏览器里直接浏览技能介绍和安装命令，不用先把仓库拉下来再翻文件。生态一旦滚起来，热度就很难降下去。

2. 先把现成的 Skills 用起来：安装与引入

2.1 技能包长什么样：目录结构与 SKILL.md 规范

不同工具的技能目录位置不太一样，但装好之后你在命令行里看到的形态大同小异。这里拿 Claude Code 举例：项目级技能放在.claude/skills/下，用户级技能放在~/.claude/skills/下。Codex 对应的是.codex/skills/或~/.codex/skills/，OpenCode 则是.opencode/skills/或~/.config/opencode/skills/。

目录里的核心就是 SKILL.md。我建议第一次接触技能的人先找一个现成仓库打开 SKILL.md 看看，比读任何教程都直观。里面通常分两块：头部的元信息负责“给 Agent 看”，正文的步骤和示例负责“给 Agent 用”。

--- name: math-modeling-report description: 用于数学建模竞赛论文的框架生成、公式排版校验与图表规范检查。当用户提到建模报告、论文排版、公式规范时使用。 ---

description 这块千万别小看，它是整个 skill 能否被正确调用的关键。Agent 不是每次对话都把每个技能完整读一遍，它只是快速扫描所有技能的 description，然后做匹配。你描述写得含糊，它可能该用的时候没用；描述里塞满无关关键词，它又会不该用的时候乱用。

2.2 手动安装 GitHub 上 Skills 的两种方式

总有人问“claude code 怎么手动装 github 上的 skills”，其实核心就两步：找到技能目录，复制到正确位置。最直接的方式是先把整个仓库 clone 下来，再把其中某个技能目录复制过去：

git clone https://github.com/username/awesome-skills.git # 查看仓库里有哪些技能 ls ./awesome-skills/skills/ # 安装到用户级目录（所有项目可用） mkdir -p ~/.claude/skills cp -r ./awesome-skills/skills/frontend-component ~/.claude/skills/ # 如果你只想在某个项目里用，可以放到项目级目录 mkdir -p .claude/skills cp -r ./awesome-skills/skills/frontend-component .claude/skills/

Codex 和 OpenCode 的安装逻辑几乎一样，只是路径名不同。

# Codex 全局目录 mkdir -p ~/.codex/skills cp -r ./frontend-component ~/.codex/skills/ # OpenCode 项目级目录 mkdir -p .opencode/skills cp -r ./frontend-component .opencode/skills/

第二种方式适合只想要某一个技能的情况：直接在 GitHub 网页上进入那个技能的目录，逐个文件复制粘贴。虽然啰嗦，但如果你用的是公司内网环境、不方便 git clone 外部仓库，这种手动复制反而是最稳的。复制的时候注意保留目录结构，别把 SKILL.md 直接丢到 skills 根目录底下，那样技能名会丢失，Agent 扫描的时候会犯迷糊。

还有一个容易踩的坑：很多技能包会带 scripts 目录，里面是 Python 或 Bash 脚本。复制到本地后，如果脚本没有执行权限，Agent 调脚本时会直接报错。装完技能之后记得给相关脚本加权限：

chmod +x ~/.claude/skills/frontend-component/scripts/*.py chmod +x ~/.claude/skills/frontend-component/scripts/*.sh

2.3 安装后验证与权限设置

装完不是就完了，一定要验证。Claude Code 里直接输入/skills，会列出当前所有可用技能；Codex 通常可以在启动日志里看到它扫描了哪些目录，也可以直接在对话里问“你现在有哪些技能”。如果列表里没出现你刚装的技能，先别急着怪工具，按这个顺序排查：

• 目录路径是不是放错了层级，技能目录必须直接放在 skills 根目录下，不能再套一层文件夹。
• SKILL.md 是不是放对了位置，文件命名不能变。
• YAML 头部是否完整，name 和 description 是必须字段，缺一个就可能被静默忽略。
• 是否已经重启会话，技能扫描一般在会话启动时加载。

权限这块多说一句：给 Agent 技能本质上是授予它一套“自动化操作权限”，尤其是带脚本的技能，相当于让 AI 能在你的机器上执行代码。从可信仓库下载的还好，来历不明的技能包建议先打开 SKILL.md 和 scripts 目录里的脚本看一遍再装。这不是危言耸听，技能描述写得再漂亮，脚本里要做坏事你也拦不住。

2.4 常用 Skills 源网站推荐

GitHub 是目前技能包最集中、更新最勤的地方。你可以直接搜“awesome claude skills”“awesome codex skills”，或者看社区维护的聚合仓库。我常用的几类来源：

• 通用聚合型仓库：一个仓库收录几十上百个技能，分类清晰，适合初学者批量浏览。比如有些仓库会按“前端开发 skills”“数学建模 skills”“写作与翻译 skills”做目录分组。
• 场景专精型仓库：比如专注于前端工程化的 typesafe ai skills 这类 GitHub 项目，里面技能偏 TypeScript、类型安全、组件规范，适合工程团队直接引到项目里。
• 网页版技能库：现在不少项目做了“skills 网页版进入”的体验，浏览器打开就能看到技能卡片、描述、标签和安装命令，比翻 GitHub 目录方便得多。这类站点通常也支持搜索，直接搜“前端开发 skills”就能筛出来。

我自己的习惯是：先看网页版或 README 里的技能列表，锁定三五个，再单独 clone 仓库看细节。不建议一口气装几十个技能，后面我会专门说清理的事，但这里先提一句：技能不是越多越好，你的 Agent 每次启动都要扫描所有技能描述，装得太杂反而增加匹配误差。

3. 分场景挑 Skills：前端开发、数学建模、AI 漫剧

3.1 前端开发 Skills：把重复劳动交给 Agent

前端是目前技能包生态最繁荣的场景之一，原因很现实：前端规范多、样板代码多、重复劳动多。一个组件从创建到验收，涉及命名风格、目录位置、样式方案、测试断言、文档示例，每个环节都有大量“约定俗成”的规则。这些规则靠嘴说，AI 记不住；写进技能里，AI 才能严格执行。

我在项目里实际用过的前端技能大致分几类：

• 组件生成类：读取项目已有组件风格，再按同样风格生成新组件。
• 迁移重构类：把旧的 class 组件改写为函数组件，把 CSS 迁移到 CSS Modules，批量替换 API 调用方式。
• 质量保障类：检查是否缺少 key、是否存在隐式 any、样式是否使用了被禁用的属性，然后自动修复。
• 协作规范类：根据 git diff 生成符合团队模板的 PR 描述、根据提交信息规范生成 commit message。

这类技能的共通点是“绑定项目规范”。一个从 GitHub 上直接拉下来的通用组件生成技能，到了你的项目里未必好用，因为它不知道你们团队的目录结构、不知道你们用的是 Tailwind 还是 styled-components。真正好用的做法是拿社区的技能包当模板，把 references 目录里的规范文件替换成你们项目自己的文档，把 examples 换成真实代码。我试过几次，替换之后 AI 生成代码的贴合度能上一大截。

3.2 数学建模 Skills：从数据分析到论文成稿的加速器

数学建模可能是“用技能收益最大”的场景之一，因为整个流程高度标准化：从拿到赛题到最终论文提交，中间要经历数据分析、模型选择、参数调优、可视化出图、公式规范化、论文排版，每一步都有固定套路。这些套路正好适合沉淀成技能包。

我身边参加竞赛的朋友（包括被华为杯等比赛虐过的人）现在基本都会准备一个 codex 技能包，里面至少包含下面几个模块：

• 赛题拆解：拿到题目后自动提取问题层次、列出假设条件、梳理数据字段。
• 数据清洗：检测缺失值、异常值、量纲差异，生成清洗报告。
• 模型速选：根据数据类型和目标函数，推荐候选模型，并用交叉验证做初步对比。
• 论文框架：生成标准论文大纲，把图表编号、公式编号、参考文献格式固定好。
• 图表规范：输出统一风格、统一字体、带标题和图例的图表。

这类技能写起来有个特点：数学建模涉及的模型 library 更新很快，技能里不要写死“用哪个版本、哪个函数”，而是写“先尝试哪些方法、按什么指标比较、怎么输出结果表”。把判断力留给模型，把流程固定交给技能。

如果你不想自己从头写，GitHub 上搜“数学建模 skills”能找到不少现成的。安装后先拿一套往年赛题数据跑一遍，把不贴合你习惯的步骤改掉。基本上改一版之后，后面每次拿到新题目，AI 都会自动进入那条熟悉的流水线。

3.3 AI 漫剧与内容创作 Skills：风格统一才是王道

AI 漫剧是最近很热的内容创作方向，这类作品的制作链条很长：角色设定、分镜脚本、画面生成、对白配音、后期剪辑，而且最大的痛点是“风格一致性”。同一个角色这一集长这样，下一集可能就换脸了；同一个场景，换个模型参数氛围就全变了。

Skills 在里边能干的事，是把“风格约束”做成一个可复用的技能包。比如说你写一个角色一致性技能，目录里可以放角色卡（角色外貌、服装、语气、口头禅）、风格词表（固定的画风关键词、调色倾向、光影描述）、分镜模板（景别、运镜、转场规则）、对白风格示例。这样一来，无论哪一集、哪个阶段，AI 在生成或检查内容时都先加载这套规范，输出的东西才不至于东一榔头西一棒槌。

内容创作类技能还有个特殊用法：反推。很多创作者会把自己过往爆款作品的关键词、镜头语言、台词节奏整理成参考文档塞进技能包，让 AI 在创作新内容时先学习旧风格。这比我手动写一百句“注意保持风格统一”有效得多，因为风格是抽象的，模型需要靠具体范例来理解，而不是靠空泛的形容词。

坦白说，内容创作类技能到现在还没有统一标准，社区里“AI 漫剧常用 skills”这类分享也多是各家用各自的经验拼出来的。我的建议是别指望找到一个现成技能包就能搞定期望的效果，把它们当成起点，往里填入你自己的角色卡和风格样本，慢慢迭代。

4. 写一个属于自己的 Skill：从零到可用的完整流程

4.1 设计 Skill 的边界：先想清楚“给谁用、解决什么”

我见过很多第一次写技能的人，上来就想做一个“万能助手技能”，什么都能干，结果写完发现 Agent 根本不知道该在什么时候用它。写技能跟写函数是一个道理：职责单一，边界清晰。

动手之前先回答三个问题：这个技能只在什么时候触发？它替用户省掉的是什么工作？它的输入和输出分别是什么？举个例子，你想写一个“前端技能”，最好拆成“React 组件生成”、“样式迁移”、“PR 描述生成”三个技能，而不是写一个“前端全能技能”。因为 Agent 是按描述匹配的，职责越聚焦，匹配越精准。

另外，技能不是越详细越好。SKILL.md 正文里堆砌八百行指令，模型未必都能记住。更合理的做法是写清楚步骤框架、关键约束、验收标准，把细节放进 references 目录由模型按需读取。一句话：正文给主流程，参考文件给细节。

4.2 目录与文件组织，以及一个可直接改的模板

一个最小的技能目录只需要一个 SKILL.md，但为了好维护，我习惯按下面这种方式组织：

format-report/ ├── SKILL.md ├── templates/ │ └── report-template.md ├── examples/ │ └── good-example.md └── scripts/ └── check_format.py

SKILL.md 基本长这样：

--- name: format-report description: 将杂乱的数据分析结果整理成结构化的报告。适用于数学建模、数据分析项目中的结果汇总和排版。 --- # 报告格式化技能 ## 触发条件 - 用户要求“整理结果”“生成报告”“格式化输出” - 用户提供了一堆表格、图表或统计结果 ## 执行步骤 1. 读取 templates/report-template.md 中的报告结构。 2. 将用户提供的数据填入对应章节。 3. 所有表格必须包含表头、单位、数据来源。 4. 所有图表引用必须使用“图1: 说明文字”的格式。 5. 跑一遍 scripts/check_format.py，检查是否遗漏必填字段。 ## 注意事项 - 不要修改用户原始数据，只调整呈现格式。 - 如果数据缺失，标注“待补充”，不要编造。

这个模板可以直接复制改。你会发现最核心的东西其实就三块：触发条件、执行步骤、注意事项。触发条件写得好不好，直接决定了 Agent 会不会“主动抄起”这个技能。

4.3 打磨细节：描述、参数、示例缺一不可

description 是最容易被低估的部分。你写“用于报告生成”，看似没问题，但 Agent 面对“把这段数据整理一下”这种模糊请求时未必会联想到这个技能。更可靠的写法是带具体触发词：“当用户提供数据集并要求整理、汇总、输出结构化报告时使用。适合数学建模、数据分析场景。”让描述跟真实对话用语贴近，匹配率才会高。

examples 目录也有大作用。模型擅长从示例里学模式，光靠文字指令描述“好的报告长什么样”，不如直接扔一个优秀范例。我第一次写技能的时候没有放 examples，Agent 生成的模板总差点意思；放进两个范例之后，输出质量肉眼可见地提升。后来我把这条经验用在了所有技能上：凡是涉及格式要求的技能，必须带“好例子”和“坏例子”。

参数这块，大多数技能其实不需要搞复杂的参数声明。模型能从对话上下文里推断出大部分信息，比如文件路径、目标语言、输出格式。不要为了“看起来专业”硬设计参数，徒增使用门槛。

4.4 调试与迭代：本地跑通再考虑共享

技能写完一定要实测。测试方法很简单：开一个新会话，只加载这一个技能，拿一个真实任务让它跑一遍。重点看三件事：技能有没有被触发、执行步骤有没有被完整遵守、输出是否符合预期。

调试过程里最常遇到的问题就是“技能没被触发”。排查思路是先看 description 是否包含用户可能说的词，其次看技能目录路径是否正确。有时候 Agent 加载了很多技能，匹配分数被稀释，这种情况下可以适当把 description 里无关的词删掉，让它更聚焦。

迭代方面，给技能目录挂个 git 仓库是我强烈推荐的做法。技能是会演化的：你可能今天加一条新规范，明天改一个模板。没有版本管理，改坏了想回退都难。放到 Git 仓库里，每次修改都有记录，等稳定之后还能分享到 GitHub 上，变成你个人的“常用 skills 源网站”里的一个条目。

5. 避坑指南：Skills 使用与维护中的真实问题

5.1 常见问题速查表

我把实际使用中遇到的典型问题整理成了一张表，方便你快速定位：

这里特别说一下中文匹配问题。Claude Code、Codex 这类工具，描述匹配底层大多依赖向量检索或关键词打分，中文分词效果确实不如英文稳定。我处理的办法是：description 里先用中文写清楚触发场景，再补一句英文关键词，比如“用于数学建模报告整理，math modeling report formatting”。这样无论模型用什么匹配策略，命中概率都会更高。

5.2 清理与更新：skills 用久了会“脏”

网上有人分享过“tibo 关于清理 skills 的方法推荐”，说白了就是定期给技能库做减法。我自己的经历也印证了这个必要性：技能装多了之后，启动扫描时间变长，匹配容易串味，该用的技能反而不被触发。清理思路只有一条：让 Agent 每次加载技能时面对一个精简、高相关的集合。

我习惯每两周做一次全量检查。先列一下所有已安装技能，看看哪些在过去两周根本没用上，果断删掉。保留的技能再看一眼 description 是否还符合现在的项目风格，不符合就改。最后把正在使用且足够稳定的技能做一次版本归档，方便回退。

这里给一个简单排查脚本，可以快速列出每个技能的核心描述：

find ~/.claude/skills -name SKILL.md | while read f; do echo "===== $(basename "$(dirname "$f")") =====" head -5 "$f" echo done

跑完一遍，哪个技能讲了什么，一目了然。删之前注意一点：团队共享的技能不要只改本地，要做变更同步给队友，否则你这边清理完了，别人那边还在用老版本，同一个项目里 Agent 行为不一致，埋雷。

5.3 我的几条实操心得

先交代背景：我日常主要用 Claude Code 写前端项目，用 Codex 跑数学建模相关任务，OpenCode 作为轮换工具。以下体会只代表个人经验，但都是我实际踩过了坑之后才得出的。

第一，项目级优先于全局级。全局目录里的技能所有项目都能看到，听起来很方便，但跨项目的时候描述匹配容易乱。比如前端项目里最常触发的是组件生成技能，你把它放到全局目录，写后端代码的时候它也可能跑出来凑热闹。更合适的做法是：全局目录只放跨领域通用技能，比如“提交信息规范化”；项目目录放这个项目专属规范，比如“商城前端组件生成”。

第二，描述里要写“什么时候不要用”。很多技能作者只写了触发条件，不写排除条件，结果 Agent 在边界场景乱用。我在自己的技能模板里固定加一块“不适用场景”，效果非常明显。

第三，技能要跟着项目走。项目代码在演进、规范在变化，技能如果不更新，很快会变成“一本过时的操作手册”。每次项目规范有调整时，顺手改一改对应的 skill 文件，不要攒到问题集中爆发再处理。

第四，尽量看官网或官方模板再写自己的。很多人写技能喜欢凭空臆想格式，其实各工具对 SKILL.md 字段都有参考文档。照着官方示例写一遍，再改内容，比从零摸索省非常多时间。

这个内容后续再做深挖的话，可以往技能调试工具、技能质量评分、团队技能库共享平台这几个方向扩展。就我目前的使用体验来说，skills 最迷人的地方不是“让 AI 变聪明”，而是让 AI 的行为变得可控、可复制、可沉淀。一份好技能，就是一个团队或一个人多年经验的实体化。它不像聊天记录那样被冲散，也不像口头经验那样容易失真，它会跟着你的项目一起迭代。先把一个最顺手的小技能写出来，跑通一次，你大概就能理解为什么社区里这么多人对这玩意儿着迷了。