一句话找图，低清图再增强：HarmonyOS7 视觉 AI 如何走进真实应用

图片越来越多以后，“找一张图”正在变成一个越来越具体的问题。 技术截图、活动照片、课程素材、会议白板、商品图片……攒了几年以后，目录和命名规则越来越难维持。明明记得某张图大概是什么画面，却想不起文件名，也记不清存在哪个文件夹。 清晰度是另一个让人头疼的问题。聊天软件压缩过的照片、早期保存的小尺寸素材、历史活动图片，在缩略图列表里看着还行，一旦放大预览或拿去做内容，人物轮廓、文字边缘和物体纹理就变得明显粗糙。 HarmonyOS 7 API 26 在 Core Vision Kit 里放进两项能力，恰好瞄准了这两个痛点。一项叫"文搜图"，允许应用根据文本语义检索图片，用户输入"会议白板""蓝色背景的技术封面"，系统就能在已建立索引的图库里找到接近的内容；另一项叫"图像超分"，可以对低分辨率图像进行超分辨率重建。目前 HarmonyOS 开发者官网已提供 26.0.0 Beta2 配套文档与开发工具，两项能力在 API 目录中仍带 Beta 标记，接口是否能查询、本地工程是否能编译，以及支持设备上的真实效果如何，需要分别判断。 为了搞清楚这两项能力到底怎么落地，我们找了一位长期活跃在 HarmonyOS 应用开发一线的开发者聊了聊。 人记住的是“画面”，图片搜索正在换一种方式 李小雨拥有 13 年研发、产品和项目管理经验，长期参与 HarmonyOS 应用开发，同时从事独立开发、大模型产品化和企业 AI 服务。 聊起文搜图和图像超分，他没有急着讲 API，而是先讲人。文搜图首先碰到的是人的记忆方式和文件管理方式之间的差异：文件系统保存的是名称、目录和时间，人真正记住的却经常是场景。"背景偏蓝、屏幕前有人演讲，或者照片里出现过白板、电脑和纸质材料"，这才是几个月后留在脑子里的东西。 图片数量少时这道鸿沟不明显，数量一多就逐渐放大。过去解决这类问题，常见方式是整理目录、修改文件名、加标签，或通过 OCR 提取图片里的文字。几种方法都有价值，但都要求图片提前存在能被精确匹配的信息。用户如果只记得画面内容，传统搜索能利用的信息就相当有限。 文搜图增加了一种更接近日常表达的搜索方式，系统根据文本语义在已建立索引的图片中寻找接近的内容。开发者不需要从头搭建跨模态模型和底层检索能力，就能先验证这种搜索方式适不适合自己的业务。 不过，李小雨并不把它当成万能搜索框。"用户已经知道文件名时，文件名搜索最快；图片有稳定业务分类时，标签更可靠；搜索合同编号、门店名称、白板文字时，OCR 更适合。"文搜图主要处理画面语义和模糊记忆，几种能力放在一起，效果通常更稳定。 图像超分则出现在查找之后。图片找到了，用户准备进一步查看，却发现原始尺寸太小，这种情况在真实应用里非常常见。它更适合放在用户已经明确想继续查看或使用某张图片之后，没必要让应用提前处理整个图库。两项能力连起来，用户流程就比较完整：前面减少查找，后面改善查看。 而李小雨做产品时最在意的一点是，AI 功能要对应一个已经存在的问题，并且能减少原来的操作成本。"一个 AI 功能如果只能在演示页面里展示，进入真实任务后用户却不知道什么时候该用，长期使用频率通常不会高。" 如果团队自己搭建文搜图，工程范围很容易从一个搜索功能扩展成一套视觉 AI 基础设施：图片要生成特征，文本要转换到语义空间，后面还要维护向量索引、相似度查询、模型版本、端侧转换和设备兼容。采用云端后，工作范围继续增加，图片上传、对象存储、模型服务、向量数据库、接口鉴权、网络异常、并发控制和调用费用。 "这些工作放在大团队里可以拆给不同岗位处理。独立开发者或三五人的小团队就会比较吃力。"李小雨说，同一个人经常同时负责客户端、后端、产品和运维。第一版功能可能几天就能完成，半年后才开始不断出现模型更新、服务器费用、异常监控和系统兼容问题。维护面的增长速度一旦超过用户价值的增长速度，功能很快就会变成负担。 他现在判断一项能力值不值得自己搭建，会特别关注半年后的维护成本。系统把底层视觉能力封装成 Kit 以后，应用依然要负责自己的业务，图片什么时候进索引、什么时候删除、搜索结果怎么展示、权限怎么处理，但开发团队少维护了一层模型和推理基础设施。 更关键的是，系统能力改变了产品验证的顺序。以前想做自然语言查找图片，团队可能先讨论模型、服务器、向量数据库和索引结构，技术方案很快变重。现在可以先准备几十张真实图片，把索引和文本查询跑起来，观察用户有没有这个需求。用户基本不用，保持实验状态即可；使用频率明显增加，再继续投入。"把产品验证放到了架构建设以前"，这是系统 AI 能力对小团队最大的帮助。 端侧处理还有一个现实影响：减少网络和服务器参与。个人相册、本地技术素材、会议资料本来就在用户设备上，如果只是为增加一个搜索入口就把大量原图传到服务器，只会增加带宽、存储和隐私处理成本。不过隐私边界仍要说清楚，Core Vision Kit 当前的个人数据处理说明把图片列为需要处理的数据，存留期标注为"不留存"，云端不存储用户数据；但应用作为数据控制方，接入服务前仍需向用户说明数据处理方式并取得同意。 目前两项能力处在 Beta 阶段，李小雨的思路是把它们优先放进辅助流程：文搜图与原有文件名、标签、OCR 并存，图像超分作为用户主动触发的增强功能。经过一轮设备和真实用户测试后，再决定是否扩大使用范围。 API 不难，真正的工程问题都在接口之外 如果把文搜图拆成完整流程，李小雨按"图片进入应用、建立索引、用户查询、业务过滤"四个动作来理解。接口调用本身很容易跑通，后面三个动作之间怎么保持一致，才会决定功能稳不稳定。 最小调用关系并不复杂。应用先初始化服务，把图片路径和对应的 scope 加入检索数据，用户输入查询后调用搜索接口获得结果： import { textSearchImage } from '@kit.CoreVisionKit'; const SEARCH_SCOPE: string = 'content_materials'; async function prepareAndSearch( imagePaths: string[], query: string ) { // 初始化失败后停止后续处理，避免继续进入错误状态。 const initialized: boolean = await textSearchImage.init(); if (!initialized) { return []; } // 图片进入业务库以后，同步建立语义索引。 // 正式项目建议记录每张图片的插入结果，方便后续修复。 for (const imagePath of imagePaths) { await textSearchImage.insertImage( imagePath, SEARCH_SCOPE ); } // 返回数量需要根据页面展示方式和图库规模继续调整。 const results = await textSearchImage.search( query, SEARCH_SCOPE, 5 ); return results; } 真正进入项目，第一个要决定的是 scope 怎么设计。这个参数看起来只是范围标