企业官网建设流程全解析

"完结无密"这四个字写在那，意味着这个系列走到最后一篇了，前面聊过的概念、搭建、单点用法，这次全部收拢到一起，用一套完整的多平台实战串起来。这篇就讲一件事：怎么把 Agent Skills 真正用起来，让它从"装了试试"变成"日常工作中离不开"的状态。

先说清楚这文章适合谁。如果你已经知道 Agent Skills 大概是什么——就是给 Agent 安装的、按需加载的一套技能包——但还不知道怎么在多个平台之间复用同一套技能，或者你正准备照着吴恩达那套 Agent Skills 教程动手实践，想找一份更完整、更贴地的操作手册，那这篇就是给你写的。文里不会讲太多理论，重点放在命令、文件的组织方式、平台之间的差异处理上，每一步都是我实际跑过的。

1. 从"工具调用"到"技能沉淀"：Agent Skills 到底解决了什么问题

很多人在刚接触 Agent Skills 的时候，会有一个困惑：这不就是写一堆提示词、封装几个函数吗，跟之前用的 Tools、MCP 有什么本质区别？我一开始也是这么想的，直到自己动手做一个完整的 Skill 并且在两个平台上跑通之后，才真正理解了这个概念的分量。

1.1 一个让人抓狂的场景：每次都要重新教 Agent

过去用 Agent 干活，最让人崩溃的是什么？是每次开一个全新会话，你都得把工作流重新给 Agent 讲一遍。

比如我想要让 Agent 帮我把视频素材转换成适合社交平台发布的短视频，涉及到选片段、加字幕、调比例这一整套流程。可以在对话里把步骤写得很详细：先分析转录稿，再确定高光片段，最后用 ffmpeg 脚本处理输出。但问题是，这些内容只在当前会话里有效。下一个新会话，一切归零，又得重新复制粘贴那大段指令。环境稍微一变，比如从 Claude Code 换到另一个工具，整套东西可能直接作废。

Tools 和 MCP 解决的是"Agent 能调用什么能力"的问题，但没解决"Agent 知道什么时候调用、按什么流程调用"的问题。所以你会发现，光是注册了一堆工具，Agent 还是经常给出文不对板的结果，因为缺少一套可复用的流程指引。

Agent Skills 恰恰补上了这一层。它把"技能"定义为一个完整目录：一个SKILL.md说明文档告诉 Agent 这个技能是干什么的、什么时候该用、按什么步骤执行，然后配上一堆可执行的脚本或参考文件。任何会话里，只要 Agent 判断当前任务匹配这个技能，就会自动读取并执行整套流程。

1.2 Skills、Tools、MCP 的边界别再搞混了

为了方便理解，我喜欢用"操作手册 + 工具箱"来做类比。

• Tool（单一工具）就像一把螺丝刀。它知道怎么拧螺丝，但不知道你要组装的是桌子还是椅子。
• MCP Server（工具服务器）像一个工具箱，里面有很多把螺丝刀、扳手、锤子，Agent 可以按需取用。
• Agent Skill（技能）则是老师傅手里的那本工作手册。手册里会写：拿到一块木板，先量尺寸，再用什么工具切割，最后怎么组装成一把椅子。它把"用哪些工具、按什么顺序、执行什么动作"全部编排好了。

所以当一个任务比较复杂、涉及多步骤的时候，我优先选择做 Skill 而不是继续堆工具。工具是零件，技能是装配线，两者是不同层级的东西。

1.3 为什么"技能"比"提示词"更适合作为复用单元

还有一个常见问题：直接用一大段提示词不也行吗？把流程写进 System Prompt 里，Agent 也会执行啊。

理论上可以，但实际维护起来是场灾难。提示词全都堆在一个系统级配置里，越滚越长，Agent 每次会话都要完整读一遍，浪费上下文窗口不说，改一个细节还可能影响其他地方。而 Skill 是独立的，每个技能一个目录，平时不参与上下文——只有 Agent 判断需要用到这个技能的时候，才去读取对应的文件。

这一点在实际使用中非常重要。我可以在工作目录里放二十个、三十个 Skill，但每次会话真正加载进来的可能只有一两个，上下文占用很干净。这种"按需加载"的机制，是普通提示词方案做不到的。

2. 吴恩达那套教程的底层逻辑：技能工程是提示词工程的下一站

吴恩达专门录过 Agent Skills 的教程，很多人看到标题以为是又一个概念科普，但实际上整套内容的重点落在"工程方法"上。他不是在告诉你 Agent Skills 有多酷，而是在示范一个东西应该怎么设计、怎么写、怎么迭代。

2.1 为什么这类教程值得逐段琢磨

Andrew Ng 的教程难得以一份快递单号查询的 Skill 为例，完整演示了从需求描述、代码改造到 SKILL.md 生成的整个过程。你看完最大的收获应该是：写一个 Skill 不是把想法塞给 AI 让它"生成一下"，而是有一套清晰的设计流程。

我自己的体会是，这套流程本质上跟写传统软件很像，但它多了一层元指令的约束——你写的每一条指令，未来都会被模型在运行时读取和理解，写得好不好直接决定了这个技能在不同模型上的表现稳定性。

他教程里反复强调一个点：description字段要写清楚"什么情况下该使用这个技能"，而不是简单写这个技能能干什么。这一点我后面会专门展开，因为十个 Skill 有九个用不好，问题都出在这一个字段上。

2.2 SKILL.md 的结构拆解：不是随便写写就能叫技能

一个标准的 SKILL.md，通常分为两块：

YAML 元信息区（开头用---包裹）：

--- name: vidmuse_short_clips description: 根据已生成的长视频转录稿和画面描述，自动拆分为多个适合抖音、B站、YouTube Shorts 的短视频分镜脚本，并输出对应 ffmpeg 处理建议。当用户需要将长视频转换为短视频系列时使用。 ---

正文指令区：

这里写的是具体的操作步骤、判断标准、输出格式。需要注意，正文不要写成大段废话文学，而是要写成 Agent 可逐条执行的指令序列。比如：

1. 读取用户提供的转录稿，识别话题转折点 2. 按"每45秒一个高光"标准从转录稿中锁定候选片段 3. 检查画面描述文件，确认候选片段是否有对应的高质量画面 4. 输出每个候选片段的：起止时间、内容摘要、推荐平台、字幕建议 5. 如片段总数超过5个，按优先级排序并说明理由

关键在于"可执行性"。写 SKILL.md 之前，你可以先问自己一个问题：如果是一个没有领域知识的实习生，拿着这份文档能不能按部就班把活干完？能，说明指令足够清晰。

2.3 技能工程的三个层次

看完教程照着练了几轮之后，我把技能工程总结成三个层次，分享出来供参考：

第一层：单步技能。就是"给我一个输入，返回一个输出"。比如查快递、翻译文本、格式化 JSON。这类 Skill 基本可以靠一个脚本解决，适合练手。

第二层：流程技能。需要多个步骤协同，涉及条件判断和分支。比如上面说的视频拆条，得先看转录稿，再查画面描述，然后输出方案。这类技能的核心价值在编排而不在单个环节。

第三层：领域技能。整套技能系统覆盖一个业务领域，多个技能还能互相引用。比如一个"内容生产技能组"，包含选题分析、脚本生成、分镜提取、字幕润色四个技能，它们之间可以协同调用。

吴恩达教程里的那个例子属于第二层。我的建议是，第一层练手可以，但真正要在工作里重用，必须做到第二层以上，因为单步技能大多用传统脚本就能解决，不需要 Agent 介入。

3. 第一站实战：Claude Code 里一行命令装好 Skill

理论说完，直接上实操。现在很多 Agent 平台都支持 Skills，但门槛最低、生态最成熟的还是 Claude Code。这一节我从那条被到处转发的安装命令讲起。

3.1 npx skills add 这条命令拆开看

最近社区里流行一条安装命令，常常见到这样的形式：

npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y

第一次看到的人往往一头雾水。把它拆开解释一下：

• npx skills add：调用 skills CLI 工具，从远程仓库获取技能。
• sandai-org/vidmuse-skills：GitHub 上的仓库地址，格式是组织名/仓库名。可以在命令里直接指定一个仓库，该仓库下所有兼容的 Skill 都会被扫描到。
• --agent claude-code：指定为哪个 Agent 平台安装。skills CLI 支持多平台，平台不同，安装目录和配置文件格式会有差异。
• -g：全局安装，安装到用户的全局技能目录，而不是当前项目目录。这样任何项目都能用，但说实话，我后面会聊到全局安装不一定是最好的选择。
• -y：自动跳过所有交互确认，全程静默安装。

还要提一种指定具体技能的方式：

npx skills add sandai-org/vidmuse-skills/vidmuse-short-clips --agent claude-code -g -y

如果你只需要仓库里的某一个技能，可以在仓库名后面继续追加/技能名，只装这一个，避免一把梭把仓库里所有技能都拉下来占用磁盘和索引时间。

3.2 装完之后怎么确认它真的生效了

安装命令顺利完成不代表万事大吉。我建议做下面两步验证：

第一步，列目录。Claude Code 的全局技能目录固定为~/.claude/skills。执行：

ls ~/.claude/skills

如果能看到一个新出现的目录，比如vidmuse-short-clips，里面有SKILL.md和配套脚本，说明物理文件已经就位。

第二步，在真实对话里触发它。打开 Claude Code，输入：

/skills

这个斜杠命令会列出当前可用的所有技能。如果新装的技能出现在列表中，就可以实际测试了：直接用一句匹配技能描述的任务描述去对话，看 Agent 是否会自动加载该技能。

这里有个非常重要的小细节：Agent 是否能触发某个技能，高度依赖SKILL.md里的description字段。如果描述写得模糊，Agent 很可能"看不见"这个技能。我在第 6 章会专门讲这个坑。

3.3 从本地仓库和私有仓库安装

skills add不只会从 GitHub 上拉。你在公司内部二次开发场景下，通常有私有仓库，CLI 工具也支持直接指向本地路径：

npx skills add ./my-skills-repo --agent claude-code -y

本地安装的好处有两个：一是开发调试快速迭代，改完直接重新 add 即可；二是不依赖外部网络。如果你整个技能仓库还没有推到远端，本地路径显然是首选。

私有仓库方面，CLI 会读取你 GitHub 的本地认证状态，所以一般直接走 HTTPS 就够了。如果仓库比较大，建议用--limit之类的参数（具体参数用npx skills add --help查）控制扫描范围，避免加载太多无关内容。

4. 跨平台复用：同一个 Skill 在多个 Agent 环境里跑通

说过了单平台安装，接下来是重头戏：多平台应用。这也是"多平台应用实战"这个标题的重心所在。很多人装了 Skill 只在 Claude Code 里用，换到其他 Agent 环境就全废了。其实这是因为一开始没有按跨平台的标准去设计。

4.1 设计时就考虑跨平台：目录结构是复用的地基

要跨平台，Skill 的目录结构必须保持兼容。下面是我打磨过多次、实测在多个 Agent 平台都能跑通的结构模板：

my-skill/ ├── SKILL.md ├── scripts/ │ ├── run.py │ └── requirements.txt └── references/ └── examples.md

• SKILL.md：技能说明书，负责告诉 Agent "何时用、怎么用"。
• scripts/：存放真正干活的脚本，注意脚本必须是无交互的纯命令行模式，接收参数输入、向标准输出打印结果。
• references/：放参考资料，比如示例输出、模板文件，供 Agent 在需要时查阅。

这个结构的核心思想是：指令和代码完全分离。SKILL.md 是任何平台都能读取的标准文本；scripts 里的脚本则保证了无论 Agent 怎么调用，最终执行的都是同一套逻辑。

4.2 不同平台之间真正要适配的是什么

每个 Agent 平台的技能加载机制不完全相同，但归纳起来就三处要适配：

第一，安装目录不同。Claude Code 是~/.claude/skills，其他平台可能是~/.config/xxx/skills或者在项目目录下。安装时把目录拷贝过去就行。

第二，触发语法不同。有些平台支持斜杠命令直接触发（如/skill 名称），有些平台只靠模型自动判断，不支持手动指定。写 SKILL.md 的时候不要太依赖某种特定平台的触发方式，否则换平台就失效。

第三，环境变量和路径规则不同。脚本里的绝对路径最好不要写死。假如脚本里有读取参考文件的操作，用相对路径会稳很多，这样目录从任何平台挂载都能正常工作。

这三个适配点，实际上都不需要改 SKILL.md 正文，改的只是外围封装。也就是说：核心技能文件只写一套，平台适配通过目录拷贝和一层薄薄的入口脚本实现。

4.3 一个 Skill 多平台调用的实测记录

我用 vidmuse 类的视频拆条技能做了一次跨平台实测，流程总结如下：

实测里最值得注意的一点是：同一个 Skill，在 Claude Code 上表现的稳定度明显高于其他平台。原因很可能是不同平台对 SKILL.md 的加载策略、上下文拼接方式不一样。所以我的建议是：如果要给多个平台共用技能，在写描述和指令的时候，尽量用中性、通用的语言，尽量避免提具体平台名。

4.4 多平台选型：不是所有平台都值得接 Skills

这里也想泼一点冷水。Skills 这个机制虽然好，但不是所有平台都值得为它投入精力。我筛选平台的三个标准：

• 是否支持按需加载：一个平台如果每次启动都强行加载全部技能，还不如用普通脚本。
• 是否支持标准 SKILL.md：只支持自定义格式的平台，等于把技能变相锁定在单个环境里。
• 社区生态是否活跃：生态决定你能复用的技能数量，也决定你踩坑时有没人帮你填坑。

按这三个标准看，Claude Code 是目前最成熟的宿主，其他平台建议先做技术验证再决定是否长期维护。

5. 从零手搓一个多平台 Skill：完整过程复盘

光说不练没意思。这一节我完整复盘自己从零手搓一个"视频会议纪要转行动项"Skill 的过程，用这个例子把所有设计要点串起来。你不需要照抄这个技能本身，但要掌握这一整套如何从想法变成可复用资产的流程。

5.1 第一步：界定技能边界，宁可窄不要宽

我当时的需求是：每次开完视频会议，AI 能根据文字纪要提取行动项，并按负责人、截止时间、优先级列表输出。

乍一看很简单，但我一开始差点把技能做宽：要不要同时做会议总结？要不要支持导出到项目管理工具？都被我砍掉了。理由很简单：技能越宽，description 就越难写准，Agent 误触发的概率就越高。技能聚焦"会议纪要 → 行动项结构化"这一件事，其他的留给别的技能或者让 Agent 自由发挥。

这个取舍特别关键。我见过太多人写一个"全能助手"一样的 SKILL.md，结果 Agent 什么都会一点，什么都做得不够好。

5.2 第二步：写 SKILL.md，重点打磨 description

初版我直接写了一个五步流程，测试之后发现 Agent 经常在不需要该技能的时候也去加载它。后来把问题定位到 description 上，改了三个版本才稳定。

下面是最终版的核心结构：

--- name: meeting_action_items description: 从会议文字纪要中提取行动项，输出负责人、截止时间、优先级。当用户提供会议纪要或提到"会议行动项""待办提取"等意图时使用。如果用户只是要求概括会议内容，不要使用本技能。 ---

注意后半句"如果用户只是要求概括会议内容，不要使用本技能"，这是典型的负向排除。description 里加入这种限制，能显著降低误触发率，这是我实践下来最有效的经验之一。

正文指令部分我按"输入处理 → 提取规则 → 输出格式"三层组织，还加了一条覆盖默认值规则：原文没有明确截止时间的行动项，标记为"待确认"，不能凭空编造时间。

5.3 第三步：配套脚本怎么写才能被 Agent 顺畅调用

这个技能不需要很强的脚本处理能力，但我仍然放了一个scripts/parse.py——用正则和简单规则把原始纪要中的行动项提取出来，让 Agent 加载技能后先运行脚本做粗提取，再做结构化输出。

这样设计的好处是什么？降低模型的纯文本解析负担，把确定性工作交给代码，把判断和总结留给模型。混合架构在实测中表现远好于让模型直接从头到尾自己写正则。

脚本要遵守三个约定：

• 通过sys.stdin读取输入，通过sys.stdout输出，不要用交互式输入；
• 任何文件路径通过参数传入，不写绝对路径；
• 输出统一 JSON 格式，方便模型进一步排版。

5.4 第四步：测试与迭代，永远先跑最小用例

技能写完，别急着投放到所有环境。我的测试路径是固定的：

1. 写三个最小测试用例，一个是标准输入、一个是边界输入（有"尽快"这类模糊期限）、一个是与技能无关的输入。
2. 先在 Claude Code 里用本地路径安装，逐个触发测试。
3. 看 Agent 是否能在正确的时机加载技能，如果不加载，先改 description；如果加载了但输出不理想，改正文指令。
4. 稳了之后再复制到其他平台做跨平台验证。

这套流程每次迭代通常只需要几分钟。最忌讳的是直接跳过测试把技能推到生产环境，一旦触发策略有误，会在真实任务里反复误干扰，体验比没有技能还差。

6. 实战中的坑与心得：Skill 不是装得越多越好

最后这一章说的是实践的"暗面"——那些文档不会写、只有跑过才懂的问题。我把高频的坑做个汇总，基本都是亲身踩出来的。

6.1 上下文窗口的隐形消耗：按需加载不等于不消耗

按需加载减少了对上下文的抢占，但请注意：一旦 Agent 判定"当前任务需要某技能"，它会把整个 SKILL.md 甚至参考资料一次性读入。如果技能的目录里堆了大量冗余文件，上下文消耗会非常可观。

我有一次在一个技能目录里放了十几个示例文件和两万字的背景说明，结果一次会话里 Agent 频繁触发该技能，整体对话质量明显下降，后来把参考资料精简到只剩一个 examples.md 才恢复。

经验法则：SKILL.md 加上所有配套文件的总体量，最好控制在 2000 个 token 以内。超过这个量，就要反思是不是把不该放进技能的内容硬塞进去了。

6.2 同名技能的优先级冲突：全局和项目级要分清

同一台机器上，全局技能目录和项目技能目录可能存在同名技能。我的测试经验是：项目级的技能优先于全局级。这个机制本身合理，但如果项目里某个旧版本技能长期没更新，会默默覆盖掉全局里的新版本。

遇到这种情况，我现在的做法是统一用带前缀的命名方式，比如meeting_action_items_v2，明确区分版本，不依赖平台默认的覆盖逻辑。

6.3 description 写得不准确，技能会"隐形"

这个坑前面提过，这里展开。Agent 判断要不要使用某个技能，本质上是把用户任务和技能的 description 做语义匹配。如果你写的是"该技能用于会议纪要处理"，那用户说"帮我把这个会议内容整理成待办"，匹配分可能不够高，Agent 就不会触发。

我的描述模板是这样的：

当用户[具体场景]时，使用本技能。输入包括[典型输入形态]，输出[具体结果]。 如果不满足[排除条件]，不要使用本技能。

一句话把一个技能的使用边界框清楚。这个字段值得花几分钟反复打磨，因为它是技能一切行为的入口。

6.4 版本管理和回滚：技能也会改出问题

技能也是代码，改出问题很常见。我强烈建议把整个 skills 目录纳入版本管理，或者每隔一段时间做一次快照备份。

实际操作中最简单的方式是：每个技能目录里放一个CHANGELOG.md，每次修改后追加一行记录，改了什么、为什么改。别小看这个习惯，等技能数量超过十个，你会回来感谢这句话。至少我自己靠这个文件找回过不少次"上次改了什么导致行为变化"的答案。

6.5 适度原则：技能库也需要做减法

装技能这件事是有瘾的。看到社区里有人分享一个好用的技能就觉得必须装。等到技能目录膨胀到几十个项目，你会遇到一个问题：Agent 选择技能的判断成本变高了，训练和测试时间也变长。

我的做法是"三进一出"规则：每新增一个技能，至少审视一次现有技能，把三个月内没用过的、功能重叠的全部清理掉。保持技能库精简，比追求数量有意义得多。

最后再分享一个实用习惯：每次做跨平台迁移，我在新平台验证成功后都会把当时的命令、目录路径、遇到的小问题记录在技能目录的 README 里。这种笔记既是个人的知识资产，未来团队协作时也能直接共享，价值远超临时记忆。希望这篇经验能帮你少走几步弯路，在自己的 Agent 工作流里把 Skills 真正跑顺。