先扔结论如果你现在把 Claude 或 Cursor 当成 ArkTS 专家来用大概率会掉坑里。我上周闲得慌跑了 37 个常见开发场景的测试结果 AI 生成的代码能直接编译通过的不到四成。剩下的要么语法错误要么用了废弃 API要么逻辑能跑但性能稀烂。你可能会说“我也用 AI 写过 ArkTS感觉还行啊” —— 那是因为你写的多半是 UI 布局。一旦涉及到状态管理、生命周期或者并发模型AI 的幻觉率直线飙升。测试怎么做的说一下我的测试方法你也可以复现。我选了 7 个 ArkTS 开发里最高频的场景每个场景设计 3-5 个不同难度的需求分别丢给 Claude 3.7 Sonnet、Cursor Composer 和某国产大模型名字就不点了。提示词刻意写得很模糊模拟真实开发里哎帮我把这个功能写了的场景不额外补充上下文。七个场景分别是UI 布局与自定义组件State / Prop / Provide 状态管理生命周期aboutToAppear / aboutToDisappear / onPageShow网络请求与错误处理并发模型TaskPool / Worker / Promise动画与手势交互文件读写与沙箱路径每个场景我按通过标准给了三档评分✅ 直接能用编译通过、逻辑正确、没踩废弃 API⚠️ 能修大体对但有小错误比如类型声明漏了、参数写反了❌ 翻车编译都过不了或者用了根本不存在的方法结果汇总出来是这样的场景ClaudeCursor国产模型UI 布局✅ 4/5✅ 5/5✅ 3/5状态管理⚠️ 2/5⚠️ 3/5❌ 1/5生命周期❌ 1/5⚠️ 2/5❌ 0/5网络请求⚠️ 3/5✅ 4/5⚠️ 2/5并发模型❌ 1/5❌ 2/5❌ 0/5动画手势⚠️ 2/5⚠️ 3/5❌ 1/5文件读写⚠️ 3/5✅ 4/5⚠️ 2/5你看UI 布局和文件 IO 这类模板化程度高的AI 表现还行。但一旦碰到状态管理和并发三个模型集体翻车。最离谱的是生命周期那栏——Claude 有两次把aboutToAppear写成了onLoad这不是鸿蒙的 API这是 Vue 的习惯带进来了。翻车现场状态管理来看个具体的。我让 AI 写一个父子组件双向同步状态的例子要求子组件修改数据后父组件实时更新。Claude 给我的代码长这样// 子组件 Child.etsComponentstruct Child{Propvalue:numberEventonChange:(v:number)voidbuild(){Button().onClick((){this.onChange(this.value1)})}}你一眼能看出来问题吗Event这个装饰器在 ArkTS 里根本不存在。鸿蒙用的是Event吗不它用的是回调函数传参的方式或者Link/ObjectLink做双向绑定。Claude 这是把 SwiftUI 或者 Vue 的概念混进来了。正确的写法应该是// 子组件 Child.etsComponentstruct Child{Linkvalue:numberbuild(){Button().onClick((){this.value1// 直接修改父组件同步更新})}}// 父组件 Parent.etsEntryComponentstruct Parent{Statecount:number0build(){Column(){Text(当前值:${this.count})Child({value:$count})// $语法建立Link绑定}}}这个$count的语法新手本来就容易忘AI 不仅没帮你还给你造了个Event装饰器让你更晕。顺便说一句Claude 在被我指出错误后的回复是“抱歉我混淆了 ArkTS 和 ArkUI-X 的语法。” —— 你看它连承认自己 hallucinate 的时候都在 hallucinate因为 ArkUI-X 也没有Event这个鬼东西。翻车现场并发模型再说一个更劝退的。我让 AI 写一个后台线程处理图片压缩的任务要求不阻塞 UI。Cursor 给我的方案是importworkerfromohos.workerfunctioncompressImage(path:string):Promisestring{returnnewPromise((resolve){constwnewworker.ThreadWorker(entry/ets/workers/ImageWorker.ets)w.postMessage({path})w.onmessage(e){resolve(e.data.outputPath)w.terminate()}})}这段代码乍一看挺像回事对吧但问题太多了。第一worker.ThreadWorker在 HarmonyOS Next 里路径已经变了应该是kit.ArkTS或者ohos.worker下的ThreadWorker但构造参数格式不对。第二onmessage的写法是旧版 API新版本用的是on(message, callback)。第三也是最隐蔽的 —— 它居然在 Promise 里直接resolve后就terminate()如果 worker 还没执行完整个线程被杀了Promise 永远挂在那。实际上 ArkTS 里图片压缩更推荐用TaskPool而不是直接操作 Workerimport{taskpool}fromkit.ArkTSConcurrentfunctioncompressTask(srcPath:string,quality:number):string{// 实际的压缩逻辑运行在后台线程constdestPathgetContext().cacheDir/compressed_Date.now().jpg// ... imageKit 压缩调用returndestPath}asyncfunctioncompressImage(path:string):Promisestring{consttasknewtaskpool.Task(compressTask,path,85)returnawaittaskpool.execute(task)asstring}AI 没推荐TaskPool是因为它训练数据里关于 HarmonyOS Next 的资料太少了。2024 年之前的文档主要讲的是 WorkerTaskPool 是后来推的AI 的 “知识” 还停留在旧版本。那 AI 完全不能用吗也不是。有两个场景我反而建议你让 AI 代劳一是纯 UI 布局。你要写一个复杂的 Grid 或者 ListAI 生成的代码基本能跑。它可能会把ListItem的嵌套层级搞得多一点但你调调就行了比自己从零写快。二是类型定义和接口。你给 AI 一份 JSON 样例让它生成对应的 ArkTS interface这个准确率很高。至少比手写快而且不容易漏字段。// 这种活丢给 AI省时间interfaceApiResponse{code:numberdata:UserInfo message:string}interfaceUserInfo{uid:stringnickname:stringavatarUrl:stringvipLevel:numbercreatedAt:number}但记住一个原则凡是涉及到 “运行时行为” 的代码 —— 状态什么时候刷新、页面什么时候销毁、异步任务怎么调度 —— 你都别信 AI。它对这些的理解大概是 “看过文档但没写过项目” 的水平。一个小技巧如果你非要用 AI 写 ArkTS我的建议是别问怎么写问这样写对不对。比如你已经写了一个State的组件不确定父子传参有没有问题把代码贴给 AI让它 review。这种 “纠错模式” 比 “生成模式” 准确率高得多因为 AI 做判断比做创造要靠谱。还有一个招在提示词里强制加上 “使用 HarmonyOS Next API 11 的语法”。虽然不一定完全管用但至少能降低它给你返回 2023 年废弃代码的概率。反正我测完这 37 个案例之后再写 ArkTS 的时候AI 帮我写的代码我都会本能地先扫一眼装饰器用得对不对。这习惯挺好就是有点心累。你平时用 AI 写鸿蒙代码吗翻车最狠的一次是什么时候本文遵循 MIT 协议转载请注明出处。