前言聊到 HarmonyOS 7 的 AI 开放能力大家很容易先想到模型能力。比如能不能做图像识别能不能做语音理解能不能做文本总结能不能让 Agent 帮用户完成一串任务。这个方向当然重要但如果你正在维护一个真实项目第一步其实不适合直接从模型列表开始。更合理的顺序是先回到业务场景里。这个功能是不是经常需要用户输入很多内容。这个页面里是不是存在大量重复整理工作。这个操作是不是原来要连续进入多个页面。这个结果是不是需要用户确认之后才能保存。这个能力接入以后是不是能减少用户操作成本而不是增加解释成本。这些问题先想清楚后面再去选择具体 AI 能力决策会稳很多。HarmonyOS 7 的新能力方向里智能化部分已经包括 Skill、Agent 和视觉 AI 能力。Skill 关注应用功能被系统级智能入口调用Agent 关注系统能力和模型能力开放视觉 AI 能力关注端侧视觉 AI 处理。对于应用开发来说这些能力并不是越多越好真正关键的是把它们放到合适的业务环节里。今天我们先从业务侧拆开看。哪些场景值得接 AI哪些场景暂时不急AI 能力应该放在流程的哪个位置如何设计输入、输出、确认和回退会议类、内容类、本地生活类应用应该怎么排优先级如果你已经有 HarmonyOS 6 原生项目那么我不建议你一上来重构页面也不建议你把所有功能都加上智能入口。先挑一个高价值、低风险、输入输出清楚的小场景完成最小验证会更适合 Beta 阶段的节奏。一、先从业务动作里找 AI 候选场景很多项目想接 AI 的时候会先去看模型能力。能总结、能识别、能生成、能问答这些能力看起来都很吸引人。可是放到应用里以后真正要判断的是这个能力能不能解决一个具体的业务动作。比如会议类应用里用户真正头疼的不是没有一个 AI 按钮而是会议结束以后还有很多整理工作。录音要转写转写文本要压缩成纪要纪要里要提取决议和待办待办还要分配责任人最后可能还要生成周报草稿。这些动作都很适合进入 AI 候选清单因为它们有几个共同特点。第一输入成本比较高。会议文本、录音转写、图片素材、长文档都不是用户愿意反复手动处理的内容。第二整理工作比较重复。摘要、分类、提取、改写、归档这些动作每次都差不多但人工处理很耗时间。第三结果可以先作为草稿。AI 先生成候选结果用户确认后再保存这样风险会小很多。可以先把常见应用场景放进一张表里。应用场景典型业务动作AI 接入价值会议纪要摘要、决议、待办提取减少会后整理时间待办管理识别责任人、截止时间、优先级降低手动录入成本周报生成汇总会议和待办进展降低重复写作成本图片处理图像识别、图像增强、素材归类降低素材整理成本本地生活意图识别、地点匹配、预约草稿减少跨页面操作学习工具知识点提取、错题归类、复习计划提高资料整理效率这个表的目的不是马上决定接入哪个 API而是先把业务动作梳理清楚。如果一个功能本身没有明确输入也没有明确输出只是因为AI 很热才想接入那它很可能不适合放在第一阶段。比如普通设置页、简单开关项、单字段表单这类功能用传统交互已经足够清楚强行增加智能入口反而会增加理解成本。这里我们可以先形成一个基本判断AI 优先放在高输入成本、高整理成本、多步骤连接明显的场景里。这句话看起来简单但在项目里很有用。它能帮助你避免把时间花在低价值智能化上也能让后续验证更容易出结果。二、用三个问题判断 AI 能力值不值得接入确定候选场景以后下一步不要急着写代码。先用三个问题做一轮筛选。这一步很像产品判断也很像工程判断。因为 AI 接入以后成本不只在能力调用本身还包括权限、性能、失败处理、用户确认、结果解释和后续维护。如果前面没有筛选清楚后面很容易出现一种情况功能看起来更智能了但真实使用反而更绕。可以先问三个问题。判断问题适合接入的表现暂缓接入的表现用户输入成本是否较高需要输入长文本、语音、图片、复杂条件只需要点一个按钮或填一个简单字段内容整理是否频繁经常做摘要、分类、提取、改写偶尔使用且人工处理很快多步骤是否能够合并原本要跨多个页面连续操作单步操作已经足够清楚如果一个功能同时满足其中两项就值得进入第一轮验证。比如会议纪要。它需要处理长文本整理摘要、决议、待办还可能继续关联周报生成。这个场景输入重、整理重、链路长AI 接入价值比较明显。再比如设置页里的开启提醒。这个功能交互非常清楚用户只需要切换一个开关。把它包装成 AI 意图调用第一阶段意义不大。除非后续要做更复杂的提醒配置比如根据会议内容自动建议提醒时间否则这个功能暂时保持传统交互就可以。下面这张表可以帮助你快速判断。功能输入成本整理频率多步骤价值接入建议生成会议纪要高高高优先验证提取待办事项中高高中高优先验证生成周报草稿高高高优先验证图片素材归类中高中高中可以验证本地生活预约草稿中中中高可以验证设置页开关低低低暂缓接入普通列表筛选低中低观察即可这里还有一个实际项目里的细节。AI 输出结果越可能影响用户承诺确认流程就越重要。生成纪要草稿可以先自动化保存纪要前建议确认。提取待办可以先自动化分配责任人前必须确认。生成周报可以先自动化发送周报前必须确认。这样做不是保守而是为了避免 AI 结果直接影响真实协作关系。三、把 AI 能力放进流程而不是单独做一个按钮很多 AI 功能不好用不是因为模型能力不够而是因为它被放错了位置。如果你在一个页面上直接加一个AI 生成按钮用户可能不知道它会处理什么内容也不知道生成结果会保存到哪里更不知道失败以后怎么回退。这样的 AI 功能看起来很显眼但不一定真正好用。更稳的方式是把 AI 能力放进已有流程。以会议类应用为例原来的流程可能是这样打开会议详情 → 查看转写文本 → 点击生成纪要 → 查看纪要 → 手动整理待办 → 保存结果加入 AI 能力以后不一定要重新设计整套页面。我们可以先把流程调整为打开会议详情 → 检查转写文本 → 生成纪要草稿 → 提取待办草稿 → 用户确认 → 保存结果这个变化的重点是让 AI 生成结果成为草稿而不是直接成为最终数据。草稿可以展示、修改、确认、放弃。这样用户会更安心项目风险也更可控。可以把 AI 能力放到流程里的几个位置。流程位置适合的 AI 动作风险控制输入前自动补全、格式整理、语音转文本用户可以继续编辑输入后摘要、分类、提取、改写生成草稿不直接保存保存前检查缺失信息、提醒风险只提示不强制修改多步骤中间合并操作、生成候选结果需要明确展示结果对外输出前生成邮件、周报、通知草稿必须确认后发送这个表适合放到很多项目里复用。比如本地生活助手里AI 可以先识别用户意图再生成预约草稿。真正提交预约前仍然要展示时间、地点、人数和联系方式让用户确认。比如图片处理工具里AI 可以先识别图片内容并建议分类。真正批量移动、删除或者公开发布前仍然要确认。比如学习工具里AI 可以先提取知识点和错题标签。真正生成复习计划前可以先让用户调整学习时间和优先级。这里可以用一个输入输出样例固定会议纪要场景的验证目标。它属于项目侧验证样例不代表 HarmonyOS 7 新 API 的实测结果。{input:{meetingText:今天讨论了版本计划、接口联调和下周发布安排。},expectedOutput:{summary:本次会议围绕版本计划、接口联调和发布安排展开。,actionItems:[确认接口联调时间,整理下周发布清单],needUserConfirm:true}}这个样例的作用是让后续验证有一个明确目标。真正接入 AI 能力时你可以对比实际输出和预期输出继续记录准确性、稳定性、耗时、权限、用户确认结果。四、根据能力类型设计不同的验证方式AI 开放能力不是一个单一功能。视觉、语音、语言理解、任务链路验证方式都不一样。HarmonyOS 7 的智能化方向里视觉 AI 能力强调端侧视觉 AI 处理Skill 和 Agent 则更偏向应用能力被系统级智能入口调用以及系统能力和模型能力开放。这里不能把所有 AI 能力都用同一个验证标准处理。可以先按照能力类型拆开。能力类型常见场景验证重点视觉 AI图像增强、内容识别、素材分类识别准确性、耗时、隐私边界语音能力语音输入、会议转写、语音指令噪声环境、识别稳定性、纠错流程自然语言摘要、改写、提取、分类输出准确性、可编辑性、确认流程Agent / Skill多步骤任务、系统入口调用任务边界、确认机制、失败回退工具链 AI代码生成、报错解释、构建修复是否能通过编译和运行验证以会议类应用为例最适合优先验证的是自然语言类能力。因为会议纪要、待办提取、周报草稿都依赖文本处理输入输出相对明确。视觉 AI 对会议类应用也有价值但优先级可能没有纪要和待办高除非应用本身涉及图片附件、白板内容、合同照片或者资料截图。以图片类应用为例视觉 AI 的优先级就会明显提高。它可能要处理图片增强、内容识别、素材归类、封面推荐。这个时候验证重点就会变成准确性、耗时、图片权限、端侧处理能力和批量处理稳定性。以本地生活类应用为例AI 更适合放在意图识别和预约草稿上。比如用户输入明天晚上帮我找一个适合两个人吃饭的地方应用可以先生成筛选条件和预约草稿但最终地点、时间和联系方式仍然需要确认。可以把不同项目的优先级整理成这样。应用类型优先验证能力暂缓能力会议类应用纪要生成、待办提取、周报草稿复杂 Agent 自动执行图片类应用图像识别、素材分类、图像增强高风险批量删除学习类应用知识点提取、错题归类、复习计划自动提交作业本地生活应用意图识别、预约草稿、地点匹配自动下单和支付项目管理应用风险提取、进度汇总、待办分配建议自动分配责任人这里需要特别注意自动化程度。AI 能够生成建议不代表适合直接替用户完成最终操作。越接近提交、发送、支付、删除、分配这类动作确认流程越不能省。五、最后用最小场景排出接入优先级到了真正动手阶段建议不要一次接入太多 AI 能力。我们先选一个最小场景跑通。最小场景最好满足几个条件。条件原因输入清楚方便构造测试数据输出明确方便判断效果好坏风险较低失败后不会破坏主流程用户价值明显容易判断是否值得继续投入能和现有项目结合不会变成孤立 Demo对于会议类应用一个很适合的最小场景是会议文本 → 生成纪要草稿 → 提取待办草稿 → 用户确认 → 保存结果这条链路有明确输入也有明确输出。生成结果先作为草稿确认后再保存风险相对可控。后续如果效果稳定可以继续扩展到责任人识别、截止时间提取、周报草稿生成。可以这样安排优先级。优先级能力原因P0会议文本整理输入明确业务高频P0纪要草稿生成用户价值明显风险较低P1待办提取价值高但需要确认P1截止时间识别能减少手动录入P1周报草稿生成和会议、待办数据联动P2自动分配责任人涉及协作关系需要谨慎P2自动发送周报对外输出必须确认如果是本地生活应用可以换成另一条最小链路。用户需求 → 意图识别 → 推荐条件 → 预约草稿 → 用户确认如果是图片工具可以换成图片输入 → 内容识别 → 分类建议 → 用户确认 → 保存分类这里大家可以发现最小验证链路的结构其实很相似输入 → AI 处理 → 候选结果 → 用户确认 → 保存结果。这个结构适合大多数低风险 AI 接入场景。当第一条链路跑通以后再考虑扩展能力范围。这个顺序比一开始就做完整智能化改造更稳。尤其是 Beta 阶段文档、SDK、设备、权限和工具链都可能继续变化我们先把一个小场景做透再逐步扩大范围项目会更容易控制。总结HarmonyOS 7 AI 开放能力的选择不适合从模型列表开始。更稳的路径是先回到业务场景判断哪里真的需要 AI。可以按照五步处理。步骤要做什么1从业务动作里找 AI 候选场景2用输入成本、整理频率、多步骤价值做筛选3把 AI 能力嵌入现有流程不直接打断主流程4按视觉、语音、自然语言、Agent、工具链分开验证5选择一个最小场景完成接入验证如果你已经有 HarmonyOS 6 原生项目可以先从一个小场景开始。会议类应用可以先做会议文本 → 纪要草稿 → 待办草稿 → 用户确认 → 保存结果。本地生活类应用可以先做用户需求 → 意图识别 → 预约草稿 → 用户确认。图片类应用可以先做图片输入 → 内容识别 → 分类建议 → 用户确认。AI 接入的价值不是让应用每个页面都出现智能按钮而是减少那些原本高输入、高整理、多步骤的重复工作。只要这个判断顺序没乱HarmonyOS 7 的 AI 能力就更容易落到真实项目里。