企业官网建设流程全解析

最近这一年，AI编程助手的热度一直没降，而“skills”这个词被提得越来越频繁。无论你用的是Claude Code、Codex还是OpenCode，只要想让AI真正融入自己的项目、按团队规范干活，最后基本都会绕回到skills上。说白了，skills就是给AI助手装上一份可复用的“操作手册”，让它遇到特定场景时知道先做什么、后做什么、产出什么格式，不再张嘴就是一套通用回答。

这篇文章我会从“是什么、怎么装、怎么写、怎么选、怎么清理、常见坑”六个维度展开，通篇都是我自己在真实项目里折腾出来的经验。适合正在用AI写代码但觉得它“差点意思”的朋友，也适合想在数学建模、AI漫剧这类具体场景里用AI干活的人参考。

1. AI编程助手的Skills到底是什么

1.1 一个场景看懂Skills的运行逻辑

先说我踩过的一个典型坑。我让Claude Code帮忙重构一个前端组件，它很快给出了改动，代码也能跑。但当我追问“为什么类名没用我们项目的BEM规范”，它才老老实实说“抱歉，我没有看到规范文件”。问题在于：你不主动提醒，AI就不会主动去翻项目规范，也不会按你团队的验收清单检查。

Skills要解决的就是这个。我给它装了一个叫“frontend-fix”的技能包之后，行为立刻变了：每次接到前端改动任务，它会先读CSS规范，再按“目录结构确认、命名规范、依赖影响、测试补充”这个顺序执行，最后给出改动清单。我不需要每次重复叮嘱。

它的本质是一个目录，里面通常有一个SKILL.md文件作为总指挥，再加上脚本、模板、示例等辅助文件。AI在对话过程中会扫描这些技能目录，一旦发现描述匹配当前任务，就主动加载对应步骤。

1.2 Skills目录长什么样

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

.skills/ ├── frontend-fix/ │ ├── SKILL.md │ └── checklist.md └── pr-description/ ├── SKILL.md └── scripts/ └── get_diff.py

SKILL.md是入口，最前面是一段YAML元信息，写着技能名称、描述、使用场景；后面是正文，告诉AI具体怎么一步一步做。辅助文件用来承接模板、脚本、数据，AI需要时就去读、去执行。

这里有个关键点：description写得好不好，直接决定技能会不会被正确触发。写得太泛，AI什么都想调用它；写得太窄，该用的时候又无动于衷。后面我会单独展开讲。

1.3 Skills和MCP、全局规则到底什么关系

很多人会把Skills、MCP、CLAUDE.md三样东西搞混，其实它们解决的问题不一样。MCP（Model Context Protocol）更像给AI接上的“手臂”，用来连数据库、调API、访问外部工具，核心是扩展AI的触达能力。Skills更像给AI注入的“行为方式”，解决的是“它到底该怎么干活”的问题。

至于CLAUDE.md这类全局规则文件，我习惯把它理解成公司制度手册，常驻且影响所有对话；而Skills是岗位专用的细碎SOP，按需触发。举个例子：CLAUDE.md可以规定“所有代码必须补测试”，而一个“bug-reproducer”技能则告诉AI怎么把复现步骤写成脚本。两者可以共存，但别把所有内容都堆进全局规则，否则每次对话都要背着沉重的包袱。

2. 从GitHub手动安装一套现成Skills

2.1 该去哪里找Skills

GitHub是目前最集中的来源，搜awesome-claude-skills这类聚合列表，能一次看到几十个项目。比较典型的有两类：一类是官方示例仓库，比如Anthropic的skills示例，结构规范、适合学习；另一类是社区合集，比如superpowers，作者把大量经过实战打磨的技能包集中管理。

还有一个source是开发者的个人博客或个人仓库，经常有人针对某个领域沉淀出非常细的技能，比如专门做React组件代码审查，专门做Git提交信息规范。这些大而全的项目和小而精的个人项目，我建议都关注，但别急着全装。

有些技能库还提供网页版目录，可以在浏览器里先浏览每个技能的说明、触发描述、目录结构，再看值不值得下载。这个环节我称之为“装前调研”，能省下后面不少清理时间。

2.2 Claude Code手动安装步骤

我最早接触的是Claude Code的Skills机制，安装路径分两种：项目级和用户级。项目级放在当前项目根目录的.skills/下，跟随项目走；用户级放在~/.claude/skills/下，所有项目都能用。

手动从GitHub装一个技能包，流程就三步。第一步，把仓库拉下来，我一般用一个临时目录存放：

git clone https://github.com/example/example-skills.git ~/tmp/example-skills

第二步，看仓库结构，找到目标技能目录，复制到指定位置。如果只想给当前项目用：

mkdir -p .skills cp -r ~/tmp/example-skills/skills/frontend-fix .skills/

如果想全局生效，就换成：

mkdir -p ~/.claude/skills cp -r ~/tmp/example-skills/skills/frontend-fix ~/.claude/skills/

第三步是验证。我习惯直接在对话里问AI：“你现在有哪些可用的skills？”，如果它能列出刚安装的名字，说明扫描成功。要是它答不上来，先确认目录名称没有拼错，再确认SKILL.md的存在和格式。

2.3 Codex和OpenCode的安装差异

Codex里Skills的概念也在快速演进。大体上也是把技能目录放到它扫描的路径，再靠description触发，但具体配置项和全局配置文件名不一样。OpenCode则更像是把Skills当成插件体系的一部分，安装后可以在配置文件中启用或禁用。

我自己有个建议：不要因为工具不同就重复造轮子。技能内容本身用SKILL.md这种通用结构来描述，真正迁移时改的只有目录位置和触发层面的配置。很多技能包换一个工具之后，只是路径变了、格式微调，核心逻辑可以继续复用。

在我个人经验里，先从Claude Code把机制和写作方法跑通，再迁移到其他工具，是最顺的路线。

3. 开发属于自己的AI Skills

3.1 SKILL.md的骨架

写Skills没有太多玄学，核心就是SKILL.md。文件最上方是YAML元信息：

--- name: pr-description description: 当用户需要生成或优化Pull Request描述时使用。适用于GitHub工作流，包含diff分析和风险提示。 ---

然后是正文，正文一定要按步骤写，让AI能一步步执行。我写过不少技能，最大的体会是：给AI写SOP，要像给新同事做交接文档一样，把前置条件、执行顺序、输出格式、禁区通通写清楚。

一个合格的正文骨架大致包含：任务目标、执行步骤、输出模板、注意事项。步骤用有序列表，每步控制在几行以内，关键地方加粗强调。别写长篇大论，AI真正执行时偏好简洁明确的指令，内容太长反而会稀释关键信息。

3.2 description如何精准触发

description是整个技能最容易“翻车”的地方。我早期写过一个代码审查技能，description写的是“帮助用户进行代码审查”，结果写前端、写脚本、写SQL时它都跳出来抢活，特别烦人。

后来我把description拆成“什么时候用”和“什么时候不要用”两部分：“当用户要求审查代码、关注bug、性能、安全隐患时使用；进行风格讨论或单纯重构时不要触发。”这下触发准多了。触发写清楚，比写一大堆执行逻辑更管用，因为错过触发条件，执行逻辑写得再好也白搭。

3.3 实测：一个PR描述生成器

我拿自己最近在用的pr-description技能做个完整示意。它的目标是：每次打开Pull Request时，自动产出结构清晰的描述文本。

SKILL.md正文我会这样写：

# PR描述生成器 执行步骤： 1. 读取当前分支相对于主分支的完整diff变化。 2. 按文件类型归类本次改动，推断改动的业务目标。 3. 按下面模板生成描述： - 背景与目的：用两三句话解释为什么有这次改动。 - 主要变更：按模块列出，每条不超过一行。 - 影响范围：标注涉及页面、接口、数据库表等。 - 风险与回滚：列出可能受影响的点，以及回滚方式。 - 测试建议：给出应该执行的测试命令或手工验证路径。 4. 如果diff里出现TODO、调试日志、临时注释，单独列出一节“待清理项”。 5. 不使用模糊形容，不用“若干优化”这种话，全部落到具体文件和行为。

配套脚本get_diff.py会负责把diff拉出来、按文件类型做个初步分类，AI再在这个基础上组织语言。整个技能只有几十行指令加一个脚本，但效果比我手动写PR模板稳定得多。

实际操作中有一个很关键的参数调整：把“影响范围”写得太宽时，AI会把所有改动都标成“可能有影响”，等于没写。我后来在技能里加了一句规则——只有明确关联的模块才写进影响范围，没把握的字段写进“待确认”。语气强硬一点，AI输出质量立刻上去。

4. 按场景选Skills：前端、数学建模、AI漫剧

4.1 前端开发场景

前端是Skills最容易见到效果的方向之一。原因很简单：前端规范多、实践杂、反馈路径清晰。我目前保留的高频技能有代码审查、样式语义化修复、性能排查和依赖升级这几类。

以性能排查为例，技能会把“先看Network加载瀑布、再查主包体积、再检查渲染次数”这个顺序固定下来，并且要求给出具体数值，不许只说“性能可能有问题”。以前我手动排查一次要半小时，现在技能把路径固定住，AI几分钟就能给出候选清单，我再人工复核一遍就行。

代码审查类技能也值得装。它会要求AI在审查时按“正确性、可维护性、性能、安全”四层依次过，每一层都给出结论和证据。这种结构化输出，比单纯让AI“看看有没有问题”专业得多。

4.2 数学建模比赛场景

华为杯这类数学建模竞赛，特点是时间紧、任务重、环节多。比赛期间我见过太多团队把AI当成橡皮擦，想到什么问什么，最后一大堆垃圾代码和片段。真正管用的做法是提前给比赛场景写一套完整Skills。

我是这样设计比赛技能包的：它被拆成“赛题解析、数据清洗、模型选型、论文写作、图表规范”五个子技能，由总控技能串起来。总控技能在比赛第一天做的第一件事，是让AI输出一份作战日历：第一天完成赛题拆解和初步模型选型，第二天出结果并做敏感性分析，第三天集中写论文和画图。模型选型子技能则规定，上场先判断数据规模、特征类型、精度要求，再决定用统计模型还是机器学习模型，不许一上来就上最复杂的深度学习。

用过一轮之后我感触很深：Skills在数模比赛里最大的价值不是让AI替你做决策，而是把团队过去踩过的坑固化成SOP，避免AI在关键节点上带着你一起跑偏。

4.3 AI漫剧制作场景

AI漫剧是另一个讨论度很高的方向。和编程不一样，制作漫剧的核心痛点是角色一致性、分镜连贯性和叙事节奏。这些正好都可以做成Skills。

我给朋友搭过一套AI漫剧工作流，其中最关键的是角色一致性技能。它会要求AI在生成任何角色画面之前，先读取角色的设定文档，再按设定里的外貌特征、服饰细节、表情基准去写生成提示词，每次生成后还自动做一致性检查。没有这种硬性约束，AI经常把同一个角色画得千变万化。

分镜脚本技能也很实用。它规定每一集先产出分镜表，列清楚景别、时长、台词、旁白、情绪目标，再进入画面生成环节。有了这个流程，整个团队在后期整合素材时不用来回返工。AI漫剧领域的Skills还比较新，但它的底层逻辑和编程场景完全一致：把不确定的AI行为，约束成可复现的流程。

4.4 场景对照速查

我把几个常见场景和推荐技能方向整理成了一张表，方便大家直接对照：

有一点想特别提醒：装技能之前，先问自己“这个场景我是不是至少每周遇到一次”。如果不是，就先放着，别为偶尔的需求增加AI的负担。

5. Skills不是越多越好：维护、更新与清理

5.1 为什么技能装多了AI反而变笨

Skill的触发机制是靠AI扫描description来判断的。技能数量多了之后，每一次交互AI都要拿当前请求去匹配几十个description，选择噪音会明显变大。还有一层隐形开销：有些技能会在触发后把附带模板、脚本信息一起读进上下文，token消耗也会上升。

我做个不太严谨但很直观的比喻：给AI塞50本岗位SOP，它可能连该翻哪本都不知道；塞3本和工作紧密相关的，它翻起来很快，执行也到位。所以技能库的精简，不是省存储，而是在帮AI降低决策成本。

我自己的准则是：一个项目里长期启用的技能控制在五个以内，冷门技能放到归档目录，真想用的时候再移回来。这样既不影响日常效率，也不用频繁卸载重装。

5.2 一套实测有效的清理方法

之前看到tibo分享过skills清理思路，我自己沿用并改了一版，现在固定用这套方法。第一步，让AI一次性列出它当前能识别到的所有技能，把名字、描述、触发场景一起导出来。第二步，把过去一周你主动使用过的技能打钩，再看哪些技能是从安装到现在都没被触发过的。

第三步最关键：把没触发过的技能全部移到archive-skills/目录，而不是直接删除。保留它们是为了防止哪天突然要用时找不到，但移出主目录之后，它们不再参与AI的日常扫描，也就不会干扰判断。我每次清理完，都会明显觉得AI回答质量回到正常水准。

最后一步是收缩保留技能的description，把一些过宽的描述改窄。这个动作看起来小，效果却很显著。我试过把一个通用审查技能改成“只处理前端组件审查”之后，误触发率直接降下来。

5.3 更新与备份策略

我从GitHub装技能时，仓库经常在更新。我的做法是：不轻易拉最新版，先看更新说明，如果只是修描述或加示例，不一定需要升级；但如果是修复了已知的触发错误，就值得更新。更新之前先把当前版本复制成带日期后缀的备份目录，万一新版不顺手，随时回滚。

自己的技能同样需要用Git管理。我每个技能对应一个独立仓库，每次优化都写清楚commit message，比如“调整PR技能的description，减少在重构场景的误触发”。时间长了之后，这些commit记录就是最好的技能演进日志，比任何文档都有说服力。

6. 实战问题实录：装上Skills前后的那些坑

6.1 技能装好了却不触发

最典型的问题就是“明明把SKILL.md放进去了，AI却像没看见”。我先排查路径，项目级还是用户级，放错地方就会失效。再排查文件名，SKILL.md的拼写不能错，大小写也有讲究。第三个排查点是frontmatter，如果YAML格式解析失败，整个技能目录会被AI跳过，而且通常没有任何报错提示。

所以我自己养成了一个习惯：刚装完技能先不干别的，直接问AI“你现在有哪些可用技能”。只要它能正常报出技能名字和描述，就说明扫描正常。这一步永远是第一步，不做的话后面全是白忙。

6.2 两个技能互相打架

当多个技能的description都匹配同一个请求时，AI有可能会把两边的指令混在一起执行，输出就会变得很奇怪。比如一个“代码审查”技能要求循序渐进，另一个“快速重构”技能要求立即给出改动方案，两者撞上时AI容易两头下注，结论时左时右。

解决办法有两个。一个是从源头避免，把冲突技能的触发描述写得互斥，明确限定各自的使用边界。另一个是在项目级目录下只保留真正需要的那一个，其他技能移到用户级或者归档目录。项目级技能的优先级通常更高，可以用这一点来控制大局。

6.3 模型版本造成的兼容性问题

就算一切都装对了，模型本身对Skills的理解能力也有差异。越新的模型，对复杂指令的分步执行越稳定。我遇到过一次情况：技能内容完全没变，升级模型之后输出质量突然大幅提升，原因就是新模型更擅长按步骤执行长指令。

如果你的技能在某个模型上表现不稳定，先别急着改技能内容，试试相同技能在不同版本模型下的表现。一次小规模对比，就能避免你白改一大堆描述。这个问题常被忽视，值得记在排查清单里。

6.4 脚本依赖与工作目录

当Skill通过脚本读取项目数据时，最容易遇到两类问题。一类是python脚本依赖的第三方库没装，脚本报错后AI可能会直接跳过脚本，输出残缺结果。我现在的做法是在SKILL.md里写清楚前置依赖，甚至让技能先检查依赖、缺失就给出安装命令，而不是硬跑。

另一类是工作目录问题。AI执行脚本时，当前工作目录可能不是项目根目录，导致相对路径全部失效。我会在技能里明确要求“先定位到项目根目录再执行脚本”，并且脚本里都用相对项目根的路径，不依赖bash启动时的目录。这些小细节，往往决定了技能能不能在真实项目里稳定复现。

6.5 一份快速排查清单

我把常见问题压缩成一张速查表，遇到问题直接按表查：

这份清单陪我躲过了很多莫名其妙的问题。现在每遇到一个奇怪现象，我都会先问自己：它到底是被哪一层影响到的？是路径、描述、脚本，还是模型本身？逐层排除，技能最终都能稳定下来。

我个人的体会是，Skills这个东西，价值不在于“装得多”，而在于“用得好”。我从见啥装啥的阶段一路走过来，最后保留在常用清单里的，也就不到十个。真正让AI能力上一个台阶的，是把少数几个技能打磨到极致，让它在每次触发时都输出稳定、可预期的结果。最后再分享一个小技巧：调完技能后，让AI在回答末尾加上一句“本次遵循了技能里的哪些步骤”，这样一眼就能看出技能是真正生效还是在假装工作。这个习惯帮我减少了很多无效调试，也希望大家能从中得到帮助。