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 没传第三个参数 keyGenerator，ArkTS 默认拿数组下标当 key，数据一变序，key 和内容的对应关系就乱套了。

我那次的具体场景是做了个置顶功能，用户把某个商品拖到最前面，数据层 reorder 之后界面却还是老顺序，点进去看详情还是旧的那条。我盯着模拟器翻来覆去试了十几分钟，才反应过来是 key 在捣鬼。后来给 AI 的规矩就一句话：ForEach 第三个参数必须写，且用稳定唯一 id，绝不能要下标。改完长这样：

ForEach(this.goods,(item:Goods)=>{ListItem(){Text(item.name).fontSize(16)}},(item:Goods):string=>item.id// 关键：稳定唯一 key，别用下标)

你猜怎么着，就这么一行，列表错乱从必现变消失。这坑我在三个项目里复现过，每次都是 AI 偷懒没写 keyGenerator。说白了就是它图省事，反正能编译过它才不管你后面删不删数据。

顺带说一句，鸿蒙的文档对 keyGenerator 讲得其实挺清楚，可 AI 偏偏爱用最省事的写法，你不在 prompt 里点名，它八成不会主动加。

规矩二：class 塞进 @State，光改属性 UI 不刷新，得 @Observed 加 @ObjectLink

AI 特别喜欢这么写：

@Stateitems:CartItem[]=[]// 某个方法里this.items[0].count=this.items[0].count+1

它以为改了数组里的对象，界面就该跟着变。错。ArkTS 的响应式系统盯的是引用有没有换，你拿着老引用改里面的字段，它眼里啥也没发生。@State 只对"赋值"这个动作做响应，直接改items[0].count属于就地改对象属性，框架压根感知不到，UI 纹丝不动。我当初还以为是模拟器没刷新，手滑点了七八次重启才死心。

我承认我一开始也这么写，盯着不动的购物车数字愣了五分钟。上周同事还问我，ArkTS 是不是状态管理有 bug，我跟他说不是 bug，是咱写法不对。正确做法：给 class 加 @Observed，子组件用 @ObjectLink 接，嵌套属性变了才会触发刷新。

等一下，这里我漏说一个前提，@Observed 只对 class 生效，你要是用 interface 定义数据，这套不灵，得先把数据结构改成 class 才行。

@ObservedclassCartItem{count:number=1constructor(publicname:string){}}@Componentstruct CartRow{@ObjectLinkitem:CartItem// 注意，这里不是 @Statebuild(){Row(){Text(this.item.name)Text(`x${this.item.count}`)}}}// 父组件里@Stateitems:CartItem[]=[newCartItem('键盘')]// 现在改属性就能刷新了this.items[0].count+=1

@ObjectLink 拿到的不是副本，是父组件那个被 @Observed 标记对象的引用，所以子组件里改 .count，父组件的数组和别的子组件会一起刷新，这才是它和 @State 最大的区别。

这套组合说出来简单，AI 默认几乎不会主动用 @ObjectLink，得你把它写进规矩里它才记得。我后来养成个习惯，凡是可能改属性的状态对象，一律先想清楚要不要上 @Observed。我特别烦那种"能编译过就行"的敷衍态度，上线之后用户看到的数字不对，锅还是你背。

规矩三：ArkTS 强类型，别让它用 any 和 as 糊弄，给个类型守卫

AI 拿不准类型的时候，最爱甩any或者直接obj as User硬转。ArkTS 开了严格模式，any 直接编译报错，as 强转在运行期还可能埋雷。我有次接口把 id 从 string 改成了 number，AI 强转出来的对象我直接取 .name，跑起来白屏，报错还指向一个八竿子打不着的组件，定位花了快一小时。DevEco Code 的语法 skill 理论上会拦，可我实测它还是会偷偷塞 as，尤其接口返回的数据它懒得判断类型时就来一手强转。

我的规矩就一条：禁止 any，禁止 as，拿不准就写类型守卫。比如接口返回的数据要转成 User：

interfaceUser{id:stringname:string}functionisUser(obj:Object):objisUser{// 守卫内部为拿属性做一次受控转型，外面绝不直接 rawData as Userconsto=objasRecord<string,Object>return'id'ino&&'name'ino&&typeofo['id']==='string'}// 用的时候if(isUser(rawData)){console.info(`拿到用户${rawData.name}`)}else{console.error('数据结构不对，别硬转')}

DevEco Code 其实有 arkts-error-fixes 这个 skill，编译报红了它会主动给解法，可它给的解法经常是“加个 as 让它过去”，而不是从类型上根治。所以类型守卫这招我是逼着它用的，不是它自愿。

你试试让 AI 第一次就写出这个守卫函数，十次里有七八次它还是图省事给你as。所以这条规矩我每次新开会话都会先丢过去，比事后一个个改红色波浪线省事得多。如果让我重来，我第一个鸿蒙项目起就把这三条钉死，而不是一个个坑踩过来才总结。

三条规矩怎么喂给 AI

我现在的习惯是，每个新工程第一次对话，先把这三句拍给它：ForEach 必须带 keyGenerator 且用稳定 id；class 进状态管理要用 @Observed 加 @ObjectLink；禁止 any 和 as，用类型守卫。不是塞进系统提示里，是作为第一条需求发过去，让它这轮就照做。比等它写错再返工舒服太多了。

规矩也不是一成不变，遇到新坑我会往里加，比如后来发现它生成的 @Builder 参数也爱乱用 any，就补了一条进去。

你也在用 DevEco Code 写鸿蒙的话，不妨也试试这几条。你遇到过它生成的代码不刷新的情况吗？欢迎留言聊聊。

顺带一提，雷达鸭鸿蒙版那几个列表页，最早就被 AI 生成的 ForEach 坑过，按上面规矩重写之后才安生。

老三，10 年以上软件开发经验，软件设计师、人工智能应用工程师。平时主要搞鸿蒙应用开发（ArkTS 北向）和 Web 前端，也折腾 AI 自动化。偶尔在 CSDN 写点鸿蒙和 AI 方向的踩坑笔记。

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