前言

做 HarmonyOS 应用时，我们过去很自然地按照页面来组织功能。

比如会议类应用，会有会议列表页、会议详情页、新建会议页、待办页、联系人页、周报页。每个页面都有自己的按钮、状态、数据加载和跳转逻辑。这个方式在传统 App 开发里很好理解，项目刚开始也很容易推进。

到了 HarmonyOS 7，情况开始有一点变化。

Skill、Agent、AI 开放能力被放到了系统智能化方向里，应用功能不再只停留在页面内部。HarmonyOS 7 新能力页面里，Skill Vibe Coding 覆盖 Skill 开发、调测、审核、上架，并且目标是让应用功能能够被系统级智能入口调用。

这对我们写应用的影响是很大的。

页面仍然要开发，交互仍然要优化，数据仍然要保存。但在页面背后，还要多一层思考：这个功能能不能被整理成一个独立能力？它需要什么输入？返回什么结果？失败以后怎么反馈？哪些动作可以自动执行，哪些动作必须确认？

这次我们就围绕这个问题展开聊聊。

从页面功能到 Skill 能力，HarmonyOS 7 应用到底应该怎么拆分。

一、先判断哪些页面功能值得拆成能力

我们在改一个已有项目时，很容易一上来就想着怎么接 Skill。这个顺序其实有点急了。

更稳的做法，是先回到项目里，看看哪些功能本身已经具备独立能力的特征。很多页面里的按钮，看起来只是一次点击，背后其实已经包含完整的业务动作。比如生成会议纪要、提取待办事项、生成周报草稿，这些功能都有明确输入，也有明确输出，还能单独判断成功或者失败。

这类功能就适合优先进入能力拆分表。

相反，一些纯展示类页面、简单设置项、普通跳转按钮，暂时没有必要都拆成 Skill 候选能力。它们继续留在页面内部会更自然，维护成本也更低。我们不需要为了追新能力，把所有按钮都改造成外部可调用能力。

可以先用三个问题筛选。

判断问题	适合拆成能力的表现
用户意图是否清晰	用户一句话就能表达目标，比如生成纪要、创建待办
输入输出是否明确	有清楚的输入参数，也有可保存或可展示的结果
是否能脱离当前页面执行	不强依赖当前页面临时状态，可以放到服务层执行

如果一个功能同时满足这三个条件，就可以进入 Skill 候选清单。

以会议类应用为例，下面这些功能就比较适合优先整理。

页面功能	是否适合拆分	原因
创建会议	适合	输入明确，输出是会议记录
生成纪要	适合	输入是会议内容，输出是纪要草稿
提取待办	适合	输入是会议文本，输出是待办列表
分配责任人	适合，但要确认	涉及协作动作，需要用户确认
切换页面 Tab	暂不适合	只是页面导航，不是独立业务能力
修改主题颜色	暂不适合	设置项简单，系统调用价值不明显

这里大家可以先别急着写代码。第一步先把功能列出来，然后给每个功能写一句自然语言描述。比如 生成纪要 可以写成 根据会议文本生成摘要、决议和待办事项。如果一句话都说不清楚，这个功能暂时就不适合拆成 Skill 能力。

二、再把页面结构改成能力结构

很多 HarmonyOS 项目刚开始都会按页面组织。这个方式符合开发习惯，也方便快速搭建功能。但当应用需要接入系统级智能入口时，只看页面结构就不够了。

页面结构关注的是用户怎么操作。
能力结构关注的是系统能调用什么。

这两件事的侧重点不同。页面里可以有按钮、列表、弹窗、加载状态；能力里需要有输入、输出、执行过程、确认要求和失败回退。我们拆 Skill 的时候，真正要做的事情，就是把页面中的业务动作抽出来。

以会议类应用为例，页面结构通常是这样的。

页面	页面职责
会议列表页	展示会议记录，支持进入详情
会议详情页	展示会议内容、录音、纪要、待办
新建会议页	创建会议并保存基础信息
待办页	展示待办事项，更新完成状态
周报页	整理阶段进展，生成周报草稿

换成能力结构以后，就会变成另一张表。

能力名称	用户意图	输入	输出	是否需要确认
创建会议	帮我记录一次会议	标题、时间、参与人	会议记录	可选
生成纪要	帮我总结这次会议	会议文本、录音转写文本	纪要草稿	建议确认
提取待办	帮我找出行动项	会议内容	待办列表	建议确认
分配责任人	把待办分给对应人员	待办、联系人	更新后的待办	需要确认
生成周报	整理本周项目进展	时间范围、项目	周报草稿	需要确认

这张表比页面结构更接近 Skill 思路。它不关心按钮放在哪里，也不关心页面怎么布局，它关心的是这个能力能不能被清楚调用。

这里有一个很实用的判断方法。

如果一个功能必须依赖某个页面的临时状态才能执行，它还没有准备好变成 Skill 能力。
如果一个功能可以通过明确参数启动，并且返回稳定结果，它就可以进入 Skill 候选池。

比如 生成纪要 这个功能，如果只写在会议详情页的按钮点击事件里，后续复用会比较麻烦。更好的方式，是把它抽到服务层。页面点击按钮时调用服务层；以后 Skill 或 Agent 需要调用时，也可以复用同一套能力边界。

能力结构整理完成以后，页面和服务层的关系也会变得更清楚。

层级	主要职责
页面层	展示界面、触发操作、展示状态
服务层	执行业务能力
数据层	保存输入、结果和状态
校验层	检查参数、权限和边界
确认层	处理高风险动作确认

这样拆完以后，项目结构会比原来更适合扩展。即使暂时不接 Skill，后续维护也会轻很多。

三、给每个能力补齐输入、输出、确认和回退

一个页面功能能不能变成 Skill 候选能力，关键不只是名字好不好听。真正要看的是它有没有完整的调用契约。

我们可以把调用契约理解成四件事。

• 输入是什么
• 输出是什么
• 是否需要确认
• 失败以后怎么处理

这四件事没有整理清楚，能力就很难稳定复用。页面内部调用时，很多细节可以靠上下文补齐；系统级智能入口调用时，就不能依赖这些隐含状态了。

以 生成纪要 为例，简单说 生成一份会议纪要 还不够。我们要继续补充更具体的信息。

项目	内容
能力名称	生成纪要
输入	会议 ID、会议文本、录音转写文本
输出	摘要、决议、待办、风险点
确认要求	建议用户确认后保存
失败情况	文本为空、文本过长、生成失败、用户取消
回退方式	保留原始文本，允许重新生成或手动编辑

这张表看起来有些繁琐，但它会直接影响后续接入质量。

比如 生成失败 时，页面可以提示重新生成；如果是系统级智能入口调用，就需要返回明确失败原因。再比如 文本过长 时，是截断、分段，还是提示用户选择内容范围，也需要提前考虑。否则能力虽然可以被调用，体验却很不稳定。

这里可以用一个项目侧接口草案来固定能力边界。它描述的是业务能力结构，不代表 HarmonyOS 7 新 API 的实测结果。

export interface MeetingSummaryInput {
  meetingId: string;
  transcript: string;
  language?: string;
}

export interface MeetingSummaryResult {
  summary: string;
  decisions: string[];
  actionItems: string[];
  risks?: string[];
}

export async function generateMeetingSummary(
  input: MeetingSummaryInput
): Promise<MeetingSummaryResult> {
  return {
    summary: '',
    decisions: [],
    actionItems: [],
    risks: []
  };
}

这段代码的作用，是把能力边界提前固定下来。你可以先不接任何 HarmonyOS 7 新能力，也不接 AI 模型，只要先把输入输出结构整理好，后面接入 Skill、Agent 或 AI 能力时，页面层就不会被反复改动。

对于高风险动作，还要单独加确认流程。

比如 分配责任人 和 生成周报。它们不像生成草稿那么轻量，一旦保存或者发送，就可能影响协作流程。所以这类能力不适合直接自动执行。更稳的方式，是先生成候选结果，再让用户确认。

可以这样整理。

能力	自动执行程度	处理建议
查询会议	可以自动执行	只返回结果，不修改数据
生成纪要草稿	可以自动生成	保存前建议确认
提取待办	可以自动提取	保存前建议确认
分配责任人	不建议自动完成	必须确认
删除会议	不建议自动完成	必须确认

我们在拆 Skill 能力时，最好不要只盯着成功路径。失败路径和确认路径同样重要。真实项目里，很多问题都不是出在功能能不能执行，而是出在用户取消、权限不足、数据缺失、结果不准确这些边界情况上。

四、把能力沉到服务层，不要只挂在页面事件里

拆 Skill 的过程，最后一定会回到代码结构。

很多项目一开始写得很快，按钮点击事件里直接处理业务逻辑，这很正常。比如在会议详情页里点击 生成纪要，直接读取文本、调用生成逻辑、更新页面状态、保存结果。项目规模小时，这种写法没有太大问题。

但当功能开始变多，页面之间开始复用同一类能力时，问题就会出现。

同样的生成逻辑，会议详情页要用，周报页也可能要用；以后 Skill 要调用，Agent 任务链路也可能要调用。如果能力一直挂在页面事件里，每增加一个入口，就要复制或者重新包装一遍逻辑。这样维护成本会越来越高。

更稳的结构，是把能力沉到服务层。

可以把会议相关能力整理成类似这样的结构。

features/
  meeting/
    pages/
      MeetingListPage.ets
      MeetingDetailPage.ets
      MeetingCreatePage.ets
    services/
      MeetingService.ets
      MeetingSummaryService.ets
      MeetingActionService.ets
    models/
      MeetingModel.ets
      ActionItemModel.ets

页面层只负责交互和展示，服务层负责执行能力，模型层负责数据结构。这样拆完以后，页面入口、Skill 候选入口、Agent 任务链入口，都可以指向同一套服务能力。

比如生成纪要，可以放到 MeetingSummaryService 里。

export class MeetingSummaryService {
  async generateSummary(input: MeetingSummaryInput): Promise<MeetingSummaryResult> {
    // 这里先保留业务接口边界
    // 后续可以接入 AI 能力、云端服务或本地模型
    return generateMeetingSummary(input);
  }
}

这段代码仍然属于项目结构草案。它的意义不是展示某个 HarmonyOS 7 新接口，而是说明能力应该从页面事件里抽出来。这样后续接入 Skill 时，页面不需要知道能力来自哪里，只需要处理状态展示和用户确认。

页面调用时，可以保持很清楚。

const result = await this.summaryService.generateSummary({
  meetingId: this.meetingId,
  transcript: this.transcript
});

这里有一个很重要的思路：页面不应该承担所有业务判断。页面可以负责按钮状态、加载提示、结果展示、错误提示；能力是否可以执行、输入是否完整、输出如何保存，这些更适合放到服务层和校验层。

拆到这里，项目会更接近下面这条路径。

页面操作 → 服务能力 → 数据保存 → 用户确认 → 状态反馈

这个结构对 Skill 很重要。因为系统级智能入口调用能力时，不一定经过原来的页面路径。如果能力只能通过页面按钮触发，系统就很难稳定复用。服务层越清楚，能力接入外部入口时就越轻。

五、用一张表确定拆分优先级

页面功能很多，不可能一次性全部拆完。真正落到项目里，还是要排优先级。

优先级可以按照三个维度判断。

维度	判断方式
用户价值	这个能力是否能明显减少操作成本
接入难度	输入输出是否清楚，是否依赖复杂页面状态
风险等级	是否会修改关键数据，是否需要确认

把这三个维度放在一起，就能大概排出拆分顺序。

以会议类应用为例，可以这样安排。

优先级	能力	原因
P0	创建会议	输入简单，主流程高频
P0	查询会议	风险低，适合系统入口调用
P1	生成纪要	用户价值高，但需要确认
P1	提取待办	业务价值高，适合和纪要联动
P1	生成周报	输出价值高，但依赖多个数据来源
P2	分配责任人	涉及协作动作，需要更强确认
P2	删除会议	高风险动作，不建议优先开放

这个表可以帮助我们避免两个问题。

第一个问题，是所有功能都想接入 Skill，结果项目还没整理完，主流程已经变乱了。
第二个问题，是一直停留在观望阶段，什么准备工作都没有做，等真正需要接入时发现页面逻辑和业务能力完全绑在一起。

比较稳的方式，是先拆 P0 和 P1。P0 用来打基础，P1 用来验证业务价值。P2 保留观察，等确认机制、权限边界、日志记录更完整后再考虑。

对于会议随记类应用或会后行动台，这个顺序比较合适。

阶段	要完成的事情
第一阶段	整理页面功能清单
第二阶段	选出 Skill 候选能力
第三阶段	补齐输入、输出、确认、回退
第四阶段	沉淀服务层接口
第五阶段	选择 1 到 2 个能力做最小验证

这里的 最小验证 不一定要马上接入完整 Skill 发布链路。可以先验证服务层是否稳定、页面是否能复用、输入输出是否清楚、确认流程是否完整。等 HarmonyOS 7 Skill 接入路径进一步稳定之后，再进入实际接入。

到这里，页面功能到 Skill 能力的拆分逻辑就比较清楚了。

不是所有页面都要改成 Skill，也不是所有按钮都要变成系统入口。更合理的做法，是把那些意图清晰、输入输出明确、业务价值高、风险边界可控的功能先整理出来。这样做，即使短期内还没有完整接入 Skill，项目结构也会先变得更清楚。

总结

从页面功能到 Skill 能力，关键不是马上接入某个新接口，而是先把应用功能整理成可以被系统理解的能力单元。

这件事可以按照五步处理。

步骤	要做什么
1	从页面里筛选高价值业务动作
2	把页面结构整理成能力结构
3	给能力补齐输入、输出、确认和回退
4	把能力沉到服务层，减少页面耦合
5	按用户价值、接入难度和风险等级排序

如果你已经有 HarmonyOS 6 原生项目，可以先不急着改页面。更实际的做法，是先挑 3 个功能整理能力表。比如创建会议、生成纪要、提取待办。等这些能力的输入输出、确认流程和服务层接口都清楚以后，后续接入 Skill、Agent 或 AI 能力都会顺很多。