企业官网建设流程全解析

为什么"skills"突然成了AI编程圈的顶流热词

如果你最近逛GitHub、刷技术社区，大概率会看到一个词反复出现：Skills。不管是"Claude Code怎么手动装GitHub上的skills""superpower skills安装"，还是"数学建模skills推荐""前端开发skills"，甚至"AI漫剧常用skills"，大家都在讨论同一个东西。我最早注意到这个趋势是因为团队里用Claude Code写代码的人越来越多，而真正让效率拉开差距的，不是谁更会写Prompt，而是谁给自己的AI助手装配了更合适的Skills。

简单说，Skills就是给AI编程Agent（比如Claude Code、Codex、OpenCode）外挂的可复用"技能包"。你可以把它理解成给一个已经很聪明的实习生配上标准作业手册：不用每次交代背景、不用反复纠正套路，只要触发对应的场景，AI就知道该按什么流程干活。这篇文章不打算讲概念层面的"AI技能学"，而是直接用我自己的实操经历来拆解——Skills到底是什么、怎么手动装、怎么写、怎么选、以及哪些坑我踩过之后发誓不再踩。如果你是刚被"skills"这个词吸引过来的开发者、学生，或者准备参加数学建模竞赛想用AI提效的人，这篇文章应该能帮你省下不少摸索时间。

1. Skills机制的本质：为什么不是"Prompt"而是"技能包"

1.1 从Prompt到Skills：一次对话式编程的范式变化

先说个我自己的经历。半年前我用Claude Code写一个前端组件库，每次处理重复性任务——比如新增一个按钮组件、写单元测试、生成文档——都要在对话里反复粘贴设计规范、代码风格约定、测试要求，一次两次还行，十几次之后人和AI都会"精神涣散"。后来我把这些约定写成一段超长Prompt，总算缓解了一点，但很快遇到另一个问题：Prompt太长之后，AI反倒容易"抓不住重点"，而且不同任务混在同一个上下文里，经常出现"写测试的时候忽然想起风格规范"这种注意力漂移。

Skills机制改变的恰恰是这个底层逻辑。它不是一段写在对话开头的超长Prompt，而是一套可触发、可复用、按需加载的"技能模块"。每个Skill自带一份说明文档（通常是一个SKILL.md文件），描述了它适用的场景、工作流程、产出格式，以及可选带的模板文件、示例代码、参考数据。AI在运行时会先读取这个说明书，再按说明书里定义的步骤干活。

这个设计背后有一个很关键的理念：渐进式披露（progressive disclosure）。日常对话时AI不需要把十几个技能的细节全部塞进上下文，只在任务命中某个技能关键词时，才把对应的技能文档加载进来。这就好比一个工具箱，Prompt像是把所有工具说明书摊在桌面上，而Skills是你需要拧螺丝的时候才拉开抽屉拿出螺丝刀，顺手还带着扭矩规范和验收标准。上下文更干净、命中更精准，AI的输出质量自然就上来了。

1.2 Skills与MCP、插件、脚本的分工差异

聊Skills的时候很多人会问：这不就是MCP（Model Context Protocol）或者插件吗？其实不完全一样。MCP解决的是"AI如何连接到外部工具和数据源"的问题，比如连数据库、查文件系统、调API；Skills解决的是"AI如何按照某套流程和方法论完成一类任务"的问题，比如怎么写数学建模论文、怎么跑前端代码审查、怎么生成分镜脚本。

如果用传统软件开发来类比：MCP像是各种系统接口和SDK，Skills则像是沉淀下来的业务流程模板和岗位SOP。两者可以配合使用，但不该混为一谈。普通的命令行脚本也行，但它做不了"理解任务上下文之后自行编排执行顺序"这件事；Skills之所以被单独拎出来，恰恰是因为它承载了AI自主规划任务的那部分智力工作。

这个区分直接决定了选型思路。比如你想让AI辅助数学建模，最有价值的不是给它装一个能调矩阵运算库的MCP（那本来就该自己写代码），而是给它一个"数学建模工作流"Skill——从赛题解读、假设提出、模型选择、代码实现到论文分段写作，每一步该怎么推进、产出什么格式，都定义得明明白白。

2. 动手装第一个Skill：手动安装GitHub上的Skills完整过程

2.1 先搞清楚你的Agent把Skills放在哪里

装Skills最关键的其实不是"知道命令"，而是"知道目录"。不同的AI编程工具对Skills的存放位置、命名规范有各自的约定。以Claude Code为例，用户在自定义技能时，需要先找到全局配置目录~/.claude/skills/，或者项目级目录.claude/skills/，把Skill文件夹放进去即可。Codex也有类似的路径结构，一般推荐放在~/.codex/skills/下；而OpenCode这类开源工具，则通常在文档里标明它读取的路径。

这里我强烈建议第一次上手的人先把官方文档里"Skills存放目录"那部分截图存下来。因为装完之后如果发现技能没生效，八成不是内容写错了，而是路径不对——我就干过一次把skill文件夹放在~/.claude/skills_old/然后把原生目录晾在原地的蠢事，结果AI完全没有识别到任何新增技能。

目录确定之后，还需要检查SKILL.md文件的命名规范。绝大多数工具要求这个主文件名就叫SKILL.md（全大写），放在技能文件夹的根目录。文件夹名理论上可以随意，但为了可读性，我习惯用短横线连接小写英文单词，比如code-review-assistant。

2.2 从GitHub手动拉取并安装的三种方式

从GitHub安装一个现成的Skills仓库，说起来就三步：下载、放到对应目录、重启或者重载会话。但实操里根据仓库的结构不同，会分成三种情况，我分别说一下。

第一种最省事，仓库本身就是单一技能，比如有的项目就提供一个my-skill文件夹，里面直接是SKILL.md。你把这个文件夹克隆下来，拷到~/.claude/skills/下，即可生效。第二种是"技能集合仓库"，比如 anthropics/skills 这种官方仓库，里面包含文档技能、PDF处理技能、PPT技能等一堆子目录。这时候不要整个克隆后直接扔进skills目录，而应该进仓库里挑选你需要的子文件夹，复制或链接到skills目录。整个仓库直接塞进去会污染技能列表，让Agent每次加载时都要检查一堆并不需要的目录，白白浪费上下文和轮次。

第三种是"带资源依赖的技能"，某些Skill不只是有一个SKILL.md，还需要配套的模板文件、Python脚本、JSON配置、图片素材。常见于数学建模、数据报表这类场景。这种技能安装时一定要把整个文件夹完整搬过去，别只拷贝SKILL.md。我就见过有人只复制了主文件，结果Skill在自己电脑上生成了一半流程就报错——因为它找不到工作目录下的模板。

有些团队用"符号链接"（symlink）来管理技能库，把GitHub克隆的仓库和Agent的skills目录软链起来，这样后续git pull更新技能时不用手动覆盖，算是一个维护技巧。Windows用户注意，创建符号链接需要开发者模式权限，或者用管理员权限的终端执行。

安装完成后，最好的验证方式是在对话里直接说一句触发语。比如你装的技能是"前端开发助手"，里面定义的关键词是frontend review，那就直接告诉AI："用frontend review看一遍这段样式代码"。如果AI给出了符合技能模板里定义格式的回答，说明装成功了；如果它像没看见一样，先检查目录层级，再看有没有重名技能干扰触发。

2.3 主流开源skills仓库速览

下面这几个仓库是我实际用过的，按使用频率排个序：

其中superpowers是我个人非常推荐早点装的。它本质上是一个"编排型技能集合"，不仅仅教AI执行单一任务，还设计了多个Skills之间的嵌套调用逻辑，比如先规划、再测试驱动开发、最后做代码审查。用起来之后最大的感受是AI的"自主性"明显变强了，但这也会带来一个问题——对于只是随手写个小脚本的人来说，它反而显得重，装之前先想清楚自己的需求。

3. 自己动手写一个AI Skill：从零开发的全流程

3.1 一个标准Skill的文件结构长什么样

如果你已经装了好几个现成Skills，大概率会好奇：这东西能不能自己写？答案是不仅能，而且写Skill本身就是一次很好的"梳理自己工作方法论"的过程。

一个标准的Skill文件结构大概长这样：

my-skill/ ├── SKILL.md # 技能主文件，含名称、描述、使用步骤 ├── assets/ # 可选：模板、脚本、辅助资源 ├── examples/ # 可选：输入输出示例 └── reference/ # 可选：参考资料、规范文档

SKILL.md里的核心字段并不多。常见的有name（技能名字）、description（技能描述，说明什么场景触发、解决什么问题、不能解决什么），然后是正文部分——用## 工作流程或者### 步骤这类Markdown结构来写使用时需要遵循的步骤。

有一个很重要但容易被忽视的点：Skills的正文越结构化，AI执行越稳定。不要写"写一份高质量的报告"这种抽象指令，而是写"第一步：读取分析对象；第二步：按照模板填充数据；第三步：输出PDF格式报告并包含以下四个章节"。AI再聪明，它对模糊指令的解读稳定性也远不如对明确步骤的执行稳定性。

3.2 用"文档处理"场景手写一个技能示例

我拿自己的一个实际技能来拆解。有段时间我每周要给项目组导出一份周报，数据来自多个表格文件，格式要求整齐划一。每次让AI做这件事都要重新交代字段含义、排序规则、输出的Markdown表格结构，很烦。于是我就写了一个叫weekly-report-builder的Skill：

--- name: weekly-report-builder description: 从周报数据文件夹中读取内容，汇总为统一格式的周报Markdown。 适用于每周生成周报的场景，关键词：周报汇总、weekly report。 --- ## 工作流程 1. 扫描指定目录下的所有CSV/Excel文件，读取文件名和修改日期。 2. 对每个文件执行数据清洗：去除空行、统一日期格式为YYYY-MM-DD。 3. 按照项目维度进行数据聚合，计算每个项目的总投入小时数和关键产出。 4. 输出到模板模板文件中的Markdown结构，章节顺序固定为：本周概览、项目进展、风险与问题、下周计划。 5. 如有缺失数据，在对应位置标注"待补充"，不得臆造。 ## 注意事项 - 只处理用户指定的目录，不要递归扫描全盘。 - 遇到无法解析的日期值，保留原始文本并标注。

写完之后我把它放进~/.claude/skills/weekly-report-builder/。从那以后，我只要在对话里说"生成这周周报"，AI就会自己跑完上面这套流程，输出格式稳定得仿佛一个有十年经验的助理在干活。这个体验上的跃升，促使我开始注意"什么样的任务值得写成Skill"。

3.3 什么样的任务值得做成Skill

不是所有任务都值得写成Skill。我总结过三个判断标准，命中任意两个，基本就值得写：一是"重复"，你发现自己每周/每天都让AI做同一类型的事；二是"稳定"，任务的输入输出格式相对固定，流程可以被枚举；三是"复杂"，步骤超过五步，靠临时编排容易漏环节。

反过来，那种每次需求都变、拼接感很强的创意任务，就不太适合做成Skill。比如"帮我想一个短视频选题"，这种属于创意发散，写进Skill反而会限制AI的发挥。适合的方向是"用固定流程产出一致结果"的任务，比如批量改代码风格、生成测试用例、汇总周报数据、检查依赖冲突、写数学建模论文的固定章节。

写Skill期间的迭代也值得说一句：第一次写基本不会完美，我建议把Skill文档当成代码来维护，接入了两三次之后，根据AI实际执行时的偏差去微调"工作流程"部分。比如我最初给周报技能定义的字段在真实数据里有两种别名，加了一条 "兼容处理" 说明之后，准确率立刻就上来了。

4. 哪些开源Skills值得收藏：按场景选型参考

4.1 开发提效类Skills：从代码审查到TDD

如果你以写代码为主，我建议优先关注两类：代码审查类Skill和开发流程类Skill。代码审查类Skill的核心价值在于把团队的编码规范固化下来，AI审查时不只是看看语法错误，而是逐条核对规范、识别设计隐患、给出修改建议。我试过把项目里的Style Guide写成一个矩形规则传入Skill之后，AI给出的审查意见明显更有针对性，不再是泛泛的"可读性有待提高"。

TDD（测试驱动开发）相关Skill则是superpowers这类技能集的招牌功能。装好之后，AI接到一个需求时会先引导你补充测试用例，再写实现代码，再运行测试并迭代。对于习惯先写实现再补测试的开发者来说，这套流程一开始可能有点别扭，但坚持一周之后，带来的直接收益是提测阶段的低级bug明显变少。

另一个容易出效果的是"Git提交信息与Changelog生成"类的Skill。它可以根据你的diff结构，按约定式提交规范生成commit message、PR描述和Changelog。原来一个PR从写完到提交可能要磨10分钟描述，现在只要跑一下技能，内容质量比我手写还稳定。

4.2 数学建模与竞赛场景：让Codex Skills帮你赢在流程

竞赛场景里，Skills的价值可能比日常开发更大，因为赛题流程高度标准化。以数学建模竞赛（包含华为杯这类赛事）为例，一个完整的数学建模流程是：解读赛题、拆解问题、提出假设、选择合适的模型、编程求解、结果验证、撰写论文。这套流程每场比赛都要走一遍，但每次的题目、数据、结论都全新，因此特别适合用"流程型Skill"来管理。

网上流传的好用数学建模Skills，基本上都是围绕上述环节做的增强。比如有的Skill专门负责"建模思路生成"，它要求AI在输出模型之前先列举3种不同建模路径，比较各自的假设强度和适用性，再给出推荐——这能有效防止AI一上来就给一个看似高大上但根本不适配数据的模型。

还有一些"论文排版"类Skill，负责把求解过程、图表、公式说明组装成竞赛论文结构。今年华为杯很多队伍反馈"Codex的skills很好用"，大概率不是因为AI模型本身变强了多少，而是因为在时间压力下，技能包帮他们把每一步都框在了正确轨道上。注意一点：竞赛规则里对AI辅助工具的使用限制也不一样，使用前务必先看赛题规则，别因为技能好用就踩了合规红线。

4.3 AI漫剧、前端开发等垂直场景的Skills

除了编程和竞赛，Skills在内容创作领域也很火。所谓"AI漫剧常用skills"，本质是把漫画/短剧的工业化生产流程固化成技能包：角色设定生成、分镜脚本拆解、风格一致性提示词、镜头语言控制、对白节奏模板。做漫剧的人往往不是不会用AI，而是每次生成之间的风格漂移太严重；用上Skills之后，等于把"风格锚点"沉淀成了固定配置，生成效率和一致性都上来了。

前端开发方向的Skills相对成熟，比如自动生成React组件、编写Storybook文档、检测CSS样式冲突、接管无障碍（a11y）检查等。我试过最顺手的是一个"前端代码审查与重构"的组合技能：AI能按组件边界拆解一个几千行的巨型文件，输出重构步骤，并在每步附上可验证的测试策略。这个场景拷贝之后，比单纯让AI"帮我重构一下"要靠谱得多。

4.4 常用Skills资源站与发现渠道

找Skills的资源渠道，我推荐顺序是：GitHub官方技能库、社区精选清单、以及技能分享站点。GitHub上搜awesome-ai-skills能找到不少热心的内容合集，其中有些是英文列表，也有中文整理版。个别在线平台会提供网页版Skills浏览和导入，搜索 "skills网页版进入" 能发现一部分，但稳定性参差不齐，我更建议直接以GitHub仓库为准。

选Skills的通用标准可以归纳为三条：维护活跃度（看最近提交时间）、文档完整度（有没有清晰说明触发场景和流程）、安装用户量（如果能看到star数或下载量）。不建议只看标题看起来牛就安装，因为很多技能包之间会互相干扰——尤其同名技能，会覆盖触发关键词，导致装了新的、旧的不生效，排查起来很头疼。

5. 踩坑实录：Skills安装与使用中的典型问题排查

5.1 装了不生效：路径与重载是最常见病根

先说一个我自己的血泪排查经历。某次我装了一个code-review技能，放进了~/.claude/skills/下，然后在对话里说"帮我审查一下这段代码的规范问题"，结果AI完全无视新技能，还在用默认逻辑给建议。我开始以为是技能内容写错了，把SKILL.md翻来覆去看了三遍也没发现问题。

后来一步步排查才发现，原来我的~目录在Windows上被解析成了C:\Users\me，而我实际运行Claude Code的目录是另一个用户路径下的符号链接环境，等于把技能装到了AI根本不会去读的位置。换到真正的用户主目录之后，再新开一个会话，技能立刻就触发成功了。

这个坑提醒我：每次装完新Skill或者改动Skill内容之后，必须新开一个会话再测试。很多Agent在已有会话里不会重新扫描技能目录，你跟它说得再多，它也用不上新技能。

5.2 两个技能互相打架：触发词冲突怎么解

第二种常见坑是触发词冲突。比如你装了两个技能，一个负责"代码风格审查"，描述里写了触发词code review；另一个负责"依赖安全检查"，描述里也写了code review。AI读到任务时可能随机加载其中一个，导致输出完全跑偏。我在一个项目里吃过这个亏，查了老半天才意识到是两个技能的description互相覆盖。

解法分两步：第一步，安装之前先用搜索功能查一下现有技能目录里有没有描述词重叠的；第二步，给每个技能写更加唯一的触发词，比如review:style、audit:deps，让触发条件错开。如果你已经装了大量技能，强烈建议做一个自己的技能清单表格，把每个技能的name、description、触发词、路径记下来，别信自己的记忆。

5.3 技能内容过于冗长导致的上下文损耗

第三个问题跟性能有关。前面我提过渐进式披露，但实际情况是，如果你在某一个技能里写了几千行说明、夹带大量模板和示例，那一旦触发，AI需要加载的内容依然会很长。上下文窗口有限，加载一个冗长技能后，留给其他任务的信息就少了，对话体验会明显变钝。

我现在的习惯是：SKILL.md主体控制在100行以内，把可以后置的内容挪到references/子目录，让AI按需读取。比如把详细的代码风格示例放到references/style-examples.md，主文件只写"风格参考见references/style-examples.md"，AI在执行到对应步骤时才去读，这样既保住了方法论，又不会一次性吃掉大量上下文。

5.4 跨工具迁移时的格式兼容问题

最后说一个进阶问题：同一个Skill在不同Agent之间能不能通用？答案是部分能，但要注意格式差异。

比如Claude Code对SKILL.md的front matter（YAML头部）解析比较宽松，而另一个工具可能要求有更严格的author、version字段。还有文件路径上的差异：Claude Code偏好~/.claude/skills，Codex偏好~/.codex/skills，迁移时不只是改个文件夹名，有时还要微调front matter里的字段才能被识别。如果经常在多个工具间切换，我建议维护一个"原始技能源仓库"，每次只从源仓库复制到目标目录，而不是在某个工具目录里改了再反向同步，那样很容易改出只有一份的孤本，到时候重装都找不回来。

6. 从"装技能"到"建技能体系"：我的实战进阶思路

6.1 给技能做分层：基础层、业务层、项目层

用了一个多月Skills之后，我最大的变化是开始给自己的技能库做"分层管理"了。基础层放那些跨项目通用的技能，比如代码审查、测试用例生成、提交信息生成；业务层放跟当前团队技术栈相关的技能，比如React组件规范、Python数据处理流水线；项目层则针对具体项目的特殊约定，比如某个老项目的目录结构、命名习惯、历史包袱注意事项。分层的好处是，项目层的东西不会污染其他项目的Agent行为，基础层又能在任何项目里保持一致的水准。

这种分层模式用文件目录也能粗略实现：基础层技能放在全局目录，业务层和项目层技能放在项目级目录。项目级目录还有一个额外好处：跟随仓库走，新同事clone下来就能用，团队协作的时候天然形成了"技能即文档"的效果。

6.2 定期清理与版本管理

Skills装多了之后，一定不要忘了做"大扫除"。我在实际使用中发现，不少技能包的触发词描述里都带上了claude或codex这类工具名，直接作为前缀。这种命名虽然不会报错，但在混合环境里容易造成触发歧义。另外，有的技能装在全局目录里但其实早已不用，每次Agent启动时都会扫一遍，扫到它还会因为过长的描述多消耗一点上下文。我的清理方法是每两周过一遍技能目录，停用超过一个月的技能要么删除，要么注释掉description里的关键词。

版本管理也值得做。Skill也是代码，我用Git仓库单独维护我的技能配置，每次改动提交后写一句commit信息。等哪次改坏了想回滚，或者换了新电脑要恢复环境，一个git clone加软链就能把整个技能体系重建出来。个人体验是这套方法比下载一堆压缩包靠谱多了。

6.3 Skills与Agentic Coding文化的结合

最后想说的是，Skills流行起来背后不只是技术更新，而是Agentic Coding（智能体编程）文化的逐渐成形。以前大家指望AI能"听懂一句就办好所有事"，但现在很多实践者开始意识到：与其让AI临场发挥，不如给它一套稳定的方法论。Skills本质上就是"驯化AI的方法论"，它不要求AI无所不知，而是把人类专家的流程知识转写成AI能稳定执行的形式。

这个文化范式对开发者的新要求是：不仅要会写代码，还要会"把任务流程结构化"。前端开发skills、数学建模skills、AI漫剧skills，本质上都是同一种能力在不同场景下的衍生。下一个阶段比拼的可能不是谁的AI更强，而是谁能把更高质量的技能体系装进AI。

说句实在的，我自己也还在持续调整技能库。每次写一个新流程，每次在真实任务里发现技能漏掉某个细节，都像是给自己的数字分身添砖加瓦。如果你刚接触Skills，不妨从"你最常让AI做的三件事"开始，把其中一件固化下来，用一周时间迭代它，我相信你会回来感谢这个选择的。