企业官网建设流程全解析

最近AI编程圈子里“skills”这个词算是彻底火了。很多人第一反应是：这不就是给AI写个Prompt模板吗？或者干脆把它理解成一种新的插件。我最初也是这么想的，直到自己动手开发了几个、踩了一堆坑之后，才意识到Skills解决的根本不是“多存几个提示词”的问题，而是把AI从一个“你每次都得重新教一遍的实习生”，变成“你交代过一次就能长期复用干活的老手”。

这篇文章我想从第一性原理出发，把Skills究竟是什么、它和Prompt/插件/MCP的区别、如何从零开发一个可用Skill、以及安装测试中的实际经验，一次性讲透。内容更适合已经用过AI编程助手、但对Skills机制还没彻底搞明白的人。如果你是刚接触，也没关系，我会尽量把每个概念都用大白话拆开讲。

1. 从第一性原理看Skills：它不是模板，是工作流封装

1.1 Skills、Prompt、插件和MCP到底有什么区别

要理解Skills，最有效的方式不是背定义，而是对比。我做了张表，把几个容易混淆的概念放在一起看：

核心差异在“知识放在哪里”。传统Prompt是把知识塞进一次对话里，说完就没了；下次再想用，要么翻历史记录，要么重新粘贴。而Skill是把“完整的工作方法”固化成一个独立模块——它包含步骤说明、参考规范，甚至能调用脚本和模板文件。AI读到SKILL.md之后，会按照里面定义的流程执行任务，而不是凭感觉发挥。

我用一个生活化类比解释：Prompt像是你每次出门前口头告诉朋友“记得带钥匙、带充电宝、带纸巾”；Skill则是你直接给他一个打包好的旅行清单，清单上不只写着带什么，还写着遇到雨天怎么办、几点出门最合适、走哪条路线不堵车。AI拿到Skill后，就不再需要你操心执行细节了。

1.2 为什么AI编程助手都在推Skills

从我自己的使用体验看，AI编程助手在没有Skills机制前，存在三个特别难受的痛点。

第一个痛点是“对话漂移”。用Claude或Codex长对话时，开头交代的格式要求、编码规范，聊到后半段经常被遗忘。明明第一轮告诉它“注释用中文”，五轮之后它又给你冒出英文注释。不是AI变笨了，而是上下文太长，早期的约束被稀释了。Skills把约束固化在独立的指令文件里，每次调用都重新加载，稳定性高得多。

第二个痛点是“重复教学”。假设你每天都要做一个固定任务，比如“按公司规范写前端组件”，你每天都要花五分钟把规范粘贴给AI。这些规范可能长达几百行，占用了大量上下文窗口，还会打断对话节奏。Skills相当于把这个教学成本一次性付清，之后AI自己就能识别“这个任务应该用那个Skill”，你不需要再复制任何内容。

第三个痛点是“隐性知识无法沉淀”。团队里厉害的人通常有一套自己的审查清单、编码习惯、测试策略，但这些东西基本都在脑子里。Skills第一次让这些隐性知识有了标准容器——一个目录、一个SKILL.md、若干个脚本和参考文件。它可以被复制、分享、上传到社区，也就具备了“积累和传播”的属性。从这个角度看，Skills的意义不只是工具层面的，更是知识管理层面的。

2. 一个Skill的组成：SKILL.md与目录结构的规范细节

2.1 SKILL.md里到底写什么

一个Skill的本质是一个目录，目录里最关键的文件叫SKILL.md。这个名字是约定俗成的，代表“入口文件”。AI接到任务后，会先扫描Skill目录，找到SKILL.md，读取里面的元信息和指令。

SKILL.md的结构非常有讲究。头部是一个YAML格式的frontmatter，有点像Hugo或Jekyll博客的头部信息，里面是AI用来“判断什么时候用这个Skill”的关键字段。我常用的最小配置是这样：

--- name: code-review-frontend description: 用于对前端JavaScript/TypeScript代码进行系统审查。当用户要求检查代码质量、发现潜在bug、评估可维护性或代码风格一致性时使用。 ---

这里有两个字段极其重要。

name是Skill的唯一标识，安装后别和其他Skill重名。我的习惯是“动词-领域”格式，比如create-blog-post、analyze-server-log，一眼就能看出是干什么的。

description是整个Skill里最考验功力的部分。AI判断“要不要调用这个Skill”，靠的就是这个字段的文本匹配。写得太泛，比如“用于代码审查”，那用户问“这段代码有问题吗”它可能触发，问“这个函数是干什么的”也可能误触发。写得太窄，比如“仅用于React函数组件审查”，那用户用Vue项目时它就识别不出来。

我的经验是：description要包含任务领域 + 触发条件 + 典型场景。比如“当用户要求检查JavaScript/TypeScript代码质量、优化性能、排查bug或统一代码风格时使用。适用于前端项目代码审查、Pull Request评审、重构风险评估。”这句话覆盖了任务类型和常见表达方式，命中率高很多。

when_to_use字段我也经常用，它作为description的补充，告诉AI“什么时候不要用”。比如规范里可以写“不要用于Python后端代码审查，除非用户明确要求对标ESLint规则。”这个字段能有效减少误触发。

frontmatter下面就是正文部分，正文才是真正的工作指令。这里的原则是：用明确的祈使句，列出可执行的步骤，而不是写一堆抽象建议。我见过很多人把正文写成了“请仔细审查代码，注意潜在问题”这种空话，AI读完等于没读。有效写法是：

# 执行步骤 1. 先读取目标目录下所有 .js/.ts/.jsx/.tsx 文件。 2. 按以下维度逐项审查：安全漏洞、边界条件、错误处理、性能瓶颈、命名规范、模块耦合度。 3. 对每个发现，标记严重等级：P0（必须修复）、P1（建议修复）、P2（可选优化）。 4. 输出Markdown报告，按等级排序，每条发现需标注文件名与行号。 5. 如果发现高风险问题，附上最小可复现代码建议。

这种写法AI执行得特别精准，因为每一步都是可验证的。我实测下来，同样的审查任务，用空泛指示的结果和用步骤化指示的结果，质量差距非常大。

2.2 目录结构和资源引用

SKILL.md写完之后，一个成熟的Skill通常还会带配套资源。我的标准目录结构长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ ├── extract-todos.py │ └── scan-deps.sh ├── references/ │ └── eslint-rules-summary.md └── templates/ └── report-template.md

scripts目录放可执行脚本，比如你想让AI运行一个代码扫描工具、批量处理文件，都可以提前写好脚本放进这里。references目录放参考资料，比如规则摘要、API文档、样例输出。templates目录放模板文件，比如AI生成报告时需要套的Markdown模板。

这里有一个关键约定：在SKILL.md中引用这些资源时，要用$SKILL_PATH这个环境变量来定位。这是一个内置的绝对路径变量，指向Skill的安装根目录，这样无论Skill放在哪个平台、哪个目录，AI都能稳定找到文件。我的正文里会写：

使用 scripts/extract-todos.py 提取代码中的 TODO 注释。执行方式： python "$SKILL_PATH/scripts/extract-todos.py" "<目标目录>"

为什么推荐把资源做成独立文件而不是写进正文？因为SKILL.md的正文长度是有限的，写得太长会挤占上下文窗口，让AI在处理核心任务时“精力分散”。脚本和参考资料作为外部文件按需加载，既保证了指令简洁，又让AI能拿到完整信息。这个设计思路和软件工程里的“关注点分离”一模一样。

3. 手把手开发一个Skill：从前端代码审查到分镜脚本

3.1 场景拆解：把一件事讲成AI能执行的流程

开发Skill的第一步，永远不是写SKILL.md，而是拆解你的目标任务。我通常问自己三个问题：这个任务输入是什么？输出是什么？中间要经过哪些步骤？

我拿一个高频场景举例——前端代码审查Skill。这是社区里最流行的Skills之一，因为它恰好是AI擅长、但人容易遗漏的工作。

人工审查一份前端代码时，我们的关注点大致有：安全性（有没有XSS注入点）、错误处理（fetch失败有没有兜底）、性能（有没有重复渲染、大对象嵌套）、可维护性（组件有没有拆得太碎或者太臃肿）。但问题在于，每个人审查的深度和维度都不一样，今天看了安全、明天忘了性能，全凭状态。

把这件事固化成Skill的时候，就得把这些维度固定下来。我最终确定的执行流程是：先扫描目录文件清单，然后分四轮审查——第一轮查安全隐患，第二轮查错误处理与边界条件，第三轮查性能问题，第四轮查代码风格与可维护性。每轮独立输出发现，最后一并汇总成报告。

这样拆完之后，SKILL.md的正文写起来就顺理成章了。我实际写出来的部分是：

# 审查维度 按以下优先级审查： 1. 安全：DOM操作是否经过转义、是否有危险的fetch URL拼接、是否使用innerHTML注入用户内容。 2. 健壮性：async/await是否缺少try/catch、可选链是否覆盖深层访问、空数组时是否崩溃。 3. 性能：useEffect依赖是否稳定、列表渲染是否有key、setState是否放在循环内。 4. 风格：命名是否语义化、函数是否单一职责、是否存在明显重复代码。

注意看，我每条都写成了“具体检查点什么”而不是“注意安全”。AI执行时就能按图索骥，精准定位问题。

3.2 从零写到MVP：开发一个分镜助手Skill

除了代码审查这种偏工程类的Skill，Skills还能用于内容创作场景。最近社区里热度很高的分镜Skill就是一个很好的例子。很多人用AI做短视频、做动画，但AI生成的分镜脚本往往很“平”，缺少镜头语言的专业感。分镜Skill要做的就是把“导演分镜”的隐性知识封装起来。

我先拆解这个任务：输入是一段故事脚本或文案，输出是一张分镜表，包含场次号、景别、运镜方式、画面描述、台词、音效建议、估算时长。中间的步骤，我定义为：拆分叙事单元、确定主次镜头、标注情绪节奏、估算镜头时长。这套逻辑来自基础视听语言，并不复杂，但绝大多数人自己写的时候根本想不到要把“情绪节奏”单列一列。

然后我把这些定义写进SKILL.md，核心段落是这样的：

# 分镜生成规则 输入的故事内容，按以下规则输出分镜表： - 每个场景拆分为独立场次，用 SC-01, SC-02 编号。 - 景别标记：远景/全景/中景/近景/特写。 - 运镜标记：固定、推、拉、摇、移、跟、升降。 - 每行镜头必须包含“画面内容”“情绪指向”“时长(秒)”三列。 - 时长估算规则：固定镜头 3-5 秒，运动镜头 5-8 秒，重要对话镜头 2-3 秒。 - 所有画面描述使用视觉语言，禁止使用心理描写或无法拍摄的抽象词汇。

这个Skill跑起来的效果非常直观。我拿一个简单的文案测试过，AI输出的分镜表已经接近小团队初稿水平了。后来我又在上面迭代了一个版本，加入了“声画对位”的检查规则，AI会检查画面变化点有没有配上音乐变化标记，这个细节是很多新手导演最容易忽略的。

所以开发Skill的过程，本质上就是在把你脑子里“怎么做这件事”的隐性知识一点一点显性化。而AI的执行能力，会让这套流程的产出效率远远超过你手动操作。

3.3 开发中的三个常见坑

开发Skill我踩过不少坑，挑三个最典型的说。

第一个坑是description写得太泛导致AI频繁误触发。我给一个日志分析Skill写的描述是“用于分析日志文件”。结果用户让AI总结一段聊天记录时，它居然也调用了这个Skill，因为“聊天记录”被它看成了“日志”。后来我把描述改成“用于分析服务器运行产生的日志文件，包括错误日志、访问日志、应用调试日志。适用于排查服务异常、统计错误频率、追踪调用链。不用于分析普通文本对话。”加了“服务器”“错误日志”“追踪调用链”这些强特征词后，误触发率直线下降。

第二个坑是步骤写得像建议而不是指令。我以前写“审查代码时可以关注一下安全性”，AI执行时就“可以”了一下，根本没有。后来把所有模棱两可的词全部去掉，改成“必须逐行检查所有用户输入是否经过转义”，执行力立刻上来了。AI是一个指令跟随者，你给它留选择余地，它就会选最容易的路。

第三个坑是资源文件没有打包导致换机器就失效。早期我做Skill喜欢把脚本放在电脑的某个角落路径里，SKILL.md里写的是绝对路径。结果分享给朋友之后，他的机器上根本找不到这个文件。后来统一改用$SKILL_PATH相对引用，所有资源都塞进Skill自己的目录里，这个问题就不再出现了。现在我做任何Skill都坚持“开箱即用”原则：下载、安装、运行，三步到位，绝不依赖外部环境。

4. 安装、调用与测试：把Skill真正用起来

4.1 从哪找现成Skill：官方市场与社区仓库

自己做Skill之前，我建议先去社区里逛逛，看看别人怎么做、哪些流程已经被封装好了。现在找Skills的渠道主要分成三类。

第一类是官方市场。部分AI编程助手内置了Skill市场，比如Claude官方市场里的Skills分类，可以搜索、一键安装。这类渠道的优势是经过官方审核，质量和安全性有保障，推荐新手从这里下手。

第二类是GitHub。在GitHub上搜索“awesome-claude-skills”这类汇总仓库，或者直接搜“topic: skills”，能找到大量社区开发者维护的Skills。社区里有个不成文的规矩：好Skill都会附带一个清晰的README和演示截图，下载之前先看两点——最近更新时间是否超过一年，以及fork和star的数量是否正常。长期没更新的Skill，大概率对新版本不兼容。

第三类是独立博客和技术社区。很多开发者会把自己辛苦做出来的Skill写成帖子分享，附带下载方式。这类Skill往往带有很强的个人实践痕迹，质量参差不齐，但也常常能发现惊喜，比如有人把“小红书文案生成”“PPT结构生成”都做成了Skill。

找Skill时有个容易被忽略的点：留意许可证。有些Skill用的是MIT协议，你可以随意改；有些则是“只允许个人使用”或者带有非商业条款。如果你打算把Skill用在公司项目里，这一步一定要看清。

4.2 安装与一键测试

不同平台的安装方式略有差异，但整体逻辑是通用的——把你的Skill目录放到指定的Skills根目录下。以我用的Claude为例，安装流程简单说就是：找到Setup或Skills管理页面，选择“Install a Skill”，然后指向Skill所在的目录或压缩包，AI会自动扫描并注册。

安装完之后，我强烈建议立刻做一轮“一键测试”。所谓一键测试，就是构造一条包含触发关键词的指令，比如我装完前端审查Skill之后，会直接发一句“请用code-review-frontend技能审查一下当前项目src目录下的代码”。如果AI正确调用了Skill并按照SKILL.md的步骤输出结果，说明安装成功。如果AI回复“我没有这个技能”或者“我没有安装该插件”，那就需要检查目录路径是否正确、SKILL.md的frontmatter是否解析失败、以及Skill名称是否和文档一致。

还有一种更精细的测试方法，叫快照对比。先在没装Skill的情况下让AI执行一次任务，记录输出；再装上Skill执行同样的任务，对比两次输出差异。这个差异越大，说明Skill对AI行为的影响越明显。这个方法尤其适合验证“我的Skill到底有没有起作用”。

4.3 调试和回归测试

调试Skill是一个反复迭代的过程。我的调试流程基本是：跑一次测试用例，观察输出，定位偏差，修改SKILL.md，再跑一次。关键点在于测试用例要有针对性。

我通常会准备三组测试用例。第一组是标准用例——完全匹配description中描述的典型请求，测试AI能否正确触发。第二组是边界用例——请求里绕了点弯子，比如“帮我看看这个文件夹有没有明显的问题”，测试AI能不能识别出这个需求本质上属于前端审查。第三组是负向用例——故意发一个完全无关的请求，比如“帮我写一首诗”，测试AI会不会错误触发。

这三组用例跑完，基本能判断一个Skill的“判别力”和“执行力”是否合格。我见过很多半成品Skill，标准用例能过，边界用例就抓瞎，负向用例更是疯狂误触发。出现这种情况，十有八九都是description没写好，其次是正文里的触发条件写得太宽泛。

还有一个容易被忽视的调试技巧：检查AI的思考过程。很多编程助手支持展开查看“AI推理摘要”或“调用日志”，里面会记录它为什么选择调用这个Skill、加载了哪些文件、执行了哪些步骤。调试时看这个日志，能发现很多输出层看不到的线索，比如AI明明读了report-template.md但没有套用模板，说明正文里“必须使用模板输出”这个指令的语气还不够硬。

5. 一张表解决90%的问题：常见故障排查实录

用Skills的时间越长，遇到的问题类型越集中。我把这些问题整理成了一张排查表，遇到情况时照着定位就行。

这张表里最常出问题的两项，一个是description质量，一个是脚本执行权限。description的问题前面已经说过，脚本执行的问题则是个“隐藏杀手”——很多人写了非常棒的辅助脚本，但在正文里只写了“运行脚本”而没有写清楚用什么解释器执行、脚本是否有可执行权限。结果AI调用了Skill，脚本却跑不起来，整个流程就卡死了。

我现在写SKILL.md时都会在脚本调用那一节固定加上三行：解释器路径、执行命令示例、预期输出格式。这样即使AI没有任何相关经验，也能照葫芦画瓢把脚本跑起来。

排查完上面所有问题之后，还有一个终极兜底手段：把Skill目录删了，从零开始用一段精心构造的Prompt完成同样任务。如果两者的执行效果差距不大，那说明这个Skill的封装没有真正提升AI的效率，该重新设计而不是继续打补丁。这个方法听起来有点极端，但确实能逼着你把注意力从“修bug”拉回到“核心价值”上。

我个人最近一个比较满意的Skill是“短视频分镜助手”，从最初只有一段分镜规则，到后来加入了景别对照表、运镜参数模板、经典电影案例分析三个references文件，前后迭代了差不多两周时间。每次迭代都在前一次的实际输出上找问题，改的不是文字，而是“AI到底在什么地方理解偏了”。这个过程让我对Skills的理解深了很多——它本质上是一个沟通器，让人类的隐性经验变成AI可以执行的结构化协议。

如果你也想试试，我建议从自己日常工作里最重复的那个任务开始，不要贪大，先做一个小而美的Skill，跑通了再慢慢加功能。等你真正上手之后会发现，这玩意儿确实会让AI从一个问答工具，变成一个能被你持续调教的执行体。