一键开通华为云码道 CodeArts 代码智能体先看结果这不是停在提示词里的 Demo如果只看 Agent 页面这个项目曾多次显示“任务完成”但如果按真实工程标准检查它还经历了 API 不兼容、状态刷新不及时、数据库字段迁移、补丁夹带反向修改等问题。真正的完成不是生成了代码而是应用能够构建、能够运行、数据能够保存、问题能够复现和回归。最终交付结果如下指标结果应用形态HarmonyOS NEXT 原生 Phone 应用开发过程10 个可独立验证的阶段关键回归测试Stage5、Stage8、Stage9 合计 52 项全部通过数据层InMemory 与 relationalStore 两套 Repository 实现工程验证ArkTS 编译通过Debug HAP 构建成功设备验证创建、生成、勾选、进度、自定义、删除和持久化全部通过开源交付AtomGit公开源码、README、运行截图和 MIT License图 1应用不是静态原型。首页能够读取已保存行程显示交通方式、日期、完成数量和进度条并可继续进入详情页操作。本文不只展示“AI 生成了什么”更复盘我如何使用华为云码道 CodeArts Agent 完成需求拆分、跨文件实现、测试补齐和 UI 优化以及如何识别并修正不能直接进入正式分支的生成结果。一、项目背景每次出门旅行我都会遇到一个看似简单但很容易出错的问题到底该带什么证件、衣物、洗护用品、充电设备和常用药品分散在不同的备忘录里旅行天数、交通方式和活动安排不同所需物品也会变化。如果只使用一张静态清单不仅容易漏项也无法直观看到整理进度。因此我使用 HarmonyOS NEXT 和 ArkTS 开发了“旅行物品清单助手”。用户输入目的地、出发日期、返回日期、交通方式和活动类型后应用会根据规则自动生成分类清单用户可以勾选物品、查看完成进度、添加自定义物品并通过本地关系型数据库保存行程和勾选状态。这次开发没有让 AI 一次性生成整个项目而是借助华为云码道 CodeArts Agent 将任务拆分成多个可验证阶段。每一阶段都经过代码审查、补丁检查、本地编译、单元测试和设备运行验证。这样的流程比“生成后直接运行”更稳妥也更接近真实项目开发。图 2CodeArts Agent 已连接公开的 AtomGit 项目StarsAbc987/TravelChecklist。截图保留项目与账号信息用于证明参赛开发链路。二、最终实现的功能应用目前包含以下核心能力创建、查看和删除旅行行程手动输入日期或使用系统日期选择器校验日期格式、无效日期及返回日期先后关系根据交通方式、活动类型和旅行天数生成清单按证件、衣物、洗护、电子设备、药品和其他六类展示物品支持自定义交通方式和自定义活动支持添加、删除自定义物品勾选清单后实时更新分类进度、总进度和进度条使用 relationalStore 保存行程、清单及勾选状态支持浅色、深色两套鼠尾草绿色主题。图 3创建页同时支持标准选项和“其他”自定义输入日期既可手动输入也可以调用系统日期选择器。三、技术架构项目采用分层结构避免页面直接操作数据库层级主要职责Model定义 Trip、ChecklistItem、交通方式、活动类型和清单分类Repository定义行程与清单的数据访问接口并提供内存和数据库两套实现Service处理日期校验、行程创建、清单生成和业务编排ViewModel为页面提供状态、进度计算和用户操作入口ArkUI 页面与组件展示行程列表、创建表单、详情页和清单分类DataAccessor封装 relationalStore 的增删改查和 ResultSet 生命周期这种设计带来的直接收益是可测试性。早期阶段可以使用 InMemory Repository 快速验证领域逻辑数据库接入后再切换到 RelationalStore Repository而上层 Service 和 ViewModel 不需要重写。四、使用华为云码道完成分阶段开发我将整个项目拆分成十个阶段每个阶段只解决一个主要问题阶段主要工作Stage 1建立领域模型、枚举、日期工具和错误类型Stage 2实现内存版 Trip 与 Checklist RepositoryStage 3实现基于规则的清单生成服务Stage 4完成应用服务和业务编排Stage 5完成 ViewModel、页面、组件和导航Stage 6接入 relationalStore实现本地持久化Stage 7完善空状态、校验反馈和发布体验Stage 8增加日期选择器、自定义输入、图标和进度刷新Stage 9加固数据库异常处理和迁移逻辑Stage 10整理 README、构建说明和最终交付检查在每个阶段我都会要求 CodeArts Agent 先读取现有代码再给出修改范围避免无关文件被改动。交付时生成独立分支或补丁不直接覆盖main。本地确认无误后再合并这使每一步都有清晰的 Git 记录也便于定位回归问题。为什么要拆成十个阶段而不是一次性要求“帮我做一个旅行清单应用”原因有三点上下文可控每轮只让 Agent 聚焦一个层级或一种风险减少跨文件修改时遗漏旧约束回归可定位每个阶段都有独立分支、提交或补丁出现问题时能够快速定位引入点验收可量化业务能力、数据库迁移、输入体验和 UI 优化分别验收避免“页面能打开”掩盖数据层问题。以 Stage 8 为例它不是简单增加两个输入框。Agent 需要同时理解日期工具、数据模型、Service、ViewModel、Repository、数据库字段、页面状态和测试 Mock。执行前先读取 23 个相关文件再按计划修改结束后检查差异、提交记录和补丁可应用性。这个过程让我看到 CodeArts 在跨文件理解上的效率也让我更重视任务边界和最终差异审查。图 4安全裁剪后的 CodeArts 执行过程。可见分支/工作区检查、文件读取、执行计划、修改、git diff --check与提交步骤认证信息未纳入图片。五、核心实现一基于规则生成旅行清单清单生成器会按“基础物品→交通方式→活动类型→旅行天数”的顺序合并规则再按物品名称去重。这样同一个物品即使被多条规则命中也只会出现一次。generate(trip:Trip):ChecklistItem[]{constallRuleItems:RuleItem[][];this.appendItems(allRuleItems,getBaseItems());this.appendItems(allRuleItems,getTransportItems(trip.transportType));for(leti0;itrip.activityTypes.length;i){this.appendItems(allRuleItems,getActivityItems(trip.activityTypes[i]));}constdays:numbercalculateTripDays(trip.departureDate,trip.returnDate);this.appendItems(allRuleItems,getDaysItems(days));// 后续按名称去重、按分类排序并生成 ChecklistItem// ...}生成逻辑不直接依赖页面和数据库同时支持注入固定 ID 和固定时间。因此测试时可以得到稳定、可重复的结果不会因为随机 ID 或当前时间不同而失败。六、核心实现二勾选后立即刷新进度开发过程中遇到过一个真实问题用户点击物品后圆形选中状态发生变化但总完成进度没有同步刷新。问题原因是写入仓储后ViewModel 中的清单数组仍然是旧数据。修复方式是在状态变更后重新读取当前行程的清单toggleItemChecked(itemId:string,isChecked:boolean):void{this.service.toggleItemChecked(itemId,isChecked);if(this.currentTrip!undefined){this.checklistItemsthis.service.getChecklist(this.currentTrip.id);}}进度文本和百分比都从最新数组计算getTripProgressPercent(tripId:string):number{constitems:ChecklistItem[]this.getProgressItems(tripId);if(items.length0){return0;}constcheckedCount:numberitems.filter((item:ChecklistItem)item.isChecked).length;returnMath.floor(checkedCount*100/items.length);}图 5、图 6同一行程的详情与勾选结果。这里验证的是状态写入之后界面是否真正读取到最新数组而不只是按钮外观发生变化。七、核心实现三数据库迁移与资源安全释放Stage 8 增加自定义交通方式和自定义活动字段后旧数据库中并不存在对应列。如果每次启动都直接执行ALTER TABLE第二次执行就会因为字段已经存在而失败。最终方案是先通过PRAGMA table_info获取列集合只对缺失字段执行迁移privatemigrateTripsTable(rdbStore:relationalStore.RdbStore):void{constexistingColumns:Setstringthis.getTableColumns(rdbStore,trips);if(!existingColumns.has(custom_transport)){rdbStore.executeSync(ALTER_TRIPS_ADD_CUSTOM_TRANSPORT);}if(!existingColumns.has(custom_activity)){rdbStore.executeSync(ALTER_TRIPS_ADD_CUSTOM_ACTIVITY);}}查询表结构时ResultSet 在finally中关闭数据库初始化失败时将ready设为false并允许页面回退到内存仓储。这个阶段让我体会到AI 能快速生成数据库代码但资源关闭、重复初始化和旧数据迁移必须单独设计和测试。八、两次不能直接接受 AI 结果的经历1. API 看起来合理但当前 SDK 不支持在优化首页标题时CodeArts Agent 使用了.customTitle(...)。代码从语义上很自然但本地 ArkTS 编译器提示NavigationAttribute不存在该属性。根据当前 SDK 的实际能力最终改为.title(this.TitleBar())修改后重新构建ArkTS 编译与 HAP 打包才全部通过。这说明 API 是否可用必须由项目实际 SDK 和编译器确认不能只依赖生成结果。2. 名为“增量补丁”实际夹带反向修改在最后一次 UI 微调中我只要求增加标题间距并将六个分类按钮改成 3×2 网格。但 Agent 生成的补丁除了目标修改还包含大量撤销现有绿色主题的反向差异。如果直接应用已经完成的卡片圆角、颜色资源和列表布局都会退回旧版本。最终我先查看git apply --stat和补丁内容只提取两个目标 hunk再执行git diff --check和 HAP 构建。这个案例说明AI 辅助开发中“审查差异”与“审查最终代码”同样重要。这次 UI 调整也采用同样的方法让 Agent 明确列出修改文件、逐页视觉变化、未修改的业务范围、已执行的静态检查和当前环境不能执行的验证。CodeArts 工作空间没有项目所需的 HarmonyOS hvigor 工具因此它没有伪造云端构建结果真正的 ArkTS 编译、HAP 构建和设备运行由我在本地 DevEco Studio 完成。图 7交付报告把“已执行”和“未在当前环境执行”分开记录。对 AI 生成结果而言这种边界说明比一句笼统的“任务完成”更可信。九、测试与验证结果项目没有把“Agent 显示任务完成”当作最终完成而是使用本地 DevEco Studio 验证。验证项结果Stage 5 ViewModel 与页面行为测试13/13 通过Stage 8 日期、自定义输入与交互测试23/23 通过Stage 9 数据访问、迁移和异常测试16/16 通过ArkTS 编译通过Debug HAP 构建BUILD SUCCESSFUL设备运行首页、创建、详情、勾选、删除、持久化均通过深色模式通过52 项关键测试不是为了凑数字而是覆盖三个最容易回归的层面测试组数量主要覆盖内容Stage 513ViewModel 初始状态、创建行程、打开详情、勾选、自定义物品、删除、进度与分类Stage 823日期格式与有效性、自定义交通/活动、输入 trim、页面交互与进度刷新Stage 916DataAccessor 正常/异常路径、ResultSet 生命周期、字段迁移、重复初始化与回退图 8先验证页面背后的状态与业务入口避免只靠手动点按判断正确性。图 9新增输入体验后进行专项回归23/23 通过。图 10数据层加固后的 16/16 测试结果。三组关键回归合计 52 项。测试通过之后我还按真实用户路径进行设备验收创建行程、选择和手输日期、自定义交通与活动、生成六类清单、勾选物品、添加自定义物品、删除行程、退出重进检查持久化并切换深色模式检查颜色与文字对比。单元测试负责快速发现逻辑回归设备验收则负责发现导航、键盘、布局和系统组件等真实交互问题两者不能互相替代。十、最终界面与体验最终界面采用鼠尾草绿色作为主要视觉语言。浅色模式以低饱和绿色和白色卡片为主深色模式使用深森林绿背景并保留足够的文字对比度。自定义物品区域使用两行三列等宽分类按钮避免最后一个分类单独换行。图 11分类按钮调整为 3×2 等宽网格“其他”不再孤零零换行选中态使用更深的鼠尾草绿信息层级更清楚。图 12深色模式不是简单反色而是单独配置背景、卡片、边框、主文字、次文字与强调色资源。这次视觉调整坚持一个原则只改变呈现不偷偷改变业务。Agent 的任务中明确禁止新增天气、倒计时、历史归档等不存在的功能也不允许修改 Model、Repository、Service、ViewModel 和数据库。最终只调整颜色资源、标题区域、卡片圆角、按钮排列和间距。这样的约束让 UI 优化保持可审查、可回滚也避免为了“看起来更丰富”而制造虚假功能。十一、使用华为云码道后的实际体会华为云码道 CodeArts Agent 最明显的价值不是“替我写完所有代码”而是帮助我快速理解陌生项目、拆分阶段任务、生成跨文件实现和补充测试。在领域模型、仓储接口、测试 Mock 和重复性代码方面它显著减少了机械工作量。但要让项目真正落地开发者仍然需要承担三个职责第一明确每轮任务边界第二检查补丁是否只包含预期修改第三在真实 SDK、真实设备和真实数据环境中验证。尤其是 HarmonyOS 与 ArkTS 的 API 版本、状态刷新和关系型数据库资源管理仅凭静态代码看起来正确还不够。对我而言这次项目最大的收获不是生成了多少代码而是形成了“需求拆分—Agent 实现—差异审查—本地测试—人工验收—独立提交”的稳定协作流程。十二、开源地址AtomGit公开仓库https://atomgit.com/StarsAbc987/TravelChecklist技术栈HarmonyOS NEXT、ArkTS、ArkUI、relationalStore开源协议MIT License仓库包含可运行源代码、README、构建和测试说明、应用截图及开源协议。欢迎交流和提出改进建议。图 13AtomGit 公开仓库已经补充项目介绍并提供可运行源代码、README、应用截图、构建与测试说明及 MIT License评审者可以据此复现并核对本文内容。结语AI 提速工程判断兜底如果让我用一句话概括这次实践CodeArts Agent 把跨文件理解和实现速度往前推了一大步而真实 SDK、测试结果、设备表现和 Git 差异决定项目能不能交付。“AI 说完成”只是一次协作回合的结束不是软件质量的终点。把需求拆小、让每次修改都有边界、保留可核查的提交、在真实环境中编译运行再用测试覆盖最容易回归的路径才是我从这次 HarmonyOS 项目中得到的最有价值的方法。