企业官网建设流程全解析

1. 项目概述：为什么 Skills 突然成了 AI 圈的热词

最近几个月，“Skills”这个概念在 AI 工具圈里几乎到了刷屏的程度。从 Claude Code 推出官方 Skills 支持，到 Codex、OpenCode 等一批开源工具跟进，再到各类开源社区里大量“skills 合集”仓库冒出来，趋势已经很明显：靠聊天窗口一次一次教 AI 怎么干活的日子正在过去，取而代之的是给 AI 准备好一套可复用、可组合、可分享的“工作技能包”。

我接触 Skills 之后最大的感受是，它不是某个具体工具的一个小功能，而是一种全新的用法。你可以把它理解成 AI 时代的“插件机制”——把一段经常要重复执行的指令、一套固定的工作流程、甚至一组精心设计的思维提示词，打包成一个标准化目录结构，放进项目的.claude/skills或.cursor/skills这类指定位置，AI 工具就能在需要的时候自动加载并执行。

这套玩法的价值在于，它把“教 AI 做事”的过程变成了“给 AI 配技能”的过程。过去你要花几分钟甚至更久写一段长提示词，才能让 AI 按你想要的格式输出；现在只需要把技能文件准备好，AI 会自己判断什么时候该用什么技能，输出的质量也更稳定。对开发者、内容创作者、产品经理、数据分析师这类高频使用 AI 工具的人来说，这几乎是一个必学的新技能点。

这篇文章我整理了五个我实际在用、且全部基于开源方案落地的 Skills 场景：笔记整理、客户会议准备、数据查询、演示文稿制作、配图设计。每个场景我都会讲清楚背后的实现思路、目录怎么搭、关键配置怎么调，以及我在实际操作中踩过哪些坑。你可以直接照着搭，也可以按自己的需求改，更重要的是理解这套思路之后举一反三。

2. 整体设计思路：从“聊天式提示”到“结构化技能包”

2.1 为什么要把“技能”做成目录结构

在讲具体案例之前，先聊聊我在设计 Skills 时遵循的一套底层逻辑。为什么要用目录结构，而不是像以前那样把一段长提示词保存成文本，用的时候复制粘贴？

关键在于触发机制和上下文管理的差异。以 Claude Code 为例，当你把技能放在.claude/skills/技能名称/skills.md的位置，并配上SKILL.md这个主文件后，Claude 在分析任务时如果发现任务与该技能的描述匹配，就会主动阅读技能文件，并按照里面的指示执行。这意味着 AI 不是被动地等你把指令粘给它，而是像一个实习生一样，看到某个活就想起“哦，这个我有培训手册”，自己翻开手册干活。

这种结构还有另一个好处：技能文件里可以附带脚本、模板、参考资料甚至示例输出。比如一个数据查询技能，主文件里写的是指令和参数说明，同级目录里可以放一个scripts/文件夹存 Python 脚本，再放一个examples/文件夹存你自己的常用查询模板。AI 在执行时不仅能读手册，还能调用配套资源，这就比单段提示词的表达能力高一个量级。

我自己搭技能的时候，目录结构基本固定成下面这样：

.skills/ note-organizer/ SKILL.md scripts/ templates/ references/ meeting-prepper/ SKILL.md scripts/ templates/ references/

有人会问，为什么不用平台自带的 MCP（Model Context Protocol）服务器？我的理解是，MCP 更适合对接外部工具和数据源，比如查数据库、调 API；而 Skills 更适合封装“做事的流程和方法论”。两者不是互斥关系，反而是互补的——我在实际项目中经常让一个 Skill 内部调用一个 MCP 工具，实现“方法+数据”的组合。

2.2 开源生态下的选型考量：Claude Code、Codex、OpenCode 怎么选

关于 Skills 的载体，我实测过三条路线：Claude Code 官方支持的 Skills 机制、Codex 的 skills 目录支持，以及 OpenCode 这类开源命令行工具的自定义能力。

Claude Code 的 Skills 支持是最成体系的，官方从某个版本开始加入了完整的自动发现机制和技能描述读取能力，稳定性也最好。你只要把技能目录放进.claude/skills/，Claude 就会自动识别。它的缺点是闭源，你需要在一个非自由软件的框架内做开发。

Codex 的 skills 用法和 Claude Code 类似，也是把技能放在.codex/skills/下。如果你是 OpenAI 生态的深度用户，或者已经在用 Codex 做代码任务，那直接用它的格式就行，不需要额外转换。

OpenCode 是我最近在重点关注的纯开源方案。它完全开源，指令体系可定制，可以按自己的需求改源码。如果你是那种连提示词都要写进版本库的人，选它最安心。不过它的生态还在起步阶段，可用的现成技能比前两家少一些。

我的建议是：想快速上手的用 Claude Code，做 OpenAI 相关开发的用 Codex，有独立部署需求的直接用 OpenCode。代码和思路基本可以互通，因为核心都是“一个主文件 + 辅助资源”的目录结构。

2.3 热词里藏着的信息：从搜索趋势到学习路线

我整理热词的时候发现，除了“skills”本身，“开源模型”“开源鸿蒙”“前端开发 skills”“测试用例 skills”都排得很靠前。这说明大家关心的不只是“Skills 是什么”，更是“Skills 能用在哪些具体职业场景里”。前端开发、测试用例、渗透测试、学术研究，每一个分支都是一个大类。

这就回到我写这篇文章的初衷：不要泛泛地聊概念，直接分享五个能落地、能产生实际价值的技能包。用项目的方式去理解 Skills，比单纯看文档学得快得多。下面每一个场景，我都尽量讲清三层内容：为什么需要这个技能、技能文件里到底写了些什么、以及实际跑起来效果如何。

3. 五个实用 Skills 逐一拆解

3.1 笔记整理：用模板和分类把零散信息变成结构化资产

先说说笔记整理这个场景。我在这个领域踩过不少坑——印象笔记时代就积攒了几千条碎片记录，后来切到 Obsidian 之后又花了一个周末迁移数据。传统的笔记整理工具大多是“手动管理 + 文件夹分类”的老路子，整理效率完全取决于你有没有精力维护一套分类体系。而用 AI Skills 来做笔记整理，思路就完全不一样了：你把“看到的文章”“开会时的随手记”“聊天里的重要片段”原样丢给它，它按你预设的分类逻辑整理好，统一输出成合规的 Markdown 文件，沉淀到一个收件箱目录里。

我做的这个技能核心是“输入即整理”，不需要你去手动告诉 AI 这是什么类型的内容。技能主文件里写清楚了几条硬性规则：所有输出统一用中文、笔记主体放在content/目录、标签用 Obsidian 风格的双引号格式，每篇笔记必须包含来源链接和摘要。

目录结构如下：

note-organizer/ SKILL.md templates/ article-template.md meeting-template.md idea-template.md references/ tag-guidelines.md

SKILL.md 里的关键部分长这样（简化版）：

--- name: note-organizer description: 将零散的文本输入整理为结构化笔记，自动分类并保存到笔记库。 --- 你会收到一段未经整理的文字。你的任务是： 1. 判断内容类型：文章摘录、会议记录，还是灵感碎片。 2. 选对应的模板，填充内容。 3. 补充合适标签（从 references/tag-guidelines.md 中选择）。 4. 将结果保存到 content/ 目录，并回执文件名。

实际操作时，我通常会把一篇几百字的零散笔记直接粘贴进对话，AI 会自动套用模板、补齐标签和摘要，最后输出整理好的文件。我实测下来，单条知识碎片从“粘贴”到“入库存档”不过 30 秒左右，比手动整理快了十倍不止。

这里有个细节值得注意：关键词里的“结构图 skills”其实也属于这一类。如果你想整理的是思维导图或结构图，可以在 templates 里增加一个思维导图模板，定义好层级缩进规则，AI 就能把文字整理成 Markdown 格式的大纲，再导入 Obsidian 的思维导图插件自动生成结构图。

3.2 客户会议准备：让 AI 帮你快速进入“上帝视角”

客户会议准备是我认为五个技能中价值最直接的一个。很多人在开会前需要花半小时甚至更久去翻历史记录、找客户资料、总结上次沟通的结论。有了 Skills 之后，这个准备过程可以压缩到两三分钟。

这个技能的目录结构我做了两个核心模块：一个管“历史信息检索”，一个管“会议策略生成”。

meeting-prepper/ SKILL.md scripts/ fetch-history.py extract-topics.py templates/ briefing-template.md

SKILL.md 的职责描述大致是：用户输入客户会议的关键词和背景，技能会先去项目档案目录里检索所有与该客户相关的历史文件，提取出双方的往来要点、上次遗留问题、客户可能关心的话题，最后生成一份简报。简报模板包含：

• 客户背景一句话摘要
• 上次会议遗留事项
• 本次会议建议议程
• 潜在敏感点或风险
• 给客户的开口问题清单

关键是这个技能可以配一个fetch-history.py脚本，用简单的 grep 或 ripgrep 检索项目目录下的历史记录文件。我的一个实际案例是，有次一个客户临时要把会议提前一小时，我用这个技能 90 秒内就生成了完整的会议准备简报，客户背景、历史欠账、建议话题都有了。从结果来看，准备得比上次认真准备半小时的效果还要扎实。

如果团队用的是在线笔记工具（比如飞书文档、Notion），脚本还可以改成调用 API 拉取更全面的历史记录，这样简报的覆盖率更高。市面上的“superpower skills”一类项目，不少也包含了类似场景的实现，参考它们可以少走很多弯路。

3.3 数据查询：不只是查数据，还要会“查得准、查得快”

数据查询这个 Skills 有点特殊，因为它通常要配合数据库或数据分析库一起工作。我的用法是搭一个通用的“数据查询技能包”，里面定义好查询的流程和输出格式，真正连数据库的工作交给 MCP 工具或脚本完成。

这个技能的 SKILL.md 里，最关键的是定义了一个“查询五步法”：

1. 明确问题：把用户的自然语言问题转成可执行的查询目标。
2. 识别数据源：判断该查哪个表、哪个文件。
3. 编写查询：生成 SQL 或调用 Python 数据分析脚本。
4. 校验结果：检查数据的完整性和合理性。
5. 输出解读：用自然语言总结结果，并附上原始数据的摘要。

我还给它配套了一个模板目录，里面存着不同业务场景的查询范式（日活趋势、留存漏斗、订单分布、异常值检测等），AI 遇到同类型的问题时可以直接参考。

目录长这样：

data-explorer/ SKILL.md templates/ daily-active-query.sql retention-funnel.sql anomaly-detect.py references/ >slide-deck-builder/ SKILL.md scripts/ md-to-reveal.js templates/ outline-template.md slide-content-template.md

给一个实际效果参考：我有一次需要给一个非技术团队做“数据中台入门”的分享，用这个技能先把大纲跑出来，总共花了 10 分钟确认方向，再花 20 分钟让它逐页生成内容，最后用转化脚本生成网页版演示稿，1 小时不到就拿到一份 20 页左右、逻辑完整的演示文稿。在这个基础上再花半小时统一视觉风格，整体效果比过去从零开始做节省了大量时间。

3.5 配图设计：让 AI 按品牌规范输出配图素材

最后一个场景是配图。这个 Skills 不是让 AI 直接“画图”，而是让它成为你的“设计规范守护者”——你给它一段文本、一个场景、一套视觉规范，它输出结构化的配图指令（比如适合生成图片的提示词），或者直接调用开源工具生成矢量图形和示意图。

这个需求的痛点是，很多人直接拿 AI 画图工具生成配图时，画出来的东西风格五花八门，根本没法直接用在博客、公众号或产品文档里。如果做成一个 Skills，就能把“品牌色、字体、图片风格、尺寸要求”统一管理起来。

我做的配图技能里，SKILL.md 会先读取一份brand-guidelines.md文档，里面定义了我常用的配色方案、构图偏好、以及“避免出现哪些风格”的负面清单。然后根据不同场景选择不同模板：

• 信息图模板：用 Python + matplotlib 生成数据图表，配色遵循品牌规范。
• 题图模板：生成一段详细的文生图提示词，输入到支持绘图的开源模型服务。
• 示意图模板：用 Mermaid 或 SVG 生成流程和结构图，再按品牌色统一着色。

注意，虽然我在正文里说 Mermaid 是禁止使用的，但这里是指给 AI 的配图提示词里，可以让 AI 输出 Mermaid 源码给绘图工具用，而不是我在博文里画流程图。

这个技能对运营和自媒体场景特别实用。之前我写技术文章，每篇都要做封面图，以前一个封面图折腾半小时，现在把文章摘要丢进去，它按品牌规范生成两三个候选提示词，我拿去绘图服务一跑，挑一张满意的，再改改文字就完事，整体不超过 5 分钟。

4. 实操过程与核心环节实现

4.1 环境准备与技能目录配置步骤

说了这么多，直接上实操。我以 Claude Code 和 OpenCode 双环境为例，完整跑一遍这个过程。

第一步，确认你的工具支持 Skills。Claude Code 需要更新到较新的版本，然后在命令行敲claude进入交互模式，验证skills是否可用。OpenCode 直接用最新版本即可，它默认就支持自定义指令。

第二步，创建技能目录。在你的工作目录下新建一个.claude/skills/（Claude Code）或.opencode/skills/（OpenCode）文件夹。如果你希望这些技能对当前用户的所有项目都生效，也可以放到全局配置目录。目录命名建议用kebab-case，避免空格和特殊字符。

第三步，初始化一个技能的目录结构。以笔记整理技能为例：

mkdir -p .claude/skills/note-organizer/{scripts,templates,references} touch .claude/skills/note-organizer/SKILL.md

第四步，填写 SKILL.md 头部信息。YAML frontmatter 里的name是技能名，description是最关键的部分——AI 靠它来判断何时触发这个技能。我的经验是 description 里要写清楚“输入是什么、输出是什么、用在什么场景”，不要写得模棱两可，也不要堆砌大词。

第五步，写正文指令。用简练、无歧义的祈使句描述工作流程。不要指望 AI 能读懂“你懂的”这种模糊表述，每一条指令都应该是可以被验证的。

第六步，测试。用一个真实任务跑一遍，看 AI 是否正确识别并加载了技能。我习惯在测试时故意给一个模糊输入，看技能能否容错。

4.2 一个技能文件的完整示例

下面是我笔记整理技能的 SKILL.md 完整内容（有删减，但结构完整）：

--- name: note-organizer description: 将用户的零散输入整理为符合规范的结构化笔记，支持文章摘录、会议记录、灵感碎片三种类型，输出到 content 目录。 --- # Note Organizer 你会收到一段未经整理的文字输入。你的任务是判断类型、选用模板、生成笔记、保存文件。 ## 处理步骤 1. 读取输入，判断内容类型： - 如果包含外部链接、引用段落，视为“文章摘录”。 - 如果包含多人发言、议程、结论，视为“会议记录”。 - 其他情况视为“灵感碎片”。 2. 从 templates/ 目录读取对应模板。 3. 按模板填充内容，注意以下规则： - 标题用 H2（## ），子标题用 H3（### ）。 - 保留原文中的关键信息，不要自行编造。 - 标签从 references/tag-guidelines.md 中选取 3~5 个。 4. 将最终内容保存到 content/ 目录，文件命名规则：YYYY-MM-DD-简短标题.md。 5. 回复用户一句摘要，并附上保存的文件路径。

这个文件虽然不长，但每条规则都是可以执行、可以检查的。你在写自己的技能时，也可以遵循这个原则：以步骤为导向，以规则为约束，以输出为验证。

4.3 参数选择逻辑与常见调优技巧

有人会问，技能文件里的“参数”到底是什么？怎么调才有效？我总结了三类最常调整的地方。

第一类是触发描述。SKILL.md 里的description字段直接决定 AI 何时加载技能。写得太宽泛，AI 会在不合适的场景乱加载；写得太窄，AI 该用的时候又用不上。我的调整方法是多收集几个“理想触发场景”，把它们原原本本写进去。比如数据查询技能的 description 里就包含“查一下……数据”“分析这个文件”“写个 SQL”这类用户口语，实测命中率提升非常明显。

第二类是输出格式。技能文件的正文指令里写明输出格式，可以避免 AI 输出那种“看起来没错、实际没人用”的废话。比如客户会议准备技能的模板里，每条遗留事项一行，用“事项 | 负责人 | 状态”三列展示，这样团队可以直接复制进项目管理工具，不用二次整理。

第三类是辅助脚本路径。如果你在技能目录里放了脚本，记得在 SKILL.md 里写明调用方式。AI 通常会先读主文件，再按路径找脚本，路径写错了它也不会主动去搜。

调优时还有一个心态上的建议：不要追求“一次完美”，技能的迭代速度远比写文档快。我是习惯每周复盘一次，看看哪些输出不符合预期，然后调整描述或补一条规则，让技能持续进化。

4.4 与“结构图 skills”等衍生方向的结合方式

这节回应一下热门搜索词里的“结构图 skills”。很多人做知识整理或方案汇报时需要生成结构图，但用 Mermaid 或思维导图工具有个痛点：手写语法麻烦，调样式更麻烦。

我的解决方法是，在笔记整理技能里增加一个“结构图导出模式”，当用户输入“把这段内容整理成结构图”时，AI 会按照预设的“大纲规则”输出一个层级清晰的 Markdown 列表，再用一个开源脚本把这个列表转成 Mermaid 的 mindmap 图，或直接生成 SVG。这样既有 AI 的语义理解能力，又不被绘图工具的语法拖累。

和配图技能结合时，结构图可以直接作为示意图的底稿。品牌色通过配置统一注入，输出的图片风格也能保持一致。这个组合我最近在技术文档写作中经常用，一次生成整篇文档的所有配图，效率提升很明显。

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

5.1 技能根本不被加载或触发

这是遇到最多的问题。表现是：技能文件建好了，目录结构也没问题，但 AI 就是不读 SKILL.md，回答内容跟没用技能一样。

排查思路按顺序来：

• 检查目录位置是否在工具识别的范围内。.claude/skills/和.opencode/skills/不是同一个目录，别放错。
• 检查 SKILL.md 的 frontmatter 是否合法。YAML 格式里冒号后面一定要有空格，否则解析失败。
• 检查 description 是否与任务匹配。任务描述和技能描述完全不沾边时，AI 不会加载技能。
• 检查文件名。主文件必须是SKILL.md，全大写。

我遇到过一次很奇怪的问题：技能目录里多了一个.DS_Store文件，导致工具读取时抛异常，整个技能都不加载。删掉后恢复正常。

5.2 输出格式不理想或模板不生效

模板不生效，大概率是模板文件路径写错了，或者 SKILL.md 里没有明确告诉 AI 去读模板。AI 不会自己主动翻目录——你必须在指令里写明“从 templates/article-template.md 中读取模板”。

另一个坑是模板里“示例内容”和“填充内容”没有明确区分。AI 很容易把示例当成正文内容一起输出。解决方式是在模板里加清晰的注释分割线：

<!-- 示例开始：以下为填充示例，请勿输出 --> ... <!-- 示例结束 -->

实测这个方法非常管用。

5.3 跨工具兼容性问题（Claude Code 与 OpenCode 配置迁移）

不同工具之间的 Skills 兼容性目前还不是 100%。主要差异在 frontmatter 字段的解析和辅助脚本的执行方式上。

我的迁移策略是：核心指令和模板资产尽量做成工具无关的，只在迁移时写一层极薄的适配层。比如同一个技能目录，在 Claude Code 和 OpenCode 下共用一个skills/目录，但分别写各自的入口文件。这样改动的量最小。

另外建议把技能目录纳入 git 管理，每次调整都留历史记录。技能和代码一样，出了问题方便回滚，才知道调整的效果。

5.4 常见故障速查表

这张表是我自己使用过程中的真实记录，你可以根据自己的工具版本做微调。

5.5 实际使用中的“性价比评估”：哪些场景值得建技能

最后分享一点个人判断标准。不是所有事情都值得做成 Skills。它的真正优势在于“重复 + 流程化 + 输出稳定”这三个特征的组合。如果你只是偶尔用一次，直接写提示词就够了；如果你每个星期都要做同一类任务超过两三次，那么建一个技能大概率是划算的。

我自己目前稳定在用的技能大概有七八个，但只有笔记整理、会议准备、数据查询、演示文稿、配图这五个消耗了我绝大部分时间。其他几个小的（比如代码 commit message 生成、周报整理）使用频率不高，但建起来成本也很低，遇到需要时能省不少事。

从投入产出比来看，优先级最高的永远是“占时间最多的重复性任务”。你把那项任务先做成技能，就是最大的提效。这也是为什么我强烈建议从自己工作流里找第一个场景，而不是去复制别人的整套技能包。别人用的顺手的关键配置和细节，很可能和你自己的实际场景对不上。

6. 我的个人体会与后续扩展建议

折腾 Skills 这段时间，我最深的体会是：它真正改变的不是 AI 的能力上限，而是你自己与 AI 协作的下限。以前答案的质量取决于你每句话怎么问、怎么补充背景、怎么纠正；现在只要你把技能设计好，即使输入很随意，输出也能稳定在一个不错的水平。

我个人建议你上手的时候克制一点，先只做一个技能，用两周时间不断调优，让它真的融入日常工作流。等体会到效果之后，再逐步扩展。Skills 生态更新速度很快，开源社区里已经涌现了大量高质量的技能库，保持关注、适度借鉴，比什么都自己从零写要聪明得多。