AI写鸿蒙UI：10个跑崩8个，剩下2个看运气

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

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

我手头在做的 App「雷达鸭」 正是这次测试的实验田。三个月下来我把 AI 自动补全在主要 UI 编码时直接关了——但 AI 写注释、写单测、写样板路由代码比人快 5 倍这事我天天用。

这篇不是劝退 AI，而是劝你把 AI 用对地方。说起来，

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

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

// AI 生成的版本
@Componentstruct WaterfallCard {
@State item: CardItem = new CardItem
@Builder ItemBuilder {
Column {
Text
Image
}
}
build {
List {
ForEach => {
ListItem {
this.ItemBuilder // ❌ 错误 ：Builder 不能在 ListItem 里直接用
}
})
}
}
}

错误有三：

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

AI 错在哪？它根本不知道 ArkTS 的 UI 框架是「声明式 + 装饰器」的复合体。它把 ArkTS 当成普通 TypeScript 在写——语法上还能过却在运行时直接炸掉。话说回来，

二、手写对照版

// 手写版
@Componentstruct WaterfallCard {
@State @Watch item: CardItem = new CardItem
private dataSource: CardItem =
onItemChange {
// 发起高清图片请求
}
@Builder
private itemCard {
Column {
Text
Image
}
}
build {
List {
ForEach(
this.dataSource。=> item.id.toString,// 显式 key
=> {
ListItem {
this.itemCard // Builder 调用，但传入具体 item
}
}
)
}
}
}

区别一眼就能看出来：

• 显式提供 防止状态丢失；
• @Watch 捕获数据变更并触发业务逻辑；

If you copy‑paste AI version directly into a project,it not crashing is pure luck.

三、为什么 ArkTS 特殊？按理说，训练数据太少导致「成功率仅20%」的根本原因

I searched Hugging Face – open‑source 鸿蒙 ArkTS 仓库数量只有 React 的 <1% 和 TypeScript 的 <5%. 那么训练数据几乎为零。AI 根本没有看到足够的「正确例子」。更糟的是ArkTS 是一个"装饰器 + 状态 + 渲染" 三件套强耦合语言。

@State、@Prop、@Link、@Builder、@Extend、@Styles 等装饰器之间的组合规则只在官方文档里列出，却缺少完整示例。从于是来看，

• Ai 看不到这些细节 → 随意组合 → 编译通过但运行时崩溃。
• Ai 在 Vue/React 上表现好，是因为对应代码在 GitHub 上已有海量样本。怎么说呢，

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

1. . 写 JSDoc 注释

/**
* AI 自动生成的注释
* @param id 案例唯一标识
* @returns 案例详情对象。未找到时返回 null
*/
async function fetchCaseDetail: Promise { ... }

Ai 完成一次只需要几秒，我手写要几分钟。

2. . 写单测模板

// AI 输出的单测骨架
describe => {
it => {
const result = await fetchCaseDetail
expect.toMatchObject
})
it => {
const result = await fetchCaseDetail
expect.toBeNull
})
})

You only need to填充业务断言 → 效率提高约 x5~x10.

3. . 写样板路由 / 配置文件

// 示例：批量注册 router
const routes = pages.map(page => ({
从name来看。page.name,path: `/${page.name}`,component: => import
}));话说回来，export default routes;

This kind of纯粹文字拼接工作是 AI 的强项，一行代码搞定数十行手敲。

五、我的 AI 协作「三区法则」——把有限时间投入到最有价值的决策活上

The split looks like:

• "绿黄红工作量占比大约是 60% / 30% / 10%"*.
• Ai 看似只完成了约 %15–20 的代码行数，但这些都是最不费脑力却耗时最长的重复劳动 → 实际节省约 *4–6 小时/天*.

六、最终给你一个判断标准——别让AI踩进致命坑！

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

• If **YES** → 把它交给 AI。即使出错，也能快速回滚或修正。
• If **NO** → 自己撸代码。是涉及状态依赖或跨页面交互的主要模块。

The reason is simple:

• Crashed core UI components can cost you **半天以上** debugging time.
• The “机械活” you outsource to AI saves that time entirely.
• The “决策活” you keep in hand prevents “20% 成功率”带来的项目延期风险。

This rule comes from three months of real‑project experience—no silver bullet,but it can cut your “踩坑率” by **≈80%**.

快来留言聊聊！说起来，

If you’ve let AI write ArkTS code before。which part crashed?Which part saved you hours?Share your story below.

关于作者： 十年以上软件开发老兵。软件设计师 + 注册人工智能工程师 + agent 工程师，主要从事鸿蒙 ArkTS 北向开发与 Web 前端。话说回来，近期专注于 AI 自动化提效。不定期在 CSDN 分享鸿蒙 / AI 实战笔记。

这篇文章遵循 MIT 协议，转载请注明出处。

\ <\/blockquote>