最近，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 私教服务，用于个性化能力提升与工程实践指导。