我用 Cursor 写了 3 个月 ArkTS 代码，结论是：AI 写鸿蒙核心 UI 一个能打的都没有

先把结论扔出来，省得你翻半天：

让 AI 写 ArkTS 的核心 UI 组件，10 个里面 8 个跑不起来。剩下 2 个里面还有 1 个会在真机上崩溃。

我手头在做的 App 雷达鸭（鸿蒙版）就是这个测试场。三个月下来，我把 AI 自动补全在核心 UI 编码时直接关了——但 AI 写注释、写单测、写样板路由代码比人快 3 倍，这事我天天用。

这篇不是劝退 AI，是劝你把 AI 用对地方。

一、AI 写 ArkTS 组件最常翻车的三个地方

我把 AI 写错的代码攒了一堆，按错误类型分了三档。看下面这段 AI 生成的「瀑布流卡片组件」，你猜错在哪：

// AI 生成的版本（看起来没问题，跑起来崩）@Componentstruct WaterfallCard {  @State item: CardItem = new CardItem()  @Builder ItemBuilder() {    Column() {      Text(this.item.title)      Image(this.item.cover)    }  }  build() {    List({ space: 10 }) {      ForEach(this.dataSource, (item: CardItem) => {        ListItem() {          this.ItemBuilder()  // ❌ 错误 1：Builder 不能在 ListItem 里直接用        }      })    }  }}

错误有三：

1. Builder
    装饰器的方法不能直接作为组件在 ListItem 里实例化，必须用 if/else 或独立组件包裹。
2. ForEach
    没传第三个参数 (item, index) => key——鸿蒙的 ForEach 第二个参数允许省略 key，但省略后无法触发 UI 刷新，这是个隐性 bug。
3. @State item
    应该是 @State @Watch('onItemChange') item，但 AI 不知道我需要监听 item 变化去请求图片清晰度。

AI 错在哪？它不知道 ArkTS 的 UI 框架是声明式 + 装饰器的复合体。它把 ArkTS 当成普通的 TypeScript 在写，语法上过得去，运行时就崩。

二、我手写的对照版本

// 手写版@Componentstruct WaterfallCard {  @State @Watch('onItemChange') item: CardItem = new CardItem()  private dataSource: CardItem[] = []  onItemChange() {    // 触发图片高清请求  }  @Builder  private itemCard(item: CardItem) {    Column() {      Text(item.title)      Image(item.cover)    }  }  build() {    List({ space: 10 }) {      ForEach(        this.dataSource,        (item: CardItem) => item.id.toString(),  // 显式 key        (item: CardItem) => {          ListItem() {            this.itemCard(item)  // Builder 调用，但参数是 item          }        }      )    }  }}

区别一眼就能看出来：关键差异不在「能不能写出来」，在「为什么这么写」。AI 没有项目上下文，不知道 onItemChange 要请求高清图，不知道 key 缺失会丢状态。

你要是把 AI 的版本直接复制粘贴进项目，跑起来没崩算你运气好。

三、为什么 ArkTS 这么特殊？训练数据少

我去 Hugging Face 搜过，开源鸿蒙 ArkTS 代码仓库数量大约是 React 的 1/200，TypeScript 的 1/500。AI 学都没学过几个，怎么写得对？

更麻烦的是，ArkTS 是个装饰器 + 状态 + 渲染三件套强耦合的语言。@State、@Prop、@Link、@Builder、@Extend、@Styles 这些装饰器互相之间的组合规则，文档里有，但代码示例不够。AI 写错不是它笨，是真没见过几个对的例子。

这也解释了为什么 Vue、React 的 AI 生成质量高很多——这几个框架的代码在 GitHub 上是海量。

四、AI 真正擅长的是这三件事

说了这么多 AI 不行的，但 AI 在雷达鸭项目里我天天用，主要在三个地方：

1. 写 JSDoc 注释

/** * AI 生成的注释（30 秒） * @param id 案例唯一标识 * @returns 案例详情对象，未找到时返回 null */async function fetchCaseDetail(id: string): Promise<CaseDetail | null> { ... }

这种纯模板化的注释 AI 写得又快又准。我手写要 1 分钟，AI 30 秒。

2. 写单测模板

// AI 生成的单测骨架describe('fetchCaseDetail', () => {  it('should return detail when id exists', async () => {    const result = await fetchCaseDetail('valid_id')    expect(result).toMatchObject({ id: 'valid_id' })  })  it('should return null when id not found', async () => {    const result = await fetchCaseDetail('invalid')    expect(result).toBeNull()  })})

骨架给出来后，我再补充业务断言。这比自己从零写快 3 倍。

3. 写样板路由/配置

比如 router 的批量注册、.hvigorfile.ts 的 build 脚本、.app.json 的页面声明——这种纯字符串拼接的活，AI 是碾压式的。

五、我现在的 AI 协作三区法则

我把自己写代码的状态分了三类：

绿区 AI 全权代理，黄区我写框架 AI 补细节，红区 AI 闭嘴我自己来。

三个月下来，绿黄红的工作量占比大约是 4:4:2。AI 看似只干了 40% 的活，但这 40% 是最不费脑的——相当于把每天 2 小时的重复劳动外包出去。

六、最后给你一个判断标准

下次你让 AI 写 ArkTS 代码，先问自己一个问题：

这段代码，AI 如果写错了，我能在 5 分钟内看出来吗？

能看出来，交给 AI。看不出来，自己撸。

核心 UI 组件的 bug 我可能要调半天，这种活绝不让 AI 碰。但工具函数、注释、单测——错了也不致命，AI 写得快就让它写。

这是我从三个月真实项目里总结出来的判断标准，没有银弹，但能让你少踩 80% 的坑。

你用 AI 写 ArkTS 时翻过车吗？是哪类代码？留言聊聊。

关于作者：十年以上软件开发老兵，软件设计师 + 注册人工智能工程师 + agent 工程师，主要写鸿蒙 ArkTS 北向开发和 Web 前端，最近在折腾 AI 自动化提效。不定期在 CSDN 分享一些鸿蒙 / AI 方向的实战笔记。

本文遵循 MIT 协议，转载请注明出处。