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 装饰器标记为入口，通过 router API 实现页面间导航。值得注意的是，项目的 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.ets
export class AI电商标题优化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.ets
import { AI电商标题优化Data } from './AI电商标题优化Model'

export class AI电商标题优化Service {
  private model: AI电商标题优化Data

  constructor() {
    this.model = new AI电商标题优化Data()
  }

  // 生成AI电商标题优化数据
  generateData(input: Record<string, Object>): AI电商标题优化Data {
    let result: AI电商标题优化Data = new AI电商标题优化Data()
    // Mock data generation based on input
    let original_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_titleVal
    return result
  }
}

服务层设计的关键决策：

输入参数类型：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 任务优先级排序

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

优先级	任务	原因
P0	任务 1 (Model)	基础依赖，所有其他任务都依赖它
P0	任务 2 (Service)	核心逻辑，UI 层依赖它
P0	任务 3 (UI 输入区域)	用户交互入口，必须优先完成
P0	任务 4 (按钮交互)	核心交互逻辑
P0	任务 5 (UI 结果展示)	核心功能展示
P1	任务 6 (导航集成)	页面集成，影响用户体验
P1	任务 7 (UI 打磨)	细节优化，提升品质感

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 组件包裹可能超出的内容？—— 必须使用

安全审查：

• 是否存