企业官网建设流程全解析

最近一直在折腾一件事：把 Claude Code、Codex、OpenCode 这些 AI 编程工具，从“只会聊天写代码的通用助手”调教成“懂我这个领域的专职工程师”。核心就靠一个东西——skills。这个词最近热度确实高，搜索量涨得很快，但你去搜会发现资料特别碎：有人叫它技能包，有人叫插件，还有人直接当高级 prompt 模板用。我从官方 skills 仓库一路装到社区的 superpower skills、TypeSafe AI Skills，中间踩了不少坑，也自己写过几个可用的，今天把这套玩法掰开揉碎讲清楚。

这篇文章适合这几类人：刚听说 skills 想搞明白它到底是什么的新手；已经在用 Claude Code、Codex 但只会普通对话、还没发挥出技能系统威力的中度用户；以及想自己写 skill 分享出去、又怕格式不对没人能用的开发者。我会尽量少讲虚的，多给能直接抄的配置、路径和步骤。

1. Skills到底是什么：AI编程里的“专项外挂”

1.1 从“裸奔的AI”到“有执照的工程师”

先说一个很直观的感受。默认状态下，Claude 或 Codex 这类工具在我看来就是个“什么都会一点、但什么都不精”的实习生。你让它写 Python 脚本，它写得还不错；你让它做数学建模，它也能套个层次分析法；你让它帮你写前端页面，它知道 React 语法。可问题在于——它对你所在的领域、你手头的项目约定、你踩过的坑，一无所知。

Skills 解决的就是这个问题。它本质上是一份结构化的“专业手册 + 可执行脚本 + 触发条件”的组合包。你把一个 skill 放进指定的目录，AI 在对话时读到对应的描述信息，就会在合适的时机把这份手册内容加载进来，按照里面写的流程、规范、模板去完成特定任务。

我打过一个比方：普通 AI 对话就像你雇了个什么都会但什么都不熟的杂工，每次都得从头交代背景。挂上 skills 之后，等于给了这个杂工一本带插图的岗位说明书，他翻到对应章节就知道该按什么流程干活、用什么工具、产出什么格式。

1.2 一个Skill的典型结构

目前社区里最主流的 skill 格式，是 Anthropic 在官方 skills 仓库里带火的结构。一个标准的 skill 目录大概长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── run_helper.py ├── assets/ │ └── template.md └── README.md

核心就一个文件：SKILL.md。这个文件开头有一段 YAML 格式的 frontmatter，里面最关键的是两个字段：

--- name: my-skill description: 当用户需要处理xxx时使用 ---

name 是技能名，description 是技能的“广告词”。这里有个很重要的机制：AI 不会在每次对话时把所有 skill 全文都读一遍，它只会先看每个 skill 的 name 和 description，判断当前用户的问题该不该触发、该触发哪一个。只有“评估命中”之后，才会真正读取并执行这个 skill 的完整内容。

这就像你手机里的应用图标：系统不会把所有 App 的完整代码都跑起来，它只读图标和名称，等你点开才加载整个应用。所以 description 写得准不准，直接决定这个 skill 会不会被正确激活，这一条后面专门讲。

1.3 为什么Skills比普通Prompt更靠谱

有人会说：那我把自己的一套 prompt 模板保存下来，每次粘贴给 AI 不也一样吗？早期我也是这么干的，但用多了发现几个硬伤。

第一，普通 prompt 是“一次性”的。你复制粘贴到对话里，它确实起作用，但只对当前这轮对话有效。下次开新会话，你还得重新粘。skills 是常驻的，只要你把对应目录配置好，每个新会话都能自动被发现、按需加载。第二，普通 prompt 没有“触发判断”能力。一个写满 3000 字的 prompt 模板，每次都得靠用户手动触发加载，AI 不会在合适的时机主动想起来“哦，这事我有专业流程”。skills 的 description 机制让 AI 自己做路由判断。第三，完整 skills 可以携带脚本和资源文件，prompt 只是文字，能承载的信息量和可操作性完全不在一个量级。

简单说：prompt 是口头交代，skills 是完整的工作流装备。

2. 哪些场景值得装Skills：从数学建模到前端开发的选型思路

2.1 数学建模：最刚需的战场

我自己是搞数模出身的，所以对“数学建模 skills”特别敏感。搜索热词里有大量“数学建模skills推荐”“华为杯建模比赛好用的codex skills”，这个方向确实值得聊。

数学建模比赛的特点是：时间紧、任务重、套路固定。优化类、预测类、评价类、微分方程建模类，每一类都有成熟的分析框架和对应算法。但如果你直接让 AI“帮我做数学建模”，它往往会给你一个四平八稳的大路货答案——层次分析法加上灰色预测，模板痕迹重得一眼就能看出是 AI 写的。

装一个建模专用 skill 之后，它会强制 AI 走完整流程：先拆解题目类型，判断是规划问题还是预测问题；然后建议候选算法，写清楚每个算法的适用条件和数据要求；接着要求 AI 把模型假设、符号说明、模型建立、求解、灵敏度分析全部结构化输出；最后连论文排版的 LaTeX 模板都给你备好。

我曾经在备赛时用过一个社区维护的建模 skill 集合，里面按“聚类分析”“时间序列”“多目标优化”分好了多个独立 skill。实际用下来，最明显的改进不是 AI 变聪明了，而是它的输出从“一篇模糊的课程作业”变成了“一份能直接拿去参赛的初稿”。它知道数学建模论文要有什么章节，知道灵敏度分析不能少，知道模型假设要写得像回事——这些就是 skills 里注入的领域知识。

2.2 前端开发：让AI变成“懂行”的同事

前端开发也是 skills 应用最活跃的领域。前端这个行当有个特点：技术栈碎片化严重，项目之间差异巨大。同样一个“封装按钮组件”的需求，在 Vue2 老项目里、Vue3 + TypeScript + Tailwind 的新项目里、小程序项目里，写法完全不一样。

如果你给 Claude Code 配一个“前端开发 skills”，里面写明项目的技术栈约定、目录规范、CSS 方案、组件命名规则、代码风格，AI 生成的代码就几乎不用返工。我见过最实用的一个前端 skill，里面甚至包含了一个“组件开发清单”：props 是否需要默认值、事件命名是否遵循规范、样式是否用了设计系统里的 token、响应式布局有没有考虑。

还有一个很多人忽略的点：前端开发不只是写代码，还涉及性能优化、浏览器兼容性、可访问性。好的前端 skill 会把这类“隐形的行业经验”写进去，让 AI 自动检查。

2.3 AI漫剧与多媒体内容生产

“AI漫剧常用skills”这个词能上热搜，说明 skills 已经不光是程序员圈子的事情了。现在很多人用 AI 工具批量生成漫画、短剧脚本、分镜、配音稿，这类内容生产的痛点在于：AI 虽然能写，但生成的文本往往没有网感，不懂得“卡点”，不知道漫剧每集应该控制在多少字、结尾要留什么悬念。

聪明的做法是把“账号风格”写进 skill 里。你做一个“漫剧脚本生成” skill，描述里写明：输出节奏参照某类热门短剧，每集时长控制在多少秒，情节用强冲突推进，每集结尾必须留钩子。AI 一进入写脚本的环节，就会按这套风格标准产出内容，而不是每次重新调教。

这类 skill 的通用逻辑是：把所有你不希望每次重复交代的“隐性要求”沉淀成一个文件。内容创作领域尤其适用。

2.4 通用工具型与学习型Skills

除了垂直场景，还有一些通用型的 skills 值得装。社区里几个比较受欢迎的集合，我简单列一下，省得大家乱搜：

如果你只是刚开始接触 skills，我的建议是别贪多。先装一两个和你工作最相关的，用顺手了再扩展。装一堆却用不起来，反而会造成“技能打架”，这个后面讲。

3. 手动安装：三款主流工具实战

3.1 Claude Code的目录挂载与Plugin方式

Claude Code 是目前对 skills 支持最原生、也最完善的工具。它的机制是扫描指定目录下的 skill 文件夹，读取里面的SKILL.md。目录分成两种，个人级和项目级。

个人级目录放在用户根目录：

~/.claude/skills/

项目级目录放在当前项目下，适合团队共享：

.claude/skills/

从 GitHub 上手动装一个 skill 的标准流程是这样的。假设我想装一个社区开源的“代码审查助手”：

# 1. 进入个人skills目录 cd ~/.claude/skills/ # 2. 克隆目标仓库（如果仓库本身就是一个skill目录） git clone https://github.com/example/repo.git code-review-skill # 3. 如果仓库里包含了多个skill，只需要复制对应的子目录 cp -r repo/skills/code-review-skill ./

克隆下来之后，确认目录结构里最外层或者某层有SKILL.md，就可以了。重启 Claude Code，新会话里它会自动扫描到。你不用做任何额外注册。

有一点要特别注意：很多 GitHub 仓库不是“一个仓库一个 skill”，而是“一个仓库装了几十个 skills”。比如 Superpower Skills 这种集合型仓库，你要用的特定 skill 往往藏在skills/子目录下，直接克隆整个仓库到个人 skills 目录会出问题——Claude 会把它当成一个巨型 skill 来解析，既臃肿又容易触发混乱。正确做法是只复制用到的那一个子目录。

3.2 Codex CLI的Skills接入

Codex CLI 目前对 skills 的支持机制和 Claude Code 稍有不同，社区里常见的做法是把SKILL.md放到指定的代理配置目录，或者通过opencode.json这类配置文件进行注册。以我实测过的路径为例：

~/.codex/skills/

把 skill 目录放到这里之后，还需要在 Codex 的配置文件里声明。具体配置项在不同版本之间变化较快，最稳妥的方式是装好之后先跑一下codex --help看当前版本的 skills 子命令是否可用，或者直接查看官方文档里的“agents”章节。

这里我要给个很重要的实操建议：不同工具的“skills”名词虽然相同，但实现细节并不完全一致。你从网上看到一篇教程说要放在某个目录，先别急着照抄，看一下这篇教程的发布时间和你当前工具版本的匹配度。我吃过的亏是：照着三个月前的教程配置，结果新版 Codex 已经改了路径，折腾半天才发现是版本差异。

3.3 OpenCode的配置方式

OpenCode 这个工具我最近也在用，它对第三方 skill 的接入方式和 Claude Code 不同，更依赖配置文件驱动。一般是在opencode.json或者项目级配置里，把 skills 的路径通过 JSON 结构注册进去。

典型的配置片段长这样：

{ "agent": { "skills": { "code-review": { "path": "./skills/code-review", "description": "代码审查专用技能" } } } }

配置完成后，重启 OpenCode，在对话里触发对应场景，它就会读取这个路径下的SKILL.md并按照其中指令行动。

需要提醒的是，OpenCode 的配置字段名会随版本微调，不同分支写法也不一样。如果你照着我的示例配置报错，大概率是版本差异。正确姿势是打开当前项目的.opencode/目录，看看里面有没有现成的 schema 定义，按那个来。

3.4 安装前必做的几件事

不管用哪个工具，手动装 skills 之前有几件事我建议提前做完，能省不少事。

第一，确认版本。查一下claude --version、codex --version，确认你的工具版本不算太老。太老的版本可能根本不支持 skills 机制，或者支持的格式标准不兼容。第二，备份已有的配置目录。如果你已经在用 skills，装新东西之前把当前目录打个包备份，出问题能回滚。第三，检查目录结构。装完先自己看一眼，SKILL.md是不是在那个目录的一级或二级位置，不要粘贴成了仓库根目录里一大堆源码文件的样子。

第四也是最重要的一点——在一个干净的测试目录里，先跑一个最简单的问题验证 skill 是否被触发。比如我装完建模类 skill，会先问一句“帮我列一下这题用到的三类候选算法”，看它是否表现出 skill 里特有的流程化口吻。如果回答还是大路货，说明 skill 根本没加载上。

4. 从零开发一个自己的Skill：完整流程与格式规范

4.1 目录结构与命名规范

如果社区里的现成 skills 满足不了你，那就自己写。别觉得难，写一个基础可用 skill 的难度，其实比写一个复杂脚本低，它本质上就是“规范格式的 Markdown + 可选辅助脚本”。

先搭目录。以“数据清洗助手”为例：

data-cleaner/ ├── SKILL.md ├── scripts/ │ └── detect_outliers.py ├── assets/ │ └── example_report.md └── README.md

命名规范上，目录名和name字段保持一致，全小写加中划线，一眼能看懂用途。不要用中文目录名，虽然部分工具支持，但跨平台和跨工具复用时很容易出编码问题。

SKILL.md是唯一必须存在的文件，其他目录都可以按需增减。原则是：能内置到指令里的小规则，直接写进SKILL.md；复杂的计算逻辑、文件处理逻辑，放到scripts/里被调用；需要给 AI 提供参考模板的，放到assets/。

4.2 把SKILL.md写对：frontmatter是关键

SKILL.md的开头必须是 YAML frontmatter，前后各用三个中划线包裹。最精简但够用的格式是：

--- name:>你是一名严谨的数据工程师，正在帮助用户完成一个数据清洗任务。你的目标是输出一个可以直接进入建模阶段的数据集，同时附上清洗报告。

第二段是执行流程清单。用编号列出不可跳过的步骤，这是 skill 的核心资产。

1. 检查数据概览：读取数据的行数、列数、缺失值比例、数据类型。 2. 缺失值处理：对数值型列先判断缺失比例；低于5%时用均值/中位数填充，高于20%时要提醒用户考虑删除该列。 3. 异常值检测：调用 scripts/detect_outliers.py 脚本辅助判断，不要手动肉眼判断。 4. 数据标准化：对偏度大于1的列应用对数变换，并在报告中说明变换理由。 5. 输出结果：保存清洗后的数据文件，并生成一份包含每一步操作原因的 Markdown 清洗报告。

第三段是输出格式约定和质量标准。告诉 AI 最后交付物的结构，以及自查清单。

清洗报告应包含：原始数据概览、每一步清洗操作的执行理由、清洗前后的统计对比。 自查清单：是否所有缺失值都已处理？报告里每个操作是否都写了原因？代码是否能直接运行？

这套结构不一定适合所有 skill，但作为一个起点，它比“你是一个数据处理专家，请帮我清洗数据”要可靠得多。

4.4 附带的脚本和资源怎么组织

skill 里的脚本是给谁用的？很多人误解了这一点。不是给用户手动跑的，而是给 AI 在需要时调用、或者给用户按 AI 的指示去执行的。

比如数据清洗这个 skill，如果要求 AI 每次都现场写一遍异常值检测代码，它写出来的可能不够严谨。更好的做法是你提前写好一个detect_outliers.py，在SKILL.md的流程里写一句“调用 scripts/detect_outliers.py 进行异常值判断”。AI 读到这个指令后，会读取该脚本内容来理解逻辑，并在执行过程中引导用户使用。

脚本语言、依赖不要搞得花哨，优先用 Python 标准库或者最常见的 pandas、numpy，减少用户环境配置成本。资源文件同理，模板文件要保持精简，放重点示例，别把一大堆参考文件塞进去。

5. 常见问题与排查心得

5.1 Skill装了对AI“没有反应”

这是所有新手都会碰到的问题，我也不例外。明明把目录放进去了，AI 回答问题时完全没体现出 skill 里的专业流程，像没装一样。

排查顺序一般是：先确认目录位置。Claude Code 的话，个人级一定是~/.claude/skills/，不要放到了~/.claude/下面当子目录漏了一层。再确认结构。SKILL.md必须在 skill 目录的一级位置，如果多套了一层文件夹，AI 可能扫不到。然后检查 frontmatter。YAML 语法错误、缩进不对、冒号后面没加空格，都会导致解析失败并且没有明显报错。最后测试 description 是否明确。问一句和 description 描述的场景八竿子打不着的问题，它当然不会触发；换个正中描述的场景再试。

我自己的习惯是，装完每个新 skill 都立刻做一次“触发测试”：用一句完全命中描述的话去提问，看反应。如果这句都没触发，那基本配置有问题，不用继续往后查。

5.2 多个Skill互相“打架”

装了十几个 skill 之后你会发现：一个问题可能同时命中了好几个 skill 的描述，AI 会无所适从，或者把多个 skill 的风格混在一起输出。

这个问题的根源多半在自己身上，属于“配了太多边界模糊的 skill”。比如同时装了一个“数据分析” skill 和一个“数据可视化” skill，两者的 description 都写了“当用户需要处理表格数据时使用”，AI 不知道该切入哪个。

解决办法有几个方向：一是合并同类项，干脆把相近的职责合成一个更大的 skill，在内部用条件分支区分场景，而不是拆散成多个独立 skill；二是加强负面描述，在每个 skill 里明确写“如果用户只想要xxx，不要使用本技能”；三是精简数量，保留最常用的几个高质量 skill，比一张大而全的技能列表更实用。

社区里也有人专门聊过“清理 skills”的方法，核心思路无非就是定期检查、合并重复、删掉超过三个月没触发过的高闲置 skill。这个习惯值得保持。

5.3 工具升级后Skills失效

这方面我踩过最大的坑是：Claude Code 版本升级后，原先能正常触发的 skill 忽然不识别了，对话里 AI 完全无视技能包。排查了半天，最后发现是版本更新改变了 skill 解析的目录优先级或 frontmatter 格式要求。

这类问题没有一劳永逸的解法，尽量做到两点：第一，升级前看更新日志，确认有没有关于 skills 机制的 breaking change；第二，每次升级后，主动跑一遍“触发测试”，把经常用的三五个 skill 各试一次。不要等急用了才发现坏了。

另外提醒一下：不同工具的 skills 体系标准并不统一，同一份SKILL.md在 Claude Code 里正常，换到 Codex 或 OpenCode 里可能完全不认。跨工具使用时，免不了要针对每个工具做适配。目前社区也在推动通用的 skills 规范，但还没到一把梭的地步。

5.4 排查技巧：给Skill写一份“调试用例”

如果你经常自己写 skill 或者维护技能库，我强烈建议给每个 skill 配套一份“调试用例”，内容很简单：写 3 到 5 条应该命中的提问示例、以及 2 条不应该命中的反问示例。放到 README.md 里，每次改完 skill 就跑一遍。

别小看这个习惯。skill 是提示词工程的一种，而提示词工程的核心难题就是“不可控”。有了固定的测试用例，你每次修改后能立刻知道哪句变化产生了影响，而不是凭感觉。我自己维护的几个 skill，迭代几版之后，行为稳定性和初版完全是两个水平。

关于如何学习 skills，我最朴素的经验就一句话：先抄、再改、最后自己写。抄一个官方仓库的小 skill，原样用明白它的触发逻辑；然后改掉里面的指令，适配自己的场景；等改顺手了，再按自己的习惯从头写一个。不要一上来就追求从零原创一个三十六章经式的巨型技能包，那是低效的。

最后再分享一个小技巧：写 skill 的 description 时，我会刻意用一句“当用户需要xxx时使用”作为开头，后面补一条“使用本技能时必须先完成xxx”的前置动作。这能让 AI 在触发时自动带上执行顺序，而不是一上来就乱输出。你把这个习惯内化到所有 skill 里，整体稳定性会提升一个台阶。