企业官网建设流程全解析

AI电商标题优化：HarmonyOS 智能电商标题生成应用全流程开发实战

摘要：本文以"AI电商标题优化"应用为案例，详细阐述在 HarmonyOS 生态下，从需求对齐到最终交付的全流程开发实践。文章遵循"对齐→架构→原子化→审批→自动化执行→评估"六阶段方法论，涵盖 ArkTS 语法约束、ArkUI 声明式 UI 开发、@State 状态管理、数据模型设计、服务层抽象、条件渲染与列表渲染、Record 数据容器、Hvigor 构建系统等核心技术主题，并配以完整的代码示例和工程实践心得。全文约 10000 字，适合 HarmonyOS 应用开发者、移动端架构师和技术管理者阅读。

一、对齐阶段（Align）

在软件开发中，对齐阶段的目标是将模糊需求转化为精确规范。这一阶段如果做得不够充分，后续的架构设计和编码实现就会不断返工，造成时间和资源的大量浪费。对于"AI电商标题优化"这一应用，我们需要从项目上下文、需求理解、技术约束三个维度进行深度对齐。

1.1 项目上下文分析

在开始任何开发工作之前，理解项目所处的上下文环境至关重要。本项目是一个运行在 HarmonyOS 操作系统上的 AI 智能助手集合应用，代码仓库位于c:\Users\l\DevEcoStudioProjects\MyApplication。整个应用以"AI 智能助手"为品牌定位，通过首页网格（Index.ets）聚合了多个 AI 驱动的应用，涵盖健康生活、工作效率、创意娱乐、学习成长、职业发展六大类别。这种应用集合的架构模式，使得每个应用可以独立开发、独立部署，同时又通过统一的首页入口为用户提供一站式的 AI 服务体验。

"AI电商标题优化"应用被归类为"工作效率"类别，其核心功能是针对电商平台的商品标题，提供 AI 驱动的智能优化、关键词分析和 A/B 测试建议。在apps.json中的注册信息示意如下：

{"icon":"🏷️","title":"AI电商标题优化","subtitle":"电商标题","color":"#3B82F6","bg":"#EFF6FF","border":"#BFDBFE","page":"apps/AI电商标题优化/AI电商标题优化Page","cat":"工作效率"}

从技术栈上看，项目采用 HarmonyOS 的 ArkTS 语言、ArkUI 声明式框架、@kit.ArkUI和@kit.ArkTS核心 Kit 包。项目构建系统为 Hvigor，依赖管理通过oh-package.json5完成。所有页面以@Entry装饰器标记为入口，通过routerAPI 实现页面间导航。值得注意的是，项目的oh-package.json5中dependencies为空，这说明项目完全依赖 HarmonyOS 系统的内置 Kit 能力，无需引入任何第三方依赖库，这大大降低了依赖管理和版本兼容性的复杂度。

1.2 需求理解与边界确认

"AI电商标题优化"的核心需求是：用户输入商品原标题和产品信息，点击"优化标题"按钮后，系统 AI 对标题进行智能优化，生成优化后的标题、备选方案、关键词分析以及平台规则提示，并以结构化方式展示。

经过需求分析，我们明确了以下关键边界：

• 用户输入：原标题（字符串）、产品信息（字符串）
• 业务逻辑：根据输入生成标题优化数据，当前阶段使用 Mock 数据模拟 AI 生成行为，后续可接入真实 AI 大模型
• 输出展示：以结构化方式展示完整的优化结果，包含优化后标题、备选标题列表、关键词列表、核心关键词、搜索量级、竞争度、优先级、标题结构分析、平台规则提示、A/B测试建议
• UI 风格：电商风格，以橙色（#F97316）为主色调，白色卡片区域展示结果，模拟电商后台的视觉体验
• 交互方式：点击"优化标题"按钮触发计算，结果区域通过if条件渲染控制显隐，初始状态隐藏结果区域，生成后展示完整的优化报告
• 数据模型：AI电商标题优化Data类定义了 10 个字段，覆盖标题优化的核心要素
• 导航行为：页面顶部提供"← 返回"按钮，使用router.back()实现返回上一页

1.3 技术约束对齐

在 HarmonyOS 的 ArkTS 环境下，有若干重要的语法约束需要在开发前对齐。这些约束与标准 TypeScript 存在显著差异，如果开发团队之前没有 ArkTS 的开发经验，这些约束可能会成为开发过程中的主要障碍。

不支持索引访问类型：这是 ArkTS 中最具约束力的规则之一。标准 TypeScript 中，我们可以通过obj["field"]的方式动态访问对象属性，这在处理 JSON 数据或动态配置时非常方便。但在 ArkTS 中，必须使用显式类型名称，通过obj.field语法访问。这要求开发者在设计阶段就明确所有字段名称，无法在运行时动态添加或访问属性。

不支持 any 和 unknown 类型：所有变量必须有显式类型标注。例如，Record<string, Object>是合法的泛型容器类型，但不能使用any。这意味着在处理不确定类型的数据时，需要借助类型断言或联合类型来解决问题。

不支持解构赋值：标准 TypeScript 中常见的const { optimizedTitle, alternatives } = data语法在 ArkTS 中不可用，必须创建临时变量逐字段操作。这虽然增加了代码量，但使数据流动路径更加清晰。

不支持 Function.bind/apply/call：在 ArkTS 中，this 的语义被限制为传统的 OOP 风格，禁止在独立函数中使用 this。这意味着所有依赖 this 的上下文操作都必须通过类的实例方法来完成，不能通过函数式编程中的 bind 或 call 来动态绑定 this。

不支持 for…in 遍历对象：对于数组，必须使用常规的 for 循环或ForEach组件进行迭代。这是因为 ArkTS 在编译时就已经确定了对象的布局，运行时遍历属性没有意义。

不支持对象字面量直接作为类型声明：必须显式声明类和接口，然后通过构造函数创建实例。这要求所有数据结构都有明确的类型定义。

不支持在构造函数中声明类字段：必须在类声明内部直接声明字段，而不是在构造函数中通过this.xxx = xxx声明。这与标准 TypeScript 的类字段声明方式一致，但 ArkTS 更加严格地强制执行这一规则。

不支持索引签名：不能使用[key: string]: string这样的索引签名。应改用数组（arrays）或Record<K, V>泛型类型。

不支持 is 运算符：必须将其替换为instanceof运算符。在使用对象字段之前，必须使用as运算符将其转换为适当的类型。

这些约束直接影响代码写法，在后续的架构和编码阶段必须严格遵守。在"AI电商标题优化"的开发中，我们特别关注了Record<string, Object>的使用方式——它是 ArkTS 支持的少数几种泛型容器类型之一，用于处理动态键值对场景。

1.4 ArkUI 声明式 UI 规范对齐

在 UI 开发层面，HarmonyOS 的 ArkUI 框架采用声明式编程范式，与传统的命令式 UI 开发有显著差异。我们需要在开发前对齐以下几个关键规范：

@State 装饰器：用于声明组件内部的状态变量，当状态变量发生变化时，ArkUI 框架会自动触发 UI 重新渲染。这是 ArkUI 响应式编程的核心机制。在"AI电商标题优化"中，我们使用@State来管理用户输入、结果数据和界面显隐状态。

@Entry 装饰器：标记页面为应用的入口页面，使其可以被路由系统识别和导航。每个页面组件都必须使用@Entry装饰器。

@Component 装饰器：将结构体标记为 ArkUI 组件，使其具备声明式 UI 的能力。在"AI电商标题优化"中，我们使用@Component装饰器，与项目中其他应用保持一致。

条件渲染：使用if/else语句根据条件控制组件的显示与隐藏，这是 ArkUI 中最常用的渲染控制方式之一。在"AI电商标题优化"中，我们使用if (this.showResult && this.resultData !== null)来控制结果区域的显隐。

列表渲染：使用ForEach组件遍历数组并生成对应的 UI 元素，需要提供唯一的键值生成函数。在"AI电商标题优化"中，我们使用ForEach来渲染alternatives和keywords数组中的每个元素。

Scroll 组件：用于创建可滚动的容器，当内容超出屏幕高度时，用户可以通过滚动查看更多内容。在"AI电商标题优化"中，整个内容区域（输入区域、按钮、结果区域）都包裹在Scroll组件中。

Row 和 Column：ArkUI 的线性布局组件，分别对应水平方向和垂直方向的布局。与 Flexbox 布局模型类似，通过justifyContent和alignItems控制子组件的排列方式。

Blank 组件：用于在Row或Column中占据剩余空间，实现弹性布局效果。在"AI电商标题优化"的顶部导航栏中，我们使用Blank()组件实现标题的水平居中。

对齐阶段是项目成功的基础。通过以上三个维度的深入对齐，我们为后续的架构设计、编码实现和测试验证奠定了坚实的基础。

二、架构阶段（Architect）

基于对齐阶段达成的共识，我们进入架构设计阶段。目标是设计出一套与现有系统架构一致、可扩展、易维护的技术方案。架构设计是软件开发中最关键的环节之一，它直接决定了代码的可维护性、可测试性和可扩展性。

2.1 整体架构设计

"AI电商标题优化"应用采用经典的三层架构模式：

┌─────────────────────────────────────────┐ │ UI 表现层 (Page) │ │ AI电商标题优化Page.ets │ │ - 用户输入采集（原标题/产品信息） │ │ - 优化结果展示 │ │ - 状态变量管理 │ │ - 条件渲染与列表渲染 │ ├─────────────────────────────────────────┤ │ 业务服务层 (Service) │ │ AI电商标题优化Service.ets │ │ - 标题优化数据生成逻辑 │ │ - AI 模型调用封装 │ │ - 输入参数处理 │ │ - 数据转换与格式化 │ ├─────────────────────────────────────────┤ │ 数据模型层 (Model) │ │ AI电商标题优化Model.ets │ │ - 数据实体定义 │ │ - 10 个字段属性约束 │ │ - 默认值初始化 │ │ - 数据完整性保证 │ └─────────────────────────────────────────┘

这种分层架构与项目中其他应用的架构模式保持一致，确保代码风格统一、易于理解和维护。每一层都有自己的明确定义和职责边界：

• UI 表现层：负责用户的交互体验，包括输入采集、结果展示、状态管理等。这一层只关注"如何展示"和"如何交互"，不关心"数据从哪里来"和"业务逻辑是什么"。
• 业务服务层：负责核心业务逻辑的实现，包括标题优化数据生成、AI 模型调用封装、输入参数处理等。这一层是应用的"大脑"，处理所有业务规则。
• 数据模型层：负责数据实体的定义和约束，确保数据结构的完整性和类型安全。这一层是应用的数据契约，所有数据流动都基于这个契约进行。

2.2 模块依赖关系

模块之间的依赖关系遵循"单向依赖"原则，即上层依赖下层，下层不依赖上层：

AI电商标题优化Page.ets ↓ import AI电商标题优化Service.ets ↓ import AI电商标题优化Model.ets

具体来说：

• AI电商标题优化Page.ets导入AI电商标题优化Model中的AI电商标题优化Data类用于类型标注，导入AI电商标题优化Service中的AI电商标题优化Service类用于业务逻辑调用
• AI电商标题优化Service.ets导入AI电商标题优化Model中的AI电商标题优化Data类用于创建和返回数据实例
• AI电商标题优化Model.ets是纯数据模型，不依赖任何其他模块

这种单向依赖关系确保了代码的可测试性——我们可以独立测试每一层，而不需要依赖其他层的实现。

2.3 数据模型设计

数据模型是架构设计的核心产出之一。"AI电商标题优化"的数据模型包含 10 个字段，覆盖标题优化的全部要素：

// AI电商标题优化Model.etsexportclassAI电商标题优化Data{optimized_title:string=''alternatives:string[]=[]keywords:string[]=[]keyword:string=''search_volume:string=''competition:string=''priority:string=''structure_analysis:string=''platform_tips:string=''ab_test_suggestion:string=''constructor(){this.optimized_title=''this.alternatives=[]this.keywords=[]this.keyword=''this.search_volume=''this.competition=''this.priority=''this.structure_analysis=''this.platform_tips=''this.ab_test_suggestion=''}}

这个模型设计体现了以下几个关键设计决策：

字段默认值初始化：每个字段都在声明时指定了默认值（空字符串或空数组），同时在构造函数中再次显式初始化。这种双重初始化策略在 ArkTS 中是必要的，因为 ArkTS 要求在类声明中直接声明字段，而构造函数中的初始化确保了实例的完整性。

数组类型字段：alternatives和keywords是字符串数组类型，用于存储多个备选标题和关键词。在 ArkUI 的 UI 渲染中，这些数组通过ForEach组件进行迭代渲染，每个备选标题以列表形式逐条展示。

纯数据类：AI电商标题优化Data是纯数据类，不包含任何业务方法。这种设计保持了数据模型的纯净性，使其可以被多个服务层方法复用。

字段命名策略：字段名采用英文命名（如optimized_title、alternatives、keywords等），与项目中的命名规范保持一致。这些字段名直接对应 AI 输出 JSON 的键名，便于后续接入真实 AI 模型时的数据映射。

2.4 服务层设计

服务层封装了核心业务逻辑，对外提供统一的接口。在"AI电商标题优化"中，服务层只暴露了一个核心方法：

// AI电商标题优化Service.etsimport{AI电商标题优化Data}from'./AI电商标题优化Model'exportclassAI电商标题优化Service{privatemodel:AI电商标题优化Dataconstructor(){this.model=newAI电商标题优化Data()}// 生成AI电商标题优化数据generateData(input:Record<string,Object>):AI电商标题优化Data{letresult:AI电商标题优化Data=newAI电商标题优化Data()// Mock data generation based on inputletoriginal_titleVal:string=String(input['original_title']||'')result.optimized_title='生成结果：'+original_titleVal result.alternatives=['示例项1','示例项2','示例项3']result.keywords=['示例数据1','示例数据2','示例数据3']result.structure_analysis='生成结果：'+original_titleVal result.platform_tips='生成结果：'+original_titleVal result.ab_test_suggestion='生成结果：'+original_titleValreturnresult}}

服务层设计的关键决策：

输入参数类型：input: Record<string, Object>使用 ArkTS 支持的泛型容器类型Record，用于接收动态的输入参数。Record<K, V>是 ArkTS 中少数几个支持的实用类型之一，用于表示键值对映射。注意，ArkTS 不支持Partial<Record<string, Object>>这样的嵌套实用类型，所以我们在使用时直接使用Record<string, Object>。

Mock 数据生成：当前阶段使用 Mock 数据模拟 AI 生成行为，original_titleVal从输入参数中提取原标题值，并将其作为生成结果的前缀。这种设计模式使得后续接入真实 AI 模型时，只需替换generateData方法的内部实现，而不需要修改调用方代码。

服务实例管理：在 Page 层中，AI电商标题优化Service被声明为private成员变量，在组件初始化时创建实例。这种设计确保了服务实例的生命周期与页面组件一致，避免了多次创建实例的开销。

类型安全：String(input['original_title'] || '')这种写法确保了即使输入参数中缺失original_title字段，也能返回一个空字符串，而不是undefined或null，从而避免类型错误。

2.5 UI 表现层设计

UI 表现层是整个应用的入口，负责用户交互和界面展示。在"AI电商标题优化"中，UI 层由单一页面AI电商标题优化Page构成，包含以下几个核心区域：

顶部导航栏：包含返回按钮、应用标题和图标，采用Row水平布局，通过Blank()组件实现标题居中。标题文字使用FontWeight.Bold粗体，颜色为深色（#1A1A1A），返回按钮使用橙色（#F97316）以匹配品牌色调。

输入区域：包含原标题和产品信息两个输入框，采用TextInput组件，每个输入框配有标签文字。输入框使用backgroundColor('#F9FAFB')和borderRadius(6)创建浅灰色背景、圆角边框的输入区域，边框颜色为#E5E7EB，营造清晰的输入边界。

操作按钮："优化标题"按钮，使用Button组件，以橙色（#F97316）为背景色，圆角 10 像素，白色文字，粗体字重，实现醒目的操作按钮视觉效果。

结果展示区域：通过条件渲染控制显隐，展示完整的优化结果，包含优化后标题（Optimized title）、备选标题（Alternatives）、关键词列表（Keywords）、核心关键词（Keyword）、搜索量级（Search volume）、竞争度（Competition）、优先级（Priority）、标题结构分析（Structure analysis）、平台规则提示（Platform tips）、A/B测试建议（Ab test suggestion）等多个字段。

2.6 数据流向设计

"AI电商标题优化"的数据流向遵循"用户输入 → 状态存储 → 服务调用 → 结果展示"的闭环：

用户输入 (TextInput onChange) ↓ this.inputData['原标题'] = val (Record<string, Object>) this.inputData['产品信息'] = val ↓ 点击"优化标题"按钮 (onClick) ↓ this.service.generateData(this.inputData) ↓ 返回 AI电商标题优化Data 实例 ↓ this.resultData = result ↓ this.showResult = true ↓ ArkUI 自动触发 UI 重新渲染 ↓ 展示优化结果 (if 条件渲染 + ForEach 列表渲染)

这个数据流向设计体现了 ArkUI 声明式编程的核心思想——开发者只需要关注状态（State）的变化，框架自动处理 UI 的更新。当showResult从false变为true时，ArkUI 框架会自动执行条件渲染，展示结果区域。

2.7 异常处理策略

在架构设计中，异常处理是不可忽视的一环。虽然"AI电商标题优化"当前阶段使用 Mock 数据，但我们需要为后续接入真实 AI 模型预留异常处理机制：

输入校验：在服务层generateData方法中，使用String(input['original_title'] || '')对输入参数进行校验和类型转换，确保即使输入字段缺失或为空，也能生成兜底的空字符串值。

空数据保护：在 UI 层，使用if (this.showResult && this.resultData !== null)进行空值检查，确保在数据未生成时不会尝试访问空对象的属性。

默认值兜底：数据模型中的所有字段都有默认值，即使在极端情况下（如数据生成失败），UI 层也能展示空数据而非崩溃。

数组保护：在渲染数组类型字段时，使用if (this.resultData.alternatives)和if (this.resultData.keywords)进行存在性检查，确保在alternatives或keywords为null或undefined时不会导致ForEach组件报错。

三、原子化阶段（Atomize）

原子化阶段的核心任务是将宏观的架构设计分解为更小的、可管理的原子任务。每个原子任务应该有明确的输入输出、清晰的责任边界，并且可以独立完成和测试。原子化分解的目标是让每个任务都能在 1-2 天内完成，避免任务粒度太大导致进度不可控。

3.1 任务分解策略

在"AI电商标题优化"的开发中，我们将整个开发任务分解为以下原子级任务：

任务 1：数据模型定义与验证

输入：需求文档中关于数据字段的定义

输出：AI电商标题优化Model.ets文件

验收标准：

• 定义AI电商标题优化Data类，包含 10 个字段
• 每个字段有正确的类型标注（string、string[]）
• 所有字段有默认值初始化
• 构造函数中完成属性初始化
• 类可以被其他模块通过export导入

工作量估算：0.5 人天

任务 2：服务层核心逻辑实现

输入：数据模型定义、业务逻辑规范

输出：AI电商标题优化Service.ets文件

验收标准：

• 定义AI电商标题优化Service类
• 实现generateData(input: Record<string, Object>): AI电商标题优化Data方法
• 正确处理输入参数，提取原标题和产品信息
• 返回符合预期的AI电商标题优化Data实例
• 方法签名与 Page 层调用方式匹配

工作量估算：0.5 人天

任务 3：UI 页面搭建——输入区域

输入：UI 设计稿、ArkUI 组件规范

输出：AI电商标题优化Page.ets中的输入区域代码

验收标准：

• 包含原标题和产品信息两个输入框
• 每个输入框配有标签文字
• 输入框使用TextInput组件，设置 placeholder
• 输入框风格统一（圆角、浅灰色背景）
• onChange事件正确更新inputData状态

工作量估算：1 人天

任务 4：UI 页面搭建——按钮与交互

输入：交互设计规范

输出：AI电商标题优化Page.ets中的按钮和交互逻辑

验收标准：

• "优化标题"按钮样式正确（橙色背景、圆角、白色文字、粗体）
• 按钮onClick事件调用服务层方法
• 正确更新resultData和showResult状态
• 页面顶部导航栏包含返回按钮、标题和图标

工作量估算：0.5 人天

任务 5：UI 页面搭建——结果展示区域

输入：UI 设计稿、数据模型定义

输出：AI电商标题优化Page.ets中的结果展示区域代码

验收标准：

• 使用if条件渲染控制结果显示
• 展示优化后标题、备选标题、关键词、搜索量级、竞争度、优先级、结构分析、平台提示、A/B测试建议
• 使用ForEach组件渲染数组类型字段（备选标题和关键词）
• 结果区域包含"优化结果"标题
• 结果卡片使用白色背景、圆角边框

工作量估算：1 人天

任务 6：导航与页面集成

输入：路由配置规范

输出：页面路由集成

验收标准：

• 页面顶部返回按钮调用router.back()正常返回
• 页面在apps.json中正确注册
• 从首页可以正常导航到该页面

工作量估算：0.5 人天

任务 7：UI 细节打磨与适配

输入：UI 设计规范

输出：UI 细节优化

验收标准：

• 页面背景色正确（#F9FAFB）
• 各组件间距、边距符合设计规范
• 文本颜色、字体大小、字重正确
• 在 HarmonyOS 模拟器上显示正常

工作量估算：0.5 人天

3.2 任务依赖关系

原子化任务之间存在依赖关系，需要按正确的顺序执行：

任务 1 (Model) ──→ 任务 2 (Service) ──→ 任务 3 (UI 输入区域) │ │ │ ↓ └──────────→ 任务 5 (UI 结果展示) ↑ 任务 4 (按钮交互) ───┘ 任务 6 (导航集成) ── 依赖于任务 3/4/5 完成 任务 7 (UI 打磨) ── 依赖于所有 UI 任务完成

任务 1（数据模型）是基础依赖，必须先完成。任务 2（服务层）依赖于任务 1。任务 3、4、5（UI 层）可以并行进行，但都依赖于任务 2。任务 6（导航集成）和任务 7（UI 打磨）在最后阶段进行。

3.3 任务优先级排序

根据依赖关系和业务价值，我们对任务进行优先级排序：

3.4 原子化分解的价值

原子化分解不仅仅是任务拆分，更是一种风险管理策略。通过将大任务分解为小任务，我们可以：

1. 降低风险：每个小任务的风险可控，即使某个任务延期，也不会影响整体进度
2. 提高可测试性：每个原子任务都有明确的验收标准，可以独立测试
3. 便于并行开发：无依赖关系的任务可以并行进行，提高开发效率
4. 增强进度可视化：通过原子任务的完成情况，可以精确跟踪项目进度
5. 便于代码审查：小粒度的变更更容易审查，提高代码质量

四、审批阶段（Approve）

审批阶段是对前面三个阶段（对齐、架构、原子化）的成果进行审核和批准，确保所有设计决策符合项目要求，不存在遗漏或冲突。审批阶段是质量门控的关键环节，通过的审批意味着项目可以从设计阶段进入编码阶段。

4.1 审批清单

在"AI电商标题优化"的审批阶段，我们建立了以下审批清单：

4.1.1 对齐阶段审批项

• 需求理解是否准确？—— 是，核心需求（用户输入原标题/产品信息 → AI 生成优化标题和关键词分析）已明确
• 边界条件是否清晰？—— 是，当前阶段使用 Mock 数据，后续可接入真实 AI 模型
• 技术约束是否已对齐？—— 是，ArkTS 语法约束、ArkUI 声明式 UI 规范已对齐
• 项目上下文是否充分理解？—— 是，项目架构、技术栈、依赖关系已分析
• 是否存在需求歧义？—— 否，需求已收敛，无歧义

4.1.2 架构阶段审批项

• 三层架构是否与现有项目一致？—— 是，与项目中其他应用的架构模式一致
• 数据模型是否完整覆盖需求？—— 是，10 个字段覆盖标题优化核心要素
• 服务层接口是否清晰？—— 是，generateData方法输入输出类型明确
• 数据流向是否合理？—— 是，符合"用户输入 → 状态存储 → 服务调用 → 结果展示"闭环
• 是否存在过度设计？—— 否，架构简单清晰，未引入不必要的抽象
• 模块依赖关系是否遵循单向依赖？—— 是，Page → Service → Model 单向依赖

4.1.3 原子化阶段审批项

• 任务分解是否合理？—— 是，7 个任务粒度适中，每个任务 0.5~1 人天
• 任务依赖关系是否明确？—— 是，依赖关系图清晰
• 验收标准是否可衡量？—— 是，每个任务有具体的验收标准
• 优先级排序是否合理？—— 是，P0 任务优先，P1 任务后置

4.2 代码审查要点

在审批阶段，除了对设计文档进行审核外，我们还建立了代码审查的要点清单，供后续编码阶段的代码审查使用：

ArkTS 语法合规性审查：

• 是否使用了any或unknown类型？—— 禁止使用
• 是否存在is运算符？—— 必须替换为instanceof
• 是否存在解构赋值？—— 禁止使用
• 是否存在Function.bind/apply/call？—— 禁止使用
• 是否存在for...in遍历？—— 必须替换为常规 for 循环
• 是否存在索引签名？—— 禁止使用，改用数组或Record
• 是否存在对象字面量直接作为类型声明？—— 必须使用类或接口
• 是否存在展开运算符用于非数组场景？—— 展开运算符仅用于数组到 rest 参数或数组字面量

ArkUI 规范审查：

• 状态变量是否使用@State装饰器？—— 必须使用
• 是否有不必要的width、height动画操作？—— 禁止在动画中改变布局属性
• 列表渲染是否提供唯一键值？——ForEach必须提供键值生成函数
• 条件渲染逻辑是否正确？—— 使用if而非show属性
• 是否使用了Scroll组件包裹可能超出的内容？—— 必须使用

安全审查：

• 是否存