企业官网建设流程全解析

看到“skills”这个热词挂在榜上，说实话我第一反应是：又一个概念要被讲烂了。但仔细翻了翻大家搜的东西——前端开发skills、Claude Code怎么手动装GitHub上的skills、华为杯建模比赛好用的codex skills、免费源站——我发现这波热度跟以往不一样，大家不是在追新概念，而是真的在干活时遇到了问题：装了skill没生效、官方源里找不到想要的、自己写的skill模型不理人。

这篇文章就把我这两三个月折腾skills的经验完整写出来。我会从“skills到底是个什么东西”讲起，然后给出手动安装、白嫖好用的源站、自己动手编写、按前端/数学建模/漫剧这几个场景搭配的完整方案，最后附一份踩坑排查清单。不管你是刚听说这个词，还是已经装了一堆skill但用不起来，都能找到对应的解决办法。

1. 先搞清楚：skills到底是什么，为什么大家都在装

1.1 从“问一句答一句”到“把经验打包成技能”

先说人话。你平时用AI编程工具（Claude Code、Codex、OpenCode这类），本质上是在跟模型对话：你交代任务，模型现场想怎么干。问题是，模型再聪明，它对“你这个项目的目录结构”“你们团队代码规范”“上一次踩坑总结出来的流程”一无所知。所以你会发现，同一个任务，你描述得越详细，它干得越好；你懒得描述，它就给你一堆正确但没用的泛泛之谈。

skills要解决的问题就是这个——把一套固定的、验证过的工作流程打包成一个文件包，让AI在接到相关任务时自动加载这套流程，而不是每次从零现想。

我举个最直观的例子。你写前端项目，想让AI帮你review代码。不说skills，你得敲一大段：检查哪些文件、注意哪些规范、输出什么格式的报告。有了skills，你只需要在项目里放一个code-review的skill，定义好“检查代码规范、找出性能隐患、给出修改建议、输出Markdown报告”这整套流程。下次你只要说“帮我review一下登录模块”，AI就会自动调用这个skill，按你预设的套路干活。

1.2 skills、提示词、MCP，这三者到底什么关系

很多教程把skills和MCP混在一起讲，实际上它们是两个层次的东西。

• 提示词（Prompt）：一次性指令，说完就完了，不保存也不复用。
• Skills（技能）：结构化的持久化指令包，告诉AI“接到这类任务时，按这套流程做”，通常包含说明文档、示例、甚至可执行的脚本。
• MCP（Model Context Protocol）：一个标准化协议，让AI能连接外部工具和数据源，比如读数据库、调API、操作浏览器。

简单类比：提示词是“你口头跟我说一遍怎么干”，skill是“你给我一本带模板带例子的操作手册”，MCP是“把工具间的接口统一成USB口，插上就能用”。三者可以配合，skill里完全可以写“调用某个MCP工具来完成某一步”。但如果你只想让AI按你的一套流程干活，不需要外接任何服务，那一个skill就够了，不用上MCP。

1.3 一个成熟的skill到底长什么样

我在GitHub上扒了不少star数高的skill，它们的结构基本一致。这里拿一个前端代码审查skill举例，你在.claude/skills/code-review/目录下会看到：

code-review/ ├── SKILL.md # 核心文件，告诉AI这个skill是干什么的、怎么执行 ├── reference.md # 可选的参考资料，比如团队的代码规范细节 └── assets/ # 可选的辅助文件，比如示例代码、模板

SKILL.md是整个skill的“大脑”，用带frontmatter的Markdown格式写。frontmatter里至少要有name和description，其中description是决定AI什么时候激活这个skill的关键。

--- name: code-review description: 用于对前端项目代码进行系统性审查，检查代码规范、性能隐患、可维护性问题并输出审查报告。当用户要求review代码、检查代码质量、查找bug时使用。 --- # Code Review 技能 ## 适用场景 ... ## 执行步骤 1. 先读取项目中的 package.json 确认技术栈 ...

后面我会专门用一整节讲怎么自己写skill，这里先让你心里有个底：skill不是一个神秘的东西，它就是一套组织良好的Markdown文件加脚本。

2. 手动装一个GitHub上的skills，保姆级流程

很多刚入门的朋友卡在第一步：从GitHub上看到了一个不错的skills仓库，但不知道往哪儿放、怎么让工具认出来。其实手动安装非常简单，核心就是把skill文件夹放进工具指定的目录。

2.1 先确认你的工具支持哪种格式

虽然各家都管自己那套叫“skills”，但目录位置和格式略有区别。

• Claude Code：支持Anthropic官方的Agent Skills格式，个人级目录是~/.claude/skills/，项目级目录是.claude/skills/。
• Codex（OpenAI的命令行工具）：也支持skills概念，安装目录可能是~/.codex/skills/。
• OpenCode：社区版的AI编程工具，同样支持skills目录，具体路径取决于版本，一般在~/.opencode/skills/或项目下的.opencode/skills/。

不确定的话，最好的办法是直接看工具的官方文档，或者在你项目的配置文件里搜一下“skills”字段。不过大多数情况下，认准“skills文件夹放在用户的主目录下”这个规律，基本不会错。

2.2 手动安装的完整步骤

第一步，把整个仓库克隆下来或者直接下载ZIP包。GitHub上很多skills仓库是一个仓库里包含多个skill，比如官方那套示例skills就是这种结构。你要做的是找到其中单个skill的文件夹，不是整个仓库。

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

你会看到类似这样的目录结构：

某个-skills仓库/ ├── code-review/ ├── test-generator/ └── ...

第二步，把需要的那个skill文件夹复制到对应目录。以Claude Code为例：

mkdir -p ~/.claude/skills cp -r code-review ~/.claude/skills/

如果你只想在某个项目里用这个skill，就放到项目的.claude/skills/下。项目级目录优先级高于个人级目录，也就是说同一个skill，项目里那份会覆盖全局那份。

第三步，重启你的工具。Claude Code、Codex这类命令行工具一般需要重启会话才能加载新的skill。重启后，你在对话里输入斜杠命令，应该能看到skill列表了。

/skills

如果列出来了，说明安装成功。这时候你随便发一个能触发该skill的任务（比如“帮我review一下当前模块”），AI就该按skill里定义的流程执行。

2.3 网页版和命令行工具的安装差异

有人问“skills网页版怎么进入”，实际上现在大多数工具的网页版（比如Claude.ai网页端）会默认加载云端配置好的skills，不需要你手动装。你要在网页版用自己装的skill，通常需要先跟工具账号体系同步——常见做法是通过GitHub同步配置，而不是直接在网页端上传文件夹。我的建议是：如果只是自己玩，用命令行工具最直接；网页版更适合体验官方已经集成好的skill。

还有一点要提醒，GitHub上有些skill仓库会附带自己的安装脚本，比如install.sh或者Makefile。如果你看到这类文件，优先跑它，能少踩很多坑。

3. 好用的skills源网站、推荐清单与下载心得

GitHub上skills仓库现在可以说是“万物皆可skill”，但质量参差不齐。有些仓库几百个star，打开一看就是篇博客改了个名。我花了好几个晚上扒了无数仓库，筛出了真正值得用的几个来源。

3.1 我实测过比较靠谱的几个地方

• Anthropic官方skills仓库（anthropics/skills）：这个是我默认推荐的首选。里面的skill虽然数量不算多，但都是精品，文档规范、示例完整，特别适合拿来学习skill该怎么写。它不是让你直接用，更像是一套“标准教科书”。

• 社区聚合仓库（superpower skills之类）：目前社区里流传比较广的一个合集，特色是把常用工作流都做成了skill，文档质量和覆盖范围平衡得比较好。我实测过里面几个文档处理、代码生成的场景，能达到“开箱即用”的程度。但这类仓库更新快，偶尔会出现依赖老版本工具的情况，装之前留意一下README里的更新时间。

• Awesome-skills类列表：这类不是skill本身，而是把散落在各处的skills仓库汇总成一个清单。好处是你可以在一个地方发现大量不同方向的skill，坏处是需要自己筛选。我的策略是只挑“近三个月有更新”的仓库，长期不更新的基本就当它死了。

3.2 怎么判断一个skill值不值得装

这里提供几个判断维度，都是我踩过坑后总结的：

还有一条捷径：看issue区。如果一个仓库的issue里有真实的bug报告和作者回复，说明它真的有人在用，值得一试。全是僵尸issue的仓库，直接跳过。

3.3 装多了之后，清理和维护同样重要

我现在看到不少朋友一上来就装几十个skill，结果AI经常“乱触发”——明明只需要一个简单操作，它非要调一个复杂skill去干。这时候就需要做减法。

清理的逻辑很简单：进skills目录，把不要的文件夹删掉或者挪到备份目录。这个我们后文单独说。我自己习惯是只保留三类——正在用、觉得不久会用到、用来学习借鉴写法的。其余的全部删除。

另外提醒一句：skill不是越多越好。AI在每次任务时都要扫描所有skill的描述来决定要不要触发，装太多描述又写得不好的skill，反而会干扰判断。精简到十个以内，你会明显感觉响应质量提升。

4. 自己动手写skills：从“会用”到“会造”

装了几个月别人的skill之后，我越来越有一个感受：真正好用的skills，永远是自己写的那几个。因为只有你知道自己的项目规范是什么、自己的团队习惯是什么。而且写skill这件事本身没那么玄学，一旦掌握方法，写一个能满足自己需求的skill用不了半小时。

4.1 SKILL.md的核心结构，拆开揉碎了讲

一个标准的SKILL.md长这样：

--- name: skill名（小写加横杠） description: 一句话说清楚这个skill干什么用、什么场景下触发 --- # 技能名称 ## 适用场景 ... ## 工作流程 1. 步骤一... 2. 步骤二... ## 注意事项 ...

拆解一下核心部分：

frontmatter的name和description是重中之重。AI靠这两个字段决定是否触发你的skill。尤其是description，写得好不好直接决定这个skill的“激活率”。建议包含触发词和行为描述，比如“当用户要求生成单元测试、补充测试用例、检查测试覆盖率时使用”。

正文部分要有“流程感”。别写成一堆概念堆砌，而是清晰给出执行步骤：先做什么、再做什么、参考什么、输出什么。AI是照着你的流程执行的，你的流程越明确，它的产出越稳定。我见过很多人写的SKILL.md，内容很丰富但毫无结构，AI读完根本不知道从哪一步开始。

可选部分：给AI留“后门”。在SKILL.md里写“如果遇到××情况，向用户确认后再继续”，这样AI不会在没有你确认的情况下强制执行，能避免很多不可控的操作。

4.2 写好一条能用、好用的指令，注意这五个要点

第一，用祈使句，别用描述句。写“读取config/目录下所有YAML文件，提取endpoints字段”比写“应该读取配置文件并分析接口定义”靠谱得多。

第二，给具体路径，别让AI猜。你的项目里有什么目录、哪个文件放什么配置，这些信息是AI不可能自己知道的。SKILL.md里直接写“配置在config/settings.yaml”，它就不用瞎找。

第三，给输出格式。要求它“输出Markdown格式的审查报告，包含问题概述、风险等级、修复建议三个部分”，比只说“给出审查结果”强一百倍。

第四，给正反示例。在SKILL.md里附上“好的做法”和“差的做法”各一个例子，AI就非常清楚标准了。这招是我从官方skill里抄来的，实测效果显著。

第五，标记不确定性。有些流程你可能自己都没跑通，那就让AI“执行到某一步后先停下来，向用户展示中间结果，确认后再继续”。别指望一步到位，人机协作本来就是个迭代过程。

4.3 实战拆解：写一个数学建模赛题skill

数学建模这个场景很有意思，因为比赛的每一阶段都高度套路化，非常适合skills。我自己给“华为杯”做准备时写了一个建模流程skill，这里把过程拆给你们看。

这个skill的核心目的：当AI收到一道数学建模题时，能按“问题理解→数据预处理→模型选择→训练与评估→结果可视化→论文写作”的流程来推进，而不是拿到题目就开始瞎跑模型。

SKILL.md长这样（部分关键内容）：

--- name: math-modeling description: 适用于数学建模竞赛题目的完整流程处理，包括数据清洗、模型选择、结果分析和论文摘要撰写。当用户提交建模题目、赛题数据或要求建模分析时使用。 --- # 数学建模全流程技能 ## 适用场景 - 华为杯、国赛、美赛等数学建模竞赛题目 - 用户提供赛题描述和数据集 ## 工作流程 ### Step 1：问题理解与拆解 先仔细阅读题目，明确这是预测类、分类类、还是优化类问题。 输出“问题重述”一节，包含：目标变量、已知条件、约束条件、评价指标。 ### Step 2：数据探索与预处理 - 读取数据文件（优先检测CSV/Excel格式） - 打印数据基本信息：行数列数、缺失值、数据类型 - 对缺失值处理：数值列用中位数填充，分类列用众数填充 - 对异常值处理：用IQR方法检测并记录，不直接删，先标记 ### Step 3：模型选择 - 如果目标变量是连续值，优先尝试：线性回归、随机森林、XGBoost - 如果目标变量是类别，优先尝试：逻辑回归、LightGBM - 如果存在时间序列特征，考虑Prophet或LSTM（数据量>1000时） ### Step 4：训练与调参 - 用5折交叉验证，保证实验可复现 - 先跑baseline，再尝试调参，不要一开始就上复杂的模型 ### Step 5：结果输出 - 输出关键指标表（RMSE/Accuracy/F1等） - 用matplotlib绘制不少于2张图表：特征重要性图、预测vs真实值对比图 ## 注意事项 - 如果是华为杯赛题，注意大数据量下的处理效率，优先使用抽样或分块读取 - 模型结果解释比模型本身更重要，论文需要的图表在建模阶段就要准备好 - 如果出现内存不足，优先降低数据精度（float64→float32）

写完之后，我把它放到全局skills目录，然后在比赛练习时直接说“帮我跑一下这道题”，AI就自动按这个流程推进，而且每一步都在往论文要用的方向靠。实测这个skill帮我省了大量“让AI理解比赛规则”的时间。

5. 场景化搭配推荐：前端、数学建模、视频创作怎么配置

很多人装skill是“看到推荐就装”，结果一堆skill互相冲突。skill的正确用法应该是“按场景配齐一整套工作流”。这里给出我实测过觉得比较顺手的三个场景配置。

5.1 前端开发的skill搭配

前端场景的核心痛点是“组件开发、样式调试、代码审查、bug修复”这几类高频工作。我建议配四个足矣：

• code-review：代码审查，保证提交质量。
• component-generator：按需求生成组件代码，包含props定义、样式方案、story案例。
• style-debugger：专门定位样式问题，尤其是flex/grid布局和响应式断点。
• test-generator：为已有组件自动生成单元测试。

这套组合的好处是各管一摊，不存在功能重叠。你在日常开发中绝大多数任务都能落到其中某个skill的触发范围。我自己的前端项目配了这四个以后，AI产出的代码稳定性和可维护性都有明显提升。

5.2 数学建模/华为杯的完整skill组合

数学建模比赛时间紧张，核心诉求是“少踩坑、少返工”。我推荐按以下四件套配置：

• math-modeling：上面写过，负责整体流程推进。
• >