AI公众号排版方案 —— HarmonyOS 原生AI应用开发全流程技术博客

tyqtyq22

234人浏览 · 2026-07-27 21:54:34

tyqtyq22 · 2026-07-27 21:54:34 发布

AI公众号排版方案 —— HarmonyOS 原生AI应用开发全流程技术博客

摘要：本文以"AI公众号排版方案"应用的完整开发过程为例，深入剖析在 HarmonyOS 平台上使用 ArkTS/ArkUI 进行原生 AI 应用开发的全流程。内容涵盖从需求对齐、架构设计、任务分解、质量审核、自动化实现到复盘评估的六个阶段，展示了如何利用 HarmonyOS 的声明式 UI 框架、@State 状态驱动机制和 MVVM 架构模式，构建一个能够根据用户输入智能生成公众号排版方案的应用。本文适合 HarmonyOS 应用开发者、ArkTS 初学者以及对 AI 与前端交叉领域感兴趣的开发者阅读。

在这里插入图片描述

1. 对齐阶段（Align）

对齐阶段是所有软件开发项目的基石。在"AI公众号排版方案"项目中，这一阶段的目标是将模糊的"做一个AI公众号排版工具"的需求，转化为精确的、可执行的规范文档。我们将从项目上下文分析、需求理解确认、疑问澄清与决策三个维度展开。

1.1 项目上下文分析

技术栈全景

在开始任何编码工作之前，首先要对项目所处的技术生态进行全面的审视。"AI公众号排版方案"运行在 HarmonyOS 生态之上，其核心技术栈如下：

技术维度	选型方案	版本/规格
操作系统	HarmonyOS	API 6.0.1 (21)
开发语言	ArkTS（基于TypeScript的静态类型方言）	Stage Mode
UI框架	ArkUI（声明式UI框架）	组件化 + @State驱动
开发工具	DevEco Studio	最新版
打包构建	Hvigor 构建系统	oh-package.json5
路由方案	router 模块（@kit.ArkUI）	页面级跳转
数据模型	纯 ArkTS 类定义	无第三方依赖

架构模式分析

整个项目采用 MVVM（Model-View-ViewModel） 架构范式，在 ArkTS 的语法约束下做了适应性调整。这种架构模式的核心优势在于关注点分离——每一层都有明确的职责边界，便于维护和测试。

Model 层：AI公众号排版方案Data 类，承载所有数据结构和业务实体。在 ArkTS 中，类声明引入的是一种新类型，而非值，因此天然适合作为数据模型。
View 层：AI公众号排版方案Page 结构体，使用 @Component 装饰器标记为 UI 组件，通过 @State 装饰器声明响应式状态变量，驱动 UI 自动刷新。
Service 层：AI公众号排版方案Service 类，封装核心业务逻辑，包括数据生成和处理，属于 ViewModel 的变体实现。

项目文件结构

从项目根目录出发，目标应用的文件结构如下：

entry/src/main/ets/apps/AI公众号排版方案/
├── AI公众号排版方案Page.ets       # 视图层（View）
├── AI公众号排版方案Model.ets      # 数据模型层（Model）
└── AI公众号排版方案Service.ets    # 业务逻辑层（Service/ViewModel）

这三个文件构成了一个完整的三层架构，彼此之间通过 import 语句建立依赖关系。Page 依赖 Service 和 Model，Service 依赖 Model，Model 独立无依赖。

依赖关系分析

从项目根目录的 build-profile.json5 可以看到，应用的目标 SDK 版本为 6.0.1(21)，采用 stageMode 阶段化运行模式。oh-package.json5 中无第三方依赖，体现了 HarmonyOS 原生开发"零外部依赖"的指导思想——所有能力均来自系统 Kit。

值得注意的是，ArkTS 的 import 语法有一条严格规则：所有 import 语句必须在程序中的所有其他语句之前。这意味着我们不能像在 JavaScript 中那样在代码中间动态导入模块。在编写代码时，必须将所有的 import 集中放在文件顶部。

1.2 需求理解确认

原始需求

"AI公众号排版方案"的核心需求是：用户输入文章内容和风格偏好，应用基于这些输入智能生成一套完整的公众号排版方案，包括布局设计、配色方案、组件列表、字体建议、配图建议和模板描述。

边界确认

在需求对齐阶段，明确边界是防止"范围蔓延"的关键手段。

维度	边界定义
输入范围	文章内容、风格偏好两个文本字段
输出范围	布局、配色方案、组件列表、字体、配图建议、模板描述等多维度信息
设备范围	仅支持手机（phone）设备类型
交互方式	文本输入 + 按钮触发 + 结果展示
网络依赖	当前版本无网络依赖（离线Mock数据）
数据持久化	无需持久化，结果仅当次展示

需求理解深化

在深入阅读源代码后，我梳理出以下关键需求点：

输入采集：用户需要提供两个维度的信息——文章内容（如"一篇关于AI技术的科普文章"）和风格偏好（如"简约、科技感"）。这些信息通过 TextInput 组件采集，以键值对形式存储在 inputData 中。
智能排版生成：点击"生成排版"按钮后，Service 层根据输入生成排版方案结果。当前版本使用 Mock 数据作为演示，但代码结构预留了接入真实 AI 模型的接口。
结果展示：排版方案以结构化卡片形式展示在页面下方，包含 layout、header、body、footer、primary、secondary、background、text、accent 等多项详细数据，以及 components 列表信息。
导航交互：页面顶部提供返回按钮，支持从主应用列表页跳入后返回。

1.3 疑问澄清与决策

在开发过程中，遇到了多个关键决策点，每个决策都需要在 ArkTS 语法约束和实际开发需求之间找到平衡。

决策1：ArkTS 语法约束下的状态管理

疑问：ArkTS 不支持 any 和 unknown 类型，也不支持索引签名，如何管理动态表单数据？

上下文分析：在公众号排版方案应用中，用户输入包含两个字段——文章内容和风格偏好。这些字段是动态的，未来可能增加或减少。在传统 TypeScript 中，我们可能会使用 any 或 {[key: string]: string} 索引签名来管理。但 ArkTS 明确禁止了这两种方式。

决策：使用 Record<string, Object> 类型替代 any。Record 是 ArkTS 中少数支持的泛型工具类型之一（Partial、Required、Readonly 和 Record 是例外），允许在编译时已知的键值对映射。对于 Object 类型的值，在 Service 层通过 String() 显式转换。这种方案在类型安全和灵活性之间取得了平衡。

@State inputData: Record<string, Object> = {};
// 在 onChange 回调中通过字符串键赋值
.onChange((val: string) => { this.inputData['文章内容'] = val })

备选方案对比：

方案	优点	缺点	结论
Record<string, Object>	编译时类型安全，兼容 ArkTS	需要显式类型转换	✅ 采用
多个独立 @State 变量	类型精确，无需转换	字段增多时冗余	❌ 不灵活
自定义类包装表单数据	类型最安全	需额外定义类，过于重量级	❌ 过度设计

决策2：条件渲染的实现方式

疑问：ArkTS 不支持 in 运算符，也不支持某些高级条件表达式，如何实现"有结果才显示"的按需渲染？

决策：使用 if 语句内嵌在 build() 方法中，配合 @State 驱动。这是 ArkUI 推荐的声明式渲染方式。当 showResult 为 true 且 resultData 不为 null 时，结果卡片才会渲染。

if (this.showResult && this.resultData !== null) {
  Column() {
    Text('🎨 排版方案')
      .fontSize(15)
      .fontWeight(FontWeight.Bold)
      .fontColor('#4C1D95')
      .margin({ bottom: 12 })
    // ... 渲染结果详情
  }
}

这种方式的优势在于：ArkUI 的 if 条件渲染是"真正"的条件渲染——当条件为 false 时，对应的节点树不会出现在渲染管线中，不会占用任何内存或计算资源。

决策3：列表数据的渲染方式

疑问：如何渲染 components 这样的动态数组列表？

决策：使用 ForEach 组件。ForEach 是 ArkUI 中用于列表渲染的核心组件，接受一个数组、一个内容生成器和一个键生成器。

if (this.resultData.components) {
  ForEach(this.resultData.components, (item: string, index: number) => {
    Row() {
      Text('• ').fontSize(12).fontColor('#666666')
      Text(item).fontSize(12).fontColor('#333333')
    }
    .width('100%')
    .padding({ top: 2, bottom: 2 })
  }, (item: string, index: number) => index.toString())
}

这里需要注意的是，ForEach 的第三个参数是一个键生成器函数，用于唯一标识每个列表项，帮助 ArkUI 的 diff 算法高效地识别哪些项需要重新渲染。我们使用 index.toString() 作为键，这在列表内容不变的情况下是足够的。

决策4：ArkTS 解构限制的应对

疑问：ArkTS 不支持解构赋值和解构变量声明，如何从对象中提取字段？

决策：不使用解构，而是直接通过点号运算符访问字段。在 Service 层中，从 Record<string, Object> 中取值后，使用 String() 进行显式转换。

let contentVal: string = String(input['content'] || '')

这种写法虽然略显冗长，但完全符合 ArkTS 的静态类型安全要求，且代码的执行路径一目了然。

2. 架构阶段（Architect）

架构阶段的核心任务是从共识文档出发，设计出系统架构、模块划分和接口规范。这一阶段的产出物是一份完整的架构设计文档，指导后续的所有编码工作。

2.1 整体架构设计

三层架构模式

"AI公众号排版方案"采用经典的三层架构，每一层都有明确的职责边界：

┌─────────────────────────────────────────────────┐
│                    View 层                       │
│         AI公众号排版方案Page.ets                   │
│    @Component + @State + build()                │
│  职责：UI渲染、用户交互、状态管理                    │
└──────────────────┬──────────────────────────────┘
                   │ 调用
┌──────────────────▼──────────────────────────────┐
│                 Service 层                       │
│        AI公众号排版方案Service.ets                 │
│   职责：业务逻辑、数据生成、AI调用封装               │
└──────────────────┬──────────────────────────────┘
                   │ 创建/使用
┌──────────────────▼──────────────────────────────┐
│                  Model 层                        │
│        AI公众号排版方案Data（class）               │
│   职责：数据定义、结构建模、类型约束                 │
└─────────────────────────────────────────────────┘

层间通信协议

View → Service：View 层通过调用 Service 层的方法，传入用户输入数据（Record<string, Object> 类型），获取处理结果（AI公众号排版方案Data 类型）。
Service → Model：Service 层创建 AI公众号排版方案Data 实例，填充各个字段后返回给 View 层。
View → Model：View 层通过 @State 装饰器持有 AI公众号排版方案Data | null 类型的变量，在 Service 层返回结果后赋值，触发 UI 自动刷新。

2.2 核心数据流

数据流是理解系统行为的关键。在"AI公众号排版方案"中，数据流是一个单向循环：

用户输入 → onChange回调 → inputData更新 → 点击按钮 →
Service.generateData() → 数据处理/AI生成 → 返回Data对象 →
resultData赋值 → @State触发 → UI自动刷新 → 用户查看结果

这个单向数据流模式与 React 的"单向数据流"理念一脉相承，但实现方式完全不同。在 ArkUI 中，数据流的驱动核心是 @State 装饰器——当被 @State 装饰的变量发生变化时，ArkUI 框架会自动重新渲染与该变量绑定的 UI 组件，开发者无需手动操作 DOM。

2.3 核心模块详细设计

Model 层：AI公众号排版方案Data

AI公众号排版方案Data 是系统的数据模型，定义了排版方案的所有字段。在 ArkTS 中，类字段必须在构造函数外声明，并且在构造函数中显式初始化。

export class AI公众号排版方案Data {
  layout: string = ''
  header: string = ''
  body: string = ''
  footer: string = ''
  primary: string = ''
  secondary: string = ''
  background: string = ''
  text: string = ''
  accent: string = ''
  color_scheme: string = ''
  components: string[] = []
  name: string = ''
  style: string = ''
  usage: string = ''
  title: string = ''
  size: string = ''
  spacing: string = ''
  font: string = ''
  image_suggestions: string = ''
  template: string = ''

  constructor() {
    this.layout = ''
    this.header = ''
    this.body = ''
    this.footer = ''
    this.primary = ''
    this.secondary = ''
    this.background = ''
    this.text = ''
    this.accent = ''
    this.color_scheme = ''
    this.components = []
    this.name = ''
    this.style = ''
    this.usage = ''
    this.title = ''
    this.size = ''
    this.spacing = ''
    this.font = ''
    this.image_suggestions = ''
    this.template = ''
  }
}

这个模型类的设计体现了几个重要的 ArkTS 约束：

不支持在构造函数中声明类字段：所有字段必须在类体内部声明，构造函数中只能赋值。
不支持索引签名：不能使用 [key: string]: string 这样的动态字段声明，每个字段必须显式声明。
必须显式初始化：每个字段在声明时或构造函数中必须被赋予初始值，不能有 undefined 状态。

从领域建模的角度看，这个模型涵盖了排版方案的三个核心维度：

视觉维度：layout（布局）、color_scheme（配色方案）、font（字体）
结构维度：header（头部）、body（正文）、footer（尾部）、components（组件列表）
元数据维度：name（名称）、style（风格）、usage（使用场景）、template（模板描述）

Service 层：AI公众号排版方案Service

AI公众号排版方案Service 是业务逻辑的核心，负责将用户输入转化为结构化的排版方案数据。

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

    result.layout = '生成结果：' + contentVal
    result.color_scheme = '生成结果：' + contentVal
    result.components = ['示例数据1', '示例数据2', '示例数据3']
    result.font = '生成结果：' + contentVal
    result.image_suggestions = '生成结果：' + contentVal
    result.template = '生成结果：' + contentVal
    return result
  }
}

这里有几个值得注意的设计点：

构造函数的角色：Service 在构造函数中创建了一个 model 实例，这是为了在后续扩展中，可以在 Service 内部维护状态。当前版本虽然未使用，但这种设计为未来接入真实 AI 模型时缓存中间结果奠定了基础。
显式类型转换：String(input['content'] || '') 这一行展示了 ArkTS 中从 Object 到 string 的典型转换模式。由于 ArkTS 不支持 any 类型，也不支持隐式类型转换，开发者必须显式调用 String() 构造函数。
Mock 数据模式：当前版本使用 '生成结果：' + contentVal 这样的 Mock 数据模式，这是一种"先让应用跑起来"的务实策略。在后续迭代中，可以将 generateData 方法内部的逻辑替换为真实的 AI 模型调用。

View 层：AI公众号排版方案Page

View 层是整个应用的"门面"，直接面向用户。在 ArkUI 中，View 层由 @Component 装饰的 struct 实现。

import { AI公众号排版方案Data } from './AI公众号排版方案Model'
import { AI公众号排版方案Service } from './AI公众号排版方案Service'
import { router } from '@kit.ArkUI'

@Entry
@Component
struct AI公众号排版方案Page {
  @State inputData: Record<string, Object> = {}
  @State resultData: AI公众号排版方案Data | null = null
  @State showResult: boolean = false
  private service: AI公众号排版方案Service = new AI公众号排版方案Service()

  build() {
    Column() {
      // 顶部导航栏
      Row() {
        Text('← 返回').fontSize(13).fontColor('#6D28D9')
          .onClick(() => { router.back() })
        Blank()
        Column() {
          Text('📱 AI公众号排版方案').fontSize(17).fontWeight(FontWeight.Bold).fontColor('#4C1D95')
          Text('GRID · 栅格排版').fontSize(9).fontColor('#7C3AED').margin({ top: 2 })
        }
        Blank()
        Text('🎨').fontSize(22)
      }
      .width('100%')
      .padding({ left: 20, right: 20, top: 16, bottom: 14 })
      .backgroundColor('#F5F3FF')

      // 内容区域
      Scroll() {
        Column() {
          // 输入区域
          Column() {
            Text('🎨 文章内容').fontSize(11).fontColor('#6D28D9')
              .margin({ top: 6, bottom: 3 })
            TextInput({ placeholder: '请输入文章内容' })
              .fontSize(13).height(40)
              .backgroundColor('#FFFFFF').borderRadius(4)
              .border({ width: 1, color: '#C4B5FD' })
              .padding({ left: 12, right: 12 })
              .onChange((val: string) => { this.inputData['文章内容'] = val })

            Text('🎨 风格偏好').fontSize(11).fontColor('#6D28D9')
              .margin({ top: 6, bottom: 3 })
            TextInput({ placeholder: '请输入风格偏好' })
              .fontSize(13).height(40)
              .backgroundColor('#FFFFFF').borderRadius(4)
              .border({ width: 1, color: '#C4B5FD' })
              .padding({ left: 12, right: 12 })
              .onChange((val: string) => { this.inputData['风格偏好'] = val })
          }
          .width('100%').padding(18)
          .backgroundColor('#FFFFFF').borderRadius(4)
          .border({ width: 1, color: '#DDD6FE' })
          .margin({ top: 6 })

          // 生成按钮
          Button('📱 🎨 生成排版')
            .width('100%').height(50)
            .backgroundColor('#6D28D9').borderRadius(4)
            .fontColor('#FFFFFF').fontSize(16)
            .fontWeight(FontWeight.Bold)
            .margin({ top: 18, bottom: 14 })
            .onClick(() => {
              this.resultData = this.service.generateData(this.inputData)
              this.showResult = true
            })

          // 结果展示区域（条件渲染）
          if (this.showResult && this.resultData !== null) {
            // ... 渲染结果详情
          }
        }
        .width('100%')
        .padding({ left: 18, right: 18, bottom: 40 })
      }
      .layoutWeight(1)
    }
    .width('100%').height('100%')
    .backgroundColor('#F5F3FF')
  }
}

2.4 接口契约定义

接口契约是模块间通信的"法律条文"，明确定义了输入输出的格式、类型和约束。

接口	方向	输入	输出	说明
generateData	View → Service	Record<string, Object>	AI公众号排版方案Data	核心数据生成接口
router.back	View → 系统	无	无	页面返回
TextInput.onChange	用户 → View	string	void	输入采集回调

2.5 异常处理策略

在架构设计阶段，还需要考虑异常处理策略。虽然当前版本使用 Mock 数据，异常场景较少，但架构设计需要为未来扩展预留空间。

输入为空：当用户点击生成按钮但输入为空时，Service 层应返回默认数据或空数据，而不是崩溃。
类型转换异常：String() 转换对于 null 和 undefined 是安全的，但对于复杂对象可能产生不符合预期的结果。未来版本应添加更严格的输入校验。
AI 模型调用失败：当接入真实 AI 模型后，需要处理网络超时、模型返回异常等场景，此时应返回友好的错误提示而不是空白页面。

3. 原子化阶段（Atomize）

原子化阶段的核心任务是将大粒度的任务分解为更小的、可独立执行和验证的原子任务。这种分解策略有助于降低开发复杂度、提高并行效率，并使每个任务的目标更加清晰明确。

3.1 任务分解原则

在"AI公众号排版方案"项目中，我们遵循以下分解原则：

单一职责原则：每个原子任务只做一件事，且只做一件事。
可独立验证原则：每个原子任务完成后，可以独立验证其正确性。
最小依赖原则：原子任务之间的依赖关系尽可能少，优先并行无依赖的任务。
价值驱动原则：优先实现对用户可见的核心价值功能。

3.2 原子任务清单

基于上述原则，将"AI公众号排版方案"的开发任务分解为以下原子任务：

任务组A：数据模型层（无依赖，可优先执行）

任务ID	任务名称	预估工时	前置依赖	验收标准
A-01	定义AI公众号排版方案Data类	0.5h	无	类包含所有排版字段，类型正确
A-02	为Data类添加构造函数	0.2h	A-01	构造函数正确初始化所有字段
A-03	添加components数组字段	0.1h	A-01	数组类型正确，支持动态添加

任务组B：Service 业务逻辑层（依赖Model层）

任务ID	任务名称	预估工时	前置依赖	验收标准
B-01	创建Service类骨架	0.3h	A-01	类可被实例化，包含model属性
B-02	实现generateData方法签名	0.2h	B-01	方法签名正确，输入输出类型匹配
B-03	实现Mock数据生成逻辑	1h	B-02	输入有效数据时返回非空结果
B-04	添加输入参数校验逻辑	0.5h	B-02	输入为空时返回默认值，不崩溃

任务组C：View 页面层（依赖Service层）

任务ID	任务名称	预估工时	前置依赖	验收标准
C-01	创建Page组件骨架	0.5h	无	页面可正常跳转和显示
C-02	实现顶部导航栏	0.5h	C-01	显示返回按钮、标题和图标
C-03	实现输入区域UI	1h	C-01	两个输入框正常显示和交互
C-04	实现生成按钮	0.3h	C-03	按钮点击触发Service调用
C-05	实现结果展示区域	1.5h	C-04, B-03	结果显示所有排版字段
C-06	实现ForEach列表渲染	0.5h	C-05	components列表正确渲染
C-07	实现条件渲染逻辑	0.3h	C-05	无结果时隐藏，有结果时显示

任务组D：集成与测试

任务ID	任务名称	预估工时	前置依赖	验收标准
D-01	集成路由配置	0.3h	C-01	从主页面可跳入本页面
D-02	全流程联调测试	1h	C-07, D-01	输入→生成→展示全流程正常
D-03	边界条件测试	0.5h	D-02	空输入、超长输入等场景正常

3.3 任务依赖图

将上述任务按照依赖关系组织成依赖图，可以清晰地看到任务的执行顺序：

A-01 ──→ A-02 ──→ A-03
  │
  └──→ B-01 ──→ B-02 ──→ B-03
              │         │
              │         └──→ C-04
              │
              └──→ B-04
              
C-01 ──→ C-02 ──→ C-03 ──→ C-04 ──→ C-05 ──→ C-06 ──→ C-07
                                                        │
                                                        └──→ D-01 ──→ D-02 ──→ D-03

从依赖图可以看出，A组和C组的前期任务（C-01、C-02）可以并行执行，B组任务依赖A组完成后才能开始，D组任务依赖所有前置任务完成。

3.4 任务优先级排序

在实际开发中，资源（时间、人力）总是有限的，因此需要为任务分配优先级：

优先级	任务ID	理由
P0（最高）	A-01, C-01, B-01	核心骨架，一切的基础
P1	C-02, C-03, B-02, B-03	核心功能，用户可见
P2	C-04, C-05, C-06, C-07	完整交互体验
P3	A-02, A-03, B-04	辅助功能，增强健壮性
P4	D-01, D-02, D-03	集成与质量保障

3.5 原子化阶段的工程价值

将任务分解到原子粒度，带来了几个重要的工程价值：

进度可视化：每个原子任务完成时，都是一个小里程碑，可以精确衡量开发进度。
风险早发现：如果某个原子任务出现困难，可以及早发现并调整方案，而不是到集成阶段才发现问题。
并行开发：无依赖关系的任务可以并行执行，最大化开发效率。
代码审查细化：原子任务级别的代码审查更加聚焦，审查质量更高。
测试覆盖：每个原子任务都可以对应一组测试用例，提高测试覆盖率。

4. 审批阶段（Approve）

审批阶段是对前面各阶段成果进行系统性审核和确认的过程。在"AI公众号排版方案"项目中，审批阶段涵盖了对需求定义、架构设计、代码实现等多个维度的质量把关。

4.1 审批层次体系

项目采用四层审批体系，从宏观到微观逐层把关：

层次1：需求审批 → 确认需求理解的正确性和完整性
层次2：架构审批 → 确认架构设计的合理性和可行性
层次3：代码审批 → 确认代码质量、风格和正确性
层次4：集成审批 → 确认各模块协同工作的正确性

4.2 需求审批（对齐阶段成果审核）

检查项清单

检查项	标准	结果
需求边界是否清晰	输入输出范围明确，无歧义	✅ 通过
技术约束是否明确	ArkTS 语法约束已识别	✅ 通过
用户场景是否覆盖	输入→生成→展示全链路	✅ 通过
验收标准是否可测试	每个需求对应具体测试场景	✅ 通过
是否存在未解决的疑问	所有关键决策点已记录	✅ 通过

需求质量评估

在需求审批中，我们重点关注以下几个方面：

完整性评估：需求是否覆盖了用户的所有核心场景？对于"AI公众号排版方案"应用，用户的核心场景是"输入内容→获得排版方案→查看结果"。当前的需求定义完整覆盖了这个场景，包括输入采集、处理逻辑、结果展示三个环节。

一致性评估：需求之间是否存在矛盾？输入字段的命名和类型是否与后续处理逻辑一致？在检查中，我们发现 inputData 使用中文键名（‘文章内容’、‘风格偏好’），而 Service 层 generateData 方法尝试读取 input['content']，这里存在键名不一致的问题。这是一个需要在代码实现阶段纠正的缺陷。

可测试性评估：每个需求是否可以被验证？对于"点击生成按钮后显示排版方案"这个需求，可以通过以下测试场景验证：

输入有效内容 → 点击按钮 → 结果卡片显示
输入为空 → 点击按钮 → 结果卡片显示（默认值）
不输入内容 → 点击按钮 → 不崩溃

4.3 架构审批（架构阶段成果审核）

架构质量门控

检查项	标准	结果
架构图是否清晰	层次分明，组件关系明确	✅ 通过
接口定义是否完整	输入输出类型明确	✅ 通过
与现有系统是否兼容	无冲突，遵循项目规范	✅ 通过
设计可行性	技术方案可实现	✅ 通过
是否过度设计	无冗余抽象，符合当前需求	✅ 通过