开发助手进入应用开发流程后，开发者面对的仍是具体工程：需求如何拆成页面和行为，生成代码是否符合已有结构，构建之后又能否在目标设备上正常运行。只看一段生成结果，很难判断工具实际参与了哪些工作，也不容易看清哪些结论还需要人工验证。
为了观察 HarmonyOS 开发助手在不同开发起点下的表现，我选了两项日常任务：从空工程开始开发垫付款记录页，以及在已有的“野集”商品首页上调整平板布局。前者侧重需求理解与代码生成，后者关注既有工程改造和目标设备上的运行效果。下文按实际开发顺序分别展开。
两项任务不构成对复杂业务系统的全面评测。它们的功能目标相对明确，页面可以在模拟器里观察，构建结果和代码 Diff 也能提供过程线索。实测结论以实际操作和验证为依据：助手做了什么、应用运行出了什么结果，以及哪些部分仍待检查。
案例一：从空工程开始开发垫付款记录页
报销场景的难点往往不在流程本身，而在于支出记录较为零散：打车费十几元、打印费几元，或临时采购产生的几十元支出。费用需要先由个人垫付，待申请报销时，再逐笔核对记录，确认哪些已经报销、哪些仍待处理。选择这一场景，是因为它贴近日常，需求边界也比较清晰，无须引入复杂的企业流程即可验证核心功能。
本次测试从新建空工程开始：我没有基于现成项目进行改造，也没有预先编写代码再交由助手处理，而是让 HarmonyOS 开发助手从需求描述出发，完成一个名为 AdvanceNote 的垫付款记录页面。验证目标不止是页面呈现，还包括用途和金额录入、报销状态切换、待报销金额动态更新，以及数据保存。
工程使用 DevEco Studio 的 Empty Ability 模板，Compatible SDK 选用 6.1.1（24），设备类型为手机。初始页面只有默认的 Hello World，工程里只有最基础的页面入口；没有额外添加平板设备或组件，这次验证范围先限定在一个手机页面。
开始让助手修改前，我先在手机模拟器里运行空白工程，确认设备连接、工程模板和初次构建正常。这个基线看起来简单，却能帮助区分原工程问题和助手改动带来的问题。后续页面如果跑不起来，至少可以确认此前的设备连接、模板和初次构建是正常的。
基线确认后，我才开始让助手接手。第一句话是：“我想把这个空页面弄成一个垫付款小本子，你先看看从哪改比较合适，先别动代码。”我特意加上“先别动代码”，是想先看它能不能读懂空工程、准备从哪里下手。如果一上来就整页替换，很多决定只能等代码出来后再返工。
助手先读取工程结构，指出首页入口位于 entry/src/main/ets/pages/Index.ets，也注意到项目目前只有一个页面。它给出的首版范围包括总额与待报销金额汇总、垫付记录列表、新增记录，以及后续可扩展的详情和统计筛选；同时说明当时只做了检查，没有修改代码。它还提到 EntryAbility.ets 会在启动时加载页面，main_pages.json 已经登记了这个页面。这些工程信息不需要我逐项复制给它，省去了交代目录结构的时间。
空工程里没有多少上下文，直接叫助手“做一个报销应用”，很容易让它自行补充功能。先让它读项目、说明准备怎么做，至少能在生成代码前检查范围。我看完回复后，才让它继续推进。
确认方向后，我发给它的要求很随意，没有写接口说明，也没有指定页面要拆成几个组件，只把要记录什么、怎么判断报销状态说出来：“能记用途和金额，能标待报销或已报销，自动算还没报的钱，记错了能删，关掉再打开也还在。金额不对就提醒我，页面大方点就行，但是要符合场景。”这样也能观察助手能不能把口头需求整理成一条可执行的开发流程。
收到要求后，助手开始执行任务，同时列出了工程检查、设计方案、数据模型与持久化、记录和状态切换页面、构建验证等待办。它把“持久化存储”和“金额校验”列入计划，和我提出的要求对应得上；清单还写了先做原型、再进入开发阶段。对开发者来说，这份清单可以作为检查需求理解的线索：如果任务里突然出现联网报销、账号登录或复杂审批，就可以在实现前叫停。
不过，这并不是一个严格的“先列计划、等我确认、再开始改代码”的流程。清单画面里，左侧的 Index.ets 已经开始引入 ExpenseHome，说明它列计划的同时，工程入口也动起来了。待办清单可以帮助理解过程，但不能自动成为审批关卡；如果改动范围或架构决策很重要，仍然要自己查看 Diff。
这份清单还有一项实际价值：需求里既然包含“要保存数据”，实现阶段就应该检查本地存储，不能只验输入框和金额计算。助手把任务拆到数据模型、页面和构建几个环节，后续检查时也有了对应的顺序。
随后助手进入设计阶段，生成报销记录页的方案。页面被设定为单页工具：上方放统计卡片，中间是录入区域，下方用“全部、待报销、已报销”筛选记录。方案还写了空金额、非数字、零金额和超出两位小数时的提示方式，以及删除前二次确认。
从待办进入设计这一步，助手开始把需求翻译成具体页面和行为。我主要检查它有没有漏掉“改状态后金额要变化”和“删错记录怎么处理”这些使用时才会遇到的细节，而不只是看配色是否好看。方案里有些细节已经超出了原始要求，比如颜色、字号和动效；对这次任务来说，视觉稿不是重点，有用的是助手先把页面结构和规则说出来，我可以在它写代码前确认方向。像“一个页面完成全部操作”，就符合这个小工具的使用方式，不需要再做几个页面来回跳转。
方案还区分了原型与最终工程的数据实现：原型预览使用 localStorage，ArkTS 端计划使用 Preferences。这个区分值得留意，原型预览能保存数据，不等于最终应用工程已经使用对应 API；方案看起来完整，也只能说明实现路径被考虑到了。最终是否按方案落到工程里、数据是否能跨重启保留，仍要看代码和实际运行。
开发阶段完成后，助手报告构建通过，并列出了生成的工程结构。入口 Index.ets 引入 ExpenseHome，另外还有数据模型、统计用的 ViewModel、录入和汇总组件，以及本地存储相关代码。实现分布在 common、home 等目录，没有把输入、列表、筛选和金额计算全堆进 Index.ets。从交付结构看，页面、数据和统计职责做了拆分；不过，这个判断依据目前是目录结构和助手说明，代码质量仍需打开文件细看。
模拟器里的页面名为“报销记”。顶部是待报销金额卡片，同时显示待报销笔数和已报销合计；下面可以输入用途与金额，点击“记一笔”添加记录，再用“全部、待报销、已报销”筛选列表。页面信息顺序围绕先看待报销金额、再录入一笔、最后查找已有记录展开，不需要另外手算当前还差多少，也没有把统计和录入藏进不同页面。对于偶尔记录一笔的小工具，少几次返回和切换比增加花哨入口更实在；当然，长期使用是否顺手还需要更多体验。
构建窗口显示 BUILD SUCCESSFUL，产物为未签名 HAP。对开发阶段来说，构建成功并在模拟器中运行，足以确认工程进入了运行检查；这不代表应用已经签名、具备上架条件，或已在真机上完成适配。签名和上架不在这次小任务范围内，因此结论停在开发构建和模拟器运行这一步。
这次并不是代码生成一次就完全结束。助手在执行过程中发现两处语法问题，之后又修复一处无效颜色值，再检查 JavaScript 语法并继续生成原型和 ArkTS 工程。阶段记录里能看到先做原型预览、再进入开发阶段，也提到了 ArkTS 持久化实现中要避免 as、any 等写法。
这个过程比“一次生成成功”更接近日常使用开发助手的情况：代码生成只是中间环节，语法问题、构建错误和页面预览都可能带来后续迭代。但自动修复不等于人工审查。删除确认、异常金额输入、本地存储具体使用了什么 API，仍然需要对照代码或实际操作核对；不能因为助手说修好了，就默认所有实现都没有问题。
这次实测没有单独记录关闭应用后重新启动的过程，因此“关掉再打开还在”没有被验证。动图能证明页面交互和统计在当前运行中工作，但不能代替重启测试。删除确认、异常金额输入和持久化 API 的行为，也需要逐项检查。
这个小任务让我看到，HarmonyOS 开发助手可以从空工程和几句自然语言开始，读取项目、拆分任务、生成页面方案，再形成 ArkTS 工程结构并在过程中修复问题。对于单页、规则明确、验证路径短的功能，这种工作方式能较快形成一个可检查的版本；是否符合需求，仍要通过 Diff、构建日志和实际运行判断。
案例二：为“野集”商品首页验证平板四列布局
第二项任务转向一个已有工程。“野集”是一个露营与徒步用品首页，页面展示六件商品，没有接商品后台；搜索按商品名、描述和分类标签过滤，分类按钮筛选类别，收藏和加购只改变页面里的状态。商品数量少，改成四列后第二行会留下两张卡片，网格列数容易观察；长列表滚动、真实商品图适配、后台数据、分页和加载状态，都不在本次测试范围内。
我使用搭载 Apple 芯片的 Mac，从华为开发者下载中心下载 ARM 版本的 DevEco Studio。首次启动时，等待 SDK 组件初始化完成，再从插件页面下载 HarmonyOS Dev Assistant 压缩包，并在 Settings/Preferences → Plugins 中选择 Install Plugin from Disk 安装。重启 IDE 后，我从右侧工具栏打开助手面板；如果工具栏里没有入口，也可以从 View → Tool Windows 查找。
插件加载与账号登录是两个状态，分别确认更容易定位问题。登录后还要配置模型，助手支持两种添加方式；本次选择通过 URL 添加 OpenAI 兼容模型，模型名填 gpt-6-luna，接口地址和 API Key 按所用服务填写。保存后回到会话页，确认模型出现在可选列表中再开始对话。这些配置放在开发助手中，没有写入页面代码。
完成开发助手的安装与模型配置后，我使用 Empty Ability 模板创建工程，Compatible SDK 为 26.0.0，设备类型同时勾选 Phone 和 Tablet。创建后，我又检查了 module.json5，确认模块声明里也包含 phone 和 tablet。设备声明说明工程支持哪些设备，页面如何排布仍要看 ArkUI 布局。
改造前，我先在 Mate 90 Pro 手机模拟器上运行原页面并搜索“灯”。结果只剩一件“复古充电营地灯”，搜索本身正常，但商品区仍是两列，单件商品靠左排着，右边留空。接着切到 MatePad Pro 13 横屏模拟器，运行同一份未修改代码：页面能打开，商品仍是两列，卡片显得很宽；搜索框、分类和活动横幅依次向下排列，页面中间也留白较多。设备运行正常，但布局还是按手机宽度组织，没有用上平板横屏空间。
同一台平板、同一方向和同一份商品数据，才能让改前改后有可比性。我保留 MatePad Pro 13 作为后续运行目标，也分别留好了手机与平板基线；之后查看结果时，不需要猜页面在哪种设备上运行。
基线留好后，我先让助手查看工程、给出调整思路，再决定是否实施。对话中选择了“一多适配”模式，提出平板页面需要重新安排导航和内容布局，让搜索、活动横幅和商品区更适合宽屏阅读，减少卡片被横向拉宽带来的空旷感，并要求手机布局保持不变。
助手先检查了项目结构和现有断点策略。它指出当前页面没有响应式断点，商品卡片固定为两列；为实现窗口尺寸变化时的适配，初步方案提到了窗口监听，并提醒如果只改一部分，平板切换或窗口尺寸变化时可能出现布局失效。这个阶段的分析帮助我了解了它准备检查什么，但最终实现仍要回到实际代码确认。
实际执行后，代码没有新增窗口监听，而是使用 ArkUI 的 GridRow 和 BreakpointsReference.WindowSize，根据窗口宽度切换列数。商品区核心配置如下：
GridRow({ columns: { sm: 2, md: 3, lg: 4 }, gutter: { x: 12, y: 12 }, breakpoints: { reference: BreakpointsReference.WindowSize }}) { ForEach(this.filteredProducts(), (item: Product) => { GridCol({ span: { sm: 1, md: 1, lg: 1 } }) { this.productCard(item) } }, (item: Product) => item.id)}最终执行说明显示，改动还涉及搜索、分类和活动横幅的平板排布：宽屏下这些内容横向展示，窄屏仍按顺序纵向排列；底部导航保留。商品区则改为响应式列数，助手说明手机为两列、中等宽度为三列、平板宽屏为四列，并增加了列间距。代码片段呈现的是商品网格的核心实现，完整修改范围还需要结合 Diff 判断。
DevEco Studio 构建窗口显示 33 个任务完成，耗时 3.982 秒，进程退出码为 0。日志还提示工程没有配置签名，因此跳过签名；本次得到的是未签名开发构建结果。构建说明工程通过编译流程，不能单凭这一项判断网格在目标屏幕上的实际效果。
助手在回复中也说明，它没有替开发者运行平板。构建后，我从 IDE 顶部设备菜单选择 MatePad Pro 13 模拟器，手动启动并安装应用。横屏页面第一行排了四张商品卡片，第二行还有两张，底部导航仍然显示；和改之前相比，商品卡片没有再被撑成两大块。
目前确认的是，布局改动通过了构建，并在 MatePad Pro 13 横屏模拟器中呈现四列商品卡片。它把页面改到了可运行的状态，但手机端改后回归、搜索和分类筛选、收藏与加购按钮都还没有逐项检查；旋转、分屏、窗口缩放和真机也没有测试。对于这种商品页，后续还应补手机竖屏，再逐项检查搜索、分类、收藏和加购；这些检查通过之后，才适合把结论扩展到完整的一多适配。
两项实测的结论
两个案例的开发起点不同，观察重点也不同：空工程案例考察助手能否将自然语言要求整理成页面、数据与基础逻辑；既有工程案例考察它能否理解已有代码、控制局部改动，并在指定设备上呈现目标布局。两次实测都显示，开发助手可以参与需求理解、代码生成或修改、问题修复和构建准备，但“是否符合预期”仍需开发者通过代码 Diff、构建日志和设备运行结果来判断。
这些案例也提醒我们区分几个容易混淆的环节：列出计划不代表代码尚未修改，原型能保存数据不等于最终应用已经验证持久化，构建成功不等于签名或上架完成，在一台模拟器上运行也不能替代跨设备、边界输入和交互回归。对于功能边界清晰、验证路径较短的任务，助手可以帮助较快得到一个可检查的版本；完整验证仍取决于开发者设定检查项并亲自完成。