AI求职信生成：基于HarmonyOS与ArkTS的AI原生应用开发实践
AI求职信生成：基于HarmonyOS与ArkTS的AI原生应用开发实践
摘要：本文以"AI求职信生成"应用为完整案例，系统阐述基于HarmonyOS Next操作系统与ArkTS语言开发AI原生应用的完整技术实践。文章严格遵循六阶段开发方法论——对齐、架构、原子化、审批、自动化执行、评估，从需求分析、架构设计、模块拆分、代码实现到质量控制，全方位呈现HarmonyOS生态下AI求职信生成应用开发的技术要点与最佳实践。全文包含核心代码片段、架构决策分析、ArkTS语法约束详解及性能优化策略，为HarmonyOS应用开发者提供可参考的完整技术方案。
一、对齐阶段（Align）：从模糊需求到精确规范
1.1 项目上下文分析
"AI求职信生成"是运行在HarmonyOS Next系统上的AI原生应用，归属于一个包含多个 AI 应用的应用集合。该集合以"AI智能助手"为统一入口，覆盖健康生活、工作效率、创意娱乐、学习成长、职业发展六大领域，每个应用解决一个具体的用户场景问题。
1.1.1 技术栈全景
在开始编码之前，我们首先梳理了项目所涉及的技术栈，确保每个技术选型都经过充分考量：
| 技术维度 | 选型方案 | 版本/规格 | 选型理由 |
|---|---|---|---|
| 操作系统 | HarmonyOS Next | API 12+ | 面向未来的全场景分布式OS |
| 开发语言 | ArkTS（基于TypeScript的鸿蒙原生语言） | – | 原生支持，编译时类型安全 |
| UI框架 | ArkUI（声明式UI框架） | – | 声明式范式，状态驱动渲染 |
| 路由方案 | @kit.ArkUI router | 系统内置 | 零额外依赖，原生性能 |
| 构建工具 | Hvigor | – | 官方构建工具，深度优化 |
| 包管理 | oh-package.json5 | – | 标准鸿蒙包管理格式 |
1.1.2 现有代码模式分析
通过分析项目已有代码，我们识别出统一的架构模式——MVC变体（Model-View-Service），这是HarmonyOS社区中广泛采用的轻量级分层架构。每个应用由三个核心文件组成：
-
*Page.ets：视图层，负责UI渲染和用户交互，以@Entry和@Component装饰器标识。这是ArkUI声明式编程的核心载体，所有界面元素在此文件中定义。 -
*Model.ets：数据模型层，定义数据结构，以export class导出。该层不包含任何业务逻辑，纯粹用于数据建模和类型约束。 -
*Service.ets：业务逻辑层，封装数据生成和业务处理逻辑。该层是未来接入真实AI大模型API的扩展点。
这种模式在整个项目中被一致遵循，从"AI求职信生成"到"AI品牌起名Slogan"、"AI合同审查"等数十个应用，均采用相同的三文件结构。这种一致性极大地降低了维护成本和跨应用开发的认知负担。
在Index.ets入口页面中，通过读取rawfile目录下的apps/apps.json配置文件动态加载应用列表，每个应用条目包含page字段指向对应的页面路径：
// Index.ets 中的动态加载逻辑
private loadApps(): void {
try {
let ctx: Context = getContext(this)
let mgr = ctx.resourceManager
let data: Uint8Array = mgr.getRawFileContentSync('apps/apps.json')
let decoder: util.TextDecoder = util.TextDecoder.create('utf-8')
let jsonStr: string = decoder.decodeToString(data)
let rawList: AppJsonItem[] = JSON.parse(jsonStr) as AppJsonItem[]
// ... 解析并构建AppInfo列表
} catch {
this.apps = this.getDefaultApps()
}
}
这段代码展示了HarmonyOS资源管理的关键API：getRawFileContentSync用于读取rawfile目录下的二进制资源文件，TextDecoder用于将UTF-8编码的字节流解码为字符串。整个加载过程是同步的，适合在aboutToAppear生命周期钩子中执行。
1.1.3 应用启动流程分析
当用户从主页点击"AI求职信生成"卡片时，完整的调用链如下：
用户点击卡片 → router.pushUrl({ url: app.pageUrl })
→ 系统加载AI求职信生成Page.ets
→ @Entry装饰器触发页面初始化
→ @Component构建组件树
→ @State变量初始化
→ build()方法执行UI渲染
→ 用户看到输入表单
这个流程体现了HarmonyOS声明式UI的核心思想：开发者只需描述UI的状态和结构，框架负责渲染和更新。
1.2 需求理解与确认
1.2.1 原始需求分析
求职信生成是求职者职业发展中的关键环节。一份高质量的求职信需要精准匹配目标岗位、突出个人亮点、展现专业素养，同时还要符合目标公司的文化和行业惯例。AI求职信生成应用的需求可以拆解为以下功能点：
- F1：收集用户输入的岗位信息（目标岗位、目标公司）
- F2：收集用户的个人经历和技能摘要
- F3：基于输入生成完整的求职信（Cover Letter）正文
- F4：突出个人亮点，帮助用户在众多求职者中脱颖而出
- F5：进行人岗匹配分析，展示求职者与岗位的契合度
- F6：生成邮件主题建议，便于求职者通过邮件发送
- F7：提供投递建议和面试准备提示
- F8：生成多个版本的求职信，适配不同类型的公司（如初创公司 vs 大企业）
- F9：识别目标公司类型，调整求职信的语气和重点
1.2.2 边界确认
经过需求澄清，我们确定了以下边界：
输入范围：
- 目标岗位（必填）：用户填写的求职目标岗位，如"前端开发工程师"、"产品经理"等
- 目标公司（必填）：用户投递的目标公司名称
- 个人经历（必填）：用户的工作经历、项目经验、教育背景等
输出范围：
- cover_letter：完整的求职信正文
- highlights：个人亮点列表（数组），3个突出的能力或成就
- match_analysis：人岗匹配分析，说明求职者与岗位的匹配程度
- subject：邮件主题建议，便于求职者通过邮件发送
- tips：投递建议和面试准备提示
- variants：多个版本的求职信（数组），适配不同类型公司
- company_type：识别的公司类型（如"初创公司"、"大型企业"等）
- adjusted：针对公司类型的求职信调整说明
非功能需求：
- 页面需在主流手机屏幕尺寸（360dp-428dp宽度）下正常显示
- 交互响应时间不超过500ms（当前Mock数据阶段）
- 支持深色模式（通过HarmonyOS的深色适配机制）
排除范围：
- 不涉及真实的AI大模型API调用（当前阶段使用Mock数据模拟）
- 不涉及后端服务，所有逻辑在客户端本地执行
- 不涉及用户认证和权限管理
- 不涉及求职信的直接发送或投递功能
1.2.3 关键决策点
在需求分析过程中，我们识别出以下关键决策点并逐一解决：
决策1：数据模型字段设计
问题：求职信信息应该包含哪些字段？字段粒度如何界定？
方案评估：
- 粗粒度：只包含"求职信正文"一个字段，简洁但信息量不足
- 细粒度：拆分为正文、亮点、匹配分析、主题、建议、变体等多个字段，信息丰富
决策结果：采用细粒度设计。求职信生成不仅仅是写一段文字，还需要提供配套的投递建议、匹配分析等增值信息，这些信息对求职者来说具有很高的实用价值。
决策2：Mock数据策略
问题：是随机生成完全固定的数据，还是基于输入做简单的映射生成？
方案评估：
- 固定数据：实现简单，但演示效果差，用户感觉不到输入与输出的关联
- 基于输入的映射生成：需要写一些条件判断逻辑，但演示效果更真实
决策结果：采用基于输入的映射生成策略。例如，用户输入的岗位名称会被嵌入到求职信正文和匹配分析中，形成"生成结果：xxx岗位"的格式，让用户直观感受到输入的影响。
决策3：状态管理粒度
问题：@State变量应该设计为几个？
方案评估：
- 单个状态对象：包含输入和输出，逻辑简单但任何字段变化都会触发整个UI重建
- 分离输入和输出状态：输入变化不影响结果展示区，反之亦然，性能更好
决策结果：分离为三个状态变量——inputData用于输入收集，resultData用于结果存储，showResult用于控制显隐。
1.3 如何在没有真实AI API的情况下验证产品价值
这是一个非常实际的问题。在项目初期，我们往往无法立即获得AI大模型的API访问权限。我们的策略是：
- Mock数据模拟：使用模板字符串生成基于输入的演示数据，让用户看到输入与输出的关联性
- 数据结构预定义：按照真实API的返回格式设计数据模型，后续只需替换Service层的实现
- UI先行：先完成完整的UI交互流程，确保用户操作路径流畅
这种策略保证了产品价值的早期验证，同时为后续的AI能力接入预留了平滑的扩展路径。
1.4 达成共识
对齐阶段最终产出了明确的需求规范文档：
- 验收标准：用户输入岗位、公司、个人经历后，点击"寄出信件"按钮，页面展示完整的求职信结果，包含cover_letter、highlights、match_analysis等9个字段的全部展示
- 技术约束：必须遵循ArkTS语法约束（不支持any/unknown类型、不支持解构赋值、不支持索引签名、不支持函数表达式等）
- 集成方案：作为独立页面，通过
router.pushUrl从主页导航进入，通过router.back()返回 - 数据流规范：单向数据流，用户输入 → Service处理 → State更新 → UI渲染
二、架构阶段（Architect）：从系统设计到模块规范
2.1 整体架构设计
基于对齐阶段的共识，我们设计了"AI求职信生成"的软件架构。整个架构遵循HarmonyOS的声明式开发范式，采用经典的三层架构。
2.1.1 架构分层图
┌──────────────────────────────────────────────────────────┐
│ 视图层（View） │
│ AI求职信生成Page.ets │
│ @Entry @Component 声明式UI + @State 状态管理 + 条件渲染 │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 信封Header（返回按钮 + 标题 + 装饰图标） │ │
│ │ 信纸输入表单（岗位 + 公司 + 个人经历） │ │
│ │ 寄出信件按钮（触发数据生成） │ │
│ │ 回信结果卡片（9个字段的条件渲染展示） │ │
│ └──────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 业务逻辑层（Service） │
│ AI求职信生成Service.ets │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ generateData(input): AI求职信生成Data │ │
│ │ - 输入参数校验和类型转换 │ │
│ │ - Mock数据生成（基于输入映射） │ │
│ │ - 结果对象组装和返回 │ │
│ └──────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 数据模型层（Model） │
│ AI求职信生成Model.ets │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ class AI求职信生成Data { │ │
│ │ cover_letter: string // 求职信正文 │ │
│ │ highlights: string[] // 个人亮点列表 │ │
│ │ match_analysis: string // 人岗匹配分析 │ │
│ │ subject: string // 邮件主题建议 │ │
│ │ tips: string // 投递建议 │ │
│ │ variants: string[] // 求职信变体列表 │ │
│ │ company_type: string // 公司类型 │ │
│ │ adjusted: string // 调整说明 │ │
│ │ } │ │
│ └──────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 系统层（HarmonyOS SDK） │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ @kit.ArkUI（router）│ ArkTS运行时 │ 资源管理 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
2.1.2 模块依赖关系与接口契约
AI求职信生成Page.ets
├── import { AI求职信生成Data } from './AI求职信生成Model'
├── import { AI求职信生成Service } from './AI求职信生成Service'
└── import { router } from '@kit.ArkUI'
三个模块的依赖关系是单向的：Page → Service → Model，不存在循环依赖，符合高内聚低耦合的设计原则。这种设计带来的好处是：
- 可测试性：Service层可以脱离UI层独立测试
- 可替换性：替换Mock数据为真实API时，只需修改Service层
- 可维护性：每个模块职责清晰，修改范围可控
2.2 数据流向设计
数据在应用中的流转遵循"单向数据流"原则，这是ArkUI声明式框架的核心设计理念。与传统的双向绑定不同，单向数据流使得数据变化可预测、可追踪：
用户输入（TextInput onChange 回调）
│
▼ 写入状态
@State inputData: Record<string, Object> = {}
│
▼ 按钮点击事件
this.service.generateData(this.inputData)
│
▼ 返回新数据
@State resultData: AI求职信生成Data | null = null
│
▼ 状态变更触发UI自动重新渲染
UI自动重新渲染（声明式绑定）
│
▼
用户查看求职信结果
这种数据流设计的关键优势在于：
- 可预测性：数据变化的方向是确定的，不存在双向绑定可能导致的循环更新问题
- 调试友好：可以在状态变化的每个环节添加日志输出，追踪数据流转
- 性能优化：框架可以精确知道哪些组件需要更新，避免不必要的渲染
2.3 数据模型设计
AI求职信生成Data类的设计考虑了求职信的完整信息维度，共包含8个字段，覆盖了求职信的核心要素：
// 文件：entry/src/main/ets/apps/AI求职信生成/AI求职信生成Model.ets
export class AI求职信生成Data {
// 求职信核心内容（2个字段）
cover_letter: string = '' // 求职信正文，完整的求职信文本
highlights: string[] = [] // 个人亮点列表（数组），突出3个核心能力
// 分析与建议（3个字段）
match_analysis: string = '' // 人岗匹配分析，展示求职者与岗位的契合度
subject: string = '' // 邮件主题建议，便于求职者通过邮件发送
tips: string = '' // 投递建议，面试准备提示
// 版本与适配（3个字段）
variants: string[] = [] // 求职信变体列表（数组），适配不同类型公司
company_type: string = '' // 公司类型，如"初创公司"、"大型企业"等
adjusted: string = '' // 调整说明，针对公司类型的求职信调整描述
constructor() {
// 显式初始化所有字段（ArkTS要求）
this.cover_letter = ''
this.highlights = []
this.match_analysis = ''
this.subject = ''
this.tips = ''
this.variants = []
this.company_type = ''
this.adjusted = ''
}
}
设计决策深度解析
1. 为什么字段名使用英文？
求职信生成的应用场景天然涉及中英文混合内容（如岗位名称、公司名称可能是英文的），字段名使用英文可以避免编码问题和潜在的跨语言兼容性问题。同时，英文字段名在序列化为JSON时也更加通用。
2. 数据类型选择
highlights和variants字段使用string[]数组类型。在UI层，通过ForEach组件遍历数组：
if (this.resultData.highlights) {
ForEach(this.resultData.highlights, (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())
}
3. 构造函数中的字段初始化
ArkTS要求在类声明体内声明字段，并在构造函数中显式初始化。不能在构造函数参数中声明字段：
// ❌ ArkTS不支持
class Foo {
constructor(public name: string) {}
}
// ✅ ArkTS支持的写法
class Foo {
name: string = ''
constructor() {
this.name = ''
}
}
2.4 服务层设计
服务层封装了核心业务逻辑，是应用的可扩展核心。当前阶段使用Mock数据，未来替换为真实AI API调用时，只需修改此层的实现：
// 文件：entry/src/main/ets/apps/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 positionVal: string = String(input['position'] || '')
result.cover_letter = '生成结果：' + positionVal
result.highlights = ['示例项1', '示例项2', '示例项3']
result.match_analysis = '生成结果：' + positionVal
result.subject = '生成结果：' + positionVal
result.tips = '生成结果：' + positionVal
result.variants = ['示例数据1', '示例数据2', '示例数据3']
return result
}
}
关键设计点
1. 输入参数类型：Record<string, Object>
这个类型选择是经过深思熟虑的。Record<K, V>是ArkTS支持的少数TypeScript实用类型之一（与Partial、Required、Readonly并列）。它表示一个键为string、值为Object的映射类型。相比any，它提供了基本的类型约束；相比具体的接口类型，它又保持了灵活性，允许动态添加字段。
2. 显式类型转换
String(input['position'] || '')这行代码展示了ArkTS中推荐的类型安全实践：
- 使用
|| ''提供默认值，防止undefined值 - 使用
String()函数显式转换，确保类型安全 - 避免使用隐式转换（如
input['position'] + ''）
3. Mock数据与真实API的替换策略
当前Service层返回的是硬编码的Mock数据。未来替换为真实AI API时，只需修改generateData方法的实现：
// 未来接入真实API的示意代码
async generateData(input: Record<string, Object>): Promise<AI求职信生成Data> {
let response = await http.request({
url: 'https://api.example.com/cover-letter/generate',
method: http.RequestMethod.POST,
data: JSON.stringify(input)
})
return this.parseResponse(response)
}
这种替换对Page层完全透明，Page层不需要做任何修改。
2.5 视图层设计
视图层是ArkTS声明式UI的核心体现，采用@Component装饰器定义组件：
// 文件：entry/src/main/ets/apps/AI求职信生成/AI求职信生成Page.ets
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() {
// 1. 信封Header
this.buildHeader()
// 2. 可滚动内容区域
Scroll() {
Column() {
// 2.1 信纸输入表单
this.buildInputForm()
// 2.2 寄出信件按钮
this.buildSubmitButton()
// 2.3 回信结果展示（条件渲染）
if (this.showResult && this.resultData !== null) {
this.buildResultCard()
}
}
}
}
}
}
状态管理设计
三个@State变量的设计遵循了"最小状态原则"：
| 状态变量 | 类型 | 用途 | 触发更新条件 |
|---|---|---|---|
inputData |
Record<string, Object> |
存储用户输入的三个字段 | 每次输入变化 |
resultData |
AI求职信生成Data | null |
存储生成结果 | 点击生成按钮 |
showResult |
boolean |
控制结果区域的显隐 | 点击生成按钮/返回 |
为什么resultData使用联合类型而不是空对象？
使用AI求职信生成Data | null而非AI求职信生成Data（初始化为空对象），是因为：
null明确表示"尚未生成数据"的状态- 在条件渲染中，可以通过
!== null进行类型收窄（type narrowing） - 避免将"空数据"和"尚未生成"两种状态混淆
三、原子化阶段（Atomize）：任务分解与模块实现
3.1 任务分解与依赖管理
将"AI求职信生成"应用开发任务分解为以下原子任务，每个任务都有明确的输入、输出和验收标准：
| 任务ID | 任务名称 | 预估工时 | 前置依赖 | 验收标准 |
|---|---|---|---|---|
| T1 | 数据模型类定义（Model） | 0.5h | 无 | 类定义完整，8个字段均已声明和初始化 |
| T2 | 服务层业务逻辑（Service） | 1h | T1 | generateData方法可返回完整数据对象 |
| T3 | 页面布局与UI组件 | 2h | 无 | 信封Header、信纸输入表单、按钮布局完成 |
| T4 | 用户输入处理逻辑 | 0.5h | T3 | 输入变化能正确写入inputData |
| T5 | 数据生成与结果展示 | 1h | T2, T3, T4 | 点击按钮后展示完整求职信结果 |
| T6 | 路由配置与导航 | 0.5h | T3 | 点击返回可回到主页 |
| T7 | 样式与视觉优化 | 0.5h | T5 | 字体、颜色、间距符合设计规范 |
| T8 | 测试与调试 | 1h | T1-T7 | 所有功能正常，无编译错误 |
任务之间的依赖关系图如下：
T1 (Model) → T2 (Service) → T5 (结果展示)
↑
T3 (布局) → T4 (输入处理) → T5 (结果展示)
T3 (布局) → T6 (路由)
T5 → T7 (样式优化)
T1-T7 → T8 (测试)
3.2 核心实现详解
3.2.1 页面顶部信封Header（T3）
顶部信封Header是整个页面的"门面"，包含三个部分：返回按钮、标题区域和装饰图标。采用Row水平布局实现左右分布：
Row() {
// 左侧：返回按钮
Text('← 返回')
.fontSize(13)
.fontColor('#5C4033')
.onClick(() => { router.back() })
Blank() // 弹性间距
// 中间：标题和副标题
Column() {
Text('📱 AI求职信生成')
.fontSize(18)
.fontWeight(FontWeight.Bold)
.fontColor('#2C1810')
Text('✉ 信件')
.fontSize(10)
.fontColor('#8B6914')
.margin({ top: 2 })
}
Blank() // 弹性间距
// 右侧：装饰图标
Text('✉').fontSize(22)
}
.width('100%')
.padding({ left: 20, right: 20, top: 16, bottom: 14 })
.backgroundColor('#F5F0E0')
设计要点：
-
主题色设计：整个页面采用暖色调——米黄色（
#F5F0E0）背景搭配深棕色（#2C1810）文字，营造出复古信纸的温暖质感。这种色彩设计不仅视觉上舒适，还通过"信纸"的隐喻强化了"求职信"的产品定位。 -
Blank()组件实现弹性布局：Blank()是ArkUI中的弹性空白组件，它会占据剩余空间。在Row中放置两个Blank()，分别位于标题的左右两侧，实现了标题居中的效果，等价于Flex布局的space-between。 -
视觉层次感：主标题使用18号字体加粗，副标题使用10号字体金色，形成了清晰的视觉层次。这种设计引导用户先关注主标题，再阅读副标题。
3.2.2 用户输入表单（T4）
输入表单包含三个输入字段，每个字段遵循相同的设计模式——标签 + 输入框的组合。特别地，整个表单被设计在"信纸"卡片中，强化了"写求职信"的沉浸感：
Column() {
// 岗位输入
Text('岗位')
.fontSize(11)
.fontColor('#5C4033')
.margin({ top: 6, bottom: 3 })
TextInput({ placeholder: '请输入岗位' })
.fontSize(13)
.height(40)
.backgroundColor('transparent')
.border({ width: { bottom: 1 }, color: '#B8A88A' })
.padding({ left: 8, right: 8 })
.onChange((val: string) => { this.inputData['岗位'] = val })
// 公司输入
Text('公司')
.fontSize(11)
.fontColor('#5C4033')
.margin({ top: 6, bottom: 3 })
TextInput({ placeholder: '请输入公司' })
.fontSize(13)
.height(40)
.backgroundColor('transparent')
.border({ width: { bottom: 1 }, color: '#B8A88A' })
.padding({ left: 8, right: 8 })
.onChange((val: string) => { this.inputData['公司'] = val })
// 个人经历输入
Text('个人经历')
.fontSize(11)
.fontColor('#5C4033')
.margin({ top: 6, bottom: 3 })
TextInput({ placeholder: '请输入个人经历' })
.fontSize(13)
.height(40)
.backgroundColor('transparent')
.border({ width: { bottom: 1 }, color: '#B8A88A' })
.padding({ left: 8, right: 8 })
.onChange((val: string) => { this.inputData['个人经历'] = val })
}
.width('100%')
.padding({ left: 24, right: 24, top: 20, bottom: 20 })
.backgroundColor('#FFFDF5')
.margin({ top: 12 })
.border({ width: 1, color: '#D4C5A9' })
关键ArkTS语法要点详解：
1. Record类型与索引访问
this.inputData['岗位'] = val 这种写法在ArkTS中是允许的，因为inputData的类型是Record<string, Object>，而Record是ArkTS明确支持的少数TypeScript实用类型之一。但需要注意，普通对象的索引签名（如interface Foo { [key: string]: string }）在ArkTS中是不支持的。
// ❌ ArkTS不支持索引签名
interface Foo {
[key: string]: string // 编译错误
}
// ✅ ArkTS支持Record工具类型
let data: Record<string, string> = {}
data['key'] = 'value' // 允许
2. TextInput的onChange回调
onChange((val: string) => { ... })中的回调必须是箭头函数，因为ArkTS不支持函数表达式。箭头函数自动捕获外层的this上下文，使得在回调中可以访问组件的@State变量。
3. 信纸风格装饰
输入框使用了border({ width: { bottom: 1 }, color: '#B8A88A' })，只显示底部边框，模拟了信纸上的横线效果。这种设计细节虽小，但显著提升了产品的整体质感和用户体验。
4. 透明背景
backgroundColor('transparent')让输入框融入信纸背景，进一步强化了"信纸"的视觉隐喻。用户感觉自己是在一张信纸上填写内容，而非在一个普通的APP表单中操作。
3.2.3 寄出信件按钮（T5）
"寄出信件"按钮是整个应用的核心交互入口，它的设计直接影响用户体验：
Button('📱 寄出信件')
.width('100%')
.height(50)
.backgroundColor('#8B4513')
.borderRadius(6)
.fontColor('#F5F0E0')
.fontSize(16)
.fontWeight(FontWeight.Bold)
.margin({ top: 18, bottom: 14 })
.onClick(() => {
this.resultData = this.service.generateData(this.inputData)
this.showResult = true
})
交互逻辑分析：
点击按钮时，以下事件顺序发生：
- 调用
this.service.generateData(this.inputData)生成求职信数据 - 将
讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。
更多推荐
5
0- 0
已为社区贡献114条内容
所有评论(0)