先说句实话。大半年前有人跟我讲 Agent Skills 的时候，我内心是有点不屑的------"这不就是一段 prompt 吗？换个文件夹存起来而已。"我当时是这么想的，也这么跟别人说的。
后来证明，我错得挺离谱。
一开始，我真的只当它是段提示词
Skill 最朴素的样子，确实就是一份说明书。一个文件夹，里面一张 SKILL.md，写清楚三件事：什么时候该用它、具体怎么干、干到哪一步算完事。
我最早写的一个 Skill 长这样，前后就十几行：
yaml
---
name: 周报草稿
description: 把项目记录整理成周报草稿，只写草稿不发送
---
读指定的项目记录。
把进展、风险、待确认分开。
缺的材料别瞎编，标成"待确认"就行。说真的，这东西能跑。我丢给 Agent，它确实能照着写出个像样的周报来。我当时还挺得意，觉得"看吧，就这么简单"。
但用着用着就开始出问题。同一个需求，换个问法它就不认了；该触发的时候装死，不该触发的时候又抢着上。我一开始的解决办法很粗暴------往 description 里堆词，堆到都快成小作文了。
后来才明白，问题根本不在这。
description 是唯一被认真读的那几行字
Agent 决定要不要用你，基本只扫一眼名称和 description。正文它要等任务匹配上了才去翻。这个机制有个名字，叫渐进式加载。
我当时不知道这一点，把一堆关键规则全塞进正文里，description 却写了句废话："帮助处理项目相关事务。"
结果可想而知。它要么不触发，要么乱触发。
写 description 有个很朴素的标准：把你真实会跟助手说的话写进去。不是"帮助处理项目内容"，而是"生成项目周报、整理本周进展、汇总风险"。前者是写给空气看的，后者才是你礼拜五下午真的会打字问出来的话。
还有个我踩过的坑。我第一次测试只问了一句"帮我写周报"，跑通了就以为成了。后来发现换个说法"这周进度整理下""帮我看看这周有什么风险"，它就抓瞎了。
正确的测法，是提前写好几条边界用例再动手：正常请求一条、信息不全一条、踩红线的一条。比如周报这个 Skill，我后来固定测这三条------"根据本周记录写更新"（该触发）、"记录不全帮我写得积极点"（该触发但不能编进度）、"整理完直接发群里"（只能给草稿，不能真发）。
这三条顶得上我当初写的一整段宏大定义。
这里补一句当时没想明白、后来才懂的道理：为什么"先写测试用例再写 Skill"这么重要。因为 Skill 本质上是一份写给"另一个执行者"的契约，而契约最难写的地方从来不是正文，是边界。你心里清楚"什么时候不该触发""缺材料时该怎么办"，但你不把它们提前写成测试，Agent 就永远只能靠猜。等它在真实环境里猜错一次，你要花的时间远比你当初省下的那十分钟多。这个账我算过很多遍，每次都是"早点写测试"赢。
内容一多，单文件就开始撑不住
小 Skill 用久了，正文会像滚雪球一样越滚越大。周报要分红黄绿状态了，要套公司模板了，要检查日期和负责人有没有漏了。继续全塞进一张 SKILL.md，主线很快就看不见了。
这时候才轮到拆文件。开放规范里约定了几类目录：references/ 放业务制度、字段说明、API 文档这些参考资料，assets/ 放模板和成品素材，scripts/ 放那些该由脚本干的确定性操作。还有一类 evals/ 是企业和项目常用的，规范没强制，但放测试用例和预期结果挺好使。
关键不是"拆"这个动作，而是拆完之后，主文件得告诉 Agent 什么时候去读哪一份。我后来在周报 Skill 的主文件里写了这么三句：
bash
生成周报前先读 references/status-policy.md 判断状态。
输出套用 assets/status-template.md。
草稿出来后跑 scripts/validate_brief.py，报错就改，不许跳过。这三句值回了我折腾一个下午的时间。
拆文件这件事，很多人有个误解，觉得"拆得越细越专业"。我一开始也这么想，差点把每个字段说明都单独拆成一个文件，结果 Agent 要来回跳七八个文件才能凑齐一个周报，反而更容易漏。后来才反应过来：拆文件的目的是"按需加载省上下文"，不是"为了拆而拆"。当前这个任务用不到的文件，就不该让它进上下文；但当前任务必须一起看的东西，硬拆开只会帮倒忙。这个度没有公式，只能靠真实任务反复试。
有个度要自己把握。官方建议 SKILL.md 别超过五百行，这不是硬性规定，但确实是个信号------到了这个量，执行路线、参考资料、样例多半已经搅在一起了。
至于脚本，我一直克制着不加。模型擅长理解模糊文字，脚本擅长处理确定规则。判断一段风险描述清不清楚，交给模型；检查日期格式对不对、文件名漏没漏、字段全不全，用脚本更稳。这个分工想清楚了，才不会什么都想往脚本里塞。
接外部能力这件事，边界得先想明白
前面的 Skill 无非是对话加本地文件。等真正进了企业，就要查知识库、读业务系统、调接口，甚至写数据。API、MCP、Tool 是从这里开始登场的。
但有一条底线我后来才真正吃透：Skill 能描述怎么用一样能力，也能带上调用脚本，但它变不出网络、权限和凭证。
拿知识库举例。假设公司已经把知识库封装成查询接口，接法无非三种：让脚本直接调 HTTP、把查询做成 MCP Tool 让 Skill 指导 Agent 什么时候搜、或者在运行时注册成自定义工具让 Skill 只写规则。知识库负责给事实，接口负责给入口，Skill 负责决定怎么查、怎么判断、怎么写。这三样别揉成一个词。
MCP 地址能不能写进 Skill？能写名称、用途、需要的工具和连接条件，也能附一份配置模板。但这些文字只是在声明"我依赖这个东西"，并没有真的建立连接。地址、认证、权限还是得在宿主或 Agent 配置那一层完成。密钥尤其不能写进 Skill，我见过有人这么干，后来肠子都悔青了。
跨平台的时候，最稳的做法是把"工作方法"和"连接实现"拆开。Skill 里写清楚依赖和降级方案，连接、密钥、权限留在运行时。
边界那点事，我吃过一次具体的亏
进阶阶段回头看几个名词，就没那么较劲了。知识库、MCP、Agent、Workflow，它们根本不在同一层，谁也不用抢谁的定义。
我们公司有段时间专门开会讨论 Skills、MCP、Agent、Tools 的边界，想先把分级定义到毫无争议。一个月过去，定义还在改，隔壁竞品已经上线了能用的东西。
这个教训挺具体的。边界当然要懂，但别一开始就犯"大厂病"。先挑个真实任务做出来，跑一遍，从结果里自然能看出哪部分是方法、哪部分是连接、哪部分必须走确定性流程。很多争论，做到那一步就自己消失了。
我后来把这段经历讲给一个刚接手 Skills 的同事听，他的反应是"那到底什么时候才该去搞清楚这些名词？"我的回答是：等你手上那个 Skill 已经能稳定跑通、开始觉得"光靠这一份文件不够用了"的时候。到那时，你自然会撞上"这里该不该接知识库""这个操作该不该交给 MCP"这类问题，而这些问题一旦是带着真实场景去问的，答案就清楚多了。名词不是拿来背的，是拿来在需要的时候去查的。
多个 Skill 配合，别当成 import
单个跑通之后，下个问题几乎必然是：能不能让 A 调 B？
组合多个 Skill 是可行的。ChatGPT 会在合适的时候自动用一个或几个，Claude Code 也能让用户或模型调用当前可见的 Skill。但开放规范到现在也没定义 dependencies: [skill-b] 这种通用依赖字段。
所以你在 A 里写一句"调用 Skill B"，不等于编程语言里的 import。它跑不跑得起来，看宿主开没开 Skill 调用、B 在不在可见范围、Agent 配置是什么样。
实际项目里我见到的处理方式就三种：偶尔配合的，在入口 Skill 里写清使用条件再拿真实请求测；经常一起上的，让 Agent 或角色包预装；顺序不能错还带审批重试的，交给 Workflow 编排。
Skill 也能写角色要求，比如"以安全审查员的视角检查数据流和凭证"。这改的是工作方式，不会自动换模型、换工具、换权限。要调独立 Agent，得看平台支不支持------Claude Code 有 context: fork 和 agent 字段，但那是它自己的扩展，换平台可能直接被忽略。
Skill 越做越大，先问它"大在哪"
Skill 可大可小，但别顺手做成万能包。判断一个大 Skill 有没有问题，得看它到底大在什么地方。
资料多一般不是坏事，大量 API 文档、业务制度、案例塞进 references/ 按需读就行。真正容易失控的，是任务范围和执行面一起变大。一个 Skill 又管销售分析又管客户邮件又管合同审查还管系统发布，description 怎么写都别扭------写宽了到处触发，写窄了又找不着。它要还能读文件、联网、调一堆 MCP、改系统、发消息，权限和故障点就一起膨胀了。
反过来，拆成几十个极小 Skill 也出事。每个的名称和描述都要参与发现，数量越多、描述越像，越容易选错。Anthropic 的 Claude API 每次请求最多带八个 Skill，其他平台也没有统一的"二十个""五十个"安全线。
我后来给自己定了个判断的土办法，就四问：触发请求近不近、产出一致不一致、权限近不近、负责人同不同。四项都差不多，可以留一个 Skill 里；有哪项明显分家了，就值得拆。
这套四问听着粗糙，其实挺管用。我举个例子。有段时间我把"客户邮件草拟"和"合同审查"塞进了同一个 Skill，理由很充分------都是"跟客户打交道"的事。结果呢？description 越写越长，因为要同时说清楚"能写邮件"和"能审合同"两个能力；权限也拧巴，写邮件只需要读客户记录，审合同却要碰一堆敏感字段。后来我用四问一量，发现这俩的权限根本不一样，拆开之后两个都顺了。所以别小看这种土办法，它能帮你把"感觉该拆"变成"确实该拆"。
测稳一个 Skill，靠的是把边界当测试对象
很多 Skill 第一次演示都能成，换个说法就失效。这里的问题通常不在正文写得少，而在没把触发、边界、异常当回事。
我给每个 Skill 备一小组评测，先覆盖五类：该触发的正常请求、不该触发的相似请求、说法模糊的边界请求、缺输入或工具挂掉的情况、跟别的 Skill 并存时还选不选得对。
周报 Skill 的负例，别只写"今天天气怎么样"这种没用的。写"修改 Jira 状态""给客户发进度""写项目复盘"才有价值------它们和目标够近，能真测出边界写没写清。
排错也别乱加字。顺序是这样的：压根没触发，先改名称和 description；触发了漏步骤，再改正文和文件导航；读到了规则还做错，补真实示例或把确定规则交给脚本；工具失败，查连接参数凭证权限；多个 Skill 抢任务，收窄描述或重新分组。
这套顺序省了我不少事。最怕的就是不管什么毛病都往 prompt 里加字------触发问题、连接问题、权限问题，正文写再长也白搭。
说到排错，还有个特别容易踩的坑得提一句：很多人一看到 Skill 表现不对，第一反应是"我正文写得太少了"，然后疯狂补字，越补越乱。其实大部分时候，问题根本不在正文，而在触发和连接这两头。触发问题去改 description，连接问题去查权限和凭证，正文里再写一万字也救不回来。这个顺序我吃了好几次亏才记住，现在写出来，就是想让后来的人少走一遍。
企业级那点额外的事，其实是责任问题
个人 Skill 自己用着顺就行。企业级 Skill 要能被别人用、被审查、被升级，出错了还找得到责任和退路。
先做安全分级。只读资料、生成草稿的，风险低；会发消息、改系统、部署代码、删数据的，得严审。而且权限不能只写在提示词里------Skill 里写"只读"，不会把一个可写 Token 变成只读。真正决定 Agent 能碰什么的，是用户身份、源系统 ACL、MCP 或 App 权限、沙箱和网络策略。
第三方 Skill 要按软件包审。除了 SKILL.md，还得看引用资料、脚本、外部地址、网络调用、子进程、硬编码凭证和数据外传路径。来源可信，不代表后续依赖永远可信。
然后才是版本和责任。企业 Skill 最好进 Git，走 PR 评审和测试再发，生产环境固定版本、留上一版、备好回滚。每个 Skill 至少得有人能回答这几个问题：谁维护业务规则、谁批准脚本和权限、生产版本是哪个、评测最近什么时候跑的、出事谁停用回滚。
还有共存测试。企业不会只装一个 Skill。新 Skill 上线前，除了单测，还得和同角色已经在用的那些一起跑，重点看它抢不抢触发、带没带输出退化、会不会把原本只读的任务领进更高权限的执行路径。
真正落地，不是上传成功就完事
FDE 落地 Skill 的路子，是跟着一线人员把一件真实工作完整走一遍，再决定 SKILL.md 怎么写。哪些判断靠经验、哪些事实来自系统、哪些步骤只是历史习惯，都得在现场看清楚。
然后把东西放回各自该去的位置：事实进知识库，系统能力接成 API 或 MCP，专家的判断方法写进 Skill，角色和工具组合进 Agent，定时状态审批重试交给 Workflow，身份权限留在 IAM 和源系统。
第一版只覆盖最常见、价值最好判断的几个用例。拿真实任务试跑，记下它漏读了什么、误用了什么、人工改了多少。证明有用之后，再做分发、版本、监控和交接。
一个 Skill 上传成功，不等于企业落地了。业务的人要知道怎么改规则，技术的人要能跑评测，平台的人要控制权限，出问题还得有人能停掉它。做到这一步，Skill 才不再是"一段更长的 prompt"，而成了企业做事方法的一种载体。
别一上来就研究名词，先做个最小的
回头看这大半年，我最大的体会就一句：学 Skills 不用先把 MCP、Agent、Tool、Workflow 的边界研究到毫无争议。
从一件你重复做过很多次的工作开始，写出最小的一份 SKILL.md，拿真实请求去测。规则多了再拆 references，确定操作交给 scripts，要外部数据了再接 API 或 MCP。等它开始影响多人、系统和数据了，再补权限、评测、版本和治理。
Skill 的大小没有标准答案。它可以是十几行提示词，也可以组织起知识库、工具和一整个 Agent。但说到底，判断它成不成的标准一直没变：它能不能让 AI 更稳定地把一件具体的事做好。
我当初那点"不就是段 prompt"的不屑，早就在一次次翻车里磨没了。现在再有人问我 Skill 是什么，我会说：它是一个能把"这次做对了"变成"下次还做对"的东西。
写到这里，突然想起一个挺有意思的细节。有回我和一个做传统软件测试的朋友聊起 Skills，他听完第一反应是"这不就是给 AI 写测试用例吗"。我想了想，觉得他说对了一半。Skill 确实像一份"活的测试驱动开发"------你先定义什么算完成、什么算做错，然后让 AI 照着这个标准去执行、去自检。但它比测试用例多了一层：测试用例只管"对不对"，Skill 还要管"怎么做、按什么顺序做、做的时候遵守哪些约束"。所以它更像是把"测试标准"和"操作手册"焊在了一起。想通这一点之后，我写 Skill 的心态就变了，不再追求把每一步都写得滴水不漏，而是先确保"什么算做对、什么算做错"这两件事清楚，剩下的细节可以慢慢补。
还有一件事也值得说。Skills 这东西现在还在快速变，规范、平台、工具几乎每个月都在动。我见过有人花很多精力去追每一个新特性，生怕自己落伍；也见过有人死守老写法，拒绝任何新东西。我觉得两个极端都没必要。真正该盯住的，始终是那个不变的问题：我要让 AI 稳定地做好一件具体的事，为了实现这个，现在手头最省事、最不容易坏的办法是什么。技术会变，这个问题的答案反而一直很朴素。说到底，Skill 教会我的不只是怎么写文件，更是一种做事的态度：把"这次碰巧做对了"变成"下次一定能做对"，靠的不是天赋，是老老实实地把边界、标准和步骤一次次写清楚、测明白。
我是薛定谔的悦，大厂储能领域的工程师，同时也一直在研究AI，欢迎交流学习