企业官网建设流程全解析

聊到VS Code最近的“Skills热”，估计不少人都刷到过这词。以前我们见面问的是“你装了啥插件”，现在AI编程助手们一水儿地推“技能”——Claude Code有Skills，Codex有Skills，连通义灵码这类助手也在跟进。简单说，Skills就是一份给AI的“操作手册+工具箱”，把你常用的工作流、代码规范、项目结构打包成文件，AI干活前先读一遍，然后照章执行。这东西到底怎么用、怎么装、怎么写，网上的教程东一榔头西一棒子，我这篇直接给你捋清楚。

这篇文章适合两类人：一类是在VS Code里用AI写代码、想提效的朋友，不管前端后端都能用上；另一类是已经被“技能装了不生效”“远程连不上”“终端版本对不上”折磨过的人。我会从Skills的运行原理讲起，手把手演示接入Claude Code、Codex、通义灵码，再给一份可以直接抄的常用技能清单，最后把我在实际使用里踩过的坑全抖出来。

1. 先搞清楚：Skills到底是个什么东西

1.1 从“插件”到“技能”：AI编程助手的进化

VS Code插件生态大家都熟，装个ESLint、装个Prettier，编辑器就多了一堆能力。但Skills不一样，它服务的是AI助手，不是编辑器本身。你装一个“前端代码审查Skills”，等于告诉Claude Code或Codex：以后你帮我审查代码的时候，先按这个流程走，先看这几个文件，再按这份规范输出问题清单。

我用一个生活类比帮你理解。Skills就像新人入职时拿到的那本《岗位操作手册》：老板不用反复叮嘱“你先干嘛再干嘛”，手册里写着“第一步做什么、第二步做什么、遇到什么情况找谁”。AI读完手册，行为立刻从“泛泛聊天”变成“按流程干活”。

从技术实现上说，Skills通常是一组带固定格式的Markdown文件外加可执行脚本。Markdown用来描述任务流程、输出规范、参考资料；脚本则负责跑测试、查日志、生成代码。AI助手通过配置文件知道在什么场景下调用哪个技能，然后照着SKILL.md里的步骤执行。

1.2 Skills的运行逻辑：为什么它比聊天提示词好用

很多人一开始会说：“我直接在对话框里写一段详细指令不就行了？”行是行，但有两个硬伤。第一，同样的指令你每次都得重新打一遍，打字慢不说，每次表述还可能有细微差异，AI输出质量跟着波动。第二，指令一长，AI容易“记不住”，尤其是超出上下文窗口之后，前面的规范被冲掉，后面就开始自由发挥。

Skills把这个问题解决了：指令固化在文件里，AI每次在任务开始前主动读取。等于把“临时口头交代”变成了“正式书面SOP”。我实测下来，同一类任务用Skills和不用Skills，稳定性能差出一个档次——尤其是代码风格统一、提交信息规范、单元测试生成这类重复性高的场景，效果特别明显。

以Claude Code为例，项目里放一个.skills目录，每个技能一个子目录，目录里有SKILL.md。AI在执行任务时发现目录下有技能，会根据任务描述自动匹配，先读SKILL.md再开干。Codex那边有类似机制，它把技能放到项目或者全局配置里，用特定的目录约定来识别。通义灵码也在往这个方向走，只是它的技能形态更接近“自定义指令”。

1.3 VS Code生态里的Skills形态

在VS Code里，Skills的载体比较多样。可能是某个扩展带来的，比如装了Claude Code扩展，它自动识别项目里的.skills目录；也可能是独立的管理工具，比如Superpowers，它本质上是一个技能集合管理方案，专门用来聚合第三方技能；还有的是通过命令行工具加载，比如CC Switch这类模型切换器，顺带把技能也管了。

所以热词里出现的“superpower skills”“nature skills”“cola skills”，本质都是同一件事——把一组干活的流程和工具打包成技能。区别只在于分发渠道和格式规范不同。有些作者把技能发在官方市场，有些发在GitHub仓库，有些直接集成在自己的AI工具里。如果你用的是JetBrains家的IDEA，这个概念同样适用，只是目录约定和插件机制会不太一样。

需要提醒一句：不是所有带“skills”字眼的东西都通用。Anthropic的Claude Skills、OpenAI的Codex Skills，以及社区自发形成的SKILL.md规范，目前还没有一个统一标准。你在网上看到一份技能包，先确认它适配哪个助手，装错地方是不会生效的。

2. 在VS Code里跑起来：主流AI编程助手接入实战

2.1 Claude Code for VS Code安装与激活

Claude Code官方提供了VS Code扩展，装上之后不用单独开终端。操作流程很简单：打开VS Code，进扩展市场搜“Claude Code”，认准Anthropic官方发布的那个，点安装。装完左侧边栏会多出一个Claude Code图标，点开后第一次使用需要登录授权，输入API Key或者用账号登录，照着官方引导走就行。

装好之后有个细节：Claude Code在VS Code里默认会读取当前项目目录，如果项目里有.skills目录，启动时会自动加载技能列表。你可以在聊天面板里输入/skills查看当前项目可用的技能，输入技能名直接触发。

我建议第一次用的朋友先建个测试项目，放一两个简单技能进去，验证加载机制是否正常。很多人装上后一脸懵——怎么聊天不生效？多数是技能目录路径不对，或者SKILL.md格式不规范。这个我在后面“自己写Skills”部分细讲。

2.2 Codex接入与Skills加载

OpenAI Codex也有VS Code扩展，安装方式类似，扩展市场搜“Codex”，装完登录账号即可。Codex的Skills机制跟Claude Code略有不同，它更强调“技能包”（skill pack）的概念，一个技能包可以包含多个相关技能，放在指定目录下。

加载Skills时，Codex会在工作区里查找约定位置的技能文件，然后在对话中通过命令列出。代码补全和行内操作是Codex的强项，所以它的技能设计里，很大一部分是“代码生成模板”和“重构检查清单”这类跟编辑器深度绑定的东西。

这里我想多说一句：如果你是团队内部使用，建议在代码仓库里统一维护一份技能包，新同事拉下来就能直接用，比每个人自己从网上东找一份西找一份靠谱得多。这跟维护一份.editorconfig或者tsconfig.json是一个思路，都是把约定沉淀到仓库里。

2.3 用CC Switch接入DeepSeek、通义千问、GLM等模型

热词里出现“cc switch”，估计不少人是冲着“一个工具切换多家模型”来的。这工具的本职工作就是把各家模型端点统一管理起来，切换模型时改一下配置就行，不用反复改API Key和Base URL。

具体到在VS Code里用Claude Code接入DeepSeek、通义千问（Qwen）、GLM这类模型，思路是：这些模型厂商提供了兼容API，配置的时候，把请求的Base URL指向对应厂商的接口地址，把Model名改成对应型号，再把API Key填进去。CC Switch这类工具就是帮你把这些配置集中管理，切换时一键生效。

我说一下接入DeepSeek的要点。在CC Switch里新建一个Provider，填上厂商给的Base URL和API Key，模型名选deepseek-chat或者deepseek-coder（具体型号看官方文档），保存后切到这个配置。回到VS Code的Claude Code扩展，它读到的就是CC Switch当前激活的配置。实测下来，普通代码生成、解释报错、写单元测试这些任务，DeepSeek这类模型完全够用，成本比Claude官方API低不少。

但要注意版本差异。CC Switch不同版本界面差异挺大，老版本只支持切换Anthropic和OpenAI这两家的模型端点，新版本才逐步加入对国产模型兼容接口的完整支持。配置前先看一眼官方README，确认你用的版本支持目标模型。另外，切换模型之后建议重启一下VS Code窗口，有些扩展对API配置的读取是启动时缓存的，不重启还会继续请求旧模型。

2.4 通义灵码：国产助手里的Skills玩法

通义灵码是阿里云出的AI编程助手，VS Code扩展市场直接搜“通义灵码”就能装。它的侧重点跟Claude Code不太一样——更贴近国内开发者的习惯，代码补全、注释生成、单元测试、代码解释都有现成功能，上手门槛很低。

通义灵码里也引入了技能相关的能力，但它更像“官方内置技能+自建自定义指令”的组合。你可以把自己团队常用的一套规范写成自定义指令，相当于轻量级Skills。比如团队要求所有提交的代码必须带错误处理，你就可以把错误处理规范写成指令，让AI生成代码时自动遵守。

对于用STM32这类嵌入式开发的朋友，通义灵码配合VS Code的嵌入式扩展（比如C/C++、Cortex-Debug、PlatformIO）体验还不错。它能理解项目里的寄存器配置和中断逻辑，生成初始化代码的准确率还行。不过它对自己的SDK和硬件库更熟，第三方库的细节别指望它完全准确，这点要有预期。

3. Skills从哪来：获取渠道、安装方法和常用推荐

3.1 官方市场与社区平台怎么选

现在获取Skills的渠道大致分三类。

第一类是AI工具自带的官方市场。比如Claude Code官方文档里列出了经过验证的技能，Codex也有自己的技能集合。官方市场的好处是质量有保障，跟工具的版本兼容性最好；缺点是数量少，很多场景官方还没来得及覆盖。

第二类是GitHub和Gitee上的开源仓库。GitHub上搜“skills for claude”或者“codex skills”，能找到大量社区项目。这类渠道数量大、更新快，但质量参差不齐——有些仓库就是一个Markdown文件集合，两三分钟就能看完；也有一些做得很系统，把几百个技能分类整理好，带说明文档和安装脚本。我一般优先看star数、最近更新时间、以及有没有人提issue反馈问题。

第三类是各种“技能导航站”和公众号资源包。这类渠道我建议谨慎，尤其是那些号称“全网最强”“一键安装几百个技能”的资源包。原因是技能这东西本质是文本和脚本，普通人很难一眼判断里面有没有夹带私货——比如某个技能脚本里藏着偷偷上传代码的指令。我拿到任何技能的第一件事就是打开文件看一眼，确认没有可疑内容，再决定要不要装。

3.2 Skills安装包的目录结构和部署方法

不管从哪个渠道拿到技能包，部署方式大同小异。我以最常见的SKILL.md格式为例。

一个标准的技能包长这样：

my-skill/ ├── SKILL.md # 技能主文件，AI主要读这个 ├── scripts/ # 辅助脚本，可选的 ├── references/ # 参考资料，可选的 └── assets/ # 图片资源等，可选的

SKILL.md是核心，它决定了AI怎么使用这个技能。文件开头一般有frontmatter，类似下面这种：

--- name: my-skill description: 这个技能用来干什么，AI靠这段description做自动匹配 ---

然后正文用清晰的分节描述工作流程：何时使用、前置条件、操作步骤、输出格式、注意事项。写得好的SKILL.md会让AI像照着菜谱做菜一样，每一步都有明确依据。

部署位置取决于你用的助手。Claude Code默认查找项目里的.skills目录，也支持全局技能目录（在用户配置目录下）。Codex类似，但它对技能包的目录组织有更细的要求，具体以官方文档为准。

把技能包拷进对应目录就算装好了，不需要编译，不需要改配置，重新开个对话就能生效。这里有个常见误解：很多人以为装技能要“运行安装脚本”或者“激活”，其实大部分情况下就是把文件放到正确的位置。所谓“安装”，本质上就是一次文件复制。

3.3 我的常用Skills清单（可直接抄作业）

分享一套我现在工作流里实际在用的技能清单，覆盖前后端开发场景，你可以根据自己的情况增删：

这些技能不是装得越多越好。我见过有人一口气装了两百多个技能，结果AI每次匹配都要在几百个Description里检索，不仅响应变慢，还经常匹配错。我的建议是控制在二十个以内，聚焦自己真正高频的场景。

安装这类技能时我还会顺手做一件事：改描述。原作者的description写得泛，比如“对代码进行审查”，太宽泛会导致AI在无关任务里也触发它。我会改成“当用户请求审查前端组件代码或提交合并请求时使用”，让匹配更精准。这个改动只要花一分钟，但能明显提升触发准确率。

4. 自己动手写一个Skills：完整实操过程

4.1 Skills文件长什么样

为了让大家彻底搞懂，我直接演示一个完整例子。假设我们要写一个“Python代码风格规范”技能，让AI生成或者审查Python代码时，按我们团队规范来。

先建目录结构：

.skills/python-style/ ├── SKILL.md ├── scripts/check_style.py └── references/style_rules.md

SKILL.md内容大概是这样：

--- name: python-style description: 当需要生成或审查Python代码时使用。重点检查命名、导入、类型标注和文档字符串。 --- # Python 代码风格规范 ## 使用条件 - 用户要求生成新的Python模块 - 用户要求审查已有Python代码 ## 操作步骤 1. 读取 references/style_rules.md 获取团队规范 2. 按规范生成或检查代码 3. 输出检查结果，按严重程度分类 ## 输出格式 每条问题一行：文件:行号 | 级别 | 问题描述 | 修改建议

references/style_rules.md存放具体的规范细节：变量命名用snake_case、函数和类要写docstring、导入语句按标准库/第三方/本地分组……这些内容AI不一定默认知道，写进references里，它每次都能读到，不需要你在对话里反复解释。

4.2 一个“整理代码规范”Skills的编写全过程

写的时候有几个关键点。第一，description要精确，因为AI靠它判断何时加载技能。第二，步骤要可执行，别写“认真检查代码”这种空话，要写“逐行检查函数是否超过50行，超过则标记”。第三，输出格式要固定，AI生成的结果你才能后续用脚本处理。

我把这个技能装进Claude Code里测试。在项目下建好.skills目录，重启对话，输入“帮我写一个读取用户配置的Python模块”。AI先读取技能描述，匹配到python-style技能，然后执行：读style_rules.md、生成代码、最后按设定格式输出检查项。整个过程不用我额外说一句“注意代码风格”，它自己就按规范来了。

这里补充一个写SKILL.md的细节：AI对“步骤编号”非常敏感，写“1. 2. 3.”比写“首先、其次、最后”更容易被执行。另外，在步骤里直接引用参考资料路径，比把内容复制粘贴进SKILL.md更省token，以后修改规范时也只改一个文件。这两个小习惯，能让你的技能维护成本低一个量级。

4.3 调试Skills的常见方式

自己写的技能第一次不生效是常态，别慌。我按经验排一个排查顺序。

先看路径：确认目录名和SKILL.md文件名大小写。Linux和macOS下路径区分大小写，mkdir Skills和mkdir skills是两个不同的目录。Windows下虽然不区分，但你把项目提交到Git仓库再到Linux服务器上跑，照样会出问题。

再看frontmatter：name和description字段格式错误会导致解析失败，比如少了冒号、引号没闭合。我遇到最多的是YAML解析器对特殊字符敏感，description里别用英文冒号加空格，容易截断。

最后看匹配：如果技能没被自动触发，大概率是description写得太具体或太模糊。太具体，任务描述跟它对不上；太模糊，其他技能更容易被匹配。调整方式是在描述里列出几个典型触发场景，用“或”连接。调试的时候，可以在对话里直接问AI“你加载了哪些技能”，让它把加载列表打出来，一眼就能看出匹配是否正常。

5. 踩坑实录：远程连接、编译烧录、终端不一致

5.1 远程开发连不上：Failed to fetch VS Code Server

这是远程开发最经典的问题。VS Code连接远程主机时，会先在远端下载安装一个VS Code Server组件。报错“无法与10.10.8.149建立连接:未能下载vs code服务器(failed to fetch)”，本质就是远端的下载请求失败了。原因基本是这几类：一是远端网络策略限制了访问官方下载地址；二是DNS解析异常；三是服务器磁盘空间不足。

排查思路：先在远端终端手动执行下载命令测试，看是不是真的下载失败。如果确实是下载问题，最省事的方法是手动部署。去VS Code官网下载对应版本、对应平台的Server压缩包，通过scp或ftp传到远端，解压到指定目录，再把下载脚本改成本地路径执行。具体版本号和目录结构，在VS Code官方仓库的vscode-server文档里有详细说明。

另一个常见场景是“设置SSH主机192.168.245.128：正在使用scp将vs code服务器复制到主机”卡了很久。SCP传输慢时先别急着杀进程，看下是不是网络本身慢，还是主机磁盘IO忙。如果是内网千兆环境还慢，检查是不是压缩没开，或者SSH密钥认证导致多次重试。传输完成后记得确认远端的~/.vscode-server目录权限，权限不对会启动失败。VS Code官方支持Windows、macOS、Linux（包括Ubuntu）三种平台，远程开发时的Server版本必须和本地客户端版本对应，版本不匹配也会报奇怪的错。

5.2 解释器与终端版本不一致

这个问题在Python开发里特别常见：VS Code右下角选了解释器3.10，结果在终端里跑python --version显示3.8，AI生成代码或者调试时行为就不对。

原因通常是你设置了解释器路径，但默认终端激活的虚拟环境是另一个。解决办法是在.vscode/settings.json里显式指定Python路径，并确认Terminal的默认profile和你用的环境一致。如果用了conda，终端里还容易被base环境干扰。更彻底的做法是：在Settings里设置开机不进conda base，然后每个项目用单独的虚拟环境，AI通过解释器路径读取，就不会串。

这里有个容易忽略的点：你改了解释器之后，终端里的Python不一定跟着变，因为终端有自己的一套环境激活逻辑。改完配置记得重启终端会话，让PATH重新加载。我见过不少人在这里折腾一下午，其实就是没重启终端。

5.3 C/C++编译成功但烧录不进开发板

嵌入式开发的朋友经常遇到“编译过了，烧录失败”。VS Code里配好C/C++扩展，代码能编出hex文件，但点击烧录没反应。这里要区分两件事：VS Code只负责编译，烧录是下载器（比如ST-Link、J-Link或串口ISP）的活。

先检查烧录器驱动：Windows下ST-Link驱动没装好，设备管理器里设备显示感叹号，烧录工具自然找不到设备。再看烧录软件配置：用的烧录工具是OpenOCD还是厂商自己的工具，目标芯片型号、接口速度、连接方式（SWD还是JTAG）都要跟电路板对上。最后看硬件：很多开发板烧录前要按住BOOT按键，或者拨码开关切到下载模式，这个最容易被忽略。

我给个排查顺序：设备管理器看驱动 → 烧录工具自检看能否枚举到芯片ID → 检查接线（SWD四根线：SWDIO、SWCLK、GND、3.3V）→ 确认芯片供电 → 看烧录日志具体报错。大多数折腾半天的烧录问题，最后都出在驱动或接线，而不是VS Code配置。

5.4 Java的System.out.println没有输出

VS Code里开发Java，运行main方法后控制台什么都看不到，这是个老问题。原因是VS Code的Java插件运行程序时，默认输出走到了调试控制台（Debug Console），而不是终端面板。你如果只盯着“终端”标签看，当然看不到print的结果。

解决方法是：第一次运行选择“Run Java”而不是直接点调试，或者在launch.json里把console配置改成internalConsole或externalTerminal。如果你用Code Runner插件，它的输出是在“输出”面板的“Code Runner”通道里，也不是终端。理解了输出去向，问题就清楚了。顺手再提醒：System.out.println如果是在非主线程频繁输出，控制台刷新可能滞后，加个flush或者用日志框架更稳。

5.5 其他小坑：版本、配置、缓存

VS Code每个月都更新，版本差异也会带来配置不兼容。很多人问“VS Code有Ubuntu版本么”——有，而且是官方一等的支持平台，不是二等公民。但正因为跨平台场景多，版本差异导致的配置问题也更多。升级后如果发现AI助手或者Skills不生效，先看扩展的更新日志，有些扩展对大版本升级没跟上，需要等一两天修复。

改完配置不生效时，记住两条命令：Developer: Reload Window（重载窗口）和Developer: Clear Editor History（清缓存），能解决一大半的“为什么没变化”。这类问题十有八九是编辑器的状态缓存没刷新，跟配置本身没关系。

6. 我的几点实操体会

最后分享几句实在话。Skills这个东西，刚接触时容易被各种“技能包”迷了眼，觉得装得越多越厉害。我实际用了大半年，最大的体会是“少而精”比“多而杂”有用得多。把三五个最常用的技能打磨好，配合适合你项目场景的模型，效率提升是实实在在的；盲目堆技能，反而让AI在选择时无所适从。

另一个体会是：任何AI技能都替代不了你对项目的理解。Skills能把流程固定下来，但流程本身设计得好不好，还得靠人。我写SKILL.md的时候，本质上是在把团队里那些“默认大家都知道”的规矩显性化——这个过程本身，比装技能更有价值。

如果你刚开始折腾，我建议从git-commit和code-review这两个技能入手，见效快、风险低，用顺手了再往测试生成、重构辅助这些方向扩展。等你有了一批自己的技能，再去看那些“技能导航站”，眼光会完全不一样——能一眼看出哪些是凑数的，哪些是真正解决问题的。