Claude Agent Skills：用文件夹封装专业流程，AI 应用从「提示工程」走向「能力工程」
核心观点
Anthropic 在 2025 年 10 月正式发布 Claude Skills，并于 2025 年 12 月将其升格为开放标准（agentskills.io）。这不是一次功能迭代，而是一次关于「Agent 能力单元」的重新定义：真正制约 Agent 落地的不是模型智能不足，而是"专业流程"无法被结构化地沉淀和复用 。Skills 给出的答案是：用一个带 SKILL.md 的文件夹，把流程、代码、模板和示例打包成可按需调用的能力单元。
关键机制：「按需加载 + 渐进展开」才是真正的核心
Skills 的实现极其简单------一个文件夹、一个 Markdown 文件、两个必填字段（name 和 description）------但简单背后的关键机制是按需加载（progressive disclosure）：
- 默认情况下，Claude 只拿到每个 Skill 的元信息（名字 + 描述），不消耗上下文窗口；
- 只有当 Claude 判断当前任务需要某个 Skill 时，才完整读取该 Skill 的指令和资源；
- 更复杂的 Skill（如 PDF 处理）甚至会在主文档里写「如需填写表单，请读 forms.md」，Claude 自主决定是否进一步读取子文档。
这个机制解决了 System Prompt 方案的根本缺陷------System Prompt 必须一次性全量加载，无论任务是否需要其中 80% 的内容，Token 都被占用了。
yaml
# SKILL.md 最小结构
---
name: my-skill-name
description: A clear description of what this skill does and when to use it
---
# My Skill Name
## 执行流程
1. ...
2. ...
## 示例
- 示例一
- 示例二
## 使用规范
- 规范一对比判断：相比 System Prompt 和 Tool，Skills 各赢在哪
相比 System Prompt，Skills 至少在三个维度形成碾压：
| 维度 | System Prompt | Skills |
|---|---|---|
| 上下文占用 | 全量加载，不管用不用 | 按需加载，默认零消耗 |
| 可维护性 | 埋在对话历史里，无法审计回滚 | 文件可 Git 版本控制 |
| 可复用性 | 一次性提示技巧，无法传承 | 团队共享、组织级资产 |
| 行为一致性 | 依赖措辞，天然漂移 | 结构固定，可回归测试 |
不同于 Tool Use（工具调用） ，Tool 负责「能做什么」（接外部 API、数据库），而 Skill 负责「应该怎么做」（专业判断、执行工作流）。两者是互补分层，而非替代关系。Anthropic 给出的分层架构是：Model（思考）→ Runtime（执行环境）→ Skill（专业能力）→ MCP Server（连接外部世界）。
这个类比值得记住：Skill ≈ 应用软件，MCP ≈ 外设，Runtime ≈ 操作系统，Model ≈ CPU。
推演：这意味着 AI 应用的开发重心正在迁移
基于上述机制，可以推导出一个具体判断：接下来企业 AI 落地的竞争焦点，会从「谁的提示词写得更好」转向「谁的 Skill 库更完整、质量更高」。
这不是空话------当 Skill 可以版本控制、可以依赖其他 Skill（官方已规划 Skill Dependencies）、可以发布到 Marketplace 被他人安装，它实际上就是一种新形态的软件包。Notion 已经发布了官方 Skill；Anthropic 仓库本身的文档技能（docx/pdf/pptx/xlsx）是 Claude.ai 「创建文档」功能的底层实现，以「source-available」形式开放，这本身就说明 Skills 已经在生产级产品中运转。
这意味着：未来有价值的不是「会用 Claude 的人」，而是「能沉淀可复用 Skill 资产的组织」。
边界局限：并非适用于所有场景，且存在真实安全风险
局限在于以下几点，需要诚实面对：
-
简单任务不值得封装：如果只是需要「改改语气」「轻量对话」，一句 System Prompt 比写一个 Skill 快得多。过度工程化是真实风险，Skywork 的对比分析明确指出「如果任务足够简单，短 System Prompt 反而更快更省钱」。
-
路由不是魔法 ：Claude 自动选择 Skill 的机制基于
description字段语义匹配，并非保证正确。官方建议用「黄金测试用例（golden tests）」在自己领域验证路由准确性，不能默认信任。 -
企业级治理细节不透明：更深层的 RBAC 权限控制、审计日志等，官方文档尚未完整公开，Skywork 明确建议「在受监管的部署环境中，需联系 Anthropic 代表确认」。
-
安全风险是真实的 ：Anthropic 官方在文档中明确警告------恶意 Skill 可能指示 Claude 窃取数据、执行非预期操作、引入代码依赖漏洞。社区已有遭遇「Skill 投毒」案例。从非可信来源安装 Skill 前，必须逐行审查 SKILL.md 及捆绑代码。
使用方式速查
Claude Code
bash
# 注册官方 Skill 市场
/plugin marketplace add anthropics/skills
# 直接安装指定技能包
/plugin install document-skills@anthropic-agent-skills
/plugin install example-skills@anthropic-agent-skills安装后直接在对话中引用即可，例如：「Use the PDF skill to extract form fields from report.pdf」
Claude.ai
付费计划直接可用官方 Skill，支持上传自定义 Skill。
API
参考 Skills API Quickstart，支持上传自定义 Skill 并通过 API 调用。
交叉验证
本文观点通过以下两个独立信源进行了交叉验证：
① windliang.wang 独立技术博客（2025-12-30） ------作者 windliang 对 Skills 标准做了深度解析，完全认同 原文的「按需加载」和「知识沉淀」核心定位，并补充了一个原文未强调的重要视角：当前 Agent 的根本问题不是「智能不足」而是「专业性缺失」 ------Agent 像「极其聪明但毫无行业经验的新人」，Skills 是在给这个新人注入可复用的行业经验。该信源还提供了 Anthropic 官方尚未在 README 里写明的安全风险清单，具有重要补充价值。
② Skywork AI 技术博客（2026-01-30），题为「Claude Skills vs System Prompts (2025): Structure Beats Ad-Hoc」 ------该信源大体认同 原文关于 Skills 优越性的判断，但提出了一个重要的补充与纠正：原文对 Skills 的描述略显偏向鼓励，而 Skywork 明确指出「Skills 需要前期投入定义契约（inputs/outputs/golden cases/dependencies），对简单任务是过度工程化」，并建议多数团队采用「简短 Base Prompt + 少量高 ROI Skill」的混合策略------这是比原文 README 更务实的落地建议，值得采纳。
两个信源均未反驳原文的核心机制描述，但都在「局限性」维度有所补充，构成对原文偏乐观叙事的有益平衡。
个人启发
对开发者/工程师 ：现在就可以把你反复在 System Prompt 里粘贴的那段「数据分析流程」或「代码审查规范」重构成一个 Skill 文件夹，提交到团队 Git 仓库。这不只是整理，而是在创建一种新型的组织知识资产，未来可以直接被 Claude Code 安装使用。
对企业决策者 ：不要把 Skills 当功能，要当「能力资产管理体系」来建设。关键动作：① 盘点高重复、高价值的业务流程（如品牌稿撰写、数据报告生成、合规审查）；② 从 2-3 个优先级最高的场景开始封装 Skill；③ 建立内部 Skill 库的版本管理和审计机制，在任何 Skill 上线前必须做安全审查。
对普通用户：Claude.ai 付费计划已经可以上传自定义 Skill，这意味着你可以把自己的「写作风格指南」「读书笔记模板」「个人工作流」封装成 Skill，一次定义，永久复用，彻底告别每次都要重新解释背景的问题。
延伸思考
-
Skill Marketplace 的生态会走向何方？ 当 Notion、Figma 等 SaaS 产品都开始发布官方 Skill，这实际上是在为自己的产品增加「AI 操作手册」。这是否意味着未来 SaaS 产品的竞争，将部分转移到「谁的官方 Skill 质量更高、用户使用更顺畅」上？
-
「Skill 投毒」会不会成为新的攻击面？ 类比 npm 包的供应链攻击，当 Skill Marketplace 的 Skill 数量增长后，恶意 Skill 的传播和检测将是系统性挑战。Anthropic 目前的应对是「用户自行审查」，这在规模化之后显然不够，这个安全问题值得持续关注。
-
Skills 的开放标准（agentskills.io）能否真正跨模型落地？ 目前 Cursor 仅在 Nightly 版支持，其他主流 Agent 框架尚未跟进。如果标准只停留在 Claude 生态，它更像一个产品特性而非行业标准；只有 GPT、Gemini 等竞争对手也采纳类似规范，「Agent 能力可移植」的愿景才真正有意义。
📚 参考来源