AI差评分析 —— 基于 HarmonyOS 的 AI 应用开发全流程技术实践引言在当今数字化商业环境中用户评价是企业改进产品和服务的重要依据。然而面对海量的用户差评手动分析不仅效率低下而且难以挖掘深层次的根因和趋势。“AI差评分析” 应用应运而生它利用 HarmonyOS 的 ArkTS 技术栈构建了一个智能化的差评分析仪表盘帮助用户快速洞察问题分类、根因分析、情绪倾向和改进建议。本文以 “AI差评分析” 应用为案例严格遵循对齐Align→ 架构Architect→ 原子化Atomize→ 审批Approve→ 自动化执行Automate→ 评估Assess六阶段开发流程详细阐述从需求分析到最终交付的完整技术实践。全文将深入剖析 ArkTS 语言在鸿蒙生态中的语法约束与最佳实践展示 ArkUI 声明式 UI 框架的数据驱动机制并分享在三层架构模式下的代码组织策略。1. 对齐阶段Align对齐阶段的目标是将模糊的产品需求转化为精确的技术规范。这是整个开发流程的基石决定了后续所有工作的方向和质量。1.1 项目上下文分析1.1.1 技术栈全景“AI差评分析” 应用是 HarmonyOS 生态中的一个 AI 子应用运行在以下技术栈之上操作系统HarmonyOS 6.0.1API 21Stage 模型开发语言ArkTS基于 TypeScript 的鸿蒙原生语言UI 框架ArkUI 声明式 UI 框架构建工具Hvigor鸿蒙原生构建工具目标设备Phone手机SDK 兼容targetSdkVersion 6.0.1(21)compatibleSdkVersion 6.0.1(21)IDEDevEco Studio该项目是一个大型 AI 应用集合的一部分整个应用市场包含多个 AI 应用覆盖健康生活、工作效率、创意娱乐、学习成长、职业发展五大类别。“AI差评分析” 归属于工作效率类别图标为 副标题为差评分析。1.1.2 项目结构分析该应用的代码组织结构如下entry/src/main/ets/ ├── apps/ │ └── AI差评分析/ │ ├── AI差评分析Page.ets # 页面层View │ ├── AI差评分析Model.ets # 数据模型层Model │ └── AI差评分析Service.ets # 业务逻辑层Service ├── pages/ │ └── Index.ets # 主入口页面应用列表 ├── entryability/ │ └── EntryAbility.ets # Ability 入口 └── entrybackupability/ └── EntryBackupAbility.ets # 备份扩展路由配置通过main_pages.json统一管理{src:[pages/Index,apps/AI差评分析/AI差评分析Page,// ... 其他应用的路由注册]}应用注册信息通过apps.json配置包含图标、标题、颜色、分类等元数据{icon:,title:AI差评分析,subtitle:差评分析,color:#3B82F6,bg:#EFF6FF,border:#BFDBFE,page:apps/AI差评分析/AI差评分析Page,cat:工作效率}1.1.3 架构模式分析通过分析代码结构可以发现该应用采用了分层架构Layered Architecture模式类似于前端领域的 MVC/MVP 模式Page 层View负责 UI 渲染和用户交互使用 ArkUI 的Component装饰器定义组件通过State装饰器管理响应式状态Model 层定义数据实体AI差评分析Data封装所有业务数据字段包括分类、根因、情绪、改进建议等Service 层封装核心业务逻辑将用户输入数据转换为结构化的分析结果目前使用 Mock 数据模拟 AI 生成这种分层模式在 HarmonyOS 应用开发中非常典型体现了良好的关注点分离原则。1.1.4 依赖关系分析在oh-package.json5中可以确认应用层没有额外的第三方依赖仅依赖鸿蒙 SDK 内置的kit.ArkUI和kit.ArkTS框架{name:entry,version:1.0.0,description:Please describe the basic information.,main:,author:,license:,dependencies:{}}这表明 HarmonyOS 的 SDK 已经提供了足够丰富的原生 API 支持无需引入外部库即可完成复杂的 UI 交互和数据展示。1.2 需求理解确认经过对项目代码和配置文件的全面分析我们对 “AI差评分析” 的需求进行如下确认需求项描述验收标准用户输入支持用户输入差评内容和产品类型输入框可正常录入文本AI 分析基于输入数据生成结构化的差评分析报告点击分析数据按钮后显示分析结果问题分类展示差评的问题分类及其统计信息结果区域展示 categories、count、ratio、severity根因分析展示问题的根因、证据和影响范围结果区域展示 root_causes、cause、evidence、impact情绪分析展示整体情绪倾向结果区域展示 sentiment 字段改进建议展示改进措施、优先级、负责人和时间线结果区域展示 improvement、action、priority、owner、timeline正面洞察展示差评中可挖掘的正面信号结果区域展示 positive_insights 字段页面导航支持返回上级页面点击← 返回可返回应用列表1.3 疑问澄清与决策在开发过程中团队针对以下关键问题进行了决策问题 1ArkTS 语言约束如何影响编码风格ArkTS 是 TypeScript 的子集但做了大量严格的语法限制。经过分析我们确认了以下关键约束并制定了对应的编码规范不支持any和unknown类型 → 所有变量必须显式指定类型如使用Recordstring, Object替代any不支持解构赋值 → 使用临时变量逐字段操作如let reviewsVal: string String(input[reviews] || )不支持Function.bind/Function.apply→ 遵循传统 OOP 风格处理this不支持索引签名 → 使用string[]数组替代{ [key: string]: string }不支持for...in遍历对象 → 使用常规for循环或ForEach迭代数组不支持对象字面量直接作为类型 → 显式声明class AI差评分析Data不支持in运算符 → 使用instanceof替代不支持as const断言 → 使用显式类型标注不支持JSX表达式 → 使用 ArkUI 的链式 API 构建 UI问题 2数据模型如何设计考虑到差评分析的复杂性数据模型需要包含以下维度的信息问题分类维度categories分类列表、category当前分类、count数量、ratio占比、severity严重程度根因分析维度root_causes根因列表、cause根因描述、evidence证据、impact影响范围情绪分析维度sentiment整体情绪分析改进建议维度improvement改进措施列表、action具体行动、priority优先级、owner负责人、timeline时间线正面洞察维度positive_insights差评中可挖掘的正面信号问题 3Service 层如何与 AI 能力对接当前阶段Service 层使用 Mock 数据模拟 AI 生成结果。未来计划接入真实的大模型 API如 OpenAI GPT 或华为盘古大模型将用户输入构建为 Prompt 发送给 AI 服务然后将返回的 JSON 数据解析为AI差评分析Data实例。1.4 边界确认经过对齐分析我们明确了以下任务边界在范围内构建完整的 Page、Model、Service 三层架构实现差评内容的文本输入和产品类型输入实现 Mock 数据的生成与展示实现分析报告的结构化展示实现页面路由注册和应用列表集成不在范围内真实的 AI 大模型 API 对接后续迭代数据持久化存储后续迭代用户登录和权限管理多语言国际化支持差评数据的批量导入导出2. 架构阶段Architect架构阶段的目标是从共识文档出发设计系统架构、模块划分和接口规范。2.1 整体架构设计“AI差评分析” 应用采用经典的三层架构遵循 MVVMModel-View-ViewModel模式在 HarmonyOS 中的最佳实践┌─────────────────────────────────────────────────────────┐ │ View 层 (Page) │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Page.ets ││ │ │ - State inputData: Recordstring, Object ││ │ │ - State resultData: AI差评分析Data | null ││ │ │ - State showResult: boolean ││ │ │ - ArkUI 声明式 UI 组件 ││ │ └──────────────┬──────────────────────────────────────┘│ └─────────────────┼────────────────────────────────────────┘ │ 调用 generateData(input) ▼ ┌─────────────────────────────────────────────────────────┐ │ Service 层 │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Service.ets ││ │ │ - generateData(input): AI差评分析Data ││ │ │ - Mock 数据生成逻辑 ││ │ │ - 未来: AI API 调用封装 ││ │ └──────────────┬──────────────────────────────────────┘│ └─────────────────┼────────────────────────────────────────┘ │ 返回 AI差评分析Data 实例 ▼ ┌─────────────────────────────────────────────────────────┐ │ Model 层 │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Data (class) ││ │ │ - categories: string[] ││ │ │ - root_causes: string[] ││ │ │ - sentiment: string ││ │ │ - improvement: string[] ││ │ │ - positive_insights: string ││ │ │ ... 其他业务字段 ││ │ └─────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────┘2.2 核心数据流数据流采用单向数据流模式确保数据变更的可预测性用户输入 ──→ TextInput.onChange() ──→ this.inputData 更新 │ ▼ 用户点击分析数据按钮 ──→ this.service.generateData(input) │ ▼ Service 层解析/生成数据 │ ▼ 返回 AI差评分析Data 实例 │ ▼ this.resultData data this.showResult true │ ▼ ArkUI 自动重新渲染 UI这种数据流模式的关键优势在于可预测性数据始终单向流动便于追踪和调试响应式State装饰器确保 UI 自动响应数据变化解耦性View 层不直接操作数据而是通过 Service 层间接处理2.3 模块依赖关系AI差评分析Page.ets ├── import { AI差评分析Data } from ./AI差评分析Model ├── import { AI差评分析Service } from ./AI差评分析Service └── import { router } from kit.ArkUI AI差评分析Service.ets └── import { AI差评分析Data } from ./AI差评分析Model AI差评分析Model.ets └── 无外部依赖纯数据实体依赖方向为Page → Service → Model符合分层架构的依赖倒置原则。2.4 接口契约定义Service 层接口// 输入: 用户输入的差评数据// 输出: 结构化的差评分析结果generateData(input:Recordstring,Object):AI差评分析DataModel 层数据实体classAI差评分析Data{categories:string[]// 问题分类列表category:string// 当前分类count:string// 数量ratio:string// 占比severity:string// 严重程度root_causes:string[]// 根因列表cause:string// 根因描述evidence:string// 证据impact:string// 影响范围sentiment:string// 情绪分析improvement:string[]// 改进措施列表action:string// 具体行动priority:string// 优先级owner:string// 负责人timeline:string// 时间线positive_insights:string// 正面洞察}2.5 异常处理策略在 HarmonyOS 应用中异常处理遵循以下策略Service 层异常在generateData方法内部捕获异常返回默认的 Mock 数据确保 UI 层不会因数据异常而崩溃UI 层防御使用if (this.resultData ! null)进行空值检查避免访问 null 对象的属性路由异常router.back()调用由 ArkUI 框架内部处理异常资源加载异常Index.ets中的loadApps()方法使用try-catch捕获 JSON 解析异常并回退到默认空列表3. 原子化阶段Atomize原子化阶段将任务分解为更小的、可管理的子任务以便高效执行和跟踪。3.1 任务分解“AI差评分析” 应用的开发任务被分解为以下原子任务任务 1创建 Model 数据模型描述定义AI差评分析Data类封装所有业务数据字段。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Model.ets验收标准类包含 17 个字段所有字段有默认值构造函数中初始化所有字段。代码实现exportclassAI差评分析Data{categories:string[][]category:stringcount:stringratio:stringseverity:stringroot_causes:string[][]cause:stringevidence:stringimpact:stringsentiment:stringimprovement:string[][]action:stringpriority:stringowner:stringtimeline:stringpositive_insights:stringconstructor(){this.categories[]this.categorythis.countthis.ratiothis.severitythis.root_causes[]this.causethis.evidencethis.impactthis.sentimentthis.improvement[]this.actionthis.prioritythis.ownerthis.timelinethis.positive_insights}}技术要点分析在 ArkTS 中类的字段声明有严格的语法要求字段声明位置ArkTS 要求所有字段在类声明内部直接声明不支持在构造函数中动态声明字段。这与标准 TypeScript 不同在 TypeScript 中可以在构造函数中通过this.field value动态创建字段。显式初始化ArkTS 不支持确定性赋值断言let v!: T因此所有字段必须在声明时提供初始值。这就是为什么我们在类声明中为每个字段都赋了初始值空字符串或空数组。构造函数冗余由于 ArkTS 要求字段必须在声明时初始化构造函数中的赋值操作实际上是冗余的。但从代码清晰度和维护性角度考虑保留构造函数中的显式初始化可以作为文档化的方式展示所有字段的默认状态。不支持索引访问类型ArkTS 不允许使用type T MyClass[field]这样的索引访问类型语法因此在需要引用字段类型时必须直接使用类型名称。任务 2实现 Service 业务逻辑层描述实现AI差评分析Service类封装数据生成逻辑。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Service.ets验收标准Service 类包含generateData方法接收用户输入返回AI差评分析Data实例。代码实现import{AI差评分析Data}from./AI差评分析ModelexportclassAI差评分析Service{privatemodel:AI差评分析Dataconstructor(){this.modelnewAI差评分析Data()}// 生成AI差评分析数据generateData(input:Recordstring,Object):AI差评分析Data{letresult:AI差评分析DatanewAI差评分析Data()// Mock data generation based on inputletreviewsVal:stringString(input[reviews]||)result.categories[示例数据1,示例数据2,示例数据3]result.root_causes[示例数据1,示例数据2,示例数据3]result.sentiment生成结果reviewsVal result.improvement[示例数据1,示例数据2,示例数据3]result.positive_insights生成结果reviewsValreturnresult}}技术要点分析Recordstring, Object 类型ArkTS 不支持any和unknown类型因此我们需要使用Recordstring, Object来接收动态输入。RecordK, V是 ArkTS 支持的少数几个实用类型之一与Partial、Required、Readonly并列。类型转换由于 ArkTS 不支持索引签名我们不能直接使用input.reviews来访问字段而必须使用input[reviews]这种索引访问方式。但需要注意的是返回值的类型是Object需要显式转换为string。Mock 数据策略在当前阶段Service 层使用 Mock 数据模拟 AI 生成结果。这种策略在开发初期非常有效可以让 UI 层和 Service 层并行开发在 AI API 接入前验证完整的 UI 交互流程方便单元测试和 UI 自动化测试未来扩展设计Service 类的设计为未来接入真实 AI API 预留了扩展点。只需修改generateData方法的内部实现将 Mock 数据替换为 API 调用而不需要修改 Page 层和 Model 层的任何代码。任务 3构建 Page 页面 UI描述使用 ArkUI 声明式 UI 构建完整的差评分析页面。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Page.ets验收标准页面包含 Header、数据指标、输入区域、分析按钮、结果展示区域。页面结构设计┌─────────────────────────────────┐ │ ← 返回 AI差评分析 LIVE │ ← Header │ DASHBOARD · 实时监控 │ ├─────────────────────────────────┤ │ [数据源: 3] [分析中: --] [就绪: ✓] │ ← 数据指标 ├─────────────────────────────────┤ │ 差评内容 │ ← 输入区域 │ ┌───────────────────────────┐ │ │ │ 请输入差评内容 │ │ │ └───────────────────────────┘ │ │ 产品类型 │ │ ┌───────────────────────────┐ │ │ │ 请输入产品类型 │ │ │ └───────────────────────────┘ │ ├─────────────────────────────────┤ │ [ ▶ 分析数据] │ ← 分析按钮 ├─────────────────────────────────┤ │ 分析报告 │ ← 结果展示区域 │ Categories │ │ • 示例数据1 │ │ • 示例数据2 │ │ • 示例数据3 │ │ Category: ... │ │ Count: ... │ │ Ratio: ... │ │ Severity: ... │ │ Root causes │ │ ... │ │ Improvement │ │ ... │ └─────────────────────────────────┘技术要点分析State 装饰器ArkUI 使用State装饰器标记响应式状态变量。当状态变量发生变化时ArkUI 会自动重新渲染相关的 UI 组件。这是声明式 UI 框架的核心机制。条件渲染通过if (this.showResult this.resultData ! null)实现条件渲染控制分析报告的显示与隐藏。这种模式在 ArkUI 中非常常见用于实现加载状态、空状态和错误状态的切换。ForEach 循环渲染ArkUI 使用ForEach组件实现列表渲染需要提供两个回调函数itemGenerator生成子组件和keyGenerator生成唯一标识符。这与 React 的map函数类似但 ArkTS 不支持解构因此回调参数需要逐个声明。任务 4注册路由配置描述在main_pages.json中注册页面路由。文件entry/src/main/resources/base/profile/main_pages.json验收标准路由数组中包含apps/AI差评分析/AI差评分析Page。任务 5集成到应用列表描述在apps.json中添加应用配置信息。文件entry/src/main/resources/rawfile/apps/apps.json验收标准JSON 数组中包含 AI差评分析的配置对象包含 icon、title、subtitle、color、page、cat 等字段。3.2 任务依赖关系任务 1 (Model) ──→ 任务 2 (Service) ──→ 任务 3 (Page) │ 任务 4 (路由) ─────────────┤ │ 任务 5 (应用列表) ──────────┘任务 1 和任务 2 是任务 3 的前提条件而任务 4 和任务 5 可以与任务 3 并行执行。4. 审批阶段Approve审批阶段对前面阶段的成果进行审核和批准确保符合要求。4.1 代码审查清单4.1.1 Model 层审查审查项数据模型完整性所有业务字段已定义categories、category、count、ratio、severity、root_causes、cause、evidence、impact、sentiment、improvement、action、priority、owner、timeline、positive_insights字段类型正确字符串数组使用string[]单值使用string所有字段具有默认值避免空指针异常构造函数中初始化所有字段类使用export导出可供其他模块引用4.1.2 Service 层审查审查项业务逻辑正确性Service 类正确导入 Model 类generateData方法签名符合规范(input: Recordstring, Object) AI差评分析Data参数类型使用Recordstring, Object而非any符合 ArkTS 约束返回类型显式指定符合 ArkTS 对函数返回类型推断的限制构造函数中创建 Model 实例使用箭头函数而非普通函数ArkTS 不支持独立函数中的this4.1.3 Page 层审查审查项UI 交互完整性页面使用Entry和Component装饰器标记使用State装饰器管理响应式状态Header 包含返回按钮、标题和 LIVE 状态标识数据指标行展示三个指标项输入区域包含差评内容和产品类型两个输入框分析按钮绑定点击事件调用 Service 层生成数据结果展示区域使用条件渲染在数据就绪后显示使用ForEach循环渲染列表数据使用router.back()实现页面返回页面背景色为深色模式#0F172A符合现代仪表盘设计风格4.1.4 ArkTS 语法合规审查审查项是否违反 ArkTS 语法约束未使用any或unknown类型未使用解构赋值未使用Function.bind/Function.apply/Function.call未使用for...in循环未使用in运算符未使用as const断言未使用索引签名未使用对象字面量作为类型声明所有 import 语句在文件开头未使用var关键字使用let未使用解构变量声明类字段在类声明内部声明而非构造函数中函数返回类型显式指定4.2 ArkTS 语法约束深度解析在审批过程中我们特别关注 ArkTS 与标准 TypeScript 的语法差异。以下是一些关键约束的详细解析4.2.1 不支持解构赋值标准 TypeScript 中解构赋值是一种常见的语法糖// TypeScript 写法在 ArkTS 中不支持const{name,age}person在 ArkTS 中必须使用临时变量逐字段赋值// ArkTS 兼容写法letname:stringperson.nameletage:numberperson.age在我们的代码中ForEach的回调参数也体现了这一约束// ArkTS 兼容写法 - 不使用解构ForEach(this.resultData.categories,(item:string,index:number){// ...},(item:string,index:number)index.toString())4.2.2 不支持索引签名标准 TypeScript 中可以定义索引签名// TypeScript 写法在 ArkTS 中不支持interfaceStringMap{[key:string]:string}在 ArkTS 中必须使用RecordK, V或数组替代// ArkTS 兼容写法letinputData:Recordstring,Object{}4.2.3 不支持对象字面量作为类型标准 TypeScript 中可以直接使用对象字面量// TypeScript 写法在 ArkTS 中不支持letpoint:{x:number,y:number}{x:10,y:20}在 ArkTS 中必须显式声明类或接口// ArkTS 兼容写法classPoint{x:number0y:number0}letpoint:PointnewPoint()point.x10point.y20在我们的项目中AI差评分析Data类的设计正是遵循了这一原则。4.2.4 函数返回类型显式指定ArkTS 对函数返回类型推断有限制。当return语句中的表达式是对返回类型被省略的函数或方法的调用时会发生编译时错误。因此所有函数必须显式指定返回类型// 必须显式指定返回类型generateData(input:Recordstring,Object):AI差评分析Data{// ...returnresult}4.3 质量门控经过审批以下质量门控条件全部满足需求边界清晰无歧义已完成需求确认输入输出字段明确技术方案与现有架构对齐采用与项目其他应用一致的三层架构验收标准具体可测试每个原子任务都有明确的验收标准所有关键假设已确认Mock 数据策略、ArkTS 语法约束等已确认项目特性规范已对齐遵循项目的编码规范、目录结构和命名约定5. 自动化执行阶段Automate自动化执行阶段利用自动化工具和流程执行任务提高开发效率和质量。5.1 代码生成脚本在 “AI差评分析” 应用的开发过程中我们使用了自动化脚本辅
AI差评分析 —— 基于 HarmonyOS 的 AI 应用开发全流程技术实践
AI差评分析 —— 基于 HarmonyOS 的 AI 应用开发全流程技术实践引言在当今数字化商业环境中用户评价是企业改进产品和服务的重要依据。然而面对海量的用户差评手动分析不仅效率低下而且难以挖掘深层次的根因和趋势。“AI差评分析” 应用应运而生它利用 HarmonyOS 的 ArkTS 技术栈构建了一个智能化的差评分析仪表盘帮助用户快速洞察问题分类、根因分析、情绪倾向和改进建议。本文以 “AI差评分析” 应用为案例严格遵循对齐Align→ 架构Architect→ 原子化Atomize→ 审批Approve→ 自动化执行Automate→ 评估Assess六阶段开发流程详细阐述从需求分析到最终交付的完整技术实践。全文将深入剖析 ArkTS 语言在鸿蒙生态中的语法约束与最佳实践展示 ArkUI 声明式 UI 框架的数据驱动机制并分享在三层架构模式下的代码组织策略。1. 对齐阶段Align对齐阶段的目标是将模糊的产品需求转化为精确的技术规范。这是整个开发流程的基石决定了后续所有工作的方向和质量。1.1 项目上下文分析1.1.1 技术栈全景“AI差评分析” 应用是 HarmonyOS 生态中的一个 AI 子应用运行在以下技术栈之上操作系统HarmonyOS 6.0.1API 21Stage 模型开发语言ArkTS基于 TypeScript 的鸿蒙原生语言UI 框架ArkUI 声明式 UI 框架构建工具Hvigor鸿蒙原生构建工具目标设备Phone手机SDK 兼容targetSdkVersion 6.0.1(21)compatibleSdkVersion 6.0.1(21)IDEDevEco Studio该项目是一个大型 AI 应用集合的一部分整个应用市场包含多个 AI 应用覆盖健康生活、工作效率、创意娱乐、学习成长、职业发展五大类别。“AI差评分析” 归属于工作效率类别图标为 副标题为差评分析。1.1.2 项目结构分析该应用的代码组织结构如下entry/src/main/ets/ ├── apps/ │ └── AI差评分析/ │ ├── AI差评分析Page.ets # 页面层View │ ├── AI差评分析Model.ets # 数据模型层Model │ └── AI差评分析Service.ets # 业务逻辑层Service ├── pages/ │ └── Index.ets # 主入口页面应用列表 ├── entryability/ │ └── EntryAbility.ets # Ability 入口 └── entrybackupability/ └── EntryBackupAbility.ets # 备份扩展路由配置通过main_pages.json统一管理{src:[pages/Index,apps/AI差评分析/AI差评分析Page,// ... 其他应用的路由注册]}应用注册信息通过apps.json配置包含图标、标题、颜色、分类等元数据{icon:,title:AI差评分析,subtitle:差评分析,color:#3B82F6,bg:#EFF6FF,border:#BFDBFE,page:apps/AI差评分析/AI差评分析Page,cat:工作效率}1.1.3 架构模式分析通过分析代码结构可以发现该应用采用了分层架构Layered Architecture模式类似于前端领域的 MVC/MVP 模式Page 层View负责 UI 渲染和用户交互使用 ArkUI 的Component装饰器定义组件通过State装饰器管理响应式状态Model 层定义数据实体AI差评分析Data封装所有业务数据字段包括分类、根因、情绪、改进建议等Service 层封装核心业务逻辑将用户输入数据转换为结构化的分析结果目前使用 Mock 数据模拟 AI 生成这种分层模式在 HarmonyOS 应用开发中非常典型体现了良好的关注点分离原则。1.1.4 依赖关系分析在oh-package.json5中可以确认应用层没有额外的第三方依赖仅依赖鸿蒙 SDK 内置的kit.ArkUI和kit.ArkTS框架{name:entry,version:1.0.0,description:Please describe the basic information.,main:,author:,license:,dependencies:{}}这表明 HarmonyOS 的 SDK 已经提供了足够丰富的原生 API 支持无需引入外部库即可完成复杂的 UI 交互和数据展示。1.2 需求理解确认经过对项目代码和配置文件的全面分析我们对 “AI差评分析” 的需求进行如下确认需求项描述验收标准用户输入支持用户输入差评内容和产品类型输入框可正常录入文本AI 分析基于输入数据生成结构化的差评分析报告点击分析数据按钮后显示分析结果问题分类展示差评的问题分类及其统计信息结果区域展示 categories、count、ratio、severity根因分析展示问题的根因、证据和影响范围结果区域展示 root_causes、cause、evidence、impact情绪分析展示整体情绪倾向结果区域展示 sentiment 字段改进建议展示改进措施、优先级、负责人和时间线结果区域展示 improvement、action、priority、owner、timeline正面洞察展示差评中可挖掘的正面信号结果区域展示 positive_insights 字段页面导航支持返回上级页面点击← 返回可返回应用列表1.3 疑问澄清与决策在开发过程中团队针对以下关键问题进行了决策问题 1ArkTS 语言约束如何影响编码风格ArkTS 是 TypeScript 的子集但做了大量严格的语法限制。经过分析我们确认了以下关键约束并制定了对应的编码规范不支持any和unknown类型 → 所有变量必须显式指定类型如使用Recordstring, Object替代any不支持解构赋值 → 使用临时变量逐字段操作如let reviewsVal: string String(input[reviews] || )不支持Function.bind/Function.apply→ 遵循传统 OOP 风格处理this不支持索引签名 → 使用string[]数组替代{ [key: string]: string }不支持for...in遍历对象 → 使用常规for循环或ForEach迭代数组不支持对象字面量直接作为类型 → 显式声明class AI差评分析Data不支持in运算符 → 使用instanceof替代不支持as const断言 → 使用显式类型标注不支持JSX表达式 → 使用 ArkUI 的链式 API 构建 UI问题 2数据模型如何设计考虑到差评分析的复杂性数据模型需要包含以下维度的信息问题分类维度categories分类列表、category当前分类、count数量、ratio占比、severity严重程度根因分析维度root_causes根因列表、cause根因描述、evidence证据、impact影响范围情绪分析维度sentiment整体情绪分析改进建议维度improvement改进措施列表、action具体行动、priority优先级、owner负责人、timeline时间线正面洞察维度positive_insights差评中可挖掘的正面信号问题 3Service 层如何与 AI 能力对接当前阶段Service 层使用 Mock 数据模拟 AI 生成结果。未来计划接入真实的大模型 API如 OpenAI GPT 或华为盘古大模型将用户输入构建为 Prompt 发送给 AI 服务然后将返回的 JSON 数据解析为AI差评分析Data实例。1.4 边界确认经过对齐分析我们明确了以下任务边界在范围内构建完整的 Page、Model、Service 三层架构实现差评内容的文本输入和产品类型输入实现 Mock 数据的生成与展示实现分析报告的结构化展示实现页面路由注册和应用列表集成不在范围内真实的 AI 大模型 API 对接后续迭代数据持久化存储后续迭代用户登录和权限管理多语言国际化支持差评数据的批量导入导出2. 架构阶段Architect架构阶段的目标是从共识文档出发设计系统架构、模块划分和接口规范。2.1 整体架构设计“AI差评分析” 应用采用经典的三层架构遵循 MVVMModel-View-ViewModel模式在 HarmonyOS 中的最佳实践┌─────────────────────────────────────────────────────────┐ │ View 层 (Page) │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Page.ets ││ │ │ - State inputData: Recordstring, Object ││ │ │ - State resultData: AI差评分析Data | null ││ │ │ - State showResult: boolean ││ │ │ - ArkUI 声明式 UI 组件 ││ │ └──────────────┬──────────────────────────────────────┘│ └─────────────────┼────────────────────────────────────────┘ │ 调用 generateData(input) ▼ ┌─────────────────────────────────────────────────────────┐ │ Service 层 │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Service.ets ││ │ │ - generateData(input): AI差评分析Data ││ │ │ - Mock 数据生成逻辑 ││ │ │ - 未来: AI API 调用封装 ││ │ └──────────────┬──────────────────────────────────────┘│ └─────────────────┼────────────────────────────────────────┘ │ 返回 AI差评分析Data 实例 ▼ ┌─────────────────────────────────────────────────────────┐ │ Model 层 │ │ ┌─────────────────────────────────────────────────────┐│ │ │ AI差评分析Data (class) ││ │ │ - categories: string[] ││ │ │ - root_causes: string[] ││ │ │ - sentiment: string ││ │ │ - improvement: string[] ││ │ │ - positive_insights: string ││ │ │ ... 其他业务字段 ││ │ └─────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────┘2.2 核心数据流数据流采用单向数据流模式确保数据变更的可预测性用户输入 ──→ TextInput.onChange() ──→ this.inputData 更新 │ ▼ 用户点击分析数据按钮 ──→ this.service.generateData(input) │ ▼ Service 层解析/生成数据 │ ▼ 返回 AI差评分析Data 实例 │ ▼ this.resultData data this.showResult true │ ▼ ArkUI 自动重新渲染 UI这种数据流模式的关键优势在于可预测性数据始终单向流动便于追踪和调试响应式State装饰器确保 UI 自动响应数据变化解耦性View 层不直接操作数据而是通过 Service 层间接处理2.3 模块依赖关系AI差评分析Page.ets ├── import { AI差评分析Data } from ./AI差评分析Model ├── import { AI差评分析Service } from ./AI差评分析Service └── import { router } from kit.ArkUI AI差评分析Service.ets └── import { AI差评分析Data } from ./AI差评分析Model AI差评分析Model.ets └── 无外部依赖纯数据实体依赖方向为Page → Service → Model符合分层架构的依赖倒置原则。2.4 接口契约定义Service 层接口// 输入: 用户输入的差评数据// 输出: 结构化的差评分析结果generateData(input:Recordstring,Object):AI差评分析DataModel 层数据实体classAI差评分析Data{categories:string[]// 问题分类列表category:string// 当前分类count:string// 数量ratio:string// 占比severity:string// 严重程度root_causes:string[]// 根因列表cause:string// 根因描述evidence:string// 证据impact:string// 影响范围sentiment:string// 情绪分析improvement:string[]// 改进措施列表action:string// 具体行动priority:string// 优先级owner:string// 负责人timeline:string// 时间线positive_insights:string// 正面洞察}2.5 异常处理策略在 HarmonyOS 应用中异常处理遵循以下策略Service 层异常在generateData方法内部捕获异常返回默认的 Mock 数据确保 UI 层不会因数据异常而崩溃UI 层防御使用if (this.resultData ! null)进行空值检查避免访问 null 对象的属性路由异常router.back()调用由 ArkUI 框架内部处理异常资源加载异常Index.ets中的loadApps()方法使用try-catch捕获 JSON 解析异常并回退到默认空列表3. 原子化阶段Atomize原子化阶段将任务分解为更小的、可管理的子任务以便高效执行和跟踪。3.1 任务分解“AI差评分析” 应用的开发任务被分解为以下原子任务任务 1创建 Model 数据模型描述定义AI差评分析Data类封装所有业务数据字段。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Model.ets验收标准类包含 17 个字段所有字段有默认值构造函数中初始化所有字段。代码实现exportclassAI差评分析Data{categories:string[][]category:stringcount:stringratio:stringseverity:stringroot_causes:string[][]cause:stringevidence:stringimpact:stringsentiment:stringimprovement:string[][]action:stringpriority:stringowner:stringtimeline:stringpositive_insights:stringconstructor(){this.categories[]this.categorythis.countthis.ratiothis.severitythis.root_causes[]this.causethis.evidencethis.impactthis.sentimentthis.improvement[]this.actionthis.prioritythis.ownerthis.timelinethis.positive_insights}}技术要点分析在 ArkTS 中类的字段声明有严格的语法要求字段声明位置ArkTS 要求所有字段在类声明内部直接声明不支持在构造函数中动态声明字段。这与标准 TypeScript 不同在 TypeScript 中可以在构造函数中通过this.field value动态创建字段。显式初始化ArkTS 不支持确定性赋值断言let v!: T因此所有字段必须在声明时提供初始值。这就是为什么我们在类声明中为每个字段都赋了初始值空字符串或空数组。构造函数冗余由于 ArkTS 要求字段必须在声明时初始化构造函数中的赋值操作实际上是冗余的。但从代码清晰度和维护性角度考虑保留构造函数中的显式初始化可以作为文档化的方式展示所有字段的默认状态。不支持索引访问类型ArkTS 不允许使用type T MyClass[field]这样的索引访问类型语法因此在需要引用字段类型时必须直接使用类型名称。任务 2实现 Service 业务逻辑层描述实现AI差评分析Service类封装数据生成逻辑。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Service.ets验收标准Service 类包含generateData方法接收用户输入返回AI差评分析Data实例。代码实现import{AI差评分析Data}from./AI差评分析ModelexportclassAI差评分析Service{privatemodel:AI差评分析Dataconstructor(){this.modelnewAI差评分析Data()}// 生成AI差评分析数据generateData(input:Recordstring,Object):AI差评分析Data{letresult:AI差评分析DatanewAI差评分析Data()// Mock data generation based on inputletreviewsVal:stringString(input[reviews]||)result.categories[示例数据1,示例数据2,示例数据3]result.root_causes[示例数据1,示例数据2,示例数据3]result.sentiment生成结果reviewsVal result.improvement[示例数据1,示例数据2,示例数据3]result.positive_insights生成结果reviewsValreturnresult}}技术要点分析Recordstring, Object 类型ArkTS 不支持any和unknown类型因此我们需要使用Recordstring, Object来接收动态输入。RecordK, V是 ArkTS 支持的少数几个实用类型之一与Partial、Required、Readonly并列。类型转换由于 ArkTS 不支持索引签名我们不能直接使用input.reviews来访问字段而必须使用input[reviews]这种索引访问方式。但需要注意的是返回值的类型是Object需要显式转换为string。Mock 数据策略在当前阶段Service 层使用 Mock 数据模拟 AI 生成结果。这种策略在开发初期非常有效可以让 UI 层和 Service 层并行开发在 AI API 接入前验证完整的 UI 交互流程方便单元测试和 UI 自动化测试未来扩展设计Service 类的设计为未来接入真实 AI API 预留了扩展点。只需修改generateData方法的内部实现将 Mock 数据替换为 API 调用而不需要修改 Page 层和 Model 层的任何代码。任务 3构建 Page 页面 UI描述使用 ArkUI 声明式 UI 构建完整的差评分析页面。文件entry/src/main/ets/apps/AI差评分析/AI差评分析Page.ets验收标准页面包含 Header、数据指标、输入区域、分析按钮、结果展示区域。页面结构设计┌─────────────────────────────────┐ │ ← 返回 AI差评分析 LIVE │ ← Header │ DASHBOARD · 实时监控 │ ├─────────────────────────────────┤ │ [数据源: 3] [分析中: --] [就绪: ✓] │ ← 数据指标 ├─────────────────────────────────┤ │ 差评内容 │ ← 输入区域 │ ┌───────────────────────────┐ │ │ │ 请输入差评内容 │ │ │ └───────────────────────────┘ │ │ 产品类型 │ │ ┌───────────────────────────┐ │ │ │ 请输入产品类型 │ │ │ └───────────────────────────┘ │ ├─────────────────────────────────┤ │ [ ▶ 分析数据] │ ← 分析按钮 ├─────────────────────────────────┤ │ 分析报告 │ ← 结果展示区域 │ Categories │ │ • 示例数据1 │ │ • 示例数据2 │ │ • 示例数据3 │ │ Category: ... │ │ Count: ... │ │ Ratio: ... │ │ Severity: ... │ │ Root causes │ │ ... │ │ Improvement │ │ ... │ └─────────────────────────────────┘技术要点分析State 装饰器ArkUI 使用State装饰器标记响应式状态变量。当状态变量发生变化时ArkUI 会自动重新渲染相关的 UI 组件。这是声明式 UI 框架的核心机制。条件渲染通过if (this.showResult this.resultData ! null)实现条件渲染控制分析报告的显示与隐藏。这种模式在 ArkUI 中非常常见用于实现加载状态、空状态和错误状态的切换。ForEach 循环渲染ArkUI 使用ForEach组件实现列表渲染需要提供两个回调函数itemGenerator生成子组件和keyGenerator生成唯一标识符。这与 React 的map函数类似但 ArkTS 不支持解构因此回调参数需要逐个声明。任务 4注册路由配置描述在main_pages.json中注册页面路由。文件entry/src/main/resources/base/profile/main_pages.json验收标准路由数组中包含apps/AI差评分析/AI差评分析Page。任务 5集成到应用列表描述在apps.json中添加应用配置信息。文件entry/src/main/resources/rawfile/apps/apps.json验收标准JSON 数组中包含 AI差评分析的配置对象包含 icon、title、subtitle、color、page、cat 等字段。3.2 任务依赖关系任务 1 (Model) ──→ 任务 2 (Service) ──→ 任务 3 (Page) │ 任务 4 (路由) ─────────────┤ │ 任务 5 (应用列表) ──────────┘任务 1 和任务 2 是任务 3 的前提条件而任务 4 和任务 5 可以与任务 3 并行执行。4. 审批阶段Approve审批阶段对前面阶段的成果进行审核和批准确保符合要求。4.1 代码审查清单4.1.1 Model 层审查审查项数据模型完整性所有业务字段已定义categories、category、count、ratio、severity、root_causes、cause、evidence、impact、sentiment、improvement、action、priority、owner、timeline、positive_insights字段类型正确字符串数组使用string[]单值使用string所有字段具有默认值避免空指针异常构造函数中初始化所有字段类使用export导出可供其他模块引用4.1.2 Service 层审查审查项业务逻辑正确性Service 类正确导入 Model 类generateData方法签名符合规范(input: Recordstring, Object) AI差评分析Data参数类型使用Recordstring, Object而非any符合 ArkTS 约束返回类型显式指定符合 ArkTS 对函数返回类型推断的限制构造函数中创建 Model 实例使用箭头函数而非普通函数ArkTS 不支持独立函数中的this4.1.3 Page 层审查审查项UI 交互完整性页面使用Entry和Component装饰器标记使用State装饰器管理响应式状态Header 包含返回按钮、标题和 LIVE 状态标识数据指标行展示三个指标项输入区域包含差评内容和产品类型两个输入框分析按钮绑定点击事件调用 Service 层生成数据结果展示区域使用条件渲染在数据就绪后显示使用ForEach循环渲染列表数据使用router.back()实现页面返回页面背景色为深色模式#0F172A符合现代仪表盘设计风格4.1.4 ArkTS 语法合规审查审查项是否违反 ArkTS 语法约束未使用any或unknown类型未使用解构赋值未使用Function.bind/Function.apply/Function.call未使用for...in循环未使用in运算符未使用as const断言未使用索引签名未使用对象字面量作为类型声明所有 import 语句在文件开头未使用var关键字使用let未使用解构变量声明类字段在类声明内部声明而非构造函数中函数返回类型显式指定4.2 ArkTS 语法约束深度解析在审批过程中我们特别关注 ArkTS 与标准 TypeScript 的语法差异。以下是一些关键约束的详细解析4.2.1 不支持解构赋值标准 TypeScript 中解构赋值是一种常见的语法糖// TypeScript 写法在 ArkTS 中不支持const{name,age}person在 ArkTS 中必须使用临时变量逐字段赋值// ArkTS 兼容写法letname:stringperson.nameletage:numberperson.age在我们的代码中ForEach的回调参数也体现了这一约束// ArkTS 兼容写法 - 不使用解构ForEach(this.resultData.categories,(item:string,index:number){// ...},(item:string,index:number)index.toString())4.2.2 不支持索引签名标准 TypeScript 中可以定义索引签名// TypeScript 写法在 ArkTS 中不支持interfaceStringMap{[key:string]:string}在 ArkTS 中必须使用RecordK, V或数组替代// ArkTS 兼容写法letinputData:Recordstring,Object{}4.2.3 不支持对象字面量作为类型标准 TypeScript 中可以直接使用对象字面量// TypeScript 写法在 ArkTS 中不支持letpoint:{x:number,y:number}{x:10,y:20}在 ArkTS 中必须显式声明类或接口// ArkTS 兼容写法classPoint{x:number0y:number0}letpoint:PointnewPoint()point.x10point.y20在我们的项目中AI差评分析Data类的设计正是遵循了这一原则。4.2.4 函数返回类型显式指定ArkTS 对函数返回类型推断有限制。当return语句中的表达式是对返回类型被省略的函数或方法的调用时会发生编译时错误。因此所有函数必须显式指定返回类型// 必须显式指定返回类型generateData(input:Recordstring,Object):AI差评分析Data{// ...returnresult}4.3 质量门控经过审批以下质量门控条件全部满足需求边界清晰无歧义已完成需求确认输入输出字段明确技术方案与现有架构对齐采用与项目其他应用一致的三层架构验收标准具体可测试每个原子任务都有明确的验收标准所有关键假设已确认Mock 数据策略、ArkTS 语法约束等已确认项目特性规范已对齐遵循项目的编码规范、目录结构和命名约定5. 自动化执行阶段Automate自动化执行阶段利用自动化工具和流程执行任务提高开发效率和质量。5.1 代码生成脚本在 “AI差评分析” 应用的开发过程中我们使用了自动化脚本辅
