前言做 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):PromiseMeetingSummaryResult{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):PromiseMeetingSummaryResult{// 这里先保留业务接口边界// 后续可以接入 AI 能力、云端服务或本地模型returngenerateMeetingSummary(input);}}这段代码仍然属于项目结构草案。它的意义不是展示某个 HarmonyOS 7 新接口而是说明能力应该从页面事件里抽出来。这样后续接入 Skill 时页面不需要知道能力来自哪里只需要处理状态展示和用户确认。页面调用时可以保持很清楚。constresultawaitthis.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 能力都会顺很多。
【HarmonyOS 7开发者前瞻】04 HarmonyOS 7 应用能力拆分方法：页面功能如何走向 Skill
前言做 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):PromiseMeetingSummaryResult{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):PromiseMeetingSummaryResult{// 这里先保留业务接口边界// 后续可以接入 AI 能力、云端服务或本地模型returngenerateMeetingSummary(input);}}这段代码仍然属于项目结构草案。它的意义不是展示某个 HarmonyOS 7 新接口而是说明能力应该从页面事件里抽出来。这样后续接入 Skill 时页面不需要知道能力来自哪里只需要处理状态展示和用户确认。页面调用时可以保持很清楚。constresultawaitthis.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 能力都会顺很多。
