企业官网建设流程全解析

1. Skills到底是什么：AI代理的"岗位说明书"

上个月我在折腾Claude Code的skills功能，遇到一个特别典型的困惑：花了一晚上把GitHub上某个很火的skills仓库拉下来，按README装好，结果AI该不会还是不会，甚至没有意识到这个skills存在。后来我才意识到，问题不是出在安装步骤，而是我根本没弄明白skills的加载机制。

先说结论：一个skill本质上就是一个包含SKILL.md文件的目录。这个文件用Markdown写成，长得跟普通文档差不多，但里面藏了一套让AI代理"按规矩办事"的指令。你可以把它理解成给AI配了一本"岗位说明书"——普通对话是让AI即兴发挥，skills则是让AI按照一套固定的工作流程、输出格式、质量标准来执行任务。

为什么现在的AI编程工具（Claude Code、Codex、OpenCode、Cline这些都算）几乎都在往skills方向发力？因为底层模型的推理能力已经很强了，但"没有规矩"——你让它写前端页面，它能写，但不会自动遵守你们团队的代码规范；你让它做数学建模，它能算，但不会自动按照论文格式输出。Skills就是来解决"AI能力很强但不听话"这个问题。

理解了这层定位，你就能明白skills和几样容易混淆的东西的区别：

用大白话讲：Prompt是口头交代，Skill是写进SOP的流程文件，插件是给你加了双手，MCP是给你接了水管。Skills本身不连接外部世界，它管的是"AI怎么思考、按什么步骤做、输出成什么样子"。你完全可以写一个纯文字的skills，不碰任何脚本，也能显著提升输出质量——这一点很多人装了一堆带脚本的skills之后反而忽略了。最见功夫的skills，往往是用最朴素的文字约束把AI的行为掰到工程规范上来的。

我强烈建议你从"岗位说明书"这个视角出发去看待每一个skills：它的description相当于岗位名称，正文就是岗责清单，子目录里的脚本和模板就是工具箱。AI代理每次会话开始时扫描一遍所有skills的description，一旦发现某个任务跟你的岗位描述对得上，就把整本说明书加载进上下文，然后照章办事。这就是为什么skills能做到"按需加载"——它不会像系统提示词一样常驻上下文占用token，而是用"简历筛选"的方式只把匹配的那本说明书翻开。选对description，等于让你的岗位说明在海量简历中被AI一眼相中。

2. 从零学习Skills：三条最有效的入门路径

别说新手，我当时玩了快一个月skills，回头看才发现学习路径如果走对了，效率能翻好几倍。市面上讲"skills怎么写"的教程不少，但真正能把人领进门的，我总结下来是三条路，配合着走效果最好。

2.1 路径一：解剖成熟的skills源码仓库

学习skills最快的方式不是看文档，而是拆开源代码。去GitHub上搜awesome-claude-skills、claude-skills这类话题，找一个star高、结构清晰的仓库，把整个目录clone到本地，然后像解剖青蛙一样把它拆开看。

以Superpowers这个社区著名的skills库为例，它里面每个skill的目录结构基本都是这样的：

superpowers/ ├── SKILL.md ├── skills/ │ ├── brainstorm/ │ │ ├── SKILL.md │ │ └── templates/ │ │ └── brainstorm-plan.md │ ├── planning/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── create-plan.py │ └── ... └── ...

拿到这种仓库，你要重点看三件事：

第一，看SKILL.md的YAML frontmatter。第二，看正文的"总-分"结构。第三，看正文与脚本、模板之间怎么分工。

拿一个典型例子来说，Superpowers里brainstorm这个skill的frontmatter长这样：

--- name: brainstorm description: 在动手写代码之前，进行结构化头脑风暴，生成多个候选方案并评估取舍。当用户需求模糊、或面对开放性问题时使用。 ---

注意两个细节：name必须与目录名一致，这是约定；description则要写成"当用户遇到什么情况时，用这个技能做什么事"，而不是泛泛的"提供头脑风暴功能"。后面这种写法在真实场景里命中率很低，因为AI是靠description里的场景关键词来匹配的。

正文部分，成熟的skill一定会写清楚"目标是什么、禁止做什么、按什么顺序做、产出什么格式"。很多新手写的skills只有"你可以这样做"的建议，没有"不要那样做"的约束，结果AI还是放飞自我。检查一个skills好不好用，就看它有没有把"边界"讲明白。

最后看它如何引用外部资源。比如有个代码评审的skill，SKILL.md正文就一句话："按照templates/review-checklist.md中的清单逐项审查代码"，真正的详细清单全放在模板文件里。这种做法的好处是：主文档保持精简，AI不会因为加载了太多细节而模糊了核心指令。这种设计思路叫渐进式披露，后面我会展开讲。

2.2 路径二：围绕官方文档和社区源网站建立知识地图

光拆几个仓库还不够，你得知道这个生态的地图长什么样。

官方层面，Anthropic有一份关于Agent Skills的文档，把目录结构、SKILL.md格式、探测加载机制都讲得很清楚。Codex、OpenCode也有各自的文档。但官方文档的问题是只讲语法，不讲"什么叫写得好"，所以要把官方文档和社区实操结合起来看。

社区源网站我这里列几个我常去的：

把这些网站过一遍之后，你对"现在这个领域有哪些好skill、各家的风格差异、什么场景配什么skill"就有了基本概念。后续碰到具体需求，至少知道往哪搜。

2.3 路径三：修改现成skills，做"二次创作"式练习

大多数人的误区是想一口气从零写出一个完美skills，结果憋了一下午只写了一屏空话。我的建议是：别从零开始，先找一个贴近你需求的现成skills，从改description、调整工作流开始。

比如我最早练习时，把一个"前端开发"skills改成"文创页面开发"skills。原版只写了基础的代码规范，我往里加了跟业务相关的部分：页面风格要求、素材目录说明、交付检查单。改完实际跑一遍，AI的行为立刻有了肉眼可见的变化——之前我每次都要手动写一大段要求，现在一句话就能触发。

这种修改式练习的好处是：你不需要先懂skills的全部语法，只要把跟自己需求最相关的那几个字段改对，就能感受到"规则驱动行为"的威力。等到你改过三五个，再回头看怎么写，思路会清晰很多。

3. 安装实操：GitHub上的Skills怎么手动装进Claude Code

不少人在这一步翻车，而且翻车方式都差不多：照着README装完，输入命令却没有任何反应。手动安装GitHub上的skills，本质上是三件事：把仓库文件放到指定目录、确认目录结构合法、重启会话让AI重新扫描。只要把这三件事做对，就一定能跑起来。

3.1 确定目录位置：项目级还是用户级

Claude Code的skills存在两个层级：

• 项目级目录：.claude/skills/，跟着项目走，适合团队共享、随代码库分发
• 用户级目录：~/.claude/skills/，所有项目都能用，适合放个人常用技能

从某个仓库clone下来用于自己日常使用，放用户级；如果是某个具体项目的前端开发规范、数学建模比赛套路，放项目级更合理。一个仓库如果同时包含一个主SKILL.md和子skills，通常整个目录直接放在skills目录下即可。

3.2 完整的手动安装步骤

我用一个实际的例子过一遍。假设要安装GitHub上某个"前端开发skills"仓库，在项目根目录下操作：

# 1. 进入项目的.claude目录（没有就创建） mkdir -p .claude/skills cd .claude/skills # 2. 克隆仓库（只拉取这一个仓库） git clone https://github.com/example/frontend-skills.git

装完之后，检查目录结构是否满足条件：

.claude/skills/ └── frontend-skills/ ├── SKILL.md ├── templates/ └── scripts/

需要注意，SKILL.md这个文件名是固定的，不能叫skill.md或README.md。很多仓库的README写得很详细，但真正的技能入口文件是SKILL.md，如果发现仓库只有README没有SKILL.md，说明它的结构不合法，装进去也不会被扫描到。

第三步，检查SKILL.md的frontmatter里name字段是否跟目录名一致。如果不一致，AI扫描时会识别不到，你调用时也会失效。

第四步，在Claude Code里输入/skills命令，应该能看到刚装进去的skills列表。如果没看到，大概率是路径错了或者SKILL.md格式有问题，逐项排查即可。

第五步，用一句话触发它。这一步很多人会忽略，他们装完直接开始正常对话，完全不复用skills。触发时不要光说任务内容，最好带着技能的触发语境，比如"用前端开发skills的规范帮我做这个页面"，看AI是否按照SKILL.md里的流程走。

3.3 其他工具的手动安装差异

Claude Code手动装skills是最成熟的流程，其他工具的机制大同小异，但在细节上有区别：

• Codex：同样使用SKILL.md，但目录约定和Claude Code不完全一样，有的版本还支持通过codex.json指定skills路径，得看具体版本文档。
• OpenCode：通过配置文件opencode.json注册skills位置，自动发现能力不如Claude Code，更依赖配置。
• Cline等VS Code插件类工具：一般提供UI界面让你填skills路径，或者要求放在工作区下的约定目录。

如果你同时在用多个工具，建议给每个工具都建一个独立的skills目录，不要共用同一个仓库，否则description扫描机制不同会导致很多诡异行为。

提示：我最常踩的坑是安装后忘了重启会话。Claude Code通常在你打开会话的时候扫描skills目录，你中途装进去然后直接说一句话，它根本不知道多了个技能。养成习惯：装完skills，新开一个会话，签验。

4. 自己动手写Skills：一个可复用的AI技能从0到1

学习skills的终极目标肯定是自己写。在这里我直接用"数学建模比赛"这个高频场景来演示一个完整的、能跑的skills是怎么诞生的。市面上搜"数学建模skills推荐"之所以答案稀缺，不是没人写，而是很多作者把这东西当成黑魔法，不肯把底牌亮出来。其实没那玄乎，就是一套规则文本加几个模板。

4.1 起步：先想清楚这个skill要解决什么问题

一个好skills的前提是：它端住一个明确的问题。不要写一个"全能助手skills"——那等于没有技能。数学建模比赛里你要解决的问题通常是：AI做建模时总是答得很散、格式不统一、分析过程不完整、结论没有量化依据。所以这个skill的名字就叫math-modeling，它只负责一件事：把AI建模回答的流程和格式固定成比赛级别。

先建好目录：

.claude/skills/math-modeling/ ├── SKILL.md └── templates/ ├── problem-analysis.md └── solution-template.md

4.2 撰写SKILL.md：description是命门，正文是灵魂

打开SKILL.md，把frontmatter写好：

--- name: math-modeling description: 当你需要完成数学建模题目的分析、建模、求解、论文输出时使用。适合参加数学建模竞赛、完成数模作业时调用。该技能会引导进行问题重述、模型假设、模型建立与求解、灵敏度分析、论文排版。 ---

description高标准要求是：把触发场景写具体，动词开头，明确该技能干的活。像"进行数学建模"这种描述太寡淡，命中率低；"当项目经理给出一段模糊需求、需要写PRD时使用"这种描述就好很多。

正文部分，我习惯按这个骨架写：目标 → 流程 → 规范 → 输出模板 → 禁令。流程写得越细，AI越不自由发挥。数学建模这个skill的正文可以这样组织（节选）：

# 数学建模助手 ## 目标 输出结构完整、逻辑严密、可直接进入论文写作阶段的建模解答。 ## 工作流程 1. 问题重述：用自己的话复述题目，提炼已知条件、求解目标和隐含约束。 2. 模型假设：明确列出所有假设，并说明每条假设的合理性。 3. 模型建立：先定义变量和参数，再写目标函数、约束条件，用数学公式表达。 4. 模型求解：说明采用的方法，给出关键计算步骤和数据结果。 5. 灵敏度分析：至少对两个关键参数做±20%幅度扰动，说明结果稳定性。 6. 结论与展望：用数据和事实说话，不写空洞口号。 ## 输出规范 - 数学公式用LaTeX，变量用斜体。 - 每个模型必须列出适用范围和局限性。 - 所有数值结果保留三位有效数字。

最关键的是禁令：写明"不要直接给出最终答案而不展示推导过程"、"不要使用模糊表述'显然可得'、"不要跳过灵敏度分析"。AI特别容易犯"直接跳结论"的毛病，SKILL.md里把禁令写死，行为就稳了。

4.3 渐进式披露：模板文件怎么分担正文压力

如果你想写得更细，照上面那个流程，正文篇幅会急剧膨胀，AI加载也慢。好的做法是：SKILL.md里只写流程的骨架，把每个环节的详尽要求放进templates子目录。

比如templates/problem-analysis.md放问题重述的详细写法，templates/solution-template.md放标准解法模板。SKILL.md里一行指引即可："分析问题阶段，参照模板目录下的problem-analysis.md执行。"

我用这个结构写过前端开发skills、AI漫剧剧本skills，效果都非常好。AI漫剧那种场景，SKILL.md主文档只写了"分镜节奏、台词密度、反转设置"三句话，真正的案例分析和分镜模板放在templates里，AI每次使用时按需读取，既能保持主指令清晰，又不至于把上下文塞爆。

4.4 验证和迭代：写完之后就完事？远没完

写完SKILL.md，至少做三轮验证：

第一轮，直接触发："帮我做这套数学建模题目。"观察AI的行为是否符合流程。

第二轮，故意给模糊的问题："这题大概是个优化问题，你看看怎么做？"测试description是否能在模糊需求下命中技能。

第三轮，给一个跟技能无关的问题，确认它不会误触发。

跑这三轮你会很快发现：AI要么在步骤顺序上偷懒，要么输出格式还是不够规范。这些问题80%靠改SKILL.md文字就能解决，而且通常只要改一句话。我迭代自己最常用的skills，前后改了十几个版本，每次改完只做一次触发测试，成本很低，收益很高。

5. 生态盘点：常用Skills来源、工具差异与场景化配置

现在这个领域最让新人头大的，不是工具功能不够，而是选择太多、不知道谁是谁、什么东西可以信。我把它分三块讲清楚：工具的差异、第三方skills库、场景化配置思路。

5.1 主流工具的Skills机制横向对比

用下来我的体感是：Claude Code的skills生态最成熟，文档全、社区多、扫描机制稳定，新手入门选它最省心；Codex也在快速补齐，但它更像"代码洞察型"的机制，聚焦在代码库语境里；OpenCode手动配置感更强，适合喜欢一切可控的玩家。

5.2 值得收藏的第三方skills库和源网站

• Superpowers：社区老牌大步库，出自Jesse Vincent之手，里面的brainstorm、planning等流程性skills设计水准很高，我推荐每个想学skills的人把它从头到尾读一遍，很多设计思路是教科书级别的。
• TypeSafe AI skills仓库：TypeScript圈很扎实的开源集合，里面的工程规范类skills适合写后端和中大型前端项目时使用。
• cola skills：一个偏"检索入口"性质的skills发现源，可以理解为技能界的导航站，适合没事翻翻、开拓思路。
• agents.md、skills.md等站点：这类源网站用于快速浏览别人发布的可复用技能，它的亮点在于不只有skills本身，还有作者的使用场景说明，能帮你判断是否适合自己。
• GitHub Topics和Awesome系列：最原始但最全的查找方式，别嫌它老，胜在数据全。

我自己的习惯是：收藏不超过五个信得过的源，每周花半小时翻一遍更新，不要遍地刷，信息过载会让学习效果大打折扣。

5.3 场景化配置：数学建模、前端开发、AI漫剧

很多人在场景化这一步彻底卡壳，其实核心就一句话：把"你希望AI做到的输出规范"写成文字，为它起个合适的description，再配上触发场景。

• 前端开发场景：重点配置代码规范、组件设计模式、浏览器兼容性约束、交付前自检清单。我用前端开发skills最大的感受是，AI产出代码的可读性明显提升，注释不再是一堆废话。
• 数学建模比赛场景：上面第4章的数学建模skills就是一个标准套路，另外可以再加一个"论文润色"skills，让它按学术论文的语言风格对解答过程做二次整理。华为杯这类比赛里，广义上的codex skills、opencode skills也可以用来做数据读取、绘图脚本生成等辅助工作。
• AI漫剧场景：核心是分镜语言与节奏。SKILL.md里可以规定镜头时长、台词密度、情绪推进方式，然后配一个经典案例库作为template，AI生成剧本时就会自动贴合"短平快、反转密"的漫剧风格。

场景化配置的秘诀，不是把skills写得越多越好，而是每个skills对应一个你最常遇到的输出场景，让AI一进这个场景就自动进入对应的行为模式。

6. 避坑与清理：Skills叠加太多、上下文膨胀怎么处理

我看到过好几个人把仓库十几个skills一股脑全装进去，结果每次会话启动都要扫描一堆description，不仅费token，AI还经常搞不清该用哪个技能。社区里Tibo那篇关于清理skills的方法之所以流传很广，核心就一个思想：技能重质不重量，按需保留，定期清理。

我自己现在每个项目只保留两到四个skills，个人的通用目录里也不超过六个。清理方法是这样的：

• 每两个星期检查一次所有技能的命中情况，凡是从来没触发过、或者触发后输出没有明显提升的，直接移到归档目录。
• 归档目录不在实际扫描路径下，需要用时再放回来，避免占用每次扫描的名额。
• 对同类的skills做合并，比如"前端代码规范"和"React组件规范"合并成一个“前端工程规范”，减少description重复互相干扰。

还有一个非常容易犯的错：把同一个skills同时装在项目级和用户级目录，结果版本冲突，AI的行为有时符合A有时符合B。你在一个项目里安装了带旧版的skills，而用户级目录是新的，AI会优先读哪个目录？文档不一定写清楚，但我实测下来是混乱的，最好的办法就是只在一个位置保留它，其他位置全部删掉。

除了数量控制，还得注意几个通用坑，我踩过并修过的：

第一，description写得不够具体。很多人的description就一句话"帮助进行XX"，这种描述命中率极低。最低要求是把"什么场景、什么任务形态、期望用什么方法"写进去。

第二，SKILL.md里没有禁令。如果不写明"禁止直接输出最终结论而不展示推理过程"，AI的默认行为就是直接给结论，你写的流程规范等于白写。

第三，把脚本依赖当成必须。很多人写skills时非要在scripts目录里放个Python脚本，还指定AI去执行。但AI在沙箱里不一定能运行脚本，导致整个技能失效。纯文案流出色的skills同样有大价值，别什么都硬上代码。

第四，不同工具之间共用一套skills时，排版、目录约定不统一导致解析报错。解决方案是每个工具建一个独立目录，不共用同一份文件。

第五，版本兼容问题。Claude Code更新版本后，skills扫描机制和目录约定偶尔会有微调，GitHub上某些老skill可能不再适配。遇到这种，去仓库的issues翻一翻通常有答案。

我在实际使用中的体会是，skills真正改变的是工作习惯——以往我每次都要在对话里重新描述一遍规范和流程，现在只需触发一个技能，AI就能按我训练好的方式干活。这个领域还远没到"一套规矩通吃天下"的阶段，各家工具都在快速迭代，但底层逻辑是相通的：把人的经验沉淀成机器可读的规则，让AI在正确的轨道上发挥它强大的推理能力。与其追着热搜词一遍遍打听"哪个skills好"，不如把手头这一个技能打磨到足够好用——那才是所有skills真正发挥作用的地方。