HarmonyOS 7 视觉 AI 落地实测：文搜图与图像超分两项能力仍带 Beta 标记

HarmonyOS 7 API 26 在 Core Vision Kit 里加入两项视觉能力，分别瞄准“找图难”和“图片清晰度差”两个老问题。一项叫“文搜图”，允许应用根据文本语义检索图片；另一项叫“图像超分”，可以对低分辨率图像进行超分辨率重建。目前 HarmonyOS 开发者官网已提供 26.0.0 Beta2 配套文档与开发工具，两项能力在 API 目录中仍带 Beta 标记。

为了搞清楚这两项能力到底怎么落地，我们找了一位长期活跃在 HarmonyOS 应用开发一线的开发者聊了聊。李小雨拥有 13 年研发、产品和项目管理经验，长期参与 HarmonyOS 应用开发，同时从事独立开发、大模型产品化和企业 AI 服务。

人记住的是“画面”，图片搜索正在换一种方式

聊起文搜图和图像超分，李小雨没有急着讲 API，而是先讲人。文搜图首先碰到的是人的记忆方式和文件管理方式之间的差异：文件系统保存的是名称、目录和时间，人真正记住的却经常是场景。“背景偏蓝、屏幕前有人演讲，或者照片里出现过白板、电脑和纸质材料”，这才是几个月后留在脑子里的东西。

图片数量少时这道鸿沟不明显，数量一多就逐渐放大。过去解决这类问题，常见方式是整理目录、修改文件名、加标签，或通过 OCR 提取图片里的文字。几种方法都有价值，但都要求图片提前存在能被精确匹配的信息。用户如果只记得画面内容，传统搜索能利用的信息就相当有限。

文搜图增加了一种更接近日常表达的搜索方式，系统根据文本语义在已建立索引的图片中寻找接近的内容。开发者不需要从头搭建跨模态模型和底层检索能力，就能先验证这种搜索方式适不适合自己的业务。

不过，李小雨并不把它当成万能搜索框。“用户已经知道文件名时，文件名搜索最快；图片有稳定业务分类时，标签更可靠；搜索合同编号、门店名称、白板文字时，OCR 更适合。”文搜图主要处理画面语义和模糊记忆，几种能力放在一起，效果通常更稳定。

图像超分放在查找之后，用户流程更完整

图像超分则出现在查找之后。图片找到了，用户准备进一步查看，却发现原始尺寸太小，这种情况在真实应用里非常常见。它更适合放在用户已经明确想继续查看或使用某张图片之后，没必要让应用提前处理整个图库。两项能力连起来，用户流程就比较完整：前面减少查找，后面改善查看。

而李小雨做产品时最在意的一点是，AI 功能要对应一个已经存在的问题，并且能减少原来的操作成本。“一个 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 怎么设计。这个参数看起来只是范围标