Skill没那么玄：今晚写出你的第一个AI技能-Seo优化-塔城地区网站建设公司

预计 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.md：

my-skill/ └── SKILL.md

SKILL.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 页面支持创建、编辑和上传 Skill；
Claude 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 会在合适时机自动启用一个或多个 Skills；Claude 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

Skill没那么玄：今晚写出你的第一个AI技能