企业官网建设流程全解析

1. 先搞清楚：官方库和私人文件夹，到底差在哪

这句话说出来可能有点得罪人，但我还是要说：Anthropic 官方库里的 skills，平均质量真的没有很多人想象中那么高。我自己前前后后把官方库翻过几遍，也在 Claude Code 里实际用了一段时间，结论是——它更像一个"入门演示集"，解决的是"让大家知道 skills 大概长什么样"这个层面的问题。真要放到自己的日常开发流里，那些官方技能往往有种"什么都沾一点，但什么都不够顶用"的感觉。

而我自己那个从零攒起来的私人 skills 文件夹，一共也就十来个技能，但它解决的都是我在真实项目里反复遇到的痛。比如我每天都要处理的前端页面复刻、接口联调时的数据结构分析、写单元测试时的边界场景枚举——这些活我用私人 skills 处理，效率比裸奔或者是硬套官方技能高出一大截。

为什么会这样？我琢磨了很久，最后想明白了一个很朴素的道理：**官方库是"给所有人用的"，而私人文件夹是"给我用的"。**这两个定位从根上就决定了它们的设计思路完全不一样。

1.1 官方库的天然短板

Anthropic 官方库的定位是覆盖尽可能多的通用场景，所以它的技能设计偏保守、偏通用，参数也往往很多，因为要照顾各种不同的用法。这就带来一个特别现实的问题：一个技能里面的 prompt 越长，模型被"带偏"的概率就越高。官方技能为了追求通用性，会把很多场景条件、分支逻辑都写进提示词里，结果就是真正执行的时候，模型经常该抓的重点没抓住，不该有的多余动作倒是一大堆。

我在官方库那段经历里踩过最典型的一个坑是：用官方那个 web 开发相关的技能去生成一个营销落地页。技能本身确实能跑起来，但生成的页面框架感特别重——很像一个"按照教程教的写法写出来的项目"，而不是一个老前端自然而然会写出来的东西。它缺少我对真实业务的理解，比如转化率优先的视觉层级、首屏加载性能的基本约束、还有那些只有踩过坑才知道要避免的布局陷阱。这些 "know-how" 不是一个官方通用技能能覆盖的，它只能靠你自己在日常开发里沉淀。

1.2 私人文件夹的核心优势——上下文即权力

再说回私人文件夹。这是我在实际使用中最强烈的一个感受：一个 skills 文件夹本质上就是一个"上下文资产的沉淀池"。你每往里面加一个技能，本质上是把你的某一部分经验、标准、偏好固化成了一段可复用的提示词资产。这跟写代码时沉淀工具函数是一样的逻辑——不要每次重新造轮子，而是把轮子存起来，下次直接用。

拿我最常用的几个私人技能来说，它们的写法跟官方库完全不同：

• 官方技能会写"请帮助用户完成 web 开发任务"这种高度抽象的描述。
• 我的私人技能会写"当用户要求把一个设计稿图片还原成前端页面时，先分析设计稿的布局结构——栅格、间距、色彩系统，再输出一个完整实现，并且默认使用我的技术栈和代码风格"。

这个差异在 AI 的世界里是决定性的。Claude 这类大模型的推理质量高度依赖 prompt 的上下文清晰度——越明确、越贴合具体场景的指示，生成质量越高。这跟人一样，你说"帮我处理一下图片"和"帮我把这张 1200 宽的产品主图压缩到 800 宽以内的 JPEG，保持背景透明"——后者得到的响应质量完全不一样。

所以在我看来，私人 skills 文件夹能"干过"官方库，靠的不是什么黑魔法，而是上下文密度和场景贴合度的降维打击。

2. 私人 skills 文件夹的架构与设计思路

说完了理念层面的东西，我们来点实际可操作的。很多人一开始搞 skills，容易掉进一个陷阱：拼命去看别人分享的 skills 清单，今天看到这个推荐就装一个，明天看到那个推荐就加一个，最后文件夹里堆了三四十个技能，真正常用的没几个，还占用了大量的上下文空间。

我自己的经验是：skills 文件夹应该遵循"小而精、按需沉淀"的原则。与其追求数量，不如认真打磨那几个真正高频使用的技能。下面我详细拆解一下我自己这个文件夹的架构方式，你可以直接参考。

2.1 目录结构设计——按使用频率与场景分层

我把私人 skills 文件夹分成了三个层级，这个分法是从实际使用频率出发的：

第一层：通用但高频。这一类是每天都会用的，比如"代码审查"、"单元测试生成"、"git commit 信息规范化"。它们的特征是跨项目复用，跟具体技术栈没什么关系。放在最外层，方便直接加载。

第二层：特定技术栈类。这一类跟着项目走，比如"React 组件开发"、"Tailwind 样式调试"、"Python 数据处理"。这类技能我会写得更具体，直接把我惯用的技术方案、依赖库、代码组织风格写进去，所以它们特别适合复用。

第三层：任务性一次性。比如"把设计稿转成前端页面"、"分析这段 JSON 数据并生成接口文档"。这类技能往往跟某个具体项目绑定，任务做完之后过一段可能就失效了。所以我一般会为它们单独开一个projects子目录，避免污染主目录。

三层之间的转移原则也很简单：一个任务类技能如果做完了第二次、第三次，说明它其实是高频任务，那就升级到技术栈类；如果一个技术栈类技能连续两个月没碰过，果断删掉或者归档。这个原则保证我的文件夹永远保持精简，不会沦为"收藏夹吃灰"。

2.2 命名规范与元数据——别让 AI 看不懂你的技能

skills 文件夹的第二个关键点在于命名和元数据。我见过太多人把技能文件命名为my_skill.md或者test.md，这种名字在 AI 读取的时候基本就是灾难。因为它无法让模型从文件名里推断出这个技能是干什么的，进而导致加载判断出错——要么该用的技能没被加载，要么不该用的技能反而被激活了。

我采用的命名规范是"动词 + 对象 + 场景"：

generate_unit_test.md review_pr_code.md convert_design_to_frontend.md debug_tailwind_layout.md

这种命名方式的优势在于：当模型扫描文件夹时，它能在几十个文件里快速找到与当前任务匹配的技能。而且文件名本身就像是技能的"标题"，即使没有打开正文，模型也能大致推断出这个技能的适用范围。

再来说元数据。每一个技能文件的头部，我都会写清楚：

• name: 技能名称（简短）
• description: 一句话描述，包含触发条件和适用场景
• when_to_use: 明确告诉模型什么情况下使用这个技能
• when_not_to_use: 明确告诉模型什么情况下不要用这个技能

这个when_not_to_use是我踩了很多坑之后才加上的。一开始我不写这个字段，结果经常出现模型在错误的任务上套用了技能——比如明明是让我写一个移动端的适配方案，结果模型却加载了"React 组件开发"的技能，输出了桌面版的布局代码。加了when_not_to_use之后，这个误触发的情况大大减少。

2.3 技术栈映射表——让技能与真实项目精准对接

这个是我私人文件夹里比较特殊的一个设计，我觉得非常有价值。我会在 skills 文件夹的根目录放一个stack-map.md文件，里面记录了我常用的技术栈对应关系：

# 技术栈映射表 ## 前端 - 框架: Vue 3 + TypeScript + Vite - UI: Naive UI - 样式: TailwindCSS + CSS Modules - 状态管理: Pinia - 请求库: Axios - 路由: Vue Router ## 后端 - 语言: Node.js (TypeScript) - 框架: NestJS - ORM: Prisma - 数据库: PostgreSQL - 缓存: Redis ## 测试 - 框架: Vitest - 断言: Jest DOM - 端到端: Playwright

这个文件的妙处在于：它是我所有私人技能的"基础设施"。每一个技能在执行的时候，都会读取这个文件来校准自己的输出风格。比如generate_unit_test.md这个技能，它会先读取 stack-map，知道项目是用 Vitest 而不是 Jest，然后生成的测试代码就直接对标 Vitest 的写法，不需要我每次在 prompt 里手动指定。这个体验一旦适应了，真的回不去官方库那种"什么都要问一遍"的状态。

3. 手工打磨核心技能的完整过程

思路讲完了，下面我以一个具体的案例完整演示一下：我是怎么从零手工打磨一个能直接提升开发效率的技能的。这个例子是"把设计稿还原成前端页面"的技能，也就是热搜词里提到的"图片还原设计稿给前端开发"。

这个技能的产生背景很直接——我经常需要把产品经理或者设计师给的设计稿图片还原成可用的前端页面。以前没有技能的时候，我需要做一大堆操作：先把图片下载下来、肉眼分析布局结构、构思组件拆分方案、最后再开始写代码。这个过程既慢又容易出错，且每次都是重复劳动。所以后来我决定把它固化成技能。

3.1 挑选痛点场景——先问自己三个问题

并不是所有任务都值得做成 skill。在动手之前，我会先问自己三个问题：

1. 这个任务的频率够不够高？如果一个月才做一次，做成 skill 的性价比不高。
2. 这个任务的标准化程度够不够高？如果每次的做法都完全不一样，那 skill 只能提供一个非常泛化的框架，帮助有限。
3. 这个任务能不能明确描述？如果你自己都说不清"怎么做好这件事"，那也别指望能用一段 prompt 把它固化下来。

设计稿还原这个任务，三个问题的答案都是肯定的：频率高、标准化程度高（都是"从图到代码"）、而且我很清楚一个好的还原应该有哪些步骤。所以它特别适合做成 skill。

3.2 编写 SKILL.md 的核心要素——把隐形经验显性化

确定了场景之后，下一步就是真正的编写过程。这是一件充满了"经验显性化"微妙之处的工作。我自己习惯用的模板结构大概是这样的：

--- name: convert_design_to_frontend description: 将设计稿图片转换成高质量的前端页面实现，适配桌面端和移动端。 when_to_use: 用户提供设计稿图片（PNG、JPG、Figma导出图等）并要求实现为页面时。 when_not_to_use: 用户只是要求修改现有页面的某个局部样式，不需要从零实现。 --- # 设计稿还原工具 ## 1. 分析阶段 - 识别设计稿的**整体布局结构**：是单栏还是多栏？有没有侧边栏？内容区域如何划分？ - 提取设计稿的**色彩系统**：背景色、文字色、主色、辅助色，整理成 CSS 变量。 - 提取设计稿的**字体与字号**：标题、正文、辅助文字的字体族、字号、字重。 - 提取设计稿的**间距规则**：观察不同元素之间的距离规律，推断栅格系统。 ## 2. 组件拆分阶段 - 将页面拆解为组件树结构，标注每个组件的职责与数据来源。 - 标识出可复用的公共组件（如按钮、卡片、输入框）。 - 识别出需要响应式处理的断点位置。 ## 3. 实现阶段 - 读取根目录的 stack-map.md，按照技术栈偏好生成代码。 - 样式方案优先使用 CSS 变量统一管理颜色与间距。 - 布局实现优先使用 Flexbox 或 Grid，减少使用绝对定位。 - 实现完成后，检查边框圆角、阴影、渐变等视觉细节是否与设计稿一致。 ## 4. 自我检查清单 - [ ] 所有颜色值是否已提取为 CSS 变量 - [ ] 页面在 320px、768px、1440px 宽度下是否正常显示 - [ ] 字体加载是否使用了合适的 fallback - [ ] 是否存在无用的重复样式代码

这里有一个很重要的创作原则：不要只写"做什么"，要写"怎么做"和"按什么标准做"。官方的很多技能恰恰败在这一环——它们会告诉你"生成一个页面"，但不会告诉你"应该在分析布局之前先提取色彩系统"这种具体的执行顺序。而正是这些执行顺序和执行标准，才是一个技能真正有价值的核心。

3.3 写一个好的 prompt 模板——把经验融入模板

技能里除了步骤之外，还需要一个 prompt 模板。这个模板是给模型在真正执行任务时做参照的。我的经验是，模板里面最好预填一些"好的做法"提示词，让模型在高频场景下直接走正确的路径。

例如，在设计稿还原技能的 prompt 模板里，我会写：

注意：在分析设计稿时，重点关注对齐关系和间距规律，这两者是还原度的核心。如果设计稿中含有交互态（如 hover、active、focus），必须在实现中完整还原。页面性能方面，首屏图片需要加上 loading 属性，非首屏图片要使用懒加载。

这种模板的价值在于：它把那些"你以为模型应该知道，但它其实不知道"的东西显式写了出来。比如"间距规律"——一个没受过训练的大模型，看到设计稿之后大概率会照着像素值一比一还原，但那样做出来的页面往往非常古怪，因为真实的间距是有节奏和规律的。你在模板里点明这一点，模型输出质量会瞬间上一个台阶。

3.4 迭代与测试——技能是"活"的，不是"死"的

技能写完了并不代表工作结束，真正的打磨才开始。我自己的习惯是：每个新技能在第一个月内至少迭代三到五轮。每一次实际使用后，我都会回到 SKILL.md 里去修补那些"模型没有按预期执行"的环节。

具体怎么发现哪里需要修补？我的方法特别朴素：就是每次用完之后回看一次生成的代码或结果，凡是发现有不够满意的地方，就倒推"如果我在技能里多写一句什么样的提示词，这次结果是不是就能更好？"如果是，那就把这一句加进 SKILL.md。这样反复迭代之后，技能的质量会越来越稳定，最终进入"输入即输出最佳结果"的良性状态。

举个真实的例子。第一版设计稿还原技能跑出来时，我发现模型总是把字体大小直接写成设计稿上的像素值，而没有考虑不同屏幕的缩放。于是我在技能实现阶段加了一句"字号大小建议使用 clamp() 函数实现响应式缩放"。第二版跑出来就好多了。这个"加一句"的过程，就是技能质量不断爬升的引擎。

4. 常见问题与排查技巧实录

这节写给那些已经动手或者准备动手搞自己 skills 文件夹的朋友。下面这些问题，是我在过去几个月的实操中真实踩过的坑，每条都有具体的排查思路和解决方案。

4.1 技能生效不稳定：同一个技能有时灵有时不灵

这是最初级的坑，也是最让人头大的。明明同一个技能同一个任务，有时候效果惊人，有时候乱七八糟。排查下来，你会发现问题大概率不出在技能文件本身，而在于触发条件写得不够清晰。

模型加载技能的逻辑是：根据用户描述与技能 description 的语义匹配度决定是否激活。如果你的 description 写得太宽泛（比如"帮助用户进行前端开发"），那么模型在遇到各种看起来沾边但不尽相同的任务时都可能误触发，也可能因为描述不够具体而错过触发。解决方案是：把 description 写得更精确，同时配合 when_to_use 和 when_not_to_use 双向校准。

4.2 上下文膨胀：技能加载太多，反而拖慢速度

这是"技能爱好者"最容易犯的毛病。技能越多，每次会话要携带的基础上下文就越多，这带来的直接后果是：模型响应变慢，而且因为上下文里塞了太多无关技能的描述，推理质量还会下降。

我自己的解决方案是：把 skills 分成"默认加载"和"按需加载"两组。默认加载的只有三四个——那些我每个任务都会用到的基础技能。其余的一律不写进默认加载列表，而是在真正需要的时候通过明确的指令让模型去读取相应的技能文件。这样既保证了高频技能的稳定生效，又避免了上下文被无谓的膨胀拖垮。

4.3 技术栈冲突：技能按自己的偏好写，跟项目实际不符

这个问题在我早期也踩过。比如我做generate_unit_test技能的时候，一开始直接用 Jest 写模板。结果后来接了一个用 Vitest 的项目，生成的测试代码就全废了。排查发现，技能里写死了 Jest 的接口，而项目实际用的是 Vitest。

后来我引入了前面说的 stack-map.md，把技术栈从技能里解耦出来。技能模板统一使用"按 stack-map 读取项目技术栈并生成对应代码"的占位逻辑。这样同一个技能就能适配不同的项目，通用性大幅提升。

4.4 技能文件太长，系统反而消化不良

这是很多人容易忽略的一个点。技能文件不是越长越好。长度越长，模型在处理时消耗的注意力就越多，反而可能让核心指令的执行效果变弱。我个人的经验标准是：一个技能文件的正文最好控制在 300 到 600 行之间。超过这个范围，要么说明你试图用一个技能覆盖了太多场景（应该拆分），要么说明你写了太多冗余的解释（应该精简）。

真正核心的执行指令应该集中在前面 100 行内，后面的部分可以作为参考示例、边界情况说明等辅助信息，这样既不影响核心指令的注意力，又能给模型提供足够的背景支持。

4.5 版本管理与同步：私人文件夹不是"一次写完就完事"

最后一条是关于工程化管理的。技能文件说到底也是代码，是代码就应该纳入版本管理。我自己是把整个文件夹放在 Git 仓库里管理的，每次修改都走一次 commit。这样做的直接好处是：当某一次修改让技能质量不升反降的时候，我能随时回退到前一个可用版本。

另外，我还会在每次大幅修改之后写一个简短的 changelog，记录这次改了什么、为什么改。这习惯听起来有点"过度工程"，但当你某天突然发现自己把一个本来好用的技能改废了、却忘了之前是怎么写的时，你就知道这个习惯有多救命了。

5. 扩展思路：从私人文件夹到"团队共享技能库"

吃完自己的螃蟹之后，我自然而然想到了下一步：既然私人 skills 能秒杀官方库，那如果我把公司团队里所有前端工程师的私人技能聚合起来，做一个"团队共享技能库"，是不是效果也会很好？

这部分我确实实践过一阵子，进展和踩坑都有，这里分享一些观察。

5.1 团队技能库与个人技能库的核心差异

个人技能库的特点是"为自己量身定制"，而团队技能库的难点在于"每个人的工作习惯和偏好都不一样"。如果直接拿某一个人的私人技能去给整个团队共用，效果往往会打折扣。因为你觉得重要的点，别人可能完全无感；你惯用的代码风格，别人可能觉得别扭。

所以团队技能库更适合的形式是：一个"公共基础层"加上每个人自己的"私有个性层"。公共基础层里放的是团队统一的标准——比如代码风格规范、提交信息规范、代码审查清单。私有个性层里放的是个人的偏好和技巧。模型在执行任务时，先加载公共基础层，再根据当前使用者的身份叠加私有个性层。这样既能保证团队标准的统一，又不牺牲个人效率的灵活性。

5.2 团队技能库建设的三个关键动作

如果你想在团队里搞技能库，我建议先做这三件事：

第一，建立一个"技能评审"机制。每个技能在合并进公共层之前，必须经过至少两个人的实际试用和评审，把"我觉得好用"变成"我们觉得好用"。这个过程能过滤掉大量个人风格的噪音。

第二，明确技能的更新责任人。没有责任人的技能库，三个月后大概率就变成一堆没人维护的死文件。每一个核心技能都得有明确的 owner，负责定期维护、问题修复、版本更新。

第三，周期性地做一次技能清理。每两个月检查一次所有技能的"激活率"——哪些技能一直在被使用，哪些自从加进来就没人碰过。激活率为零的技能直接删掉或归档，绝不手软。这跟代码库里的死代码清理是一个道理，清理过后整个库的质量和效率都会有明显提升。

最后分享一个小技巧

我个人在实际操作中体会最深的一点：skills 文件夹不是用来收藏的，用来迭代才有价值。技能的价值不在于创建那一刻的完美，而在于每一次使用之后你怎么修补它。我把这个当作副产品来理解——就像写代码里最重要的不是代码本身，而是你从每次调试里学到的东西。Skills 的迭代过程，本质上就是你把自己对 AI 协作的理解不断地显性化、固化下来的过程。

所以如果你也想开始建设自己的 skills 文件夹，我的建议非常简单：别等完美，先从一个你明天就会用到的任务开始，写一个粗糙但能用的版本，然后实际用起来，边用边改。十来个这样的迭代下来，你再回头用官方库，会有种"从自己家精致的厨房走进大食堂"的感觉——功能都有，但味道终究差了那么点意思。

祝大家都能折腾出属于自己的那个"碾压官方库"的私人文件夹。