企业官网建设流程全解析

1. 从“skills”这个热词说起：它到底是什么，为什么突然火了

如果你最近在技术社区、AI 工具群或者前端圈子里频繁看到“skills”这个词，不用怀疑，它确实正在成为 AI 辅助开发领域一个绕不开的概念。但很多人第一次接触时都会懵：skills 到底是插件？是提示词模板？是某种配置文件？还是某个平台的专属功能？我刚开始也花了点时间才把这件事理清楚，这里直接给结论——skills 本质上是一套写给 AI 编程助手看的“技能说明书”，它用结构化的方式告诉 AI：在什么场景下、按照什么步骤、调用哪些工具、遵守哪些约束，去完成一件具体的任务。

这个概念的流行，和 Claude 系列工具（尤其是 Claude Code）的普及直接相关。Claude Code 是一个跑在终端里的 AI 编程助手，它能读写文件、执行命令、搜索代码库，能力很强，但默认状态下它对你的项目规范、团队约定、特定领域的操作流程一无所知。你当然可以在每次对话里手动把要求打一遍，但那样效率极低，而且容易漏。skills 就是为了解决这个问题而出现的：把重复性的、有固定套路的任务，沉淀成一份可复用的技能描述文件，AI 在需要时自动加载并执行。

那为什么是现在火？我的观察是三个因素叠加。第一，AI 编程助手从“聊天玩具”变成了“真正能干活的工具”，大家开始认真考虑怎么把它嵌进日常工作流；第二，社区里涌现出一批高质量的 skills 分享，比如前端开发、数学建模、代码审查、文档生成等场景，让后来者看到了“原来还能这么用”；第三，SKILL.md 这种约定俗成的文件格式降低了门槛，你不需要写代码，用自然语言加少量结构就能定义技能。这三点凑在一起，skills 就从一个小众玩法变成了值得系统学习的东西。

这篇文章适合谁看？如果你是刚接触 Claude Code 或者类似 AI 编程工具的新手，想搞清楚 skills 的来龙去脉和基本用法，那前面的基础部分会对你有帮助；如果你已经在用这类工具，但觉得每次都要重复交代背景很烦，想把自己的经验沉淀成可复用的技能库，那中后段的实操和避坑经验会更对胃口；如果你只是好奇“skills 推荐”“常用 skills”这类搜索词背后到底在说什么，那通读一遍也能建立起完整的认知框架。我会尽量用从业者之间交流的方式来讲，不堆术语，该给步骤给步骤，该说原理说原理。

2. skills 的核心机制拆解：SKILL.md 到底写了什么

2.1 一个 skill 的最小结构长什么样

要理解 skills，最直接的方式就是看一个 SKILL.md 文件里到底有什么。虽然不同工具、不同版本的实现细节有差异，但核心结构是相通的。一个典型的 skill 通常包含以下几个部分：名称和描述，用来说明这个技能是干什么的、什么时候该触发；适用场景，告诉 AI 在什么条件下应该加载这个技能；操作步骤，这是主体，用自然语言或者半结构化的方式描述执行流程；约束和注意事项，比如哪些操作不能做、哪些参数必须确认；示例，给出输入输出的样例，帮助 AI 理解预期结果。

我拿一个前端开发场景来举例。假设你想定义一个“组件代码审查”的 skill，SKILL.md 大概会这么写：名称叫“react-component-review”，描述是“对 React 函数组件进行代码审查，检查 hooks 使用规范、props 类型定义、性能隐患和可访问性问题”。适用场景写明“当用户要求审查 .tsx 或 .jsx 文件中的组件代码时触发”。操作步骤分几条：先读取目标文件，识别组件定义和 hooks 调用；然后逐项检查 useState 和 useEffect 的依赖数组是否完整；接着检查 props 是否有 TypeScript 类型或 PropTypes 定义；再检查是否有不必要的重渲染风险；最后按严重程度输出问题列表和修改建议。约束里写清楚“不要自动修改代码，只输出审查意见”“如果文件超过 500 行，先询问用户是否只审查变更部分”。

这个结构看起来简单，但里面有几个关键设计点值得说。第一，触发条件要明确。如果描述写得太宽泛，AI 可能在不需要的时候也加载这个技能，浪费上下文窗口；写得太窄，又可能该用的时候不触发。我的经验是，触发条件里最好包含具体的文件类型、用户意图关键词和操作对象。第二，步骤要可执行。不要写“检查代码质量”这种模糊的话，要拆成“检查 X”“确认 Y”“对比 Z”这种 AI 能一步步照做的动作。第三，约束要硬。尤其是涉及文件修改、命令执行、网络请求的操作，一定要明确边界，否则 AI 可能会做出你意料之外的事情。

2.2 skills 和普通提示词的区别在哪里

很多人会问：我直接在对话里把要求打出来不就行了，为什么要费劲写一个 SKILL.md？这个问题我一开始也想过，实际用下来发现区别主要在三个层面。

可复用性是最直观的。你写一次 skill，之后所有同类任务都能触发，不用每次重新交代背景。比如你团队有一套固定的代码提交规范，写成 skill 之后，AI 在帮你生成 commit message 时会自动遵守，省去了反复提醒的麻烦。一致性是第二个层面。人写提示词会有波动，今天记得检查类型定义，明天可能就忘了；skill 是固化的，每次执行都按同样的标准来，输出质量更稳定。可组合性是第三个层面，也是我觉得最有意思的地方。多个 skill 可以叠加使用，比如一个“代码审查”skill 加一个“安全扫描”skill，AI 在处理同一个文件时可以同时应用两套规则，这种组合能力是手动提示词很难做到的。

当然，skills 也不是没有代价。写一个高质量的 skill 需要时间，而且要对任务本身有足够深的理解，否则写出来的步骤是空的。另外，skill 加载会占用上下文窗口，如果项目里塞了几十个 skill，AI 可能反而被干扰。所以我的建议是：高频、固定、有明确标准的任务才值得写成 skill，一次性或者高度依赖具体上下文的任务，直接对话更划算。

2.3 不同工具对 skills 的支持差异

目前 skills 这个概念并不是某一个工具独有的，Claude Code、Codex 以及一些开源 AI 编程工具都在不同程度上支持类似机制。差异主要体现在几个方面：文件位置和加载方式，有的工具要求 skill 放在项目根目录的特定文件夹下，有的支持全局技能库；触发机制，有的是 AI 自动判断是否加载，有的需要手动调用；格式严格程度，有的要求严格的 YAML front matter，有的只要自然语言描述就能识别。

以 Claude Code 为例，它通常会在项目目录下寻找特定命名的文件或文件夹来识别 skills。社区里常见的做法是在项目根目录建一个.claude/skills/或者类似结构的目录，每个 skill 一个子文件夹，里面放 SKILL.md。但具体路径和命名规则会随版本变化，我踩过的坑是：照着半年前的教程建了目录，结果新版本改了规则，skill 死活不触发。所以一定要以你当前使用的工具版本的官方说明为准，社区教程只能参考思路，不能照搬路径。

Codex 那边的 skills 机制思路类似，但在格式和触发逻辑上有自己的特点。如果你同时用多个工具，建议把 skill 的内容和工具相关的配置分开管理，核心的操作步骤和约束写成通用文档，然后针对不同工具做一层适配。这样迁移成本会低很多。

3. 手把手实操：从零写一个能用的 skill

3.1 动手之前先想清楚三件事

在打开编辑器写 SKILL.md 之前，我强烈建议你先花十分钟把这三个问题想明白，否则写出来的 skill 大概率是废的。

第一，这个任务真的会重复发生吗？如果只是偶尔做一次，写 skill 的时间成本可能比直接对话还高。判断标准很简单：过去一个月里，你让 AI 做过几次类似的事？如果超过三次，就值得沉淀。第二，这个任务有明确的成功标准吗？skill 的价值在于把“怎么做”固化下来，如果连你自己都说不清楚什么算做得好，那写出来的步骤也是模糊的。比如“帮我写个好点的文案”就不适合做 skill，“按照品牌调性检查文案中的禁用词和语气问题”就适合。第三，这个任务需要 AI 调用外部工具或读写文件吗？如果涉及文件操作、命令执行、API 调用，skill 里必须把这些边界写清楚，否则风险很高。

我自己的习惯是，在笔记软件里维护一个“候选 skill 清单”，每次遇到重复性任务就记一笔，攒够三次再动手写。这样能确保写出来的 skill 都是真正高频的，不会变成一堆没人用的摆设。

3.2 写一份 SKILL.md 的完整流程

假设我们要写一个“数学建模论文格式检查”的 skill，这是社区里搜索量很高的场景。下面是我实际操作的步骤。

第一步，确定 skill 的名称和触发描述。名称用英文小写加连字符，比如math-modeling-format-check。描述要包含关键词，方便 AI 匹配，比如“检查数学建模竞赛论文的格式规范，包括摘要结构、公式编号、图表标题、参考文献格式和页边距要求”。这里的关键是把用户可能说的同义表达都覆盖进去，比如“论文格式”“排版检查”“格式规范”这些词都放进去，提高触发率。

第二步，写适用场景和排除条件。适用场景写“当用户要求检查数学建模论文格式、排版或规范时触发”。排除条件也很重要，比如“不适用于内容质量审查”“不适用于非竞赛类学术论文”，这样能避免 AI 在不该用的时候乱用。

第三步，拆解操作步骤。这是最花时间的部分。我会先把整个检查流程在脑子里过一遍，然后按顺序写下来。比如：先读取论文文件，识别章节结构；然后检查摘要是否包含问题、方法、结果、结论四个要素；接着检查公式是否连续编号、编号格式是否统一；再检查图表是否有标题、标题位置是否正确；然后检查参考文献格式是否符合竞赛要求；最后检查页边距、字体、行距等排版参数。每一步都要写清楚检查什么、怎么判断、不符合时怎么记录。

第四步，补充约束和注意事项。比如“只输出检查报告，不自动修改文件”“如果发现格式问题超过 20 处，按严重程度排序后只展示前 20 条”“遇到无法判断的情况，标记为待确认而不是直接报错”。

第五步，加示例。给一个输入样例和对应的输出样例，让 AI 更清楚预期结果。示例不用太长，但要有代表性。

写完之后，我会实际跑几个测试用例，看看触发是否准确、步骤是否可执行、输出是否符合预期。通常第一版都会有各种问题，改两三版才能稳定。

3.3 让 skill 真正被触发的几个技巧

写完 SKILL.md 只是第一步，更头疼的是怎么让 AI 在该用的时候用上。我踩过的坑包括：skill 写好了但从来不触发、触发了但执行到一半跑偏、多个 skill 同时触发互相干扰。下面这几个技巧是实测有效的。

描述里放“用户会说的话”。AI 匹配触发条件时，主要看你的描述和用户输入之间的语义相似度。所以描述里要包含用户可能用的口语化表达，而不是只写专业术语。比如用户可能说“帮我看看这个论文格式对不对”，那描述里就要有“检查论文格式”这样的短语。

控制 skill 的数量和粒度。一个项目里不要塞太多 skill，我建议控制在 10 个以内，每个 skill 的职责尽量单一。如果一个 skill 想管太多事，触发会变得不稳定，执行也容易乱。宁可拆成两个小 skill，也不要写一个巨无霸。

用明确的文件路径和命名。不同工具对 skill 文件的存放位置有要求，一定要按当前版本文档来。我见过有人把 SKILL.md 放在项目根目录，结果工具只扫描特定子目录，自然不触发。另外文件名大小写也要注意，有的工具区分大小写。

测试时用真实场景。不要只测试“完美输入”，要试试模糊的、带错别字的、口语化的表达，看看 skill 还能不能触发。真实使用中用户的输入往往是不规范的，skill 的鲁棒性很重要。

4. 高频场景与 skills 推荐：哪些方向值得投入

4.1 前端开发场景的 skills 实践

前端开发是目前 skills 应用最密集的领域之一，原因很简单：前端任务重复性高、规范多、工具链成熟。我整理了几个实际用下来收益明显的方向。

组件代码审查是最常见的。前面已经举过例子，核心是检查 hooks 依赖、props 类型、性能隐患和可访问性。这个 skill 的价值在于把团队代码规范固化下来，新人提交的代码也能按同样标准审查。样式规范检查也很实用，比如检查是否使用了设计系统的 token、是否有硬编码颜色值、响应式断点是否统一。提交信息生成是另一个高频场景，根据代码变更自动生成符合团队规范的 commit message，省去手动写的麻烦。

还有一个我觉得被低估的方向是依赖升级检查。前端项目依赖多、更新快，升级时容易出兼容性问题。可以写一个 skill，让 AI 在升级某个依赖前，先检查项目中所有用到该依赖的地方，列出可能受影响的文件和代码片段，再给出升级建议。这个 skill 写起来不复杂，但能省下大量排查时间。

4.2 数学建模与科研场景的 skills 思路

数学建模比赛和科研写作是 skills 搜索里的热门方向，这也不难理解：这类任务流程固定、格式要求严格、时间压力大，正好适合用 skill 来提效。

论文格式检查前面已经详细讲过。代码复现检查是另一个实用方向，数学建模经常需要把论文里的算法用代码实现，可以写一个 skill 来检查代码是否完整复现了论文中的公式和步骤，有没有遗漏边界条件。图表生成规范也值得做，比如统一图表配色、字体、尺寸，确保论文里的图表风格一致。参考文献管理可以检查引用格式、去重、补全缺失信息。

科研场景里，文献综述辅助是一个有争议但确实有用的方向。让 AI 帮你梳理某个方向的文献脉络、提取核心方法和结论、对比不同工作的差异，能节省大量阅读时间。但要注意，AI 的文献理解能力有限，输出只能作为参考，不能直接引用。我的做法是把这个 skill 定位为“阅读辅助”而不是“写作替代”，输出的是结构化的笔记而不是成稿。

4.3 通用效率类 skills 的取舍

除了垂直场景，还有一些通用效率类的 skills 也值得考虑，但要谨慎选择，因为太泛的 skill 往往效果不好。

文档生成是一个相对靠谱的方向，比如根据代码注释自动生成 API 文档、根据变更记录生成发布说明。会议纪要整理也有人做，把会议录音转写后让 AI 提取待办事项和决策点，但准确率取决于转写质量。邮件草拟可以按场景分类，比如客户回复、内部沟通、进度汇报，每种场景一个 skill。

我不太推荐做的是那种“万能助手”型的 skill，比如“帮我处理所有文本任务”。这种 skill 描述太宽泛，触发不稳定，执行时 AI 也不知道该按什么标准来。skill 的价值在于具体，越具体越有用。宁可写十个窄场景的 skill，也不要写一个宽泛的。

5. 常见问题与排查实录：那些教程里不会写的坑

5.1 skill 不触发怎么办

这是最高频的问题。我遇到过的原因大概有这么几类：文件位置不对，工具根本没扫描到；描述关键词不匹配，用户输入和 skill 描述之间语义差距太大；格式有误，比如 YAML front matter 写错了导致解析失败；skill 数量太多，AI 在加载时做了取舍，优先级低的被跳过了。

排查顺序建议这样：先确认文件路径和命名是否符合当前工具版本的要求，这一步能解决大部分问题；然后检查描述里是否包含了用户实际会说的关键词，可以手动把用户输入和描述做对比；接着看格式有没有语法错误，特别是缩进和特殊字符；最后如果 skill 确实很多，试着临时移除一些，看目标 skill 是否能触发。

还有一个隐蔽的坑是上下文窗口限制。如果项目很大、对话很长，AI 可能没有足够的上下文空间来加载 skill。这种情况下，要么精简 skill 内容，要么在对话开始时手动提示 AI 加载特定 skill。

5.2 skill 执行到一半跑偏怎么处理

触发成功但执行跑偏，通常是因为步骤写得太模糊或者约束不够硬。比如你写“检查代码质量”，AI 可能只检查了格式就结束了；你写“修改文件”，AI 可能改了你没预期的地方。

解决办法是把步骤拆到不能再拆，每一步都是一个明确的动作，有明确的输入和输出。约束要写成硬性规则，比如“禁止修改任何文件”“如果发现超过 10 个问题，先输出摘要再询问是否展开”。另外，可以在 skill 里加一个“执行前确认”步骤，让 AI 在开始前先复述一遍它打算怎么做，你确认后再继续。这个习惯能避免很多意外。

5.3 多个 skill 冲突怎么协调

当项目里有多个 skill 时，可能会出现同时触发或者互相干扰的情况。比如一个“代码审查”skill 和一个“代码格式化”skill 同时作用于一个文件，AI 可能不知道该先执行哪个。

我的处理方式是给 skill 分优先级和适用范围。在描述里写清楚“本 skill 应在格式化完成后执行”或者“本 skill 仅适用于 .tsx 文件”。另外，可以把相关的 skill 组织成一个工作流，用一个上层 skill 来编排执行顺序，而不是让它们各自为政。如果两个 skill 确实功能重叠，那就合并成一个，不要留着互相打架。

5.4 常见问题速查表

6. 把 skills 用好的几个底层习惯

6.1 像维护代码一样维护 skill

skill 不是写完就完了，它需要持续维护。我的做法是把 skill 当成项目代码的一部分，放在版本控制里，每次修改都记录变更原因。当团队规范更新时，同步更新对应的 skill；当发现某个 skill 经常出问题时，及时重构而不是将就。

另外，定期清理也很重要。我每季度会过一遍所有 skill，把过去三个月没触发过的删掉或者归档。skill 库不是越大越好，保持精简才能让每个 skill 都保持高质量。

6.2 从“写 skill”到“设计工作流”

单个 skill 解决的是单点问题，但真正提升效率的是把多个 skill 串成工作流。比如一个完整的前端开发流程可能包括：需求分析 skill、组件设计 skill、代码实现 skill、代码审查 skill、测试生成 skill、提交信息生成 skill。每个 skill 各司其职，按顺序执行，形成一条流水线。

设计工作流时要注意交接点。上一个 skill 的输出要能作为下一个 skill 的输入，格式要统一。比如代码审查 skill 输出的问题列表，要能被修复 skill 直接读取和处理。这需要在写 skill 时就考虑好数据格式和接口约定。

6.3 保持对工具变化的敏感

AI 编程工具迭代很快，skills 的机制、格式、触发逻辑都可能变。我踩过的最大的坑就是照着旧教程配置，结果新版本不兼容。所以建议关注你所使用工具的官方更新日志，每次大版本更新后，抽时间测试一下现有 skill 是否还能正常工作。

社区里的 skills 分享也值得关注，但要有判断力。别人分享的 skill 是基于他们的项目和工作流写的，直接拿来用往往水土不服。正确的做法是理解它的设计思路，然后根据自己的实际情况改写。抄思路，不抄内容，这是我用下来最稳的策略。

6.4 一个实际案例的完整复盘

最后分享一个我实际做的 skill 案例，把前面的要点串起来。背景是团队里经常需要把设计稿转成前端代码，每次都要跟 AI 反复交代设计规范、组件库用法、命名约定。于是我写了一个design-to-codeskill。

描述里写了“根据设计稿描述生成 React 组件代码，遵循团队组件库和命名规范”。适用场景限定为“当用户提供设计稿截图或描述并要求生成组件代码时”。步骤分五步：先识别设计稿中的组件类型和布局结构；然后映射到团队组件库中的对应组件；接着生成代码骨架，包括 imports、组件定义、props 类型；再填充样式，使用设计系统 token 而不是硬编码值；最后输出代码并附上使用的组件和 token 清单。约束包括“不生成测试代码”“如果设计稿中有组件库没有的元素，先询问而不是自行创造”“生成的代码必须通过 ESLint 检查”。

实际用下来，这个 skill 把设计稿转代码的时间从平均 40 分钟压缩到了 10 分钟左右，而且代码风格统一，审查成本大幅降低。当然也遇到过问题，比如设计稿里的间距值不在设计系统 token 里，AI 会卡住。后来在约束里加了一条“遇到无法映射的值时，使用最接近的 token 并标注差异”，问题就解决了。

这个案例说明，skill 的价值不在于写得多漂亮，而在于真正嵌入工作流、解决具体问题、并且能持续迭代。你不需要一开始就写得很完美，先跑起来，遇到问题再改，迭代几轮之后自然会稳定。

如果你还没开始用 skills，我的建议是从一个最小场景入手，比如“提交信息生成”或者“代码格式检查”，写一个最简单的版本，跑通整个流程，感受一下触发、执行、输出的完整链路。有了体感之后，再逐步扩展到更复杂的场景。这个过程本身也是对你工作流的一次梳理，哪些环节可以标准化、哪些环节需要人工判断，想清楚这些，比写多少个 skill 都重要。