前言
做 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 的实测结果。
exportinterfaceMeetingSummaryInput{meetingId:string;transcript:string;language?:string;}exportinterfaceMeetingSummaryResult{summary:string;decisions:string[];actionItems:string[];risks?:string[];}exportasyncfunctiongenerateMeetingSummary(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里。
exportclassMeetingSummaryService{asyncgenerateSummary(input:MeetingSummaryInput):Promise<MeetingSummaryResult>{// 这里先保留业务接口边界// 后续可以接入 AI 能力、云端服务或本地模型returngenerateMeetingSummary(input);}}这段代码仍然属于项目结构草案。它的意义不是展示某个 HarmonyOS 7 新接口，而是说明能力应该从页面事件里抽出来。这样后续接入 Skill 时，页面不需要知道能力来自哪里，只需要处理状态展示和用户确认。
页面调用时，可以保持很清楚。
constresult=awaitthis.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 能力都会顺很多。
