技术人讲架构，喜欢画分层图。最底层是存储，往上是计算，再往上是服务，最上面是应用。层次分明，逻辑清晰。但企业 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，参数靠人工录入，检索基本靠文件名。
技术栈没变厚，只是把该连的线连上了。