某生产企业的知识准入：AIS 如何支撑客户的 Facade 业务应用实践

最近，我们在某生产企业中接到了一个很具体的需求：客户希望一线员工在现场看到产品铭牌、产品参数页或者说明书时，可以直接使用手机拍照上传，系统通过 AI 自动识别图片内容，提取产品型号和关键参数，最终形成产品知识并进入对应的知识库。

从用户的视角看，这个需求并不复杂。他只需要完成拍照、上传和查看结果几个动作。至于图片使用什么模型解析，产品内容如何整理，系统如何判断知识是否重复，又如何决定应该进入哪个知识库，都应该由后台自动完成。

但当我们真正沿着“拍一张照片，形成一条知识”向下分析时，会发现这并不是一个简单的 OCR 功能，也不只是给多模态模型增加一个上传页面。它实际上包含了一条完整的知识生产链路：原始材料采集、多模态解析、内容标准化、知识库查询、重复判断、知识分类、准入审核、正式入库，以及入库后的检索和应用。

客户需要在前台看到一套简单、清晰的操作流程，AIS 则需要在后台为这条流程提供稳定的知识基础能力。这正是 Facade 模式与 AIS 知识 Infra 结合的价值。

一、用户想要的，是拍照之后系统自动完成后续工作

客户对采集端的要求很明确。员工可以直接拍照，也可以从手机相册中选择图片。上传的内容可能是完整的产品参数页，也可能只是一张设备铭牌或说明书截图。

图片上传以后，系统需要自动识别其中的产品名称、型号和主要参数，并把零散的识别结果整理成结构清晰的标准知识。例如，一张铭牌中可能只有型号、额定功率、制造编号和若干技术参数，最终进入知识库的内容则需要包含知识标题、产品概述、基本参数和适用场景等部分。

客户还希望为不同类型的产品建立独立知识库。例如，“设备类产品”和“运维类产品”可以分别进入不同的知识空间。员工不应该在拍照之前先理解复杂的知识库目录，系统需要根据图片内容和业务规则判断产品类型，并把知识送到正确的位置。

真实材料也不会都是理想样本。客户准备的测试数据中包含正常图片、英文材料、重复材料、信息被遮挡的铭牌和无关图片。这意味着系统不能只设计一条“识别成功后直接入库”的直线流程，还必须能够处理内容重复、信息不足、无法分类、材料无关和解析失败等情况。

因此，业务人员真正期待的并不是一个图片识别结果，而是一个明确的业务结论：

• 这张图片是否已经完成识别；
• 识别出了什么产品和参数；
• 是否命中了已有知识；
• 为什么被判定为重复或未入库；
• 应该进入哪个产品知识库；
• 是否需要业务人员审核；
• 最终是否已经成为正式知识。

当这些问题被完整列出来以后，拍照只是知识生产的入口，后面真正运行的是一条企业知识加工与治理流程。

二、从一张图片到正式知识，需要经过哪些步骤

我们把客户的需求拆开以后，一张图片要真正进入企业知识库，至少需要经历以下几个阶段。

第一步是材料采集和原图留存。员工上传图片后，系统需要保存原始文件，并记录上传人、上传时间、业务对象和文件来源。原图不能在解析完成后就被丢弃，因为人工审核、问题追踪和重新加工都需要回到原始证据。

第二步是多模态解析。系统不仅要识别图片中的文字，还要理解标题、型号、参数名称和参数值之间的关系。对于英文资料、复杂版面或者部分遮挡的图片，也要尽可能给出可解释的识别结果，并明确哪些信息无法确认。

第三步是知识加工。原始解析结果通常只是零散文本，不能直接作为高质量知识使用。系统需要按照企业的知识模板重新整理内容，生成标准标题、产品概述、技术参数和适用范围。客户当前决定先以标准文本形式沉淀知识，后续再根据实际需要动态提取结构化字段，这也是一种更稳妥的分阶段建设方式。

第四步是知识库查询和重复判断。系统使用标准化后的内容检索已有知识，结合产品型号、关键参数和语义相似度判断是否已经存在相同或高度相似的内容。如果命中已有知识，流程不应该继续创建新文档，而要返回重复比例、命中的知识和拦截原因。

第五步是知识分类。通过重复检查的内容，需要继续判断所属产品类型、目标知识库和知识标题。如果图片信息不足，无法可靠确定产品类别，系统应该进入“待补充”或“待人工判断”，而不是依靠模型猜测后直接写入。

第六步是知识准入审核。系统自动生成的内容首先应该是一条候选知识，业务人员需要结合原始图片、解析结果、标准化内容、重复检查和分类建议进行确认。只有审核通过的内容，才成为代表企业的正式知识。

第七步才是正式入库与发布。审核通过后，系统在目标知识库中创建文档，写入内容和元数据，并向搜索、RAG 和 Agent 发布。后续使用过程中产生的检索、引用和反馈数据，还可以继续用于评估知识质量。

这张表展示的已经不是一个单点 AI 功能，而是知识从业务现场进入企业知识体系的完整过程。

三、业务人员需要看到流程界面，而不是 AIS 底层技术节点

如果只从技术能力来看，我们完全可以让员工进入 AIS 后台，选择知识库、上传文件、触发工作流，再进入执行记录查看结果。但这并不是业务人员熟悉的工作方式。

现场员工关心的是“拍照采集”和“是否入库”，审核人员关心的是“有哪些待审核内容”和“应该通过还是退回”，管理人员关心的是“采集了多少知识”“哪些内容被重复拦截”和“哪些任务长期没有完成”。他们不需要理解解析器、模型参数、知识库 ID、工作流变量和条件节点。

因此，我们为客户开发了一套面向手机端的单页面应用。页面围绕业务人员的操作组织：拍照采集、从相册选择、确认上传、查看加工进度和查看历史记录。记录状态也使用业务语言，包括“处理中”“已入库”“重复拦截”“未入库”和“处理异常”。

用户点击某条记录后，可以继续查看识别结果、加工后的标准知识、命中的相似内容、重复率、目标知识库和各阶段处理状态。未来增加审核功能时，审核人员还可以在同一业务应用中查看原图和候选知识，完成修改、通过、退回或驳回。

业务人员看到的是一套清晰的知识采集和审核流程，AIS 内部运行的则是由多个算子组成的知识加工工作流。

这层面向业务人员的应用，就是 Facade。

四、Facade 的作用，是把业务流程翻译成知识能力

在软件设计中，Facade 模式使用一个更符合使用者认知的外观层，隐藏底层系统的复杂性。员外在《跨越业务视角与 AI 技术视角的鸿沟，Facade 模式在企业 AI 落地中的应用思考》中，把这一思想应用到了企业 AI 落地：底层可以包含知识库、Agent、Skill、文档解析和任务编排，但业务人员最终应该看到自己熟悉的页面、步骤和状态。

在本次场景中，“拍照采集”这个动作背后包含文件存储、任务创建和工作流触发；“重复拦截”背后包含知识检索、相似内容召回、重复率提取和条件判断；“审核通过”背后则包含候选知识状态变化、审核记录、知识写入和正式发布。

Facade 不是简单换一套页面皮肤，也不是把 AIS 的接口逐个转发给前端。它需要理解客户的业务对象、岗位和流程，再把多个底层能力组合成一个完整的业务动作。

整个方案可以分为三层：

业务前端不需要持有 AIS 的长期访问凭证，也不需要理解每一个内部接口。Facade 应用服务承接用户请求，把一次业务操作转换成一个或多个 AIS 任务，并把 AIS 返回的通用状态翻译成客户业务中的处理结果。

通过这层连接，客户得到的是一套符合自身工作习惯的完整解决方案，而不是一组需要客户重新组装的 AI 接口。

五、AIS 为这条业务流程提供了哪些 Infra 能力

Facade 可以把页面做得很简单，但并没有消除系统复杂性。真正复杂的知识处理过程仍然存在，只是被放到了更适合承载它的位置。AIS 的价值，就是把这些复杂能力沉淀为可复用的知识 Infra。

5.1 文档与多模态解析能力

AIS 负责接收原始文件，根据文件类型和场景选择解析能力。对于图片材料，解析过程不只提取文字，还要理解版面、产品标题、型号和参数之间的语义关系。原始文件、解析结果和任务记录需要彼此关联，为后续审核和追溯提供证据。

同一个 Facade 应用未来可能上传图片、PDF、Word、Excel 或其他材料。上层页面只关心“提交资料”，具体使用哪种解析引擎和策略，由 AIS Infra 统一处理。

我们在文章《AIS 知识引擎如何设计企业级文档解析：解析引擎、解析实例与解析策略》中，详细的阐述了当前AIS的对接各个解析引擎/策略的能力，可以轻松应对这种不同文件类型的解析策略，完成解析的对接。

5.2 知识加工算子与工作流能力

此次需求中组合了文件上传、文件存储、文档解析、AI 模型、知识检索、参数提取、条件分支、知识分类、创建文档、写入内容和消息通知等算子。

这些算子的作用不是在页面上展示一张复杂流程图，而是把企业知识生产规则固化成可以长期运行的工作流。模型提示词、标准文本模板、重复率阈值、分类逻辑和异常分支都可以在工作流中配置。业务规则变化时，调整对应节点即可，上层 Facade 不需要重新实现全部功能。

每个加工任务还需要保留节点输入、输出、状态、耗时和错误信息。Facade 可以基于这些数据展示业务进度，知识管理员也可以在 AIS 中排查解析失败、模型异常和分类错误。

从能力结构来看，这条流程涉及的并不是单一的“AI 节点”，而是一组可以被不同业务场景重新组合的知识加工算子：

这些算子并不是为某一个演示页面临时编写的代码，而应该逐渐沉淀为 AIS 的通用知识加工能力。本次场景可以用它们处理产品图片，术语运营场景可以用它们加工搜索日志，客服场景可以用它们把服务记录转换成案例知识。上层业务对象不同，底层仍然是在对数据进行接入、解析、检索、判断、加工和写入。

在当前AIS基础设施中，知识加工的算子能力，是随着业务的扩展，组件越来越丰富。

知识加工工作流还承担了一项很重要的职责：把企业业务规则从 Facade 页面中剥离出来。哪些内容算重复、什么情况下必须转人工、不同产品应该进入哪个知识库、审核通过后执行哪些写入和通知，都可以由工作流统一控制。Facade 负责收集用户动作和展示业务结果，不需要在每一个客户页面中重复实现这些规则。

因此，知识加工是 AIS Infra 中承上启下的一层。向前，它接住各种 Facade 产生的原始材料和业务数据；向后，它输出带有来源、结构、分类和判断依据的候选知识，再交给准入审核和知识治理。没有这层稳定的加工能力，Facade 只能调用零散模型接口，很难形成一套可以持续运行的企业知识生产流程。

5.3 知识检索与去重能力

知识去重不是简单比较文件名。不同员工可能拍摄同一个铭牌，图片角度和清晰度不同；同一产品也可能出现在参数页、说明书和宣传材料中。

AIS 可以先对候选内容执行关键词、向量或混合检索，召回可能相似的已有知识，再结合产品型号、关键字段和语义结果完成重复判断。系统不仅要给出“重复或不重复”，还需要保留命中的知识、相似度和判断依据，让业务人员能够理解为什么被拦截。

查询和去重能力也可以被其他 Facade 复用。无论上层采集的是产品资料、客服案例还是业务术语，底层都需要先知道企业是否已经存在相同或相近的知识。

5.4 候选知识与准入治理能力

知识加工完成后，系统产生的首先应该是候选知识，而不是立即对所有应用生效的正式知识。

候选知识需要关联原始材料、解析结果、标准化内容、目标知识库、重复检查、模型信息和工作流记录。AIS 还需要管理它的准入状态、审核意见和内容版本。Facade 负责提供符合客户习惯的审核页面，AIS 则保证审核结果能够真正控制知识是否发布。

5.5 正式知识与应用支撑能力

审核通过后，AIS 在目标知识库中创建正式知识，建立权限、版本和来源关系，并向搜索、RAG 和 Agent 发布。

正式入库不是链路的结束。知识会在客户的搜索页面、问答应用、Agent Search Tool 和其他业务系统中被持续使用。AIS 需要提供统一检索、权限过滤、引用溯源和开放 API，同时记录知识被召回、引用和反馈的情况。

这些使用数据可以再次进入知识加工和治理。无结果查询可能说明知识缺失，错误召回可能说明内容或分类需要修改，长期没有使用的知识可能需要重新评估。这样，客户得到的才不是一次性的图片入库功能，而是一套能够持续运行的知识生命周期。

六、知识准入是从 AI 生成走向企业可信的关键边界

在完整流程中，知识准入值得单独强调。

多模态模型可以识别产品型号，也可以把零散信息整理成结构清晰的产品说明，但生成结果并不天然等于企业事实。模型可能识别错数字，可能混淆参数单位，也可能在图片被遮挡时根据上下文补全了一个看起来合理、实际上错误的内容。

知识一旦正式发布，就可能被搜索、RAG 和 Agent 反复使用。错误内容不再只是一次识别错误，而会变成企业应用持续依赖的错误上下文。

因此，自动加工和人工审核承担不同责任。系统适合规模化完成解析、整理、查询、去重、分类和风险提示；业务人员负责确认事实、业务边界和最终准入。

审核人员应该能够同时看到原始图片、解析文本、加工后的候选知识、相似知识、重复率、目标知识库和系统建议，再选择通过、修改后通过、退回补充或驳回。审核意见和修改内容也要结构化保存，成为后续加工规则、模板和模型约束的输入。

经过多轮运行后，AIS 积累的不只是更多知识，还会逐渐沉淀企业自己的知识生产规范：哪些材料可以自动准入，哪些字段必须人工确认，什么情况必须重新采集，以及哪些内容不能进入正式知识库。

七、从这个需求可以看到 AIS 的完整知识生命周期

回到客户最初提出的拍照需求，我们可以发现它已经覆盖了知识全生命周期的主要阶段。

员工拍照并提交图片，是知识生产；多模态解析、内容整理、查询、去重和分类，是知识加工；候选知识审核、权限、版本和正式发布，是知识治理；入库后的搜索、RAG、Agent 使用与效果反馈，则属于知识运营。

这四个阶段并不只服务于产品图片。产品知识、业务术语、企业制度、客服案例、项目档案和 Agent 生成内容，都可以运行在同一套知识工程框架中。

上层 Facade 的页面、字段和业务动作会发生变化，底层知识生命周期却具有高度共性。这就是 AIS 能够作为知识库 Infra 支撑不同客户和业务场景的原因。

八、同一套 AIS 可以支撑更多 Facade 业务应用

在本次项目中，Facade 是一套面向现场员工的产品知识采集中心。换一个业务场景，它可以变成完全不同的应用。

在银行 APP 搜索场景中，Facade 可以是一套术语运营工作台，参考文章《企业AI知识库下一站：让知识自己长出来》，运营人员查看无结果查询和用户表达，审核新术语并发布到检索服务；在制度管理场景中，它可以是一套制度起草、修订、会签和发布流程；在客服场景中，它可以把服务记录加工成候选案例，由主管审核后进入客服知识库。

Agent 也可以使用同一套 Infra。它通过 Search Tool 检索正式知识和引用来源，也可以把任务执行中发现的新内容提交为候选知识，等待加工和审核。

这些 Facade 可以由我们结合客户需求快速开发，也可以由客户研发团队构建，还可以嵌入客户已有系统。它们不需要重复实现文件解析、知识加工、检索去重、准入治理和知识生命周期，只需要通过稳定接口使用 AIS 提供的基础能力。

这种模式在标准化和定制化之间形成了清晰边界。客户得到的是符合自身业务习惯的完整应用，AIS 则继续专注建设跨行业复用的知识 Infra。项目中反复出现的共性能力还可以进一步沉淀为标准 API、加工算子、流程模板和行业模板，降低后续交付成本。

九、AIS 的价值，是让复杂知识能力以业务流程的方式被使用

客户最开始提出的，只是希望员工可以拍照识别产品信息。

如果我们只交付一个图片识别接口，这个需求解决到“模型成功返回文本”就结束了。但客户真正需要的是：图片能够被正确解析，内容能够被标准化，重复知识能够被拦截，不确定内容能够进入审核，审核通过后能够进入正确知识库，并在后续搜索和 Agent 中稳定使用。

Facade 解决业务人员如何操作的问题。它把知识能力组织成页面、按钮、状态、待办和审核流程。

AIS Infra 解决这些业务动作如何被可靠执行的问题。它提供解析、多模态处理、知识加工、查询去重、候选知识、准入治理、正式入库、检索与生命周期管理。

两者结合以后，我们给客户提供的就不再是一个知识库后台，也不只是一组 AI 接口，而是一套从业务现场到可信知识、再从可信知识回到业务应用的完整解决方案。

上层的业务应用可以千变万化，底层的知识能力应该稳定、统一并且可治理。

这正是 AIS 在 Facade 模式中的定位：成为企业各种业务流程背后，那套覆盖知识生产、知识加工、知识治理和知识运营全生命周期的企业知识 Infra。