企业官网建设流程全解析

1. 从“每次都要重新讲一遍”说起：Skill 到底解决什么问题

我最早接触 Agent 工作流的时候，犯过一个很典型的错误：把所有操作流程都塞进对话里。每次让 Agent 帮我处理一个固定任务，比如“把一份会议纪要整理成结构化周报”，我都要重新描述一遍格式要求、字段顺序、语气风格、哪些内容要合并、哪些要单独列出。一次两次还行，到了第十次，我开始烦了——不是烦 Agent，是烦我自己。

后来我意识到，这不是 Agent 不够聪明，而是我没有把“我已经想清楚的流程”沉淀下来。Skill 的核心价值，就是把那些你反复讲、反复调、反复修正的操作流程，变成一份可复用、可触发、可版本管理的结构化文件。你写一次，之后 Agent 在合适的场景下自动加载，不需要你每次从头交代。

这件事听起来简单，但真正动手做的时候，很多人会卡在几个地方：Skill 文件到底长什么样？description 怎么写才能被正确触发？流程步骤要细到什么程度？哪些内容该写进 Skill，哪些不该？我前后折腾了十几个 Skill，踩了不少坑，也总结出一套比较稳的做法。这篇文章就围绕skill-creator这个思路，把“如何打造自己的专属 Skill”这件事讲透。

先明确一下适用人群：如果你已经在用 Agent 处理重复性任务，比如代码审查、文档整理、数据分析、内容生成、项目初始化，那 Skill 对你价值最大。如果你还没开始用 Agent，也没关系，理解 Skill 的设计思路，对你梳理任何“可复用流程”都有帮助。

提示：Skill 不是提示词模板的简单堆砌。它更像一份“操作手册 + 触发条件 + 边界说明”的组合体，写得好不好，直接决定 Agent 能不能在正确的时候做正确的事。

2. Skill 文件的骨架：SKILL.md 里到底该放什么

2.1 为什么是 Markdown 而不是 JSON 或 YAML

我试过用 JSON 写 Skill，也试过 YAML，最后回到 Markdown。原因很实际：Skill 的主体内容是“给人看也给模型看”的自然语言流程描述，Markdown 在可读性和结构表达上最平衡。JSON 适合机器解析，但你写流程的时候会不断被引号、转义、层级括号打断思路；YAML 好一点，但长文本段落写起来还是别扭。Markdown 的标题层级、列表、代码块、引用块，刚好能覆盖 Skill 需要的所有表达形式。

另一个原因是，Agent 在读取 Skill 时，本质上是在做“上下文注入”。Markdown 的标题结构能帮助模型快速定位到“这个 Skill 是干什么的”“什么时候用”“具体步骤是什么”，比纯结构化数据更符合模型的阅读习惯。

2.2 一个 Skill 的最小可用结构

我不建议一上来就追求大而全。先跑通一个最小闭环，再逐步加细节。下面是我常用的最小结构：

--- name: weekly-report-builder description: 将会议纪要或零散工作记录整理成结构化周报，适用于需要按固定模板输出周报的场景。 --- ## 触发条件 当用户提到“周报”“weekly report”“整理本周工作”等关键词，且提供了原始记录时，加载本 Skill。 ## 输出格式 1. 本周完成事项（按项目分组） 2. 进行中事项（标注当前进度） 3. 风险与阻塞（标注影响范围） 4. 下周计划（按优先级排序） ## 处理规则 - 合并重复事项，保留最新状态 - 未明确归属的事项放入“其他” - 风险项必须标注影响范围，无法判断时标注“待确认”

这个结构里，name和description放在 front matter 里，是为了让 Agent 在“决定是否加载这个 Skill”时有一个快速判断依据。正文部分则分成触发条件、输出格式、处理规则三块，分别回答“什么时候用”“产出什么”“怎么处理细节”。

2.3 description 的写法决定 Skill 能不能被触发

这是我最想强调的一点。很多人 Skill 写得很认真，但 description 写得太泛，导致 Agent 根本不知道什么时候该用它。比如你写“帮助处理文档”，这等于没写。Agent 面对几十个 Skill 的时候，只能靠 description 做初筛，写得太泛就会被忽略，或者被错误触发。

我的经验是，description 要包含三个要素：动作 + 对象 + 场景。举个例子：

• 差：帮助整理内容
• 好：将会议纪要、聊天记录等非结构化文本整理成按项目分组的周报，适用于需要固定模板输出的周报场景

再比如一个代码审查 Skill：

• 差：审查代码
• 好：对 Python 代码进行静态审查，检查命名规范、异常处理、边界条件，适用于提交前的自查场景

你会发现，好的 description 里其实隐含了“触发词”。Agent 在匹配时，会看用户输入里有没有“周报”“会议纪要”“Python 代码审查”这类信号。你 description 里写清楚了，匹配成功率就高。

注意：description 不要写得太长，控制在两三句话以内。太长反而会稀释关键信息，模型抓不住重点。

2.4 触发条件要不要单独写

要。而且我建议写得比 description 更具体。description 是给 Agent 做初筛用的，触发条件是给 Agent 做二次确认用的。比如：

## 触发条件 满足以下任意一条时加载： - 用户明确提到“周报”或“weekly report” - 用户提供了会议纪要、工作记录等原始材料，并要求“整理成固定格式” - 用户说“按上周的模板来” 以下情况不加载： - 用户只是问“周报怎么写”但没有提供原始材料 - 用户要求的是日报或月报

把“不加载”的情况也写出来，能有效减少误触发。我一开始没写这部分，结果 Agent 在我只是讨论“周报格式”的时候也把 Skill 加载了，反而干扰了正常对话。

3. 把流程写细：从“能跑”到“稳定跑”的关键差距

3.1 步骤粒度：写到“不需要再问”为止

Skill 最容易出问题的地方，是步骤写得太粗。比如你写“整理会议纪要”，Agent 会问你：要不要合并同一议题的多次讨论？要不要保留发言人？时间戳要不要？你每回答一次，就等于在补全 Skill。正确的做法是，把你曾经回答过的所有问题，提前写进 Skill 里。

我现在的判断标准是：如果一个步骤在执行时，我还需要额外解释才能让 Agent 做对，那这个步骤就没写够。比如“整理会议纪要”这个 Skill，我会写到这个程度：

## 处理规则 ### 议题合并 - 同一议题的多次讨论合并为一个条目 - 合并时保留最新结论，历史讨论放入“讨论过程”子项 - 如果多次讨论结论冲突，标注“存在分歧”并列出各方观点 ### 发言人处理 - 默认保留发言人姓名 - 如果用户要求匿名，用“发言人A/B/C”替代 - 如果发言人未明确，标注“未标注” ### 时间戳处理 - 默认不保留时间戳 - 如果用户要求保留，格式统一为 HH:MM - 跨天会议标注日期

这些规则不是我凭空想的，是我在实际使用中一次次被问出来的。每被问一次，我就补一条。补到后来，Agent 基本不再追问，直接出结果。

3.2 边界条件：什么不做，比做什么更重要

Skill 写多了会发现，明确“不做什么”往往比“做什么”更能提升稳定性。因为 Agent 的默认行为是“尽量帮忙”，你不设边界，它就会自由发挥。比如一个“代码审查”Skill，如果不写边界，Agent 可能会顺手帮你重构代码、改命名、甚至调整架构。这些不一定是坏事，但会偏离你原本的意图。

我会在 Skill 里专门加一节“边界与禁止事项”：

## 边界与禁止事项 - 只做审查，不直接修改代码 - 不评价代码风格偏好（如空格 vs 制表符），除非用户明确要求 - 不检查业务逻辑正确性，只检查通用规范 - 如果发现严重问题，标注“需人工确认”，不自行判断

这几条写进去之后，Agent 的输出范围就收窄了，我拿到结果后不需要再过滤一遍。

3.3 输出格式：给模板，不给描述

“输出一个结构化的报告”——这种描述等于没描述。Agent 对“结构化”的理解和你可能完全不一样。正确做法是直接给模板，用占位符标出需要填充的部分。

## 输出格式 ### 本周完成 - [项目名]：[事项描述]（[状态]） ### 进行中 - [项目名]：[事项描述]（进度：[百分比或阶段]） ### 风险与阻塞 - [风险描述]（影响：[影响范围]，建议：[建议动作]） ### 下周计划 - [优先级] [事项描述]

有了这个模板，Agent 的输出会非常稳定。我甚至会把模板放在 Skill 的最前面，让 Agent 先看到“最终要产出什么”，再去看处理规则，这样它处理细节时更有目标感。

3.4 示例：给一个完整输入输出对

如果 Skill 的逻辑比较复杂，我会在最后附一个完整的输入输出示例。这相当于给 Agent 一个“参考答案”，能显著提升首次执行的准确率。

## 示例 输入： “周一跟产品对了需求，确认要做导出功能；周三开发说导出性能有问题，需要加缓存；周五测试提了三个bug，两个已修，一个待确认。” 输出： ### 本周完成 - 导出功能：与产品确认需求（已完成） ### 进行中 - 导出功能：性能优化，加缓存方案（进度：开发中） - 导出功能：bug修复（进度：2/3，1个待确认） ### 风险与阻塞 - 导出性能问题（影响：上线时间，建议：优先验证缓存方案） ### 下周计划 - 高：完成剩余bug修复 - 中：验证缓存方案效果

这个示例一放进去，Agent 基本就能理解“合并”“标注状态”“风险提取”这些规则具体怎么落地了。

4. 触发机制与加载策略：让 Skill 在该出现的时候出现

4.1 Skill 的触发不是“关键词匹配”那么简单

很多人以为 Skill 触发就是看用户输入里有没有某个词。实际用下来，Agent 的触发判断更接近“意图匹配”。它会综合看：用户当前在做什么任务、上下文里有没有相关信号、当前加载的其他 Skill 有没有冲突。所以你在写 Skill 的时候，不能只堆关键词，还要把“意图”写清楚。

比如“周报”这个词，可能出现在“帮我写周报”“周报模板发我”“周报怎么写”三种语境里。前两种应该触发，第三种不应该。如果你只写关键词“周报”，就会误触发。我的做法是在触发条件里写清楚意图：

## 触发条件 加载本 Skill 需要同时满足： 1. 用户提供了原始工作记录（会议纪要、聊天记录、任务列表等） 2. 用户要求输出固定格式的周报 仅提到“周报”但没有提供原始记录时，不加载。

4.2 多个 Skill 冲突时怎么办

当你积累到十几个 Skill 之后，冲突是必然的。比如你有一个“通用文档整理”Skill，又有一个“周报生成”Skill，用户输入“把这份记录整理一下”，两个都可能被触发。这时候 Agent 会怎么选？取决于你的 Skill 里有没有写优先级。

我会在 Skill 里加一行：

## 优先级 当与“通用文档整理”Skill 同时匹配时，优先加载本 Skill。

或者在 description 里写清楚适用范围：

description: 将工作记录整理成周报。仅适用于周报场景，通用文档整理请使用 document-organizer。

这样 Agent 在做选择时就有依据了。

4.3 手动触发与自动触发

有些 Skill 适合自动触发，比如“代码审查”“周报生成”；有些适合手动触发，比如“项目初始化”“批量重命名”。手动触发的 Skill，我会在 description 里写“需用户明确调用”，避免 Agent 自作主张。

description: 初始化新项目目录结构。需用户明确说“初始化项目”时加载，不自动触发。

这个区分很重要。自动触发的 Skill 如果误触发，会打断正常对话；手动触发的 Skill 如果自动触发，可能会在你还没准备好时就执行操作。

5. 从零到一：用 skill-creator 思路搭建你的第一个 Skill

5.1 先选一个“你已经做过至少五次”的任务

不要一上来就挑战复杂任务。选一个你已经重复做过至少五次、流程已经比较清晰的任务。比如：

• 把零散笔记整理成结构化文档
• 对一段代码做提交前自查
• 把英文技术文档翻译成中文并保留术语
• 从一堆数据里提取关键指标并生成摘要

选好之后，先别急着写 Skill。先手动做一遍，把每一步都记下来。记的时候注意：哪些步骤是你下意识做的？哪些判断是你凭经验做的？这些往往是 Skill 里最需要写清楚的部分。

5.2 用“三问法”确定 Skill 边界

写之前问自己三个问题：

1. 这个 Skill 的输入是什么？是用户的一段话、一个文件、还是多个来源的材料？
2. 输出是什么？是一段文本、一个表格、还是一个文件？
3. 中间有哪些判断？哪些情况需要特殊处理？哪些情况应该拒绝？

这三个问题的答案，基本就构成了 Skill 的骨架。输入对应触发条件，输出对应输出格式，判断对应处理规则。

5.3 写第一版：不求全，求跑通

第一版 Skill 不要写太长。我的经验是，控制在 50 行以内，先把主流程跑通。比如：

--- name: note-organizer description: 将零散笔记整理成按主题分组的结构化文档，适用于会议记录、学习笔记等场景。 --- ## 触发条件 用户提供零散笔记并要求“整理”“归类”“结构化”时加载。 ## 输出格式 ### 主题一 - 要点 - 要点 ### 主题二 - 要点 ## 处理规则 - 按内容相关性分组，每组不超过 5 条 - 合并重复要点 - 无法归类的放入“其他”

写完第一版，拿三个真实案例跑一遍。看哪里卡住、哪里输出不对、哪里需要你额外解释。把这些都记下来，作为第二版的补充。

5.4 迭代：每次只改一个地方

Skill 迭代最忌讳一次改太多。你改了三处，结果输出变差了，你都不知道是哪处改坏了。我的做法是每次只改一个地方，改完立刻用之前的案例验证。比如这次只加“合并重复要点”的规则，下次只加“每组不超过 5 条”的限制。这样你能清楚知道每条规则的实际效果。

我自己的“周报生成”Skill 迭代了七版。第一版只能做简单分组，第三版加了风险提取，第五版加了优先级排序，第七版加了示例。每一版都是被真实问题逼出来的，不是提前设计好的。

6. 那些没人告诉你但一定会踩的坑

6.1 Skill 写太长，反而触发不了

我一开始觉得 Skill 越详细越好，结果写了一个 300 行的 Skill，Agent 反而不太愿意加载它。后来才明白，Skill 的加载是有上下文成本的。太长会占用大量上下文，Agent 在判断是否加载时会犹豫。而且太长的 Skill 里，关键信息容易被淹没。

我的建议是：主 Skill 控制在 100 行以内，超出的部分拆成子 Skill 或附录。如果确实需要很长的规则，把最核心的触发条件和输出格式放在前面，细节规则放在后面，并标注“按需查阅”。

6.2 description 写得太“聪明”，导致匹配失败

有些人喜欢在 description 里用很抽象的表达，比如“赋能内容生产”“提升工作效率”。这些词对人有用，对 Agent 匹配没用。description 要写具体的动作和对象，不要写价值主张。“将会议纪要整理成周报”比“提升工作效率”有用一百倍。

6.3 忘了写“不触发”的情况

这个坑我踩过好几次。只写“什么时候触发”，不写“什么时候不触发”，结果 Agent 在闲聊时也加载 Skill，输出一堆格式化的内容，很尴尬。后来我强制自己在每个 Skill 里都加一节“不加载的情况”，误触发率明显下降。

6.4 输出格式用“描述”而不是“模板”

“输出一个清晰的列表”——这种描述 Agent 理解不了。什么叫清晰？几条？什么格式？直接给模板，用占位符。这是提升输出稳定性最有效的一招，没有之一。

6.5 没有版本管理

Skill 是会不断迭代的。如果你不记录每次改了什么，改到后面你会忘记为什么某条规则存在。我的做法是在 Skill 文件末尾加一个简单的变更记录：

## 变更记录 - v1.0：初始版本，支持基本分组 - v1.1：增加合并重复要点规则 - v1.2：增加风险提取规则 - v1.3：增加输出示例

不用很正式，但要有。这在你回头排查问题时非常有用。

7. 进阶：让 Skill 之间产生协作

7.1 Skill 组合：一个任务拆成多个 Skill

当你的任务变复杂时，单个 Skill 会变得臃肿。这时候可以考虑拆成多个 Skill，让它们协作。比如“周报生成”可以拆成：

• meeting-note-parser：解析会议纪要，提取事项和状态
• weekly-report-builder：把解析结果整理成周报格式
• risk-extractor：从事项中提取风险项

每个 Skill 只做一件事，组合起来完成完整流程。这样做的好处是，每个 Skill 都更短、更稳定，也更容易复用。比如risk-extractor也可以用在项目报告、复盘文档等场景。

7.2 用 Skill 串联工作流

更进一步，你可以写一个“工作流 Skill”，专门描述多个 Skill 的调用顺序：

## 工作流 1. 加载 meeting-note-parser，解析原始记录 2. 加载 risk-extractor，提取风险项 3. 加载 weekly-report-builder，生成最终周报 4. 如果风险项超过 3 条，额外加载 risk-prioritizer 排序

这个工作流 Skill 本身不处理具体内容，只负责编排。这样你调整流程时，只需要改工作流 Skill，不用动各个子 Skill。

7.3 Skill 的复用与迁移

写好的 Skill 可以跨项目复用。比如“代码审查”Skill，在 A 项目写完，B 项目直接拿过去用，只需要微调触发条件。我现在的做法是维护一个“Skill 库”，按领域分类：文档处理、代码审查、数据分析、内容生成。新项目开始时，先从库里找现成的，找不到再写新的。

提示：跨项目复用 Skill 时，注意检查触发条件里有没有项目特定的关键词。比如“检查导出模块”这种，换项目就不适用了，要改成通用表达。

8. 我自己的 Skill 管理习惯

最后分享几个我日常管理 Skill 的习惯，都是踩坑之后养成的。

第一，Skill 文件统一命名。我用领域-动作.md的格式，比如doc-weekly-report.md、code-review-python.md。这样在目录里一眼就能找到，也方便 Agent 按领域筛选。

第二，每个 Skill 都写“最后验证时间”。在 front matter 里加一行last_verified: 2025-06-01。Skill 放久了可能会因为 Agent 版本更新而失效，定期验证一下，过期的就更新或删除。

第三，保留“废弃 Skill”目录。有些 Skill 不用了，但里面的规则可能还有参考价值。我会把它们移到deprecated/目录，而不是直接删掉。过段时间回头看，经常能捡回一些有用的东西。

第四，用真实案例做回归测试。每次改完 Skill，我会拿之前存的三到五个真实案例跑一遍，确认输出没有变差。这个习惯帮我避免了好几次“改一处坏三处”的情况。

第五，Skill 不要写“完美”，要写“够用”。我见过有人花两周写一个 Skill，结果用了一次就不用了。Skill 的价值在于被使用，不在于被写得多漂亮。先写一个能跑的版本，用起来，再迭代。这才是 skill-creator 这个思路真正的意义——不是创造一个完美的 Skill，而是创造一个能持续进化的 Skill。