12 天迁移 1000+文件:DevEco Code 如何助力灵动小组件完成第四次大重构

AI 驱动的代码重构,让复杂迁移工作变得高效可控。 项目背景: 应用名称:灵动小组件 · 鸿蒙桌面美化应用 作…

AI 驱动的代码重构,让复杂迁移工作变得高效可控。

项目背景:

应用名称:灵动小组件 · 鸿蒙桌面美化应用

作者介绍:灵动小组件开发团队 · CTO

团队定位:跨界团队,包括医生、动画师、农学专业毕业生、退伍军人等。

核心产品:灵动小组件 — 鸿蒙系统桌面小组件美化与功能增强应用。

本次实践:使用 DevEco Code 完成 ArkTS V1 到 ArkTS V2 的整体架构迁移。

引言:半年以上的迁移计划,12天完成

41 个模块、1000+个文件,涉及应用 UI、桌面卡片、本地/云数据库读写,以及应用向桌面卡片的数据与图片推流——按照传统方式评估,灵动小组件从 ArkTS V1 到 ArkTS V2 的整体迁移预计需要半年以上。最终,团队借助 DevEco Code,用 12 天完成了迁移,功能可正常使用,运行无明显 Bug。

这次实践最值得关注的,还远不仅仅是效率的提升,团队没有把 DevEco Code 当成一个代码补全工具,而是把迁移规则沉淀成 Skill,把复杂工程拆成可控模块,再让 AI Agent 贯穿分析、改码、构建、验证和修复环节,人则负责架构判断、任务拆分和最终验收。

一、为什么必须重构:功能越快迭代,技术债也越快累积

灵动小组件是一款鸿蒙系统上的桌面小组件(服务卡片)美化与功能增强应用,被用户称为“桌面装修神器”。它能提供天气、日程、纪念日、趣味互动等多种卡片,并支持“喵喵拳分歧器”、3D 趣味表情等互动体验。在 HDC 2026 鸿蒙星光大道上,灵动小组件作为 42 款创新应用之一展出,受到广泛关注。

灵动小组件在 2024 年 8 月完成了第三次大重构,之后便不断高速迭代。作为 CTO,我非常明显地感受到代码质量在日渐崩坏:新功能的增加、bug 的维护都变得越来越困难。代码中充斥着难以理解的函数和组件,甚至出现了很多完全相同的类和函数副本。单个文件超过 3000 行的超大组件,就为了在不大改代码结构的情况下解决跨模块循环依赖的问题。

想要修复一个 bug,光是查找代码就需要反复检查,有时候改了几处,结果测试时才发现还有副本代码没有修改。终于在 2026 年 6 月,我们决定踩下刹车,进行第四次大重构,深入彻底地修复代码中存在的各种问题。

二、重构核心:ArkTS V1 版本到 ArkTS V2 版本的整体迁移

重构计划的第一步是将 ArkTS V1 版本整体转为 ArkTS V2。

我们项目启动时还没有 ArkTS V2 版本,所以整个项目都是基于 ArkTS V1 构建的。为了解决小组件的数据同步需求,我们设计了一个非常复杂的数据结构和状态同步算法。

等到 ArkTS V2 发布时,已经有了大量的历史包袱。为了保证代码的稳定性,我们一直延续了 ArkTS V1 的开发路线。但实际上 ArkTS V2 的状态管理机制更加适合我们的应用场景,它可以大幅简化我们的数据同步机制,用更少的代码,实现更好、更稳定的数据传递效果。

ArkTS V1 与 ArkTS V2 的核心差异:

图片 1.png

借着这次机会,我们决定将整个项目彻底由 ArkTS V1 迁移为 ArkTS V2。这相当于要把从项目第一行代码开始到现在近 3 年写下的文件全部重构。

需要改写 41 个模块的 1000 多个文件,涉及到应用内 UI、桌面卡片、本地数据库/云数据库增删改查、应用向桌面卡片的数据推流/图片推流——我们借助 DevEco Code 完成了第四次重构,花了 12 天,就完成了全部的迁移工作。

三、DevEco Code:AI 编程助手登场

DevEco Code 是华为在 HDC 2026(2026年6月12日)期间正式发布的 AI 编程助手,基于华为自研的 BitFun(毕方)和开源 OpenCode 构建,专为鸿蒙应用开发场景深度定制的一站式 HarmonyOS 应用开发 AI Agent。

核心定位

DevEco Code 融合鸿蒙领域软件工程能力,覆盖需求理解、方案设计、代码生成、语法检查、编译构建、推包运行、功能验证、问题修复、日志分析等全流程,结合鸿蒙应用开发特性做全链路深度优化,打造适配鸿蒙生态、贴合开发者需求的 AI 开发工具。

三种工作模式

图片 2.png

三循环鸿蒙应用开发质量保障

DevEco Code 的 Harness 包含三个递进的验证循环,让 AI 写下的每一行代码,都要连过三关:

图片 3.png

(1)语法校验——在源头发现问题。 AI 生成代码后,轻量级语法工具完成初步过滤并修复明显的语法问题。在此基础上,Agent 引入 LSP 对代码仓进行依赖分析、调用链分析与引用关系分析,帮助 AI 快速建立对项目结构的完整认知,提升代码重构与跨模块修改的准确性。

(2)编译诊断——守住代码语法准确率防线。调用编译工具进行编译诊断,错误信息回传至 AI Agent 定位修复,保障生成的代码准确度,直至编译通过。

(3)UI 意图校验,直面被长期忽视的盲区。编译通过不等于功能正确,功能正确不等于 UI 符合预期。这是 AI 编码中长期被忽视的问题。UI 意图校验是 Harness 为解决功能正确性而提供的亮点的能力。基于多模态模型能力,代码编写完成后,自动拉起模拟器,执行 UI 意图校验与逻辑功能验证:模拟真实用户的点击、滑动、长按、输入等交互操作,执行过程中主动截图,生成对比报告供开发者审阅。

UI 显示与交互问题一经发现,即自动回传智能体修复。开发者无需进行重复性验证,只需审阅报告,做出决策——验证全闭环,结果自反馈,证据可视化。

DevEco Code 支持强大的代码修复能力,针对三重循环遇到的语法问题、构建报错、运行崩溃、UI 显示问题和交互功能问题等开发阶段的代码错误,都能很好的修复,保障了三重循环的正常进行,为我们的迁移工作提供了强大的支撑。

四、如何用 DevEco Code 完成迁移?

光靠 DevEco Code 自身是无法在这么大工程量的前提下,通过几句提示词就自动完成 ArkTS V1 向 ArkTS V2 的整体迁移的。如果试图用简单的一句“把项目中的 ArkTS V1 状态管理全部迁移为 ArkTS V2 版本”就想完成这么复杂的工作,最终只会在烧掉了大量的 token 以后,收获一坨完全无法运行的诡异代码。

大规模迁移是可行的,只是需要我们做一些额外的工作。

第一步:编写迁移 Skill

工作的第一步是写个迁移 Skill。把如何从 ArkTS V1 向 ArkTS V2 迁移的流程、关键信息全部封装起来,让 DevEco Code 知道 ArkTS V1 和 ArkTS V2 有什么区别,迁移要修改哪些内容,遇到问题要去哪里找文档。

Skill 是 DevEco Code 的核心原子能力单元,可以理解为“可复用的专家经验包”。它将高频的鸿蒙开发操作固化为精确的指令集,让 AI Agent 不再只是泛泛生成代码,而是能结合鸿蒙开发的真实规则和经验执行任务。

Skill 的核心价值

▪ 模型无关性:将标准化开发操作固化为高精度指令集,不依赖特定大模型版本。

▪ Token 消耗降低 70%+:AI 无需在提示词中反复加载冗长配置步骤,直接调用 Skill,任务完成速度提升 3 倍以上。

▪ 保持“当下最佳实践”:知识库随 IDE 版本实时更新,保证 AI 始终遵循最新技术规范。

第二步:模块划分

由于代码架构过于复杂,一次性迁移可能会导致代码异常,且难以进行测试。我们没有一次性让 AI 进行整体迁移,而是基于之前开发中对代码架构的理解,把整个项目按代码的耦合关系进行了划分。每个模型的迁移,尽量少的依赖其他模型,为后续的并行迁移打基础。

第三步:逐模块迁移 + 自动验证

基于上一步的代码划分,我们采用 DevEco Code 的 Goal 模式,逐模块地进行迁移。Goal 模式每一次任务执行完成,都代表着本次迁移工作通过构建,且经过了 UI 自动化测试和交互功能测试,人工仅做最终的评审即可。将 bug 压制在最小范围内,一旦人工复检出现问题,及时进行微调。通过构建通过+功能验证+UI 验证的机制,输出客观的验证报告,避免模型不加测试的认为任务开发完成。而验证发现问题自修复,多轮迭代开发的能力,避免了人工需要持续与 Agent 交互。

第四步:Git 多分支并行迁移+主开发分支集成测试

我们通过 git 多分支操作不同模块的迁移工作,进一步提升了并行迁移的效率。每个迁移任务运行在一个分支上,迁移任务完成便合入主开发分支,进行集成功能测试,一旦测试通过,就把迁移的文件直接提交 Git 仓库,然后向下一批文件推进。

图片 4.png

四步迁移流程:Skill 编写 → 模块划分 → 逐模块迁移 → 测试验证

五、最终成果

最终只花了 12 天 就完成了全部的 ArkTS V1 → ArkTS V2 迁移工作,完成了这次整体重构计划中最困难的一步。

成果数据

▪ 迁移范围:41 个模块,1000+ 个文件。

▪ 迁移时间:12 天(原预计半年以上)。

▪ 最终状态:运行无明显 bug,功能可正常使用。

这次实践让我感受最深的是:AI 编程真正有价值的地方,不只是帮我多写了几百行代码,而是帮助我把一个模糊的痛点,快速变成了一个“读懂旧代码—改写—验错—修复”的可控流程,并交付了可正常运行,有质量验证的结果。

经验总结

Skill 封装解决了“AI 如何理解迁移规则”,提升迁移的准确性;

模块划分解决了“大规模多任务并行迁移的可控性”;

DevEco Code 的 Goal 模式通过生成-验证-修复的闭环,自测试解决了单次“迁移质量保障”;

Git 多分支并行迁移,提升了迁移的速度,主开发分支集成测试,保障迁移功能的正确性。

对我来说,用 DevEco Code 、用 Goal 模式开发最值得称赞的地方:通过封装 Skill,沉淀人工的智力能力,Goal 模式通过Skills正确的迁移代码,通过自验证自修复机制,保障迁移模型的功能正确性。开发者不用守在电脑前,高频介入 Agent 的开发过程,可以同时启动多个 Goal 任务进行开发,只负责结果审核和集成测试即可。

写在最后

人的工作没有消失,只是换了位置。

以前开发者站在每个代码细节里,不断地拉扯 AI 来工作,人工判断该不该改,整理提示词告诉 AI 怎么改。现在开发者站在了甲方的视角:先提需求——需要什么功能,评审 AI 的产出是否符合预期,最后判断功能代码能不能合入主线。Agent就是乙方,接需求开发代码,自验证自修复,交付特性出来给甲方评审。

当 AI Coding 真正进入需求、编码、构建、验证和修复的完整开发链路后,它将彻底重塑软件工程开发,让复杂的任务变得更高效、更可控,也更容易沉淀为下一次可以复用的能力。

如果您想了解更多关于 DevEco Code & DevEco CLI 相关内容,可以登录HarmonyOS开发者官网,点击“开发”频道,按照“开发文档-指南-AI Coding-DevEco Code”路径获取相关使用指南:

图片 5.png

关于作者: 澎湃科技

为您推荐