企业官网建设流程全解析

1. 从"skills"这个热词说起：它到底在解决什么问题

最近一段时间，不管是在开发者社区还是各类技术群组里，"skills"这个词出现的频率高得离谱。很多人第一次看到它，会以为是某个新出的编程语言特性，或者某个框架的插件系统。但如果你真的去翻一翻相关的讨论，会发现大家嘴里的"skills"其实指向一个很具体的东西——给AI编程助手（比如Claude Code、Codex这类工具）扩展能力的模块化技能包。

我最初接触这个概念的时候也走了弯路。当时我以为"skills"就是普通的插件，装上去就能用。结果折腾了半天才发现，它的设计思路和传统插件完全不是一回事。传统插件往往是往宿主程序里注入代码、挂钩子、改行为；而skills更像是一份"操作手册"——它告诉AI助手在遇到某类任务时，应该按照什么流程、调用什么工具、遵循什么规范去干活。这个区别非常关键，理解错了后面全是坑。

举个生活化的类比。传统插件像是给你的手机装了一个新硬件模块，直接改变手机的功能；而skills更像是给一个刚入职的助理递了一本《公司业务操作手册》，助理本身没变，但他知道该怎么干活了。AI助手就是那个助理，skills就是那本手册。

那为什么这个东西突然火起来了？我的观察是三个原因叠加。第一，AI编程助手的能力已经足够强，强到人们开始不满足于"它能写代码"，而是希望"它能按我的规矩写代码"。第二，不同团队、不同项目的工作流程差异巨大，靠官方内置的功能根本覆盖不过来，必须有一个让用户自己定义流程的机制。第三，skills的编写门槛比写插件低得多，很多时候就是写一份结构化的说明文档，前端、后端、测试、运维都能上手。

这篇文章我想做的事情很明确：把skills这个东西从概念到落地讲透。包括它和传统插件的本质区别、怎么找到靠谱的skills、怎么自己写一个、在不同工具（Claude Code、Codex等）里怎么配置、以及我在实际使用中踩过的那些坑。不管你是刚听说这个词的新手，还是已经装了几个skills但没搞明白原理的老手，应该都能从里面找到有用的东西。

提示：本文讨论的skills特指AI编程助手的技能扩展机制，和安卓逆向领域里那个同名的"脱壳skills"完全是两码事，搜索的时候注意区分，否则会被带偏。

2. skills和传统插件到底差在哪：一次概念上的彻底厘清

2.1 插件是"改程序"，skills是"教方法"

要理解skills，必须先把它和插件（plugin）分开。这两个词在很多文章里被混用，导致大量误解。

传统插件的本质是代码注入。它通过宿主程序提供的接口，把自己的逻辑挂载进去，直接改变程序的运行行为。比如你给IDE装一个插件，它可能会在编辑器里加一个新面板、在右键菜单里加一个选项、在编译流程里插一个步骤。插件是"活"的，它自己会运行。

skills的本质是知识注入。它不改变AI助手本身的代码，而是往助手的"上下文"里塞进一段结构化的知识，让助手在处理特定任务时参考这段知识。skills本身不会"运行"，它只是被读取、被理解、被执行。真正干活的是AI助手，skills只是给它指路。

这个区别带来一个很实际的后果：插件的bug是程序bug，skills的bug是理解偏差。插件出问题，你去看日志、断点调试；skills出问题，你得去看AI是不是误解了你的意图，或者你的描述本身就有歧义。排查思路完全不同。

2.2 为什么skills这种"软扩展"反而更强

乍一看，skills不能直接改程序，好像比插件弱。但实际用下来，我发现它在很多场景下反而更强，原因有三个。

第一，覆盖面更广。插件只能做宿主程序预留了接口的事情，接口没开放的功能你干不了。而skills理论上可以描述任何流程，只要AI助手有能力执行。比如你想让助手"每次提交代码前先跑一遍lint，再检查commit message格式，最后生成changelog"，这种跨多个工具的流程，插件很难做，但skills写一段说明就行。

第二，维护成本更低。插件要跟着宿主程序的版本走，宿主一升级，插件可能就挂了。skills是纯文本描述，只要AI的理解能力在，它就一直能用。我有个skills从去年写到现在，中间换了三个版本的助手工具，一次都没改过。

第三，可组合性更好。多个插件之间经常打架，因为它们都在改同一个程序。而多个skills可以叠加使用，AI会综合所有skills的指示来干活。你可以有一个"代码规范"skill，一个"测试流程"skill，一个"文档生成"skill，它们互不干扰。

2.3 一个具体的对比场景

假设你要让AI助手帮你写一个React组件。没有skills的时候，你得在每次对话里重复交代："用函数组件不要用类组件""样式用CSS Modules""props要有TypeScript类型""不要用any"。说一次两次还行，说一百次谁都烦。

有了skills之后，你把这些要求写进一个"前端开发规范"skill里，之后每次让助手写组件，它自动就按这个规范来。你不需要重复交代，助手也不会忘记。

再进一步，如果这个skill里还写了"写完组件后自动生成对应的测试文件""测试用React Testing Library""覆盖率要报告出来"，那助手就会连测试一起帮你搞定。这就是skills的威力——它把"你脑子里的隐性规范"变成了"助手能读到的显性知识"。

3. 找skills：官方市场、社区仓库和"野生"来源怎么选

3.1 官方市场是起点，但不是终点

如果你用的是Claude Code这类工具，官方通常会提供一个skills市场（marketplace）。这是最省心的起点，因为里面的skills经过了一定程度的审核，质量相对有保障，安装也最方便。

但官方市场的问题也很明显：数量有限，覆盖场景不全。官方团队精力有限，不可能把每个细分领域都覆盖到。比如你做的是某个垂直行业的业务系统，官方市场里大概率找不到对口的skill。

我的建议是：先用官方市场里的通用skills打底，再根据自己项目的特殊需求去找或写专用skills。通用skills比如"代码审查""提交规范""文档生成"这些，官方市场里通常都有不错的，直接用就行。专用skills就得自己想办法了。

3.2 社区仓库：淘金的地方，也是踩坑的地方

社区仓库（比如各种GitHub上的skills集合）是找skills的主要战场。这里的skills数量多、花样全，但质量参差不齐。我见过写得非常专业的，也见过纯粹是复制粘贴凑数的。

在社区仓库里淘skills，我总结了几条筛选标准：

• 看更新频率。一个半年没更新的skill，大概率已经跟不上工具的演进了。优先选最近一两个月有提交的。
• 看描述是否具体。好的skill描述会明确说清楚"这个skill解决什么问题""适用于什么场景""有什么前置要求"。含糊其辞的通常质量也不行。
• 看有没有示例。带使用示例的skill，说明作者真的用过，不是拍脑袋写的。
• 看issue区。如果issue区里全是"装了没反应""报错"这类问题，而且没人回复，直接跳过。

注意：社区仓库里的skills是纯文本文件，理论上你可以直接读一遍再决定装不装。我强烈建议装之前先读一遍，尤其是那些会执行命令、访问网络的skill，读一遍能避免很多意外。

3.3 "野生"来源：能用但要格外小心

除了官方市场和社区仓库，还有一些"野生"来源，比如别人在博客里贴出来的skill片段、群里分享的文件、某个教程里附带的配置。这些来源的skills不是不能用，但风险更高。

主要风险有两个。一是内容可能过时，教程写的时候能用，现在可能已经失效了。二是可能夹带私货，比如某个skill里偷偷让你把代码上传到某个不明服务器。虽然这种情况少见，但防人之心不可无。

我的做法是：野生来源的skills，一律先在一个隔离环境里试，确认行为符合预期再放到正式环境。尤其是涉及网络请求、文件操作的skill，必须看清楚它到底在干什么。

3.4 找不到合适的怎么办：自己写

说实话，用久了你会发现，最合适的skills往往是自己写的。因为只有你自己最清楚你的工作流程、你的规范、你的偏好。别人的skill再通用，也总有一些地方和你的习惯对不上。

自己写skill的门槛比想象中低。下一节我会详细讲怎么写。这里先给个心理预期：一个能用的skill，核心内容可能就几百字，写起来比写一篇技术文档还快。

4. 手写一个skill：从结构到落地的完整过程

4.1 skill的基本结构长什么样

一个skill通常包含几个部分：名称、描述、适用场景、具体指令。不同工具的格式略有差异，但核心要素是相通的。

名称要短、要能一眼看出用途，比如"react-component-standard"就比"my-skill-1"强得多。描述要一句话说清楚这个skill干什么，因为AI在决定是否使用某个skill时，会先看描述。适用场景要写明白什么时候该用、什么时候不该用，避免AI在不该用的时候乱用。具体指令是核心，要写清楚步骤、规范、注意事项。

我见过很多人写skill，把具体指令写得特别笼统，比如"写高质量的代码"。这种描述等于没说，因为"高质量"是个主观词，AI没法执行。好的指令应该是可操作的，比如"所有函数必须有JSDoc注释，注释要包含参数类型和返回值说明"。

4.2 指令部分怎么写才有效

写指令部分，我总结了几个原则。

第一，用祈使句，不用陈述句。"检查代码风格"比"代码风格应该被检查"好，因为前者是明确的动作指令。

第二，步骤要编号。AI处理有序列表比处理大段文字更可靠。如果你的skill涉及多步流程，一定要用1、2、3列出来。

第三，给出判断标准。不要只说"做X"，要说"做X，如果遇到Y情况则做Z"。AI需要知道边界条件。

第四，提供示例。一个正例加一个反例，比十句抽象描述都管用。AI能从示例里学到很多隐含的规则。

第五，控制长度。skill不是越长越好。太长的skill会占用大量上下文，反而影响AI的表现。我的经验是，单个skill的核心指令控制在500到1500字之间比较合适，超过2000字就该考虑拆分了。

4.3 一个完整的skill示例

下面是我自己写的一个"提交信息规范"skill的简化版，可以感受一下结构：

# commit-message-standard ## 描述 规范Git提交信息的格式，确保提交历史清晰可读。 ## 适用场景 当用户要求提交代码、生成提交信息、或整理提交历史时使用。 ## 指令 1. 提交信息第一行必须是类型前缀，格式为 `type: 简短描述`。 2. 类型只能是以下之一：feat、fix、docs、style、refactor、test、chore。 3. 简短描述不超过50个字符，用中文，结尾不加句号。 4. 如果改动涉及多个方面，在空行后补充详细说明，每行不超过72字符。 5. 如果关联了issue，在最后一行写 `Refs: #issue编号`。 ## 示例 正例： feat: 增加用户登录接口 实现了基于token的登录验证，包含过期刷新逻辑。 Refs: #123 反例： 更新了一下代码 （问题：没有类型前缀，描述过于笼统）

这个skill不长，但信息密度很高。AI读了之后，基本能稳定地按这个规范生成提交信息。

4.4 写完之后的测试方法

skill写完不是就完事了，必须测试。测试的方法很简单：构造几个典型场景，看AI的表现是否符合预期。

比如上面那个提交信息skill，我会故意让它处理几种情况：只改了一个文件的简单提交、改了多个模块的复杂提交、关联了issue的提交。看它是不是每种情况都按规范来。如果某一种情况表现不对，说明skill里对应的描述有歧义，回去改。

测试的时候要注意，不要只测一次就下结论。AI的输出有随机性，同一个skill跑三次可能有一次不对。多测几次，如果错误率超过两成，说明skill需要优化。

5. 在Claude Code和Codex里配置skills的实操细节

5.1 Claude Code的skills安装路径与配置

Claude Code的skills通常放在一个特定的目录下，具体路径因操作系统而异。在Windows上一般是用户目录下的某个隐藏文件夹，在macOS和Linux上则是家目录下的配置目录。安装方式有两种：一种是通过命令行工具从市场直接安装，另一种是手动把skill文件放到对应目录。

手动安装的时候有个坑要注意：目录结构必须符合规范。很多skill要求放在特定的子目录里，比如按类别分文件夹。如果你直接把文件扔在根目录，工具可能识别不到。我第一次装的时候就因为这个折腾了半小时，后来看了文档才发现要放到指定子目录。

配置完成后，通常需要重启工具或者重新加载配置才能生效。有些版本支持热加载，改完skill文件直接生效，但保险起见还是重启一下。

5.2 Codex的skills接入方式

Codex的skills机制和Claude Code略有不同。Codex更强调skills和具体任务的绑定，也就是说，你可以在发起一个任务的时候指定使用哪些skills，而不是全局生效。

这种方式的好处是更灵活，不同的任务可以用不同的skills组合。坏处是每次都要指定，如果忘了指定，skill就不生效。我的做法是把常用的skills组合保存成预设，每次直接调用预设，省得一个个选。

Codex还有一个特点是它对skills的解析更严格。如果skill的格式不规范，Codex可能会直接忽略它，而不是像有些工具那样"尽力理解"。所以给Codex写skill，格式一定要严格按规范来。

5.3 跨工具使用skills的兼容性问题

很多人会同时用多个AI编程助手，希望一套skills能通用。现实是，完全通用很难，但大部分可以复用。

不同工具对skill的格式要求有差异，比如有的要求用YAML头，有的要求用Markdown标题，有的对字段名有特定要求。如果你想让一个skill在多个工具里都能用，最稳妥的做法是写一个核心内容，然后针对每个工具做一层格式适配。

我的做法是维护一个"skill源文件"，里面是纯内容，不带任何工具特定的格式。然后用脚本把它转换成各个工具需要的格式。这样改一次内容，所有工具都能同步更新。

5.4 配置过程中最常见的三个报错

第一个报错是"skill not found"。这通常是路径问题，要么文件放错地方了，要么目录名拼错了。检查的时候注意大小写，很多系统是区分大小写的。

第二个报错是"invalid skill format"。这是格式问题，通常是缺少必填字段，或者字段名写错了。对照官方文档的格式要求逐项检查。

第三个报错是"skill conflict"。这是多个skill之间有冲突，比如两个skill都试图定义同一个流程。解决办法是检查一下有没有功能重叠的skill，把重复的删掉或者合并。

6. 那些没人告诉你的skills使用心得

6.1 skill不是越多越好

刚开始用skills的时候，我有个误区：觉得装得越多越好，恨不得把能找到的skill全装上。结果发现，装太多反而变差。

原因是每个skill都会占用AI的上下文空间。装了几十个skill之后，AI的"注意力"被分散了，处理具体任务时反而容易忽略关键指令。而且skill之间可能互相干扰，一个说"用A方案"，另一个说"用B方案"，AI就懵了。

我现在的做法是按项目装skill。每个项目只装这个项目真正需要的skill，通常不超过十个。项目之间互不干扰，每个项目里的AI都能保持专注。

6.2 定期清理和更新skill

skills不是装完就不管了。随着项目演进，有些skill会过时，有些会变得不必要。我养成了一个习惯：每个月花半小时过一遍手上的skills，把不再用的删掉，把需要改的更新一下。

清理的时候问自己三个问题：这个skill最近一个月用过吗？它的内容还准确吗？有没有更好的替代品？三个问题里有两个答案是"否"，就考虑删掉。

6.3 用skill解决"重复交代"的痛点

skills最大的价值，在我看来是消灭重复交代。你有没有过这种经历：每次让AI干活，都要先花一大段话交代背景、规范、偏好，交代完了才进入正题。这些交代的内容，其实大部分是固定的，完全可以写成skill。

我统计过，用skill之前，我平均每次对话要花三成的时间在"交代背景"上。用了skill之后，这部分时间基本省了，直接说需求就行。一天下来能省不少时间，更重要的是省心——不用每次都想着"我有没有漏交代什么"。

6.4 团队协作中的skill管理

如果是团队一起用AI助手，skills的管理就更重要了。我的建议是把skills纳入版本控制，和代码一起管理。这样每个人用的都是同一套skill，输出风格才能统一。

具体做法是在项目仓库里建一个skills目录，把项目相关的skill都放进去。新人入职的时候，拉下代码就自动有了全套skill，不用一个个手动装。skill的修改也走正常的代码审查流程，避免有人偷偷改了skill导致大家行为不一致。

提示：团队共享的skill里不要放个人偏好，比如"我喜欢用两个空格缩进"这种。个人偏好应该放在个人的全局skill里，项目skill只放团队共识的部分。

6.5 一个反直觉的发现：skill写得好，AI表现能提升一大截

最后分享一个我自己的观察。很多人抱怨AI助手"不够聪明""老是理解错"，但问题往往不在AI，而在你没把要求说清楚。

我做过一个对比实验：同一个任务，一次只给AI一句简单的需求，另一次给AI配一个详细的skill。结果后者的输出质量明显更高，而且稳定性好得多。这说明什么？说明AI的能力上限其实很高，只是需要你把它"引导"到正确的方向上。skill就是这个引导工具。

所以我的结论是：与其抱怨AI不行，不如花点时间把skill写好。这个投入的回报率非常高，写一次能用很久，而且越用越顺手。

7. 从"用skill"到"造skill"：进阶玩法

7.1 把个人经验沉淀成skill

用了一段时间别人的skill之后，你会慢慢发现自己的独特需求。这时候就该考虑自己造skill了。

造skill的素材来源很广：你平时反复交代的那些话、你总结的检查清单、你踩过的坑、你团队的规范。把这些东西整理成结构化的文档，就是一个skill。

我有个习惯，每次发现自己"又在重复交代同一件事"的时候，就记一笔。攒够几条之后，把它们整理成一个skill。这样日积月累，我的skill库越来越丰富，干活也越来越省事。

7.2 skill的组合与嵌套

单个skill的能力有限，但多个skill组合起来能实现很复杂的功能。比如你可以有一个"代码生成"skill、一个"代码审查"skill、一个"测试生成"skill，让它们串起来工作：先生成代码，再审查，再生成测试。

组合的时候要注意顺序和依赖。有些skill必须在另一些之后执行，比如"测试生成"必须在"代码生成"之后。这个顺序要在调用的时候明确指定，不能指望AI自己理清。

7.3 用skill实现"工作流自动化"

skills的终极玩法，是把整个工作流都skill化。从需求分析到代码生成，从测试到部署，每一步都有对应的skill。你只需要在起点说一句"帮我实现这个需求"，后面的流程AI会自动按skill走完。

当然，这需要相当多的前期投入，要把每个环节都写清楚。但一旦搭起来，效率提升是巨大的。我现在做常规的功能开发，基本就是一句话启动，中间不用怎么干预。

7.4 给skill写文档和版本号

当你的skill库大到一定程度，就需要给每个skill写文档、标版本号了。文档说明这个skill干什么、怎么用、有什么限制；版本号让你能追踪skill的演进，出问题的时候能回滚到旧版本。

这一步很多人会忽略，觉得skill就是个小文件，不用那么正式。但我的经验是，skill库越大，文档和版本管理越重要。否则过几个月你自己都忘了某个skill是干什么的。

8. 关于skills，我踩过的那些坑

8.1 坑一：skill描述太笼统导致AI乱用

我写过一个"代码优化"skill，描述写的是"优化代码质量"。结果AI变得特别激进，动不动就重构我的代码，把能跑的代码改得面目全非。后来我把描述改成"在保持功能不变的前提下，优化代码的可读性和性能，不做大规模重构"，问题才解决。

这个坑的教训是：描述里的每个词AI都会当真。"优化"这个词太宽泛，AI的理解可能和你完全不同。描述要具体到"优化什么""优化到什么程度""不做什么"。

8.2 坑二：skill之间指令冲突

有一次我同时装了两个skill，一个说"注释要详细"，一个说"注释要简洁"。结果AI在写注释的时候左右为难，输出质量很不稳定。后来我把两个skill合并成一个，明确说"公共API要详细注释，内部实现简洁注释"，冲突才消除。

这个坑的教训是：装skill之前要检查有没有功能重叠。重叠的skill要么合并，要么只留一个。

8.3 坑三：skill里的示例过时了

我有个skill里带了一个代码示例，用的是某个库的旧版本API。后来那个库升级了，API变了，但skill没更新。结果AI照着旧示例写代码，跑起来全是报错。我排查了半天才发现是skill的锅。

这个坑的教训是：skill里的示例要定期检查。尤其是涉及第三方库的示例，库一升级就要跟着更新。

8.4 坑四：把skill当成了万能药

有段时间我特别迷信skill，什么问题都想用skill解决。结果写了一大堆skill，维护成本高得吓人，而且很多skill根本用不上。后来我想明白了：skill只适合解决"重复性"和"规范性"的问题。一次性的、探索性的任务，用skill反而累赘。

这个坑的教训是：不是所有事情都值得写成skill。判断标准很简单：这件事你会重复做吗？会重复做，就值得写skill；只做一次，就别费那个劲了。

8.5 坑五：忽略了skill的加载顺序

有些工具里，skill的加载顺序会影响最终效果。如果两个skill有依赖关系，加载顺序错了就会出问题。我曾经因为加载顺序不对，导致一个skill的配置被另一个覆盖了，排查了很久。

这个坑的教训是：了解你所用工具的skill加载机制。如果支持指定顺序，就把有依赖关系的skill按正确顺序排列。

9. 写在最后：一些零散但实用的建议

关于skills这个话题，能聊的还有很多。最后再分享几个零散但我觉得挺有用的点。

第一，从模仿开始。如果你不知道怎么写skill，先找几个别人写的好skill，照着结构模仿。写多了自然就有感觉了。

第二，保持skill的单一职责。一个skill只干一件事，干好。不要试图写一个"什么都能干"的超级skill，那种skill往往什么都干不好。

第三，给skill起好名字。名字是AI判断是否使用某个skill的第一依据。名字起得清楚，AI用对的概率就高。

第四，定期回顾skill的效果。skill不是写完就完了，要观察它实际用起来效果怎么样。效果不好的，要么改，要么删。

第五，别怕删skill。很多人舍不得删自己写的skill，觉得写了半天删了可惜。但一个没用的skill留着只会添乱。该删就删，需要的时候再写就是了。

skills这个东西，说到底是一种"把经验固化下来"的手段。你踩过的坑、总结的规范、形成的习惯，都可以通过skill变成AI能理解的知识。用得好的话，它能让你的AI助手真正变成"懂你"的助手，而不是一个每次都要从头交代的陌生人。这个价值，值得花点时间去琢磨。