企业官网建设流程全解析

如果你最近逛技术社区，大概率会被同一个关键词刷屏：Skills。AI 工具圈里能一夜之间被反复提起的新词不多，但“Skills”这次是真的出圈了。无论你用的是 Claude Code、Codex、opencode，还是只停留在网页版聊天工具阶段，都绕不开一个话题：模型能不能学会一套可持续复用的工作方法？

简单说，Skills 就是把“告诉 AI 怎么做事”从一段临时提示词，变成一套可以安装、可以复用、可以传播的技能包。对开发者来说，它解决的是上下文爆炸和提示词难以复用的问题；对普通用户来说，它让 AI 从“问一句答一句”进化成“你给它一个任务，它按自己的 SOP 走”。这篇文章我就从原理、目录结构、安装使用到手写一个技能包，全部拆开讲清楚。文末我也会聊聊自己对网上那点“作者瓜”的态度，但重点还是放在技术本身。

1. 先搞清楚 Skills 到底是什么

1.1 从提示词内卷到技能封装

以前我们调教 AI 靠什么？靠提示词。比如想让模型帮我们写符合规范的 Git 提交信息，就在每次对话里粘贴一段“请遵循 Conventional Commits 规范，type 用 feat/fix/docs/style/refactor/perf/test/build/ci/chore，scope 要尽量精确……”这段话长了之后，你会发现两个问题：一是每次开新会话都要重新粘贴一遍，二是它把上下文窗口占掉一大截，真正处理代码的余量反而少了。更糟的是，如果这段提示词写得不够结构化，模型很可能在对话中途“忘掉”规则，或者被用户某一句随意的话带偏。

Skills 的出现就是为了根治这个病。它的思路很直接：把“某类任务的标准做法”封装成一个文件夹，文件夹里有一份 SKILL.md 作为主文档，再配上参考资料、模板、脚本等资源。模型遇到相关任务时，“按需读取”这份技能，而不是在每一次对话里把所有规则都提前塞进上下文。这个设计很像人去工作——你不需要把公司全部规章背下来才上班，遇到具体流程，翻对应的操作手册就行。

这个转变在 AI 工具的发展路径上是必然的。最开始大家都是堆提示词，拼谁的 prompt 更长更细；后来发现，真正有效率的方式是“模块化”，让不同的任务对应不同的知识块。你让模型写测试用例时，它才加载测试相关的规范；你让它做前端页面时，它再读取组件库的使用约定。这就是 Skills 被各种工具迅速跟进的原因，它把“模型知识”和“你的领域经验”做了解耦。

1.2 Skills 和 Prompt、MCP 到底什么关系

很多朋友看到 Skills 后第一反应是：这和 Prompt 不就是一回事吗？不是。Prompt 是一段指示，每次对话时给出；Skills 是结构化的技能包，包含主文档、示例、脚本、参考文件，并且能被模型在合适的时机主动加载。可以这样理解：提示词是“美团外卖订单”，一次性消费；Skills 是“你家冰箱里的预制菜 + 菜谱”，随时可以取用，而且配方可以不断更新。

又问：那 MCP（Model Context Protocol，模型上下文协议）呢？这也是容易混淆的点。MCP 解决的是“模型如何调用外部工具和数据”的问题，比如连接数据库、读文件、调 API，它像给 AI 装了一双可以伸长的手；Skills 解决的是“模型应该按照什么流程和方法来做”的问题，像给 AI 装了一套脑子里的工作手册。两者并不互斥。实际工作中它们经常配合使用：MCP 负责取数据，Skills 负责告诉模型取完数据之后该按什么标准、什么步骤继续干活。

还有一个常见误区是，不少人把“技能”等同于“让模型学会某个新能力”。其实模型本身的能力没有变化，Skills 提供的是“标准操作流程 + 领域知识”。模型参数没有增加，但它能干得更像机构里的熟手，原因就在于它按手册走了。这个理念后来被 Claude Code 官方文档命名为“Agent Skills”，很多第三方仓库也都沿用了 SKILL.md 的约定。可以明显感觉到，AI 工具圈正在快速收敛到一套类似的文件规范上。

2. 一个可运行的 Skills 内部到底长什么样

2.1 核心只有一个 SKILL.md

很多人第一次打开一个 skills 仓库的时候会愣住：说是技能包，怎么里面文件那么少？好消息是，一个最基本的技能包确实可以只包含一个文件：SKILL.md。这个文件通常放在一个以技能名命名的目录下，例如.claude/skills/commit-message/SKILL.md。模型会在遇到某个任务时，先去技能目录里扫一遍名称和描述，再决定要不要打开这份文件。

SKILL.md的结构遵循一套约定：顶部是 YAML 格式的 frontmatter，必须包含name和description两个字段。name是技能名称，要求简短直接；description则至关重要，因为模型就靠它来判断“什么时候该用这个技能”。描述里应该写清楚触发条件、适用场景，甚至还要写“不要用在哪些场景”，避免模型错误加载。

frontmatter 下面是正文。正文没有统一的强制格式，但好的技能说明书通常包含这几部分：任务目标、操作步骤、判断标准、常见错误和示例。模型是一个“阅读理解能力很强但缺乏常识”的执行者，你不能只给它一句“要有礼貌”，得告诉它什么叫有礼貌、在什么场景下表现礼貌、做到什么程度算达标。这里我强烈建议在每个技能里放至少一个“示例”，示例是模型模仿的最佳参照物，比抽象规则管用得多。

2.2 一个最小可运行的技能演示

这里我给一个可以直接复制的例子。假设我要做一个“代码审查技能”，让模型在提交代码前帮忙发现常见问题。目录结构如下：

code-review/ ├── SKILL.md └── reference/ └── common-bugs.md

SKILL.md内容：

--- name: code-review description: 对代码变更进行系统审查，检查逻辑错误、边界条件、安全隐患和代码规范。当用户要求 review、检查代码、或者准备提交合并请求时使用。 --- # 代码审查技能 ## 目标 对传入的代码或代码变更进行系统化审查，输出问题清单和改进建议。 ## 审查步骤 1. 先阅读变更的整体结构与目标，不要一开始陷入细节。 2. 逐项检查：逻辑正确性、边界条件、异常处理、安全问题、性能隐患。 3. 参照 reference/common-bugs.md 中的常见问题清单，逐条核对。 4. 输出审查结论，按严重程度分级：阻塞、建议、可选。 5. 每条问题必须附带代码位置和修改建议，不允许只写“有问题”。 ## 审查规范 - 只有当问题影响功能正确性或安全性时，才标记为“阻塞”。 - 设计偏好和风格类问题统一归入“可选”，避免噪音。 - 如果发现安全漏洞，先明确指出漏洞类型，再给修复示例。 ## 示例 ### 输入代码 ```javascript function getDiscount(user) { if (user.level === 'vip') { return 0.8; } return 1; }

期望输出

• 阻塞：无。
• 建议：getDiscount未处理user为空的情况，调用方传入空对象时会抛出异常。建议增加空值判断，并返回默认折扣1。

看到没有，这个技能文件的本质就是把你希望模型遵守的工作方式“固化成文档”。复杂技能可以拆出多个参考文件，把常用的缺陷模式、代码规范、术语表放在 `reference` 目录里，让主文件保持精简。`SKILL.md` 是目录，参考文件是具体的书，模型只有进入这本书之后才会继续翻页。 ### 2.3 为什么“按需加载”比“全塞进去”靠谱 早期给 AI 写系统提示词，大家的习惯是“把所有要求都写在 system prompt 里，越细越好”。这个路子用到一定程度就会撞墙：模型上下文窗口有限，你塞进去一万字规则，真正处理任务的空间就少了一万字；而且规则与规则之间容易冲突，模型会陷入“到底听哪条”的纠结。Skills 采用了一种叫“渐进式披露”的策略——模型先看到技能包的描述，觉得相关才打开完整内容，如果里面还引用了其他文件，就继续一层层展开。 这像极了你在公司查制度手册：你不会把几百页制度全背下来，而是遇到报销问题时翻开报销章节，遇到请假问题时再看请假章节。渐进式披露带来的直接收益有两个：一是上下文利用率提升，同样的窗口可以处理更复杂的任务；二是准确率上升，因为模型在特定时刻看到的干扰信息变少了。这也是 Skills 看起来“高级”的核心原因，它不靠蛮力给 AI 灌输规则，而是设计了一套规则的分发机制。 ## 3. 现成 Skills 怎么装、怎么用 ### 3.1 装一个技能比你想象的简单 如果你还处于“先拿来用”的阶段，最简单的办法是把网上的技能包目录拷贝到本机配置目录。不同 AI 工具对目录约定略有差异，以 Claude Code 为例，本地技能目录一般放在 `~/.claude/skills/`（用户级）或者项目下的 `.claude/skills/`（项目级）。用户级技能对所有项目生效；项目级技能只在该仓库内生效。团队协作场景下，把技能目录直接提交到 Git 仓库里，队友拉到代码后就能共享同一套工作规范。 ```bash # 假设你已经把某个技能仓库 clone 到了本地 mkdir -p ~/.claude/skills cp -r path/to/code-review ~/.claude/skills/

复制完成后，重启会话，让模型重新扫描目录。之后你可以直接说“帮我 review 一下这段代码”，正常情况下模型就会自动加载code-review技能，按里面的步骤执行。注意，不同工具的名称和路径不一样，Codex 的 skills 机制、opencode 的加载方式都各有细微差异，但核心思路一致：它们都需要在一个约定好的目录里放技能包，并且通过description让模型判断是否加载。所以从别人那里下载技能包时，先看下载说明，别硬套路径。

3.2 高频场景下 Skills 的实际效果

可能你会问：装了 Skills 之后，模型表现真的有质的区别吗？根据我自己的实测，区别最大的是那些“规则明确但过程繁琐”的任务。举个例子，前端开发场景里，很多团队会沉淀一份组件库使用规范，哪个按钮该用哪个组件、间距用设计 token 还是写死、样式冲突时怎么处理。如果靠每次开新会话都贴规范，开发体验简直折磨；但把它做成一个frontend-dev技能后，模型每次写页面都会主动读一遍规范，产出的代码风格稳定不少。

测试用例生成也是一个典型场景。很多测试工程师烦的不是写用例，而是要遵循团队那套格式：用例编号规则、前置条件怎么描述、预期结果怎么写。把测试用例要求封装成技能后，你只需要描述功能点，模型就能按固定模板输出完整用例，而且每次格式都统一，review 成本大幅下降。还有文档写作类技能，比如“写周报”“写 PR 描述”“生成 changelog”，这类任务规则多但不需要什么深度推理，属于模型最容易做好的，也是最值得先封装成技能的。

3.3 我建议的“技能优先”落地清单

与其漫无目的地到处找别人分享的技能包，不如先在团队里盘点自己的重复劳动。我列一个优先级清单，你可以照着看一下自己属于哪类：

刚开始不用求多，先挑一个你每周都要重复做的事情，把流程整理成技能。我自己的经验是，一个技能包只要能在三次以上重复任务中替你节省时间，就值得长期维护。等积累到七八个技能后，你切换工具或换项目时的适应速度会快得吓人，因为这些经验资产跟着你走，不跟随某个具体模型。

4. 手把手写一个高质量 SKILL.md

4.1 第一步不是写文件，而是划边界

很多人第一次写技能时容易犯的错误是“贪多”。一个技能包既想管代码审查，又想管提交信息，还想管分支命名，结果 description 写得又长又模糊，模型不知道该在什么时候触发它。正确的做法是，每个技能只服务一个任务类型，边界要清晰。比如“代码审查”和“提交信息生成”就应该拆成两个技能，虽然它们都属于 Git 工作流，但任务类型完全不同。

划好边界之后，动笔前先梳理流程。你可以在纸上列出：当你手动做这件事时，你实际上会经历哪些步骤？哪些地方你曾经犯过错？哪些规则是你希望 AI 一定要记住的？这些内容就是技能的核心素材。千万别凭感觉硬写，因为你自己都不清楚的流程，AI 更不可能帮你执行。我一般习惯写一个“执行地图”：触发条件、准备步骤、执行顺序、完成标准、常见例外。

4.2 description 写得好不好，决定技能会不会被翻牌

description是整个技能包最重要的一个字段。为什么？因为模型不会把你所有的技能说明都读一遍，它只是在任务到来时扫一遍技能目录下的名称和描述，觉得可能相关才会打开文件。所以如果你的 description 写得太抽象，比如“用于代码开发”，那它可能永远不会被触发；写得太具体，把某一种情况写死了，也会导致其他类似任务被漏掉。

一个好的 description 应该包含三块信息：触发场景、任务对象、不适用场景。举个例子：“当用户要求为新增功能编写单元测试，或要求检查测试覆盖率时使用。适用于前端和后端 JS/TS 项目。如果只是修改已有测试用例的断言语义，不需要使用本技能。” 这样模型能非常清楚自己的选择边界。不要小瞧这个细节，项目里技能数量一旦超过十个，description 写得模糊的包基本等于废的。

4.3 一份可以直接参考的完整示例

我手头经常用的是一个“生成提交信息”的技能，写出来供你参考。它解决的问题很具体：团队提交信息格式混乱，release 时看 git log 像看天书。把这个技能放进项目里之后，你会发现所有人提交的 message 都能自动符合规范。

--- name: commit-message description: 根据代码变更内容生成符合 Conventional Commits 规范的 Git 提交信息。适用场景：用户执行 git commit 前想要生成 commit message，或者请求“写个提交信息”。当仓库没有遵循 Conventional Commits 时不要使用。 --- # git commit message 生成 ## 任务目标 分析代码变更，产出一到多条符合 Conventional Commits 2.0 规范的提交信息。 ## 步骤 1. 查看 git diff 和 git status，理解本次变更的目的。 2. 判断变更类型：feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、perf（性能）、test（测试）、build（构建）、ci（CI）、chore（杂务）。 3. 确定影响范围 scope，尽量使用模块名，例如 auth、checkout、api。 4. 用一句话概括主要变更，不要超过 30 个汉字或 60 个英文单词。 5. 如果变更内容包含多个维度，拆成多条提交信息，而不是塞进一条里。 ## 硬性约束 - 禁止在 subject 末尾加句号。 - 禁止把重构和功能混在一条提交里。 - 一定要区分 feat 和 refactor：用户行为不变的是 refactor，用户功能增加的是 feat。 ## 示例 ### 变更内容 新增了登录页面的验证码倒计时逻辑，并且重构了原来的验证码发送函数。 ### 期望输出 feat(auth): 新增登录验证码倒计时功能 refactor(auth): 抽取验证码发送公共逻辑

注意看这个文件的表述方式：每一条都是“可执行”的，而不是“可感受”的。它没有写“提交信息要清晰”这种空话，而是写了“不要超过 30 个字”“禁止句号”“用户行为不变的是 refactor”这类可校验的规则。这就是技能文件和普通提示词之间最大的区别：普通提示词靠模糊引导，技能文件靠精确约束。

5. 运行期容易踩的坑和排查记录

5.1 装了技能但模型像失忆了一样

这是我在社区看到最多的问题：用户把技能目录配置好了，文件也没放错，但让 AI 执行任务时它完全没有按照技能里的流程走。排查时先看三件事。第一，你的会话是不是在安装技能之前就开启了？很多 AI 工具只在会话启动时扫描技能目录，中途新增的文件不会被加载，重启一个会话再试。第二，技能目录是否真的是工具认的那个目录？我见过有人把文件夹放到了~/skills/而不是~/.claude/skills/，名字差一点，模型就完全看不见。

第三，也是最容易被忽略的：description和你的请求不匹配。比如你写了一个技能叫“代码审查”，描述里写的是“当用户要求 review 代码时使用”，但你实际说的是“帮我看看这段代码写得怎么样”，模型可能觉得这不属于“review”请求，于是没有加载技能。解决方法是把描述覆盖得更宽，或者用任务时直接点名，比如“请使用 code-review 技能帮我审查这段代码”。把技能名直接说出来，是最可靠的触发方式。

5.2 多个技能包内容打架

当技能包越来越多，冲突问题就会出现。比如“commit-message”技能要求每个提交信息不超过 30 个字，另一个“changelog 生成”技能可能为了生成更详细的发布说明，要求 commit 信息写得详细。这种冲突在技能内部很难解决，因为模型会同时加载两份文档，看到两个冲突的规则后会自己“权衡”，有时候就会做出你不想看到的选择。

我的建议是，在技能文档里学会写“不适用场景”。每个技能的开头都声明自己不负责什么事情，避免越界。对于多个技能可能同时匹配的任务，更推荐做法是：拆出一个“总控技能”，主要负责判断任务应该分派给哪个子技能，不要动手执行细节。不过普通用户在一开始不用想得太复杂，把技能数量控制在十个以内，认真写好每个技能的边界，绝大多数冲突都能避开。

5.3 第三方技能可以白嫖，但要先“验货”

现在社区里出现了很多收集技能包的仓库，质量参差不齐。有些技能是真正干活用的，有些更像是“演示”或者“花架子”。我下载第三方技能后不会直接扔进自己的主目录，而是先在一个临时项目里跑一遍，看看这个技能到底触发了什么逻辑、有没有偷偷调用外部接口、有没有读取本机文件的异常行为。毕竟技能本质上是可执行指令，装进你的工具链等于给了它一定的操作权限，安全策略要跟上。

特别提醒一点，不要迷信“高级技能”“全网首发”这些包装词。AI 技能的价值不在名字多响，而在它的规则能不能适配你的工作流。我拿过一些很流行的技能包，打开之后发现里面全是大而化之的“应该做得更好”式建议，没有一条可以验证的规则。这种技能装上之后，模型表现不会有任何提升。花 10 分钟读一遍 SKILL.md，再决定要不要保留，这个习惯值得养成。

5.4 一个速查表收好

6. Skills 能走多远：趋势与建议

6.1 各家 AI 工具都在做同一件事

一个技术方向最明显的时候，就是不同产品不约而同往同一个方向走。最近 Claude Code、Codex、opencode 等工具陆续都在推自己的技能机制，说明它们已经意识到“模型能力”和“经验封装”需要分层。模型的能力会随着版本迭代不断提升，但你的工作习惯、团队规范、项目特性这些东西，应该沉淀在模型之外的可复用资产里——Skills 恰恰承担了这个角色。

从另一个角度看，这也意味着技能的“可迁移性”会越来越值钱。你现在为一个工具写好的技能，未来如果格式统一，可以直接平移到下一个更聪明的模型上。网上已经有很多开源的技能合集，里面覆盖了前端、测试、学术写作、代码审计等场景。我建议凡是看到符合自己工作流的技能，先下载拆开看一遍，看它的规则和示例是怎么组织的，然后自己照着改一版。这个过程本身就是一次学习。

6.2 与其追新模型，不如先攒自己的技能库

如果你现在还没开始用 Skills，我的建议是不要错过这波。不是说它是什么神奇技术，而是它代表了一个非常务实的工作习惯：把你和 AI 的协作流程，变成一份可以管理、可以迭代的资产。好的开发者会把自己的代码做版本管理，好的 AI 使用者也应该把自己的 AI 工作流做版本管理。Skills 就是这个工作流的“配置文件”。

我认识的一些效率比较高的同行，已经把自己常用的十几个技能做成了私有库，里面甚至包含他们多年总结的代码规范、写作风格、常用工具链。这些技能不是一个 prompt 能替代的，因为它们是依赖项目实际反馈不断修改出来的经验精华。新模型出来后，他们不会特别兴奋，因为再强的模型也需要一套好方法来发挥价值。而这一套方法，正是 Skills 在帮你沉淀的东西。

6.3 小技巧：让技能自己迭代

一个容易忽略的点是：技能不是写一次就完事的静态文档，它应该像代码一样持续迭代。我每过一段时间就会回头看看自己的技能目录，哪些技能总是被触发但是效果不好，哪些技能一直没被用过，然后做增减。更好的做法是，每次 AI 在执行技能时给了你一份不太满意的结果，你把“为什么不满意”记录下来，反向补进 SKILL.md 的规则里。

时间长了你会发现，技能文件里每增加一条规则，都是在减少一次返工。这个过程有点像在训练一个越来越懂你的助手，但你不用重新训练模型本身，只需要更新文档。未来如果出现更好用的模型，你把这些技能原封不动带过去，几乎不需要额外调教，新模型就能立刻按你习惯的方式干活。我个人认为，这才是 AI 工具在“个人效率放大”方面最值得投入的方向。

最后再分享一个私人习惯：我不怎么爱囤技能包，但我很喜欢拆技能包。网上那些热度很高的 skills 合集，我下载回来之后第一件事就是看它的 SKILL.md 结构，看完通常只要几分钟，就能判断出是认真打磨过还是临时拼凑的。至于围绕着某个作者的那些“瓜”，我没太多兴趣去评价，作品本身能不能解决实际问题，才是技术圈最该关注的事。动手把技能目录建起来，从自己最烦的那个重复任务开始写一份 SKILL.md，用过一轮你就明白为什么这个东西值得火。