Agent Skill 智能体技能完全拆解：从渐进式加载原理到多工具实战落地

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

一句话先给结论：Agent Skill（智能体技能）= 一份 SKILL.md 说明书 + 可执行脚本 + 按需加载的参考资料，它靠"渐进式加载"在不撑爆上下文的前提下，把零散提示词升级成一套可复用、可分发、可串联的标准作业流程。 它和 MCP 不是替代关系——MCP 解决"工具怎么连"，技能解决"流程怎么走"，两者组合起来才是完整闭环。技能最核心的省钱机制是三层加载：L1 只读名称描述（几十 token）、L2 用到时才读主体说明（几百 token）、L3 真正触发时才拉参考文档和脚本，没用到的内容一律不进上下文。本文会把"为什么需要技能、技能由什么组成、底层怎么加载、怎么写出能用的技能、怎么在 CLI/IDE 里跑通、怎么打包部署、怎么做安全审查"一条线讲透，并配上目录结构、流程图和示例代码。想看完整拆解，往下翻。

一、先把问题摆上桌：长提示词为什么总在复杂任务上翻车

我自己刚开始折腾智能体那会儿，干过一件特别费劲的事：为了让一个 AI 助手"既能整理会议、又能写文档、还能查规范、顺便把结果发出去"，我吭哧吭哧写了几百行系统提示词，把所有规则、所有边界、所有格式要求一股脑塞进去。简单任务跑得挺漂亮，一进到真实的复杂业务流程，它就开始抽风——解决了第一个问题，第二个问题又冒出来；好不容易第二个对了，第一个又跑偏了。相信不少人都有过这种"按下葫芦浮起瓢"的体验。

后来我才想明白，这背后其实是一个本质矛盾：自然语言天生是模糊的，而工程交付要求的是严谨的。你用一长段话去描述一套多维度、非线性的复杂逻辑，模型在执行时很难每一步都精准对齐你的意图，偏差几乎是必然的。

把翻车的原因摊开看，主要是三类。

第一类是注意力被稀释。大模型底层是 Transformer 的注意力机制，说白了它在"读"上下文的时候，精力是有限且会分配的。提示词越长、对话轮次越多，上下文窗口被填得越满，模型对其中某些细节的"关注度"就越低。结果就是——它看起来好像理解了你所有要求，真到执行时却把一些关键细节给"忘"了。你跟它聊得越久，越容易出现幻觉、越容易蹦出莫名其妙的回答，根子就在这儿。

第二类是流程失控。一个庞大的任务如果没拆开，模型在多步推理里很难维持逻辑一致性。步骤一多、彼此一耦合，它就容易乱套。这跟我们人做事是一个道理：一个大项目甩给你，你也得先拆成阶段、再拆成任务、排好优先级，一步步推进；指望一口气从头干到尾不出错，不现实。

第三类是工具调用混乱。一旦任务涉及外部能力——查天气、查地理位置、调第三方接口——如果这些工具没在提示词里说明白，模型经常会"找不到工具"或者识别错。更要命的是，工具定义本身就很吃 token，没有清晰的触发场景描述，调用出错的概率会进一步放大。

我把这三点画成一张图，方便你建立整体印象：

flowchart TD
    A[一坨超长系统提示词] --> B[上下文越来越长]
    B --> C1[注意力稀释<br/>细节被忽略 / 幻觉]
    B --> C2[流程失控<br/>多步推理逻辑不一致]
    B --> C3[工具混乱<br/>找不到工具 / token 浪费]
    C1 & C2 & C3 --> D[复杂任务翻车]
    D --> E[需要一种新组织方式：Agent Skill]

这就引出了技能（Skill）这个东西。它的思路不是"把规则写得更长更全"，而是反过来——把一个大能力拆成边界清晰的小模块，每个模块只负责一件事，用到哪个才加载哪个。这跟我们做事时"大任务拆小任务、各自完成再汇总"的逻辑完全一致。接下来我就从最基础的概念开始，一层层讲清楚它到底是什么、怎么运转、怎么落地。

二、Agent Skill 到底是什么：一句话讲清"技能三件套"

技能这个词，翻译过来就是"技能"，理解起来其实不绕。你打游戏的时候，一个英雄有很多技能，每个技能负责打出某种效果、某段伤害。智能体的技能也是一个意思：它就是要去实现某一个特定的功能、某一种特定的能力。 你完全可以把它当成一份"能力使用说明书"来理解。

这里要先和一个老概念划清界限——函数调用（function calling）。很多人会问，函数调用不是早就能让模型调代码、调接口了吗，技能跟它有啥区别？区别还真不小。函数调用本质上只是"一次 Python 函数执行"或者"一次 API 调用"，它是个点状的动作。而技能是个组合体，它不光能调函数，还能携带提示词约束、参考资料、触发规则，是一套"打包好的工作方式"。

用我自己的话总结：函数调用是"一把锤子"，技能是"一份带锤子的施工说明书"。

再往深里说一层。函数调用解决的是"模型怎么把一个动作执行出去"——它本质是把模型的意图翻译成一次确定的程序调用，调完拿到返回值就结束了，模型并不知道这个动作前面该铺垫什么、后面该收尾什么。技能不一样，它把"什么时候该调、调之前要先准备什么、调完拿到结果怎么处理、出错了走什么兜底"这些上下文一并打包进去了。换句话说，函数调用是"招式"，技能是"招式 + 心法 + 出招时机"。我自己的体会是，当一个任务只有一两步、且边界很清楚时，裸函数调用就够了；可一旦任务有了"先后顺序、条件分支、要参考资料"这些复杂度，光靠函数调用拼起来会很脆，这时候就该上技能了。

一个标准技能，由三部分组成，我习惯叫它"技能三件套"。

第一件：SKILL.md（核心说明书，必选）。 这是整个技能唯一不能少的文件。它说明这个技能是干什么用的、用在什么场景、有哪些步骤、有哪些注意事项。还拿游戏技能打比方——这个技能造成多少伤害、攻击范围多大、什么时候放——这些最基本的信息，你得先在说明书里写清楚。文件开头有一段 YAML 格式的元数据（frontmatter），最关键的就是 name 和 description 两个字段，它俩决定了模型"什么时候想起来用这个技能"。

第二件：脚本（scripts，可选）。 技能不光能调大模型生成内容，还能执行真实的程序逻辑。这正是它被叫做"Agent Skill"的原因——单个技能本身是"死"的，它需要一个智能体（Agent）来驱动执行。比如你要调用本地的一段 Python 脚本去上传文件、压缩数据、访问某个内网服务，光靠大模型生成文字是办不到的，必须落到脚本上跑。完成复杂任务时，脚本往往是绕不开的一环。

第三件：reference（参考资料，可选）。 这相当于技能自带的一个小知识库。举个我常用的例子：让 AI 帮你做"周报汇总"，它得按公司的规范来写吧？如果你们公司有一套报告格式规范、有一套术语标准，那 AI 在汇总时就应该参考这些文档，而不是自由发挥。这跟新人进公司干活要先翻规章制度是一个道理——reference 就是给智能体"翻"的那本制度。

这时候很多人会冒出一个疑问：我把参考文档直接写进提示词里不就行了，为啥还要单独搞个 reference？ 这个问题问到点子上了，答案恰恰是技能最大的优化所在，我放到第四章的"渐进式加载"里专门讲——简单说就是为了省 token、省成本，用到哪份文档才加载哪份，而不是一上来把几十上百个文档全塞进上下文。

整套技能的目录结构长这样（这是一个我虚构的"周报助手"示例，方便你看清层级）：

.（你的项目根目录）
└── <工具规范目录>/            # 比如 .claude / .codebuddy / .codex 等
    └── skills/                # 技能总目录，下面可以放多个技能
        ├── weekly-report/      # 技能一：周报助手
        │   ├── SKILL.md        # 必选：说明书 + 元数据
        │   ├── references/     # 可选：参考资料（知识库）
        │   │   └── report-style.md
        │   └── scripts/        # 可选：可执行脚本
        │       └── upload.py
        └── data-clean/         # 技能二：数据清洗（同样的三件套结构）
            └── SKILL.md

我把"三件套"各自的职责、是否必选、可以放什么，整理成一张表，新手对着看一眼就清楚：

所以技能从来不是一段简单的脚本，它是一套 SOP（标准作业程序）+ 工具 + 知识库 的组合概念。这个认知打底了，后面理解它的运行原理才不会绕。我自己带人时，第一件事就是先把这张表讲明白——莫潇羽@无忆研习社这边踩过的弯路告诉我，概念没立住，后面调试再卖力也是事倍功半。

三、和提示词、MCP 比，技能到底解决哪一层问题

要把技能讲透，绕不开它和"提示词"以及"MCP"的关系。这三个东西经常被混着说，但它们解决的根本不是同一层问题。

先说 MCP（Model Context Protocol，模型上下文协议）。这是一个由行业推动的开放标准，最早在 2024 年底被提出，核心目的就一个：解决大模型访问各种外部数据和工具时"接口不统一、每接一个都要单独写一遍"的麻烦。我特别喜欢官方那个比喻——MCP 就是"AI 世界的 USB 接口"。USB 解决的是各种外设接电脑的问题，键盘、鼠标、U 盘，只要支持 USB 协议就能被识别；MCP 解决的是大模型接各种 API、各种本地文件、各种服务的问题，只要某个服务实现了 MCP 服务端，客户端就能标准化地接进来。在 MCP 出现之前，连 N 个模型和 M 个工具是个 "N×M" 的噩梦，每条连接都要定制；有了 MCP，这事被抹平成了一套标准协议。

那技能和 MCP 比，解决的又是什么？我用做菜来打个通俗的比方，一下就清楚了：

• 快捷指令 / 一键功能，好比微波炉上的"一键解冻"按钮——单一、固定、死板，按一下只能干一件特定的事。
• MCP 工具，好比厨房里的刀具——通用性强、能力强，但它本身不会自己动，需要有人来指挥。
• 技能（Skill），好比一份菜谱——它解决的是"标准流程（SOP）"的问题。做一道菜，你得知道步骤、火候、用什么刀、注意哪些细节，技能就是把这一整套流程化、自动化地驱动起来。

我把三者的差异列成表，这是新手最容易搞混的地方，建议存一下：

讲到这儿要强调一个常被忽略的点：MCP 和技能不是二选一，它俩是搭配着用的。 MCP 负责把外部能力接进来，技能负责把这些能力按一套标准流程编排起来。前者管"有没有工具可用"，后者管"拿到工具后怎么一步步把活干完"。我自己在实际项目里，经常是先用 MCP 接好接口，再用技能把"先做什么、再做什么、用哪份规范校验、最后怎么交付"串成闭环。

补一句行业背景，方便你建立坐标系：现在这套"用 Markdown 文件给智能体下指令"的做法，背后还有一个更通用的开放约定叫 AGENTS.md——它被定位成"写给 AI 智能体看的 README"，本身就是一个纯 Markdown 文件、没有强制字段，目前已被数万个开源项目采用，并被多家主流 AI 编程工具支持。技能规范和 AGENTS.md 这套思路是一脉相承的：用人能读、AI 也能读的纯文本，把"该怎么干"沉淀下来。理解了这层，你就明白为什么各家工具的技能写法高度相似、还能互相移植了。

落到实操上，我给你一个判断顺序，免得纠结：手头任务只是缺一个外部能力（查接口、连数据库、读某个系统），那是 MCP 的活，去接 MCP；任务有一套固定流程、要按规范一步步走、还会反复发生，那是技能的活，去写技能；要是两者都沾——既要连外部系统、又要按流程编排——那就 MCP 负责"连"、技能负责"编"，搭配着上。我自己现在做内部工具，基本都是这个判断逻辑，省去了大量"到底该用哪个"的内耗。莫潇羽@无忆研习社后面也会单独出一篇 MCP 的实操拆解，这里先把边界讲清楚。

四、核心机制：渐进式加载（Progressive Disclosure）的三层结构

这一章是全文最关键的地方，技能省钱、能扩展、不撑爆上下文，全靠这个机制。我自己理解透它，是在反复对比"为什么技能比裸提示词便宜"之后才彻底通的，所以这里我尽量讲得细一点。

机制的名字叫渐进式加载（业内也叫 Progressive Disclosure，渐进式披露）。一句话概括：智能体不是一上来就把技能的全部内容塞进上下文，而是像翻一本组织良好的手册——先看目录，需要时再翻到具体章节，最后才去查附录。 信息分层加载，用到哪层才加载哪层。

它分成三层，我习惯叫 L1 / L2 / L3。

L1：元数据层（Metadata）。 智能体启动、扫描所有可用技能时，只读取每个技能的 name 和 description，编译成一小段 YAML 塞进系统提示词里。这一层极轻，按行业公开的说法大约只占 100 个 token 上下。它的作用只有一个——让模型"知道有这么个技能存在、大概什么时候该用它"，但绝不把说明书全文加载进来。所以你哪怕装了几十上百个技能，启动时也几乎没有上下文负担。这就是技能能"无脑多装"的底气。

L2：技能主体层（Instructions）。 当模型根据用户意图判断"该用这个技能了"，它才会去读取 SKILL.md 的正文——也就是详细的工作说明、步骤、规则。这一层的体量适中，通常控制在几百到几千 token（官方建议 SKILL.md 正文保持在 500 行以内，超了就拆文件）。也就是说，没被触发的技能，它的正文永远不会进你的上下文。

L3：资源与脚本层（Resources）。 这是真正的"按需加载、按需执行"。只有当任务确实需要某份参考文档或某段脚本时，模型才会去读 references 里的知识库、或调用 scripts 里的脚本。比如一份几十上百页的内部规范，平时压根不加载，只有当对话里真的命中了相关话题，才去把它拉进来。脚本同理，命中"上传 / 同步"这类意图时才去执行。

我把三层的加载时机和大致 token 量级整理成表（token 数是数量级示意，不是精确值，实际取决于你的文件大小）：

为什么这么设计能省钱？道理很直白：用 AI 的接口是要按 token 计费的，一个中文字符大约折合 2 个 token，一个英文单词大约 1 个。如果你把所有规范、所有手册一股脑全加载，几十上百页内容动辄几万 token，每次对话都背着它跑，成本会非常吓人。渐进式加载把"不一定用得到"的内容延后到"确实要用"的那一刻才加载，没命中就不掏这份钱，上下文也更干净、模型注意力更集中。

我给你算一笔很粗的账，体会一下差距。假设你有 20 份内部规范文档，每份平均 3000 字，全量加载差不多是 20 × 3000 × 2 = 12 万 token。如果走"全塞进提示词"的老路，哪怕这次对话只用得上其中一份，你也得为这 12 万 token 买单，而且每轮对话都重复掏一次。换成渐进式加载：启动时 20 个技能的 L1 元数据加起来可能就两千 token 出头；这次真正命中了一份规范，才加载那一份的几千 token；其余 19 份一个字都不读。两种方式的成本差出一个数量级，这还没算"上下文太满导致模型分心、结果变差"的隐性损失。规模越大，技能这套机制的优势越明显——这也是它敢宣称"能装无限多技能而几乎不增加上下文负担"的底气所在。

下面这张图，展示了一条用户消息触发技能后，上下文是怎么一层层"长大"的：

sequenceDiagram
    participant U as 用户
    participant A as 智能体
    participant S as 技能文件系统
    Note over A: 启动：只载入所有技能的 L1 元数据（很轻）
    U->>A: 发来一段需求
    A->>A: 比对意图，命中某个技能
    A->>S: 读取该技能 SKILL.md 正文（L2）
    S-->>A: 返回步骤与规则
    A->>A: 判断是否需要参考资料 / 脚本
    A->>S: 命中规范话题 → 读 references（L3）
    A->>S: 命中"上传"意图 → 调 scripts（L3）
    S-->>A: 返回知识库内容 / 脚本执行结果
    A-->>U: 交付结果

配一段虚构的 SKILL.md 示例，你能直观看到三层是怎么写在一个文件里的（这里我用"周报助手"做例子，纯属演示）：

---
# 这部分就是 L1 元数据：启动时被加载，决定何时被想起
name: weekly-report-helper
description: 把零散的工作记录汇总成规范周报。当用户提到"周报""汇总本周工作""周总结"时触发。
---

# 周报汇总助手（以下正文属于 L2，触发时才加载）

你是一名严谨的周报整理助手，按以下维度提炼工作记录：
- 本周完成事项
- 进行中事项
- 风险与待办
每个维度用一句话概括，不要堆砌。

## 参考规范（L3：命中时才加载）
当内容涉及"报销 / 预算 / 采购"等字眼时，必须参考 references/report-style.md 中的格式规范。

## 上传（L3：命中时才执行）
当用户提到"上传 / 同步 / 推送到云端"时，调用 scripts/upload.py，
把生成好的周报作为 content 参数传入。

看明白这段，你基本就握住了技能的命门：该轻的时候极轻（L1），该详的时候才详（L2），该花钱看知识库、跑脚本的时候才花（L3）。 这套"按需"的哲学，正是它比裸提示词高明的地方。

五、一个技能的完整生命周期：从意图识别到结果反馈

把原理讲完，咱们顺一遍技能从被"想起"到"干完活"的完整链路。我把它拆成四个动作，记住这四步，调试时出问题你就知道卡在哪一环了。

第一步：意图匹配。 用户抛来一个问题，智能体拿它去和所有已加载的 L1 元数据比对，看哪个技能的 description 最贴合。这一步有两种触发方式：一种是显式调用，你直接点名"用周报助手帮我汇总"；另一种是自动触发，你只是正常聊天，话里带了"汇总本周工作"，它自己就把对应技能匹配上了。两种方式效果没本质区别，区别只在于你是不是明说。

第二步：读取手册。 命中之后，智能体去读这个技能目录下的 SKILL.md，把正文（L2）加载进来，相当于翻开操作手册看清楚"这活该怎么干"。

第三步：按需执行。 接下来它边干边判断：要参考资料就去引用 references 里的知识库；要跑程序就去调 scripts 里的脚本。注意，这一步是动态的——命中规范话题才读规范，命中"上传"才跑上传脚本，不命中就跳过。

第四步：结果反馈。 整套动作跑完，给你一个可验收的结果，并告诉你它做了什么、产物在哪。

一张流程图收一下：

flowchart LR
    A[用户提问] --> B{意图匹配<br/>比对 L1 元数据}
    B -->|命中| C[读取 SKILL.md 正文 / L2]
    C --> D{是否需要资源 / 脚本?}
    D -->|需要规范| E[引用 references / L3]
    D -->|需要执行| F[调用 scripts / L3]
    D -->|都不需要| G[直接生成]
    E & F & G --> H[结果反馈 / 交付产物]

这套链路和我们人类干活的逻辑几乎一模一样：先听懂需求（意图匹配），再翻一下该怎么做（读手册），需要查资料就查、需要动手就动手（按需执行），最后把成果交出去（反馈）。理解这一点，你写技能时就会自然地按"人怎么做事"去组织它，而不是硬塞一堆规则。

这条链路对调试也极有价值。技能没按预期工作时，你顺着四步定位就行：根本没被想起来，问题多半在第一步——description 的触发词没写对；想起来了却乱来，问题在第二步——SKILL.md 正文的步骤、边界没写清；该查的资料没查、该跑的脚本没跑，问题在第三步——L3 的触发条件或路径有误；结果出来了但形态不对，那就是第二步的输出格式约定没说死。我自己排错时，基本就是拿这四步当"分诊台"，一格一格往下排，比漫无目的地改提示词高效得多。

六、怎么写出一个"能用"的技能：单一职责与工程实践

知道了原理，落到笔头上，怎样才算一个好技能、怎样是个烂技能？我把自己踩过坑总结出来的几条原则摆在这儿，照着写，质量一般不会太差。

最重要的一条：单一职责。 一个技能只干一件事，别让它身兼数职。这也是新手最容易犯的错——总想着写一个无所不能的超级技能，结果它什么都干不利索。技能要做到"原子性"，专注、单一，描述清晰，并且可组合。就像玩游戏，单个技能各管一摊，两个技能搭配着放，效果反而更强。

对照着看，好技能和烂技能的差别一目了然：

写法上，有几个我每次都会做的动作：

一是把 description 的触发词写到位。 元数据里的 description 不只是"介绍"，它直接决定模型"什么时候想起来用你"。所以要把适用场景、典型触发词都写进去。这一条我吃过亏——描述写得太泛，技能装了却死活不被触发，排查半天才发现是描述里没埋对关键词。

二是给清晰的示例。 在 SKILL.md 里写明"输入长这样、输出长这样"，把你最终想要的格式直接示范给它。你定义好一个格式，它最终就照这个格式输出，省去反复纠偏。

三是定义人设角色。 比如"你是一名严谨的周报分析师"，角色立住了，输出的专业度和稳定性都会上一个台阶。

四是约定接口与规范。 比如统一用 Markdown 输出、字段含义说清楚、边界划明白。这里我要特别强调一个被很多人忽略的点：写技能时，不光要写"让 AI 做什么"，还要写"让 AI 不做什么"。 大模型底层是"预测"，预测天生带随机性，你不给它划边界，结果就容易飘、容易出幻觉。把预测范围圈得越小，结果越精准。

下面是一段把"角色 + 输入输出 + 边界"都写清楚的 frontmatter 与正文示例（仍以虚构的周报助手为例）：

---
name: weekly-report-helper
description: |
  把零散工作记录汇总成规范周报。
  触发词：周报、汇总本周工作、周总结、本周复盘。
---

# 角色
你是一名有十年经验的周报分析师，输出克制、结论先行。

# 输入
用户给出的零散工作记录（可能是几条流水账）。

# 输出（务必遵守此格式）
## 本周完成
- ……（一句话一条）
## 进行中
- ……
## 风险与待办
- ……

# 不要做的事
- 不要编造未发生的工作
- 不要输出与周报无关的寒暄
- 涉及金额时，必须以 references 中的规范为准，不得自行假设上限

到了企业级场景，技能就不能是孤零零一个了，得设计成"带衔接的工作流"。我前面说技能可组合，落到企业里就是：把每个技能当成一个角色环节，上一个环节的输出，作为下一个环节的输入。就像一家软件公司里有需求分析、技术架构、任务规划、编码、代码评审这些岗位，彼此是接力的。

flowchart LR
    A[需求分析<br/>产出需求文档] --> B[技术架构<br/>产出设计方案]
    B --> C[任务规划<br/>拆成可执行 TODO]
    C --> D[编码执行<br/>按规范实现]
    D --> E[代码评审<br/>把关质量]
    E --> F[高质量交付]
    subgraph 思考阶段
      A
      B
      C
    end
    subgraph 执行阶段
      D
      E
    end

我自己的经验是：个人玩票的小技能，单输入单输出就够了；但真要上企业级，一定得考虑这种衔接性，把"思考（需求→架构→规划）"和"执行（编码→评审）"串成一条流水线，质量才稳得住。莫潇羽@无忆研习社这边做过几个内部技能，最后能跑顺的，无一例外都是把职责拆细、再用工作流串起来的那种。

七、动手搭建：在 CLI / IDE 里从零跑通一个技能

理论讲够了，咱们实操一遍。我自己试下来，不管用哪种工具——AI 编程的命令行（CLI）、AI 代码编辑器（IDE），还是可视化平台——搭技能的套路是高度一致的，差别只在目录规范的名字不同。这也正是"遵循开放规范、一次编写多处可用"的好处。

第一件事，是建对目录。 各家工具都约定：在项目根目录下建一个"点开头"的规范目录，再往里建 skills，每个技能一个独立文件夹。规范目录的名字随工具而变，但层级结构一样：

项目根/
└── .<工具规范目录>/      # 不同工具名字不同：.claude / .codebuddy / .codex / .trae …
    └── skills/
        └── weekly-report/
            ├── SKILL.md           # 必选
            ├── references/        # 可选
            │   └── report-style.md
            └── scripts/           # 可选
                └── upload.py

命名我踩过一个坑，提醒一句：技能名、目录名优先用英文。中文不是不能用，但个别工具在编码识别上偶尔会出岔子（比如冒出乱码、或元数据没被正确解析）。用英文命名最稳，正文内容用中文完全没问题。

第二件事，是把 SKILL.md 按 L1 → L2 → L3 递进写出来。 我建议分三步验证，别一口气全写完就跑。

第一步，先只写 L1 元数据（name + description），存盘后让工具识别一下"你有哪些技能"。这里有个高频小问题：刚创建完，工具可能因为没刷新而识别不到。我的做法是——退出当前会话重进，或者干脆重开一个新对话让它重新加载上下文，一般就出来了。如果还不行，多半是 frontmatter 的 YAML 格式写错了（比如缩进、符号），用 IDE 打开看高亮就能发现。这也是我推荐用 IDE 写技能的原因：格式错了能一眼看出来，纯命令行有时候哪错了你都摸不着头脑。

第二步，补上 L2 正文，写清楚这个技能要干的事。比如周报助手要做两件事——汇总、上传——就把规则、示例、输出格式都写进去。写完直接拿一段示例需求去触发它，看输出是不是按你约定的格式来的。

第三步，挂上 L3 的参考资料和脚本。参考资料放进 references/，脚本放进 scripts/。验证"按需加载"是否生效，最直观的办法是对比两条输入：一条不涉及规范、