企业官网建设流程全解析

最近AI编程圈子里，"skills"这个词出现的频率高得离谱。从Claude Code到Codex，再到OpenCode，几乎每个主流AI编码工具都在推自己的技能体系。朋友圈里有人晒出装满几十个skill的目录截图，像在炫耀新收藏的游戏皮肤；也有人装了半天发现AI根本不理他，回来求救。作为一个把Claude Code和Codex都重度用到日常开发里的老玩家，我今天想把这套东西彻底讲透：skills到底是什么、为什么值得装、怎么写自己的、怎么从GitHub手动安装、怎么清理维护。全文不整虚的，全部是能直接抄作业的操作。

1. Skills 到底是什么：一套让模型"瞬间起飞"的外挂技能包

1.1 从"提示词越来越长"这个痛点说起

用过AI编码工具的人都有体会：为了让模型稳定地产出符合预期的代码，你得在项目里塞一大堆说明文件。今天加一条"组件放src/components下"，明天补一段"接口返回格式必须统一"，后天再追加"样式用Tailwind，别用CSS Modules"。很快，一个项目的上下文里塞了好几千字的规则，模型每次都要处理这些冗长指令，响应变慢，偶尔还会互相打架。

更麻烦的是，这些规则是死的。你写前端时需要的规范和你做数据分析时需要的流程完全不同，可它们全挤在一个配置里，模型只能自己分辨该用哪条。这就是文件名带s的"技能"体系出现的原因——它把一组高度相关的指令、脚本和参考资料打包成一个独立单元，按需加载。模型先看目录里每个技能的简短描述，判断当前任务匹配哪个，再把这个技能的内容注入上下文。

说人话：skills就是给AI模型装的外挂技能包。不触发的时候完全不占资源，触发的时候才展开，比把所有经验写成几千字塞进系统提示词高一个维度。

1.2 一个 skill 的目录到底长什么样

官方定义里，一个skill就是一个包含SKILL.md文件的目录。这个文件是核心，里面用Markdown写了这个技能的工作流程、约束条件和代码规范。除了它，目录里还可以放辅助脚本和参考资料，形成一套完整的"运行环境"。

我日常用的一个前端审查skill目录结构长这样：

frontend-review/ ├── SKILL.md ├── scripts/ │ ├── check_imports.py │ └── analyze_bundle.py └── references/ └── team-conventions.md

SKILL.md负责告诉模型"你该按什么步骤做、遵循什么规范"，scripts/里的Python脚本负责执行具体检查，references/里的资料是模型参考用的细节文档。三者配合，AI拿到任务后先读主文件，需要跑脚本就执行脚本，需要查细节就翻参考资料。

核心文件的开头是一段YAML格式的元信息：

--- name: frontend-review description: 当用户要求审查前端代码、检查React组件结构、优化页面性能时使用该技能。触发词：代码审查、重构、性能优化。 ---

name是这个技能的标识，description是让模型判断"什么时候该用我"的依据。别小看这段描述，它决定了技能会不会被正确触发，我后面会专门讲怎么写它。

1.3 不同工具的 skills 实现差异

现在主流工具对这个概念的叫法和落地方式不完全一样，我用下来最大的体感区别在"存放位置"和"触发机制"上。

Claude Code把skills放在~/.claude/skills/目录下，每个子目录对应一个技能，官方还专门做了一个示例仓库anthropics/skills。它的加载机制比较聪明：启动时会扫描目录，把所有技能的描述收集起来，任务来临时动态匹配，命中后把整个skill目录的内容塞进上下文。

Codex的体系更偏向"配置文件+技能包"的组合。项目根目录的AGENTS.md负责写全局规则，skills则放在~/.codex/skills/或项目级目录里，可以理解成在基础指令之上叠加的专业模块。我实测下来，Codex对skill的触发比较依赖描述里的关键词，描述写得越长越具体，触发越准确。

OpenCode作为新秀，技能结构跟Claude Code类似，社区里已经有不少现成库可以直接用。

选择工具之前建议先想清楚需求：如果主要做日常编码辅助，Claude Code的生态最成熟；如果更在意指令的精细控制，Codex的AGENTS.md机制更顺手。

2. 手把手写一个属于你自己的 skill

2.1 先定场景，再写描述

很多人一上来就写指令，写到一半发现模型根本不按预期触发，于是反过来怀疑工具坏了。我的经验是：先定触发场景，再写技能内容。

问自己三个问题：

• 什么情况下用户会需要这个技能？
• 用户大概率会用什么词来描述这个需求？
• 这个技能最终要交付什么结果？

比如我想写一个"数学建模竞赛辅助"技能。用户来找你时可能说的是"帮我做赛题分析""这个题目怎么建模""求个预测模型"，甚至直接甩过来一个题目文件。那么描述就覆盖这些表达：

--- name: math-modeling-helper description: 适用于数学建模竞赛场景，包括赛题理解、模型选型、数据预处理、灵敏度分析、论文结构规划。当用户提到建模、赛题、拟合、预测、评价模型或上传题目文件时优先触发。 ---

触发场景描述得越具体，AI越不会误判。反例是只写一句"处理数学建模问题"——太泛了，模型在普通数学问题时也可能调它，最后得到一堆预设步骤，反而误事。

2.2 SKILL.md 的写法与三个关键点

主体部分建议按"目标-步骤-约束-输出"四段式组织。我写一个AI漫剧分镜技能做个示例：

# 漫剧分镜辅助 ## 目标 根据用户提供的剧情文案，生成适合AI生成工具使用的分镜脚本和画面提示词。 ## 工作流程 1. 提取剧情中的角色、场景、动作、情绪变化。 2. 按3-5秒一个镜头切分戏剧节点。 3. 为每个镜头编写画面描述，包含角色状态、环境光线、镜头运动、氛围词。 4. 输出结构化JSON，并附带改图参数的对比表。 ## 约束 - 角色描述必须保持外观的一致性，复用同一段外貌提示词。 - 运镜指令使用固定词表：推、拉、摇、移、跟、升降。 - 不生成任何露骨、暴力的画面描述。 ## 输出格式 每个镜头包含：镜头编号、画面描述、提示词模板、参数建议。

三个关键点实践下来受益最大：

第一，步骤要可执行。别写"分析剧情"这种空话，要写"提取角色、场景、动作、情绪变化"这种模型能直接照做的操作。第二，约束要防呆。把不该出现的元素、不可跨越的边界直接写死，减少违规概率。第三，输出要有格式。给一个明确的JSON结构或表格模板，模型产出的东西才能直接用，而不是凭空发挥。

2.3 写完怎么验证它真的生效

写完之后立刻验证，别等用到时才发现。我最常用的验证姿势：

# 确认目录结构 ls ~/.claude/skills/math-modeling-helper/

然后打开Claude Code，直接问一句"你现在有哪些技能可用，列一下名称和用途"。如果列表里没出现新技能，说明目录位置不对或frontmatter解析失败。如果列表里出现了，再触发一次场景，比如"帮我分析一个预测类赛题"，观察它是否真的加载了对应技能的内容。

验证时我最爱干的一个小动作是：故意换几种说法触发同一个技能。比如对漫剧技能说"帮我拆分一下这个剧情"，再说"这集分镜给我出一版"，看两次是否都稳定触发。触发不稳定，八成是描述里的触发词覆盖不够，补词就行。

3. 从 GitHub 手动装 skills：三步走

3.1 找到靠谱的来源

GitHub上的skills资源丰富，但质量参差不齐。我的筛选标准就三条：

• 看仓库更新时间，半年以上没动的直接跳过。
• 看SKILL.md写得是否具体，只有一句话描述的基本是占坑。
• 看目录结构是否完整，正规技能库一般有示例、有文档、有版本说明。

值得关注的几类仓库：

• 官方示例集：anthropics/skills，适合入门对照。
• 社区知名套装：比如obra/superpowers，包含规划、调试、测试驱动开发、代码审查等一整套技能。
• 垂直领域技能集：typesafe-ai这类围绕类型安全的技能库，适合前端/全栈方向。
• 个人维护的精选列表：搜"awesome ai skills"一类的合集，里面整理了大量分散的仓库。

3.2 clone 下来放到正确的目录

以Claude Code为例，完整流程我走一遍：

# 1. 克隆官方示例集 git clone https://github.com/anthropics/skills.git # 2. 查看目录结构 ls skills/ # 3. 只拷贝自己需要的skill cp -r skills/artifact ~/.claude/skills/ cp -r skills/svg ~/.claude/skills/

Codex的路径稍有不同，现在一般通过配置文件夹加载：

mkdir -p ~/.codex/skills cp -r ./superpowers ~/.codex/skills/

如果只想装仓库里的单个技能，也可以直接在GitHub网页上进入该技能目录，下载目录里的文件，再手动放到本机对应目录。注意层级：SKILL.md必须放在skill目录的根下，别套一层多余的文件夹，否则工具扫描不到。

3.3 装完必做的检查清单

装完不要急着干活，先过一个检查清单：

1. 目录位置对不对：Claude Code看~/.claude/skills/，Codex看~/.codex/skills/。
2. 文件层级对不对：SKILL.md是否在根目录，scripts是否是独立子目录。
3. frontmatter是否完整：name和description两字段缺一不可，格式错误直接跳过。
4. 是否触发冲突：和已有技能重名，会出现一个覆盖另一个的情况；描述高度重叠，则会出现随机选择的问题。
5. 权限是否可用：技能里的脚本如果依赖Node/Python环境，先手动跑一遍确认没有依赖缺失。

我见过太多人卡在第三步，原因五花八门——YAML缩进不对、description里冒号后面忘了空格、文件末尾多了个奇怪的符号。一个最笨但最有效的办法：复制一段已知能用的frontmatter，只改name和description字段。

4. 实战推荐：按场景挑选 skills 的参考思路

4.1 前端开发的技能组合

做前端，最值钱的是把团队规范固化成技能。我常驻的一套组合包括：

• 代码审查技能：内置组件拆分原则、命名规范、样式约束，任务来了自动按团队标准过一遍代码。
• React项目脚手架技能：包含目录结构模板、路由配置模式、状态管理选型流程。
• 性能优化技能：把常见的性能问题诊断路径（首屏、打包体积、重复渲染、资源加载）写成固定排查步骤。

这类技能的共同特点是：把平时得翻文档、问组长、对着旧代码猜的经验，变成了模型随手可用的规则。新人上手时尤其受益，问AI的问题里涉及的隐性约束，技能文件里已经写清楚了。

前端技能的坑在于版本迭代快。半年不更新，技能里写的"推荐使用CRA"可能早就过时了，所以要养成定期检查技能内容版本的习惯。我会在技能里加一行"适用范围提示"，标注适用于哪些框架版本，避免模型对老项目也推新方案。

4.2 数学建模竞赛玩家的搭配

数学建模是我看到不少人在用的场景，特别是华为杯这类时间紧张、流程固定的比赛。这类技能的价值不在"帮你算出答案"，而在把建模套路固化成流程，减少临场决策成本。

我分享一个经过实际检验的建模搭配思路：

• 模型选型技能：内置"赛题类型→候选模型"对照表，看到题目能快速定位该用回归、分类、优化还是评价模型。
• 数据预处理技能：固定处理流程——缺失值检查、异常值清洗、归一化方法选择、特征工程步骤，省去每次手动交代。
• 论文排版技能：内置竞赛论文的标准章节结构，包括问题重述、模型假设、模型建立、求解、灵敏度分析、优缺点评价，连图表编号规则都写进去。

竞赛场景下我最看重的其实是"灵敏度分析"这一块。很多队伍做完模型就交卷，评委一问参数变化对结果的影响就答不上来。如果把灵敏度分析写成标准步骤，强迫模型在每次建模后都做参数扰动和稳健性检验，论文质量会明显提升。

这类技能要注意别把模型写死。建模比赛最忌讳套模板，技能里应该给"模型选择决策树"而不是"必用XX模型"。

4.3 内容创作（AI漫剧）方向

最近AI漫剧很火，核心痛点是"分镜不连贯"和"角色不一致"。用技能包能解决大部分问题。

一个分镜技能至少包含：

• 角色一致性约束：固定外貌提示词，每次生成都复用。
• 分镜节奏模板：3-5秒一个镜头，按情绪曲线分配全景、中景、特写。
• 运镜词表：固定的推拉摇移术语，避免模型自己造词导致生成效果失控。
• 输出结构：镜头编号、画面描述、提示词模板、参数建议，方便后续批量执行。

内容创作类技能的最大坑是"提示词越写越极端"。为了让画面出效果，有人会把负面提示词堆到上千字，结果生成结果反而僵化。我的建议是技能里只约束必需的边界条件，给模型留出创意发挥的空间，宁可描述少一点，也别把AI的手脚全绑上。

4.4 值得关注的几个技能库

分享几个我实际用过且觉得可以推荐的来源，按使用场景分类：

• anthropics/skills：官方示例，内容中规中矩，适合理解标准写法。
• obra/superpowers：社区热度很高的套装，主打"让AI帮你规划、拆解、验证"，适合需要流程化工作的场景。
• typesafe-ai：面向TypeScript全栈方向的技能集，代码示例丰富，适合偏工程质量导向的团队。
• 各类领域合集：在GitHub上搜"awesome skills"或"skills collection"，能发现不少按tag整理好的列表。

我的建议是不要一口气装一堆。一个工具装3-5个核心技能，用一段时间，再逐步增补，效果比囤50个技能好太多。

5. Skills 的管理与清理：加装容易维护难

5.1 为什么要定期清理

技能是会堆积的。今天看到一个调研技能不错，装上；明天看到一个代码生成技能，装上；后天又看到一个论文审查技能，装上。用不了一个月，skills目录里躺着几十个技能，表面看是"武器库丰富"，实际是灾难。

首先，技能数量过多会拖慢启动时的描述收集，工具的响应速度肉眼可见地下降。更麻烦的是，AI的触发逻辑会在多个相似技能之间摇摆——比如你装了"Python代码审查"和"通用代码审查"两个技能，任务来了它得纠结该用哪个，表现出来就是行为不稳定，有时候触发这个有时候触发那个。

所以社区里一直有人强调"断舍离"，tibo分享过的一套方法我实践后很受用，核心思路就一句话：只留你最近一周真正用过的技能。

5.2 清理思路与方法

我的清理流程分四步：

第一步，摸底。列出当前所有技能：

ls -la ~/.claude/skills/

第二步，体检。逐一看每个技能的使用价值，重点自查三件事：SKILL.md的描述是否准确、和现有其他技能是否重叠、最近一次实际帮到忙是什么时候。

第三步，分类处置。长期没用但舍不得删的，挪出技能目录，放到备份目录去。明确没用且描述平庸的，直接删。有重叠的，合并到主力技能里，删掉冗余的那个，减少模型的决策负担。

第四步，复查。清理完重启工具，确认启动速度和触发准确率都有改善。

我自己常用一个维护技巧：每次清理完，会在~/.claude/CLAUDE.md里记一行"当前保留技能清单及启用日期"。下次再想装新技能，先看清单，如果同类已有一个，就先明确差异再决定是否安装。这比完全靠脑子记靠谱多了。

5.3 一套贴身的维护节奏

维护节奏我建议按"项目期"而不是"时间"来走。比如一个项目开始前，是往技能库里增补的好时机——根据项目技术栈把对应技能一次性配齐。项目进行中尽量不加装，避免干扰已稳定的触发逻辑。项目结束后，是清理的最佳时机，把这次用不上的技能归档，把高频使用的技能记录下适用范围。

养成定期查看技能描述的习惯。很多技能装上之后，工具升级、模型更新，描述里的触发词可能不再适应新版本。保持描述和实际行为一致，是长期稳定使用的秘诀之一。

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

6.1 装上却不触发

这是问得最多的一种情况。技能装好了，列表里能看到，但任务来了就是不触发。排除目录和frontmatter格式问题后，问题多半出在描述上。

我的排查思路：先看description里写的触发词是否和用户表达习惯一致。前端审查技能写的是"代码审查"，但用户实际说的是"帮我看看这段代码写得怎么样"，模型就不会往审查方向匹配。

改进方法有两种。一是扩充触发词，把同义表达都列上。二是改用"行为描述式"写法——不写名词，而写"当用户描述他们遇到代码质量问题，或请求对代码运行情况进行分析时使用"。行为描述式比关键词列举的泛化能力更强，我自己现在偏向后者。

6.2 上下文被吃垮

打开一个强技能后，模型要处理SKILL.md加上一堆脚本和参考资料，单次对话的tokens消耗比平时大不少。如果项目本身还挂着大文档，很容易撑爆上下文窗口，表现为回复变慢、中途遗忘、生成质量下降。

对策有两个方向。一是技能瘦身：把SKILL.md控制在合理篇幅内（我的经验是核心指令不超过100行），参考资料尽量精简，scripts脚本只保留必需的。二是把技能文件中的大表格、长代码库挪到单独文件，需要时才让模型grep来取，而不是一触发就全量加载。

6.3 和其他配置打架

技能与CLAUDE.md/AGENTS.md里的全局规则冲突时，模型容易陷入混乱。比如项目级规则说"统一使用pnpm"，但技能里写的是npm命令，最后它先按pnpm装一遍，又按技能跑一遍npm命令，场面很难看。

我的约定是：全局配置管约束，技能管流程。全局规则里只写项目不可妥协的红线，具体操作细节全部下放到技能。如果两者冲突，我会在全局配置里明确优先级声明，比如"当技能与本文件冲突时，以本文件为准"，或者反过来，视项目而定。

6.4 快速验证技能状态的小抄

把常用的验证命令和自查项整理成了一份速查表，有问题先过一遍再想复杂原因：

我个人在实际操作中的体会是：skills这套东西，最初的入门门槛在于概念理解，但真正拉开差距的，在于"会不会维护"。少装、精写、勤清理，远比堆数量重要。有一次我在整理目录时删掉了十几个技能，重启后的第一个任务响应速度明显变快，触发也稳定了，从那时起我就坚定了一个信念——这玩意儿跟冰箱一样，囤多了不会自动更新，只会发霉。

如果你正准备入坑，我的建议是别急着到处收集技能库，先挑一个小场景，亲手写一个只有几十行的SKILL.md，用起来，感受它到底怎么影响模型行为。这个过程跑通了，后面装什么、怎么装、怎么定制，都会顺手很多。