企业官网建设流程全解析

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

很多人第一次听到 Skill 这个词，脑子里浮现的是游戏里的技能树，或者是某种需要长期训练才能掌握的硬本领。但在 AI 工具链的语境下，Skill 的含义要具体得多，也务实得多。它本质上是一份写给 AI 看的“操作手册”——用结构化的方式告诉 AI 在特定场景下应该怎么做、按什么顺序做、注意哪些坑。你可以把它理解成给 AI 装的一个“插件包”，但这个插件包不是代码，而是知识。

1.1 从“每次都要重新解释”到“一次写好反复用”

我先说一个几乎所有人都遇到过的场景。你让 AI 帮你写一份周报，第一次你得告诉它格式要求、语气偏好、需要包含哪些模块、数据从哪里来。第二次你再让它写，它又忘了，你还得重新说一遍。第三次、第四次，每次都在重复同样的解释工作。这种体验就像你招了一个新员工，但他每天早上来上班都会失忆，你得从头培训一遍。

Skill 要解决的就是这个问题。你把周报的格式规范、语气要求、数据来源、常见模板全部写进一个 Skill 文件里，之后每次让 AI 写周报，它自动读取这个文件，按照你定义好的流程执行。你不需要再重复解释，它也不会再忘记。这个逻辑放到任何重复性任务上都成立：代码审查、论文润色、数据清洗、会议纪要整理、甚至是帮你按照特定风格回复邮件。

1.2 Skill 和 Agent 的区别：一个是知识，一个是执行者

这是被问得最多的问题之一。很多人把 Skill 和 Agent 混为一谈，其实两者的定位完全不同。Agent 是一个能自主决策、调用工具、执行多步任务的智能体，它像是一个“员工”。而 Skill 是给这个员工看的“岗位操作手册”。Agent 负责决定“做什么”和“什么时候做”，Skill 负责告诉它“具体怎么做”。

举个例子。你有一个 Agent 负责帮你管理项目进度，它需要定期检查任务状态、发送提醒、更新文档。这些动作的触发时机和优先级由 Agent 自己判断。但“检查任务状态”这个动作具体要查哪些字段、“发送提醒”要用什么模板、“更新文档”要遵循什么格式，这些细节全部写在 Skill 里。Agent 是决策者，Skill 是知识库。没有 Skill 的 Agent 就像一个聪明但什么都不懂的新人，有 Skill 的 Agent 才是一个能直接上手的熟练工。

1.3 为什么现在 Skill 突然火起来了

Skill 这个概念并不是凭空冒出来的。它的流行和 AI 编程工具的普及直接相关。当越来越多的人开始用 Claude Code、Cursor 这类工具写代码时，大家发现一个问题：AI 写代码的能力很强，但它不了解你的项目规范、不知道你的代码风格、不清楚你的目录结构约定。每次生成代码都要手动调整，效率反而降低了。

Skill 机制的出现让这个问题有了系统性的解法。你把项目的编码规范、目录结构、常用命令、测试流程写成一个 Skill 文件，AI 在生成代码时自动参考这些信息，输出的结果就直接符合你的要求。这个思路一旦被验证有效，就迅速扩展到了编程之外的领域——写作、科研、数据分析、项目管理，凡是需要“按照特定规范重复执行”的场景，都可以用 Skill 来优化。

2. 一个 Skill 文件里到底写了什么

理解了 Skill 的定位之后，下一个问题自然是：它长什么样？怎么写？虽然不同平台和工具对 Skill 的具体格式要求可能有差异，但核心结构是相通的。一个完整的 Skill 文件通常包含几个关键部分：元信息、触发条件、执行步骤、注意事项、示例。

2.1 元信息：让 AI 知道这个 Skill 是干什么的

元信息是 Skill 文件的头部区域，用来说明这个 Skill 的名称、适用场景、版本等基础信息。这部分看起来简单，但写得好不好直接影响 AI 能不能在正确的时机调用它。名称要具体，不能太泛。“代码审查”就不如“Python 后端代码安全审查”来得明确。适用场景要写清楚什么情况下应该用这个 Skill，什么情况下不该用。

我见过很多人写 Skill 时忽略元信息，觉得这只是个“标题”不重要。实际使用下来，元信息写得好不好，直接决定了 AI 能不能在正确的场景下自动匹配到这个 Skill。如果你的 Skill 名称太模糊，AI 可能在不需要的时候调用它，或者在需要的时候反而没调用。这就像给文件起名字，叫“文档1”和叫“2024年Q3销售数据分析报告”，后者的可检索性明显更高。

2.2 触发条件：什么时候该用这个 Skill

触发条件是 Skill 设计中最需要动脑子的部分。你需要明确告诉 AI：当用户提出什么类型的请求时，应该加载这个 Skill。触发条件可以基于关键词、任务类型、文件类型、甚至是上下文中的特定模式。

写触发条件时有一个常见的误区：写得太窄或太宽。太窄了，AI 经常匹配不到，Skill 形同虚设。太宽了，AI 在不相关的场景也调用它，反而干扰正常输出。我的经验是，触发条件要覆盖核心场景，但不要试图覆盖所有边缘情况。宁可多写几个专门的 Skill，也不要写一个“万能 Skill”试图处理所有事情。

2.3 执行步骤：核心中的核心

执行步骤是 Skill 文件的主体，也是最能体现写作者经验水平的部分。这部分要像写菜谱一样，把每个步骤写清楚：先做什么、再做什么、每步的输入是什么、输出是什么、遇到分支情况怎么处理。

写执行步骤时，我建议遵循几个原则。第一，步骤要可执行，不能是“优化代码质量”这种模糊描述，而要具体到“检查是否存在未处理的异常”“确认所有数据库查询都有索引覆盖”。第二，步骤之间要有明确的顺序和依赖关系，让 AI 知道什么必须先做、什么可以并行。第三，对于关键步骤，要说明“为什么这样做”，这样 AI 在遇到变体情况时能做出合理判断，而不是死板地照搬。

2.4 注意事项和示例：让 Skill 真正好用

注意事项部分记录的是“踩过的坑”和“容易出错的地方”。比如“不要在没有确认的情况下删除文件”“生成 SQL 时注意转义特殊字符”“处理中文时注意编码格式”。这些内容看起来琐碎，但实际使用中能避免大量问题。

示例部分则是给 AI 提供“参考答案”。一个具体的输入输出示例，比一大段抽象描述更有效。我通常会在 Skill 里放两到三个典型示例，覆盖正常情况和边界情况。示例不需要很长，但要足够具体，让 AI 能理解你期望的输出格式和风格。

3. 去哪里找现成的 Skill

不是每个人都需要从零开始写 Skill。很多时候，你想要的功能已经有人写好了，直接拿来用就行。但“去哪里找”这个问题，确实让很多新手感到困惑。

3.1 官方仓库和社区市场

最直接的来源是各个平台的官方 Skill 仓库。Claude Code 有官方的 Skill 目录，Cursor 也有自己的插件市场。这些官方渠道的 Skill 通常质量有保障，更新也比较及时。缺点是数量有限，覆盖的场景不一定完全匹配你的需求。

社区市场是另一个重要来源。GitHub 上有大量个人开发者分享的 Skill 文件，覆盖了从编程到写作到数据分析的各个领域。搜索时可以用“awesome-skills”“skill-collection”这类关键词，能找到不少整理好的合集。不过社区来源的 Skill 质量参差不齐，使用前最好先读一遍内容，确认没有安全问题再加载。

3.2 从别人的项目里“偷师”

我个人的经验是，最好的 Skill 往往不是专门去找的，而是在阅读别人项目时顺手发现的。很多开源项目会在根目录放一个.skills文件夹或者SKILL.md文件，里面记录了这个项目的开发规范、常用命令、代码风格约定。这些内容本身就是高质量的 Skill 素材。

你可以在 GitHub 上搜索特定技术栈的项目，看看他们有没有把项目规范写成 Skill 文件。比如搜索“SKILL.md Python”或者“skills 前端开发”，能找到不少实际项目中的真实案例。这种从真实项目中提取的 Skill，往往比通用模板更实用，因为它们经过了实际使用的检验。

3.3 怎么判断一个 Skill 值不值得用

找到 Skill 之后，怎么判断它好不好用？我通常会看几个方面。第一，看元信息是否清晰，能不能一眼看出这个 Skill 的适用场景。第二，看执行步骤是否具体，有没有“正确的废话”。第三，看有没有示例，示例的质量如何。第四，看更新时间和使用反馈，太老的 Skill 可能已经不适配当前版本的工具了。

还有一个很重要的判断标准：这个 Skill 解决的问题是不是你真正遇到的问题。很多人看到“热门 Skill 推荐”就一股脑全装上，结果发现大部分都用不上，反而让 AI 的上下文变得混乱。我的建议是按需加载，只装当前项目真正需要的 Skill。

4. 自己动手写一个 Skill 的完整流程

当你找不到合适的现成 Skill，或者现有 Skill 不能完全满足需求时，就需要自己动手写了。写 Skill 这件事，门槛没有想象中那么高，但写好确实需要一些经验和技巧。

4.1 从“记录自己的操作流程”开始

写 Skill 最好的起点不是打开编辑器开始敲字，而是先观察自己平时是怎么做这件事的。比如你要写一个“代码审查 Skill”，先回想一下：你每次审查代码时，会按什么顺序看？先看目录结构还是先看核心逻辑？会重点检查哪些问题？有没有固定的检查清单？

把这些流程写下来，就是 Skill 的雏形。我习惯用手机备忘录或者纸质笔记本记录，因为写的时候不需要考虑格式，想到什么写什么。等流程记录得差不多了，再整理成结构化的 Skill 文件。这个“先记录后整理”的方法，比直接对着空白文件想要高效得多。

4.2 用 Skill Creator 工具加速开发

如果你用的是 Claude Code，它自带一个叫 Skill Creator 的功能，可以帮你快速生成 Skill 文件的框架。你只需要描述想要实现的功能，它会生成一个包含元信息、触发条件、执行步骤的模板，你在这个基础上修改和补充就行。

其他平台也有类似的辅助工具。比如有些社区开发的 Skill 生成器，可以通过问答的方式引导你一步步完成 Skill 的编写。这些工具不能替代你的思考，但能帮你省去搭建框架的时间，让你把精力集中在内容本身上。

4.3 迭代比一次性写完更重要

我见过很多人写 Skill 时追求“一次写完”，结果写出来的东西要么太理想化不实用，要么漏掉了关键细节。我的经验是：先写一个能用的版本，然后在实际使用中不断迭代。

第一版 Skill 不需要很完美，能把核心流程说清楚就行。用几次之后，你会发现哪些步骤 AI 理解不了、哪些地方容易出错、哪些场景没有覆盖到。根据这些反馈逐步补充和调整，通常迭代三到五次之后，Skill 的质量会有明显提升。这个过程和写文档、写教程是一样的，好内容都是改出来的。

4.4 一个实际案例：从零写一个“周报生成 Skill”

我拿周报生成这个场景来完整走一遍流程。首先明确需求：每周五下午，根据本周的 Git 提交记录和任务管理工具中的完成情况，生成一份格式固定的周报。

元信息部分写清楚：名称叫“周报自动生成”，适用场景是“每周五生成工作周报”，版本号从 1.0 开始。触发条件设置为：当用户提到“写周报”“生成周报”“本周总结”时加载。

执行步骤分五步。第一步，读取本周的 Git 提交记录，提取 commit message 中的关键信息。第二步，读取任务管理工具中本周完成的任务列表。第三步，按照“本周完成”“进行中”“下周计划”“风险与问题”四个模块组织内容。第四步，每个模块用简洁的条目式语言描述，避免大段文字。第五步，输出格式为 Markdown，标题用二级标题，条目用无序列表。

注意事项写三条：不要编造没有完成的任务；如果某项任务没有明确结果，标注“进行中”而不是“已完成”；周报语气保持客观，不要用“非常”“特别”这类主观修饰词。

示例部分放一个完整的周报样例，让 AI 知道最终输出应该长什么样。这个 Skill 写完之后，我实际用了两个月，中间调整了三次，现在基本能做到一键生成，只需要手动补充少量个性化内容。

5. 写 Skill 时最容易踩的几个坑

写了十几个 Skill 之后，我总结出一些反复出现的问题。这些坑看起来不大，但每一个都会显著影响 Skill 的实际效果。

5.1 把 Skill 写成“愿望清单”

这是新手最常犯的错误。写出来的 Skill 全是“要保证代码质量”“要输出高质量内容”“要注意用户体验”这类无法执行的描述。AI 看到这种 Skill 和没看到差不多，因为它不知道具体该做什么。

正确的做法是把每个要求都转化成可执行的动作。“保证代码质量”改成“检查所有函数是否有错误处理”“确认变量命名符合驼峰规范”“验证边界条件是否覆盖”。“输出高质量内容”改成“每个论点至少配一个具体案例”“段落长度控制在三到五行”“避免使用被动语态”。越具体，AI 执行起来越准确。

5.2 步骤之间缺少依赖关系

有些 Skill 的步骤写得很详细，但步骤之间是孤立的，没有说明先后顺序和依赖关系。AI 在执行时可能会跳过某些步骤，或者以错误的顺序执行。

解决这个问题的方法是在步骤描述中明确标注依赖关系。比如“在完成第一步的数据读取之后，再进行第二步的数据清洗”“第三步必须在第二步的输出基础上进行”。对于可以并行的步骤，也要明确说明“以下两步可以同时进行”。这些标注看起来啰嗦，但能大幅提升 AI 执行的准确率。

5.3 忽略异常情况的处理

大部分 Skill 只写了“正常流程”怎么做，没有考虑“如果出错了怎么办”。实际使用中，异常情况出现的频率远比想象中高：文件不存在、数据格式不对、网络请求失败、权限不足。

一个好的 Skill 应该包含基本的异常处理逻辑。比如“如果 Git 仓库不存在，提示用户先初始化仓库”“如果任务管理工具无法访问，跳过该步骤并记录警告”“如果输出格式不符合预期，回退到默认模板”。这些处理逻辑不需要很复杂，但能让 Skill 在非理想环境下也能正常工作。

5.4 示例太少或者太简单

示例是 Skill 中最容易被忽视的部分。很多人只放一个最简单的示例，甚至不放示例。结果 AI 对输出格式的理解完全靠猜，生成的内容和预期差距很大。

我的建议是至少放三个示例：一个最简单的正常情况、一个包含多个模块的复杂情况、一个边界情况。示例要完整，包含输入和输出。如果输出是代码，要包含完整的代码块；如果输出是文档，要包含完整的文档结构。示例越具体，AI 的输出越稳定。

6. 不同场景下的 Skill 设计思路

Skill 的设计没有万能公式，不同场景需要不同的思路。我挑几个典型场景，说说各自的设计要点。

6.1 编程开发类 Skill：规范先行

编程类 Skill 的核心是“规范”。你需要把项目的编码规范、目录结构、命名约定、测试要求全部写进去。这类 Skill 的触发条件通常和文件类型或操作类型相关，比如“当用户要求生成 Python 代码时”“当用户要求创建新组件时”。

执行步骤要包含：读取项目配置文件、检查现有代码风格、生成符合规范的代码、运行格式化工具、执行相关测试。注意事项要特别强调“不要引入项目中没有使用过的依赖”“不要修改无关文件”“生成的代码必须包含类型注解”。

6.2 写作类 Skill：风格和结构并重

写作类 Skill 需要同时定义“写什么”和“怎么写”。结构方面，明确文章需要包含哪些部分、每部分的顺序和篇幅。风格方面，定义语气、人称、句式、用词偏好。

我写过一个“技术博客 Skill”，里面定义了：开头用场景引入而不是定义解释、每个章节必须有具体案例、代码块必须标注语言类型、避免使用“通过”“随着”这类套话。这些规则写进去之后，AI 生成的初稿质量明显提升，后期修改的工作量减少了一半以上。

6.3 数据分析类 Skill：流程和校验是关键

数据分析类 Skill 的重点是流程的严谨性和结果的校验。执行步骤要包含：数据加载、数据清洗、异常值处理、分析执行、结果验证、可视化输出。每个步骤都要有明确的输入输出定义。

校验环节特别重要。我通常会在 Skill 里加入“检查数据行数是否在合理范围内”“确认关键字段没有空值”“验证计算结果和预期量级一致”这类校验步骤。这些检查能及时发现数据问题，避免基于错误数据得出结论。

6.4 科研辅助类 Skill：引用和逻辑是核心

科研场景对准确性和逻辑性的要求极高。科研类 Skill 需要特别强调：所有引用必须可追溯、论证过程必须完整、不能编造数据或文献、结论必须有证据支撑。

我见过有人用 AI 辅助写论文时，AI 编造了不存在的参考文献。这个问题可以通过 Skill 来规避：在 Skill 中明确要求“所有引用必须来自用户提供的文献列表”“如果找不到对应文献，标注‘待补充’而不是编造”“每个论点必须有至少一个引用支撑”。这些规则能有效降低 AI 产生幻觉的风险。

7. 让 Skill 真正融入日常工作流

写好了 Skill 只是第一步，让它真正融入日常工作流才能发挥价值。我分享几个实际使用中的经验。

7.1 从高频重复任务开始

不要一上来就给所有任务都写 Skill。先挑那些你每天或每周都要做、而且每次做法都差不多的任务。比如每天的代码提交检查、每周的周报生成、每月的项目进度汇总。这些任务写 Skill 的投入产出比最高。

低频任务或者每次做法都不一样的任务，写 Skill 的收益不大。因为 Skill 的价值在于“标准化重复流程”，如果流程本身就不固定，Skill 反而会成为束缚。

7.2 建立自己的 Skill 库

随着写的 Skill 越来越多，你需要一个地方来管理它们。我建议在本地建一个专门的目录，按场景分类存放。比如skills/development/放编程类，skills/writing/放写作类，skills/analysis/放分析类。

每个 Skill 文件命名要清晰，用英文小写加连字符，比如python-code-review.md、weekly-report.md。文件头部加上版本号和更新日期，方便追踪。如果 Skill 之间有依赖关系，在文件里注明。

7.3 定期回顾和清理

Skill 不是写完就一劳永逸的。工具在更新，项目在变化，你的需求也在变。我每个月会花半小时回顾一下现有的 Skill，看看哪些还在用、哪些已经过时、哪些需要更新。

过时的 Skill 要及时删除或归档，不要留在那里干扰 AI 的判断。需要更新的 Skill 要记录下需要改的地方，集中处理。这个维护工作看起来麻烦，但能保证你的 Skill 库始终处于可用状态。

7.4 和团队共享 Skill

如果你在团队中工作，Skill 的共享能带来更大的价值。把团队通用的规范写成 Skill，每个人都能用，新成员上手也更快。共享的方式可以是通过 Git 仓库管理，或者放在团队内部的文档平台上。

共享 Skill 时要注意版本管理。不同人可能对同一个 Skill 有不同的修改需求，需要有一个机制来合并和协调。我通常的做法是：核心规范由一个人维护，其他人可以提建议但不要直接改。这样能保证 Skill 的一致性。

8. 关于 Skill 的一些常见疑问

最后集中回答几个被问得比较多的问题。

8.1 Skill 文件应该放在哪里

不同工具的约定不一样。Claude Code 默认读取项目根目录下的.claude/skills/目录，也支持用户主目录下的全局 Skill。Cursor 有自己的配置目录。具体位置要看工具的文档。我的建议是：项目相关的 Skill 放在项目目录里，通用 Skill 放在全局目录里。这样既能保证项目独立性，又能复用通用能力。

8.2 一个 Skill 文件可以有多长

没有硬性限制，但实际使用中，太长的 Skill 会影响 AI 的加载速度和处理效果。我的经验是单个 Skill 文件控制在 2000 字以内，超过这个长度就考虑拆分成多个 Skill。拆分的原则是按功能模块拆，而不是按步骤拆。比如“代码审查”可以拆成“安全检查”“性能检查”“风格检查”三个独立 Skill。

8.3 Skill 和提示词有什么区别

提示词是你每次对话时输入的内容，Skill 是预先写好、可以反复加载的规范文件。提示词是“一次性”的，Skill 是“持久化”的。你可以把 Skill 理解成一种特殊的提示词，它的特殊之处在于：结构化、可复用、可版本管理、可共享。写 Skill 本质上就是在写一份高质量的、结构化的提示词。

8.4 不会写代码能写 Skill 吗

完全可以。Skill 文件本质上是结构化的文本，不需要编程基础。你只需要能把一件事的流程说清楚，就能写 Skill。我见过很多非技术背景的人写出了非常好用的 Skill，比如行政人员写的“会议纪要整理 Skill”、HR 写的“面试反馈汇总 Skill”、运营写的“活动复盘 Skill”。关键不在于技术能力，而在于你对业务流程的理解深度。

8.5 Skill 会不会让 AI 变得死板

这是一个合理的担心，但实际使用下来，好的 Skill 不会让 AI 死板，反而能让它在正确的框架内发挥更大的灵活性。因为 Skill 定义的是“必须遵守的底线”和“推荐遵循的流程”，而不是“唯一正确的答案”。AI 在执行 Skill 时，仍然可以根据具体情况做出判断和调整。真正让 AI 死板的是那些写得过于僵化、不留任何余地的 Skill，这是写作者的问题，不是 Skill 机制本身的问题。

8.6 怎么知道一个 Skill 有没有生效

最直接的方法是看 AI 的输出是否符合 Skill 中定义的规范。如果 Skill 要求“每个函数必须有文档字符串”，而 AI 生成的代码没有，说明 Skill 没有生效。这时候需要检查：Skill 文件是否放在了正确的目录、触发条件是否匹配、文件格式是否正确。有时候 AI 会部分执行 Skill 的内容，这时候需要检查 Skill 中是否有相互矛盾的指令。

8.7 Skill 需要定期更新吗

需要。工具版本更新、项目规范变化、个人偏好调整，都会导致原有 Skill 不再适用。我建议至少每季度检查一次，看看有没有需要更新的地方。如果发现某个 Skill 经常出问题，说明它需要重新设计，而不是小修小补。

8.8 多个 Skill 之间会冲突吗

有可能。如果两个 Skill 对同一件事给出了不同的指令，AI 可能会困惑。比如一个 Skill 说“代码注释用中文”，另一个说“代码注释用英文”，同时加载就会冲突。避免冲突的方法是：在写 Skill 时就明确它的适用范围，不要和其他 Skill 重叠。如果确实需要同时使用多个 Skill，要确保它们之间没有矛盾的指令。

8.9 怎么评估一个 Skill 的质量

我通常从几个维度评估：触发准确率（该调用的时候有没有调用）、执行完整度（定义的步骤有没有全部执行）、输出稳定性（多次执行结果是否一致）、维护成本（是否需要频繁修改）。这四个维度都表现好的 Skill，就是高质量的 Skill。

8.10 Skill 的未来会怎么发展

从目前的趋势看，Skill 正在从“个人工具”向“团队资产”演变。越来越多的团队开始把 Skill 作为知识管理的一部分，把老员工的经验沉淀成 Skill 文件，让新成员能快速上手。同时，Skill 的格式和标准也在逐步统一，未来可能会出现跨平台通用的 Skill 规范。对于个人来说，现在开始积累自己的 Skill 库，是在为未来的效率提升打基础。