企业官网建设流程全解析

最近身边好几个搞前端的朋友都在折腾“skills”，打开GitHub一搜，跟AI辅助开发相关的skills仓库已经多到看不完。Claude Code、Codex、OpenCode这些主流AI编程助手，也都在往同一套叫“skills”的能力体系上靠。很多人第一反应是：这不就是插件吗？我的看法是，它比插件更轻，但比提示词更重，本质上是给AI编程助手配一套标准化的“作业指导书”。

这篇文章想聊透一件事：AI skills到底是什么、怎么从GitHub手动装、怎么写一个自己用的、哪些场景真正值得配，以及技能包攒多了之后怎么收拾。适合正在用Claude Code或Codex写代码、参加数模竞赛、做AI内容生产的人，也适合纯粹想搞懂这套新玩意的技术爱好者。

1. Skills不是插件，是给AI的生产力SOP

先说概念。Claude Code、Codex这波工具里说的skills，指的不是模型参数，也不是什么可执行插件，而是一个有固定格式的能力包：以目录为单位，里面放一个核心说明文件和配套的资源文件，比如模板、脚本、示例。这个目录被放到指定路径后，模型在对话过程中会根据任务内容自行判断“该不该读这份说明”，读了就按说明里的流程干活。

听起来是不是很像SOP（标准作业程序）？我一直觉得这个类比最贴切。插件是给软件装外挂模块，而skills是给一个“每次对话都像刚睡醒的重度失忆员工”准备的操作手册。AI模型本身很强，但它不会记得你上周跟它说过的偏好，也不会自动掌握一套复杂任务的固定动作。Skills的作用，就是把那些“你希望它每次都能稳定做对”的事情，写成一套它随时能翻到的作业指导书。

它和普通提示词的区别在于调用逻辑。你把一套复杂规则贴在每次对话里，既占上下文窗口，模型也未必抓得住重点；而skills文件放在一边，只在任务匹配时被模型主动读取。换句话说，普通提示词是你追着模型喊“记住这个”，skills是模型自己需要时去查手册。这个区别在长会话里特别明显——指令不会随着对话变长而被稀释。

跟MCP（模型上下文协议）这类工具相比，skills也更轻。MCP适合接外部数据源和操作外部系统，而skills几乎不需要什么基础设施，一个文件加一个目录就能跑起来，天然自带“人肉可读”属性，随手改随手生效。要类比的话，MCP像是给AI接了API接口，skills更像是给AI做了入职培训。

再往深一层说，skills这套机制能火起来，根本原因是它把“模型能力”和“业务经验”做了解耦。模型本体的能力升级，不用等工具厂商；只要你把经验沉淀成skills文件，换一个更强的模型也能继续复用。这个特性在Codex、OpenCode这些开源方案里尤其有价值——因为你攒下的技能资产，不会因为换工具而清零。

2. 三分钟上手：把GitHub上的skills装进主流编程助手

现在实战。这里重点回答一个高热问题：Claude Code怎么手动装GitHub上的skills。很多人的困惑是，仓库里文件那么多，到底要克隆哪些、放哪里、怎么让工具识别到。

2.1 先摸清技能目录的存放规则

手动安装的核心就是一条：找到SKILL.md文件所在的那个文件夹，把它整体放到工具能扫描到的地方。SKILL.md是技能包的入口文件，你可以把它理解成说明书首页——YAML格式的开头定义技能的元信息，后面的正文写具体操作流程。

不同工具的扫描路径略有差异，但大逻辑一致：

• Claude Code：项目级放到.claude/skills/，用户级放到~/.claude/skills/
• Codex：项目级.codex/skills/，用户级~/.codex/skills/
• OpenCode：通常在配置目录下的skills/子目录

用户级和项目级的区别，一句话说清：用户级是你给所有项目配的通用技能，适合放代码审查习惯、提交信息规范这类恒定规则；项目级跟着特定仓库走，适合放跟业务绑定的流程，比如这个项目的架构约定、测试要求。团队协作时，项目级技能可以直接提交到仓库里，所有人拉到代码就自动拥有同一套规则。

2.2 手动安装的标准动作

假设你在GitHub上找到一个很想要的skill仓库，手动安装分四步：

1. 把仓库clone到本地，或者直接下载ZIP。
2. 在仓库里找到包含SKILL.md的那个目录。注意看目录结构——有些仓库把几十个skill按文件夹分好了，你要的不是整个仓库，而是其中单个技能文件夹。
3. 把这个文件夹复制到目标路径。以Claude Code用户级安装为例，就是把<技能文件夹>复制到~/.claude/skills/下，复制完目录结构长这样：~/.claude/skills/<技能名>/SKILL.md。记住这层关系：技能文件夹的直接子级必须有SKILL.md，否则扫描不到。
4. 重启会话或执行工具的重载命令，然后直接测试：用一句能触发该技能的话提问，看模型是否表现出遵循了技能里的规则。

我特别想提醒一个坑：GitHub上有不少skill仓库是直接把整个项目打包发布的，下载下来是嵌套目录层层套娃。你需要核对清楚SKILL.md是不是在技能文件夹的一级子目录下。我之前装一个documents转换skill，明明放对了路径却一直不生效，排查半天发现是文件夹套了一层仓库外壳，SKILL.md被埋在了二级子目录。所以装完第一件事就是检查路径深度。

2.3 验证装没装上：别只看目录

目录对了不一定代表能用。最简单的验证方式是直接对话测试。比如你装了一个“PR描述生成器”的skill，就故意用“帮我写这个分支的PR描述”这种带触发场景的话开口。模型如果调用了技能，回答风格和流程会明显按照SKILL.md里的规则来，比如主动问你提交范围、按模板产出内容。

想看得更细的话，可以开启工具的输出追踪功能。Claude Code会用日志记录模型读取了哪些文件，那里能看到技能文件是否真的被读取。这个方法比猜可靠一百倍。装完技能没反应，九成是描述和触发场景写得不对，或者放错了路径，这两类问题靠日志一查一个准。

顺带提一下superpower skills这类聚合包。网上很多人问“superpower skills怎么安装”，这类聚合包通常以插件市场或安装脚本形式提供，仓库README里会有明确的一键安装命令。但如果你不想一键脚本改变你现有的配置结构，或者所处的网络环境不方便执行在线安装，那就回到手动安装的老路子：把它们拆解成一个个标准技能文件夹，按上述规则逐个放进skills目录。手动装虽然麻烦点，但每个技能都在哪儿、内容是什么，你心里有数，后续清理也方便。

3. 手写第一个Skill：规则、模板与描述的艺术

说完了装现成的，来聊聊怎么自己写。很多人在“AI skills怎么写”这个搜索词上卡住，其实核心就一套格式套路：一个SKILL.md文件 + 按需配套资源文件。

3.1 框架：SKILL.md的两段式结构

一个标准的SKILL.md长这样：

--- name: pr-description-writer description: 当用户要求撰写或优化Pull Request描述、且提供了分支或提交信息时使用。输入是git分支名、提交记录；输出是结构化PR描述。 --- # PR描述生成器 ## 角色与目标 你是一名资深代码审查者，负责把git改动整理成清晰可读的PR描述。 ## 执行步骤 1. 先运行 git log 和 git diff 获取改动范围。 2. 按改动类型将提交归类：功能新增、Bug修复、重构、文档。 3. 对每个类别，用一行话概括核心改动，不展开细节。 4. 最后生成模板化PR描述，包含：标题、背景、改动清单、测试建议。 ## 输出格式 ```markdown ## 标题 ... ## 背景 ... ## 改动清单 - ... ## 测试建议 - ...

禁忌

• 不要编造提交中没有出现的改动。
• 不要使用Emoji。
• 如果改动过大，优先询问用户是否需要按模块拆分。

frontmatter里最重要的字段是两个：`name` 和 `description`。name是技能的唯一标识，description则决定模型“什么时候该读这个文件”。读文件这个动作是模型自主判断的，而判断依据就是description是否匹配当前任务。 ### 3.2 描述字段：写得越具体，命中率越高 我在刚学写skills时犯过一个极其典型的错误：把description写成“用于生成PR描述”。这么写的作用约等于没说——因为模型面对“帮我把这些改动整理一下”这类真实口语触发时，根本不会把这句话跟PR描述关联上。 一份好description要包含三个要素：触发场景、输入来源、输出目标。拿上面那个示例来说：触发场景是“用户要求撰写或优化Pull Request描述”；输入来源是“提供了分支或提交信息”；输出目标是“生成结构化PR描述”。模型拿到这个描述，就能在杂七杂八的请求中精准判断“现在该调用这个技能了”。 这是一条很容易被忽略的经验：description是写给模型的路由器，不是写给人的摘要。你要去模拟用户在真实对话里会怎么拐弯抹角地表达需求，把这些可能说法都自然地融进description里。比如除了“写PR描述”，还可以补一句“或整理这次改动的提交信息”。多一个触发表达，就少一次技能沉睡。 ### 3.3 正文设计：把隐性经验显性化 正文部分要写的是“你希望模型每次都能稳定执行的完整流程”。有三个内容建议写进正文：角色设定、执行步骤、禁忌清单。 角色设定给模型一个行为基调，比如“资深代码审查者”，这会影响它后续的用词和判断标准。执行步骤是主体，要按顺序写清楚每一步做什么。这里有个关键原则：步骤里涉及的每条规则都应该具体到不能有第二种理解。 禁忌清单也值得单独列一节。为什么强调这个？因为模型对这类规则的记忆优先级是最高的。比如“不要编造提交中没有出现的改动”这条，实测非常管用，能有效抑制模型在PR描述里放飞自我。你踩过的经验教训，都可以沉淀到这里，让同一个坑不踩第二次。 如果是技能本身逻辑复杂，需要示例、模板代码、参考文档，这些内容不要全塞进SKILL.md。把SKILL.md保持在“可快速阅读理解”的篇幅，其他内容放到同目录下的assets或references子目录，用相对路径引用。否则说明文件太长，模型读起来反而抓不住重点。 ### 3.4 调试循环：跟模型一起调技能 自己写的第一个skill几乎不可能是完美的，调试是必须的动作。这几步是我每次写新技能都会走的流程： 1. 用真实任务触发技能，观察输出是否符合预期。 2. 打开日志，确认技能文件确实被加载。 3. 哪里失控就改哪里。大多数情况下，问题出在正文规则表述模糊，比如“按改动类型归类”没说清到底分几类——写清“功能新增、Bug修复、重构、文档”四类就能立竿见影。 4. 换一个完全不同的触发说法再测一次，检验description的鲁棒性。 这套循环跑个两三轮，技能基本就能稳定干活了。我个人的经验是，花一小时写技能正文，不如花半小时打磨description和边界规则，前者决定下限，后者决定上限。 ## 4. 哪些场景值得专门配Skill：前端、数模、AI漫剧的实战拆解 skills不是万能的，也不是所有任务都值得配一个。结合热搜里出现的高频场景，聊聊我看来真正值得沉淀成skill的几类活。 ### 4.1 前端开发：把工程规范变成肌肉记忆 前端是skills落地最密集的领域之一。常见的技能包括：组件生成、代码审查、样式规范检查、依赖更新评估。这类场景有一个共同特点：重复度高、规范性强、判断逻辑可文本化。 比如团队里有一套React组件的写法约定——函数组件、props用TS类型定义、样式用CSS Modules、必须导出memo版本。以前这些约定靠代码评审时人工盯，现在写一个“React组件工厂”的skill，让模型严格按照这套约定生成组件代码，新成员也能写出老手风格的代码。这个场景里skills的价值不只是提效，更是把团队隐性规范显性化。 前端技能设计时有一个特定策略值得提：把项目的技术栈和目录约束写进项目级skill，而不是用户级skill。因为不同项目的框架和约定不一样，项目级隔离能避免规则串味。 ### 4.2 数学建模与竞赛：复杂任务的流程管理器 数学建模场景能成为skills热门，是因为竞赛流程极其固定、但每一步都不简单。华为杯这类数模比赛，从赛题解读、模型选型、求解验证到论文撰写，整个流程可以拆成几个skill节点： - 赛题解读技能：把赛题要求拆成约束条件、目标函数、数据字段说明 - 模型选型技能：根据问题特征推荐候选模型，列出每个模型的适用假设和计算复杂度 - 论文结构技能：按竞赛论文模板组织章节，检查摘要是否覆盖关键结论 - 结果呈现技能：规范图表命名和格式 这类技能的好处在于，模型不必每次从零“思考”竞赛套路，而是按既定流程推进，关键节点还能主动提醒你“数据检查过了吗”“灵敏度分析做了吗”。参加过一次数模竞赛的人肯定都懂，流程化是制胜关键，而没有skill的裸模型在长时间多轮对话里几乎必然遗漏某个环节。这种场景下，一个设计良好的skill等于给全队配上从不缺席的流程管理员。 ### 4.3 AI漫剧与内容生产：把创意工作半标准化 “AI漫剧常用skills”这个热搜词很有意思。AI漫剧的生产链路通常是：文案创作、分镜拆解、绘图提示词生成、脚本整合。这套链路横跨文案和绘画两个领域，每个环节都有自己的专业规则。 比如“分镜拆解”技能，要能读懂叙事文案并拆成镜头列表，每个镜头有画面描述、景别、运镜方式、画面时长。这类规则高度专业化，很难靠模型默认水平完成，但又不值得为它单独开发一套工具。用skill封装恰恰合适——把分镜的格式规范和镜头语言规则写进SKILL.md，模型按规则输出，后期人工修改量能大幅下降。 内容生产场景还有一类很值得做的“反向技能”：内容质检。比如AI漫剧生成后，用技能检查分镜和文案是否匹配、是否有穿帮、角色一致性是否保持。这类技能本质上是给产出设立质量门禁，价值不输于生成类技能。 ### 4.4 怎么判断一个场景该不该配Skill 综合上面三类案例，我觉得判断标准可以压缩成三条： 1. 流程是否可固定？如果任务每次做法都不一样、高度依赖灵感，那写进skill只会限制发挥；反之如果步骤固定，就适合。 2. 是否要反复执行？一次性任务不值得沉淀，每周都要干的活才值得。 3. 规则能否文本化？规则能用文字讲清楚，才写得进SKILL.md；要是规则本身就是“看了才知道好”，那就别硬写。 满足这三条，配skill是值得的；不满足，直接用普通对话反而更自由。 ## 5. 攒了一堆Skill之后：清理与沉淀的方法论 装技能一时爽，技能库维护火葬场。热搜里提到“tibo关于清理skills的方法推荐”，我深有感触。Skill库越攒越大之后，会遇到几个典型问题：目录混乱、技能互相冲突、模型“选择困难”。这里分享一套我自己在用的管理方法。 ### 5.1 冲突是怎么发生的，又怎么排查 最常见的冲突是“同名不同内容”。GitHub上叫code-reviewer的skill可能有好几个版本，你装了一个觉得不好用，又从另一个仓库装了一个同名的，后装的覆盖了先装的，你以为自己在用B版本，其实跑的还是A版本。 排查办法很朴素：定期列目录，按修改时间排序，把长期没有触发记录（通过日志看）的技能拎出来审视。要么它的description写得不好导致一直没被触发，要么它跟别的技能职责重叠了，要么根本就是装完就忘了。三种情况只有一种值得留：改成更好的description。 ### 5.2 我的清理三层法 我现在管理技能库用三步： 1. 按来源和职责给每个技能加一个ID前缀。比如公司项目用 `com-`，前端通用用 `fe-`，数据处理用 `data-`。文件多的时候，前缀本身就是导航。 2. 把技能分成“核心常驻”和“按需调用”两类。核心常驻放用户级目录，比如代码风格、安全审查；按需调用尽量下沉到项目级目录，项目用完了删掉整个文件夹都不心疼。 3. 每两个月过一遍技能库。实测方法是看日志里各技能的读取次数，连续两个月没有一次触发的技能，直接进回收站。如果舍不得删，至少标注为disabled或挪出扫描目录。 这套方法执行下来，我的技能库从40多个瘦身到15个左右，模型触发准确率肉眼可见地提升了。原因不复杂：候选技能少了，description匹配时的干扰项就少了。 ### 5.3 沉淀：从“临时脚本”到“公用技能库” 清理不是只做减法，更高一层是把临时解法沉淀成正式技能。我在项目里写代码时经常临时要求模型做某个特殊格式的校验，后来发现这个校验几乎每次都要用，于是把校验规则整理成SKILL.md，补上description和示例，放到项目级目录。熟练之后，从一个临时想法到一个成熟技能，可能只要半小时。 团队层面上会更值得做。当项目级skills累积一段时间后，可以把其中通用的部分提取出来，形成团队统一的技能库。新成员入职，配置好工具后拉一下技能库，就等于把团队过去半年踩过的坑、总结的规范一次性装进大脑——这个效率提升，远比省几分钟写代码有价值。 最后分享一个小细节。不管你的技能库用哪种结构，强烈建议在SKILL.md的改动历史里补一行changelog。我自己吃过亏：某天发现一个技能表现明显变差，改来改去都找不到原因，后来才想起上周调整过正文里的一条规则。有了changelog，十分钟就能定位到是哪个改动影响了行为。这行字用不了你一分钟，但它在关键时刻能省下一下午。