DevEco Code 这工具我小半年前就开始拿它写鸿蒙越用越觉得它最值钱的那块不是补全是 Build 模式能把描述需求、生成 .ets、编译、推真机一条龙串起来。你对着它说一句新建个登录页它真能把代码写完还顺手帮你 build 出来第一次跑通那个 demo 的时候我确实有点惊着。可你要是放手让它自由发挥写 ArkTS三天里准撞上几个它反复犯的同款错误现实反手就是一巴掌。我头一回信它不信邪让它一口气给我生成整个设置页编译过了跑起来列表乱跳、状态还不更新。我一开始以为是真机抽风折腾半天才反应过来是 AI 写出来的代码本身有问题。那次之后我学乖了凡是要让 AI 写 ArkTS我先在脑子里过一遍它最容易翻车的几个点。后来发现翻来覆去就那三件事干脆固化成规矩每次新工程开头先拍给它。说白了通用大模型写 ArkTS 有先天短板。它训练数据里鸿蒙的样本本来就少又爱把 TypeScript 和 React 的肌肉记忆搬过来。DevEco Code 内置的 arkts-grammar-standards 这类 skill 会拦一部分可真到复杂点的页面该翻车还是翻车。我躺过的坑比你想象的多后来干脆给它立了三条冷门规矩效果比反复改 prompt 强太多。规矩一ForEach 的 keyGenerator 必须显式写死别信 AI 的默认用 index你让 AI给我来个商品列表它十有八九给你这么一段ForEach(this.goods,(item:Goods){ListItem(){Text(item.name)}})这段代码能跑可一旦你做删除、置顶或者后端返回顺序变了列表就开始抽风。明明数据删了界面还留着旧的那条或者点 A 项展开B 项跟着展开。根因是 AI 没传第三个参数 keyGeneratorArkTS 默认拿数组下标当 key数据一变序key 和内容的对应关系就乱套了。我那次的具体场景是做了个置顶功能用户把某个商品拖到最前面数据层 reorder 之后界面却还是老顺序点进去看详情还是旧的那条。我盯着模拟器翻来覆去试了十几分钟才反应过来是 key 在捣鬼。后来给 AI 的规矩就一句话ForEach 第三个参数必须写且用稳定唯一 id绝不能要下标。改完长这样ForEach(this.goods,(item:Goods){ListItem(){Text(item.name).fontSize(16)}},(item:Goods):stringitem.id// 关键稳定唯一 key别用下标)你猜怎么着就这么一行列表错乱从必现变消失。这坑我在三个项目里复现过每次都是 AI 偷懒没写 keyGenerator。说白了就是它图省事反正能编译过它才不管你后面删不删数据。顺带说一句鸿蒙的文档对 keyGenerator 讲得其实挺清楚可 AI 偏偏爱用最省事的写法你不在 prompt 里点名它八成不会主动加。规矩二class 塞进 State光改属性 UI 不刷新得 Observed 加 ObjectLinkAI 特别喜欢这么写Stateitems:CartItem[][]// 某个方法里this.items[0].countthis.items[0].count1它以为改了数组里的对象界面就该跟着变。错。ArkTS 的响应式系统盯的是引用有没有换你拿着老引用改里面的字段它眼里啥也没发生。State 只对赋值这个动作做响应直接改items[0].count属于就地改对象属性框架压根感知不到UI 纹丝不动。我当初还以为是模拟器没刷新手滑点了七八次重启才死心。我承认我一开始也这么写盯着不动的购物车数字愣了五分钟。上周同事还问我ArkTS 是不是状态管理有 bug我跟他说不是 bug是咱写法不对。正确做法给 class 加 Observed子组件用 ObjectLink 接嵌套属性变了才会触发刷新。等一下这里我漏说一个前提Observed 只对 class 生效你要是用 interface 定义数据这套不灵得先把数据结构改成 class 才行。ObservedclassCartItem{count:number1constructor(publicname:string){}}Componentstruct CartRow{ObjectLinkitem:CartItem// 注意这里不是 Statebuild(){Row(){Text(this.item.name)Text(x${this.item.count})}}}// 父组件里Stateitems:CartItem[][newCartItem(键盘)]// 现在改属性就能刷新了this.items[0].count1ObjectLink 拿到的不是副本是父组件那个被 Observed 标记对象的引用所以子组件里改 .count父组件的数组和别的子组件会一起刷新这才是它和 State 最大的区别。这套组合说出来简单AI 默认几乎不会主动用 ObjectLink得你把它写进规矩里它才记得。我后来养成个习惯凡是可能改属性的状态对象一律先想清楚要不要上 Observed。我特别烦那种能编译过就行的敷衍态度上线之后用户看到的数字不对锅还是你背。规矩三ArkTS 强类型别让它用 any 和 as 糊弄给个类型守卫AI 拿不准类型的时候最爱甩any或者直接obj as User硬转。ArkTS 开了严格模式any 直接编译报错as 强转在运行期还可能埋雷。我有次接口把 id 从 string 改成了 numberAI 强转出来的对象我直接取 .name跑起来白屏报错还指向一个八竿子打不着的组件定位花了快一小时。DevEco Code 的语法 skill 理论上会拦可我实测它还是会偷偷塞 as尤其接口返回的数据它懒得判断类型时就来一手强转。我的规矩就一条禁止 any禁止 as拿不准就写类型守卫。比如接口返回的数据要转成 UserinterfaceUser{id:stringname:string}functionisUser(obj:Object):objisUser{// 守卫内部为拿属性做一次受控转型外面绝不直接 rawData as UserconstoobjasRecordstring,Objectreturnidinonameinotypeofo[id]string}// 用的时候if(isUser(rawData)){console.info(拿到用户${rawData.name})}else{console.error(数据结构不对别硬转)}DevEco Code 其实有 arkts-error-fixes 这个 skill编译报红了它会主动给解法可它给的解法经常是“加个 as 让它过去”而不是从类型上根治。所以类型守卫这招我是逼着它用的不是它自愿。你试试让 AI 第一次就写出这个守卫函数十次里有七八次它还是图省事给你as。所以这条规矩我每次新开会话都会先丢过去比事后一个个改红色波浪线省事得多。如果让我重来我第一个鸿蒙项目起就把这三条钉死而不是一个个坑踩过来才总结。三条规矩怎么喂给 AI我现在的习惯是每个新工程第一次对话先把这三句拍给它ForEach 必须带 keyGenerator 且用稳定 idclass 进状态管理要用 Observed 加 ObjectLink禁止 any 和 as用类型守卫。不是塞进系统提示里是作为第一条需求发过去让它这轮就照做。比等它写错再返工舒服太多了。规矩也不是一成不变遇到新坑我会往里加比如后来发现它生成的 Builder 参数也爱乱用 any就补了一条进去。你也在用 DevEco Code 写鸿蒙的话不妨也试试这几条。你遇到过它生成的代码不刷新的情况吗欢迎留言聊聊。顺带一提雷达鸭鸿蒙版那几个列表页最早就被 AI 生成的 ForEach 坑过按上面规矩重写之后才安生。老三10 年以上软件开发经验软件设计师、人工智能应用工程师。平时主要搞鸿蒙应用开发ArkTS 北向和 Web 前端也折腾 AI 自动化。偶尔在 CSDN 写点鸿蒙和 AI 方向的踩坑笔记。本文遵循 MIT 协议转载请注明出处。