用 AI 写鸿蒙应用时最容易产生“假完成”的位置不在代码生成而在代码生成之后HAP 没有签名、签名配置和本机 SDK 不匹配、安装目标不存在、Ability 启动失败、启动后又 crash。模型一句“已经完成”并不能证明这些环节真的成立。hmharness 的价值取向是把验证链往前推不只让代理改代码还让它在本机工具链里确认设备、读取项目档案、签名、安装、启动并回读日志。2026-09-09 的公开提交bdc83d0记录了一次完整链路验证同一条会话内工具调用结果为ok共 9 次工具调用。这条链路到底验了什么公开证据中的会话依次使用了这些工具harmony_devices先确认可用的目标设备或模拟器harmony_project_profile读取项目与产物上下文避免在错误目录里猜 HAP 路径harmony_sign使用调试签名处理 HAPharmony_install把包安装到目标设备harmony_launch启动目标 Abilityharmony_logs回读运行日志让后续判断基于真实输出。这条链路的关键不是“多调用了几个工具”而是把代理的结论从“我认为能跑”推进到“签名、安装、启动和日志回读已经在本次环境完成”。对鸿蒙开发来说这正好卡在最容易断掉的几段上。公开证据在哪里看证据页由真实日志导出当前公开统计包括46 个进化轮次26 个 active 技能17 个 canary 试验中18 个 draft 技能14 个 archived 技能227 条洞察120 条长期记忆。公开提交信息如下提交地址https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f证据页地址https://swsgbl.github.io/hmharness/evidence/影响环不是只会“越学越多”自进化系统真正危险的地方是候选技能一旦晋级就很难退出来。hmharness 的 SELFFEED 记录里保留了影响环候选先进入 canary 小比例暴露再与对照组比较成本与结果数据不足时不冒进表现更差则退回 draft。这次公开记录中有 3 个 canary 被判定有害并退回草稿codexhost-offline-upgradecontinue-hmharness-conversation-workflowverify-before-execution-workflow这比“又晋升了多少技能”更重要。能淘汰变差的候选才说明进化 loop 不是单向奖励机器。边界必须说清楚这条证据证明的是在本次公开记录的环境里签名、安装、启动、日志回读链路跑通影响环能淘汰 3 个表现有害的 canary。它不证明所有机器、所有 SDK 版本、所有真机环境都必然成功hmharness 已经在普遍意义上“越用越聪明”项目获得 Huawei/OpenAtom 官方背书。hmharness 是独立 MIT 开源项目Windows 是优先验证平台macOS/Linux 属于社区支持。环境差异本身就是最重要的数据如果你试用欢迎把 OS、Node、DevEco/OpenHarmony SDK、真机或模拟器状态以及第一条失败命令反馈到 GitHub Discussions。上手入口npminstall-ghmharness/cli hmh init hmh tui相关链接GitHubhttps://github.com/swsgbl/hmharnessnpmhttps://www.npmjs.com/package/hmharness/cli证据页https://swsgbl.github.io/hmharness/evidence/提交https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f AI说能跑不算数：hmharness把鸿蒙签名安装启动一次验通
用 AI 写鸿蒙应用时最容易产生“假完成”的位置不在代码生成而在代码生成之后HAP 没有签名、签名配置和本机 SDK 不匹配、安装目标不存在、Ability 启动失败、启动后又 crash。模型一句“已经完成”并不能证明这些环节真的成立。hmharness 的价值取向是把验证链往前推不只让代理改代码还让它在本机工具链里确认设备、读取项目档案、签名、安装、启动并回读日志。2026-09-09 的公开提交bdc83d0记录了一次完整链路验证同一条会话内工具调用结果为ok共 9 次工具调用。这条链路到底验了什么公开证据中的会话依次使用了这些工具harmony_devices先确认可用的目标设备或模拟器harmony_project_profile读取项目与产物上下文避免在错误目录里猜 HAP 路径harmony_sign使用调试签名处理 HAPharmony_install把包安装到目标设备harmony_launch启动目标 Abilityharmony_logs回读运行日志让后续判断基于真实输出。这条链路的关键不是“多调用了几个工具”而是把代理的结论从“我认为能跑”推进到“签名、安装、启动和日志回读已经在本次环境完成”。对鸿蒙开发来说这正好卡在最容易断掉的几段上。公开证据在哪里看证据页由真实日志导出当前公开统计包括46 个进化轮次26 个 active 技能17 个 canary 试验中18 个 draft 技能14 个 archived 技能227 条洞察120 条长期记忆。公开提交信息如下提交地址https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f证据页地址https://swsgbl.github.io/hmharness/evidence/影响环不是只会“越学越多”自进化系统真正危险的地方是候选技能一旦晋级就很难退出来。hmharness 的 SELFFEED 记录里保留了影响环候选先进入 canary 小比例暴露再与对照组比较成本与结果数据不足时不冒进表现更差则退回 draft。这次公开记录中有 3 个 canary 被判定有害并退回草稿codexhost-offline-upgradecontinue-hmharness-conversation-workflowverify-before-execution-workflow这比“又晋升了多少技能”更重要。能淘汰变差的候选才说明进化 loop 不是单向奖励机器。边界必须说清楚这条证据证明的是在本次公开记录的环境里签名、安装、启动、日志回读链路跑通影响环能淘汰 3 个表现有害的 canary。它不证明所有机器、所有 SDK 版本、所有真机环境都必然成功hmharness 已经在普遍意义上“越用越聪明”项目获得 Huawei/OpenAtom 官方背书。hmharness 是独立 MIT 开源项目Windows 是优先验证平台macOS/Linux 属于社区支持。环境差异本身就是最重要的数据如果你试用欢迎把 OS、Node、DevEco/OpenHarmony SDK、真机或模拟器状态以及第一条失败命令反馈到 GitHub Discussions。上手入口npminstall-ghmharness/cli hmh init hmh tui相关链接GitHubhttps://github.com/swsgbl/hmharnessnpmhttps://www.npmjs.com/package/hmharness/cli证据页https://swsgbl.github.io/hmharness/evidence/提交https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f