AI小红书文案：HarmonyOS 智能内容生成应用全流程开发实战

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

---

一、对齐阶段（Align）

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

1.1 项目上下文分析

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

"AI小红书文案"应用被归类为"创意娱乐"类别，其核心功能是针对小红书平台的内容创作者，提供 AI 驱动的文案生成能力。在 apps.json 中的注册信息示意如下：

{
  "icon": "📱",
  "title": "AI小红书文案",
  "subtitle": "小红书文案生成",
  "color": "#FF2442",
  "bg": "#FFF0F3",
  "border": "#FFD6DC",
  "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 大模型
• 输出展示：以结构化方式展示完整的小红书笔记，包含标题、备选标题、正文、标签、封面建议、互动钩子、发布时间
• UI 风格：小红书品牌风格，以红色（#FF2442）为主色调，清爽的白色卡片区域，模拟小红书笔记的视觉体验
• 交互方式：点击"生成笔记"按钮触发计算，结果区域通过 if 条件渲染控制显隐，初始状态隐藏结果区域，生成后展示完整笔记预览
• 数据模型：AI小红书文案Data 类定义了 7 个字段，覆盖小红书笔记的核心要素
• 导航行为：页面顶部提供"← 返回"按钮，使用 router.back() 实现返回上一页

1.3 技术约束对齐

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

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

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

不支持解构赋值：标准 TypeScript 中常见的 const { title, body } = 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> 泛型类型。

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

1.4 ArkUI 声明式 UI 规范对齐

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

@State 装饰器：用于声明组件内部的状态变量，当状态变量发生变化时，ArkUI 框架会自动触发 UI 重新渲染。这是 ArkUI 响应式编程的核心机制。

@Builder 装饰器：用于定义可复用的 UI 构建函数，可以将 UI 代码封装为独立的构建方法，提高代码复用性。

条件渲染：使用 if/else 语句根据条件控制组件的显示与隐藏，这是 ArkUI 中最常用的渲染控制方式之一。

列表渲染：使用 ForEach 组件遍历数组并生成对应的 UI 元素，需要提供唯一的键值生成函数。

Scroll 组件：用于创建可滚动的容器，当内容超出屏幕高度时，用户可以通过滚动查看更多内容。

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

对齐阶段是项目成功的基础。通过以上三个维度的深入对齐，我们为后续的架构设计、编码实现和测试验证奠定了坚实的基础。在团队开发中，建议将对齐阶段的成果整理为 ALIGNMENT_AI小红书文案.md 文档，作为团队共识的正式记录。

---

二、架构阶段（Architect）

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

2.1 整体架构设计

"AI小红书文案"应用采用经典的三层架构模式：

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

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

• 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小红书文案"的数据模型包含 7 个字段，覆盖小红书笔记的全部要素：

// AI小红书文案Model.ets
export class AI小红书文案Data {
  title: string = ''
  title_alternatives: string[] = []
  body: string = ''
  hashtags: string[] = []
  cover_suggestion: string = ''
  interaction_hook: string = ''
  posting_time: string = ''

  constructor() {
    this.title = ''
    this.title_alternatives = []
    this.body = ''
    this.hashtags = []
    this.cover_suggestion = ''
    this.interaction_hook = ''
    this.posting_time = ''
  }
}

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

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

数组类型字段：title_alternatives 和 hashtags 是字符串数组类型，用于存储多个备选标题和话题标签。在 ArkUI 的 UI 渲染中，这些数组通过 ForEach 组件进行迭代渲染。

纯数据类：AI小红书文案Data 是纯数据类，不包含任何业务方法。这种设计保持了数据模型的纯净性，使其可以被多个服务层方法复用。

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 topicVal: string = String(input['topic'] || '')

    result.title = '生成结果：' + topicVal
    result.title_alternatives = ['示例项1', '示例项2', '示例项3']
    result.body = '生成结果：' + topicVal
    result.hashtags = ['示例项1', '示例项2', '示例项3']
    result.cover_suggestion = '生成结果：' + topicVal
    result.interaction_hook = '生成结果：' + topicVal
    result.posting_time = '生成结果：' + topicVal
    return result
  }
}

服务层设计的关键决策：

输入参数类型：input: Record<string, Object> 使用 ArkTS 支持的泛型容器类型 Record，用于接收动态的输入参数。Record<K, V> 是 ArkTS 中少数几个支持的实用类型之一，用于表示键值对映射。

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

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

2.5 UI 表现层设计

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

顶部导航栏：包含返回按钮、应用标题和应用图标，采用 Row 水平布局，通过 Blank() 组件实现标题居中。

输入区域：包含主题、产品、风格三个输入框，采用 TextInput 组件，每个输入框配有标签文字。输入框使用 backgroundColor('#F5F5F5') 和 borderRadius(8) 创建圆角灰色背景的输入区域。

操作按钮："生成笔记"按钮，使用 Button 组件，以小红书品牌红色（#FF2442）为背景色，圆角 25 像素，实现胶囊按钮的视觉效果。

结果展示区域：通过条件渲染控制显隐，展示完整的笔记内容，包含标题、备选标题、正文、标签、封面建议、互动钩子和发布时间。

2.6 数据流向设计

"AI小红书文案"的数据流向遵循"用户输入 → 状态存储 → 服务调用 → 结果展示"的闭环：

用户输入 (TextInput onChange)
    ↓
this.inputData['主题'] = val  (Record<string, Object>)
    ↓
点击"生成笔记"按钮 (onClick)
    ↓
this.service.generateData(this.inputData)
    ↓
返回 AI小红书文案Data 实例
    ↓
this.resultData = result
    ↓
this.showResult = true
    ↓
ArkUI 自动触发 UI 重新渲染
    ↓
展示笔记预览 (if 条件渲染)

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

2.7 异常处理策略

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

输入校验：在服务层 generateData 方法中，对输入参数进行校验，确保必要的字段存在且格式正确。

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

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

---

三、原子化阶段（Atomize）

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

3.1 任务分解策略

在"AI小红书文案"的开发中，我们将整个开发任务分解为以下原子级任务：

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

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

输出：AI小红书文案Model.ets 文件

验收标准：

• 定义 AI小红书文案Data 类，包含 7 个字段
• 每个字段有正确的类型标注
• 所有字段有默认值初始化
• 构造函数中完成属性初始化
• 类可以被其他模块通过 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 条件渲染控制结果显示
• 展示标题、备选标题、正文、标签、封面建议、互动钩子、发布时间
• 使用 ForEach 组件渲染数组类型字段（备选标题和标签）
• 结果区域包含"笔记预览"标题
• 结果卡片使用白色背景、圆角边框

工作量估算：1 人天

任务 6：导航与页面集成

输入：路由配置规范

输出：页面路由集成

验收标准：

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

工作量估算：0.5 人天

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

输入：UI 设计规范

输出：UI 细节优化

验收标准：

• 页面背景色正确（#F5F5F5）
• 各组件间距、边距符合设计规范
• 文本颜色、字体大小、字重正确
• 在 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 架构阶段审批项

• 三层架构是否与现有项目一致？—— 是，与项目中其他应用的架构模式一致
• 数据模型是否完整覆盖需求？—— 是，7 个字段覆盖小红书笔记核心要素
• 服务层接口是否清晰？—— 是，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
• 是否存在对象字面量直接作为类型声明？—— 必须使用类或接口

ArkUI 规范审查：

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

安全审查：

• 是否存在硬编码敏感信息？—— 确认无 API Key、密码等敏感信息
• 输入参数是否进行类型转换？—— String(input['topic'] || '') 确保类型安全

4.3 审批流程

在"AI小红书文案"的开发中，我们采用了以下审批流程：

1. 自审：开发者完成设计后，首先进行自我审查，对照审批清单逐项检查
2. 互审：将设计文档提交给另一位团队成员进行交叉审查，从不同视角发现问题
3. 终审：技术负责人进行最终审批，确认所有事项已解决后，批准进入编码阶段

审批通过后，所有设计文档（对齐文档、架构文档、原子化任务列表）被标记为"已批准"状态，作为后续开发工作的正式依据。任何对已批准设计的变更都需要重新提交审批，确保设计变更的可追溯性。

4.4 审批阶段的常见问题

在审批阶段，我们经常遇到以下问题，需要特别注意：

需求遗漏：在审查过程中发现某些需求未被覆盖。例如，在"AI小红书文案"的初始设计中，遗漏了"互动钩子"（interaction_hook）字段的展示，在审批阶段被及时发现并补充。

技术方案冲突：新应用的设计与现有项目架构存在冲突。例如，如果新应用使用了不同的状态管理方案，需要与现有架构对齐。

过度设计：开发者为"未来可能的需求"做了过多的设计，导致当前实现复杂度增加。审批阶段需要严格遵循"只做当前需要做的事"原则。

---

五、自动化执行阶段（Automate）

自动化执行阶段是将设计转化为实际代码的过程。在"AI小红书文案"的开发中，我们通过自动化工具和规范化的编码流程，确保代码质量和开发效率。

5.1 环境搭建与构建系统

HarmonyOS 应用开发使用 Hvigor 构建系统，它是华为自研的构建工具，基于 Gradle 但针对 HarmonyOS 进行了优化。项目的构建配置位于 oh-package.json5 文件中：

{
  "name": "entry",
  "version": "1.0.0",
  "description": "Please describe the basic information.",
  "main": "",
  "author": "",
  "license": "",
  "dependencies": {}
}

从配置可以看出，项目没有任何第三方依赖，所有功能都基于 HarmonyOS 内置的 Kit 能力。这包括 @kit.ArkUI（UI 框架）和 @kit.ArkTS（基础能力）。

5.2 数据模型层编码实现

数据模型层是应用的基础，定义了数据结构和类型约束。在"AI小红书文案"中，数据模型层的完整实现如下：

// entry/src/main/ets/apps/AI小红书文案/AI小红书文案Model.ets
export class AI小红书文案Data {
  title: string = ''
  title_alternatives: string[] = []
  body: string = ''
  hashtags: string[] = []
  cover_suggestion: string = ''
  interaction_hook: string = ''
  posting_time: string = ''

  constructor() {
    this.title = ''
    this.title_alternatives = []
    this.body = ''
    this.hashtags = []
    this.cover_suggestion = ''
    this.interaction_hook = ''
    this.posting_time = ''
  }
}

这段代码展示了 ArkTS 中数据模型的标准写法。有几个关键点值得注意：

字段声明与初始化：ArkTS 要求类字段必须在类声明内部声明，而不是在构造函数中声明。同时，每