企业官网建设流程全解析

1. 从提示词到“技能包”的进化

这两年搞AI编程和AI自动化，我最大的感受是：光会写提示词已经不够了，真正拉开效率差距的，是你有没有把提示词、工作流、工具调用固化成一整套可复用的能力模块——圈内现在把这玩意儿叫“skills”，中文语境里有人翻译成“技能”，但我更愿意叫它“技能包”或者“操作模式”。

我在实际项目里经常遇到这种场景：同一个团队里，明明大家都在用Claude Code或者Codex这样的AI编码工具，但产出质量天差地别。有的人能把代码生成、项目分析、测试用例、Bug修复这些环节做成一条流水线，丢进去一个需求就能稳定产出高质量结果；有的人还在靠每次手打几百字的提示词，一天下来能折腾三四个来回。差别在哪？就在有没有把“经验”沉淀成“skills”。

今天这篇东西，我打算把围绕着“skills”这词的坑和心得一次性讲清楚。不管你是正在折腾Claude Code、Codex、OpenCode、Cursor这类工具，还是想给自己搞一套专属的skill体系，甚至是想弄明白“skills如何调用MCP”“agent skills有哪些推荐”，这篇文章应该都能给你一个比较完整的答案。

先说重点结论：skills本质上是一种结构化的指令包，让AI不只是记住你说的一句话，而是拥有一个可以跨项目、跨场景复用的专业操作能力。它把提示词、步骤规范、约束条件、工具调用方法、示例参考全部封装在一起，类似于给AI装了一个岗位说明书加操作手册。早期大家诟病AI“智商高但不会干活”，很大程度上就是因为缺少这种结构化能力约束。

2. 核心概念与工作原理拆解

2.1 skills到底是什么：一个“岗位说明书加操作手册”的复合体

我复盘了市面上主流的AI编程工具，包括Claude Code的官方技能生态、Codex的skills、OpenCode里的agent技能，还有社区里Matt Pocock这些大佬在推的实战技能包，发现它们虽然在实现细节上各有差异，但底层设计逻辑是高度一致的。

一个典型的skill包含这么几层东西：第一层是触发描述，也就是告诉AI“当用户遇到什么场景时，你应该调用这个技能包”；第二层是操作步骤，把完成这个任务需要走的流程规定清楚，不讲废话直接干活；第三层是规则约束，比如代码风格、文件命名、测试要求、输出格式，这些是保证质量和一致性的关键；第四层是参考示例，放两到三个高质量的输入输出例子，AI才能准确理解你的预期；第五层是工具调用说明，如果这个技能需要操作外部工具，比如跑测试、查文档、读数据库，在这里面定义好调用方式。

我拿吴恩达在agent skills教程里说过的一个观点来印证：给AI系统配置角色和技能，本质上是在做“工程化”，不是在做“提示工程”。提示词决定一次对话的走向，skills决定一个智能体在整个生命周期里的行为模式。

2.2 为什么不能把skills做成“一个大提示词”

很多人刚开始接触skills的时候，会觉得这不就是把提示词放个文件里嘛，有什么了不起的。还真不是。我自己踩过这个坑。

最开始我确实尝试过把一份非常详细的任务说明直接塞给AI，让它当成系统提示词来处理“代码审查”这件事。结果是什么呢？第一，上下文窗口被大量占用，一个几千字的提示词塞进去，真正处理业务上下文的空间就少了；第二，提示词太长之后，AI的执行稳定性明显下降，它会在执行到最后时报错或者偏离最初的规则要求，注意力被稀释；第三，完全没法模块化复用。我想让它在代码审查时顺带生成测试用例，就不得不改整个提示词，牵一发动全身。

skills的聪明之处在于，它将原本“一坨”内容按职责拆分：描述文件只管“什么时候触发这事”，SKILL.md文件只管“怎么干活”，脚本和模板文件负责具体执行。AI在第一次读取的时候就知道你这个技能包的边界在哪里，知道哪些规则是必须遵守的，哪些是参考建议，执行效率和稳定性都提升了一个量级。

2.3 从“会聊天”到“会干活”的能力跃迁

我观察到一个比较有意思的现象：同样是让AI写一份数学建模论文的辅助分析，直接问和用skills驱动，展现出来的水平差异是“业余助手”和“专业顾问”之间的差异，这个判断我对比过很多次得出的结论。

核心原因是，skills内嵌了领域专家的操作惯性。拿数学建模来举例，一个专门为建模设计的skill，它的操作流程大概率会是：先拆解问题，确定建模类型；再列出假设条件；然后给出一套从数据预处理到模型求解的框架；最后按论文结构输出结果。而如果让通用AI自由发挥，它常常会跳过需求确认，直接开写一个看起来很像样但实则泛泛而谈的方案，如果被追问又容易推翻重来。

所以我在实际推技能方案的时候总跟人说一句话：skills解决的不仅仅是“AI会不会”，更核心的是解决了“AI会不会稳定地、按专业套路地做”。

3. 主流平台的skills生态与选择建议

3.1 Claude Code的skills体系：生态最完整的先行者

先说Claude Code。这个工具应该是当前AI编程助手里面把skills玩得最明白的，社区生态也最丰富。在GitHub上搜claude code skills，你能找到大量现成的技能包，从PPT生成、代码审查、前端还原设计稿，到专利写作、渗透测试、移动端开发，五花八门。很多人第一次看到这个列表会觉得“太夸张了吧”，但实际上正是这种丰富的生态让Claude Code从一个命令行工具变成了一个真正意义上的“智能体工作台”。

那Claude Code里的skills文件是放在哪儿的呢？常规路径是在项目的.skills目录里放一个SKILL.md，或者放在用户级目录~/.claude/skills下面，这样每个项目都能直接调用。更核心的一点是，Claude Code支持在skills里直接调用MCP工具，这一点等会儿我会单独展开讲，因为它把技能的能力边界拓宽了很多。

我之前用过一个社区推荐度很高的npx命令来安装生态技能，命令行大概是npx skills add xxx/yyy --agent claude-code，这么一行就能把远程的skills仓库拉下来装进本地的技能目录里，整个过程非常丝滑。我个人的建议是，新手上路先别急着自己造轮子，把社区里评价高、star多的skill用起来，用熟练了你自然知道自己的技能包应该怎么写了。

3.2 Codex与OpenCode：同一个理念的不同生态

Codex在skills上做了挺多差异化的尝试。它的核心特点是侧重项目级分析场景，比如Codex分析项目结构、梳理技术栈、识别架构瓶颈这类工作，用skills固化之后效果很明显。据了解，GitHub Copilot底层的一些代码生成工作流也做了类似的“技能化”改造，只不过对外名称不一样。

OpenCode这个工具可能对国内用户来说稍微冷门一点，但它在agent skills上的设计非常值得关注。它允许用户以非常细的粒度定义工具，并且把“技能创建器”做成了可视化的配置流程。如果你本身已经用熟了Cursor这种编辑器，想往外探索一下命令行风格AI工具，OpenCode的skills设计应该会给你不少惊喜。

Baoyu skills在国内社区讨论度也很高，它的特点在于把一套开箱即用的技能配置打包得很整齐，基本上拉下来就能跑，对想快速体验agent skills效果的人来说是最省事的一条路。不过我用下来的感受是，这类聚合技能的通用性有了，但具体到你的业务场景，还是要做个性化调整的。别人的鞋合不合脚，只有自己穿了才知道。

3.3 场景向skills推荐：怎么选不踩坑

下面这张表根据我实际使用和社区反馈整理出来的按场景选技能的建议，含个人主观判断，仅供参考：

如果你需要的是渗透测试、代码审计这类偏安全的技能，我多说一句：千万别拿你搜到的脚本直接往生产环境怼，先看明白它的每一步在做什么，再在隔离环境里跑通，安全合规这根弦任何时候都不能松。

4. 从零开发一个自己的skill：完整实操

4.1 前置准备与目录结构

开发自己的skill之前，先把自己的使用场景想明白，再动手写文件。我推荐一个最简单通用的目录结构：

my-skills/ ├── SKILL.md # 技能的主文件，必备 ├── scripts/ # 放辅助脚本（可选的） └── assets/ # 放参考模板、示例文件（可选的）

SKILL.md的内容格式一定要用标准Markdown，头部建议加YAML格式的frontmatter来声明技能名称、描述和适用场景。这里有一个特别重要的细节：描述部分一定要写清楚“什么情况下触发”，AI是靠语义匹配来决定调用哪个技能的，描述写得太模糊，它会在需要的时候完全不调用，或者在最不该调用的时候蹦出来。

4.2 编写SKILL.md的核心步骤

技能主文件的编写，我习惯按照四个模块来组织：

第一块是“角色目标”，用一两句话告诉AI它在这个技能里扮演什么角色。比如说你这个技能是“前端设计稿还原助手”，那角色目标可以写成“你是专业的前端开发工程师，负责根据设计稿图片生成还原度高、兼容性好的页面代码”。

第二块是“执行流程”，把整个任务拆分成几个有序的步骤。步骤不能太粗，也不能太细，太粗了AI不知道该怎么做，太细了会限制它的灵活性。我以前碰到的问题就是步骤写得太大，AI在执行到一半时就在原地打转。

第三块是“规则约束”，把你最在意的几条硬性规则写清楚。这里语法上有一点小技巧，规则尽量用肯定句而不是否定句。比如说“推荐使用flex布局实现页面结构”，比“不要用table布局”要有效得多。

第四块是“输出模板”，规定AI输出的最终格式。这一点在处理PPT、专利、测试用例这类需要输出标准文档的场景里格外重要。

4.3 一个可直接复用的例子：图片还原设计稿技能

这里举一个我最近刚做的例子，也是热词里提到过的场景：给前端开发用的“图片还原设计稿”技能。因为很多团队目前设计稿是以图片形式给的，AI虽然有视觉能力，但如果不对它做专门的约束，它还原出来的页面经常是“远看还行、近看全歪”。

我的SKILL.md核心内容大概是这样设计的：

• 角色目标：定义“像素级还原设计稿”的前端开发角色。
• 执行流程：先分析图片的整体布局和设计风格；再识别颜色体系、字体大小、间距规律；然后生成HTML结构，再写CSS样式；最后输出样式说明文档。
• 规则约束：必须使用语义化标签；样式优先使用CSS变量定义主题色；禁止硬编码奇怪的颜色值；必须标注哪些参数需要后端接口提供。
• 输出模板：代码文件结构与说明文档的固定格式。

设置成技能之后，我再丢设计稿给AI，输出质量就明显稳定了，尤其是颜色、间距这类细节很少再乱来。为什么？因为技能里的规则约束把AI潜意识里“随便设计一下”的欲望压住了，让它走标准化的前端还原流程。

4.4 命令行如何源码安装skill

自己写好技能之后，如果只在本地项目里用，放到项目的.skills目录下就行了。但如果想跨项目使用或者分享给别人，推荐用npx方式放到用户级目录，或者直接推送到GitHub。

源码安装这块我多说一句。很多人在网上看到类似npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这样的命令，就直接复制粘贴，结果在安装的时候莫名其妙卡住了，其实很多问题都出在本地CLI版本和安装脚本不兼容上。安装之前先确认环境变量和Node版本没问题，再执行安装命令，如果网络环境不稳定，还有更稳妥的源码安装方式：直接把仓库clone下来，然后手动拷贝到对应的skills目录里。

# 示例：放到Claude Code用户级技能目录 git clone https://github.com/xxx/my-skills.git ~/.claude/skills/my-skills

5. skills如何调用MCP工具：进阶技能必学

5.1 MCP给skills带来的能力扩充

MCP我简单说两句，它的全称是Model Context Protocol，即模型上下文协议，本质上是一条让AI模型与外部工具、数据源进行标准化通信的“通用USB接口”。以前的AI工具之间互相不认，你在Claude里写好的脚本换到Codex上就不能直接用；有了MCP之后，工具和模型之间的对话有了统一格式，跨越了平台边界。

skills和MCP的关系，可以理解成：skills是大脑里的操作手册，MCP是手和脚。操作手册告诉你该用什么工具，MCP负责把你的指令翻译成工具能听懂的语言并执行。

为了让AI基于项目上下文去检索并把检索结果融合进分析结论里，演示如何构造能自动执行的“skills去调MCP工具”其实是一种很标准的做法。也就是说，一个skill里可以写明“第一步调用MCP工具检索项目文档，第二步根据检索结果生成方案”，AI在执行时就会按照这个流程去使用外部工具。

5.2 一个具体配置例子：测试用例生成技能

我用测试用例生成技能来举例说明。测试用例生成这个场景，让很多团队很头疼，因为光靠大模型的直觉去写测试用例，覆盖率和断言质量往往不稳定。通过把测试用例生成能力做成一个skill，并在里面配置MCP调用，我就能保证每次生成的用例都符合我个人的工程规范。

在skill的规则约束里明确写上：

• 调用MCP工具获取被测函数/模块的源代码和API定义；
• 分析函数输入输出参数与边界条件；
• 基于代码实现生成最小完备的用例集；
• 每个用例必须包含正常路径、异常路径和边界条件三类。

这样配置完之后，AI不再凭空脑补测试场景，而是先通过MCP拿到真实的代码上下文，再结合技能里固化的测试设计原则来生成用例。说实话，这个效果是我自己手动写prompt时很难稳定复现的。

5.3 实测案例：文档检索加PPT生成的双技能组合

再分享一个更复杂一点的场景。我做过一个自动化写PPT的流程，它结合了“文档检索”和“PPT生成”两个skills，实际技术链路是：先用文档检索skill去检索项目仓库里的设计方案、周报、竞品分析，再把检索结果输入到PPT生成skill，由它来决定版式、提炼要点、调用MCP工具渲染最终文件。

这个流程如果没有MCP，基本上是不可能实现的，因为AI没有办法主动从仓库里把资料捞出来，然后再把结果喂给绘制工具。但有了MCP之后，两个skill之间可以实现无缝的数据流转。如果你研究过“skills如何调用MCP工具”这个热搜词，下面这个原则值得牢记：skill负责“怎么用”，MCP负责“用什么”，界限划分清晰，才不会在复杂场景里变成一笔糊涂账。

6. 常见问题排查与避坑心得

6.1 skills不生效：常见的三个原因

“我明明把SKILL.md放进去了，AI怎么完全不按套路来？”这个问题在社区里被问了无数次，我也遇到过。根据实操经验，八成是以下三个原因造成的。

原因一是描述写得不行。AI加载技能靠的是语义匹配，如果SKILL.md开头那段描述写得跟你的需求对不上，就会发生“看不到技能”的问题。解决方案是把技能适用场景、触发条件、关键词都写明确，越具体越好。

原因二是文件路径不对。Claude Code的skills和Codex的skills存放目录不一样，你在网上抄代码的时候最好先弄清楚对方用的是哪个工具，路径照搬大概率报错。

原因三是缓存。有些AI工具会缓存上下文或技能列表，你修改了SKILL.md之后，它可能还是按旧版本执行。按我的经验，改完技能之后最好重启一次会话，重新加载一次上下文，不要指望热加载。

6.2 表格速查：SKILL.md编写常见错误与修正方向

6.3 技能越多越好吗：控制“技能过载”

随着可用skill越来越多，我开始遇到一个比较反直觉的问题：装了太多技能之后，AI反而更“不会干活”了。原因不复杂，技能列表一长，AI在选择调用什么技能时会出现混乱，有时甚至会把几个不相关的技能组合叠加，产生令人哭笑不得的结果。

用了一段时间后，我的习惯是每个项目只保留最多两三个真正核心、常用的技能，把其他的统统移出到备份目录。特别是那些一次性用过的“一次性技能”，用完就删，不然它躺在目录里还会干扰后续调用。技能的核心价值不在多，而在准、稳、可复用。

6.4 多工具协同时的路径兼容问题

还有一个细节值得提醒。如果你像我一样在多个AI编码工具之间切换使用，比如同时用Claude Code和Codex，那就要注意它们对技能目录的约定不太一样，包括URL路径的格式和处理策略也都不同。我在opencode上正常用的技能配置，切到Claude Code之后如果不改路径，就完全识别不到。建议在换工具时，先到它们各自的文档里查一下技能目录路径，再决定是复制还是软链接。

7. 经验心得：技能建设这件事的长期回报

最后说点个人体会。我见过太多人折腾skills，是为了“跟上热点”或者“显得专业”，但在我自己把技能成体系地建设了大半年以后，我的真实感受是：skills真正改变的是你对AI的使用哲学。

以前我写提示词，每一句话都是在“教”AI怎么做；现在我写技能，是在“定义”AI怎么持续稳定地做一件事，然后把管理过程交给配置本身。这种思维方式转变之后，我对“AI会不会取代程序员”这件事的看法也变了。工具不会取代会用工具的人，但会用工具的人之间，差距会越来越大。

如果你现在的工作里，有哪一类任务是你每周都要重复处理的，我会特别建议你把那件事做成一个skill。花一个下午的时间写SKILL.md，之后每次都能省下至少几个小时的重复劳动，这个投资回报率是非常可观的。你写第一个技能的时候可能会觉得麻烦，写到第五个之后，你自己就能总结出一套属于自己的技能设计方法论了。

毕竟，真正好用的人工智能系统，不是从一个宏大的需求开始的，而是从一个“打破重复”的念头开始的。