我拿 15 个鸿蒙真机 crash 测了三种 AI，修复率最高的不是你以为的那个

你有没有遇到过这种场景——鸿蒙真机突然 crash，打开 DevEco Studio 看日志，一堆 arkui 日志刷屏，你盯着那行FATAL EXCEPTION发呆，脑子里只有一个想法：“这到底是哪个组件炸了？”

我最近就碰了一连串这种事。上架后的头两周，用户反馈的 crash 报告堆了 20 多条，类型五花八门——列表滚动闪退、弹窗关闭后白屏、网络切换后状态丢失……当时我一边修 bug 一边琢磨：要是让 AI 来修，能比我快吗？

于是我做了一个不太严谨但挺有意思的实验——拿 15 个真实 crash，喂给三种"修 bug 工具"，看谁修得多、修得快。

实验怎么做的

我从 crash 日志里挑了 15 个，按类型分三组：

三种"工具"分别是：

1. DevEco CodeGenie——华为官方 AI 助手，集成在 DevEco Studio 里
2. Cursor——通用 AI IDE，我日常写代码用的
3. 我本人——纯手工，靠经验 + 日志 + 文档

给每个工具同样的输入：crash 日志 + 出问题的源码片段 + 页面上下文描述。计时从开始分析到真机验证通过为止。

等一下，这里我漏说一个前提——"验证通过"的标准是真机跑 5 分钟不 crash，不是模拟器上点两下就 OK。模拟器不炸不代表真机不炸，这坑我躺过不止一次。

下面这段代码就是其中一个典型的状态管理类 crash——@Watch 同帧赋值丢中间值：

// crash 场景：列表页搜索框输入时，连续赋值 searchKeyword// 用户打字速度快的场景下，同帧两次赋值只触发一次 @Watch 回调@Entry@Componentstruct SearchPage{@StatesearchKeyword:string=''@Watch('onKeywordChanged')onKeywordChanged(oldVal:string,newVal:string){// 看似每次赋值都触发，实际同帧只触发一次// oldVal 是第一次赋值前的值，newVal 是同一帧赋值完成后的终值this.fetchSearchResults(newVal)}build(){Column(){TextInput({text:this.searchKeyword}).onChange((value:string)=>{this.searchKeyword=value// 用户连续输入时，中间值全部丢失})}}}

Cursor 给的修复方案是加setTimeout防抖——Web 上管用，鸿蒙上没用。CodeGenie 的方案是"在 onChange 里手动调用 fetchSearchResults"，绕过了 @Watch，但这等于把状态监听和业务逻辑耦合在一起，我觉得这方案不算修复，算回避。

我自己的修法：拆一个@State debounceKeyword做缓冲，用aboutToAppear里注册定时器做真防抖：

// 修复版：独立缓冲字段 + 定时器防抖@Entry@Componentstruct SearchPage{@StatesearchKeyword:string=''@StatedebounceKeyword:string=''privatedebounceTimer:number=-1aboutToAppear(){// 初始化时同步一次this.debounceKeyword=this.searchKeyword}aboutToDisappear(){if(this.debounceTimer!==-1){clearTimeout(this.debounceTimer)}}build(){Column(){TextInput({text:this.searchKeyword}).onChange((value:string)=>{this.searchKeyword=value// 真防抖：300ms 后同步到 debounceKeyword，触发列表刷新if(this.debounceTimer!==-1)clearTimeout(this.debounceTimer)this.debounceTimer=setTimeout(()=>{this.debounceKeyword=value},300)// 列表监听 debounceKeyword 而不是 searchKeywordCaseList({keyword:this.debounceKeyword})}}}

这修改真机验证通过了。5 分钟连打 200 次，没有一次 crash。

数据说话

你可能觉得华为自家的 CodeGenie 对鸿蒙 bug 应该最懂——毕竟它吃的是鸿蒙官方文档和 API 变更记录。但修复率最低的就是它，53%。Cursor 反而拿了 67%。

这结果跟我预想的不一样。我一开始觉得 CodeGenie 肯定碾压 Cursor，结果被数据打脸了。仔细看发现 CodeGenie 有个明显的短板：它对 @Watch 和 @Link 这类状态管理问题的理解停在"文档层面"。文档写的是"赋值触发回调"，实际同帧多次赋值只触发一次，它没考虑到，给出的方案经常是"再赋一次值确保触发"——在鸿蒙上纯属无效操作。

Cursor 好一点，但也好得不多。我的项目里 .cursorrules 写了 8 条禁令，它遵守得还行：

# .cursorrules 片段（鸿蒙项目专用）-禁止使用 Router 做页面跳转，只用 Navigation + NavPathStack-禁止 @State 传整个对象，必须用 @ObjectLink + @Observed 拆分-禁止 LazyForEach 的 keyGenerator 用 index.toString()-禁止在 build() 中写超过 30 行逻辑，必须拆成 @Builder-禁止 @Watch 回调里直接做异步请求，必须用防抖缓冲-禁止 async 函数中直接赋值 @State 依赖项-禁止 @CustomDialog，用普通 @Component + visibility 替代-禁止在组件 aboutToDisappear 中做 setState 类操作

碰到状态管理类 bug，Cursor 至少不会给出违反禁令的方案。但网络/异步类它只修了 3 个——鸿蒙的 async 函数里 @State 赋值有个时序问题，赋值发生在 render tick 结算前，导致视图更新不及时。Cursor 加setTimeout，这招在 Web 上管用，鸿蒙上没用。

我本人修复率最高，87%，没什么好吹的——这些 crash 大半是我自己代码搞出来的，我能不熟吗。但耗时是硬伤，平均 18 分钟一个 bug，那天从上午十点干到下午五点。

每种工具擅长什么

拆开看比较有意思：

UI 渲染类：三者差不多，Cursor 和我 4/5，CodeGenie 3/5。LazyForEach key 冲突这种问题 AI 修得挺快，因为模式固定——换 key、加 aboutToReuse 清理就行。但有个 crash 是组件嵌套太深导致渲染栈溢出，CodeGenie 给的方案是"减少嵌套层级"，这建议等于说"别写太多代码"，我看着就烦。

状态管理类：这是拉开差距的地方。我全修了，Cursor 3/5，CodeGenie 只有 2/5。说白了，鸿蒙的状态管理有大量"文档没写但真实存在"的行为，靠喂文档解决不了，得靠踩坑经验。

网络/异步类：CodeGenie 和 Cursor 都是 3/5，我 4/5。这类 bug 定位不难，难点在鸿蒙异步时序跟 Web 不一样。AI 工具习惯套 Web 方案过来，在鸿蒙上水土不服。举个具体例子——Promise reject 未 catch 导致白屏，这 bug 在 Web 上你有window.onerror兜底，鸿蒙上没有全局错误捕获机制，reject 直接把页面渲染中断了：

// 网络/异步类 crash：Promise reject 白屏// Web 上 unhandledrejection 会在 window 层兜底// 鸿蒙上没有全局兜底，reject 直接中断组件渲染@Entry@Componentstruct CaseListPage{@Statecases:CaseItem[]=[]@StateisLoading:boolean=trueaboutToAppear(){this.fetchCases()// 如果 reject，isLoading 永远是 true → 白屏}asyncfetchCases(){// Cursor 方案：try-catch 包起来// CodeGenie 方案：加 .catch(() => {}) — 等于吞掉错误// 我的方案：catch 后设置 fallback 状态try{constresponse=awaitfetchCaseList()this.cases=response.datathis.isLoading=false}catch(e){// 关键：不能只 catch，还得让页面有个兜底展示this.isLoading=falsethis.cases=[]// 空列表 → 触发 EmptyViewconsole.error('[CaseList] fetch failed:',e)}}build(){if(this.isLoading){LoadingView()}elseif(this.cases.length===0){EmptyView({message:'数据加载失败，下拉刷新重试'})}else{CaseList({cases:this.cases})}}}

Cursor 和 CodeGenie 都只解决了"不白屏"这一步——加 catch 防止 reject 中断渲染。但它们都没考虑到 catch 之后页面该展示什么。一个永远卡在 loading 状态的页面跟白屏没有本质区别，用户看不到任何有用信息。

顺便说一句，雷达鸭上线后遇到的这些 crash 基本都集中在状态管理和异步类，跟列表页和搜索页的交互逻辑直接相关——这类 bug 恰好是 AI 最不擅长修的。你说气不气。

两个没修掉的 bug

我自己也有 2 个没修过——一个是 Navigation 路由栈在某些手势操作下状态回退不一致，我到现在也没完全搞明白触发条件；另一个是华为特定型号（MatePad Pro）上的 WebGL 渲染崩溃，大概率是底层驱动问题，不是应用层能修的。

Cursor 和 CodeGenie 对这两个都是直接给出无关方案，等于瞎猜。这倒也印证了那个结论——工具再快，碰到真没见过的 bug 类型，一样束手无策。

4 分钟修一个 bug 但只有一半能过真机验证，跟 18 分钟修一个 bug 但几乎都能过，你怎么选？

我个人选后者。生产环境的 crash 你不能赌。但简单 UI 渲染类问题，让 Cursor 先过一遍能省不少时间，修完我再复核。状态管理类和异步类，目前还是自己来靠谱。

关于作者：老三，10+ 年软件开发老兵，软件设计师 & 人工智能应用工程师，专注鸿蒙 ArkTS 北向开发和 Web 前端，不定期在 CSDN 分享鸿蒙和 AI 方向的技术笔记。

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