未来可能有个新职位，叫「Skill设计工程师」

朋友丢了三份扫描 PDF，想让我帮忙转成 Markdown 再分析

扫描件还是纸质文档拍的，歪歪扭扭的那种。

我第一反应是用多模态模型直接提取——Gemini、豆包都行。但正好前几天听说混元开源了个 OCR 模型，据说吊打 Gemini 3 Pro，手痒想试试。

结果一搜，刚开源，没 API。

又想起飞桨 PP-OCR，一查官方文档，确实能用，还支持视觉理解。

问题来了：MCP 还没适配，官方只给了 API 文档。

那就把 API 文档做成 Skill 吧。

为什么是 Skill 不是 MCP？

MCP 有个问题：提示词太重了，动不动占满上下文。

Skill 不一样。它是分级暴露的机制——

一开始只告诉模型「我有哪些 Skill」「名字叫啥」「干嘛用的」，占用极小。等模型确认要用了，再展开具体文档和脚本。

这个设计很聪明。上下文空间省出来，干正事的余地就大了。

十分钟，从 API 文档到可用 Skill

操作流程其实很简单：

第一步：把官方 API 文档的示例复制下来，存成本地 Markdown 文件。

第二步：我之前装过 Anthropic 官方的 Skill Creator（一个「造 Skill 的 元Skill」），直接在 Claude Code 对话框里说：

帮我用 Skill Creator 把这个 API 文档设计成 OCR Skill，要求能批量识别提取 PDF 里的文本。

第三步（关键）：加一句——

不要直接开始，先问我几个问题，确保需求对齐。

加了这句之后，Claude Code 先调用了 Skill Creator 了解流程，然后开始反问我：输出格式要啥？批量处理的逻辑是？错误怎么处理？

几轮对话，需求完全对齐。

一分钟不到，本地就生成了 Skill 安装包，根目录里自动激活。

关掉窗口，新开一个，让它调用刚刚创建的 paddleocr skill转换 pdf，一发即中。

Skill 的三层价值

用完之后我一直在想，Skill 这东西的想象空间比我预想的大。

第一层：任何 API 都能变成 Skill。

以前要调 API，要么写代码，要么等人做 MCP 适配。现在？官方文档复制粘贴，十分钟搞定。下次遇到类似任务，直接调用。

第二层：复杂的系统提示词，打包成 Skill 更香。

我之前做知识卡片，系统提示词巨长——设计风格、代码示例、Few-Shot 全塞里面。现在全部封装成 Skill，调用的时候才加载，平时不占空间。

第三层：工作流本身就是 Skill。

写公众号的流程——调研、出大纲、填充内容——这不就是一个 Skill 吗？把流程固化下来，以后每次写作，模型自己就知道该怎么推进。

未来的产品形态，可能就这么简单

一个通用能力极强的底层 Agent 框架（比如 Claude Agent SDK），加上各行业垂直的 Skill 库。

不需要复杂的产品架构，不需要臃肿的功能堆砌。

底座够强，Skill 够多，大部分工作场景就能覆盖了。

那问题来了：以后是不是每个公司都会有个职位叫做——Skill Engineer（技能设计工程师）？