企业官网建设流程全解析

1. 为什么“每次从头教 AI”是个必须解决的问题

如果你最近半年高频使用各类 AI 编程助手、写作助手或者 Agent 工具，大概率会有一种强烈的疲惫感：每次开一个新会话，你都得重新交代一遍背景。比如“我们团队用 TypeScript 严格模式”“提交信息必须遵循 Conventional Commits”“数据库迁移脚本不允许直接改字段类型”“写单元测试时 mock 要放在__mocks__目录下”。你讲一遍，AI 点头如捣蒜；换个窗口，它又失忆了。

这件事的本质不是 AI 记性差，而是你的经验没有被结构化地沉淀下来。你脑子里那套“我们团队就是这么干的”隐性知识，对 AI 来说是不可见的。你每次重新输入，本质上是在做一次性的、不可复用的“提示词劳动”。劳动成果随着会话关闭而蒸发，下一次还得重来。

“Skill”这个概念就是冲着这个痛点来的。你可以把它理解成给 AI 装的一份可复用的操作手册：把某类任务的背景、约束、步骤、检查清单、常见坑，写成一个结构化的文件（通常叫SKILL.md或类似命名），放在 AI 能读取的位置。之后无论谁在什么会话里触发这个场景，AI 都会自动加载这份手册，按你定义的方式干活。

标题里说的“12 个开源 Skill”，核心价值不在于这 12 个具体文件本身，而在于它们示范了一种把个人和团队经验资产化的方法。你抄的不是那 12 份内容，而是它们组织经验的方式。学会这套方法之后，你可以把自己手里那些“每次都要讲一遍”的东西，全部变成可版本管理、可分享、可迭代的 Skill 文件。

这篇文章适合三类人看：一是天天和 AI 助手打交道、被重复交代背景折磨的开发者和写作者；二是团队里负责规范落地、想让 AI 输出更符合内部标准的技术负责人；三是对 Agent、Skill 机制好奇，想搞清楚“它到底怎么知道该干什么”的探索者。下面我会从机制、结构、实操、避坑几个层面，把这件事讲透。

2. Skill 到底是怎么被 AI “读到”的

2.1 从“提示词”到“可加载资产”的认知转变

大多数人用 AI 的方式还停留在“对话”层面：我打字，它回复，聊完即止。这种方式下，你的所有上下文都活在这一次会话的临时记忆里。而 Skill 的思路是把上下文外置成文件，让 AI 在需要的时候主动去读。

这个转变很像从“口头交接工作”变成“写一份 SOP 文档”。口头交接的问题是，每个人问一遍你就得讲一遍，而且每次讲的详略还不一样；SOP 文档写一次，谁需要谁去看，内容永远一致，还能持续修订。Skill 就是 AI 世界里的 SOP。

具体机制上，不同工具的实现细节不一样，但大方向是一致的：AI 在启动或执行某类任务时，会扫描特定目录下的 Skill 文件，读取其中的元信息（比如这个 Skill 叫什么、什么时候该用），然后决定是否把完整内容加载进当前上下文。有的实现是关键词触发，有的实现是任务类型匹配，还有的是显式调用。

注意：Skill 不是“训练”AI，它不会改变模型权重。它只是在运行时把额外信息喂给模型。所以 Skill 的效果高度依赖你写的内容质量，写得含糊，AI 执行得也含糊。

2.2 SKILL.md 这类文件的典型结构

虽然不同平台的 Skill 格式有差异，但一个能用的 Skill 文件通常包含这几块：

• 元信息头：名称、描述、适用场景、触发条件。这部分决定了 AI 能不能在正确的时机找到它。
• 背景与目标：这个 Skill 解决什么问题，期望产出什么。
• 约束与规则：必须遵守的硬性要求，比如“不允许使用 any 类型”“输出必须是 JSON”。
• 操作步骤：分步骤的执行流程，越具体越好。
• 检查清单：完成前必须逐项确认的事项。
• 示例：正例和反例，帮助 AI 理解边界。

我见过很多人写 Skill 只写“帮我做 X”，然后抱怨 AI 不听话。问题就出在：你给的是愿望，不是指令。愿望是模糊的，指令是可执行的。一份好的 Skill 读起来应该像一份给新人的交接文档，而不是一句口号。

2.3 为什么“开源 Skill”比自己从零写更值得参考

自己从零写 Skill 最大的问题是不知道边界在哪。你不知道该写多细，不知道哪些约束是必要的，不知道检查清单该列几项。开源 Skill 的价值就在于它提供了大量“别人踩过坑之后总结出来的结构”。

比如一个做代码审查的 Skill，可能包含“先看命名再看逻辑”“安全问题优先级高于风格问题”“每个问题必须给出修改建议而不只是指出问题”这类规则。这些规则单看很朴素，但它们是经过实际使用打磨出来的，能帮你快速建立起对“Skill 该长什么样”的直觉。

而且开源意味着你可以直接 fork、改、用。你不需要从空白文件开始，而是站在别人的结构上做本地化适配。这个效率差距是巨大的。

3. 12 个开源 Skill 里真正值得抄的东西

3.1 分类看：它们覆盖了哪些场景

把常见的开源 Skill 按用途归类，大致能分成这么几类，每一类背后都对应一种高频的“重复交代”场景：

你会发现，这些场景的共同点是：有明确的“正确做法”，但正确做法不在 AI 的默认知识里。AI 的默认输出是“平均水平的通用答案”，而 Skill 的作用是把它拉到“符合你要求的答案”。

3.2 抄结构，不抄内容

这是我最想强调的一点。很多人看到开源 Skill 的第一反应是“我直接拿来用”。但 Skill 是高度场景化的东西，别人的团队规范、技术栈、业务约束和你大概率不一样。直接套用，轻则水土不服，重则引入一堆你根本不需要的规则。

正确的做法是拆解它的结构。拿一个代码审查 Skill 举例，你可以这样拆：

• 它的元信息是怎么写的？触发条件用了哪些关键词？
• 它的约束分了几层？哪些是硬性、哪些是建议？
• 它的检查清单是按什么维度组织的？按严重程度还是按文件类型？
• 它的示例是怎么构造的？正例反例各说明了什么？

把这套骨架抽出来，再往里填你自己的内容。这样得到的 Skill 才是真正属于你的资产，而不是一件不合身的别人的衣服。

3.3 一个被低估的细节：触发条件的写法

Skill 能不能在正确的时机被加载，几乎完全取决于触发条件写得好不好。写得太宽，AI 动不动就加载，浪费上下文还干扰判断；写得太窄，该用的时候用不上，等于白写。

我实测下来比较稳的写法是**“场景描述 + 关键词 + 反例排除”三件套**。比如：

• 场景描述：当用户要求审查代码改动时
• 关键词：review、审查、检查、diff、PR
• 反例排除：不适用于纯格式调整、不适用于依赖升级

反例排除这一条很多人会忽略，但它能显著减少误触发。AI 在判断“要不要用这个 Skill”时，明确的排除条件比模糊的包含条件更有用。

4. 从零做一个自己的 Skill：完整实操

4.1 先选一个“你讲过三遍以上”的场景

不要一上来就想着做一个大而全的 Skill。选场景的标准很简单：这件事你跟 AI 交代过三次以上，而且每次交代的内容高度相似。这就是最值得沉淀的场景。

举几个我实际做过的例子：一是“把一段中文技术描述翻译成英文提交信息”，二是“根据错误日志给出排查步骤”，三是“把散乱的需求整理成任务清单”。这三个场景我都反复交代过，做成 Skill 之后，每次省下的时间累积起来非常可观。

选好场景后，先别急着写文件。拿一张纸，把你每次口头交代的内容列出来。列完之后你会发现，里面有一部分是每次都说的（核心规则），有一部分是偶尔补充的（边界情况）。核心规则进 Skill 主体，边界情况进检查清单或示例。

4.2 写第一版：宁可啰嗦，不要含糊

第一版 Skill 的原则是把话说死。不要写“尽量使用清晰的命名”，要写“变量名必须是名词或名词短语，函数名必须是动词开头，禁止使用 data、info、temp 这类无意义词”。不要写“注意安全”，要写“所有用户输入必须经过校验，禁止直接拼接进查询语句”。

为什么宁可啰嗦？因为 AI 对模糊指令的解读是发散的。你说“清晰”，它可能理解成“短”，也可能理解成“有注释”。你说“动词开头”，它就没有歧义。第一版写得越具体，后面迭代的成本越低。

一个实操技巧：写完第一版后，拿三个不同的真实任务去测。看 AI 的输出是否符合预期。不符合的地方，就是你需要补充规则的地方。这个“写—测—补”的循环，通常跑三轮就能得到一个相当可用的 Skill。

4.3 用真实任务验证，而不是靠想象

我见过太多人写完 Skill 之后自我感觉良好，实际一用全是问题。原因就是验证用的是想象中的任务，而不是真实任务。

真实任务的特点是：有脏数据、有边界情况、有前后依赖。你想象的任务是“把这段代码审查一下”，真实任务是“这个 PR 改了 8 个文件，其中 3 个是自动生成的，2 个只改了格式，剩下 3 个有逻辑改动，帮我重点看逻辑改动”。后者才是 Skill 要面对的实际情况。

验证的时候记录两件事：一是 AI 哪些地方没按 Skill 执行，二是 Skill 里哪些规则其实没必要。前者说明规则不够明确，后者说明规则过度设计。两个方向都要调整。

4.4 版本管理：Skill 也是代码

Skill 文件应该和代码一样纳入版本管理。原因有三：一是你可以看到规则是怎么演进的，知道每条规则为什么存在；二是多人协作时可以 review 变更；三是出问题可以回滚。

目录结构上，我习惯这样组织：

skills/ code-review/ SKILL.md examples/ good.md bad.md commit-message/ SKILL.md log-analysis/ SKILL.md checklist.md

每个 Skill 一个目录，主文件统一叫SKILL.md，示例和检查清单拆成独立文件按需引用。这样结构清晰，也方便 AI 按需加载部分内容而不是全部。

5. 让 Skill 真正被用起来的几个关键动作

5.1 触发时机比内容质量更影响使用率

一个内容写得再好、但从来不被触发的 Skill，等于不存在。我观察下来，Skill 用不起来最常见的原因不是内容差，而是触发条件没设计好。

改进方法很直接：去看你实际使用 AI 时的输入。把你最常打的那些话记下来，从中提取关键词。比如你经常说“帮我看看这段代码有没有问题”，那“看看”“有没有问题”“代码”就该进触发条件。触发条件要贴着你的真实语言习惯写，而不是贴着书面语写。

另一个技巧是在 Skill 描述里写清楚“什么时候不要用”。这能帮 AI 排除掉大量相似但不适用的场景，减少误触发带来的干扰。

5.2 把 Skill 当成“给新人的交接文档”来写

这个心态转变很重要。很多人写 Skill 时想的是“我要教 AI 做事”，于是写得很抽象。但如果你把它想成“我要给一个刚入职、能力很强但完全不了解我们情况的同事写交接文档”，你的写法会立刻变得具体。

你会写清楚：我们为什么这么做、不这么做会有什么后果、遇到 X 情况时该怎么处理、哪些是绝对不能碰的红线。这些内容恰恰是 AI 最需要的。AI 不缺通用能力，缺的是你的具体上下文。

5.3 定期清理“僵尸规则”

Skill 用久了会积累一堆规则，其中有些是当初为了解决某个特定问题加的，后来那个问题不存在了，规则却还在。这些“僵尸规则”会增加 AI 的认知负担，甚至导致它在不相关的场景里做出奇怪的行为。

我的做法是每个季度过一遍所有 Skill，对每条规则问三个问题：这条规则现在还有效吗？最近三个月它触发过吗？删掉它会不会出问题？三个问题里有两个答案是“否”，就删掉。保持 Skill 精简，比堆砌规则更重要。

6. 踩过的坑：那些让 Skill 失效的常见错误

6.1 规则互相打架

这是最隐蔽也最致命的问题。比如你在一个 Skill 里写“输出必须简洁，不超过三句话”，在另一个 Skill 里写“必须完整覆盖所有边界情况”。当两个 Skill 同时被加载时，AI 就懵了：到底该简洁还是该完整？

解决办法是建立规则优先级。在 Skill 里明确写“当本规则与其他规则冲突时，以本规则为准”，或者干脆在顶层维护一份全局规则，各 Skill 只写自己特有的部分。规则冲突这件事，不遇到则已，一遇到就是大问题，提前设计好优先级能省很多事。

6.2 把“示例”写成了“唯一答案”

示例的作用是帮助理解边界，不是规定唯一输出。我早期写 Skill 时，示例写得太具体，结果 AI 把所有类似任务都往示例的格式上套，遇到稍微不同的情况就生搬硬套。

后来我改成每个示例都标注“这个示例说明了什么原则”。比如“这个示例说明的是：当输入包含多个问题时，要按严重程度排序而不是按出现顺序”。这样 AI 学到的是原则，而不是模板。

6.3 忽略了“失败路径”

大多数 Skill 只写了“顺利情况下怎么做”，没写“出错了怎么办”。但实际使用中，失败路径才是高频场景。比如输入格式不对、信息缺失、任务超出能力范围，这些情况如果没有在 Skill 里定义处理方式，AI 就会自由发挥，结果往往不可控。

我的做法是在每个 Skill 末尾加一段“异常处理”：输入不完整时先追问而不是猜测；任务超出范围时明确说明而不是硬做；遇到不确定的情况时给出选项而不是替用户决定。这几条加上之后，输出的稳定性明显提升。

6.4 一次改太多，无法定位问题

Skill 迭代时，很多人喜欢一次性改一堆规则，然后发现效果变差了，却不知道是哪条改坏的。这是典型的“多变量同时变更”问题。

正确做法是每次只改一个变量，改完立刻用固定的一组测试任务验证。这组测试任务要覆盖正常情况、边界情况、异常情况。改完对比前后输出，确认是变好还是变坏。虽然慢一点，但每一步都可追溯，长期看反而更快。

7. 把经验变成资产的长期思路

7.1 从个人 Skill 到团队 Skill 库

个人用 Skill 省的是自己的时间，团队用 Skill 省的是所有人的时间，而且能保证输出一致性。当你有了一批稳定的个人 Skill 之后，下一步就是把它变成团队资产。

团队化的关键动作有三个：一是统一目录结构和命名规范，让所有人都能找到；二是建立 review 机制，新 Skill 和 Skill 变更都要有人看；三是写一份“如何写 Skill”的元 Skill，让新人能快速上手。这三件事做完，Skill 库就能自我运转了。

7.2 让 Skill 跟着项目走，而不是跟着人走

一个常见的误区是把 Skill 放在个人目录下。这样一旦这个人休假或离职，Skill 就失传了。正确做法是把 Skill 和项目代码放在一起，跟着仓库走。谁 clone 了项目，谁就拿到了这套 Skill。

这样做还有个额外好处：Skill 的变更可以和代码变更一起 review。当项目规范调整时，Skill 的更新会被自然地纳入同一个 PR，不会出现“代码改了但 Skill 没改”的脱节情况。

7.3 定期回顾：哪些经验还没被沉淀

最后分享一个我坚持了半年的习惯：每个月花半小时，回顾这个月里“我跟 AI 重复交代过什么”。凡是重复超过两次的，就考虑做成 Skill。这个习惯让我陆续沉淀了十几个 Skill，现在开新会话时，需要手动交代的内容已经少了一大半。

经验这东西，放在脑子里是消耗品，每次用都要重新讲一遍；写成 Skill 就变成了资产，写一次，之后每次都在帮你省时间。12 个开源 Skill 最大的启发不是那 12 份内容，而是它证明了一件事：你的经验值得被结构化地保存下来。从今天开始，挑一个你讲过三遍以上的场景，写你的第一个 Skill 吧。