企业官网建设流程全解析

这几天总有人问我同一个问题：Claude Code / Codex / OpenCode 里的 skills 到底怎么用？GitHub 上那些 skills 仓库，克隆下来丢进目录就报错；superpower skills 装了一大堆，结果一个都触发不了；还有人把 skills 当成提示词模板，写半天发现根本不生效。我前后折腾了小一周，踩了不少坑，终于把这条链路摸明白了。先给结论：skills 不是 prompt，也不是传统意义上的插件，它是一套“给 AI 预装的工作流程”。想明白这一点，后面安装、手写、排错都会顺很多。这篇文章把 skills 的原理、手动安装、自己怎么写、各场景推荐以及技能库整理全部过一遍，适合正在用 AI 编程助手、又烦透了每次都得重复描述流程的开发者，也适合想给团队沉淀统一工作流的同学。

1. 为什么突然都在聊skills：它补的是“临时对话提示”的短板

1.1 从一段让我抓狂的对话说起

我之前让 Claude Code 改一个前端组件，每次都得在对话里强调同一套规则：“按项目的 ESLint 规则检查”“不要动其他文件”“改完以后输出变更摘要和影响范围”。说多了模型容易忘，上下文一长就开始自由发挥，最后改出来的代码风格和项目完全不在一个频道上。

后来我才意识到，这不是模型能力的问题，而是“方法论的沉淀”出了问题。AI 对话本质上是一个无状态流程，模型再聪明，也没法在你每次说话时自动回忆起上次约定的做事方式。Skills 要解决的，就是这个事：把“做什么、按什么顺序做、做到什么程度算完、最终输出长什么样”固定成一个文件包。这样当用户用触发词唤起一个任务时，模型会主动去读这个技能的定义，按既定流程走，而不是随机应变。

1.2 Skills、提示词、插件和MCP，差在哪

很多人刚接触 skills 都会困惑：它不是提示词吗？那和插件、MCP 有什么区别？我自己做了个对比，这样看最清楚。

举个例子可能更直观。装一个“code-review”技能后，你说“帮我审查最近的 diff”，模型会加载 SKILL.md，按里面写的步骤先拉取变更文件，再逐项检查安全问题、性能隐患、命名规范，最后按固定格式输出审查报告。这不是你临时在 prompt 里写几行能稳定复现的效果，因为 prompt 没有结构，也没有强制的顺序和输出约束。

那为什么不能把所有规则都塞进 system prompt？因为模型的上下文窗口始终是有限的。你要塞的内容一多，彼此之间就会互相干扰，而且不同任务的方法论混在一起，很容易让模型在判断“当前该按哪套规则走”时出错。Skills 采用“按需加载”的方式，就像你把操作手册放在工位抽屉里，干活的时候才拿出来翻，而不是把整个柜子都背在身上。

1.3 什么场景下 skills 收益最明显

我用了这一段时间后，发现不是所有任务都适合做 skills，但下面这几类场景收益特别明显：

• 流程性强、需要稳定输出的任务，比如代码审查、周报生成、数学建模审题、LaTeX 论文排版。
• 需要调用外部脚本和工具的任务，比如数据清洗、批量文件重命名、格式转换。
• 多人在同一个仓库里协作，需要统一工作流的场景，比如团队约定好的 git 提交规范、发布检查单。
• 你自己经常做但每次都讲不清楚的私有流程，比如公司内部的数据脱敏规则、日志采集规范。

换句话说，凡是那种“我闭着眼睛都会做，但每次给 AI 讲都要费半天劲”的活，都值得花十几分钟固化成 skills。

2. 手动安装GitHub上的Skills：从下载到生效的完整链路

2.1 先搞清楚目标工具的skills目录

手动安装 GitHub 上的 skills，第一步不是下载，而是先确认你用的工具到底扫描哪个目录。我实测过几款主流工具，情况是这样的：

• Claude Code：用户级目录在~/.claude/skills/，项目级目录在.claude/skills/。项目级的优先级高于用户级，同名技能会按项目级为准。
• Codex 系列工具：不同版本差异很大，有的支持~/.codex/skills，有的要走插件机制。安装前务必先看仓库 README，别想当然。
• OpenCode：常见的是.opencode/skills，但某些版本需要在配置文件里显式注册目录。
• 各类 IDE 封装的插件市场：本质上是把技能目录挂接到配置里，你在网页端“一键安装”的按钮，背后做的也是同一件事。

关键原则是：以你要装的那个技能仓库的 README 为准。不要只克隆下来就丢，仓库作者通常会在文档里写清楚“把哪个目录放到哪个位置”。我看到很多人翻车，都是因为少看了这一步。

2.2 手动安装的标准步骤

我总结了一套通用安装流程，不管你是给 Claude Code 装还是给 Codex/OpenCode 装，都可以按这个顺序走：

1. 在 GitHub 上找到技能仓库，先看 README，确认它要求的依赖、目录结构、许可证。
2. 用git clone或直接下载 ZIP 到本地。
3. 如果是 ZIP，解压后把技能目录复制到目标目录。注意复制的是“技能名”那一层，不是“仓库名”那一层。
4. 检查一下最终路径是否符合技能名/SKILL.md这样的结构。
5. 重启你的 CLI 或编辑器会话，确保工具重新扫描技能目录。
6. 用一句触发语做验证，比如“你有哪些 skills？列出名字和触发描述”。

有人会问，网上常说的“skills 下载”“skills 网页版进入”是什么意思。我理解这些说法，本质上就是技能分发的不同形式：网页端点击安装、脚本一键克隆、包管理器安装，背后最终都会落到本地某个带 SKILL.md 的目录上。理解了这一点，你就不会被各种花哨的包装绕晕。

提示：复制目录时最容易踩的坑是路径嵌套过深。比如你克隆了一个仓库，里面是repo-name/skill-name/SKILL.md，正确做法是把skill-name这一层复制到目标目录，而不是把整个repo-name放进去。否则工具扫描不到，表现就是“装了跟没装一样”。

2.3 如何快速验证 skills 真的生效了

装完以后怎么知道到底有没有生效？我有三个很实用的办法：

• 直接问模型：“你现在可用哪些 skills？以上下文触发描述的形式列出来。”如果它能清晰列出来，说明扫描成功了。
• 用一个关键词很明确的指令去触发，比如技能里写了“周报”，你就说“根据这个 git log 帮我写一份周报”，然后观察它的回答是否在走技能定义的流程。
• 临时在 SKILL.md 里加一行“每次执行本技能时，先输出SKILL-LOADED标记”，触发后如果模型输出了这个标记，说明加载成功。验证完把这行删掉。

第三个方法我特别推荐，因为有些技能加载了但效果不明显，你分不清是没加载还是流程写得不好。加个标记一目了然。

2.4 superpower skills 这类“大礼包”为什么容易翻车

superpower skills 是社区里比较热门的一个技能仓库，里面打包了很多预设技能。但很多人装了以后发现很多技能根本触发不了，原因主要有三个：

第一，大仓库里的技能目录结构不统一。有的是skills/xxx/SKILL.md，有的还带 scripts、references 子目录；你复制的时候可能只复制了外层，技能内部的脚本路径就断了。

第二，不少技能依赖 Node.js、Python 或者额外的 npm 包。装仓库本身不等于装依赖。缺依赖的时候模型可能照常走流程，但一旦要调用脚本就会报错。

第三，很多技能之间存在作用域重叠。比如同时装了“代码审查”和“PR 检查”两个技能，描述又写得差不多，模型可能不知道触发哪个。

所以我现在的建议是：不要全量克隆 superpower skills。只把你自己真正会用到的三五个技能目录复制出来，放进你的技能目录。这样出问题了也好排查。

2.5 装完不生效？按这个顺序排查

如果你发现技能根本没被加载，别瞎改。我踩过太多坑以后总结了一套固定排查链路，按顺序走，基本能定位问题：

1. 检查目录层级：确认技能名/SKILL.md是否存在，而不是多套了一层仓库名。
2. 检查 SKILL.md 内容：文件是否完整，frontmatter（开头用---包住的元信息区）是否格式正确，name和description是否有值。
3. 检查描述覆盖范围：模型是靠 description 来决定是否加载技能的。你写的描述如果和真实触发场景不匹配，技能就永远不会被唤起。
4. 确认工具确实扫描了这个目录：不同工具对用户级和项目级目录的处理不一样，有时候项目里的同名目录会“屏蔽”用户级目录。
5. 检查文件名大小写：Linux 和 macOS 的文件系统区分大小写，如果仓库里是Skill.md而你系统里扫描的是SKILL.md，就识别不到。
6. 重启会话：很多工具是在启动时扫描技能目录的，运行过程中新增的文件不会自动生效。

这套链路我每次都能用上。尤其是最后一条，我经常忘了重启，折腾半天发现改完文件根本没重新加载。

3. 手写Skills：从SKILL.md模板到一份数学建模审题技能

3.1 最小的SKILL.md长什么样

搞清楚了安装，接下来就是自己写。其实 skill 的核心就是一个SKILL.md文件，只是它对格式和触发描述有比较严格的要求。一个最小的技能文件长这样：

--- name: weekly-report description: 当用户要求写周报、提交周报、整理本周工作进展时使用。输入可以是工作日志、git 提交记录或零散记录。 --- # Weekly Report 按时生成周报： 1. 先收集本周的时间节点、完成事项、未完成事项。 2. 按“工作内容 - 结果 - 下一步计划”的结构组织。 3. 用简洁的要点形式输出，避免形容词堆砌。 4. 输出完成后，提醒用户补充上下文和量化数据。

这里的name是技能的唯一标识，不能和已有技能冲突；description最重要，它决定模型什么时候加载这个技能，所以一定要写清楚“什么情况下用”“输入是什么”“输出是什么”。有些人写 description 只写一句话“用于生成周报”，模型在模糊场景下就可能不触发；如果写成“当用户要求写周报、提交周报、整理本周工作进展时使用”，匹配准确率会高很多。

3.2 带脚本和参考文件的skills结构

稍微复杂一点的技能，不会只有一个 SKILL.md。我常用的目录结构是这样的：

skill-name/ ├── SKILL.md ├── scripts/ │ └── process_data.py └── references/ └── examples.md

这里要特别说明，scripts和references并不是必须的，但用好它们能让技能更强大。scripts里面放的是可供模型调用的一次性脚本，比如数据清洗脚本、LaTeX 模板生成脚本；references里放的是步骤太多、SKILL.md 写不下时的详细参考资料。模型在 SKILL.md 里看到“如需深入参考，查看 references 目录下的文件”，它自己会决定要不要去读。这样能避免主文件过长，也能保证主流程的清晰。

3.3 实例：数学建模审题skills（华为杯/国赛通用）

数学建模是这几天被问得最多的场景，尤其是华为杯、国赛期间，很多人都想用 Claude Code 或者 Codex 辅助写论文和建模。我自己手写了一个“数学建模审题”技能，核心思路是把人工竞赛中的“三遍审题法”固化下来：

第一遍，逐句读完赛题文本，把题目里出现的条件、约束、数据来源全部摘出来，不遗漏任何一句隐藏条件；第二遍，把自然语言条件转换成数学语言，比如“不超过某个阈值”要变成约束条件，明确这个约束是硬约束还是软约束；第三遍，根据问题的数据规模和条件，列举候选模型并评估可行性，最后输出一份审题文档。

对应的 SKILL.md 我节选一段：

--- name: mcm-problem-analysis description: 当用户提供数学建模赛题文本、要求进行审题、拆解问题、梳理约束条件、推荐候选建模方法时使用。适用场景包括国赛、华为杯、美赛等。 ---

然后正文按步骤写：

1. 提取全部已知条件：包括数值、单位、变量符号。
2. 区分目标函数和约束条件：题目中“在……前提下”“不超过”“至少”这些字眼往往对应约束。
3. 列出所有候选模型：预测类问题优先考虑回归、时间序列、机器学习；优化类问题优先考虑线性规划、启发式算法；评价类问题优先考虑层次分析法、熵权法、TOPSIS。
4. 每个候选模型需要评估数据量是否足够、计算成本是否可接受、结果是否可解释。
5. 输出审题文档，格式包括：问题类型、已知条件、约束清单、候选模型矩阵、推荐方案。

这个技能我实测下来，能显著减少模型审题时的“漏条件”。以前 Claude Code 拿到赛题直接就开写，写着写着才发现某个约束没考虑进去；现在它必须先输出审题文档，再进入下一步，整体思路清晰很多。

3.4 写skills最容易翻车的五个细节

我自己手写了七八个技能之后，总结出五个特别容易翻车的地方：

• description 写得太泛。很多人写“用于数学建模相关任务”，结果模型在所有数学任务上都加载这个技能，反而干扰了正常讨论。正确写法是明确触发场景。
• 只给步骤不给判断条件。比如让模型做数据清洗，没写“如果某列缺失率超过 50%，停下来提示用户选择删除或填充”。没有判断条件，模型会硬着头皮继续跑，产出一个无效结果。
• 不约束输出格式。SKILL.md 里只说了“分析问题”，没说最终报告长什么样。模型每次输出的结构都不一样，后续没法自动化处理。
• 堆砌内容。一个 SKILL.md 超过 300 行以后，模型容易“迷失重点”。解决方法是把复杂的细节拆到 references 目录，主文件只留流程骨架。
• 没有版本号。技能改了两三版以后，你可能都分不清当前生效的是哪一版。我习惯在 frontmatter 里加一个version: 1.2，改动积累到一定程度就递增。

3.5 卸载和清理：别让旧技能污染技能库

有安装自然有卸载。清理技能其实很简单：直接删除对应的技能目录就行。但有几个细节需要留意。

一是项目级和用户级同名技能的问题。如果你项目里有一个.claude/skills/code-review，用户级也有一个，工具通常会加载项目级的。你想删“用户级覆盖”的把项目目录删掉才有效。

二是依赖残留。有些技能带了 scripts，删除技能目录后，它可能还留了缓存目录或者全局安装的依赖包。我见过有人删了技能，但技能脚本输出文件还在工作目录里，后续提交代码时被误提交。

三是缓存问题。部分编辑器插件会缓存技能列表，删掉目录后界面上还显示有那个技能。重启一下基本都能解决。

关于清理方法，我自己的习惯是每个月跑一次：

find ~/.claude/skills -name "SKILL.md" -type f | sort

看到所有技能清单之后，把超过三个月没使用过、又不在我核心工作流里的技能目录直接移到一个archive备用目录。这样不会误删，也能让技能库保持精简。我一直认为，技能库最怕的不是少，而是多。装了几十个技能，模型被一堆不精准的 description 干扰，触发率反而会下降。

4. 不吹不黑：几个场景下值得装的Skills清单

4.1 数学建模与竞赛：把流程变成可复用的资产

数学建模大概是这几天被问得最多的场景之一。很多人问华为杯比赛用什么 codex skills 好。我的回答是：不如你自己写三个固定技能。

数模比赛本质上拼的是流程标准化。第一天审题、第二天建模、第三天写论文，每多一个环节出岔子，后面全崩。我推荐固定三件套：审题拆解技能、LaTeX 论文写作技能、数据清洗技能。审题拆解对应我前面写的mcm-problem-analysis；LaTeX 写作技能负责把结果按竞赛模板排版；数据清洗技能负责处理赛题附带的 Excel 或 CSV 数据。

为什么我觉得现成的数模技能不如自己写？因为现成技能包含的泛化步骤太多，很多是用“通用模板”糊出来的，没有针对具体赛题类型做优化。你只需要结合自己常用的模型，写清楚判断条件和输出格式，效果往往比网上的通用技能包要好。

4.2 前端开发与typesafe类skills

前端开发是另一个热门场景。热词里的“前端开发 skills”和“typesafe ai skills github”其实是同一类需求：希望 AI 生成代码时符合项目的类型约束和风格规范。

Typesafe AI 的 skills 库我看过，思路挺好的：它通过给模型提供类型系统的上下文和规则，让 AI 生成的 TypeScript 代码避免随手写any、避免破坏 API 边界。这个在多人仓库里尤其有用，因为不是你一个人在用 AI 写代码，如果每个人生成的代码风格不统一，后面会很难维护。

前端场景我推荐固定装这几个类型：TypeScript 类型修正、React 组件生成、无障碍（a11y）审查、样式命名规范。装的时候注意一点：这类技能最好放在项目级目录，因为每个项目用的技术栈和 lint 规则不一样。放在用户级目录会干涉所有项目，可能适得其反。

4.3 AI漫剧与其他创意生产skills

AI 漫剧是最近一个很有意思的应用方向。它本质上是用 AI 生成分镜脚本、角色描述、画面提示词，然后交给视频生成工具出片。这类工作我很推荐做 skills，因为它的流程高度固定，而且每一步的输出格式都非常重要。

一个完整的漫剧技能，可以定义成这样的流程：先根据剧本生成分镜列表，每个分镜包含镜头序号、景别、画面内容、角色状态、光线与情绪、镜头时长；再为每个分镜生成一段可供视频模型使用的提示词；最后输出一个素材清单，方便后续剪辑。关键点是：分镜表格的字段必须固定，否则后面没法批量导入其他工具。

我自己写过类似的分镜技能，最深的一个体会是：模型自己生成的分镜列表看起来很好看，但往往没有给“每镜头时长”这种关键字段。你必须在 SKILL.md 里写死“每个镜头必须标注预估时长，且所有镜头时长总和等于剧本目标时长”。这种约束，恰好是 skills 比其他方式更适合表达的内容。

4.4 那些名字很酷的库：cola skills、codex nature skills怎么看

网上偶尔能看到一些名字很酷的技能库，比如 cola skills、codex nature skills 之类。我的态度比较保守：不要迷信库名和 star 数。

判断一个技能库值不值得装，我只看三个标准：第一，仓库作者是否持续更新，超过一年没动静的基本可以放弃；第二，SKILL.md 是否人工编写且结构清晰，如果打开发现里面全是煽动性的“你就是顶级专家”式 prompt 而不是操作流程，直接跳过；第三，依赖是否声明清楚，没有 dependencies 说明的技能，多半装完就跑不起来。

我把这些库分成三类：官方示例库、社区精选库、个人实验库。官方示例库适合学习结构；社区精选库适合直接使用，但必须筛选；个人实验库，除非你时间很多，否则不建议在生产环境里装。

5. 常用源、个人技能库与长期维护

5.1 可靠的Skills获取渠道

很多人第一个问题就是“去哪找 skills”。我现在常用的渠道有这几个：

• GitHub 搜索：直接搜awesome-claude-skills、claude-skills、codex-skills、opencode-skills，按“最近更新”排序，比按 star 排序更靠谱。
• 官方示例仓库：Anthropic 官方维护过一些 skill 示例，结构规范，适合学习。
• Typesafe AI 的 skills 仓库：偏 TypeScript 生态，适合前端团队。
• 各类聚合网站：本质上也是从 GitHub 抓数据，作用类似导航站。

无论是哪个渠道，我都会在拿到技能后，先打开 SKILL.md 读一遍再安装。这一步能省掉后面大量的排查时间。因为很多技能包里的 SKILL.md 是 AI 生成的，看起来完整，实际没有可执行的判断条件，装了也是摆设。

5.2 判断一个技能库值不值得装

我总结了一个简单的评估表，分享给大家：

表格里的最后一条很多人不看，但很重要。没有 license 的代码，你用了以后在合规上会非常被动。

5.3 我的个人技能库目录约定

用了一段时间 skills 以后，我把自己常用的技能按领域分目录维护，结构大概是这样的：

~/.claude/skills/ ├── coding/ │ ├── frontend-ts-fix/ │ └── code-review/ ├── data/ │ ├──>