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

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 的核心差异：

借着这次机会，我们决定将整个项目彻底由 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 开发工具。

三种工作模式

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

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

（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 仓库，然后向下一批文件推进。

四步迁移流程：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”路径获取相关使用指南：