技术人讲架构喜欢画分层图。最底层是存储往上是计算再往上是服务最上面是应用。层次分明逻辑清晰。但企业 AI 的真实场景往往卡在层与层之间的缝隙里。一份 PDF 躺在存储层。应用层的大模型需要它的内容。中间隔了多少道坎首先PDF 可能是扫描件需要 OCR 识别。识别出来的文字可能有错需要纠错。然后内容需要结构化——标题、段落、表格、图表分别提取。接着提取的内容需要标注元数据这是什么类型的文档、属于哪个项目、涉及什么主题、谁有权访问。标注完后内容需要向量化供大模型检索。最后还要考虑版本管理——这份 PDF 更新了向量库里的数据要不要同步更新这些步骤涉及的技术都不新。OCR、NLP、向量化、权限管理每个领域都有成熟的方案。但把它们串起来让企业里的任何一份文档都能在需要时被 AI “用得上”这就是最后一公里的问题。一些平台开始用 Skill 化思路解决这个问题。每个处理步骤封装成一个独立的 Skill有统一的接口和校验规则。OCR 是一个 Skill元数据提取是一个 Skill向量化是一个 Skill。它们可以单独调用也可以编排成流水线。架构上Skill 层位于存储和应用之间。对上层应用来说它提供的是标准化的 AI 能力接口。对下层存储来说它负责把静态文件转化为可计算的数据资产。Skill 内部处理所有脏活累活格式转换、错误处理、权限校验、日志记录。鸿翼 OpenContent V9 把这三层拆成了 OC Skill、数据治理 Skill 和 AI 数据连接 Skill每层有独立的职责边界又通过统一调用机制串联。一个具体的例子某制造企业把过去十年的技术图纸全部 Skill 化处理。图纸进系统后自动提取参数、生成标签、建立关联。研发人员现在可以用自然语言查询“找一下承压能力大于 10MPa 的法兰设计图”系统直接返回匹配结果。这在以前是不可想象的——图纸是扫描版 PDF参数靠人工录入检索基本靠文件名。技术栈没变厚只是把该连的线连上了。