企业官网建设流程全解析

这半个月我基本把GitHub上和skills相关的仓库翻了个遍。从Anthropic官方那个技能示例库，到社区里star过万的superpowers，再到华为杯建模群里大家互相传的codex技能包，前前后后装了不下三十个skills，也亲手拆了几个仓库研究它们的写法。先说结论：不管你是用Claude Code、Codex还是OpenCode，skills这套东西本质上就是同一件事——给AI Agent准备一批标准化的"任务执行手册"，让它在遇到对应场景时能按成熟的经验干活，而不是每次临场发挥。这篇就把我关于skills的理解、安装方法、推荐清单和自己动手写的经验一次性讲清楚。

1. skills到底是什么，先掰开揉碎讲明白

1.1 一张SKILL.md就是一本岗位说明书

很多人第一次接触skills，是在某个项目的目录里看到一个叫.claude/skills的文件夹，里面躺着几个子目录，每个子目录里有一个SKILL.md文件。打开一看就是普通的Markdown，顿时觉得"就这？"

对，就这。但不要小看这个Markdown，它本质上是一张高度结构化的岗位说明书。

一个典型的SKILL.md长这样：

--- name:>git clone https://github.com/某个/技能仓库.git /tmp/skills-temp # 把仓库里所有直接含SKILL.md的子目录复制进目标目录 find /tmp/skills-temp -maxdepth 2 -name "SKILL.md" -exec dirname {} \; | while read d; do cp -r "$d" ~/.claude/skills/ done

当然，这么批量复制的前提是确认这些技能之间没有命名冲突。要是只想装其中几个，手动复制更快。

2.2 Claude Code安装流程实操

Claude Code对skills的支持最成熟，安装路径也最清晰。我以装一个GitHub上的前端审查技能为例：

第一步，建目录并下载：

mkdir -p .claude/skills cd .claude/skills git clone https://github.com/example/frontend-review-skill.git frontend-review cd /你的项目目录

这里有一个很关键的细节：目录名最好和SKILL.md里的name字段保持一致。比如技能文件里写的是name: frontend-review，那你放技能的文件夹名最好也是frontend-review。不一致会导致显式调用的时候找不到。

第二步，确认技能结构正确：

tree .claude/skills/frontend-review # 应该是： # .claude/skills/frontend-review/ # ├── SKILL.md # └── scripts/ # └── review.py

第三步，在Claude Code对话里测试。显式调用的方式是在输入框里输入#frontend-review，后面跟你的需求。比如：

#frontend-review 审查一下 src/components/UserCard.tsx 这个组件的代码质量

Claude Code就会强制加载这个技能，按照SKILL.md里的流程走，而不是等你描述需求让它自己判断。

第四步，如果你想增加一个额外的技能目录（比如仓库里技能太多不想平铺，而是保持原来的目录结构），可以在.claude/settings.json中配置：

{ "skills": { "additionalDirectories": [ "~/projects/skills-repo/skills" ] } }

这样所有放在那个目录下、结构完整的技能也都会被扫描到。

提示：技能放在项目级.claude/skills目录里，只对当前项目生效；放在用户级~/.claude/skills目录里，对所有项目生效。平时开发不要什么都往用户级塞，项目相关性强的技能放项目级，通用方法论放用户级，否则几十个技能堆在一起，模型选择效率会明显下降。

2.3 Codex和OpenCode怎么装

Codex和OpenCode对skills的支持没有Claude Code那么统一，但基本思路是一致的：识别SKILL.md文件，只是默认目录名不同。

先说OpenCode。它的约定通常是在项目根目录放.opencode/skills，或者用户级配置目录下放~/.config/opencode/skills。你从GitHub下载一个技能的文件夹，放到这个目录下，然后调用方式类似@skill-name或者直接在对话里提到相关需求。OpenCode的文档更新快，具体配置项以你所用版本的README为准。

Codex的情况特殊一点。早期的Codex主要依赖AGENTS.md管理项目行为规范，对skills的支持是后来逐步加入的。社区现在最常用的温和方法是：把技能的内容合并进项目的AGENTS.md文件里。

# AGENTS.md ## 数学建模报告生成 当需要生成数学建模报告时，按以下步骤执行： 1. 读取数据目录中的所有csv文件 2. 先做数据质量检查，再建模 3. 最终输出必须包含模型评估表格和结论 ...

不过如果你用的是最新版本的Codex CLI，它也开始支持.codex/skills目录了，把GitHub下载的技能文件夹放进去即可。我的建议是：先查你本地Codex的版本和文档，确认支持哪种方式。这不算甩锅，而是这几个月工具迭代太快，写死了反而坑人。

2.4 用Git子模块管理技能版本

装一个两个技能没什么感觉，装到十个以上，更新就成了麻烦。每个星期都要去各个仓库看有没有新提交，想想就头大。

我的做法是把技能库做成Git子模块。比如我有个my-skills目录，专门用来聚合常用的外部技能：

mkdir my-skills && cd my-skills git init git submodule add https://github.com/anthropics/skills.git anthropic-official git submodule add https://github.com/obra/superpowers.git superpowers

以后更新所有技能只要跑一条：

git submodule update --remote --merge

需要哪个技能就把它从对应的子模块目录复制到Claude Code的扫描路径里，或者直接在additionalDirectories配置里指向my-skills/anthropic-official/skills。这样技能仓库和你的项目代码分离，不会污染项目历史，也不会因为某个技能仓库删库导致你的项目出问题。

3. 我实测下来值得收藏的skills清单

3.1 前端开发类：组件审查和一键重构

前端开发是skills最成熟的应用领域之一，因为前端任务的输入输出相对明确，代码就是代码，审查标准也是公开的。我常用的有三个：

第一个是组件代码审查技能。它会强制模型按"可访问性、性能、状态管理、边界情况"四部分逐项检查组件，每项都必须给出具体的行号和修改建议，不允许说"整体看起来不错"这种废话。配合Claude Code，我审查一个复杂的表格组件只需要一次#component-review调用，省掉大量来回对话。

第二个是性能审计技能。这个技能内置了LCP、INP、CLS这些Core Web Vitals的检查清单，还会指导模型用Lighthouse报告定位问题。以前我优化页面性能全靠自己列清单，现在模型会主动检查图片是否懒加载、字体文件是否压缩、长列表是否虚拟化。

第三个是响应式布局调试技能。它包含一套viewport断点测试流程，从375px到1440px逐档检查，并且会输出一份问题清单，标注"在哪个断点、哪个元素、出现什么视觉问题"。这个对移动端适配特别有用。

注意：前端技能包质量参差不齐。很多GitHub上的前端技能只写了"审查代码时使用本技能"这种空泛描述，完全没有可执行的检查项。下载前先看SKILL.md里有没有具体的检查清单，没有就是纯凑数，别浪费时间。

3.2 数学建模类：从数据清洗到论文排版

华为杯建模群里最近流传的codex skills合集我实测了几个，确实能省不少事。数学建模的痛点很固定：数据处理繁琐、模型对比麻烦、论文排版要命。

我用下来最值的是数据质量检查技能。它能自动生成一份数据探索报告，包含缺失值比例、异常值分布、字段类型建议、相关性热力图，还顺手给出预处理方案。以前这个过程至少花半天，现在基本十分钟出初稿。

其次是模型对比技能。它不直接帮你选模型，而是指导模型同时训练3~5个基线模型，用交叉验证输出统一的评估表格，最后再根据赛题需求推荐最优方案。关键是它会强制输出"为什么选这个模型"，而不是单纯比较准确率，这对建模论文的"模型选择依据"部分非常有用。

还有论文排版技能，专门处理公式和表格。它能识别模型输出的结果，自动整理成LaTeX或Markdown格式的三线表，公式编号、单位、显著性标记都给你规范好。建模比赛最后一天最缺的就是这个。

3.3 AI漫剧类：分镜、角色一致性和配音稿

AI漫剧是今年短视频赛道里杀出来的一匹黑马，相关的skills也大量出现。一套完整的AI漫剧技能库通常包含四个部分：

故事分镜技能：输入一段小说或文案，输出分镜表，每一镜包含景别、镜头描述、画面Prompt、时长建议。好的分镜技能会内置镜头语言规则，比如"对话场景用中近景交替""情绪爆发用特写"。

角色一致性技能：这是AI漫剧最核心的痛点。技能会指导模型生成角色设定卡，包含外貌特征、服饰细节、常见表情、固定风格的Prompt模板。后续所有画面生成都引用这张角色卡，避免主角每帧都换脸。

配音脚本技能：根据分镜生成配音稿，标注情绪、语速、断句位置，还会按平台习惯拆成黄金三秒的开头钩子。

成片质检技能：对照分镜脚本逐条检查成片，确认画面切换是否符合镜头逻辑、字幕是否同步、角色是否一致。

这里必须提醒一句：AI漫剧的版权问题比技术更值得重视。用skills的时候一定要确保输入是原创内容，不要拿别人的小说、剧本去跑分镜和配音，这类技能的自动化程度越高，侵权风险就越大。

3.4 常用skills源网站和仓库推荐

找skills不用到处瞎搜，我用下来最靠谱的几个渠道：

1. GitHub直接搜，关键词用SKILL.md而不是skills，因为很多技能仓库的文件名都是这个。可以配合星标排序：

   gh search repos "SKILL.md" --sort=starred --limit 30

2. Anthropic官方skills仓库，质量稳定，风格统一，适合作为写技能的标准参考。

3. superpowers，社区明星项目，作者是资深开发者，技能覆盖面广，更新频率高。它的很多技能对"如何定义触发条件"和"如何设定检查清单"都处理得很好，建议所有想学写技能的人都读一遍源码。

4. 各种awesome清单，GitHub上搜awesome claude skills或awesome agent skills，有人维护汇总列表，按领域分类。看到不错的仓库点进去再看它被谁引用过，可以顺藤摸瓜找到更多好东西。

5. 聚合站点，现在已经有一些人做了单纯的skills导航站，按前端、数据、写作、办公等分类陈列，下载方式统一是复制目录到本地。这种站点更新速度快，但质量参差，注意甄别。

4. 自己动手写一个skills，核心是触发描述和步骤边界

4.1 标准目录结构

看完几十个仓库后你会发现，好技能的结构惊人地相似：

my-skill/ ├── SKILL.md ├── scripts/ │ ├── main.py │ └── utils.py ├── references/ │ ├── example-output.md │ └── config-template.json

SKILL.md负责告诉模型"怎么做"，scripts放可执行的辅助代码，references放参考素材。为什么要这么分？因为上下文窗口宝贵。如果SKILL.md写成三千字的大长篇，模型加载技能时会消耗大量上下文，留给真正思考的空间就少了。正确的做法是SKILL.md只写流程骨架，详细代码放scripts，详细案例放references，模型需要时再去翻。

4.2 description触发词怎么写

写skill最容易犯的错误，就是description写得天花乱坠。我见过最离谱的一个是这样：

description: 一个强大的全能技能，适用于各种场景，可以大幅提升效率，让AI更好地理解和处理任务。

这种描述等于没写。模型看到它的时候根本不知道什么时候该用，结果就是要么永远不触发，要么乱触发。

我写description的经验是遵循三段式：任务类型 + 触发条件 + 排除条件。

description: 数据清洗技能，用于数学建模、数据分析和机器学习场景。当用户提供数据集、要求处理缺失值或异常值、检查数据质量时使用。不适用于已清洗完毕的数据，不适用于纯文本处理任务。

这样模型判断起来非常快：用户说"帮我看看这个csv怎么全是空值"，触发；用户说"帮我写Python脚本处理Excel"，部分匹配，看输入格式是否满足；用户说"帮我写首诗"，完全不匹配，不加载。

4.3 执行步骤必须带边界条件

SKILL.md的执行步骤部分，不是把流程写出来就行，关键在于每一步都要有判断边界。

比如我写前端审查技能时，其中一步是这样的：

## 执行步骤 1. 识别组件类型 - 如果是有状态组件，检查useState/useReducer的使用是否合理 - 如果是纯展示组件，跳过状态检查，直接检查props类型和默认值 - 如果两个条件都不满足，输出"组件类型无法识别，请补充说明" 2. 检查事件处理 - 每个事件处理函数必须有错误处理 - addEventListener必须在组件卸载时移除 ...

为什么要强调"如果...否则..."？因为模型最擅长的是顺着惯性走，最怕的是面对意外情况时自己编造逻辑。你给它明确的边界条件，它就能稳定地在正确轨道上执行。没有边界条件，它可能对一个纯展示组件去检查状态管理，然后信心满满地输出一堆不存在的"问题"。

4.4 调试技能的正确姿势

自己写的技能，前几次运行大概率不会让你满意。我调试技能的流程是这样的：

1. 强制触发：用#my-skill直接调用，不要依赖模型自动触发，这样能排除触发判断的干扰，专心看执行逻辑。
2. 跑最小用例：准备一个最简单、最典型的测试输入，看输出是否符合预期。
3. 构造边界用例：故意输入一个不该触发该技能的任务，看它是否会在步骤里做出合理判断。
4. 修改后重开会话：技能的修改要生效，建议重新打开Claude Code会话，或者至少用/clear清空上下文。因为同一会话里模型可能已经把旧规则缓存住了，实测中改完不重开会话，经常出现"改了跟没改一样"的情况。

5. 装得多踩坑也多，常见问题排查实录

5.1 skill一直不生效

最让人崩溃的就是技能装好了，目录结构没问题，但模型就是不按技能干活。排查顺序我总结成一套：

1. 检查目录层级。必须是skills目录/技能名/SKILL.md这个三级结构，技能名和SKILL.md之间不能多套一层。很多人把整个git仓库clone下来直接丢进skills目录，多了一层包壳，工具根本扫描不到。

2. 检查front-matter格式。name和description必须是YAML格式的键值对，少闭合引号、缩进不对都会导致解析失败。快速验证方法：用Claude直接读一下SKILL.md，问它能不能识别这个技能的名称和触发条件。

3. 检查description质量。如果技能描述里全是"强大的""高效的""各种场景"这种词，模型大概率不会自动触发。先用#技能名强制调用，如果强制调用能生效、自动触发不生效，十有八九是description的问题。

4. 确认版本支持。用的是旧版Claude Code或者独立构建的Agent终端，可能根本不支持skills目录扫描，可以升级到最新版再试。

5.2 上下文窗口被技能描述塞爆

我碰到过一个场景，项目里装了二十多个技能，每次对话都感觉模型"变傻"了，回答明显变慢，还经常忘记前面交代的任务。后来排查发现，是某个技能仓库里的SKILL.md写了八百行，模型每次决策时都要把二十几个技能的摘要过一遍，再加上那个超长技能的完整内容，上下文窗口被白白占掉一大块。

改进方案有三个：

• 精简SKILL.md，把详细内容移到references目录，正文只保留流程骨架和检查清单。
• 减少项目级技能数量，项目相关但又不是频繁用的技能，放到用户级目录，等真正需要时再手动#调用。
• 及时清理，每次项目切换后检查一下.claude/skills目录，有些技能在那个项目里根本用不上，移走或删掉。

5.3 skill之间互相冲突

装到一定数量后，你会发现两个技能的description可能覆盖了同一类场景。比如一个"数据分析技能"和一个"数学建模技能"，用户说"分析一下这份数据"，模型可能在两个技能之间犹豫，最后选了一个并不是最优的。

我处理冲突的办法是：少装大而全的技能，多装小而精的技能。如果两个技能确实边界不清，我会在其中一个的description里明确加上排除条件，比如"如果用户要求的是建模流程整体方案，请使用xxx技能而不要使用本技能"。另外，给同一类任务设置明确的优先级顺序，写在各自的description里，模型决策时会拿这个做参考。

5.4 批量清理无用skills

GitHub上技能更新很频繁，很多技能装完发现并不好用，时间一长就积累了一堆垃圾。

清理时最麻烦的是有些技能带了大量scripts文件，单个体积可能几十MB。我每个月会跑一次这个命令：

du -sh ~/.claude/skills/* | sort -h

从下往上翻，体积最大的优先检查，如果它只是带了一堆用不上的依赖脚本，果断删掉。不想彻底删除的话，把整个目录移到~/.claude/skills_disabled/，需要时再移回来，比改后缀名更干净。

社区里还有人推荐用一个专门的清理技能，通过分析使用日志统计每个技能的调用次数，把零调用的技能自动标记为禁用。这个思路很好，本质是把技能管理也交给一个skill去做。我试过，但效果一般，主要原因是日志统计的粒度不够细。目前还是手动定期清理最靠谱。

最后说一点我自己的想法。skills的价值完全不在数量，而在命中率。装三十个技能不如认真打磨三五个高频场景。看到热门仓库先别急着clone，把SKILL.md打开读一遍，如果description写的是"强大的""全能辅助"这类空泛描述，多半是无效技能包；如果里面有具体的步骤、边界条件和检查清单，才值得花时间装进去。把时间花在打磨自己高频场景的技能上，让模型"抓起来就能用"，这才是skills这套机制真正的意义。