前言

一个已有 HarmonyOS 6 原生项目，到底应该怎样安排 HarmonyOS 7 适配路线。

这类项目通常已经有完整业务结构。比如会议类应用里，可能已经有会议列表、会议详情、新建会议、联系人、待办、项目、设置、本地数据库、页面路由、权限申请和多端适配基础。如果一拿到 API 26 Beta，就直接开始大范围重构，很容易把原本稳定的主流程改乱。

HarmonyOS 7 API 26 Developer Beta1 面向开发调测，适合提前体验 API 26.0.0 Beta1 版本的新能力、新特性，并使用 DevEco Studio 进行应用开发；这个阶段也适合通过邀请测试和远程真机云调试等方式完成应用验证。

我不按单点能力展开，而是用一个会议类项目来拆完整路线。

这里以 会议随记 Pro / 会后行动台 这类应用作为样例。它的核心业务是：记录会议、整理纪要、提取待办、关联联系人、沉淀项目进展，后续还可以扩展到周报生成、跨端同步和 Agent 任务链。

这类项目做 HarmonyOS 7 适配时，可以先把事情分成两类：

整条路线可以概括成一句话：

先保证项目能跑，再整理能力边界；先做最小验证，再逐步接入新能力。

一、先做工程基线

真实项目适配 HarmonyOS 7，第一步应该是工程基线。

所谓工程基线，就是先确认项目在 API 26 环境下能不能打开、编译、安装、启动、运行主流程。这个阶段不适合马上接 Skill、Agent、AI 或空间化能力。因为主流程还没有稳定时，新能力接入只会让问题来源变得更复杂。

以会议类应用为例，第一轮可以先检查这些内容。

HarmonyOS SDK 的版本信息需要结合 DevEco Studio 查看，官 SDK 内置在 DevEco Studio 中，具体版本可在 DevEco Studio 的相关菜单中查询。

对已有项目来说，适配分支很重要。稳定分支继续保留，API 26 迁移放到独立分支里处理。

main  └── feature/harmonyos7-api26-adaptation

这个分支命名只是项目侧约定，重点是把 API 26 相关改动隔离出来。后续如果某个配置、依赖或页面改动导致问题，可以和主分支快速对照。

工程基线阶段还需要保存一次迁移前主流程记录。

这张表比直接开始改代码更有价值。迁移后出现异常时，可以先判断问题是不是 API 26 环境下新增的。如果迁移前状态没有记录，排查时很容易陷入反复猜测。

P0 只处理工程能不能跑，不处理体验增强和新能力接入。

二、再把业务功能整理成能力清单

工程能跑以后，第二步才是能力整理。

HarmonyOS 7 的新能力页已经把 Skill、Agent 和视觉 AI 放在智能化方向里，同时 Agent 方向强调系统能力和模型能力开放，支持 Agent 能力构建和已有 Agent 的 A2A 接入。

这对会议类项目的影响，在于把页面背后的业务功能整理成能力单元。

会议类项目原本可能是按页面组织的。

到了能力视角，我们可以整理成另一张表。

这里的关键是区分 生成草稿 和 执行动作。

生成纪要、提取待办、生成周报草稿，都可以先作为低风险能力整理。它们的结果可以展示给用户确认，不直接改变外部状态。发送周报、删除会议、自动分配责任人，属于高风险动作。它们会影响数据、协作关系或对外输出，第一阶段不适合自动化。

能力清单整理完以后，可以继续沉到服务层。

pages/  MeetingListPage.ets  MeetingDetailPage.ets  MeetingNewPage.ets​services/  MeetingService.ets  MeetingSummaryService.ets  MeetingActionService.ets  WeeklyReportService.ets​models/  MeetingModel.ets  ActionItemModel.ets  ContactModel.ets  ProjectModel.ets

这个结构是项目侧组织方式，用来表达页面、服务和模型的分层关系。它的价值在于让页面按钮、Skill 候选入口、Agent 任务链都可以复用同一组服务能力。

能力整理阶段可以先做三件事。

这一阶段暂时不需要追求完整 Skill 接入。先把能力拆出来，后续文档、SDK、设备和审核链路更稳定时，接入成本会明显降低。

三、选择一个最小 AI / Agent 链路验证

能力清单整理以后，第三步是选择一个最小验证链路。

这里最容易出错的地方，是一开始就想做完整 Agent。比如从会议录音到转写，再到纪要、待办、责任人、截止时间、周报、发送、归档，全部交给 Agent 自动处理。这个目标很吸引人，但第一阶段变量太多。

而更稳妥的方式，是先选一条低风险链路。

会议文本 → 生成纪要草稿 → 提取待办草稿 → 用户确认 → 保存草稿

这条链路适合作为第一轮验证，有几个原因。

HarmonyOS 7 的智能化方向包含 AI 开放能力、Skill 和 Agent 相关能力。对于项目来说，第一轮更适合验证 输入 → 候选结果 → 用户确认 → 保存结果 这条低风险结构，而不是直接完成高风险自动执行。

这里可以用一个项目侧输入输出样例固定验证目标。

{  "input": {    "meetingText": "本次会议确认了版本节奏、接口联调安排和下周发布前的测试计划。"  },  "expectedOutput": {    "summary": "本次会议围绕版本节奏、接口联调和发布测试安排展开。",    "actionItems": [      {        "title": "确认接口联调时间",        "needConfirm": true      },      {        "title": "整理发布前测试清单",        "needConfirm": true      }    ]  }}

这个样例属于项目侧验证样例。它不代表某个 HarmonyOS 7 新 API 的运行结果。它的作用是让后续 AI 能力验证有明确目标：输入是什么、输出应该是什么、哪些结果需要确认。

最小验证链路还应该配一张状态表。

第一阶段只做前五项。后面三项暂缓。这样做可以让验证结果更干净，也能避免过早把高风险动作放进自动化链路。

这里还要配合日志记录。

interface TaskExecutionLog {  taskId: string;  abilityName: string;  inputSummary: string;  status: 'success' | 'failed' | 'cancelled';  errorMessage?: string;  createdAt: number;}

日志结构可以先保持简单。只要能记录任务、能力、输入摘要、执行状态、错误信息和时间，就能支持后续复查。Beta 阶段的问题经常和 SDK、设备、权限、服务条件有关，日志会比临时描述可靠得多。

四、多端和空间化先改核心页面

AI 和 Agent 链路之外，多端适配也要进入路线图。

HarmonyOS 开发者官网的探索页已经把多设备应用开发作为重要方向，覆盖一次开发、多端部署，以及折叠屏、平板、鸿蒙电脑等应用开发实践入口。

对于会议类项目来说，多端适配不应该等到最后才处理。因为会议类应用天然有列表、详情、编辑、待办、项目看板这些页面，大屏和折叠屏展开态会明显影响信息组织方式。

第一阶段可以先改五类页面。

对于列表详情页，可以先用主从结构处理大屏。

手机：会议列表 → 会议详情大屏：左侧会议列表 + 右侧会议详情

这类改造对真实项目很有价值。它不依赖某个新 API，也不会打乱业务逻辑，但能让应用在平板、折叠屏和窗口环境里更自然。

编辑页也适合优先处理。会议纪要编辑页可以把内容分成三层。

这三层分清楚以后，后续接入 AI 生成、Skill 调用或 Agent 链路时，用户不会混淆原始内容、生成内容和最终内容。

空间化能力可以先放在第二阶段。HarmonyOS 7 新能力页提到沉浸光感组件和 3DGS 端侧重建等空间化方向，前者强调光学行为、空间属性和交互响应能力，后者更适合空间建模、商品展示和文旅展陈等 3D 内容场景。会议类工具应用第一阶段可以先做层级、分栏、状态和确认，不必强行接入复杂 3D 能力。

页面改造优先级如下。

这条路线比较稳。先改核心路径，暂缓全站视觉重构。等核心页面在多端环境里稳定后，再选择适合页面做空间化增强。

五、最后用工具链和优先级表控制节奏

真实项目适配 HarmonyOS 7，最后一定要靠工具链和优先级表收住节奏。

DevEco Studio 覆盖 AI 辅助编程、编译构建、UI 实时预览、代码调试、性能调优、模拟器等能力；DevEco Code 面向 HarmonyOS 开发场景，DevEco CLI 面向编程 Agent，提供工程创建、语法检查、编译构建、运行调测等全流程工具能力。

这意味着，工具链应该进入适配流程，而不是只在写代码时出现。

我们可以把 DevEco Code 和 DevEco CLI 放到这些环节里。

工具链进入以后，适配工作可以从单次修改变成闭环。

问题现象 → 上下文收集 → 工具建议 → 最小修改 → 编译运行 → 真机验证 → 记录结论

这条闭环比一次性重构更适合真实项目。每一轮只解决一个问题，修改范围清楚，结果可以复查，回退也更容易。

最后我们可以把所有事项排成一张路线表。

也可以按照 P0、P1、P2 继续拆。

这张表就是项目适配路线的核心。它能避免两个常见问题：一类是看到 HarmonyOS 7 新能力很多，就立刻全面重构；另一类是因为 Beta 阶段还在变化，就所有准备工作都不做。

更合适的状态，是 P0 立刻做，P1 分阶段做，P2 保持观察。这样既能跟上 HarmonyOS 7 的方向，也不会破坏现有项目稳定性。

总结

一个已有 HarmonyOS 6 原生项目适配 HarmonyOS 7，不需要把所有新能力一次性接完。

应该按照如下路线进行：

对于会议类项目，第一轮可以只做这些事：API 26 分支、编译安装、首页加载、会议列表详情、新建保存、旧数据读取、权限检查、能力清单、纪要草稿和待办草稿最小验证、首页和列表详情多端适配。

暂时不动的内容也要明确：不做全量 Agent 自动执行，不做自动发送周报，不做自动删除会议，不做自动分配责任人，不做全站空间化重构，不在主流程还没稳定时接入太多新能力。

这样安排以后，HarmonyOS 7 适配会更像一条可控路线，而不是一次冒险式重构。先把现有项目稳定跑起来，再把能力边界和验证闭环建立起来，后面的 Skill、Agent、AI 开放能力、多端适配和工具链升级，才有真正落地的基础。