企业官网建设流程全解析

1. 为什么突然全网都在聊skills：一个被大多数人低估的机制

最近一个月，我的信息流几乎被同一个词刷屏：Agent Skills。从Claude官方下场推Skills，到Codex把Skills作为核心能力，再到社区里冒出各种"skills大全""skills推荐"，这股热度来得非常猛。我自己也花了两周时间，把能试的客户端、能看的文档、能装的技能包都折腾了一遍，今天想把这个东西掰开揉碎讲清楚。

先说结论：Agent Skills本质上是一套"给AI智能体写操作手册"的标准格式。没有它之前，你想让AI帮你干活，靠的是在对话框里反复粘贴长Prompt，或者写一堆复杂的System Prompt；有它之后，你把"怎么做一件事"的完整方法论直接打包成一个文件夹，扔给Agent，它就能按步骤干活。听起来好像只是把Prompt换了个载体？不，差别远不止这个。

我用一个生活化的例子解释。把Agent想象成一个刚入职的新员工，MCP这种机制，相当于给新员工接通了公司的各种系统和数据库权限——他能查数据、能调API，但他不知道该按什么流程干活、怎么判断质量、遇到异常怎么处理。而Skills，相当于给新员工一份前任留下的《岗位SOP手册》，里面写着"第一步做什么、第二步做什么、遇到什么情况怎么处理、最终产出长什么样"。两份东西一配合，新员工才真正"能干活"。

所以你会发现，Skills和MCP经常被拿来对比，但两者根本不是竞争关系，而是互补关系。MCP管"手"——能不能触达外部工具；Skills管"脑"——知不知道怎么做对的流程。这也是为什么OpenAI的Codex、Anthropic的Claude都在押注这个方向，因为只要Agent还想做复杂任务，"带方法论干活"就是一个绕不开的需求。

这篇文章我尽量不谈空话，直接把Skills的底层结构、开发流程、安装使用、避坑经验全部摊开。不管你是前端开发者想给Agent写个"分镜skills"用于视频创意，还是后端工程师想在Codex里挂一个"自动挖洞skills"，又或者只是个AI工具爱好者想搞清楚这东西到底怎么玩，这篇都能给你一个完整的操作路径。

2. SKILL.md文件结构：为什么一份Markdown能指挥Agent干活

很多人第一次接触Skills，会有个天然疑问：这不就是个Markdown文件吗？凭什么它就能让Agent按指令执行？这就得从Agent的工作机制说起。

2.1 渐进式披露：让Agent"先看目录、再看章节"

Agent在启动一个Skill时，并不是把这个文件夹里的所有内容一次性读完——它不是大模型的全量上下文，而是按照"渐进式披露"的节奏来读东西。具体说，Agent会先读根目录下的SKILL.md，看一眼里面的name和description字段，判断"这个技能适不适用于当前任务"。如果适用，它才会继续深入，读取SKILL.md里的正文指令，并根据指令去按需加载子文件、参考脚本、示例数据。

这个设计非常巧妙。回想一下你写过的最复杂的Prompt，是不是动辄几千字，把AI的上下文窗口塞得满满当当？一旦任务变多，这些细节互相干扰，AI反而不知道该听谁的。Skills的渐进式披露，相当于把知识从"一次性强制灌入"变成了"按需动态加载"。Agent要处理视频分镜，它就加载分镜相关的参考文件；要处理周报，就加载周报模板。这既节省了上下文，又提高了指令执行精度。

2.2 SKILL.md的完整字段拆解：name、description和正文指令

一个标准的SKILL.md长什么样？我可以直接给你一个最小可用的骨架：

--- name: weekly-report description: 根据本周工作数据生成结构化周报，包含完成事项、数据指标、风险问题和下周计划。 --- # 周报生成助手 当用户要求生成周报时，按以下流程执行： 1. 收集用户提供的本周工作内容，包括完成的功能、修复的问题、对接的协作方。 2. 按分类整理为：本周完成 / 关键数据 / 风险与阻塞 / 下周计划。 3. 每个分类项用列表呈现，避免长段落堆砌。 4. 数据指标如缺失，明确标注"待补充"，不要编造。 5. 输出格式为Markdown，可直接粘贴到飞书/钉钉文档。

注意看front-matter里这两个字段，name和description。name是技能的唯一标识，description是Agent判断"什么时候该调用这个技能"的依据。description写得越具体、越功能导向，Agent的判断越准。如果你写"这个技能可以做一些事情"，那Agent大概率会在不该用的时候用它；如果你写"当用户需要生成周报、整理工作汇总、提交周度总结时使用"，触发率就会高很多。

正文部分，就是实打实给Agent看的操作指令。这里有一个经验技巧：指令不要写成"解释什么是周报"这种百科式文本，要写成"当用户要求X时，按步骤做Y并产出Z"的操作式文本。Agent是一个执行者，不是学习者，你在Skill里给它的是操作SOP，不是知识科普。

2.3 参考文件、脚本与Resources目录：让Skill具备真正的"手"

如果一个Skill只靠Markdown文本，那它和一段优秀Prompt的区别其实不大。Skills真正的灵魂在于，它可以挂载参考文件、脚本和其他资源，让Agent在执行过程中调用这些内容。

典型的Skill目录结构是这样的：

my-skill/ ├── SKILL.md # 入口文件，必须存在 ├── scripts/ │ ├── analyze.py # 辅助脚本，处理结构化数据 │ └── generate.js # 辅助脚本，生成报告 ├── references/ │ ├── template.md # 参考模板 │ ├── examples.md # 示例输出 │ └── faq.md # 常见问题处理 └── assets/ ├── config.json # 配置数据 └── prompt.txt # 预置提示词

比如我之前开发了一个"批量压缩图片"的Skill，SKILL.md里写清楚"调用scripts/compress.sh来处理目标目录下的图片"，Agent读到这条指令后，会先检查scripts目录下是否有这个脚本，然后调用它执行。这就让Skill从"纯文本指令"升级成了"可执行的自动化任务"。

这里补充一句关于脚本语言的选择。我见过很多人在Skill里挂Python脚本，结果Agent环境里没装依赖库，执行直接报错。如果你开发Skills的分发对象是普通用户，脚本尽量用标准库实现，或者用Node.js这类默认环境比较完整的方式。我的习惯是：能用Shell轻轻松松搞定的绝不上Python，能避免依赖第三方库的绝不引入，因为Agent环境里的依赖管理，远比你本地环境脆弱得多。

2.4 为什么Skills选择Markdown而不是JSON或代码文件

聊个稍微底层一点的问题：为什么生态都选了Markdown作为Skill的主格式？我自己琢磨过一阵，也跟社区朋友交流过，结论有三点。

第一，Markdown兼具结构性和可读性。大模型的训练数据里，Markdown语料占了相当大的比例，模型对它的理解天然比自定义格式要强。换成JSON，字段嵌套深了模型容易迷；换成纯文本，层级信息丢失严重。Markdown是"层级清晰+模型友好"的平衡点。

第二，Markdown易于人类阅读和协作。Skills不只是给机器看的，也是给团队沉淀知识用的。一个新工程师拿到一个Skill文件夹，打开SKILL.md，不需要任何解析工具就能读懂方法论。这种"人机共享阅读体验"非常重要——要知道很多技能的维护者是靠团队协作完成的，如果只有机器能读，那维护成本就失控了。

第三，Markdown天然支持"渐进式披露"所需的链接机制。正文里可以写"详见references/examples.md"，Agent会自动去加载这些子文件，形成知识树。JSON虽然也能引用，但可读性和模型理解度都远不如自然语言+链路链接来得直接。

3. 从零开发一个属于自己的Skill：以"前端开发辅助"为例

讲了这么多原理，可能你还是觉得隔了一层。这一节我直接带你走完一个完整开发流程。我选一个大家最容易上手的例子：开发一个前端开发技能包，用来让Agent辅助完成页面搭建、组件生成和代码审查。

3.1 第一步：明确边界——这个Skill能做什么，不做什么

这是我在Skills踩坑过程中学到的最大教训。很多人写Skill，上来就想要一个万能技能，什么都能干，结果description写得又宽又泛，Agent拿到之后不知所措。好的做法是：给Skill一个清晰的边界，宁可做少一点，做精一点。

我的前端Skill定位如下：辅助生成Rust? 不，是辅助生成HTML/CSS/JavaScript组件代码、按需产出响应式布局方案、对既有代码做基础的可访问性检查。它不做的事包括：后端接口设计、数据库表结构、部署上线流程。这些边界我会在SKILL.md开头部分直接写清楚，明确告诉Agent"不要执行以下操作"。

为什么边界这么重要？因为Agent的执行风格是"任务驱动"。如果你不写清楚边界，用户随口问一句"帮我把这个接口联调一下"，Agent可能就尝试开始写后端代码了——它不会质疑这个请求是不是超出技能范围。边界写清楚之后，Agent会直接回复"该任务已超出我的技能范围，建议切换到对应的后端开发技能包"。

3.2 第二步：编写SKILL.md——用操作式语言代替描述式语言

我实际编写的前端Skill的SKILL.md如下，你可以直接参考这个写法：

--- name: frontend-component-builder description: 当用户要求生成前端组件、HTML页面、CSS样式调整、响应式布局或进行代码可访问性审查时使用。不适用于后端、数据库、部署相关任务。 --- # 前端组件构建助手 ## 核心原则 - 所有输出基于现代HTML5语义化标签，不使用deprecated的标签如<center>、<font>。 - CSS优先使用Flexbox和Grid，尽量避免float布局。 - 兼顾移动端优先，基准断点为 375px / 768px / 1024px 三个档位。 ## 组件生成流程 1. 向用户确认组件的用途场景：页面区域、交互方式、视觉风格。 2. 基于语义化HTML构建结构，同时为关键节点补充aria-label和role属性。 3. 输出内联CSS变量方案，主色/辅助色/间距统一使用CSS变量。 4. 校验响应式布局：宽度是否弹性、伸缩项是否设置了min-width:0、栅格是否铺满。 5. 输出完成后，用清单模式列出可访问性检查结果。 ## 设计约束 - 不要使用内联style属性，除非是动态值。 - 不要引入任何第三方CSS框架，除非用户明确要求。 - 图片缺失时，必须提供alt占位文本，不能用空字符串。

这个文件看起来不长，但你注意它的信息密度。每个条目都是"具体约束+可执行动作"，没有任何一句废话。我特别在"设计约束"里加入了几个反直觉的限定，比如"不要使用内联style"——为什么？因为大多数AI生成的前端代码都习惯往style属性里塞样式，虽然能用，但维护性极差。作为团队管理者，我不希望Agent给团队产出一堆屎山代码，所以从源头约束住。

3.3 第三步：挂载参考模板与脚本

SKILL.md写完之后，我在references目录下放了两份文件。一份是templates/component-template.html，里面是我团队沉淀的标准卡片组件结构；另一份是examples/best-practice.md，收集了三五个高质量的前端代码片段作为参照。

为什么挂载示例比在SKILL.md里把话说尽要好？因为大模型从示例中学习模式的能力，远强于从规则描述中学习。你写"组件结构要清晰，语义化标签要合理"，Agent很难量化什么叫"合理"；但你给它两个"优秀组件输出示例"，它就能模仿示例的结构和风格，产出质量会指数级提升。这也是Skill设计里非常核心的调优技巧：多用例子，少讲道理。

脚本方面我放了一个check-a11y.mjs，用Node标准库实现基础的可访问性检测，比如检查img标签是否有alt属性、button是否有可访问名称、表单label是否关联。之所以用Node标准库而不引入puppeteer这类大依赖，就是考虑到其他用户复用时，他们的Agent环境很可能没有这些依赖。

3.4 第四步：本地联调与迭代技巧

Skill开发完不能直接发布。我的习惯是先在本地客户端里加载这个Skill，然后用20到30个典型问题去测试。

比如我会问："帮我生成一个产品卡片的响应式组件""把我的导航栏改成用Flexbox实现""这个页面代码做一次可访问性检查"——然后把Agent的产出结果一步步对照检查。重点看两点：一是它是否正确触发了这个Skill，二是它在执行过程中是否严格遵循了SKILL.md的约束。

测试过程中一定会发现问题。我第一次测的时候发现，Agent老是跳过"确认组件用途场景"这一步，直接就开始出代码了。原因是我在SKILL.md里写的"向用户确认用途场景"，语气太软，Agent理解成了可选项。我改成"必须按以下顺序执行：第一步，向用户确认用途场景，未确认前不得开始编写代码"，效果立刻就不一样了。这就是Skills开发的常态：指令的强制性语言，直接影响Agent的执行效果。

4. Skills的安装、分发与市场：从官方渠道到第三方平台

讲完了开发，我们再聊聊使用环节——毕竟对一个普通用户来说，下载和安装才是第一步。Skills生态虽然还年轻，但安装渠道已经挺丰富了，我给大家梳理一下。

4.1 官方市场与内置平台：最省心的获取方式

现在主流的支持Skills的客户端，基本都内置了技能市场。Claude这边有一个skills官方市场入口，用户在客户端设置里就能浏览、一键安装社区技能包；Codex也允许通过指令直接安装GitHub上的Skills仓库。这种官方市场的好处是，技能包都经过基本审核，目录结构完整，装完即用。

不过我就直说了，目前官方市场的技能包数量跟npm这种成熟生态比，还是少得多。你想找冷门的技能，比如"自动挖洞skills""分镜skills"，在官方市场里经常搜不到。这时候就得靠社区渠道。

4.2 GitHub与第三方技能平台：挖掘冷门技能的地方

GitHub是目前Skills分发的主阵地。搜一下"awesome-claude-skills"或者直接搜"skills"关键词，能翻到很多开源技能包仓库。我个人常用的是几个专门的skills下载平台，它们做的事跟npm registry类似——提供技能包的搜索、预览、一键安装命令。

安装方式我给你整理一下，不同客户端的标准做法不太一样：

• Claude系列客户端：把技能文件夹复制到用户目录下的~/.claude/skills/目录，或项目目录下的.claude/skills/目录，重启客户端即可加载。
• Codex：通过指令或配置指定skills目录位置，支持从本地路径和Git URL加载。
• 社区型平台（如Reasonix）：提供图形化管理界面，支持直接在界面上搜索、下载、启用/停用技能。

以Reasonix为例，它安装新skills的操作逻辑是：在界面里搜索你需要的技能名称，找到后点击安装，它会自动把技能文件放到对应目录，并在配置里注册启用。如果你是要装我前面开发的前端组件助手，装完之后新建一个会话，问一句"帮我生成一个产品卡片组件"，Agent就会自动加载这个Skill并且输出带语义化标签的完整组件代码。

4.3 手工安装的本质：看懂目录，走遍天下都不怕

不管用什么平台，手工安装的本质都是"把技能文件夹放到指定位置"。你理解了这一层，就永远不会被工具绑架。我把通用步骤总结一下：

1. 解压或clone技能包，确认根目录有SKILL.md文件。
2. 查看SKILL.md里的name字段，确认技能名称唯一、没有覆盖现有技能。
3. 把整个文件夹复制到对应客户端的skills目录。
4. 重启客户端，让技能注册生效。
5. 用一句话测试触发技能，确认description描述能命中实际需求。

这里有个很多人踩过的坑：下载技能包后不检查目录结构，直接把整个仓库clone下来扔进skills目录。结果仓库里有README.md、LICENSE、test文件，SKILL.md反而在子目录里，客户端根本找不到。所以每次安装后，务必先确认SKILL.md在根目录，再重启客户端。

4.4 团队级技能管理与版本控制

如果你不是个人使用，而是想在公司团队里推广Skills，我强烈建议把技能目录纳入Git管理，用一个单独的仓库维护。每次更新技能，按语义化版本打tag，团队成员通过拉取最新代码来同步。

这里分享一个我团队正在用的约定：dev分支存放正在开发的技能，main分支只放经过测试的稳定版本。每个技能包必须附带CHANGELOG.md，记录每次更新改了哪些指令、加了什么示例。这样做的原因是，Agent执行技能的效果受文本细节影响巨大，改一句话可能就改变整个输出风格——如果没有变更记录，你根本无法定位是哪个版本引入的回归问题。

5. 实战踩坑实录：我在Skills上摔过的五个坑

凡是新东西，就必然有一堆坑等着你踩。这两周我前前后后装了50多个技能包，开发了3个自有技能，踩坑记录可以写成一本小册子。挑五个最有代表性的跟大家说说，希望能帮你们省点时间。

5.1 description写得太抽象，技能死活不触发

这是我遇到的第一个坑。我给一个"论文写作辅助"技能写了description：用于学术写作辅助，提升论文质量。结果怎么触发都不生效。后来我把description改成：当用户要求写论文、修改学术稿件、生成文献综述、优化论文逻辑结构时使用。还包括参考文献格式检查和学术语言润色。，触发率立刻飙升。

原因很好理解：Agent判断是否调用技能，本质是拿用户输入和description做语义匹配。你写得越抽象，匹配面越窄；你列出具体场景的词组，匹配面就宽了。我把这个经验总结成一个筛选条件：如果description里包含"等等"这类模糊词，那就说明还没写到位，得继续加具体场景。

5.2 把Skill当成万能Prompt，什么都往里塞

社区里有一个非常普遍的误区：觉得自己有个好用的Prompt模板，套一个SKILL.md的壳就算开发了一个Skill。这种"伪技能"到了真正的Agent环境里，表现往往非常平庸。

我对比过同一个知识内容，以纯Prompt形式和Skill形式分别运行的效果。差异最大的点在于：纯Prompt是一次性把全部指令塞进上下文，即使任务不相关它也在消耗上下文；而Skill是渐进式加载，任务不相关时一点上下文都不占用，相关时只加载必要部分。所以，Skill的正确价值在于"沉淀方法论并把上下文开销降到最低"，而不是把一段长篇Prompt换个扩展名。

如果你发现自己写的SKILL.md一眼望去超过300行，大概率是思路出了问题。试着把冗余内容拆到references目录下，SKILL.md只保留精简的执行指令。这个理念我后面细说。

5.3 脚本路径写死，换台设备就崩

我在开发图片压缩Skill时，脚本里写了一个绝对路径/Users/laike/scripts/compress.sh。在我自己的环境里一切正常，但发给朋友后直接报错——他的用户名目录不同，路径解析失败。

解决方案其实很简单：所有引用参照物都是以Skill文件夹自身为基准，用相对路径。在SKILL.md里，我会这样写：

执行scripts/compress.sh，处理用户指定的图片目录或当前工作目录下的图片。

Agent在运行时会先定位SKILL.md所在目录，然后在其相对路径下查找脚本。这要求开发者在引用文件时，一律使用相对于Skill根目录的路径，不要写任何绝对路径。这也是测试环节容易忽略的事：本地跑通不算数，换一个目录模拟用户场景再跑一遍才算数。

5.4 上下文还是被撑爆了：忘了控制"加载范围"

有朋友跟我抱怨，说装了某个skills后Agent的上下文占用明显变大，对话质量也下降了。我打开那个技能包一看，references目录下放了十几个几十KB的文档，而且SKILL.md里只写了"参考references目录下的所有文件"。

这就是新手开发常犯的"无差别加载"错误。正确的做法是，在SKILL.md里精确指定按需加载的逻辑，例如：

3. 当用户要求生成产品说明时，加载 references/product-guide.md。 4. 当用户要求生成技术方案时，加载 references/tech-design-template.md。 5. 其他情况不要加载任何参考文件。

这样一来，Agent只会加载与当前任务相关的参考文件，而不是启动时一股脑全读进去。渐进式披露的优势，必须靠了你明确的按需加载指令才能真正发挥出来。

5.5 与MCP的分工不清：技能里去调API，纯属自找麻烦

另一个常见的边界问题，是Skill和MCP工具的界限被抹糊。我见过有人写了一个"数据分析Skill"，在SKILL.md里要求Agent直接去调某个数据库的API，结果Agent压根没有对应的MCP连接，执行到一半就报错。

正确的分工应该是：Skill负责"决定做什么、按什么顺序做、如何判断结果质量"；MCP负责"提供执行工具，比如连数据库、调外部API、访问文件系统"。Skill可以引用MCP工具的名字，但不应该自己承担"连接外部系统"的职责。开发Skill时，只描述"使用数据分析工具获取数据后，按以下步骤清洗和加工"，由Agent根据环境自动匹配可用的MCP工具。

6. Powerskills与生态趋势：为什么我说这波值得跟进

Skills的价值不止于个人效率提升。往深了看，它正在改变Agent使用方式的底层范式——从"每次都从零对话"变成"调用沉淀好的方法论"。而社区里已经开始出现一些新东西，值得大家关注。

6.1 从Skills到Powerskills：当方法论开始"互操作"

最近听到一个新概念叫Powerskills，它描述的是"技能之间的组合调用"。举个例子，一个"周报生成skills"可以调用"数据分析skills"里的统计方法，再由"文档排版skills"统一输出格式。每个技能不再是孤岛，而是像一个函数一样可以被其他技能引用。

这正是我想强调的方向：当前Skills生态大致处于"单技能单用"阶段，但很快会出现技能组合调用的需求。就好比你装了一个"竞品分析"技能和一个"PPT生成"技能，下一步自然希望"竞品分析"跑完的结果能自动喂给"PPT生成"。这种组合能力一旦成熟，Agent的威力会上一个台阶。

6.2 跨平台兼容性：现在就要为未来留好后路

另外一个趋势是跨平台兼容。现在还处于混战期，Claude有自己一套规则，Codex也有自己的命名，但基本结构差异并不大——都是SKILL.md加辅助资源。我在开发技能时，刻意保持最大公约数的写法，也就是只用标准的front-matter字段name和description，不在正文里掺杂任何特定平台的私货指令。

这样做的红利，在我从Claude切换到Codex时立刻体现出来了。同一个技能文件夹，基本做到复制即用，只花了很少的时间适配平台差异。我建议你开发新技能时也保持这样的习惯，不要绑定某个平台的特性语法，尽量用"自然语言描述操作流程"这种通用方式。

6.3 个人与团队如何低成本跟进：我给的具体建议

最后给一些可落地的建议。如果现在的你还在观望，不知道从哪下手，我建议你按这样的顺序推进：

• 第一周：从官方市场和GitHub各装几个头部技能包，跑通安装流程，感受一下"Agent按SOP干活"和"Agent自由发挥"之间的效果差异。
• 第二周：选一个你日常工作中重复度最高、流程最固定的任务，把它写成第一个自有Skill。不需要追求覆盖面广，聚焦一个场景提高完成度。
• 第三周：尝试拆解你团队里的核心工作流程，固化成2到3个相互独立的技能包，并建立Git仓库管理版本。
• 如果你本身就负责工具链建设，先把MCP和Skills的分工理清楚，再考虑引入Powerskills的技能组合能力。

从我个人的实际体验来看，Skills这个机制最大的价值不是让AI变聪明，而是让AI可被沉淀、可被传承、可被审计。过去一个优秀员工的隐性知识随着离职就流失了，现在这些东西可以显式化为技能包，永久留存在团队里。单凭这一点，就值得你花时间深入了解它。