企业官网建设流程全解析

1. 先说清楚"skills"到底是什么

最近"skills"这个词在AI开发圈里突然就炸了，前端开发skills、agent skills测试、codex skills、superpower skills这些关键词满天飞。如果你还没搞明白它和普通的prompt、插件、MCP有什么区别，那这篇文章可以帮你一次理清楚。

简单说，AI Agent的skills（技能）本质上是一组可复用的能力包——一个文件夹里装着指令文档、脚本和资源文件，让AI助手（Claude、Codex这类Agent）在面对特定任务时能够按照预定义的高质量流程去执行。它解决的是一个很实际的问题：每次让AI干活都要重复调教一遍太痛苦了，为什么不能像给员工写SOP一样，把一套成熟的工作方法打包给AI？

这玩意儿最打动我的一点是它的"文档驱动"设计哲学。一个skill的核心是一份带格式约定的Markdown文件，叫做SKILL.md，模型通过读这个文档来理解"遇到这类任务你该按什么步骤来、你要调用哪些脚本、你要输出什么格式"。也就是说，你不需要写一大堆复杂的插件代码，用自然语言把流程描述清楚，AI就能照做。

这篇文章适合谁看？适合已经在用Claude、Codex等Agent工具、但觉得默认行为不够可控、想让AI真正"专业化"的开发者，也适合刚听说skills这个概念、想入门的小白。我会从原理讲到实操，再讲到踩坑，尽量让你看完就能自己上手。

2. 拆开一个skill看看：目录结构、SKILL.md和运行机制

2.1 SKILL.md是灵魂：YAML头信息加Markdown正文

一个标准的skill目录长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ ├── fetch_data.py │ └── parse_results.js └── assets/ └── templates/

SKILL.md是整个skill的核心入口，它由两部分组成：开头的YAML frontmatter和正文。frontmatter里最重要的两个字段是name（技能名）和description（技能描述）。别小看这个description，Agent判断"当前任务该不该用这个skill"靠的就是它——系统会把当前任务和所有已安装skill的描述做语义匹配，匹配度高了才会自动触发。

正文部分则是真正的"操作手册"。你要告诉模型：这个技能是干什么的、应用的边界是什么、执行时遵循哪些步骤、有哪些注意事项、输出格式长什么样、需要调用哪些脚本、脚本的参数怎么传。写得越结构化、越具体，模型执行得就越稳定。

我见到过很多失败的skill，问题几乎都出在正文太笼统。你在SKILL.md里写的不是给搜索引擎看的摘要，而是给模型看的"操作SOP"——它没有隐性常识，不会自动脑补你的意图，你必须把关键约束明确写出来。比如你做一个"写周报"的skill，你不能只写"生成一份周报"，你得写清楚：汇报对象的层级、需要包含哪几个板块（工作进展/问题风险/下周计划）、每个板块的字数范围、用什么样的语气、要不要附数据表格。

2.2 脚本与资源：真正干活的引擎

SKILL.md负责"告诉模型怎么做"，而scripts目录里的脚本负责"把事情真的做掉"。这其实是skills设计里非常聪明的一环：纯文档适合描述流程和规范，但一旦涉及批量文件操作、调用外部API、处理结构化数据，让模型对着文档手写临时代码，既慢又容易出错。有配套脚本，模型只需要按SKILL.md里的说明去执行命令、传参数，可靠性大幅提升。

举个例子，我自己写过一个"批量压缩图片"的skill。SKILL.md里只写了压缩策略和参数约定，实际压缩逻辑放在scripts/compress.py里。模型接到任务后，调用脚本、传入目标目录和压缩比，脚本自己遍历文件、批量处理、输出报告。整个过程模型的角色从"程序员"变成了"操作员"，出错率自然就降下来了。

assets目录通常放模板、样例、配置文件这类静态资源。比如论文写作skill可以放一个论文结构模板.md，分镜skill可以放几个分镜表范例。模型在执行时可以直接读取这些文件作为参考，输出质量会更稳定。

2.3 为什么是"文档驱动"而不是"代码驱动"

这可能是skills最反直觉也最值得理解的设计。传统我们习惯了一切皆代码——功能要用代码实现，逻辑要用代码表达。但skills选择让Markdown文档当主角，有几个很实际的原因。

第一是门槛低。写一个能用的小skill，本质上就是写一份条理清晰的操作说明，不需要会编译、不需要处理依赖关系、不需要考虑跨平台。这会带来生态的爆发式增长，事实也确实如此——GitHub上已经出现了大量个人开发者贡献的skill合集，像superpowers这种打包了几十个技能的能力集，一个人就能维护得动。

第二是AI友好的表达形式。大模型本身就是靠自然语言训练的，一份写得很好的SKILL.md，对模型来说是"最高效的输入"。代码当然也重要，但代码的抽象层次和模型的思考方式不一定吻合。文档则能直接把"为什么这么做""什么时候该停""什么情况要检查"这类上下文传递给模型，这是纯代码很难做到的。

第三是审计和演化更自然。skill的改动可以像文档一样diff、review、版本化。团队里任何人想改进某个skill，直接编辑一段文字就好了，不需要理解复杂的插件SDK。这种"把能力沉淀成文档"的思路，其实和优秀团队维护内部wiki的精神一脉相承——只不过这次的"读者"是AI。

3. 把现成的skills装进Agent：安装与调用实操

3.1 去哪儿找靠谱的skills：官方市场与社区渠道

现在skills的获取渠道已经很丰富了。Claude官方有内置的市场，可以直接在客户端里浏览、一键安装社区贡献的skill。想要更广的覆盖面，可以去GitHub搜"awesome-claude-skills"这类汇总仓库，或者直接看一些star数高的合集项目——superpowers就是目前非常活跃的一个skill集，作者是Jesse Vincent，里面收录了几十个经过验证的技能，覆盖面从写作辅助到代码审查都有。

社区搜索时我有个判断标准：别只看star数，要看SKILL.md的写法。写法敷衍、正文只有三行"帮我做XXX"的skill，装进去大概率是在浪费上下文空间。好的skill，SKILL.md正文通常有明确的执行流程、边界条件和输出规范，scripts目录里还有配套脚本。这就跟挑开源项目一样，看文档质量比看宣传语靠谱得多。

3.2 安装到对应目录：Claude与Codex的差异

装skill的方式取决于你用的是哪个Agent。以Claude为例，个人skills安装在~/.claude/skills/目录下，把整个skill文件夹丢进去就行，重启会话后新skill就会被识别。Codex这边类似，也是把skills放到对应的工作区目录或全局目录，具体路径在官方文档里写得很清楚，装的时候注意区分"全局"和"项目级"——全局skills对所有会话生效，项目级skills只在当前仓库内生效。

这里有个实操细节值得说：目录名就是skill的名字。你创建~/.claude/skills/my-report-writer/，那么这个skill的标识就是my-report-writer。给目录起名时要用短横线分隔的小写英文字母，别用中文、别带空格，不然匹配逻辑很容易出问题。

3.3 调用方式：自动匹配与手动触发

skill的触发逻辑有两种。第一种是自动匹配——你直接给Agent一个任务，它根据任务内容比对skill描述，觉得合适就会自动加载使用。第二种是手动触发——你在对话里显式提到skill名，比如"用write-report这个skill生成一下季度总结"。我实测下来，自动匹配在简单场景下表现不错，但复杂任务里经常出现"该用的时候没用、不该用的时候乱用"的情况。

所以我的建议是：关键任务务必手动点名。在需要严格复现流程的场景里，明确说出skill名字，让模型知道"现在你必须按这个流程走"，这比寄希望于模型的自我判断要稳得多。如果Agent支持通过命令行方式操作skill，也可以写进工作流里，确保每次执行都被固定下来。

4. 自己写一个skill：从需求到落地的完整流程

4.1 需求拆解：什么样的能力适合做成skill

先说结论：凡是"你反复让AI做、流程相对固定、期望输出有统一标准"的事，都适合做成skill。比如日常周报汇总、图片批量压缩、竞品信息收集、代码仓库规范检查——这些任务重复度高、规则明确，沉淀成skill能省掉大量重复沟通。

不适合做成skill的也有：一次性创意任务、需要实时交互的对话、决策路径极不稳定的任务。这种场景硬做成skill，要么指令写得过于宽泛导致没有约束力，要么为了覆盖所有分支把SKILL.md写得比字典还厚，模型反而抓不住重点。

项目启动前，我习惯先花十分钟回答三个问题：这个任务的输入和输出分别是什么？中间有几条必经的子步骤？哪几个环节最容易出错？把答案写下来，SKILL.md的骨架基本就出来了。

4.2 撰写SKILL.md：让模型"看得懂"你的意图

写SKILL.md有几个反复验证过的原则。第一，前30行就要说清楚这个skill干什么和不干什么。模型读文档是有注意力权重的，越靠前的信息越容易被采纳。把边界条件写在前头，能有效防止模型"越界发挥"。

第二，步骤编号化。用清晰有序的"Step 1、Step 2、Step 3"把执行流程列出来。有实验数据显示，编号化的步骤比自由段落式的描述，执行一致性高很多。每个步骤里再注明"当出现XXX情况时，做YYY"，相当于给模型预置了异常处理分支。

第三，输出模板化。与其用文字描述"输出要好看一点"，不如直接在SKILL.md里嵌入一个输出模板，规定标题层级、段落结构、字段名称。模型照着模板填空，产出的结果稳定到你怀疑人生。

第四，明确哪些事模型可以自主决定，哪些必须询问用户。比如"生成周报时，如果缺少上周数据，必须向用户询问来源，不得自行编造"。这类授权边界写清楚，能避免很多灾难性输出。

4.3 测试与迭代：skill也要版本管理

写好的skill一定要经过多轮测试再投入使用。我最常用的测试方式：准备3到5个典型任务样例，在干净会话里分别触发这个skill，逐个检查输出是否按SKILL.md的约束执行。如果某个步骤模型总是跳过，别觉得是模型笨，大概率是你的指令有歧义或者上下文顺序有问题——调整措辞，让关键动作更显眼，再跑一轮。

我自己维护的skill，现在都会做版本管理。每次修改SKILL.md后，我会在frontmatter里加一个version字段，在正文末尾用change log记录本次改了什么。这样一旦新版本出了问题，还能快速回退到旧的稳定版本。对于团队协作的使用场景，建议直接把skills目录纳入git仓库，所有变更走代码评审流程——你会发现review一份SKILL.md的改动，比review一段代码的改动成本低得多。

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

5.1 skill没生效：名字、路径、触发词的坑

这是新手最容易卡住的一关。装了好几个skill，结果对话里提了半天，模型完全没反应。排查顺序通常是：先确认目录放在了正确的位置、目录名符合规范；再检查SKILL.md开头的frontmatter是不是被解析成功——YAML缩进错误、多了一个非法字段，都可能导致整个skill被跳过；最后看description写得好不好，如果描述和任务的语义距离太远，模型根本不会匹配到这个skill。

还有一个不容易发现的坑：修改SKILL.md后没有重启会话。很多Agent在会话启动时才扫描一次skills目录，你中途改了文件，当前会话里用的还是旧版本。我踩过好几次这个坑，改了半天参数发现行为完全没变，最后重启会话一切正常。

5.2 模型不按SKILL.md执行：指令设计的常见误区

Skill装了、触发了，但模型的执行结果和SKILL.md里描述的大相径庭。这种问题九成出在指令设计上。最常见的误区是一次性塞太多内容——SKILL.md超过300行，模型读着读着就"迷失"了。解决办法是拆分：把详细步骤、脚本说明挪到SKILL.md同目录下的辅助文档里，比如REFERENCE.md，正文里只留必要流程，需要时引导模型自己去看辅助文档。

第二个误区是约束分散在长文的各个角落。模型不是逐字读文档的，它的注意力会集中在开头和结尾。把最重要的约束放在显眼位置，用"必须""禁止""不要"这类强指令词，重复强调也不过分。我写skill的惯例是：核心约束至少出现两次——前排概述里一次，对应步骤里再具体展开一次。

5.3 多skill冲突与优先级：能力池的管理策略

安装的skill一多，新的问题出现了：任务描述模糊时，Agent可能同时匹配到两三个skill，或者一个都匹配不上。面对这种情况，我建议你在description里明确写清楚"适用场景"和"不适用场景"。你甚至可以故意在描述里写"如果任务不满足XXX条件，请勿使用本skill"，这能有效压缩误匹配的概率。

如果多个skill确实存在功能重叠，一个是"通用版"，一个是"特定场景加强版"，我会在场景加强版的描述里直接写"当用户明确提到XXX时，优先于通用版使用"。实测下来，这种显式的优先级声明，比指望模型自己比较两个skill的适用范围要可靠得多。

另一个管理策略是控制并发生效的skill数量。很多Agent会一次性把匹配到的所有skill都注入上下文，skill多了不但消耗上下文窗口，还会让模型决策变慢。我自己会把常用skill控制在10个以内，不常用的临时放到备份目录，需要时再启用。这个习惯让会话的整体响应速度和执行质量都有明显提升。

6. 一些经验体会和后续扩展方向

用skills这套机制折腾了这么久，我最大的感受是：它真正把"AI能力复用"这件事的门槛降了下来。以前写插件要懂SDK、要处理依赖、要考虑兼容性，现在写好一份文档，AI就能按你的标准干活。这种"授人以SOP"的思路，对整个工具生态的影响才刚刚开始。

最后分享两个小建议。一是别急着一次装一堆skill，先从自己最高频、最消耗精力的任务入手，做一个跑通全流程，吃透机制后再批量扩展。二是skill的迭代依赖真实使用反馈，每次用完不满意，花五分钟把"模型哪里没按规范做"记下来，集中改进SKILL.md——坚持几轮之后，你的skill会比市面上的大多数通用skill好用得多。

后续值得关注的方向，我个人比较看好两个：一个是带复杂脚本链的skill，让模型不仅能写文档、还能编排多步骤自动化任务；另一个是团队级skill库的共享与沉淀机制，一套优质的技能库，可能会成为团队在AI时代的重要资产。你现在开始积累的每一个skill，都在为这个方向打下基础。