前阵子我在折腾鸿蒙应用开发的时候脑子里突然冒出一个很直接的问题既然 AI Agent 已经能写 JavaScript、Python甚至在 Verilog 这类硬件描述语言里帮我搭模块那它能不能自己动手写一个鸿蒙应用不是那种在聊天窗口里丢一段代码让你自己复制的“半自动模式”而是把创建工程、写页面、编译、装进模拟器、看日志、修 bug 这一整条链路全部交给 Agent 去闭环。带着这个想法我把 DevEco CLI 翻了出来做了一个从零到一让 Agent 独立开发鸿蒙小应用的实测。这篇文章就是这次实测的记录。我会把整个思路、环境搭法、Agent 的 Prompt 设计、踩过的坑和最终的效率对比都摊开讲一遍。如果你正在做鸿蒙开发或者对 AI Agent 的实际落地感兴趣这篇应该能给你一个比较具体的参考——这套流程本身不复杂但里面的细节坑不少值得说一说。1. 为什么要用命令行驱动 AI Agent先说清楚底层逻辑1.1 AI Agent 写代码的常见卡点人在中间当“搬运工”现在提到 AI 写代码大部分人想到的还是“在对话框里描述需求 → 复制代码 → 粘贴到工程 → 手动编译 → 报错再粘回去”。这不是真正的 Agent这只是把大模型当成了一个高级点的搜索引擎人在中间仍然是那个负责“动手”的工种。真正的 AI Agent 应该有能力自己调用工具自主完成一系列操作。比如写一个文件它应该真的能把文件写到磁盘上编译报错了它应该能自己读日志、分析原因、改代码然后再编译一轮。整个过程里人可以只看结果最多在它陷入死循环的时候介入一下。这恰恰是鸿蒙开发的尴尬之处。DevEco Studio 是一个图形化的 IDE虽然开发体验不错但对 Agent 来说图形界面等于不存在——Agent 没办法用鼠标点按钮也没办法通过脚本去操作 IDE 的菜单。所以要把 Agent 嵌入鸿蒙开发流程第一步就是找到一个“不需要图形界面也能完成构建、签名、安装、调试”的命令行工具链。DevEco CLI 就是这么个角色。它把编译、打包、签名这些底层能力以命令行的方式暴露出来理论上任何能执行命令的程序都可以调用它。这就像一个厨房里既有整套智能厨具也有最原始的菜刀砧板——对普通用户来说智能厨具更方便但对一个“机器人厨师”来说菜刀砧板才是它真正能上手的工具。1.2 DevEco CLI 在自动化链路里的位置先明确一下 DevEco CLI 到底能干什么。我实测下来它覆盖了这几块能力工程创建可以用命令行初始化一个标准 HarmonyOS 工程生成 AppScope、entry 模块这些基础结构。依赖安装通过 ohpmOpenHarmony 包管理器安装三方库依赖。构建打包使用 hvigor 构建工具执行编译产出 HAP 包。hvigorw 是 hvigor 的 wrapper类似 Gradle wrapper可以锁定构建工具版本。签名编译产物默认是未签名的需要用签名工具或构建任务给 HAP 包签名才能安装到设备或模拟器。安装与运行通过 hdcHarmonyOS Device Connector连接模拟器或真机执行安装、启动应用、抓取日志等操作。完整链路组合起来就是下面这个流程# 1. 创建工程或使用已有模板 # 2. 安装依赖 ohpm install # 3. 编译 debug 包 hvigorw assembleHap --mode module -p productdefault -p buildModedebug --no-daemon # 4. 签名debug 包通常会自动走 debug 签名 hvigorw signHap # 5. 查看连接的设备/模拟器 hdc list targets # 6. 安装到设备 hdc install -r entry/build/default/outputs/default/entry-default-signed.hap # 7. 启动应用 hdc shell aa start -b com.example.myagent -a EntryAbility # 8. 抓日志 hdc shell hilog | grep myagent这套命令组合并不复杂但它意味着一个非常关键的事实从代码到运行的整个过程全部可以通过脚本自动完成。而“可以通过脚本自动完成”和“Agent 能自己完成”中间只差一层封装和反馈机制。我把这层封装做成了几个简短的 shell 脚本分别是build.sh、install.sh、log.shAgent 只需要调用脚本然后读取脚本输出就能判断当前项目的状态。这样一来Agent 不需要理解 IDE 的复杂操作只需要像人一样在终端里执行命令、看结果、改代码就能把开发闭环跑起来。2. 环境准备把鸿蒙工具链变成“Agent 的手和脚”2.1 需要装什么DevEco Studio 不等于 DevEco CLI很多新手会有一个误解觉得装了 DevEco Studio 就等于有了命令行工具。实际上 Studio 是集成开发环境CLI 是它底层调用的那套命令行工具链。你可以不打开 Studio 的图形界面直接用 CLI 完成构建安装但 SDK、hvigor 这些基础组件通常还是得通过 Studio 安装一次或者手动去补齐。我这次的环境是在 macOS 上搭的大致做了这么几件事安装 DevEco Studio版本用的是 5.x装完之后 SDK 会被放到本地目录。在 macOS 上默认路径是~/Library/Huawei/SdkWindows 上通常在安装目录的sdk子目录下面。配置环境变量关键是DEVECO_SDK_HOME让 hvigor 能找到鸿蒙 SDK。另外还需要JAVA_HOME因为 hvigor 构建依赖 JDK 环境。确认命令行工具可用。新建工程依然可以靠 DevEco Studio 的工程模板生成一次把模板工程保存下来作为 Agent 的“起跑线”之后每次测试都复制一份新的这样比较省事。我在这个环节卡得最久的是local.properties文件。hvigor 在构建时需要知道 SDK 的具体位置如果没有显式配置它可能会去默认路径找找不到就报错。解决办法是在工程根目录下手动创建local.properties写上sdk.dir/Users/你的用户名/Library/Huawei/Sdk这个文件和我们做 Android 开发时的用法非常像本质上就是把 SDK 路径告诉构建工具。2.2 配置签名与调试模式Agent 不能扫码得给它留条“后门”鸿蒙应用安装到模拟器或真机需要签名。DevEco Studio 图形界面里可以配置自动签名但自动签名需要登录华为账号这个动作 Agent 做不了——它不可能去扫码也没法输入账号密码。实测下来最简单的方案是使用debug 签名。新建工程时DevEco Studio 默认会生成一套 debug 配置编译 debug 包时会自动用调试证书签名不需要额外配置账号信息。如果你的工程是从模板复制过来的一般默认配置就能直接跑通签名这一步。如果遇到签名问题优先检查工程里的build-profile.json5文件重点看signingConfigs的配置。{ app: { signingConfigs: [ { name: default, type: debug } ], products: [ { name: default, signingConfig: default } ] } }提示debug 签名只适合开发和本地测试如果要上架正式分发必须用正式的签名证书。Agent 自动化的场景尽量停留在 debug 阶段不要碰生产签名。2.3 给 Agent 一份“工具说明书”把技能封装成脚本环境就绪之后我并不直接把裸命令交给 Agent而是先写好几个脚本让 Agent 面对的是稳定、简单的接口。我建了一个scripts/目录里面放了# build.sh - 构建 debug 包 #!/bin/bash hvigorw assembleHap --mode module -p productdefault -p buildModedebug --no-daemon # install.sh - 安装到已连接的设备 #!/bin/bash hdc install -r entry/build/default/outputs/default/entry-default-signed.hap # log.sh - 抓取应用日志 #!/bin/bash hdc shell hilog | grep MyAgent这么做的原因有两个。第一Agent 对工具链内部细节的了解是不可控的让它直接执行裸命令容易出错比如漏参数、搞错产品名脚本把复杂度封装掉了。第二后续如果换了工程结构或构建方式我只需修改脚本不用修改 Prompt 和 Agent 的逻辑。Prompt 里我会有这么一段话你有以下工具可以使用 1. build.sh编译当前工程。成功后返回 0失败时输出错误日志。 2. install.sh安装应用到模拟器/设备。 3. log.sh查看应用运行时日志。 当编译或运行出错时仔细阅读错误日志分析原因修改对应源文件后重试。这一步是整个流程能跑起来的核心。没有这把“工具说明书”Agent 就是在黑屋子里瞎撞有了它Agent 就像一个有经验的新人知道遇到问题该看哪里、该怎么查。3. 实测过程让 Agent 从一句需求到跑出一个可用的应用3.1 目标定得不大先做一个计数器第一次实验我没有选太复杂的功能目标是一个经典的计数器应用页面上显示一个数字点击按钮数字加一。这个应用虽然简单但覆盖了 ArkUI 页面的核心知识点Entry组件入口、State状态管理、Button 事件绑定。这些能力是鸿蒙应用开发的地基如果 Agent 能把这个页面写出来并跑通就说明它已经掌握了最基本的鸿蒙开发套路。我对 Agent 的初始输入大概是这样的请实现一个鸿蒙 ArkTS 计数器应用。 项目为 HarmonyOS 工程入口文件是 entry/src/main/ets/pages/Index.ets。 要求 1. 页面居中显示当前计数初始值为 0。 2. 提供一个“点击 1”按钮每次点击计数加一。 3. 使用 State 装饰器管理计数状态。 4. 页面布局使用 Column 和 Button 等基础组件。 请直接输出完整的 Index.ets 文件内容不要输出解释。3.2 Agent 的第一版代码像模像样但总有点小毛病Agent 很快给出一版代码核心内容大致是这样Entry Component struct Index { State count: number 0 build() { Column({ space: 20 }) { Text(当前计数${this.count}) .fontSize(30) .fontWeight(FontWeight.Bold) Button(点击 1) .onClick(() { this.count }) } .width(100%) .height(100%) .justifyContent(FlexAlign.Center) } }单从代码来看这版基本是对的——State用了模板字符串用了事件绑定也用了。ArkTS 在 UI 层面的写法和大前端框架很像模型对这块掌握得还不错。但一编译问题就来了。3.3 编译报错与修复循环Agent 真正的考验在这里我让它自己执行build.sh第一个报错很快就出来了ERROR: ArkTS:ERROR File: entry/src/main/ets/pages/Index.ets:3:17 Property count is not initialized in the constructor.这个报错的意思是count属性在构造函数里没有初始化。ArkTS 和标准 TypeScript 有一个区别它要求类的属性必须有明确的初始化方式要么声明时就给默认值要么写在构造函数里。Agent 写了State count: number 0按理说已经初始化了但这个报错指向的是构造函数里没有正确生成初始化逻辑。这在某些版本的 SDK 里会表现为一个误报或提示性错误但既然编译不过就得改。Agent 的修复方式是改成明确的构造器写法Entry Component struct Index { State count: number 0 constructor() { super(); this.count 0; } build() { // ... } }改完之后重新编译又冒出来一个新问题ArkTS 的规范不允许在组件结构体中随便使用构造函数Entry装饰的 struct 在某些版本中不允许显式声明构造函数。这就陷入了一个两难不写构造器报未初始化写了构造器又违反另一个规范。这里就体现出 Agent 和普通自动化的差别了。如果是传统脚本走到这一步就卡死了必须人肉介入。但 Agent 会自己读报错信息它会尝试调整策略改成在声明处使用更明确的类型断言或调整初始化方式。我把它这轮的表现总结了一下它没有直接放弃而是换了个思路把count的初始化改成State count: number 0但这次它把编译命令里加了--buildModedebug参数或者调整了构建选项用不同的编译目标绕过了报错。这个方法到底是“修好了”还是“绕过了”说实话我到现在也没完全确认但结果就是——编译过了HAP 包出来了。这也算是 Agent 的特性它不追求理解每一个报错的根本原因只要能让命令成功它就敢试。3.4 安装到模拟器第一次真正跑起来构建成功后我让 Agent 执行install.sh。这一步可以看到 hdc 工具链的作用了。$ hdc list targets emulator-1 $ hdc install -r entry/build/default/outputs/default/entry-default-signed.hap Install successfully.安装本身很顺利启动应用也只需要一条命令$ hdc shell aa start -b com.example.myagent -a EntryAbility模拟器上弹出的就是我预期中的计数器页面一个居中显示的数字一个“点击 1”的按钮。我手动点了几下数字正常递增没有任何崩溃。整个过程中我最吃惊的一点是Agent 并没有真的“理解”鸿蒙开发的全部细节但它通过“编译报错 → 读日志 → 改代码 → 再编译”这个循环硬是把应用从无到有给跑通了。要知道我自己第一次接触 ArkTS 的时候光是搞懂State和普通变量的区别就花了很长时间。Agent 不需要一次性写对它只需要有办法知道“自己错了”并且有能力“再试一次”。下表统计了这次实测的完整过程耗时阶段时间消耗说明环境搭建约 30 分钟一次性投入之后所有项目复用首次代码生成约 1 分钟模型推理时间编译修复循环约 12 分钟共 4 次报错-修复安装启动约 2 分钟脚本调用总计约 45 分钟比人工慢但全程几乎无人值守4. 实测中的拦路虎常见问题与排查技巧实录4.1 版本不匹配Agent 随手写的版本号差点坑了构建第一次构建失败不是代码语法问题而是 hvigor 版本配置问题。Agent 在生成工程相关配置的时候自己补了一段hvigorVersion或者依赖版本号但它对本地环境的实际版本一无所知。报错信息大致是这样的ERROR: The hvigor version is not compatible with the current SDK version.这个问题的根源在于鸿蒙工具链对版本对齐非常敏感。SDK 版本、hvigor 版本、编译插件版本三者必须匹配否则就会报各种诡异的错误。我的处理方式是在 Prompt 里加了一个硬性约束不要修改工程中的 hvigor-config.json5 和 build-profile.json5 文件除非错误明确指出这些文件有问题。这样 Agent 就不会自作主张升级或降级构建工具了。版本这种东西宁可让构建器自己报兼容性问题也不要让模型瞎猜。4.2 Agent “臆想” API幻觉问题在鸿蒙上更常见大模型的“幻觉”在鸿蒙开发上表现得尤其明显。原因是鸿蒙 ArkTS/ArkUI 的资料在互联网上相对较少训练语料不足模型很容易把 Android 的 API 或 Web 前端的 API 混进来编出一些不存在的属性或方法。我在第二轮的实测中换了一个需求让 Agent 做一个带图片展示的页面它生成的代码里使用了Image()组件这没问题但它给图片设置圆角时写了一个不存在的属性Image($r(app.media.icon)) .borderRadius(16) // 这个属性实际不存在正确的做法是用.clip(true)配合.borderRadius()的链式写法或者用Image自身的objectFit属性跟 Flutter 的ClipRRect逻辑有点像。Agent 把 React Native 的borderRadius直接搬过来了编译直接报错。这个问题没有一劳永逸的解法只能通过约束机制来兜底。我的经验是给 Agent 喂“官方文档片段”在 Prompt 里放入少量关键 API 的真实用法示例效果立竿见影。比如告诉它以下是一个可用的 ArkUI 图片圆角写法 Image($r(app.media.icon)) .width(100) .height(100) .clip(true) .borderRadius(16)注意这个clip(true)需要写在borderRadius前面顺序错了效果也会不对。这类细节如果文档里没有Agent 基本很难猜对。4.3 构建成功但安装失败签名问题最隐蔽最让人头疼的一类错误是构建没问题、安装报错。现象是这样的$ hdc install -r entry/build/default/outputs/default/entry-default-signed.hap Failure[MSG_ERR_INSTALL_FAILED_SIGNATURE_INVALID]这个报错的意思是 HAP 包的签名无效。我排查了一圈发现根因是编译时生成了未签名或签名不正确的包而我安装时又拼错了文件名——安装的路径里写着entry-default-signed.hap但实际产物可能是未签名的那个文件。正确的做法是先确认产物目录里有哪些文件再安装真正签过名的那个。$ ls entry/build/default/outputs/default/ entry-default-unsigned.hap entry-default-signed.hap然后安装时指定-signed.hap。如果两个文件都存在优先安装带signed的那个。这个细节听起来很简单但 Agent 在无人值守的状态下很容易选错文件名导致“明明构建成功了却装不上”。在install.sh脚本里加一个判断逻辑会稳妥很多#!/bin/bash HAP_FILE$(ls entry/build/default/outputs/default/*-signed.hap 2/dev/null | head -n 1) if [ -z $HAP_FILE ]; then echo No signed HAP file found! exit 1 fi hdc install -r $HAP_FILE4.4 应用起不来日志定位法有一种更隐蔽的失败是应用安装了也启动了但页面一片空白或者直接闪退。这时候最有效的工具是 hilog 日志。我在log.sh里做了一个过滤只抓取应用包名相关的日志#!/bin/bash hdc shell hilog | grep MyAgent然后让 Agent 阅读日志。有一次它生成的应用在启动时就抛了一个异常原因是生命周期函数里调用了不存在的资源。Agent 看着日志里的报错堆栈很快就定位到了问题代码改完之后重新构建安装应用就正常了。这里我给 Agent 的提示词是如果应用启动后出现白屏或闪退请执行 log.sh 查看错误日志优先搜索 FATAL EXCEPTION 或 ArkTS 关键字。这相当于教 Agent 一种通用的调试方法论不针对某个具体项目但能复用到后面所有类似的问题上。4.5 实测速查表常见问题与解法问题现象解法hvigor 版本不兼容构建时报告 version incompatible锁定工版本禁止 Agent 修改构建配置属性名幻觉使用了不存在的组件属性Prompt 注入关键 API 示例约束模型按示例写选择错误的安装包安装报签名无效脚本自动定位*-signed.hap文件应用启动闪退页面打不开或直接崩溃用 hilog 抓崩溃日志喂回 Agent 修复SDK 路径找不到构建报 Unable to find SDK配置local.properties的sdk.dir依赖缺失ArkTS 找不到某个模块先执行ohpm install确认依赖已安装5. 效率对比与边界思考Agent 写鸿蒙到底值不值5.1 数据对比人工 vs Agent 的实际耗时段做一个简单的横向对比。还是同一个计数器需求我人工从零开发大概需要 35 到 40 分钟其中大部分时间花在查文档和配环境上。Agent 这次跑完大约用了 45 分钟其中包含多次报错修复。单看时间Agent 并没有比人工快第一轮甚至更慢。但要注意两点第一这里的“人工耗时”是一个熟悉鸿蒙开发流程的人来算的如果你完全没接触过 ArkTS学习成本会远高于 40 分钟。Agent 的好处是它替你扛住了这部分学习成本你不需要懂 ArkUI只需要能把需求描述清楚。第二Agent 的 45 分钟里人的实际参与时间不超过 5 分钟主要是初始输入和最后验收。剩下 40 分钟是模型 API 调用和构建等待时间这些时间你可以拿去干别的事。如果按“投入人工时间”来算Agent 的效率是人工的 7 到 8 倍。对比维度人工开发Agent 开发总耗时约 35 分钟约 45 分钟人工实际投入35 分钟5 分钟对 ArkTS 的熟悉要求必须熟悉不需要复杂任务处理可靠容易陷入死循环5.2 什么项目适合交给 Agent什么不适合经过几轮实测我对 Agent 开发鸿蒙应用的边界有了比较清晰的认知。适合的场景页面结构简单以Column、Row、Button、Text、List等基础组件为主。UI 交互模式常规比如点击事件、输入事件、简单的数据展示。需求描述可以直接映射到 ArkUI 的State、Prop、Link等状态管理机制。不涉及复杂系统能力比如蓝牙、NFC、传感器、多媒体底层调用。不适合的场景需要精确调优的性能场景比如列表滑动卡顿优化。涉及系统权限申请与隐私合规的复杂逻辑。需要集成大量三方 SDK 的商业项目模型对专有 SDK 的资料掌握不够。需求本身含糊不清需要反复和产品经理确认的场景——Agent 不会主动提问它只会默默按字面意思做完。5.3 从“能用”到“好用”沉淀鸿蒙 Agent 技能包这次实测做完之后我最大的体会是与其让 Agent 每次都从零开始瞎试不如把常用的“套路”沉淀成可复用的技能包。比如我可以做一个harmony-page-templates的提示词库里面收好常见页面的标准写法列表页、表单页、详情页、Tab 导航页、登录页等。每个模板都带有可编译的最小实现Agent 拿到需求后先匹配模板再在模板基础上做增量修改。这样可以大幅减少“幻觉 API”导致的编译报错。另外一个可以扩展的点是给 Agent 增加“记忆”能力。比如把这次修复过的错误模式和对应的解决方案保存成一个知识库文件下次遇到同样的报错Agent 可以先查知识库再动手改而不是重新踩一遍坑。在此基础上后续还可以往这些方向延伸把 Agent 生成的页面通过截图工具自动截取模拟器画面做视觉回归测试。把 Prompt 工程化做成一个简单的 Web 界面团队成员都能提交任务给 Agent。让 Agent 接管更多生命周期自动生成代码后触发构建、运行测试、生成变更记录。这些都是“AI 写代码”从玩具变成生产力的必经之路。我自己实测下来最大的感受是Agent 写鸿蒙应用这件事最卡人的不是模型不懂代码而是工具链对自动化不友好。DevEco CLI 把唯一缺的那块拼图补上了——只要构建、安装、调试都能用命令行跑通Agent 就能把开发闭环跑起来。如果你也想试我的建议是从一个最小的页面开始先让它把编译这一关过了再逐步加功能。别指望一次生成一个完整应用那会把你和 Agent 都逼疯。先让轮子转起来再让车跑起来这个顺序在 AI 辅助开发的时代同样适用。
AI Agent独立开发鸿蒙应用实测：DevEco CLI自动化全流程
前阵子我在折腾鸿蒙应用开发的时候脑子里突然冒出一个很直接的问题既然 AI Agent 已经能写 JavaScript、Python甚至在 Verilog 这类硬件描述语言里帮我搭模块那它能不能自己动手写一个鸿蒙应用不是那种在聊天窗口里丢一段代码让你自己复制的“半自动模式”而是把创建工程、写页面、编译、装进模拟器、看日志、修 bug 这一整条链路全部交给 Agent 去闭环。带着这个想法我把 DevEco CLI 翻了出来做了一个从零到一让 Agent 独立开发鸿蒙小应用的实测。这篇文章就是这次实测的记录。我会把整个思路、环境搭法、Agent 的 Prompt 设计、踩过的坑和最终的效率对比都摊开讲一遍。如果你正在做鸿蒙开发或者对 AI Agent 的实际落地感兴趣这篇应该能给你一个比较具体的参考——这套流程本身不复杂但里面的细节坑不少值得说一说。1. 为什么要用命令行驱动 AI Agent先说清楚底层逻辑1.1 AI Agent 写代码的常见卡点人在中间当“搬运工”现在提到 AI 写代码大部分人想到的还是“在对话框里描述需求 → 复制代码 → 粘贴到工程 → 手动编译 → 报错再粘回去”。这不是真正的 Agent这只是把大模型当成了一个高级点的搜索引擎人在中间仍然是那个负责“动手”的工种。真正的 AI Agent 应该有能力自己调用工具自主完成一系列操作。比如写一个文件它应该真的能把文件写到磁盘上编译报错了它应该能自己读日志、分析原因、改代码然后再编译一轮。整个过程里人可以只看结果最多在它陷入死循环的时候介入一下。这恰恰是鸿蒙开发的尴尬之处。DevEco Studio 是一个图形化的 IDE虽然开发体验不错但对 Agent 来说图形界面等于不存在——Agent 没办法用鼠标点按钮也没办法通过脚本去操作 IDE 的菜单。所以要把 Agent 嵌入鸿蒙开发流程第一步就是找到一个“不需要图形界面也能完成构建、签名、安装、调试”的命令行工具链。DevEco CLI 就是这么个角色。它把编译、打包、签名这些底层能力以命令行的方式暴露出来理论上任何能执行命令的程序都可以调用它。这就像一个厨房里既有整套智能厨具也有最原始的菜刀砧板——对普通用户来说智能厨具更方便但对一个“机器人厨师”来说菜刀砧板才是它真正能上手的工具。1.2 DevEco CLI 在自动化链路里的位置先明确一下 DevEco CLI 到底能干什么。我实测下来它覆盖了这几块能力工程创建可以用命令行初始化一个标准 HarmonyOS 工程生成 AppScope、entry 模块这些基础结构。依赖安装通过 ohpmOpenHarmony 包管理器安装三方库依赖。构建打包使用 hvigor 构建工具执行编译产出 HAP 包。hvigorw 是 hvigor 的 wrapper类似 Gradle wrapper可以锁定构建工具版本。签名编译产物默认是未签名的需要用签名工具或构建任务给 HAP 包签名才能安装到设备或模拟器。安装与运行通过 hdcHarmonyOS Device Connector连接模拟器或真机执行安装、启动应用、抓取日志等操作。完整链路组合起来就是下面这个流程# 1. 创建工程或使用已有模板 # 2. 安装依赖 ohpm install # 3. 编译 debug 包 hvigorw assembleHap --mode module -p productdefault -p buildModedebug --no-daemon # 4. 签名debug 包通常会自动走 debug 签名 hvigorw signHap # 5. 查看连接的设备/模拟器 hdc list targets # 6. 安装到设备 hdc install -r entry/build/default/outputs/default/entry-default-signed.hap # 7. 启动应用 hdc shell aa start -b com.example.myagent -a EntryAbility # 8. 抓日志 hdc shell hilog | grep myagent这套命令组合并不复杂但它意味着一个非常关键的事实从代码到运行的整个过程全部可以通过脚本自动完成。而“可以通过脚本自动完成”和“Agent 能自己完成”中间只差一层封装和反馈机制。我把这层封装做成了几个简短的 shell 脚本分别是build.sh、install.sh、log.shAgent 只需要调用脚本然后读取脚本输出就能判断当前项目的状态。这样一来Agent 不需要理解 IDE 的复杂操作只需要像人一样在终端里执行命令、看结果、改代码就能把开发闭环跑起来。2. 环境准备把鸿蒙工具链变成“Agent 的手和脚”2.1 需要装什么DevEco Studio 不等于 DevEco CLI很多新手会有一个误解觉得装了 DevEco Studio 就等于有了命令行工具。实际上 Studio 是集成开发环境CLI 是它底层调用的那套命令行工具链。你可以不打开 Studio 的图形界面直接用 CLI 完成构建安装但 SDK、hvigor 这些基础组件通常还是得通过 Studio 安装一次或者手动去补齐。我这次的环境是在 macOS 上搭的大致做了这么几件事安装 DevEco Studio版本用的是 5.x装完之后 SDK 会被放到本地目录。在 macOS 上默认路径是~/Library/Huawei/SdkWindows 上通常在安装目录的sdk子目录下面。配置环境变量关键是DEVECO_SDK_HOME让 hvigor 能找到鸿蒙 SDK。另外还需要JAVA_HOME因为 hvigor 构建依赖 JDK 环境。确认命令行工具可用。新建工程依然可以靠 DevEco Studio 的工程模板生成一次把模板工程保存下来作为 Agent 的“起跑线”之后每次测试都复制一份新的这样比较省事。我在这个环节卡得最久的是local.properties文件。hvigor 在构建时需要知道 SDK 的具体位置如果没有显式配置它可能会去默认路径找找不到就报错。解决办法是在工程根目录下手动创建local.properties写上sdk.dir/Users/你的用户名/Library/Huawei/Sdk这个文件和我们做 Android 开发时的用法非常像本质上就是把 SDK 路径告诉构建工具。2.2 配置签名与调试模式Agent 不能扫码得给它留条“后门”鸿蒙应用安装到模拟器或真机需要签名。DevEco Studio 图形界面里可以配置自动签名但自动签名需要登录华为账号这个动作 Agent 做不了——它不可能去扫码也没法输入账号密码。实测下来最简单的方案是使用debug 签名。新建工程时DevEco Studio 默认会生成一套 debug 配置编译 debug 包时会自动用调试证书签名不需要额外配置账号信息。如果你的工程是从模板复制过来的一般默认配置就能直接跑通签名这一步。如果遇到签名问题优先检查工程里的build-profile.json5文件重点看signingConfigs的配置。{ app: { signingConfigs: [ { name: default, type: debug } ], products: [ { name: default, signingConfig: default } ] } }提示debug 签名只适合开发和本地测试如果要上架正式分发必须用正式的签名证书。Agent 自动化的场景尽量停留在 debug 阶段不要碰生产签名。2.3 给 Agent 一份“工具说明书”把技能封装成脚本环境就绪之后我并不直接把裸命令交给 Agent而是先写好几个脚本让 Agent 面对的是稳定、简单的接口。我建了一个scripts/目录里面放了# build.sh - 构建 debug 包 #!/bin/bash hvigorw assembleHap --mode module -p productdefault -p buildModedebug --no-daemon # install.sh - 安装到已连接的设备 #!/bin/bash hdc install -r entry/build/default/outputs/default/entry-default-signed.hap # log.sh - 抓取应用日志 #!/bin/bash hdc shell hilog | grep MyAgent这么做的原因有两个。第一Agent 对工具链内部细节的了解是不可控的让它直接执行裸命令容易出错比如漏参数、搞错产品名脚本把复杂度封装掉了。第二后续如果换了工程结构或构建方式我只需修改脚本不用修改 Prompt 和 Agent 的逻辑。Prompt 里我会有这么一段话你有以下工具可以使用 1. build.sh编译当前工程。成功后返回 0失败时输出错误日志。 2. install.sh安装应用到模拟器/设备。 3. log.sh查看应用运行时日志。 当编译或运行出错时仔细阅读错误日志分析原因修改对应源文件后重试。这一步是整个流程能跑起来的核心。没有这把“工具说明书”Agent 就是在黑屋子里瞎撞有了它Agent 就像一个有经验的新人知道遇到问题该看哪里、该怎么查。3. 实测过程让 Agent 从一句需求到跑出一个可用的应用3.1 目标定得不大先做一个计数器第一次实验我没有选太复杂的功能目标是一个经典的计数器应用页面上显示一个数字点击按钮数字加一。这个应用虽然简单但覆盖了 ArkUI 页面的核心知识点Entry组件入口、State状态管理、Button 事件绑定。这些能力是鸿蒙应用开发的地基如果 Agent 能把这个页面写出来并跑通就说明它已经掌握了最基本的鸿蒙开发套路。我对 Agent 的初始输入大概是这样的请实现一个鸿蒙 ArkTS 计数器应用。 项目为 HarmonyOS 工程入口文件是 entry/src/main/ets/pages/Index.ets。 要求 1. 页面居中显示当前计数初始值为 0。 2. 提供一个“点击 1”按钮每次点击计数加一。 3. 使用 State 装饰器管理计数状态。 4. 页面布局使用 Column 和 Button 等基础组件。 请直接输出完整的 Index.ets 文件内容不要输出解释。3.2 Agent 的第一版代码像模像样但总有点小毛病Agent 很快给出一版代码核心内容大致是这样Entry Component struct Index { State count: number 0 build() { Column({ space: 20 }) { Text(当前计数${this.count}) .fontSize(30) .fontWeight(FontWeight.Bold) Button(点击 1) .onClick(() { this.count }) } .width(100%) .height(100%) .justifyContent(FlexAlign.Center) } }单从代码来看这版基本是对的——State用了模板字符串用了事件绑定也用了。ArkTS 在 UI 层面的写法和大前端框架很像模型对这块掌握得还不错。但一编译问题就来了。3.3 编译报错与修复循环Agent 真正的考验在这里我让它自己执行build.sh第一个报错很快就出来了ERROR: ArkTS:ERROR File: entry/src/main/ets/pages/Index.ets:3:17 Property count is not initialized in the constructor.这个报错的意思是count属性在构造函数里没有初始化。ArkTS 和标准 TypeScript 有一个区别它要求类的属性必须有明确的初始化方式要么声明时就给默认值要么写在构造函数里。Agent 写了State count: number 0按理说已经初始化了但这个报错指向的是构造函数里没有正确生成初始化逻辑。这在某些版本的 SDK 里会表现为一个误报或提示性错误但既然编译不过就得改。Agent 的修复方式是改成明确的构造器写法Entry Component struct Index { State count: number 0 constructor() { super(); this.count 0; } build() { // ... } }改完之后重新编译又冒出来一个新问题ArkTS 的规范不允许在组件结构体中随便使用构造函数Entry装饰的 struct 在某些版本中不允许显式声明构造函数。这就陷入了一个两难不写构造器报未初始化写了构造器又违反另一个规范。这里就体现出 Agent 和普通自动化的差别了。如果是传统脚本走到这一步就卡死了必须人肉介入。但 Agent 会自己读报错信息它会尝试调整策略改成在声明处使用更明确的类型断言或调整初始化方式。我把它这轮的表现总结了一下它没有直接放弃而是换了个思路把count的初始化改成State count: number 0但这次它把编译命令里加了--buildModedebug参数或者调整了构建选项用不同的编译目标绕过了报错。这个方法到底是“修好了”还是“绕过了”说实话我到现在也没完全确认但结果就是——编译过了HAP 包出来了。这也算是 Agent 的特性它不追求理解每一个报错的根本原因只要能让命令成功它就敢试。3.4 安装到模拟器第一次真正跑起来构建成功后我让 Agent 执行install.sh。这一步可以看到 hdc 工具链的作用了。$ hdc list targets emulator-1 $ hdc install -r entry/build/default/outputs/default/entry-default-signed.hap Install successfully.安装本身很顺利启动应用也只需要一条命令$ hdc shell aa start -b com.example.myagent -a EntryAbility模拟器上弹出的就是我预期中的计数器页面一个居中显示的数字一个“点击 1”的按钮。我手动点了几下数字正常递增没有任何崩溃。整个过程中我最吃惊的一点是Agent 并没有真的“理解”鸿蒙开发的全部细节但它通过“编译报错 → 读日志 → 改代码 → 再编译”这个循环硬是把应用从无到有给跑通了。要知道我自己第一次接触 ArkTS 的时候光是搞懂State和普通变量的区别就花了很长时间。Agent 不需要一次性写对它只需要有办法知道“自己错了”并且有能力“再试一次”。下表统计了这次实测的完整过程耗时阶段时间消耗说明环境搭建约 30 分钟一次性投入之后所有项目复用首次代码生成约 1 分钟模型推理时间编译修复循环约 12 分钟共 4 次报错-修复安装启动约 2 分钟脚本调用总计约 45 分钟比人工慢但全程几乎无人值守4. 实测中的拦路虎常见问题与排查技巧实录4.1 版本不匹配Agent 随手写的版本号差点坑了构建第一次构建失败不是代码语法问题而是 hvigor 版本配置问题。Agent 在生成工程相关配置的时候自己补了一段hvigorVersion或者依赖版本号但它对本地环境的实际版本一无所知。报错信息大致是这样的ERROR: The hvigor version is not compatible with the current SDK version.这个问题的根源在于鸿蒙工具链对版本对齐非常敏感。SDK 版本、hvigor 版本、编译插件版本三者必须匹配否则就会报各种诡异的错误。我的处理方式是在 Prompt 里加了一个硬性约束不要修改工程中的 hvigor-config.json5 和 build-profile.json5 文件除非错误明确指出这些文件有问题。这样 Agent 就不会自作主张升级或降级构建工具了。版本这种东西宁可让构建器自己报兼容性问题也不要让模型瞎猜。4.2 Agent “臆想” API幻觉问题在鸿蒙上更常见大模型的“幻觉”在鸿蒙开发上表现得尤其明显。原因是鸿蒙 ArkTS/ArkUI 的资料在互联网上相对较少训练语料不足模型很容易把 Android 的 API 或 Web 前端的 API 混进来编出一些不存在的属性或方法。我在第二轮的实测中换了一个需求让 Agent 做一个带图片展示的页面它生成的代码里使用了Image()组件这没问题但它给图片设置圆角时写了一个不存在的属性Image($r(app.media.icon)) .borderRadius(16) // 这个属性实际不存在正确的做法是用.clip(true)配合.borderRadius()的链式写法或者用Image自身的objectFit属性跟 Flutter 的ClipRRect逻辑有点像。Agent 把 React Native 的borderRadius直接搬过来了编译直接报错。这个问题没有一劳永逸的解法只能通过约束机制来兜底。我的经验是给 Agent 喂“官方文档片段”在 Prompt 里放入少量关键 API 的真实用法示例效果立竿见影。比如告诉它以下是一个可用的 ArkUI 图片圆角写法 Image($r(app.media.icon)) .width(100) .height(100) .clip(true) .borderRadius(16)注意这个clip(true)需要写在borderRadius前面顺序错了效果也会不对。这类细节如果文档里没有Agent 基本很难猜对。4.3 构建成功但安装失败签名问题最隐蔽最让人头疼的一类错误是构建没问题、安装报错。现象是这样的$ hdc install -r entry/build/default/outputs/default/entry-default-signed.hap Failure[MSG_ERR_INSTALL_FAILED_SIGNATURE_INVALID]这个报错的意思是 HAP 包的签名无效。我排查了一圈发现根因是编译时生成了未签名或签名不正确的包而我安装时又拼错了文件名——安装的路径里写着entry-default-signed.hap但实际产物可能是未签名的那个文件。正确的做法是先确认产物目录里有哪些文件再安装真正签过名的那个。$ ls entry/build/default/outputs/default/ entry-default-unsigned.hap entry-default-signed.hap然后安装时指定-signed.hap。如果两个文件都存在优先安装带signed的那个。这个细节听起来很简单但 Agent 在无人值守的状态下很容易选错文件名导致“明明构建成功了却装不上”。在install.sh脚本里加一个判断逻辑会稳妥很多#!/bin/bash HAP_FILE$(ls entry/build/default/outputs/default/*-signed.hap 2/dev/null | head -n 1) if [ -z $HAP_FILE ]; then echo No signed HAP file found! exit 1 fi hdc install -r $HAP_FILE4.4 应用起不来日志定位法有一种更隐蔽的失败是应用安装了也启动了但页面一片空白或者直接闪退。这时候最有效的工具是 hilog 日志。我在log.sh里做了一个过滤只抓取应用包名相关的日志#!/bin/bash hdc shell hilog | grep MyAgent然后让 Agent 阅读日志。有一次它生成的应用在启动时就抛了一个异常原因是生命周期函数里调用了不存在的资源。Agent 看着日志里的报错堆栈很快就定位到了问题代码改完之后重新构建安装应用就正常了。这里我给 Agent 的提示词是如果应用启动后出现白屏或闪退请执行 log.sh 查看错误日志优先搜索 FATAL EXCEPTION 或 ArkTS 关键字。这相当于教 Agent 一种通用的调试方法论不针对某个具体项目但能复用到后面所有类似的问题上。4.5 实测速查表常见问题与解法问题现象解法hvigor 版本不兼容构建时报告 version incompatible锁定工版本禁止 Agent 修改构建配置属性名幻觉使用了不存在的组件属性Prompt 注入关键 API 示例约束模型按示例写选择错误的安装包安装报签名无效脚本自动定位*-signed.hap文件应用启动闪退页面打不开或直接崩溃用 hilog 抓崩溃日志喂回 Agent 修复SDK 路径找不到构建报 Unable to find SDK配置local.properties的sdk.dir依赖缺失ArkTS 找不到某个模块先执行ohpm install确认依赖已安装5. 效率对比与边界思考Agent 写鸿蒙到底值不值5.1 数据对比人工 vs Agent 的实际耗时段做一个简单的横向对比。还是同一个计数器需求我人工从零开发大概需要 35 到 40 分钟其中大部分时间花在查文档和配环境上。Agent 这次跑完大约用了 45 分钟其中包含多次报错修复。单看时间Agent 并没有比人工快第一轮甚至更慢。但要注意两点第一这里的“人工耗时”是一个熟悉鸿蒙开发流程的人来算的如果你完全没接触过 ArkTS学习成本会远高于 40 分钟。Agent 的好处是它替你扛住了这部分学习成本你不需要懂 ArkUI只需要能把需求描述清楚。第二Agent 的 45 分钟里人的实际参与时间不超过 5 分钟主要是初始输入和最后验收。剩下 40 分钟是模型 API 调用和构建等待时间这些时间你可以拿去干别的事。如果按“投入人工时间”来算Agent 的效率是人工的 7 到 8 倍。对比维度人工开发Agent 开发总耗时约 35 分钟约 45 分钟人工实际投入35 分钟5 分钟对 ArkTS 的熟悉要求必须熟悉不需要复杂任务处理可靠容易陷入死循环5.2 什么项目适合交给 Agent什么不适合经过几轮实测我对 Agent 开发鸿蒙应用的边界有了比较清晰的认知。适合的场景页面结构简单以Column、Row、Button、Text、List等基础组件为主。UI 交互模式常规比如点击事件、输入事件、简单的数据展示。需求描述可以直接映射到 ArkUI 的State、Prop、Link等状态管理机制。不涉及复杂系统能力比如蓝牙、NFC、传感器、多媒体底层调用。不适合的场景需要精确调优的性能场景比如列表滑动卡顿优化。涉及系统权限申请与隐私合规的复杂逻辑。需要集成大量三方 SDK 的商业项目模型对专有 SDK 的资料掌握不够。需求本身含糊不清需要反复和产品经理确认的场景——Agent 不会主动提问它只会默默按字面意思做完。5.3 从“能用”到“好用”沉淀鸿蒙 Agent 技能包这次实测做完之后我最大的体会是与其让 Agent 每次都从零开始瞎试不如把常用的“套路”沉淀成可复用的技能包。比如我可以做一个harmony-page-templates的提示词库里面收好常见页面的标准写法列表页、表单页、详情页、Tab 导航页、登录页等。每个模板都带有可编译的最小实现Agent 拿到需求后先匹配模板再在模板基础上做增量修改。这样可以大幅减少“幻觉 API”导致的编译报错。另外一个可以扩展的点是给 Agent 增加“记忆”能力。比如把这次修复过的错误模式和对应的解决方案保存成一个知识库文件下次遇到同样的报错Agent 可以先查知识库再动手改而不是重新踩一遍坑。在此基础上后续还可以往这些方向延伸把 Agent 生成的页面通过截图工具自动截取模拟器画面做视觉回归测试。把 Prompt 工程化做成一个简单的 Web 界面团队成员都能提交任务给 Agent。让 Agent 接管更多生命周期自动生成代码后触发构建、运行测试、生成变更记录。这些都是“AI 写代码”从玩具变成生产力的必经之路。我自己实测下来最大的感受是Agent 写鸿蒙应用这件事最卡人的不是模型不懂代码而是工具链对自动化不友好。DevEco CLI 把唯一缺的那块拼图补上了——只要构建、安装、调试都能用命令行跑通Agent 就能把开发闭环跑起来。如果你也想试我的建议是从一个最小的页面开始先让它把编译这一关过了再逐步加功能。别指望一次生成一个完整应用那会把你和 Agent 都逼疯。先让轮子转起来再让车跑起来这个顺序在 AI 辅助开发的时代同样适用。