一句话找图，低清图再增强：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 怎么设计。这个参数看起来只是范围标识，却会直接影响用户能搜到哪些图片。会议应用可以按项目或单次会议划分，内容素材工具可以按客户、专题或素材类型划分，电商应用可能按店铺、品牌或商品类别组织。技术层面几种方式都能实现，产品体验却会有明显差异——如果用户进入一个客户项目后绝大多数搜索都发生在当前项目里，项目级范围比较自然；如果用户经常跨项目找历史素材，索引切得太细反而增加操作。scope 的颗粒度最好根据用户平时在哪里发起搜索来决定，而不是照搬现有文件目录或数据库结构。

第二个问题是业务数据和搜索索引怎么保持同步。这个问题在几张图片的 Demo 里很难暴露，真实应用里的图片却一直处于变化状态。假设用户已删除一张图片，业务数据库也移除了记录，但搜索索引仍保留原来的路径——下一次查询仍可能返回这条结果，页面根据 imagePath 加载文件时才发现原图不存在。相反，新图片已进入业务库但索引建立失败，用户能正常浏览却始终无法通过语义搜索找到。

图片文件、业务记录和搜索索引需要一起维护。图片成功保存后再建立索引，用户删除图片时同步删除检索记录。单张图片删除可以这样处理：

async function removeIndexedImage(  imagePath: string,  scope: string): Promise<boolean> {  // 业务图片删除以后同步清理语义索引。  // 删除失败时可以把 imagePath 记录到修复队列。  return await textSearchImage.deleteImage(    imagePath,    scope  );}async function releaseSearchService(): Promise<void> {  // 页面或业务模块不再使用文搜图服务时释放资源。  // release 与清空检索数据承担不同职责。  await textSearchImage.release();}

复制代码

clearData()需要更谨慎地使用。一张图片失效没必要清理整个索引；测试环境重置，或系统能力变化后确实需要重建检索数据，再考虑全量清理。图片数量少时这个区别不明显，几千张以后，全量重新建立索引会带来明显的等待和资源消耗。

因此图片规模增加后，应用最好逐渐转向增量维护，新图片产生后新增索引，图片删除后同步删除索引，已处理完成且文件未变的图片保留现有状态。索引建立时机也要随之调整：几十张时应用启动后完成一次处理可能没影响，几百上千张后每次启动都重建全部索引就很难接受。

第三个容易被忽略的问题是图片路径。系统图库返回的 URI、应用沙箱文件和缓存目录文件拥有不同生命周期。有些路径当前能读取，应用重启后仍有效；有些缓存路径一旦被清理，索引保存的地址就失去意义。李小雨会主动加入生命周期测试：图片插入索引后退出应用，重启执行相同查询；删除原图后重新搜索；移动文件后观察旧索引；清理缓存后检查图片状态。这些测试可能没有漂亮的演示效果，却能提前暴露路径失效和索引残留问题。

第四个问题发生在搜索结果返回之后。语义相似度可以帮助排序，但业务页面还需判断图片是否真的符合用户当前任务。用户输入"活动现场大屏幕"，一张会议室投影照片也可能有一定语义相关性。比较成熟的图片搜索通常会继续叠加时间范围、项目、地点、图片类型、OCR 文字和已有标签，语义搜索负责提供候选结果，业务信息继续缩小范围。

图像超分的调用链确实短很多，按"图片进入应用、解码成 PixelMap、执行超分、处理输出结果"四个阶段理解。当前开发指南已给出比较完整的调用方式，代码本身不长，主要保留分析器生命周期和一次处理流程：

import {  imageSuperResolution,  visionBase} from '@kit.CoreVisionKit';import { image } from '@kit.ImageKit';private analyzer:  imageSuperResolution.ImageSRAnalyzer | undefined;async aboutToAppear(): Promise<void> {  // 页面进入后创建分析器。  // 当前页面连续处理图片时直接复用，减少重复初始化。  this.analyzer =    await imageSuperResolution.ImageSRAnalyzer.create();}private async enhanceImage(  pixelMap: image.PixelMap): Promise<image.PixelMap | undefined> {  if (!this.analyzer) {    return undefined;  }  // Core Vision Kit 接收 PixelMap。  // 图库 URI 或文件路径需要先完成图片解码。  const imageData: visionBase.ImageData = {    pixelMap: pixelMap  };  const request: visionBase.Request = {    inputData: imageData  };  // 执行超分处理，返回新的 PixelMap。  const response: imageSuperResolution.ISPResponse =    await this.analyzer.process(request);  return response.pixelMap;}async aboutToDisappear(): Promise<void> {  if (this.analyzer) {    // 页面离开以后释放分析器资源。    await this.analyzer.destroy();    this.analyzer = undefined;  }}

复制代码

调用关系比较集中，真正进入项目后第一个要考虑的是图片资源。PixelMap 已是解码后的像素数据，输入图片、超分结果、页面当前显示的对象以及后续保存产生的数据，都可能同时占用内存。李小雨会尽量让分析器和页面生命周期保持一致，页面进入后初始化，当前页面处理多张图片时持续复用，页面退出后释放。每次点按钮都重新创建分析器，会让等待过程和资源状态变得更复杂。

异步任务是第二个要提前处理的问题。用户点增强按钮后系统需要一定处理时间，如果按钮在等待期间仍能不断提交任务，很容易出现多个任务同时进行、结果互相覆盖或资源持续增长。页面进入处理状态后可以暂时禁止重复提交，当前任务完成或失败后再恢复操作。

失败处理也要提前设计。用户原本已有一张可查看的图片，超分失败后继续保留原图比较自然。AI 增强可以帮助基础体验，但不应该因为增强能力出异常，导致用户连原始图片都看不了。

第三个问题是输入和输出边界。当前公开的调用方式非常简洁，应用提供 PixelMap 得到新的 PixelMap，公开示例没有向业务层暴露倍率、质量等级或图片类型这样的控制参数。在没有明确底层能力前，没必要提前设计两倍、四倍、高清、超清这类可调选项。更稳妥的方式是先读取不同测试图片的实际输入和输出尺寸，记录 Beta2 环境下的真实结果，再决定界面提供哪些选项。

第四个问题是保存。超分处理完成后应用拿到的是新的 PixelMap，页面能显示增强结果，但用户图库里并不会自动多出一个文件。产品如果需要保存，还要继续完成图片编码、文件写入和媒体库保存。处理成功和保存成功最好用不同状态——用户点增强后先得到预览结果，确认效果合适再保存。这样既减少无意义的文件生成，也让用户清楚当前看到的是临时处理结果还是已保存的图片。

老照片是另一个容易产生预期偏差的场景。当前开发指南确实把老照片修复列为适用方向，但老照片经常同时存在划痕、缺失、严重褪色、曝光异常和颜色变化，超分主要处理分辨率和细节重建，其他问题还需不同图像能力配合。如果产品目前只使用图像超分，李小雨更倾向于用"清晰度增强"或"高清增强"这样的名称，避免用户对效果产生误解。

最后要考虑增强结果的真实性。低分辨率图片本来就缺少一部分信息，超分需要根据已有画面重建更多细节。这种结果适合普通预览、内容创作、历史照片展示和商品图片增强；但证据照片、医疗影像、证件材料和工业检测图片对原始真实性要求更高，应用应该始终保留原图，并在界面上明确区分原始图片和增强结果。

端侧、云端还是自建模型，没有一种方案适合所有图片

文件名、人工标签、OCR、云端服务和自建模型都能参与图片检索，应用应该怎么选？李小雨的答案是先判断用户掌握的是什么信息：知道精确名称，文件名搜索最快；图片有稳定业务分类，标签更可靠；要找图片里的文字，OCR 更适合；只记得画面内容，语义检索更有优势。

几种方式放在同一个应用里并不冲突。用户输入"唐山活动大屏"，语义搜索先找活动现场和大屏幕相关画面，OCR 再检查图片中有没有"唐山"或活动名称，时间、地点和项目字段继续过滤。最终用户看到的是一组综合结果，并不需要了解背后用了几种检索方式。

搜索方式确定后再判断端侧还是云端，核心条件是数据原本保存在哪里。个人相册、本地技术素材、会议截图本来就在用户设备上，设备侧检索比较自然；企业图片集中保存在云端，几十万甚至几百万张需要多人共享，伴随组织权限、审计、备份和跨设备访问，服务端建统一索引更方便。平台范围也影响选择，只有 HarmonyOS 客户端可充分利用系统能力；产品同时覆盖多平台且要求完全一致的结果，统一服务端更容易管理。系统能力和自建模型之间还有控制程度的差异：系统 API 接入简单，专业图像产品如果需要针对人物、文字、动漫和摄影分别选模型并控制质量、倍率和计算预算，自建方案调整空间更大。

李小雨做方案判断时通常会连续确认几个条件：图片保存位置、规模、需要覆盖的平台、数据是否允许上传、团队能承担多少维护成本、算法需要多大控制空间。条件明确后，方案通常不会特别难判断。

从 Demo 到主流程，AI 能力要先经得起测试和失败

AI 能力很容易出现这种情况：几张截图表现很好，换一组样本结果就明显变化。如果测试图片、查询文本、设备和判断标准都没固定，最后得到的准确率或处理时间很难复查，也很难判断升级版本后到底发生了什么变化。

文搜图第一轮没有必要准备特别大的图库。30 张左右的固定图片已经足够逐张检查结果。图片类型尽量拉开差异，会议白板、舞台屏幕、电脑桌面、纸质资料、人物、建筑、技术封面、产品截图和流程图，既要有明显不同也要有容易混淆的场景。查询内容也提前固定，从具体物体到组合关系到完整场景逐级增加，边界测试同样保留：图片中的具体编号、某个具体人物、图库里不存在的物体、比较抽象的气氛描述。结果记录从几个基础指标开始，首次索引时间、单张增加时间、查询时间、Top 1 是否命中、Top 3 是否包含目标、有多少明显无关结果。漏检和明显误检也要保留，它们能帮团队知道系统能力应该放在哪个环节。

生命周期测试和准确率同样重要。图片删除后有没有继续出现在结果里，应用重启后索引状态怎样，清空后能不能正常重建——用户一旦发现已删除的图片还在搜索结果里，很容易对整个搜索功能失去信任。第一轮 30 张验证稳定后再逐步扩大 100 张、500 张、1000 张，观察索引时间和查询时间的变化。

图像超分也需固定测试样本，方式可分两组。第一组有清晰原图，先把高清图片主动缩小，再用低分辨率版本做超分，最终与原始高清图对照，方便观察重建的轮廓和纹理差异。第二组用真实低清素材——聊天压缩图、早期活动照片、小尺寸网络图片、低清文字截图和老照片，更接近日常使用。观察时重点放大局部区域：文字检查笔画连接，人物检查头发和皮肤边缘，建筑和设备观察直线和小结构，重复纹理检查有没有不自然补全。性能记录同时进行，输入尺寸、输出尺寸、单张处理时间、连续处理的内存变化、重复点击有无异常、页面退出后资源有无释放。同样的处理时间放在不同产品里体验完全不同：用户主动增强一张老照片等几秒可能能接受，每次上传图片前自动处理同样的等待就明显拖慢流程。

目前已经能确认的是版本和接口范围：HarmonyOS 7 API 26 已公开文搜图和图像超分，开发工具和配套文档进入 26.0.0 Beta2，Core Vision Kit API 目录已列出 imageSuperResolution 和 textSearchImage，两项能力仍带 Beta 标记。还不能提前写死的是实际检索准确率、具体处理耗时、内存消耗、不同设备间的画质差异，以及大规模图库的真实表现。李小雨会把验证拆成三层：文档确认接口设计和调用方式，本地 Beta2 SDK 与工程编译确认开发环境能不能用，支持设备运行后再讨论性能、准确度和视觉效果。几层证据分开后，每个数字都有明确来源。

从场景来看，如果图片数量已经多到影响人工查找，同时用户能够用自然语言描述自己想找的画面，文搜图就值得进入第一轮验证。内容创作者的本地素材库、会议和企业资料、巡检施工维修售后现场照片、个人相册都是比较典型的例子。

图像超分则适合原图清晰度不足、用户又确实需要进一步查看的场景。老照片、聊天压缩图、历史活动照片、小尺寸商品图都比较合适。触发时机仍然需要控制，用户只是在列表里快速浏览缩略图时，没有必要提前处理所有图片；进入详情页、明确发现图片模糊以后，再提供高清增强入口会更加合理。如果产品运行一段时间后发现大量用户每次都会执行增强，再考虑自动触发或者后台预处理。

也有一些业务需要保持谨慎。搜索精确编号、具体文字和业务状态时优先用 OCR 和结构化数据；具体人物涉及身份识别和隐私，需要单独设计；证据照片、医疗影像、证件材料、工业检测图片和科研图片需保留原始文件，增强结果只能用于辅助查看。大型企业图库也需单独评估，百万级图片、多人权限、集中备份和跨平台访问同时存在时，云端搜索通常仍承担主要工作。跨平台一致性也是产品团队要提前决定的问题：各平台允许存在一定差异时，HarmonyOS 端可优先用系统能力改善本地体验；所有平台必须输出完全相同结果时，统一服务端更容易管理。

对于目前仍在 Beta 阶段的能力，李小雨尤其看重一个判断方式：AI 暂时失效以后，用户原来的任务还能不能完成。文搜图初始化失败以后，文件名称、标签、时间和 OCR 应该继续工作；图像超分失败以后，原图继续显示；当前设备暂时不支持相关能力，页面可以隐藏对应入口，但基础图片功能仍然保持正常。

这个原则也决定了一项 AI 能力适不适合直接进入主流程。如果暂时关闭 AI，用户仍然能够完成原来的任务，那么它更适合先从辅助位置开始接入，等真实效果稳定以后，再逐渐提高在整个流程中的使用权重。

写在最后：从一个非常具体的需求开始

聊到最后，李小雨对未来也提出了几点期待。

往后看，文搜图还需要更加完善的索引管理能力。图片数量边界、不同规模下的使用建议、scope 约束、索引持久化，以及系统更新后的重建方式越清楚，开发团队越容易提前设计正式架构。图片规模持续增加以后，批量插入、批量删除、索引进度、当前索引数量和失败条目也会变得越来越重要。

搜索本身如果能够提供更多业务组合能力，例如时间过滤、其他条件过滤、相似度控制，以及与应用自身标签组合，也会更方便开发者构建混合搜索。真实应用最终往往都会让语义、OCR、标签和结构化数据共同参与，而不是把所有问题都交给单一模型。

图像超分方面，任务管理和质量控制同样值得继续完善，包括处理进度、取消任务、批量处理，以及速度和质量之间的选择。如果以后能够针对文字、人像和普通照片等不同输入特点提供处理策略，产品可以根据实际场景选择更合适的方式。设备能力检测也很重要，端侧 AI 与系统版本和硬件条件联系紧密，如果应用能够在用户点击以前确认当前设备能力，就可以提前决定入口是否展示，也能够避免用户等待一段时间后才发现任务无法执行。

对于独立开发者和中小团队来说，更适合的起点依然不是“大而全”。可以先从一个非常具体的需求开始，例如做一个本地内容素材库，第一版只准备几十张固定图片，完成索引建立、自然语言搜索、图片删除和应用重启，再增加一张低清图片，让用户主动执行图像超分。

这一轮验证完成以后，很多真正影响产品决策的问题其实已经有了答案：图片路径是否稳定，索引是否容易维护，用户的自然语言能不能找到正确内容，超分等待时间能不能接受，资源有没有明显增长，失败以后基础功能能不能继续使用。等这些问题得到验证以后，再决定有没有必要继续扩大。

从这个角度看，HarmonyOS 7 把文搜图和图像超分开放给应用，意义并不只是多了两个视觉 AI API。更实际的变化是，开发团队可以用相对较低的前期成本，把系统 AI 能力先放进一个已经存在的用户问题中，通过真实使用验证它究竟减少了多少操作、改善了多少结果，又增加了多少等待和维护成本。

当 AI 越来越多地进入操作系统和应用开发框架，开发者面临的问题也正在发生变化：从“能不能把 AI 接进应用”，走向“它能不能稳定地留在应用里”。后者考验的已经不只是接口和模型能力，更是开发者对用户任务、工程边界和产品价值的判断。