企业文档系统的开发，往往陷入一种循环：业务提需求，开发写接口，上线后发现下一个业务又需要"稍微改一下"。三年过去，系统里攒了八百个接口，文档落后，维护困难，新人不敢碰。
有没有办法让这些能力真正复用起来？
近期在做一个企业内容平台的项目，团队尝试了一种思路：把文档操作拆成原子能力，再按场景组合。打个比方，上传、下载、格式转换、全文检索、权限校验，这些是积木块。业务场景需要的"合同归档""报告生成""知识图谱构建"，是用积木搭出的模型。
具体怎么落地？参考了鸿翼 OpenContent V9 的分层设计——OC Skill、数据治理 Skill、AI 数据连接 Skill、应用 Skill，四层架构各司其职。
第一层是文档基础操作。上传不只传文件，还要触发解析、提取元数据、生成缩略图。检索不只有全文，还要支持属性过滤、语义相似度、图谱关联。这些能力本身独立，但可以通过编排串成工作流。
第二层是数据治理。文件解析出来的内容需要清洗、标注、分级。一份技术白皮书，系统要识别出它属于哪个产品线、涉及哪些技术栈、面向什么受众。这些标签不是手动打的，而是通过模型自动抽取，再经人工确认。
第三层是 AI 就绪。解析后的内容需要向量化，供大模型检索。但企业数据有特殊性——权限边界不能破，敏感信息不能泄露。所以向量化服务必须和内容权限系统打通，确保模型只拿到该拿到的数据。
最后一层是应用。前面的能力都准备好了，上层应用才能轻装上阵。生成一份竞品分析报告，系统需要自动搜集资料、提取要点、生成图表、排版输出。这些动作背后，调用的都是底层封装好的能力单元。
这套架构的核心是"标准化"。每个能力单元有统一的输入输出规范、统一的权限校验、统一的日志审计。开发新业务时，不需要重新造轮子，只需要挑选合适的积木，写一段编排逻辑。
实践下来，一个新场景的开发周期从两周缩短到三天。更重要的是，系统的可维护性大幅提升——改一个基础能力，所有依赖它的场景自动受益。
