最近发现Agent skill 真的非常很好用，完全可以把我之前的很多项目都用skill重新做一遍了，同时也发现了skill的一种好玩的用法。

本文主要介绍了skill的一种特殊用法：用 Agent Skill 倒推 AI 应用解决方案

当业务部门提出一个需求时，可以用skill进行快速的效果验证和技术方案选型，再反向推导产品设计。这样一来，很多工作其实不用从头做起，也算是一种另辟蹊径的方案了。

一、先搞懂：什么是 Agent Skill？

想象你雇了一个非常聪明的新员工（ AI Agent）。他什么都能学，但刚入职时对你们公司的具体业务一无所知。

Agent Skill 就像是给这个新员工的”工作手册”。（注：不同的工作，可以创建不同的手册）

手册里写着：

– 这项工作要做什么

– 具体步骤是什么

– 要注意哪些规范

– 遇到问题怎么处理

– 有哪些工具可以使用

有了这份手册，聪明的员工就能快速上手，按照专业标准完成工作。

官方定义：

Agent Skill是 Anthropic（Claude 的开发公司）在 2025 年底发布的一个开放标准。它本质上是一个文件夹，里面包含了让 AI 完成特定任务所需的所有”知识”：

一个 Skill 文件夹的结构：

my-skill/ ← 技能文件夹

├── SKILL.md ← 核心说明书：告诉 AI 这个技能是什么、怎么用

├── instructions/ ← 详细指南：具体的操作步骤

├── scripts/ ← 执行脚本：实际干活的代码

└── resources/ ← 配套资源：模板、示例等辅助材料

举个例子

假设有一个”Excel 处理”的 Skill，它的说明书（SKILL.md）可能是这样的：

“`

【技能名称】Excel 智能处理

【能做什么】

– 读取和分析 Excel 文件

– 自动创建数据图表

– 生成格式规范的财务报表

【使用步骤】

1. 接收用户上传的 Excel 文件

2. 分析文件内容和结构

3. 根据用户需求进行处理

4. 输出处理后的文件

【质量标准】

– 所有公式必须正确，不能有错误提示

– 数字格式要符合财务规范

– 保留原文件的样式和格式

“`

有了这个 Skill，AI 就”学会了”如何专业地处理 Excel 文件。

补充说明：Skill 和 MCP 的关系

你可能听说过 MCP（Model Context Protocol），它和 Skill 是搭档关系：

MCP 解决”能不能连上”的问题，Skill 解决”会不会用”的问题。

Skill的技术特点

1）渐进式披露 (Progressive Disclosure)

• Agent 不需要始终携带所有技能的指令
• 只有当用户请求匹配某个技能的领域时，才加载相关的元数据、指令和资源
• 优化资源使用效率

2）动态发现与加载

• Agent 可以在运行时发现新技能
• 按需加载，无需预先配置所有能

二、为什么我建议用 Skill 来”倒推”解决方案？

理想情况下，我们假设用户愿意（或者有能力）直接和 AI 对话，AI 自动调用各种 Skill 来完成任务。但现实往往没这么简单。

原因一：企业应用场景需要”确定性”，而不是”可能性”

很多 AI 工具的真正使用者是业务人员——财务、法务、运营、市场。他们的诉求很直接：我要完成工作，越快越好。

对他们来说：

– 对话式交互太不确定了 — “我该怎么描述才对？””为什么结果和上次不一样？”

– 他们更习惯明确的操作流程 — 点击按钮、填表单、上传文件，每一步都清清楚楚

– 他们要的是效率，不是探索 — 工作场景下，没人想花时间去调试AI

Skill 的价值在于： 它已经定义好了输入是什么、输出是什么、中间怎么处理。我们可以据此设计一个确定性的交互界面，让用户通过简单的操作就能使用 AI 的专业能力。

原因二：许多公司没有统一的Agent管理平台或官方架构

Skill 本来是设计给 AI Agent 用的，Agent 会根据任务自动发现和加载不同的 Skill。

但现实是，很多公司并没有这样一个统一的 Agent 平台。真实情况往往是：

– 各个部门各自为战

– 每个需求需要开发单独的应用

– 需求单点分散，需要嵌入不同的业务系统中

比如：

– 法务部门想要一个合同审查工具，最好能嵌入他们的 合同管理 系统

– 财务部门想要一个报表生成工具，得放在他们的 ERP 系统里

– 市场部门想要一个文案生成工具，要对接他们的内容管理系统

每个需求都需要一个独立的应用，而不是一个”什么都能做”的对话框。

Skill 的价值在于：把它当作”能力蓝图”。

即使没有 统一规划Agent 平台，你也可以把 Skill 里的核心逻辑和能力提取出来，封装成独立的服务，嵌入到各个业务系统中。

原因三：利用Skill快速实现需求效果验证和技术验证

面对新需求：你不需要从零设计工作流，也不需要纠结用什么技术手段，Skill 里都已经有了。

一个成熟的 Skill 里包含的不只是”能做什么”，还有：

完整的处理流程和逻辑

配套的模板和资源

写好的提示词

使用示例

可执行的代码脚本

Skill 的价值在于：完成效果验证，并提供一份已经经过验证的可落地的技术方案。

三、实操指南

第一步：分析需求，定义清楚输入输出

先别急着动手，把需求理清楚。

当你收到一个模糊的需求时（比如”我们需要一个合同审查工具”），首先要做的是把它变成清晰的定义。

1. 把需求拆成具体的功能点

原始需求：”业务需要一个工具来审查合同风险”

拆解后：

✅ 功能1：能识别合同里的关键条款（违约责任、付款条件、保密条款等）

✅ 功能2：能判断哪些条款对我们不利

✅ 功能3：能生成一份风险评估报告

✅ 功能4：能处理 PDF 和 Word 两种格式的合同

2. 明确输入是什么

合同文件

审查标准

风险判定规则

3. 明确输出是什么

条款识别结果

风险评估

审查报告

4. 明确限制条件

准确性

速度

格式

安全合规

这一步的产出：一份简单的需求说明。它会是下一步创建 Skill 的输入。

第二步：用 AI 编程工具创建专属 Skill

现在有很多 AI 编程工具支持 Skill 标准：

– Claude Code，Anthropic 官方的编程助手

– Codex ，Chat GPT 的官方变成助手

操作方法：

1. 打开你习惯用的 AI 编程工具

2. 把第一步整理好的需求告诉它，让它帮你创建 Skill

3. 它会帮你生成一个完整的 Skill 目录

这一步的产出：一个结构完整的 Skill。

第三步：用真实数据测试，快速迭代

1. 准备测试数据

2. 评估效果

3. 发现问题就改进

4. 反复迭代直到满意

这一步的产出：一个经过验证、真正好用的 Skill。

第四步：把 Skill 的能力设计成可用的产品

到了这一步，产品经理就可以邀请技术人员参与评估方案可行性了

没错！现在我们非技术出身的产品经理也可以自己进行技术验证了。

1、理解 Skill 的能力边界

先回顾一下这个 Skill：

– 能做什么、不能做什么

– 需要什么输入、会输出什么

– 有哪些可以调整的选项

2、设计用户界面

设计一个让业务人员可以直接操作的前端交互页面

3、选择合适的产品形式嵌入业务系统

– 独立网页应用

– 嵌入OA CRM ERP

– 接口对接

– 其他形式

最终产出：一个业务人员可以直接使用的产品，背后是 Skill 的能力在驱动。

四、总结用法

1. 知道有什么： 保持对 Agent生态发展的关注，建立Agent设计”能力清单”。

2. 快速验证需求 ：收到需求时，第一反应是寻找AI优先的解决方案。

3. 包装技术： 把底层技术转换成靠谱、简单、好用、可复用、可拓展的产品。