AI 写的鸿蒙应用真能运行吗？设备到日志六项逐关验证

作者：袖梨 2026-09-14

当 AI 代理给出“应用已经可以运行”的结论时，开发者仍需确认这句话是否经过真实设备和本机工具链验证。对鸿蒙应用而言，设备连接、工程路径、签名、安装、Ability 启动和运行日志中的任何一环都可能让结果失效。下面从一条公开执行记录出发，拆解完整验证顺序及其结论边界。

让 AI 写鸿蒙应用时，最可疑的一句话往往不是“我改了代码”，而是“已经可以运行了”。代码看起来完整，不代表本机有可用设备；构建产物存在，不代表它已经完成调试签名；安装命令返回了，不代表目标 Ability 真的启动；页面刚打开，也不代表随后不会 crash。

这类“假完成”通常出现在代码生成之后、真实设备验证之前。hmharness 的做法是把这段链路显式交给工具验证：代理不能只靠推理宣布成功，而要在本机环境里确认设备、项目档案、签名、安装、启动和日志。

一句话结论

公开提交 bdc83d0 记录了一次完整的运行证据链：同一条会话 outcome=ok，共 9 次工具调用，依次覆盖：

harmony_devices
→ harmony_project_profile
→ harmony_sign
→ harmony_install
→ harmony_launch
→ harmony_logs

这条记录证明的是“本次环境完成了这组验证”，不是所有机器、所有 SDK、所有真机都必然成功。把边界放在结论前面，后面的证据才有价值。

检查点	工具	它补上的证据	如果跳过会留下什么假象
目标存在	`harmony_devices`	当前可用真机或模拟器	对不存在的 target 继续推理
项目上下文	`harmony_project_profile`	工程结构、产物和路径	猜错 HAP 路径或模块
签名完成	`harmony_sign`	调试签名处理后的产物	把未签名包当成可安装包
安装成功	`harmony_install`	包已经进入目标设备	只验证文件存在，不验证部署
启动成功	`harmony_launch`	目标 Ability 被拉起	安装成功但入口不可用
运行反馈	`harmony_logs`	启动后的真实日志	错过启动后 crash 或运行时错误

这 6 步的重点不是“多调几个工具”，而是把结论的证据类型从“模型认为”推进到“本机工具链输出”。对鸿蒙开发来说，签名配置、SDK 路径、设备连接和 Ability 启动恰恰是最容易因环境差异而断开的环节。

一个可靠的验证链应当先固定环境，再操作设备：

反过来，只要少了后两步，就很容易得到“文件已经生成”但应用不可用的半成品结论。对 AI 代理来说，这不是小概率问题：模型擅长生成看似合理的成功叙述，而设备、签名和日志不会迁就这份叙述。

提交地址：github.com/swsgbl/hmha…

hmharness 的公开证据里还保留了影响环：候选技能先进入 canary 小比例暴露，再与对照组比较成本和结果；数据不足时不冒进，表现更差则退回 draft。

在同一个 bdc83d0 记录里，3 个 canary 被判定有害并退回草稿：

候选技能	暴露组	对照组	判定
`codexhost-offline-upgrade`	8s / 50%	219s / 82%	retire
`continue-hmharness-conversation-workflow`	10s / 60%	217s / 82%	retire
`verify-before-execution-workflow`	8s / 50%	219s / 82%	retire

表里的时间和成功率只解释这次判定，不是新的性能承诺。重要的是机制方向：一个声称能自进化的系统，必须能淘汰让结果变差的候选；否则“进化”只会变成单向奖励机器。

2026-09-14 核对时，npm 最新版和公开 main 的包版本均为 0.13.3，安装要求 Node >= 22：

npm install -g @hmharness/cli
hmh init
hmh tui

这条只说明当前公开安装入口，不把 bdc83d0 的历史验证自动扩展成今天所有版本的行为结论。若你要复现设备链路，建议另外记录 OS、Node、DevEco/OpenHarmony SDK、真机或模拟器状态，以及第一条失败命令。

如果你正在试用，欢迎把环境差异反馈到 GitHub Discussions。对这类工具链项目，一条真实的 SDK/设备阻塞信息，比泛泛的点赞更有价值。