DevEco Code vs Cursor谁才是ArkTS王者先甩结论DevEco Code、Cursor、GitHub Copilot 三款 AI 工具写鸿蒙代码我只留了一个。被踢掉的那个你可能猜不到。HDC2026 刚结束不到一周华为发布了 DevEco Code 和 DevEco CLI。定位很清楚——懂鸿蒙的 AI 编程助手。你说我一个用 Cursor 写了大半年 ArkTS 的人能不心动吗测试需求一个下拉刷新列表页选这个场景是有原因的。ArkTS 里Refresh组件和List组件的组合写法是 AI 工具最容易出现看着对但跑不起来的重灾区。你要是写过鸿蒙肯定知道这个组合有多坑——API 12 之前和之后写法还不一样。三款工具用的同一个 prompt用 ArkTS 写一个下拉刷新列表页使用 Refresh List 组件 支持下拉刷新数据模拟 2 秒延迟和上拉加载更多。 数据项包含 title 和 subtitle 两个字段展示为卡片样式。Copilot第一个出局的GitHub Copilot 给我的第一版代码长这样EntryComponentstruct RefreshList{Stateitems:string[][]Staterefreshing:booleanfalsebuild(){Refresh({refreshing:$$this.refreshing}){List(){ForEach(this.items,(item:string){ListItem(){Text(item)}})}}.onRefresh((){this.loadData()})}}$$this.refreshingArkTS 里压根没这个语法。这明显是 React 双向绑定的思路硬搬过来的。而且Refresh组件在 API 12 里的用法根本不是这样的——refreshing参数从构造函数里移出去了改成属性方法。等一下这里我漏说一个前提。我文件后缀是.ets理论上 Copilot 应该能从上下文推断出这是鸿蒙代码。但显然它的训练数据里 ArkTS 的样本少得可怜。我又试了两轮——加了HarmonyOS ArkTS关键词、把官方文档示例贴进上下文——Copilot 依然在用 React 的思路写鸿蒙。第三次翻车后我直接关了不再浪费时间。DevEco Code语法没毛病就是太能写了DevEco Code 生成的代码语法层面确实比 Copilot 靠谱很多interfaceItemData{title:stringsubtitle:string}constmockData:ItemData[]Array.from({length:30},(_,i)({title:标题${i1},subtitle:这是第${i1}条数据的描述信息}))EntryComponentstruct RefreshList{StateisRefreshing:booleanfalseStateisLoadingMore:booleanfalseStateitems:ArrayItemData[]StatepageIndex:number1StatehasMore:booleantrueStaterefreshStatus:RefreshStatusRefreshStatus.IdleStatelastRefreshTime:stringStateerrorMessage:stringStateretryCount:number0aboutToAppear(){this.loadData()}asyncloadData(){this.isRefreshingtruetry{awaitnewPromisevoid((resolve)setTimeout(resolve,2000))this.itemsmockData.slice(0,10)this.pageIndex1this.hasMoretrue}catch(error){this.errorMessage加载失败}finally{this.isRefreshingfalse}}asyncloadMore(){if(this.isLoadingMore||!this.hasMore)returnthis.isLoadingMoretruetry{awaitnewPromisevoid((resolve)setTimeout(resolve,1000))conststartthis.items.lengthconstnewDatamockData.slice(start,start10)this.items[...this.items,...newData]this.pageIndexif(newData.length10){this.hasMorefalse}}catch(error){this.errorMessage加载更多失败}finally{this.isLoadingMorefalse}}build(){Column(){Refresh(){List({space:12}){ForEach(this.items,(item:ItemData){ListItem(){Column(){Text(item.title).fontSize(16).fontWeight(FontWeight.Bold)Text(item.subtitle).fontSize(14).fontColor(#666666).margin({top:4})}.padding(16).backgroundColor(#FFFFFF).borderRadius(8).width(100%)}},(item:ItemData)item.title)}.width(100%).layoutWeight(1)}.refreshing(this.isRefreshing).onRefresh((){this.loadData()})}.width(100%).height(100%)}}你看出来了吧接近 100 行代码功能齐全编译也能过。但我只要一个下拉刷新列表页它给我整了一套错误处理 重试机制 分页状态管理。retryCountlastRefreshTimeerrorMessage我一个都没让它写。说白了DevEco Code 的毛病跟大部分懂框架的 AI 工具一样——它觉得给你写得越多越负责。但你只是想快速出个原型200 行模板代码反而增加阅读成本。我砍掉多余的状态和逻辑只留核心功能大概 45 行interfaceItemData{title:stringsubtitle:string}constmockData:ItemData[]Array.from({length:30},(_,i)({title:标题${i1},subtitle:这是第${i1}条数据的描述信息}))EntryComponentstruct RefreshList{StateisRefreshing:booleanfalseStateisLoadingMore:booleanfalseStateitems:ArrayItemData[]StatehasMore:booleantrueaboutToAppear(){this.itemsmockData.slice(0,10)}build(){Refresh(){List({space:12}){ForEach(this.items,(item:ItemData){ListItem(){Column(){Text(item.title).fontSize(16).fontWeight(FontWeight.Bold)Text(item.subtitle).fontSize(14).fontColor(#666666).margin({top:4})}.padding(16).backgroundColor(#FFFFFF).borderRadius(8).width(100%)}},(item:ItemData)item.title)}.width(100%).layoutWeight(1)}.refreshing(this.isRefreshing).onRefresh((){this.isRefreshingtruesetTimeout((){this.itemsmockData.slice(0,10)this.hasMoretruethis.isRefreshingfalse},2000)}).width(100%).height(100%)}}等一下——精简版里我漏了上拉加载。算了不加了这篇文章的重点不是教你怎么写完整列表页是对比 AI 工具。上拉加载逻辑你照着下拉刷新的思路自己加就行。Cursor偶尔幻觉但改起来最快Cursor 的第一版代码比 Copilot 靠谱但比 DevEco Code 轻量。它踩的坑是另一个方向——API 版本混淆。它给我生成的Refresh组件写法是这样的Refresh({refreshing:this.isRefreshing}){List(){// ...}}.onRefresh((){this.loadData()})如果你在 API 11 及以下版本这种构造函数传参的写法是对的。但 API 12 改成了属性方法.refreshing()构造函数里不再接受refreshing参数。Cursor 的训练数据里两种写法都有它随机挑了一个——恰好挑了个旧的。但我选 Cursor 的理由很简单你告诉它一次它第二次就改对了。不像 DevEco Code你让它删掉retryCount它改了但errorMessage的引用还留着你得再改一轮。代码越冗余迭代成本越高。我手头在做的一个 App 叫雷达鸭它的分类列表页就是用 Cursor 写的初版然后我手动改了Refresh和List的嵌套方式。从开写到编译通过大概 40 分钟Cursor 帮我省了至少 20 分钟的模板代码。我留了哪个Cursor。但它不是万能的。如果你的情况是我完全不懂 ArkTS想靠 AI 全自动生成那目前三款工具都不够格。DevEco Code 最接近能跑但你得花时间砍掉过度生成的部分。如果你对 ArkTS 有基本了解只是想让 AI 帮你省掉写模板代码的时间Cursor 目前迭代效率最高——前提是你得随时盯着它的 API 版本。至于 DevEco Code它有一个场景确实比 Cursor 强你需要查鸿蒙某个组件的最新用法时。毕竟它是专门喂了鸿蒙文档的。写代码还在努力。查文档比谁都快。你平时用哪款 AI 写鸿蒙代码有没有踩过类似的坑关于作者老三10 年软件开发老兵软件设计师注册人工智能工程师agent 工程师。专注鸿蒙 ArkTS 北向开发和 Web 前端偶尔折腾 AI 自动化不定期在 CSDN 分享技术文章。本文遵循 MIT 协议转载请注明出处。