预计 4200 字 · 约 11 分钟读完 · 难度 ⭐⭐ 小白友好进阶段有代码照抄能跑核心价值今天就能亲手做出首个可反复复用的 Skill并带走一套「能力何时扩充、文件何时拆分」的判断标准过去一周DeepSeek Harness 刷屏了。8月13日DeepSeek 把自家的 Agent 框架 Harness 开源MIT 协议。仓库上线当晚 Star 破万如今已经冲向 17 万。我把整个仓库翻了个遍。真正让我坐直的不是它答得多好而是 README 里那句设计哲学一切皆插件。在这套框架里模型、工具、技能统统以插件形式存在。它甚至能在干活中途自己写一个新 skill 存起来下回遇到同类任务直接复用。于是评论区最常见的问题变成了skill 到底怎么上手但有个细节被大多数人错过了仓库自带 11 个官方 skill点开任何一个里面不过是一个文件夹加一份 SKILL.md。这跟你看完本文就能亲手做出来的东西结构上一丝不差。先把结论放在这里。Skill 被传得很玄其实它的最小形态就是一份教 AI 干活的说明书。说明书里要写清的只有三件事何时启用、步骤是什么、怎样才算干完。就这么点事。任务复杂起来之后你可以在说明书旁边陆续添加模板、案例、业务规则和脚本也可以教会 Agent 调用知识库、API、MCP 等外部工具。Skill 可小可大这是它的特点。但学习路径必须从前往后走先把一个能稳定复用的小 Skill 做出来能力再一项一项往上加。顺序一旦颠倒人容易陷进概念研究——三个月过去手里一个跑通的 Skill 都没有。这样的朋友我见得不少。接下来的路线从最小的 Skill 起步经过文件拆分、工具接入、评测一路讲到企业治理。MCP、知识库、Agent 这些词都会出现但全部放回具体场景里解释。一份说明书的最低配置先回答一个疑问它跟一段精心打磨的提示词差别在哪一段提示词的宿命是发在某个对话里任务一结束就散了。下回做同类的事你要么重打一遍要么在聊天记录里翻半天。Skill 把一类任务的做法固化成文件反复调用、分享同事、进 Git 做版本管理都行。提示词用一次就丢Skill 是留下来生息的资产。这是两者的分水岭。截至 2026 年 8 月Agent Skills 已经形成开放规范。规范约定的最低形态一个文件夹里面至少躺着一份 SKILL.mdmy-skill/ └── SKILL.mdSKILL.md 分两截顶部一段 YAML 登记名称和描述往下是正文写做事方法--- name: project-status-brief description: 根据项目记录起草状态简报。当用户要求生成项目周报、整理本周进展或汇总风险时使用。只生成草稿不负责发送。 --- # 项目状态简报 读取指定项目记录区分已确认进展、风险和待确认事项。 按公司模板生成草稿所有关键结论保留依据。Agent 平时的记忆只装着每个 Skill 的名称和描述任务对上号之后才去读正文正文又能指向更多资料。这个机制叫渐进式加载它替上下文省下大量空间。一份说明书哪怕只写成一段话也是合格的--- name: concise-review description: 审核中文文章中的重复、空话和机械总结。当用户要求精简文章或检查表达时使用。 --- 保留事实和作者判断。 删除重复解释、模板连接词和没有新增信息的段落。 不要补写作者没有提供的经历。用途明确、能被检索到、可以重复执行——三个条件它都满足。代码暂时一行都不用加。今晚就动手五个问题写出一个能用的第一个 Skill选题别贪。做行业研究成为销售专家这类宽任务不适合练手。要找的是你亲手做过许多次、成果好坏一目了然的那件工作。本文继续用根据项目记录写周报举例。动笔之前先把三条测试请求写下来1. 根据本周记录写一份项目状态更新。 → 应该触发读取规定来源生成草稿。 2. 记录不完整帮我写得积极一点。 → 应该触发但不能补造进度缺失内容进入待确认。 3. 整理完直接发到管理群。 → 可以生成草稿不能自动发送。这三行字比任何定义都管用第一条锚定正常场景第二条处理信息残缺第三条守住高风险动作的边界。接着把目录建起来mkdir -p project-status-brief touch project-status-brief/SKILL.md第一版主文件把五个问题交代清楚就够1. 什么样的请求会唤起它2. 要读哪些资料3. 步骤按什么顺序走4. 什么动作被禁止5. 干到什么程度算完。照着写--- name: project-status-brief description: 根据项目记录生成项目周报或状态简报。当用户要求整理本周进展、风险、下周计划时使用。只生成草稿不发送消息不修改项目系统。 --- # 工作步骤 1. 读取用户指定的本周项目记录。 2. 分成已完成、进行中、风险、下周计划和待确认五类。 3. 只把有记录支持的内容写成事实。 4. 信息不足时列入待确认不要补写。 5. 按模板生成简报草稿。 # 完成条件 - 每项进展能找到对应记录 - 风险包含负责人和下一步没有信息时明确留空 - 输出是草稿不执行发送或系统写入。description 值得你花最多的心思。Agent 判断要不要调用一个 Skill依据几乎全在这句话上。写成帮助处理项目内容等于没写生成项目周报、整理本周进展、汇总风险才是用户嘴里的原话。写完放进真实环境跑。ChatGPT 目前在 Plugins 的 Skills 页面支持创建、编辑和上传 SkillClaude Code 的个人 Skill 放在 ~/.claude/skills/skill-name/SKILL.md项目级放在 .claude/skills/skill-name/SKILL.md。其余支持 Agent Skills 的产品入口各异文件结构大体一致。测试环节别只丢一句帮我写周报。至少把上面三条全部跑一遍另加两条长得像但不该触发的请求比如帮我修改 Jira 状态给客户起草一份说明邮件。它要是到处抢活把 description 收窄该出场时找不到它就把用户的真实说法补进描述。到这里最小版本成立调用得上、按步骤走、结果可验收。资料多了给文件夹分房间一个 Skill 用上几个月正文自然越滚越长。拿周报来说状态要分红黄绿格式要贴公司模板日期和负责人还得查漏。全堆在 SKILL.md 一个文件里阅读路径很快会糊掉。这时候把隔壁房间打开project-status-brief/ ├── SKILL.md ├── references/ │ ├── status-policy.md │ └── source-map.md ├── scripts/ │ └── validate_brief.py ├── assets/ │ └── status-template.md └── evals/ └── evals.json开放规范给出了 scripts/、references/、assets/ 三类可选目录的定义其余摆放属于使用者的自由。evals/ 就是这样一类企业项目惯用的自定义目录规范本身没有强制要求。各房间的分工SKILL.md——任务入口、执行顺序、关键边界、完成条件references/——业务制度、字段说明、API 文档、长案例assets/——输出模板、图片、字体等成品素材scripts/——格式校验、数据转换、文件处理等确定性操作evals/——测试请求与预期结果用于回归。主文件还得充当导览员告诉 Agent 何时读哪份生成周报前先读取 references/status-policy.md 判断项目状态。 输出时使用 assets/status-template.md。 草稿完成后运行 scripts/validate_brief.py校验失败时修正草稿不要跳过错误。资料包再厚也不怕当前任务用不到的文件不必挤进上下文——这正是渐进式加载兑现价值的地方。官方建议把 SKILL.md 控制在 500 行以内。这个数字不是协议红线更像一条水位线水位逼近时多半意味着执行路线、参考资料和样例已经搅在一起了。脚本不急着写。模糊文字的理解是模型的强项确定规则的执行是脚本的强项。判断一段风险描述写没写清楚交给模型核对日期格式、文件名、必填字段脚本更可靠。我的实操体会值得进 scripts/ 的是那些每次都得人工过一遍的机械动作——格式、命名、必填字段。脚本写一次往后全自动。连接外部世界先认清那条边界前面的 Skill 只动对话和本地文件。真实的企业任务要查知识库、读业务系统、调接口甚至执行写入。API、MCP、Tool 从这里登场。先立一条底线Skill 可以描述一种能力怎么用也可以自带调用脚本但它变不出网络、权限和凭证。知识库的三种接法假设公司已把知识库封装成查询 API接入方式有三种由 Skill 里的脚本直接调 HTTP API把查询能力做成 MCP Tool让 Skill 指导 Agent 何时搜索或者把它注册为 Agent 运行时里的自定义工具Skill 里只落查询规则。周报 Skill 的查询规则长这样查询顺序第一步本周项目记录第二步最近一次决策碰范围、预算、交付日期只认现行版正式文件查无结果归入待确认模型记忆不得拿来充数。知识库出事实API 或 MCP 管入口Skill 定规则。三个词别混成一个。MCP 配置写在 Skill 里行不行Server 的名称、用途、所需工具和连接条件都可以写还能附一份配置模板--- name: customer-research description: 查询企业知识库并整理客户研究。当用户要求检索客户案例、产品资料或历史项目时使用。 compatibility: Requires the company-knowledge MCP server and read access ---正文再补充用哪个搜索工具、查不到时怎么处理。注意这些文字只是声明依赖和用法并没有建立连接。MCP 的地址、认证与权限一般交由宿主、Agent 配置或插件的连接层去落实密钥在任何情况下都不写进 Skill。OpenAI 当前的插件体系可以把 Skills 与 Apps、App templates 打包进同一个工作流外部系统连接由 App 及其权限负责。其他 Agent 平台也可能在 Agent 配置里同时声明 Skills、Tools 和 MCP Servers。建连接的是运行时教用法的是 Skill。API 调用规则怎么写直接写操作规则是一种做法调用客户查询工具时 1. 优先使用客户编号不根据模糊姓名修改记录。 2. 只读取当前用户有权访问的字段。 3. 查询失败时保留错误信息不连续重试超过两次。 4. 任何写入动作都要再次确认。另一种把确定的调用封装进 scripts/。脚本能跑不能跑取决于环境是否开放网络、有没有依赖和凭证。Anthropic 当前通过 Claude API 上传的 Skills 运行在无网络沙箱里访问不了外部 API本地 Agent 或企业自建运行时能否联网由各自环境决定。跨平台发布时把工作方法与连接实现分开处理Skill 里写清依赖和降级方式连接、密钥、权限留给运行时。Skill 之间怎么配合单打独斗跑通后下一个念头通常是Skill A 能不能叫 Skill B组合调用已经可行。ChatGPT 会在合适时机自动启用一个或多个 SkillsClaude Code 也支持用户或模型调用当前可见的 Skills。但开放规范目前没有定义 dependencies: [skill-b] 这样的通用依赖字段。所以在 A 里写一句调用 Skill B效果不等于编程语言里的 import。执行与否取决于宿主开放没开放 Skill 调用、B 是否在可见范围以及当前 Agent 的配置。实际项目里有三条路偶尔搭把手的两个 Skill在入口 Skill 写清使用条件用真实请求验证经常成组出现的一批 Skill让 Agent 或角色包预装它们顺序敏感、还牵扯审批重试和状态的把编排交给 Workflow。Skill 也能指定角色比如让 Skill 扮演企业安全审查员逐一排查数据流、凭证与不可逆操作。这改变的是当前任务的干活方式模型、工具和权限不会因此自动切换。调用独立子 Agent 要看平台支持。Claude Code 目前提供 context: fork 和 agent 扩展可以把 Skill 放进独立上下文交给指定子 Agent。注意这两个字段属于 Claude Code 的私有扩展并未纳入开放规范--- name: security-review description: 对当前方案进行安全审查 context: fork agent: enterprise-security-reviewer ---一旦迁移到其他平台这些字段面临两种命运被直接无视或上传环节就被拒收。要分别确认三件事子 Agent 预加载了哪些 Skill、能发现哪些 Skill、能调用哪些工具。太大和太碎都是病Skill 可大可小不代表可以顺手堆成一个什么都干的庞然大物。评估一个巨型 Skill先看它大在哪里。资料量大通常无害。成堆的 API 文档、业务制度和案例放进 references/ 按需读取就好。真正危险的是任务范围和执行面同步膨胀。一个 Skill 同时管销售分析、客户邮件、合同审查和系统发布description 注定写不准——写宽了到处触发写窄了叫不出来。它若还能读文件、访问网络、连多个 MCP、改系统、发消息权限和故障点会一起滚雪球。Claude Code 当前在自动压缩后每个重新挂载的 Skill 最多保留前 5000 tokens全部重新挂载的 Skills 共享 25000 tokens。内容过长或连续调用太多较早的 Skill 会被丢掉。这是 Claude Code 的实现细节别外推成所有平台的通用限制但它证明了一件事上下文预算会实际左右执行。另一个极端——碎成几十个微型 Skill——同样有代价。每个名称和描述都参与发现竞争数量越多、描述越接近选错的概率越大。Anthropic 当前的 Claude API 每次请求最多携带 8 个 Skills其他平台没有通用的20 个50 个安全线。拆不拆我看四个指标触发请求是否高度重叠产出物是否同构权限是否同级业务是否同一个负责人。四项大体重合留在同一个 Skill 里有一项明显分岔就到了拆的时候。换种说法就失灵把它测稳不少 Skill 的通病演示一次成功换个措辞立刻趴窝。病根不在正文写得短而在于触发条件、动作边界和异常路径从未被当作被测对象。给每个 Skill 配一小组评测覆盖五类情况1. 应触发的正常请求2. 不该触发的相似请求3. 措辞模糊的边界请求4. 缺输入、工具不可用、数据打架5. 与其他 Skill 同场时还选不选得对。周报 Skill 的负例别拿今天天气怎么样充数。修改 Jira 状态给客户发送进度写项目复盘才有含金量——它们离目标任务足够近才能真正检验边界写没写清。排错讲次序压根没触发先改名称和 description触发了但漏步骤改正文和文件导航规则读了还做错补一个真实示例或把确定规则移交脚本工具报错查连接、参数、凭证、权限多个 Skill 抢活收窄描述或重新分组。这套次序防的是同一个坑不分青红皂白往 Prompt 里堆字。触发、连接、权限三类问题正文写得再长也无解。进公司之后多出来的功课自己用标准是顺不顺手。公司用Skill 得经得起别人使用、被审计、被升级出事时找得到责任和退路。第一课安全分级只读资料、出草稿的 Skill风险天然低。会发消息、改业务系统、部署代码、删数据的 Skill审批、确认、审计一个都不能少。权限写在提示词里等于没写。Skill 里声明只读并不能把一个可写 Token 变成只读。真正决定 Agent 能碰什么的是用户身份、源系统 ACL、MCP 或 App 权限、沙箱和网络策略。第三方 Skill 要按软件包的标准审查SKILL.md 之外引用资料、脚本、外部地址、网络调用、子进程、硬编码凭证、数据外传路径逐项过。来源可信不代表它的依赖链永远可信。第二课版本与责任人企业 Skill 应该进 Git走 PR 评审加测试再发布。生产环境锁版本留好上一版和回滚路径。模型、工具 Schema、业务制度或数据接口一变回归重跑。每个 Skill 至少答得出这几个问题业务规则谁维护脚本和权限谁审批生产环境跑的哪个版本评测最近一次何时执行出事谁停用、谁回滚。第三课共存测试公司不会只装一个 Skill。新 Skill 上线除了单独测试还得跟同角色已在用的 Skills 同场跑会不会抢触发、会不会拖累输出质量、会不会把只读任务带进更高权限的执行路径。FDE 怎么把 Skill 落进企业FDE 的正确姿势先跟一线人员把一项真实工作完整走一遍再动笔写 SKILL.md。哪些判断靠经验、哪些事实来自系统、哪些步骤纯属历史惯性现场看得一清二楚。然后各归其位事实与正式材料进知识库系统能力接成 API、MCP、App 或 Tool判断方法沉淀到 Skill角色、模型与工具组合成 Agent定时、状态、审批、重试、补偿交给 Workflow身份与权限留在 IAM、运行时和源系统。第一版只碰最常见、价值最好判断的几个用例。拿真实任务试跑记录漏读、误用和人工干预量。验证有效才轮到团队推广、版本管理、监控与交接。Skill 上传成功离企业落地还差一整段路。业务人员会改规则、技术人员跑得动评测、平台团队管得住权限、出了事有人能踩刹车——几件事齐了Skill 才算从一段加长的 Prompt变成企业做事方法的可维护载体。从一件小事开始学 Skills不必先把 MCP、Agent、Tool、Workflow 的概念边界辩到滴水不漏。挑一件重复劳动写出最小的 SKILL.md用真实请求检验。规则膨胀了拆 references确定性操作交给 scripts需要外部数据再接 API 或 MCP。等它开始牵动多人、系统和数据权限、评测、版本、治理按需补齐。Skill 的体量没有标准答案。它可以只是一段提示词也可以统辖知识库、工具和 Agent。归根结底只看一条AI 能不能靠它把一件具体的事做得更稳。既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧如果可以给我个星标⭐将不胜感激谢谢你看我的文章我们下次再见。#AI技能 #AgentSkills #ClaudeCode #DeepSeek #AI工作流 #提示词工程作者大象-推动 AI 共学让普通人轻松上手AI相关链接1. DeepSeek Harness 开源仓库https://github.com/deepseek-ai/deepseek-harness2. Anthropic Skills 官方文档https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview3. 大象AI共学社群主页https://daxiangnaoyang.github.io