企业官网建设流程全解析

最近一段时间，我身边的同事、社群里的朋友，几乎都在折腾同一样东西：AI编程工具里的skills。Claude Code装完你大概率会被建议去配几个skills；Codex、opencode这类工具也在跟进；就连做数学建模比赛、AI漫剧创作的同学，都在问“哪几个skills最好用”“GitHub上的skills怎么手动装”。如果你也正处于“听说了很久、但还没真正用起来”的状态，这篇文章应该能把最关键的问题讲清楚：skills到底是什么，以及装好了它之后你的工具使用体验会发生什么变化。

我用了一个多月，把几十个skills翻来覆去地装、用、删，也从一开始只会复制别人配置的纯新手，变成现在能按自己的需求写SKILL.md。整个过程里踩的坑不少，但收获更大。下面是我觉得最值得沉淀下来的内容，从原理讲到手动安装、从推荐清单到自研模板，一步步来。

1. 先搞懂skills和普通prompt的差别，这决定了你会不会用

1.1 一句话解释skills：把老手干活的方式固化下来

先说最直观的理解。skills本质上不是一个插件，也不是一个独立运行的程序，它是一套给AI模型看的“工作手册”，正式点说就是“系统级提示词+示例+流程约束”的集合体。

举个例子：你让AI给你写一个React组件。裸用prompt，模型的反应是“你让我写，我就按我脑子里常见的方式写”，结果经常是能用但不符合你项目里的规范，没有测试、没有类型定义、文档风格也对不上。而你装了一个“前端组件生成skill”之后，模型在接到“写一个Button组件”这个请求时，会被skill里的说明引导着做三件事：先看项目里的组件规范，再按规范生成包含类型定义和测试的完整文件，最后按项目模板输出文档。整个过程像不像一个刚入职的新人，突然拿到了一本老员工写的《从需求到上线的标准操作手册》？这就是skills的核心价值。

所以千万别把skills和普通prompt关键词混为一谈。普通prompt是“一次性请求”，而skill是“一次定义、多次复用的整套方法论”。当你把某个领域的全部know-how写进SKILL.md，再让AI在需要的时候主动加载它，这个AI就从一个“什么都会一点的通才”，变成了某个岗位上的“熟练工”。

1.2 skills、prompt和MCP：三者的边界在哪里

很多人把skills和MCP搞混，我在刚开始用的时候也没少闹笑话。这里用一张表格把它们的区别说清楚：

MCP相当于给AI接上了“手和脚”——比如让它能查数据库、发请求、操作文件；skills则相当于给AI配了“大脑里的工作逻辑”——告诉它拿到工具之后按什么节奏做。两者配合起来效果最好，但skills的准入门槛更低，因为它本质上就是一个按特定格式写的Markdown文件，不需要单独写服务器，也不用处理什么鉴权协议。

1.3 为什么说skill数量的质量基本等于你的AI生产力上限

这里我想多说一句可能反直觉的话：决定AI编程工具上限的，不是模型版本新不新，而是你给它配的技能体系全不全。

同一个模型，装上合适的skills之后，在特定任务上的表现能拉开一个档次。比如“从设计稿还原页面”这个场景。没有skill时，AI会老老实实给你写一堆看起来差不多、但细节经不起推敲的HTML/CSS；有了一个包含常见设计系统、响应式断点、样式命名规范的skill之后，它输出的代码审美和工程规范都会立刻在线。我自己感受最深的变化是“代码审查”这个任务，手工让AI审查，它总是蜻蜓点水，好像什么都看了一遍又什么都没看；装了一个专门做code review的skill后，它会按架构、性能、可维护性、安全隐患几个维度逐项排查，输出的问题清单比很多同事提的意见还细。

1.4 SKILL.md内部到底长什么样

所有skill的核心文件都叫SKILL.md，一般长这样：

--- name: frontend-component-builder description: 根据需求生成生产级前端组件。当用户需要新建组件、还原设计稿、生成UI代码时，优先使用本技能。 --- # 组件生成流程 1. 先确认技术栈与组件库。 2. 查阅项目中的样式规范与命名约定。 3. 输出TypeScript类型定义、组件实现、样式文件和单元测试。 4. 补充Props文档与使用示例。 ## 输出要求 - 组件必须包含类型注释。 - 测试必须覆盖正常状态和空状态。 - 禁止使用内联样式，除非组件需要动态变量。

文件头部用三根短横线包起来的部分是frontmatter，name字段是技能的唯一标识，description字段极其重要，因为AI就是靠读description里的描述来决定当前任务要不要调用这个skill。后面的正文部分就是给模型看的工作流程、约束和输出规范。理解了这一层结构，后面手动安装和自研就都顺理成章了。

2. 手动安装GitHub上的skills：没有图形界面入口时最稳的路径

2.1 安装前先确认工具认哪个目录

不同工具对自己的skills目录约定不完全一样，但基本都是固定路径，安装前要心里有数。我整理了一份目前主流工具常用的目录位置，你按自己用的工具对照一下：

如果你用的工具版本更新导致路径变了，直接在官方文档里搜“skills directory”就能找到。装了多个AI编程工具的同学，建议别偷懒，每个工具的路径都单独建目录，养成习惯后面管理不慌。

2.2 手动安装的四个标准步骤

以GitHub上最常见的skills仓库为例，手动安装不需要什么特殊工具，纯命令行操作。核心逻辑就是：把skill文件下载下来，放进对应的skills目录里。

第一步，先确认你已经登录了GitHub CLI或配置好了个人访问令牌。如果你之前从来没配过，用下面的命令快速搞定登录：

gh auth login

按提示选择浏览器授权或粘贴token，看到Logged in as的字样就说明没问题。如果不方便用gh，也可以手动复制整个仓库zip包再解压到目标目录，同样可行。

第二步，进入你的目标skills目录，把GitHub上那个仓库clone下来：

cd ~/.claude/skills git clone https://github.com/anthropics/skills.git

这是我比较推荐的方式，因为anthropics/skills这个仓库是官方维护的，里面有大量示例级skill，结构规范，适合当“种子库”用。如果你想装的技能不在这个仓库里，那就把URL换成对应的仓库地址。

第三步，处理“每个skill应该单独占一个目录”的问题。很多GitHub仓库是“一个仓库里装了十几个skills”，但AI工具默认只会去skills文件夹的直接子目录里找SKILL.md。如果直接把整个仓库clone进skills目录，可能会导致一堆技能没被识别。稳妥的做法是：克隆之后进仓库里看看结构，把单个skill的文件夹复制到~/.claude/skills/下：

cp -r ~/.claude/skills/anthropics-skills/skills/xxx-skill ~/.claude/skills/

如果整个仓库本身就是单一的skill，顶层直接是SKILL.md，就不需要这步了。

第四步，验证目录结构。完事之后要看一眼：

ls ~/.claude/skills/

正常应该看到形如skill-name/SKILL.md这样的结构，每个skill一个独立文件夹，里面有SKILL.md和配套的示例文件。

2.3 装完后怎么验证真的生效了

目录里有了文件不代表就一定能被AI自动识别。我自己的验证方法特别土，但也特别有效：重启一次工具会话，然后用一句能触发该skill描述的话去问。

举个例子，如果装的skill描述里写的是“当用户需要设计数据库表结构时使用”，那我就直接输入“帮我设计三张业务表的库表结构，包含索引和关联关系”。如果工具在答复前自动加载了对应技能，或者给出了明显带有该skill风格的输出（比如遵循了里面的步骤要求），就说明生效了。有的工具会显示“加载了xxx技能”之类的提示，看到了基本就稳了。

如果发现AI完全没提这个skill，大概率是description写得不够明显，或者目录位置放错了。重新调整描述第一句话，或者把它挪到更标准的路径，再试一次。

2.4 卸载和清理要注意的事

卸载skill其实没什么好纠结的，直接删掉对应目录即可：

rm -rf ~/.claude/skills/某个不需要的skill

但有两件事必须提醒。其一，github仓库更新之后，你本地clone的旧版本不会自己同步，需要定期git pull。尤其是那些热门仓库，作者更新很勤，不同步就跟不上了。其二，千万不要图省事用“整站同步脚本”一股脑把所有GitHub仓库都拉下来，skills装太多之后，AI每次调用都要在庞大的库里做匹配，反而影响响应质量，还可能在多个skill描述之间产生冲突。我的经验是，精装5-8个核心领域技能，效果远好于囤100个。

3. 哪些skills值得优先装：按使用场景挑，别贪多

3.1 前端开发：组件生成与UI还原类

这一块是GitHub上skills最多的赛道，也是新手最容易“装了就后悔”的区域——因为很多skills写得很水，只是把prompt换了个壳。真正好用的前端skill，至少要包含三样东西：项目技术栈说明、组件库规范、测试要求。比如让他生成组件时，会主动问你是用Tailwind还是纯CSS，会约束props必须带类型，会自动套Storybook格式的文档。

如果你主要用Claude Code或者Codex做前端页面，优先找“react-component-generator”“frontend-craft”这类命名的skill。用的时候也有讲究：别指望一个skill覆盖你所有场景，“生成组件”和“设计稿转代码”最好拆开，各管一摊。

3.2 代码审查与安全扫描类

第二个我非常推荐的方向是代码审查类。手动让AI审查代码最大的痛点是它“太客气”，总是先说代码写得好，然后象征性提几个小建议。好的review skill会强制AI按固定维度输出：架构问题、性能风险、安全隐患、可维护性、测试覆盖，每条给出具体行号和修改建议。装了这个以后，你再让AI“review这段代码”，出来的结果会专业得多，基本可以直接当团队评审材料用。

选择这类skill时，优先看仓库里有没有现成的“输出模板”文件。有模板的skill通常说明作者真的思考过“如何让输出可执行”，而不只是让AI自由发挥。

3.3 数学建模与竞赛类：为什么这类skill特别受学生欢迎

最近“华为杯”“国赛”这些比赛季，数学建模skills的需求量突然就上来了。我自己虽然不参赛，但看社区里的讨论很有感触。数学建模赛题一般分三种类型：偏物理机理的、偏数据分析的、偏优化决策的。对应的skill要解决的问题其实很明确：如何把一道开放性赛题快速拆解成“问题重述、假设、符号说明、模型建立、求解、灵敏度分析、论文框架”这样的标准流程，以及如何把整个思路用LaTeX格式输出。

这类skill建议去GitHub搜索“math-modeling”或“MCM/ICM”关键词，很多是往年参赛学生开源出来的，里面通常还带着赛题模板和排版示例。但说句正经话——skill能帮你把论文框架和代码组织得更好，不能替代你自己完成建模推导和实验验证。比赛要的是理解问题、亲手求解的能力，AI只是帮手，这个边界自己心里要有数。

3.4 内容创作与AI漫剧类

你可能会意外，“AI漫剧”居然也是skills的高频使用场景。说白了，做漫剧最头疼的不是“能不能生成一张图”，而是角色一致性和分镜连贯性。没有skill的时候，每次让AI生成都像在开盲盒；配了专做漫剧脚本与分镜的skill后，通常在目录里维护一份角色设定表、场景描述库、分镜模板，SKILL.md则规定每次生成前先确认主人公外貌、服装、场景关键词，然后再出图。

如果你也是做创作内容的，可以在skills库里搜索“comic-script”“storyboard”相关字眼。装完之后要有意识地往里面填充你自己的角色设定，因为再好的skill也只是框架，真正让角色“长在”项目里的，是你喂给它的设定文件。

3.5 数据处理与分析类

最后一个高频方向是数据处理。写Python处理Excel、清洗csv、做透视表，这些工作本身不复杂，但每次都要从头梳理“数据里有什么缺失值、类型对不对、异常值怎么筛”，总觉得很繁琐。一个成熟的数据分析skill会让AI先输出变量探查结果，再和你确认清洗规则，最后统一生成代码和可读图表。相当于给数据处理流程加了一层“先计划再动手”的缓冲，分析质量会稳很多。

4. 自己写一个skill其实不难：按这套模板来，十分钟搞定

4.1 动手之前先想清楚：你要固化的是一个什么流程

很多人觉得写skill是件高级的事，其实不然。我建议第一次尝试的人，选一个自己日常工作里重复频率最高的任务，最好是一个你已经形成固定方法的流程。比如“接到一个需求，怎么拆任务、排优先级”就是一个很好的切入点。你越是熟悉这个流程，就越容易写出能让AI照做的指令。

如果把“写good skill”比作“教实习生干活”，你就明白问题在哪了：光说“认真一点”没用，你得告诉实习生“先看什么，再做什么，什么情况下做什么，什么情况下不做什么”。skill正文里这些东西写得越具体，AI的表现越好。

4.2 SKILL.md的骨架模板直接抄

我实际用下来觉得最顺手的模板是这样：

--- name: task-splitter description: 将一段杂乱的需求描述拆解成可执行的任务清单。当用户需要规划、拆解需求、整理任务列表时，优先使用本技能。 --- # 任务拆解流程 1. 读取用户输入，区分“目标”“约束”“已有资源”三类信息。 2. 如果需求边界模糊，先用最多三个问题向用户确认，不要自行猜测。 3. 将目标拆成独立可交付的任务，每个任务包含验收标准。 4. 按依赖关系排序，标注可并行任务。 5. 输出Markdown清单，包含优先级、预估顺序、依赖。 ## 场景示例 输入：做一个登录页面 输出：任务1-确认登录方式（手机号/邮箱/第三方）...

记住三个关键点。第一，name要短，容易记忆。第二，description前三行要写清触发条件，AI靠它判断是否启用这个技能。第三，正文里要有“步骤+输出格式”，不能让AI自由发挥，否则skill就退化成普通prompt了。

4.3 配套的示例文件与参考输出别省

只有SKILL.md也能跑，但效果会差很多，因为模型缺少“好结果长什么样”的参照。所以我现在写skill，习惯给每个skill建一个examples子目录，里面放1-2个输入输出对。比如任务拆解skill的例子文件里，我放了一段用户原始输入，配一份拆好的任务清单，AI看到之后就更容易模仿输出形式。

结构大致这样：

task-splitter/ ├── SKILL.md ├── examples/ │ ├── input.md │ └── output.md

这个方法对任何领域的skill都管用。AI模型本质上是“看到好例子才好办事”的，给它喂一个具体的高质量输出，胜过你在指令里解释一百句。

4.4 写完调试的三个质量检查项

写完之后别急着用，先做一轮自查。我总结了三个质量标准：

• 指令够具体吗？如果正文里充斥着“合理地规划”“高效地分析”这种形容词，那就等于啥都没说。改成“先检查数据缺失值，再确认字段类型，最后输出三个独立表格”这种可执行动词。
• 过程可迭代吗？好的skill不会一步到底，而是会在关键节点停下来和用户确认。写skill时主动留出“确认点”的位置，比如“完成阶段一后，向用户展示结果，确认无误再继续”。
• 输出可验证吗？如果任务输出是代码、文档、表格，就把格式要求写清楚。代码要有类型、文档要带目录、表格要说明字段来源。否则输出漂移问题会折磨你。

我自己第一次写的“数据处理skill”，就是因为输出格式写得不够死，结果AI每次都给我吐不同风格的代码，直到把输出规范细化到“函数名用下划线、dataframe输入、返回统计摘要”这种颗粒度，才真正稳定下来。

5. 维护与清理：skills装多了之后踩过的坑

5.1 用目录和命名建立你自己的“技能库”

用了一阵子之后，你会发现skills的维护其实和代码库管理很像。我现在的做法是建立了一个~/.claude/skills/大目录，里面按领域分类建子目录，每个skill自带README，写上来源仓库地址、最后更新时间、用途说明。刚开始觉得这步多余，但等你的skills数量过十几个之后，没有备注绝对会认不出哪个是哪个。

我还习惯用Git管理这个skills目录本身。如果有重要修改，就提交一次版本记录，这样哪天改坏了还能回滚。对非程序员朋友，只要记住“把skill文件夹当成普通文件来备份管理”，就完全够用了。

5.2 GitHub仓库的时效性：旧skill比没有skill更可怕

这是我最想强调的一个点。AI工具迭代很快，以前写出来的skill描述风格、文件结构，新版本可能已经不完全匹配了。比如一些早期的skill还在用旧版的frontmatter字段，新工具虽然能解析，但触发效果会打折扣。建议每两周抽空检查一遍常用仓库的更新记录，看到“breaking changes”提醒，就及时看看说明。

同时，针对那些“超多star但长期没人维护”的仓库，我现在的态度是直接不用。skill的价值在于它和当前工具的契合度，仓库停在两年前，里面写的流程很可能已经过时，AI建模逻辑一变，旧指令还会干扰新输出。清理掉它们，比留着当心理安慰更有用。

5.3 一个个人爱好：给自己的常用工作流写一套“微技能”

如果你已经把现有skills用顺手了，我还有一个建议：除了那些大而全的领域技能，试着给自己的工作流写一些只有几十行的“微技能”。比如我给自己写了一个“消息回复快译”的micro skill，规定任何领导发来模糊的“这事儿你再看看”，一律先归类、再拆分、最后给出“已确认/待确认/需补充”三栏回复。这个skill不到三十行，但每天帮我省下的心智成本比任何大skill都多。

skills的价值不在于装得多、装得新奇，而在于它是不是真的贴合你的高频工作场景。从官方仓库复制，再从自己的重复劳动里提炼，两条路同时走，你很快就能配出一套属于自己的、高生产力的技能组合。