前言

聊到 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 能力就更容易落到真实项目里。