企业官网建设流程全解析

说实话，我第一次认真研究 AI 编程代理里的skills，是因为一个特别没面子的场景：Claude Code 在同一个项目里连续三次把同样的 ESLint 配置改错，我气得差点把终端砸了。后来朋友甩了一个词过来：你没给它写 skill 吧？当时我以为又是某种花哨的插件机制，根本没当回事。直到真的花一个下午把一个"数学建模类问题拆解"的 skill 喂进去，整个协作体验直接变了。这篇东西不是教程文档，是我自己从"skills 是什么"到"怎么写、怎么装、怎么清理"完整踩过一遍之后，整理下来的一套实操笔记。内容覆盖前端、数学建模、AI 漫剧这些高频场景，主角是目前社区里最活跃的 Claude Code 和 Codex，顺带聊聊 OpenCode。你如果正在用这些工具写代码、做竞赛、甚至批量产内容，这篇应该能直接帮你少走很多弯路。

1. 先搞清楚：AI 的 "skills" 到底是个啥？

1.1 从 prompt 到 skill：一次范式转变

先说个最简单但最重要的认知：skill 不是插件，不是 MCP server，它本质上是一份"高质量上下文包"。我以前用 AI 写代码，习惯把一长串要求直接粘进对话里，什么"你是资深前端工程师，注意性能、注意可维护性、注意边界情况"，每次都要重复一遍，而且经常说着说着就被 AI 带偏。skill 的思路恰恰相反，把这条冗长的指令变成一个可以被反复调用的独立模块，里面除了指令，还塞了示例、检查清单、代码片段、甚至脚本。AI 在合适的场景下会自动加载这个模块，而不是靠你每次手写临时发挥。

这个转变很关键。以前 prompt 是"一次性消费"，skill 是"资产化沉淀"。你今天在某个项目里总结出来的那套处理 React 性能问题的方法论，整理成 skill 之后，明天开一个新项目，AI 直接就能带着这套经验上岗。时间久了，你手里的 skills 库就是你个人的"AI 调教资产库"，越用越值钱。

1.2 skill、plugin、MCP：三兄弟别搞混

很多人第一次搜 skills 的时候，会看到 plugin、MCP、extension 这些词一起涌出来，直接懵掉。我用一张表把它们的区别讲清楚。

一个常见的误区是：有了 MCP 就不需要 skill。实际上两者是互补的。MCP 给 AI 提供了"手"，skill 给了 AI"脑子"。比如数学建模场景，你接一个能跑 Python 的 MCP server，AI 确实能调用环境去算题了，但如果没 skill 告诉它"先拆问题、再选模型、再验证假设"这套流程，它很容易拿到数据就开始糊模型，结果跑出来一堆没有业务意义的数字。所以正经的用法是 MCP 负责能力接入，skill 负责方法论约束，两个配合才稳。

2. 值得关注的 skills 场景与热门推荐

2.1 前端开发类 skills：解决"AI 改代码像瞎子一样"的问题

前端开发是 skills 受益最明显的领域之一。原因很简单：前端项目对"风格一致性"的要求特别变态，组件命名、状态管理方式、样式方案、目录结构，任何一项不一致都会让后期维护炸裂。我给 Claude Code 配过一个前端规范类 skill，里面就是把团队那套代码评审 checklist 全部写成指令，再配上两个"好的组件示例"和"坏的组件示例"。效果就是 AI 生成的代码风格明显向团队规范靠拢，而不是生成一堆"能跑但味道不对"的代码。

社区里现在能搜到的前端 skills 主要分三类。第一类是全栈脚手架类，你给它一个项目描述，它能按照固定的架构模板把项目搭出来；第二类是单点优化类，比如"React 性能分析 skill"，专门用来排查重渲染问题；第三类是代码审查类，让 AI 按指定标准对现有代码做 review 并直接输出带优先级的修复建议。我个人建议新手从第二类和第三类入手，因为见效最快，而且不用一次性给 AI 灌输太多规则。

2.2 数学建模 / 竞赛类 skills：华为杯、国赛都能用的实战组合

数学建模是另一个让我彻底服气 skills 的场景。拿华为杯这类比赛来说，时间紧、任务重，每道题都得在几天内完成"问题分析-模型建立-求解-验证-论文写作"的完整闭环。以前我干这事的时候，全靠人肉在多个文件之间来回复制粘贴提示词，浪费时间不说，AI 还经常忘了前面的约束。

后来我组合了一套"数学建模工作流 skill 包"，包含三个独立 skill：第一个是问题拆解器，拿到题目后强制 AI 先输出问题域、约束条件、目标函数和可选模型列表，不经过这步不许碰数据；第二个是模型选择器，内置了常见的优化模型、统计模型、机器学习模型的适用条件对照表，让 AI 基于第一个 skill 的输出做匹配推荐；第三个是论文结构器，按数模论文的标准章节结构组织写作，把摘要、模型假设、灵敏度分析这些模块的要求都写进去。

我自己的实测体验是：用上这套 skill 之后，AI 给出的建模思路从"东一榔头西一棒子"变成了"有逻辑递进"，尤其在被追问"为什么选这个模型"的时候，AI 能引用 skill 里的对照表给出理由，而不是胡编。华为杯这种比赛，评委特别喜欢看这种有依据的分析，所以这套组合对竞赛人群来说非常值得复制。

2.3 AI 漫剧 / 创意内容类 skills：批量产出的稳定器

AI 漫剧或者 AI 短视频这两年特别火，很多工作室在批量做内容。这类场景的核心痛点其实是"风格一致性"：同一部漫剧，主角长相不能变、画风不能变、叙事节奏也不能变。光靠 prompt 去控制，换个场景就翻车。skills 在这里的玩法是把整个叙事和视觉规范固化成几个模块，比如"角色一致性 skill"里写好主视觉描述和禁止事项（比如"任何时候不得改变瞳孔颜色"），"分镜脚本 skill"里规定一场戏必须按"远景定场-中景对话-特写反应"的节奏来写。

有人可能会问，这不就是写几个模板 prompt 吗？区别在于 skill 能被 AI 自动触发。比如你在对话里扔进一句"下一场戏是主角在雨中回忆"，AI 会自动激活对应的分镜 skill 和角色 skill，而不需要你每次手动把一大段规范复制进来。对于批量产内容的团队，这个"自动触发"的价值不是省几分钟，而是消灭了人为忘记带上下文的问题。

2.4 通用效率类 skills：superpower 这类全家桶要不要装？

社区里讨论度最高的通用型 skills 项目，一个是 superpower skills，另一个是 Anthropic 官方维护的 skills 仓库。superpower 这类全家桶的特点是"全"，从写代码到写文档，从做计划到做复盘，塞了几十个 skill 进去。第一次装完那种感觉确实很爽，感觉 AI 什么都懂。

但我要泼一盆冷水：全家桶对你来说可能太重了。我的实际体验是，几十个 skill 全量塞进上下文之后，AI 的响应变慢，而且会出现"选择困难"，明明一个简单的排序问题，它非要调用那个"算法设计大师"的 skill，输出一堆和问题不匹配的仪式感内容，纯粹是浪费 token。所以我的建议是：你可以把全家桶下下来当成 skill 写作的参考教材，但实际使用一定要做瘦身，只留高频使用的十个以内。这个清理方法后面专门有一节讲。

3. 手动安装 GitHub 上的 skills：以 Claude Code 为例

3.1 先看懂一个 skill 仓库的结构

很多人在 GitHub 上找到了心仪的 skills 仓库，却卡在"怎么装"这一步。原因是不理解 skill 的目录结构。一般一个标准 skill 长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── check.py └── resources/ └── template.md

核心就是那个SKILL.md文件，它是一切的入口。里面一般带 YAML 格式的 frontmatter，包含name和description两个关键字段。name是 skill 的标识，description则是给 AI 看的触发条件，AI 就是通过读这段描述来判断"当前任务该不该调用这个 skill"。所以一个 skill 能不能被 AI 正确触发，一半的功劳取决于description写得好不好。

剩下的scripts和resources目录都不是必须的，看需要加。scripts放一些可以被 AI 调用的脚本，比如格式检查脚本；resources放辅助材料，比如模板文件、参考文档。理解了这个结构，安装就变得很简单：本质就是把整个目录放进 AI 工具能扫到的地方。

3.2 手动安装：clone 到你不需要思考的位置

以 Claude Code 为例，它在运行时主要扫描两个位置的 skills：一个是用户级目录~/.claude/skills/，一个是项目级目录.claude/skills/。用户级目录对所有项目全局生效，项目级只对当前项目生效。手动安装的步骤如下。

第一步，定位仓库：先去 GitHub 找到目标仓库，把仓库 clone 到本地任意临时目录。注意有些仓库根目录就是一整个 skill，有些仓库则是多个 skill 的集合，你还得进去找到对应子目录。

第二步，复制：把单个 skill 目录复制到~/.claude/skills/下面。比如你下载了一个叫frontend-review的 skill，最终路径应该是~/.claude/skills/frontend-review/SKILL.md，这个结构不能错。

第三步，重启会话：让 Claude Code 重新加载配置。用/skills命令可以列出当前已加载的 skills，检查一下目标 skill 有没有出现在列表里。如果出现了，就说明安装成功，可以开始用了。

# 安装命令示例 git clone https://github.com/xxx/awesome-skills.git /tmp/awesome-skills mkdir -p ~/.claude/skills cp -r /tmp/awesome-skills/frontend-review ~/.claude/skills/

提示：复制完目录之后，先看一眼SKILL.md里的name字段和目录名是否一致。有些仓库的目录名和name不一致，Claude Code 对这种情况的处理在不同版本里表现不太一样，统一改一致最稳妥。

3.3 Codex 和 OpenCode 的安装差异

如果你用的不是 Claude Code，而是 OpenAI 的 Codex 或者开源的 OpenCode，安装思路一样，就是目标目录不同。Codex 的 skills 通常放在.codex/skills/（项目级）或者~/.codex/skills/（用户级）；OpenCode 的配置目录一般在~/.config/opencode/skills/这种位置。最笨也最有效的办法是装好工具之后，先手动建一个测试 skill，然后看它到底被扫描到哪个目录，再去翻这个目录的路径。

我个人的建议是，如果你想在不同工具之间共享同一种 skills 管理体验，可以把"真正的技能内容"集中放在一个自己的目录里，比如~/my-skills/，然后在各个工具的 skills 目录里建软链接指向它。这样你改一份内容，所有工具都生效，不用重复复制。

3.4 安装失败最常见的三个原因

安装这门手艺，失败才是常态。我踩过的坑和看到别人踩的坑，基本可以归结为三点。

第一，目录结构不对。最常见的是直接把整个仓库根目录复制进来，导致SKILL.md没有在顶层，而是埋在仓库名/某个子目录/SKILL.md里。这个问题最气人，因为看起来啥都装了，但 AI 就是不认。

第二，description 写得太差。有时候 skill 装上了，也能列出，但 AI 永远不触发它。这种多半不是安装问题，而是 skill 自己的description写得像猜谜，AI 根本不知道什么场景该调它。这类问题只能靠改写SKILL.md来解决。

第三，文件权限问题。在用软链接或者跨用户目录分享 skills 的时候容易遇到，AI 工具进程读不了文件。用ls -l看一眼权限位，给足读权限就行。

4. 自己写一个 skill：从零到能用的完整过程

4.1 先搞清 SKILL.md 的骨架和写作顺序

自己动手写 skill 并没有想象中那么难，但也不是写一段 prompt 扔进去那么简单。一个能稳定发挥作用的 skill，背后通常有一整套结构。我把 SKILL.md 的骨架拆给你看：

• YAML frontmatter：name+description。name别起得太玄，description则要尽量写清楚"这个 skill 在什么情况下、解决什么问题"。
• 触发条件说明：正文一开始，用自然语言告诉 AI"什么时候必须使用这个 skill"，相当于给 AI 一个开关。
• 执行步骤：把任务的执行流程拆成明确的、有序的步骤。注意步骤要拆到 AI 不用猜的地步。
• 硬性规则：列出绝对不能违反的铁律，比如"禁止使用全局变量""不得修改用户未指定的文件"。
• 输入 / 输出格式：定义调用这个 skill 的时候需要哪些输入，以及 AI 应该输出什么格式的内容。
• 示例：一个完整的、好的示例比一百句解释都管用。

写作顺序上，我的习惯是先从示例开始。先把一个理想输出样例写好，然后倒推需要什么样的步骤和规则才能产生这样的输出。最后再回头写description。很多新手搞反了，先写描述再写内容，结果描述写得花团锦簇，实际执行逻辑全是漏洞。

4.2 写 PROMPT 的进阶技巧：别坐等 AI 理解，给它决策树

这是我写了几十个 skill 之后最大的心得：好的 skill 不是"指令大集合"，而是"决策树"。最简单的写法是告诉 AI"如果 A 情况就做 X，如果 B 情况就做 Y"，但真正的实战里情况往往是混合的、交错的。

举个例子。我在写数学建模问题拆解这个 skill 时，没有简单写"先读题再拆解"，而是写了一套判断规则：

• 如果题目包含明确的目标函数和约束条件：优先归入优化类问题，输出模型候选列表时必须包含线性规划或整数规划的评估。
• 如果题目给出时间序列数据且要求预测：优先归入统计预测类，必须做平稳性检验并在输出中给出检验结论。
• 如果题目是分类问题但数据量小于阈值：强制提醒优先尝试可解释模型，而不是一上来就选神经网络。

这种"如果-那么"结构让 AI 的执行路径稳定得多。因为 AI 天然喜欢顺着明确的逻辑链走，你给它一个判断框架，它输出的东西就具有了可预期性。写 skill 最忌讳的就是含糊的期望，比如"请给出高质量的分析"，这种描述等于没说。

4.3 完整示例：手写一个"数学建模问题拆解" skill

我直接把我用过的简化版贴出来，你可以照着改。这个 skill 是前面说的建模 skill 包里的核心模块，结构很典型。

--- name: math-modeling-scaffold description: 用户给出一个数学建模竞赛题目或复杂实际问题时使用。用于在建模前完成问题结构化拆解，输出问题域、约束条件、决策变量、目标函数和候选模型清单。任何数学建模相关请求都必须先经过此 skill 处理。 --- # Math Modeling Scaffold 你必须在使用本 skill 后，按以下结构输出内容。未完成全部步骤之前，禁止进入建模或求解阶段。 ## 步骤一：问题域识别 - 用自己的话复述题目，不超过 100 字。 - 列出问题所属的学科域（运筹优化 / 统计预测 / 机器学习 / 微分方程等）。 ## 步骤二：要素抽取 - 约束条件：列出题目中所有显式和隐式约束。 - 决策变量：列出可能的决策变量，并标出离散/连续属性。 - 目标函数：如果题目隐含优化目标，将其明确写成数学形式；如果没有，则说明"该问题不是显式优化问题"。 ## 步骤三：候选模型生成 - 基于以上要素，给出 3 个候选建模方向。 - 每个候选必须说明选它的理由、适用前提、以及如果前提不满足时的备选方案。 ## 步骤四：硬性规则 - 禁止编造题目中不存在的数据。 - 禁止在未完成要素抽取前给出最终模型。 - 输出必须使用 Markdown 表格呈现候选模型对比。 ## 示例 （此处粘贴 1-2 个之前做过的完整拆解案例）

这个 skill 核心就一个目的：掐住 AI 建模前期的流程。我试过没有这个 skill 的状态，AI 经常拿到题十分钟就开始列方程，最后发现漏了一个关键约束，整个模型推翻重来。加了 skill 之后，它哪怕想飞也得先把前四步走完，过程质量明显高一个档次。

4.4 调试和迭代：skill 不是写一次就完事

写完 skill 只是第一步，调试才是重头戏。我的调试方法非常简单粗暴：准备三个不同类型的测试输入，分别让开了 skill 的 AI 和没开 skill 的 AI 跑一遍，然后对着输出差异找问题。如果发现 AI 的输出还是偏离预期，通常不是 AI 笨，而是 skill 里的规则有歧义，需要改得更"死板"一点。

迭代频次方面，一个新 skill 我一般会经历三次左右的修改才达到稳定状态。第一次修逻辑漏洞，第二次补边界情况，第三次简化措辞（减少 token 占用）。修改完要记得重启会话再测试，因为 AI 工具对 skill 的加载大多是在会话启动时完成的，热更新能力有限。

5. 常用 skills 源网站和获取渠道

5.1 值得常驻的几个 GitHub 仓库

社区里几个高质量的 skills 源我已经常驻了，定期去翻翻更新。按我的使用频率排序：

有些名字你可能没搜到，比如 cola skills，这类通常是社区个人维护的集合型仓库，特点是作者会把自己的实战经验打包进去，风格更野，但有时反而更对你的场景。我的建议是别只盯着 star 数高的，多去搜"skills"和你的垂直场景组合词，比如"前端开发 skills""数学建模 skills"，往往能挖到小众但好用的东西。

5.2 在 GitHub 上筛选高质量 skills 的三个标准

GitHub 上 skills 仓库鱼龙混杂，我筛选的时候只看三点。

第一，看 SKILL.md 的 description 是否具体。凡是 description 写成"帮助开发者提高效率"这种片儿汤话的，直接跳过。好描述会写清楚触发条件和使用边界，我前面说过了。

第二，看是否带示例。一个好的 skill 必然带完整的输入输出示例。不带示例的 skill，大概率是作者从某个 prompt 集合里复制粘贴过来充数的，稳定性和效果都没保证。

第三，看最近更新时间和作者对 issue 的回复。skills 这个领域变化太快，官方工具的加载规则说改就改，长期不更新的 skill 大概率已经失效。作者如果在 issue 区积极回复"适配新版工具"之类的内容，说明还在维护。

5.3 自己搭一个私有技能源

公共仓库只是起点，认真玩 skills 的人最后都会走上自建这条路。原因很简单，你自己沉淀的 skill 才最贴合你的工作流，而且包含很多不能公开的团队规范或业务逻辑。我用的是最传统的方案：一个私有 Git 仓库，按类型建目录，比如frontend/、math-modeling/、content/，每个目录下放对应的 skill 子目录，然后通过软链接的方式让 Claude Code 和 Codex 都能读取。

自建技能源还有一个额外的好处，就是可以做版本管理。我改一个 skill 改坏了，可以直接回滚到之前的版本。这个习惯帮我避免过好几次灾难，有一次我把一个本来运行良好的代码审查 skill 改成了"全英文输出规范"，结果 AI 开始频繁输出英文注释，团队差点炸锅，亏得 git 回滚救了一条命。

6. 技能库管理：清理、去重和版本控制

6.1 为什么要定期清理？因为会"技能通货膨胀"

我见过有个朋友，装完 superpower 全家桶之后又装了两三个聚合包，总共塞了 80 多个 skill 进系统。看起来壮观，实际用起来是一场灾难。主要的副作用有三个：token 浪费、选择困难、指令冲突。token 浪费发生在很多工具会把 skill 列表甚至内容加载进系统提示词；选择困难是说 AI 面对几十个候选 skill 时，经常挑一个次优的去执行；指令冲突更离谱，两个 skill 对同一个操作给出相反要求，AI 直接精神分裂。

这就像手机里装了几百个 App，看似啥都能干，实际上每个都想弹通知，最后你连微信消息都看不清。技能库不是收藏夹，装进去就是为了用的，用不上就删，别心疼。

6.2 清理方法论：按使用频率和场景归档

关于清理，我之前看到过一个叫 tibo 的开发者分享过一套思路，核心是"分类 + 频率 + 价值"三维清理法。我自己实操下来觉得很有用，具体做法是这样的。

第一步：把当前所有 skills 列个清单。 第二步：按使用场景打标签，比如"高频关键""低频备用""实验性尝试""过期废弃"。这里可以靠/skills命令的输出和你的记忆来判断，不用太精确。 第三步：对每一类执行不同策略。高频关键的直接保留；低频备用的移到单独目录，别占着主目录；实验性的只留最新那个版本；过期废弃的直接删。 第四步：每两个月做一次复盘，把真的超过半年没用过的低频 skill 清理掉。

这套清理的频率因人而异，我自己的节奏是每个季度大扫除一次，每次能删掉三五个"曾经觉得有用、实际吃灰"的 skill。释放的可不只是硬盘空间，更重要的是 AI 的决策空间。

6.3 用 Git 管理 skills 版本的实操细节

用 Git 管理 skills 有几个容易忽略的细节。第一是目录结构要和工具的扫描路径解耦，我建议真正的技能目录放在~/skills-repo/下，然后用软链接接到~/.claude/skills/和~/.codex/skills/，这样 git 仓库只管内容，不管工具路径。

第二是提交信息要写清楚改动意图。别写"update skill"这种废话，我一般写"frontend-review: 增加对 Vue 3 组合式 API 的检查规则"，一个月之后翻 log 还能想起来当时的思路。

第三是要做"示例基线"。在每个 skill 的目录里放一个test/文件夹，存几个标准测试输入和期望输出。每次改动 skill 之后，用这些示例跑一遍回归测试。我见过很多 skill 越改越歪，就是因为没有守住基线，改着改着把 AI 的行为改偏了。

7. 学习路径与实用心得

7.1 新手最顺的学习顺序

如果你完全零基础，我的建议是先不要急着写自己的 skill，按下面这条路径走，大概一两天就能上手。

第一步：找一个靠谱的官方示例仓库，比如 anthropics/skills，把里面的 skill 挨个读一遍，重点看SKILL.md的结构。先培养语感，知道好 skill 长什么样。

第二步：选一个你工作中最高频的场景，把现有的 prompt 整理成一个最简单的 skill，先装上用起来。不用追求结构完整，先体验"调用 skill 之后的差异"。

第三步：当你觉得现有 skill 不够用、AI 经常在某个环节跑偏的时候，再开始学写决策树式规则，逐步完善细节。这时候才算真正进入 skill 开发的状态。

最忌讳的学习方式是一上来就研究全家桶源码，试图理解所有类型。实际写作和调试的经验比阅读重要得多，写坏三个 skill 之后，你自然就懂那些最佳实践是为什么了。

7.2 我踩过的几个值得记住的坑

讲几个我用真金白银的 token 换来的教训。

第一个坑是"过度使用示例"。我给一个前端 skill 塞了整整两个完整的项目示例，结果每次 AI 输出都会不自觉模仿示例里的命名风格，哪怕场景根本不同。示例不是越多越好，一个正例一个反例足以。

第二个坑是"规则互相矛盾"。我写完"输出必须简洁"的规则之后，又在同一个 skill 里写了"必须输出完整的逐步分析"，结果 AI 每次都在语句长度上纠结。写完 skill 之后一定要通读一遍，把自己放在 AI 的位置上感受一下有没有左右互搏的地方。

第三个坑是"忽略工具升级"。Claude Code、Codex 这些工具的加载规则是快速演进的，一个月前能正常触发的 skill，可能因为工具加了新的优先级机制就失效了。所以每逢工具提示升级，我都建议花十分钟过一遍常用 skills 还正不正常。

第四个坑是关于 token 的：skill 不是塞得越详细越好。本地测试的时候用大模型感觉不明显，但一旦进入长对话，一个 3000 字的 skill 可能挤压真正对话内容的上下文空间。我这边的经验值是单个 skill 的正文控制在 800 到 1500 字之间，执行规则写清楚，但别写成百科全书。

7.3 把 skills 当作团队资产来运营

最后想多说一句，是个人的价值判断。很多人把 skills 当成"个人效率工具"，但我更愿意把它看作"可沉淀的团队资产"。一个好用的 skill，本质上是你和团队把隐性知识显性化的过程。以前老程序员带新人，靠的是口口相传和 code review 里一遍遍纠正；现在你把团队规范写进 skill，AI 就成了一个不厌其烦、永远遵守规范的新成员。

所以我在团队里推过一个做法：每次有人写了一个新的高效 prompt 或者解决了一个疑难 bug，就顺手把它变成一个小 skill 提交到团队仓库里。一个月下来，团队就有了一个"集体调教"的 AI。这件事的价值不是省了几个小时的提示词时间，而是把每个人脑子里的经验沉淀成了可复用的资产。我自己的体会是，skills 真正厉害的地方不是让 AI 变聪明，而是倒逼你把问题想清楚——你不把流程琢磨透，根本写不出一条稳定的规则。就凭这一点，花在 skills 上的时间就一点都不亏。