企业官网建设流程全解析

先问自己一个直白的问题：同一个 AI 编程助手，为什么有人用着像带了十年默契的老搭档，有人却觉得它笨得只会空泛附和？差别通常不在模型本身，而在一个很容易被忽略的配置——Skills。

这正是 Claude Code、Codex、OpenCode 这些工具上线以来最值得花时间研究的模块。你给它一套标准作业流程，它就能在数学建模、前端开发、数据清洗之类的具体场景里按套路干活；你不给，它就只能靠通用知识随机发挥。这篇内容就是把这套东西彻底捋清楚：Skills 到底是什么、怎么手动把 GitHub 上现成的 Skills 装进本地、怎么写自己的 Skills、以及从哪找到靠谱的 Skills 资源库。

1. 先搞明白：AI编程里的"Skills"到底是什么

1.1 从"会聊天"到"会干活"的临门一脚

最早用 AI 写代码的人都有过这种经历：明明给了大模型一堆上下文，它还是东一榔头西一棒子，问一句答一句，稍微复杂点就忘前面说好的约定。问题不在于模型不够聪明，而在于你只给了它"目标"，没给它"流程"。

Skills 解决的就是这个断层。本质上，Skills 是一组预先定义好的指令文件，里面写清楚了当 AI 接收到哪类请求时，应该按照什么样的顺序、采用什么样的方法、输出什么样的格式来完成工作。它不是一个宏命令，不是一段提示词，而是一个带有元信息（触发条件、名称、描述）的完整工作流说明书。

我做了一个很朴素的比喻：Skills 就像你给刚入职的实习生发的一本岗位 SOP 手册。实习生本身可能很聪明，但不知道你们团队规定的日报格式、代码风格、交付流程；你把 SOP 塞给他，他立刻能按你们的规矩产出东西。AI 工具内置的通用模型能力就是那个实习生，Skills 就是那本 SOP。

1.2 Skills、提示词和 MCP 到底有什么不同

这块经常有人混在一起，我讲个明白。

提示词是什么？提示词是你在对话框里输入的那段话，是一次性的、针对当前对话的临时指示。你换了新对话，它就没了。Skills 是持久化的文件，放在固定目录里，每次启动工具都能加载，它是可复用、可分享、可版本管理的资产。

那 MCP 又是什么？MCP（Model Context Protocol）解决的是 AI 连接外部工具的问题，比如让 AI 能访问你的文件系统、查询数据库、调用 API，相当于给 AI 装了"手"。而 Skills 解决的是"怎么做"的问题，相当于给 AI 装了"大脑里的流程模板"。一个是接设备的接口协议，一个是业务流程的标准化模板，两者不冲突，经常搭配使用。一个完整的 AI 编程环境里，MCP 负责"能碰哪些东西"，Skills 负责"碰的时候按什么章法来"。

现在社区里流传的那些名字——前端开发 skills、superpower skills、codex nature skills——本质上都是别人写好的这种 SOP 文件包。superpower skills 是一个帮你管理这些技能包的平台工具，codename skills 则是不同 AI 工具对应的官方或社区技能仓库名称。理解了这个基础概念，后面所有操作都能串起来。

2. 手动安装 GitHub 上的 Skills：保姆级实操

2.1 安装前的准备：确认你用的工具

先别急着 git clone，第一步是搞清楚你的 AI 编程工具读哪个目录。不同工具的 Skills 目录规范不一样，装错位置是最常见的翻车原因。

目前主流的几款工具：

• Claude Code：默认读取~/.claude/skills/目录，每个 Skill 占一个子目录，子目录里必须有SKILL.md主文件
• Codex（OpenAI 的 CLI 工具）：有自己独立的 skills 目录规范，通常在~/.codex/skills或项目级.codex/skills
• OpenCode：社区驱动，目录规则比较灵活，通常在~/.config/opencode/skills

你可以在官方文档里查确认，也可以直接在终端输入工具名带 help 参数。我个人的建议是直接看官方文档，因为这类工具迭代很快，目录路径经常会变，过时的博客资料反而会误导你。我踩过一次坑，照着三个月前的教程把 Skill 丢进旧目录，工具愣是没反应，最后发现新版改了路径。

2.2 三种手动安装姿势详解

第一种：git clone 直接拉取

这是最推荐的方式，因为后续更新方便。假设你已经找到了一个想要的 Skill 仓库，比如某个数学建模辅助 Skills：

cd ~/.claude/skills git clone https://github.com/example/math-modeling-skill.git

clone 完成后，检查一下目录结构是否正确：~/.claude/skills/math-modeling-skill/SKILL.md。很多人在这一步翻车——clone 下来的仓库里可能有个嵌套目录，实际文件在子文件夹里。你要确保SKILL.md文件的位置与 skills 根目录之间正好隔着一层子目录。

第二种：下载 zip 解压复制

有些仓库没有用 git 管理，或者你只想要某个仓库里的单个 Skill 文件夹。那就直接下载 zip，解压后把包含SKILL.md的那个文件夹整个复制到 skills 目录：

unzip skill-pack.zip -d ~/.claude/skills/

注意：不要只复制 SKILL.md 文件本身，必须是整个文件夹。Skills 的识别粒度是文件夹级别，里面除了 SKILL.md 还可以有参考脚本、模板、示例数据，这些辅助文件通过相对路径被主文件引用。

第三种：用管理工具代劳

现在社区里比较火的 superpower skills 就是干这个的。它提供一个交互式命令行界面，让你像逛应用商店一样浏览、安装、更新 Skills。用这类工具的优点是省事，缺点是你得先花时间把管理工具本身配置好。

我自己三次实操下来的经验是：手动安装一次，能让你把整个机制彻底搞明白。管理工具更像是锦上添花；如果你连 Skills 目录在哪、SKILL.md 长什么样都不知道，直接用管理工具，出了问题你会完全不知道怎么排查。手动装两三个之后，再上管理工具，心态就完全不同了。

2.3 安装完怎么验证生效

装完之后别急着用，先验证三件事：

1. 路径对不对——回到 skills 根目录，确认文件层级符合skills/技能名/SKILL.md
2. 格式对不对——打开 SKILL.md，看头部有没有正确的 YAML frontmatter，至少有name和description字段
3. 工具识不识别——重启你的 AI 编程工具，输入/skills或等价命令，看看列表里有没有出现新装的名字

有些工具支持热加载，不需要重启；但如果你不确定，老老实实重启一次最安心。我见过不少人装完发现没生效，折腾半天结果是没重启进程。

验证通过后，可以随便给 AI 一个对应场景的请求，比如装了数学建模 Skill 就丢一道简单的建模题，观察 AI 的输出风格是否符合 Skill 里规定的流程。如果 AI 答得跟没装一样，八成是 description 里的触发词没写好，这个留在第 5 章细说。

3. 自己动手写一个 Skills：从零开始

3.1 SKILL.md 文件结构拆解

先看一个最简示例：

--- name: math_modeling_assist description: 用于数学建模竞赛的辅助技能。当用户提出建模问题、要求模型分析、需要论文写作建议时使用。 --- # 数学建模辅助 ## 使用场景 - 用户给出一个数学建模赛题 - 用户询问模型选择建议 - 用户需要论文结构优化 ## 工作流程 1. 分析问题背景，提取关键约束 2. 将问题归类到常见模型类型 3. 推荐合适的模型并解释理由 4. 给出求解步骤和工具建议 5. 输出论文写作要点 ## 输出格式 - 问题分析 - 模型选择 - 求解方案 - 论文片段

这个骨架包含三部分：头部元数据、触发描述、工作流程和输出要求。别小看这个结构，写得好不好，直接决定这个 Skill 被 AI 调用的频率和效果。

头部元数据是灵魂。name是这个 Skill 的唯一标识，description是告诉 AI"什么时候该用我"的关键。description 写得太泛，比如"帮助解决数学问题"，AI 碰到任何数学相关的对话都会尝试调它，结果就是每个请求都被这个 Skill 干扰；写得太窄，比如"只处理华为杯A题第一问"，那 AI 永远不会在别的场景想起它。好的 description 要写出触发条件和适用边界：在什么场景下、用户提出什么类型的问题时启用。

正文部分要遵循"可执行、可验证"原则。你写的每一步流程，AI 得能照着做。不要写"深入分析问题"这种废话，要写"先列出题干中的所有约束条件，再逐一判断属于硬性约束还是软性约束"。具体到什么程度？到 AI 不需要猜你意图的程度。

3.2 实战：写一个数学建模辅助 Skill

以数学建模这个高频场景为例，完整走一遍创作过程。

首先想清楚这个 Skill 要解决什么问题：很多参赛队伍用 AI 辅助建模，但 AI 给的方案往往太通用，缺少数模竞赛特有的套路——模型假设要怎么写、灵敏度分析怎么做、论文排版有什么竞赛规范。这个 Skill 就是要把这些经验固化下来。

我实际写的版本里有这样的内容（节选）：

--- name: math_modeling_competition description: 面向数学建模竞赛（含华为杯、国赛、美赛）的完整辅助技能。当用户提供赛题、ASK模型推荐、需要论文结构优化或求解指导时使用。 --- ## 解题全流程 1. 赛题理解：拆解问题为子问题，标注数据类型与缺失信息 2. 模型初选：根据问题特性匹配模型池（优化模型、预测模型、评价模型、微分方程模型） 3. 模型细化：说明为什么选这个模型、有什么假设、验证数据是否满足 4. 求解工具：推荐使用 Python 的 numpy/scipy/pandas，必要时使用 scikit-learn 或 cvxpy 5. 验证与敏感性分析：变化关键参数，观察结果稳定性 6. 论文框架：按照摘要、问题重述、模型假设、模型建立与求解、模型检验、评价与改进的顺序组织

关键在于第 4 步的求解工具和代码片段。Skills 里的内容越贴近真实操作越好。我还写了几个常用模型的 Python 代码模板，放在同一个 Skill 目录下的scripts/文件夹里，然后在 SKILL.md 里用相对路径引用它们。这样 AI 在调用时可以直接读取模板，不用现场编代码，准确率提升非常多。

3.3 开发中的几个关键细节

版本管理。Skills 本身就是文本文件，最适合用 git 管理。我自己的习惯是给每个 Skill 建一个独立仓库，或者至少在一个总仓库里按目录分开。这样改坏了能回滚，也能方便分享给别人。

测试迭代。写完一个 Skill 并不算完，要在真实场景里压测。我会准备 3 到 5 个典型问题，逐个丢给 AI，观察它是否走对了流程、输出是否符合要求。发现问题就回编辑改描述或流程，改完再测。这个过程非常像调试程序，只不过调试的对象是"指令流程"而不是"代码逻辑"。

不要贪多。刚开始写 Skills 的人最容易犯的毛病是一个 Skill 里塞进一堆不相关的场景。比如数学建模和漫剧脚本写作完全不搭界，却硬塞进同一个 Skill，结果 AI 每次调用时都要解析一大段无关内容，响应速度变慢，关注度也被稀释。一个 Skill 只解决一类问题，这是铁律。

4. 按场景挑 Skills：数学建模、前端开发与资源渠道

4.1 数学建模与竞赛场景

数学建模是当前 Skills 需求最旺盛的场景之一，尤其华为杯这种赛事期间，各大高校队伍都在求好用的技能包。一个合格的数模 Skill 至少要覆盖四个环节：

• 模型库导航：把常见的优化模型、预测模型、评价模型分门别类，并注明每种模型的适用前提、所需数据量级、典型应用场景
• 代码生成规范：生成整洁的 Python 代码，带注释，变量命名规范，直接能跑
• 论文写作模板：符合竞赛评审偏好的论文结构，摘要写法、图表引用格式、公式排版
• 可视化风格统一：一套图表生成逻辑，统一配色、字体、标注风格

社区里有些现成的数模 Skills 做得相当不错，但要注意甄别。很多所谓的"数模大礼包"其实就是把一些通用 Prompt 打包了一下，挂个 Skills 的名头。判断标准很简单：打开 SKILL.md 看一眼，如果里面只是大段的宏观指导而无具体的操作流程和模板代码，那多半是水货。

4.2 前端开发场景

前端开发是另一个高频场景。好的前端 Skills 应该解决这些问题：

• 组件开发流程标准化：需求拆解、组件结构设计、状态管理方案选型、样式规范、测试用例编写
• 框架特定的编码规范：React 项目就规范 hooks 的使用规则，Vue 项目就强调组合式 API 的组织方式
• 性能优化的排查路径：从网络请求、渲染计算、打包体积三个维度给出排查顺序和优化手段

我用过的前端开发 Skills 里，实用性最强的是那些带有详细代码模板和检查清单的。比如一个 React 组件开发 Skill，它会先要求 AI 确认 props 接口设计，再生成组件骨架，然后补全样式，最后检查是否有性能隐患。这套流程能把 AI 生成的代码质量提升一个档次。

4.3 如何找到靠谱的 Skills 源网站

这个问题几乎是所有人问过我的："Skills 去哪找？"我的筛选顺序如下：

1. GitHub 搜索是最直接的方式，搜 "awesome skills"、"claude skills" 这类关键词，会有一堆聚合仓库
2. 官方文档列出的社区仓库，质量经过初步筛选，比较可信
3. 技术社区的热帖：一些资深开发者会在博客或社区分享自己写的 Skills，附带使用说明，这类通常实战性很强

筛选时看三个指标：stars 数量、最近提交时间、SKILL.md 内容的密度。stars 高但三个月没更新，可能已经不适配新版工具；SKILL.md 全是泛泛而谈的空话，stars 再高也说明只是被打包推荐过，实际成效未必好。

这里特别提醒一点：安装陌生 Skills 前，务必打开 SKILL.md 和目录里的脚本文件看一眼。Skill 本质上是可执行指令，如果里面有下载未知文件、读取敏感路径、让 AI 输出异常内容之类的操作，说明这个 Skill 可能是不安全的工具。毕竟 Skills 是社区生态，质量参差不齐，安全意识不能丢。

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

5.1 装了不生效：先按这三个顺序查

这个问题占我遇到问题的七成。排查顺序有讲究，不要乱试。

第一步，查目录结构。在终端里执行：

find ~/.claude/skills -name "SKILL.md"

看看输出结果的目录层级是否完全正确。如果文件在~/.claude/skills/xxx/yyy/SKILL.md，中间多套了一层，工具就识别不了。把多余的嵌套目录去掉即可。

第二步，查 frontmatter 格式。打开 SKILL.md，看头部有没有用---包裹的 YAML 块，name字段是否为字母数字加下划线。最常见的问题是我见过有人description里写了带冒号或引号的特殊字符，导致 YAML 解析失败，整个文件被跳过。

第三步，查 description 的触发词。这一步最隐蔽。哪怕目录和格式都正确，如果 description 里没有覆盖用户可能表达的自然语言，AI 就不会调用这个 Skill。比如你的 description 写的是"用于数学建模竞赛"，用户问的是"帮我看看这道优化题怎么办"，两者语义相关但字面引用度不高，AI 可能就选了别的方案。解决方案是把触发场景扩展，多写几个同义触发句："数学建模、优化问题、竞赛解题、论文结构优化"。

5.2 权限、路径冲突这类脏活

如果你用的是公司电脑或受管系统，Skills 目录可能没有写权限。报错信息往往是Permission denied或者工具根本无法读取。解决办法是检查目录属主：

ls -ld ~/.claude/skills

如果属主不是当前用户，用sudo chown -R 当前用户名:当前用户组 ~/.claude/skills改回来，或者干脆把技能目录移到用户完全可控的路径并更改工具配置。

还有一种情况，就是同时装了多个流程类似但内容不兼容的 Skills。比如一个 Skill 要求 AI 输出 Python 代码用 numpy 风格，另一个要求用 pandas 风格，AI 就会陷入选择困难，输出摇摆不定。这属于叠加冲突。解决办法是合并同类项，只保留最适合的版本，或者把不同场景用更明确的 description 区分开。

5.3 清理和更新 Skills 的正确姿势

Skills 装多了也是一个麻烦。年初我装了一堆热门的，结果单次会话加载耗时明显变长，而且 AI 频繁在几个相似 Skills 之间跳来跳去，效率反而下降。后来看了社区大牛 tibo 分享的清理思路，然后实践了一套自己的方法：

• 每三个月做一个全量盘点，列出所有已安装 Skills
• 统计每个 Skill 在过去一个月的实际触发次数
• 触发次数几乎为零的，先停用观察而不是立即删除，确认没用再删
• 更新用git pull拉取对应仓库最新代码

很多人忽略的一点是：清理 Skills 不只是删目录，还要注意工具自身的缓存。有些工具会把 Skill 索引缓存到内存或本地文件，删除目录后列表里还显示着旧名字。重启工具通常能解决，实在不行就清一下工具的缓存目录。

关于更新策略，我的建议是别盲目追新。如果当前 Skill 用得稳定可靠，哪怕社区出了新版本也不必急着升。先看 changelog，确认更新内容确实是自己需要的，再动手。升级带来新 bug 这种事，在 Skill 生态里同样发生过不止一次。

个人经验分享

回过头看，我把 Skills 踩通的路径大概是：先手动装了五六个社区优秀的包，拆开看它们的 SKILL.md 是怎么写的；然后模仿着一个最简单的"输出格式化"需求写了自己的第一个 Skill；再往里面叠加真实业务流程、代码模板、验证清单。这个过程走了差不多一个月的业余时间，但换来的是之后每次写代码、做建模、处理数据，AI 生成的产出都稳定在一个很高的基准线上。

如果你刚开始接触，我把这些内容里最值得操作的部分划个重点：先确认自己的工具读哪个 Skills 目录，去 GitHub 上找一个高质量的现成包手动装一次，全程走完你就不会再有任何困惑。等手工流程熟练了，再考虑用 superpower skills 这类管理工具批量安装和更新。最后留一个建议给你——从今天开始，把你每次重复交代 AI 的工作流程，逐步沉淀成自己的私有 Skills。这可能是你在 AI 编程上做的最划算的一笔长期投资。