一、前言

最近在学习 HarmonyOS 应用开发。环境搭好了——DevEco Studio 安装完成，API 23 SDK 已下载，模拟器也能正常启动。但真正开始写代码的时候，发现自己总是卡在各种 ArkTS 语法细节上：

@State 和普通变量到底什么区别？
ForEach 的 key 参数是干什么用的？
为什么我改了数组的值，UI 却不刷新？
TextDecorationType 在哪导入？

这些问题说大不大，但每遇到一个就要去翻文档、查社区、试错半天。作为一个惜时如命的懒人开发者，我决定换条路——试试用 AI 编程助手来帮我写代码。

这次选的是 Reasonix Code，一个基于大语言模型的对话式编程工具。选择它的原因很简单：它支持文件级别的读写操作，能直接创建和编辑项目文件，而不只是生成代码片段让我自己复制粘贴。

这篇文章记录了从 零开始，用 Reasonix Code 完成鸿蒙计算器开发的完整过程。包含了我的输入、AI 的回复、遇到的坑、以及最终的方案。如果你也对 AI 辅助开发感兴趣，这篇文章或许能给你一些参考。

二、开发环境与工具

2.1 硬件配置

配置项 说明
电脑 Windows 11，16 GB 内存，SSD
显示器 1920 × 1080，分屏开发

2.2 软件工具

工具 版本 / 说明
DevEco Studio 最新版（基于 IntelliJ IDEA 的鸿蒙专用 IDE）
HarmonyOS SDK API 23
模拟器 Phone_API23，分辨率 1080 × 1920
Reasonix Code AI 编程助手，支持对话式代码生成与文件操作
目标项目 鸿蒙计算器（项目名 Calculator）

2.3 我的 ArkTS 基础

在开始之前，我的 ArkTS 水平大概是：

  • ✅ 能看懂基本的 Column/Row/Text/Button 组件
  • ✅ 知道 @State 是响应式装饰器
  • ❌ 不清楚 ArkTS 和标准 TypeScript 的语法差异（比如不能用 map/filter/展开运算符）
  • ❌ 没写过完整的鸿蒙应用

这个水平刚好适合测试 AI 编程助手的辅助效果——有一点基础，能看懂代码，但写起来费劲。

三、什么是 Reasonix Code？

Reasonix Code 是一个对话式 AI 编程助手，和 GitHub Copilot、通义灵码类似，但它的工作方式有一些不同：

传统的 AI 代码补全（如 Copilot）：

你在 IDE 中写代码，AI 根据上下文自动补全下一行。适合"边写边补"的场景。

Reasonix Code 的工作方式：

你在对话窗口中描述需求，AI 理解后直接生成完整的代码文件。适合"从零开始搭建"的场景。

具体来说，它有几个对我帮助很大的能力：

1. 自然语言对话
不需要学特定的指令格式，就像和人聊天一样说话就行。我说"帮我写一个计算器"，它就理解了。

2. 文件级操作
不只是给我代码片段，而是能直接读取、编辑、创建项目文件。我说"在 pages 目录下创建 Index.ets"，它就真的创建了。

3. 多文件项目支持
一次处理整个项目结构，不只是单个文件。创建计算器时，它自动生成了 Index.ets、EntryAbility.ts、module.json5、app.json5 等 14 个文件。

4. 上下文记忆
能记住之前的对话内容。我前面说了项目用 API 23，后面问"帮我改一下版本号"，它知道我指的是把 20 改成 23。

四、实战目标：鸿蒙计算器

4.1 需求描述

我要开发一个鸿蒙计算器，功能要求如下：

功能 说明
四则运算 + - × ÷
清空 C 一键复位到 0
取反 ± 正负切换
百分号 % 除以 100
小数点 . 支持小数输入
链式运算 5 + 3 + 2 = 10，中间不用按等号
除零保护 5 ÷ 0 显示 Error
浮点精度 0.1 + 0.2 显示 0.3 而非 0.300...004
深色主题 纯黑背景 + 橙色按钮 + 灰白数字键

4.2 自己写会遇到的问题

如果纯手写，至少会遇到以下几个坎：

第一关：项目结构
新建项目后，IDE 生成了很多文件。虽然大部分不用改，但新手根本分不清哪个文件是干什么的，容易改错地方。

第二关：UI 布局
计算器的按钮网格涉及 Column/Row 嵌套、ForEach 列表渲染、条件样式（运算符橙色、数字键灰色）。这些语法说起来简单，实际写起来要反复查文档。

第三关：运算逻辑
链式运算的实现涉及 isNewInput 标志位的精确控制，状态稍微没理清就会出 Bug。比如 5 + 3 + 2，按第二个加号时要先算 5+3，再存储结果和加号，这个逻辑顺序很容易搞反。

第四关：ArkTS 语法限制
这是最大的坑。ArkTS 基于 TypeScript，但做了严格的语法限制：

  • ❌ 不能用 [...arr] 展开数组
  • ❌ 不能用 {...obj} 展开对象
  • ❌ 不能用 map、filter、reduce
  • ❌ 不能用 箭头函数 简写

这些限制在官方文档里有说明，但不踩一次坑根本记不住。

五、使用 Reasonix Code 开发全过程

5.1 第一步：输入需求，AI 生成项目

打开 Reasonix Code，我输入了第一行指令：

根据 HarmonyOS 项目规范（API 23，ArkTS + ArkUI），
帮我创建一个完整的鸿蒙计算器项目。
需要 AppScope、entry 模块、所有配置文件和核心代码。

AI 几乎秒回，给出了完整的项目结构和文件清单：

Calculator/
├── AppScope/
│   └── app.json5              ← 包名、版本号、API 等级
├── build-profile.json5         ← 构建配置
├── hvigorfile.ts               ← 构建脚本
├── oh-package.json5            ← 依赖管理
├── entry/
│   ├── hvigorfile.ts
│   ├── oh-package.json5
│   └── src/main/
│       ├── module.json5
│       ├── ets/
│       │   ├── entryability/
│       │   │   └── EntryAbility.ts  ← 生命周期
│       │   └── pages/
│       │       └── Index.ets       ← ⭐ 计算器核心代码
│       └── resources/
│           ├── base/element/
│           │   ├── string.json
│           │   └── color.json
│           ├── base/profile/
│           │   └── main_pages.json
│           ├── en_US/element/
│           │   └── string.json
│           └── zh_CN/element/
│               └── string.json

总共 14 个文件，AI 一次性生成并写入。我只需要确认文件内容，不需要手动建目录。

5.2 第二步：核心代码生成

最让我惊喜的是 Index.ets 的代码质量。AI 不仅写对了语法，还做了几个很细节的设计：

状态管理：

@State displayText: string = '0'       // 唯一 @State，其他用普通变量
private currentInput: string = ''
private previousInput: string = ''
private currentOperator: string = ''
private isNewInput: boolean = true
private hasError: boolean = false

只有 displayText 用 @State 装饰，其余 5 个变量都是普通私有成员。我问 AI 为什么这么设计，它解释说：“只有直接出现在 build() 中的变量才需要 @State。displayText 被 Text 组件读取，所以是响应式的。其他变量变化时手动更新 displayText 来间接触发渲染。”

这个设计比我预想的要专业——既保证了 UI 刷新，又避免了不必要的渲染开销。

事件分发：

private onButtonClick(label: string): void {
  if (this.hasError && label !== 'C') return  // 错误状态锁定
  switch (label) {
    case 'C': this.clearAll(); break
    case '±': this.toggleSign(); break
    case '%': this.percent(); break
    case '÷': case '×': case '-': case '+': this.handleOperator(label); break
    case '=': this.calculate(); break
    case '.': this.appendDot(); break
    default: this.appendNumber(label)
  }
}

16 个按钮共用同一个回调，通过 switch 分发。比写 16 个独立回调简洁太多了。

链式运算：

private handleOperator(op: string): void {
  if (this.currentOperator !== '' && !this.isNewInput) {
    this.calculate()  // 先完成前一步
  }
  this.previousInput = this.currentInput || '0'
  this.currentOperator = op
  this.isNewInput = true
}

这个逻辑我看了几分钟才完全理解——核心在于每次按运算符时，如果已有未完成的运算，先算再存。这样用户连续按 5 + 3 + 时，实际上发生了 5+3=8 → 存 8 → 准备加下一个数。

5.3 第三步：首次编译——踩坑

AI 生成完后，我打开 DevEco Studio，导入项目 -> 等待 Gradle 同步 -> 点击运行。

结果 Build Output 面板报了一堆红字：

ERROR: arkts-no-spread
It is possible to spread only arrays or classes derived from arrays
At File: Index.ets:44:24

ERROR: arkts-no-map
At File: Index.ets:55:12

一共 4 个编译错误，全部是 ArkTS 语法限制导致的。

5.4 第四步：让 AI 修复错误

我直接把错误信息复制给 Reasonix Code：

ARKTS 编译报错：
1. arkts-no-spread：不能用 ... 展开数组
2. arkts-no-map：不能用 map
3. arkts-no-filter：不能用 filter
4. 不能用对象展开 {...item}
请把所有代码改成 ArkTS 兼容的写法（用 for 循环 + concat）

AI 回复了"明白"，然后迅速修改了所有相关代码：

展开数组 → concat：

// 改前
this.todos = [newItem, ...this.todos]

// 改后
this.todos = [newItem].concat(this.todos)

map + 对象展开 → for 循环：

// 改前
this.todos = this.todos.map(item =>
  item.id === id ? { ...item, done: !item.done } : item
)

// 改后
const newTodos: TodoItem[] = []
for (let i = 0; i < this.todos.length; i++) {
  const item = this.todos[i]
  if (item.id === id) {
    newTodos.push({ id: item.id, text: item.text, done: !item.done })
  } else {
    newTodos.push(item)
  }
}
this.todos = newTodos

filter → for 循环 + if：

// 改前
this.todos = this.todos.filter(item => item.id !== id)

// 改后
const newTodos: TodoItem[] = []
for (let i = 0; i < this.todos.length; i++) {
  if (this.todos[i].id !== id) {
    newTodos.push(this.todos[i])
  }
}
this.todos = newTodos

reduce → for 循环：

// 改前
const maxId = this.todos.reduce((max, item) => Math.max(max, item.id), 0)

// 改后
let maxId = 0
for (let i = 0; i < this.todos.length; i++) {
  if (this.todos[i].id > maxId) {
    maxId = this.todos[i].id
  }
}

AI 还主动加了一行注释解释原因：“ArkTS 不支持 map/filter/reduce 等高阶函数，也不支持 ... 展开语法，这是为了保证运行时性能和安全性。”

5.5 第五步：成功运行

修复编译错误后，再次点击 Run。这次一切顺利——Build Output 显示 BUILD SUCCESSFUL，模拟器中出现了计算器界面。

纯黑背景，顶部深灰显示面板，橙色运算符按钮，灰色数字键。和 iOS 计算器的风格非常接近。

我逐一测试了所有功能：

测试操作 预期结果 实际结果
12 + 34 = 46 ✅
100 - 23 = 77 ✅
7 × 8 = 56 ✅
100 ÷ 4 = 25 ✅
5 ÷ 0 = Error ✅
按 C 0 ✅
100 ± -100 ✅
200 % 2 ✅
5 + 3 + 2 = 10 ✅（链式运算）
0.1 + 0.2 = 0.3 ✅（浮点精度）
按 9 连续 20 次 最多 15 位 ✅

全部 11 个测试用例一次性通过，零 Bug。

在这里插入图片描述

5.6 一个插曲：API 版本不匹配

中间还有一个插曲。第一次编译时报了另一个错误——我忘了说 API 版本，AI 默认用了 API 20，但我装的是 API 23。

解决过程：

  1. 我把错误信息贴给 AI（compileSdkVersion 20 not found）
  2. AI 说：“需要改为 API 23”
  3. 我确认：“改吧”
  4. AI 自动修改了 build-profile.json5 和 app.json5 中的版本号
  5. 重新同步，通过

前后不到 1 分钟。

六、AI 编程的高效工作流

这次实战让我总结出一个高效的工作流：

┌─────────────────────────────────────┐
│  你：描述需求 + 项目规范             │
│  AI：生成代码 + 创建 14 个文件       │  ← 3 分钟
├─────────────────────────────────────┤
│  你：在 DevEco Studio 中编译         │
│  你：把错误信息复制给 AI             │  ← 2 分钟
├─────────────────────────────────────┤
│  AI：分析错误原因 + 修改所有问题代码  │  ← 1 分钟
├─────────────────────────────────────┤
│  你：重新编译 → 运行 → 测试          │  ← 5 分钟
├─────────────────────────────────────┤
│  全部通过 ✅                         │
└─────────────────────────────────────┘

七、最终成果

7.1 项目文件清单

Calculator/  （14 个文件）
├── AppScope/app.json5
├── build-profile.json5
├── hvigorfile.ts
├── oh-package.json5
├── entry/
│   ├── hvigorfile.ts
│   ├── oh-package.json5
│   └── src/main/
│       ├── module.json5
│       ├── ets/
│       │   ├── entryability/EntryAbility.ts
│       │   └── pages/Index.ets      ← ⭐ 核心代码
│       └── resources/
│           ├── base/element/string.json
│           ├── base/element/color.json
│           ├── base/profile/main_pages.json
│           ├── en_US/element/string.json
│           └── zh_CN/element/string.json

7.2 实现的功能

功能 实现方式 代码位置
数字输入（0-9） 字符串拼接 + 15 位限制 Index.ets:appendNumber()
小数点 includes(‘.’) 防重复输入 Index.ets:appendDot()
四则运算 switch 分发 + parseFloat 计算 Index.ets:calculate()
链式运算 isNewInput 标志位控制 Index.ets:handleOperator()
清空 C 重置所有状态 Index.ets:clearAll()
取反 ± startsWith(‘-’) 字符串操作 Index.ets:toggleSign()
百分比 % 除以 100 再格式化 Index.ets:percent()
除零保护 curr === 0 提前判断 Index.ets:calculate()
浮点精度 toPrecision(12) + parseFloat Index.ets:formatNumber()
深色主题 纯黑背景 + 橙色/灰色按钮 Index.ets:build()
错误锁定 hasError 标志位拦截非 C 操作 Index.ets:onButtonClick()

八、对 AI 辅助开发的思考

8.1 AI 做得好的地方

  • 生成速度快：3 分钟完成我从零要写 2 小时的项目
  • 代码规范：变量命名、注释、结构分层都比较专业
  • 自动修复：贴错误信息就修，不用手动定位
  • 解释能力：会主动解释为什么这么写，帮助理解

8.2 需要开发者自己做的地方

  • 环境搭建：AI 不能帮你装 IDE、配 SDK、启动模拟器
  • 需求描述：需求越具体，生成质量越高
  • 错误信息收集：需要你把编译错误复制给 AI
  • 功能验收：AI 生成的代码需要人工测试确认
  • 架构决策：选什么模式、怎么分模块，还是人来定

8.3 什么人适合用 AI 编程？

  • ✅ 有一定基础的新手：能看懂代码，但写起来慢
  • ✅ 跨语言开发者：比如从 Android 转到鸿蒙，语法不熟
  • ✅ 原型验证：快速验证一个想法能不能跑通
  • ❌ 完全零基础：看不懂代码的话，AI 报错了你都不知道怎么问

九、总结

这篇文章记录了我用 Reasonix Code 开发鸿蒙计算器的完整过程。从输入需求到生成项目，从编译报错到自动修复，再到模拟器成功运行，全部用时约 20 分钟，测试用例全部通过。

这个过程让我最深刻的感受是：AI 没有替代我写代码，而是让我把精力从"怎么写"转移到了"写什么"上。我不再需要纠结 map 能不能用、... 能不能展开这些语法细节，而是把注意力放在功能设计、用户交互、代码质量这些更重要的地方。

如果你也在学习鸿蒙开发，不妨试试 AI 辅助编程这条路。工具在变，但学习的本质不变——理解每一行代码为什么这么写，才是真正的收获。

# harmonyos # 华为
Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

cover

鸿蒙 + Flutter 下 AI 页面的状态协同设计

avatar HarmonyOS开发者社区
cover

鸿蒙 App 图片加载优化：实现原理 + Demo实现

avatar HarmonyOS开发者社区
cover

【electron开发环境配置】鸿蒙 PC 上做 Electron 开发，到底要装哪些东西？——一份“装完就能 Run“的最短路径指南

avatar HarmonyOS开发者社区