最近，Anthropic 发布了一份 30 多页的 Skill 创建指南，系统讲解如何为 Claude 构建自定义能力模块。

这不是简单的 API 更新说明，而是一份偏工程体系化的能力设计手册。

当模型厂商开始教开发者“如何设计能力单元”，说明一个趋势正在形成：

大模型能力，正在进入结构化阶段。

Skill 为什么是一层新的能力抽象

在 Skill 出现之前，我们扩展大模型能力主要依赖：

• 更复杂的 Prompt
• 外部 Tool 调用
• Agent 编排流程

但这些方式都存在工程问题：

Prompt 不稳定 Tool 过于原子化 Agent 复杂度过高

Skill 的定位，恰好在 Tool 与 Agent 之间。

Tool 是操作层 Skill 是能力层 Agent 是调度层

Skill 不是简单封装接口，而是：

• 定义清晰职责
• 约束输入输出结构
• 明确触发条件
• 支持组合调用

这一步，本质是在为大模型建立“能力模块系统”。

官方指南背后的设计逻辑

从 Anthropic 指南的内容来看，有几个信号非常明确：

第一，Skill 是模型能力的结构化延伸。 它与推理能力协同，而不是外挂脚本。

第二，强制结构化输入输出。 通过 schema 限制行为边界，减少误调用。

第三，强调职责单一与可复用。 避免一个 Skill 承担过多语义任务。

这实际上是在把传统软件工程原则引入大模型能力设计。

Skill / Tool / Agent 的工程边界

在实际项目中，这三层常被混淆。

我们用结构图表达更清晰。

Skill 能力架构示意图

这张图的关键点：

• Agent 不直接操作底层工具
• Skill 负责封装能力语义
• Tool 执行具体动作
• 外部系统对模型不可见

当 Skill 清晰时，Agent 会更简单； 当 Skill 混乱时，调度逻辑会指数级膨胀。

Skill 执行链路图

在实际运行中，Skill 的调用链路大致如下：

• 模型并不直接控制底层系统
• Skill 是语义与执行之间的桥梁
• 每一步都可以被观测和测试

这意味着： AI 系统开始具备可追踪的能力链路。

对开发与测试体系的影响

Skill 的结构化，会带来工程体系的变化。

第一，能力沉淀成为可能。 重复逻辑不再写 Prompt，而是封装成 Skill。

第二，测试对象发生变化。

需要验证：

• Skill 触发是否正确
• 参数结构是否符合定义
• 是否存在幻觉调用
• 异常路径是否覆盖

第三，质量体系要覆盖“能力链路”。

包括：

• 决策路径记录
• 工具调用日志
• 重试与回滚机制

当能力被模块化，系统反而更可控。

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。