正在加载，请稍候
鸿蒙端能自动验证的环节比 Web 端少一圈。本文用四层循环框架拆解断点，给出 linter 规则写法、人工介入位置与三个产出指标。
一家零售客户把鸿蒙版的迭代交给 AIcoding 工具后，前两周提交量涨了六成，第三周却卡在上架审核。模型没出问题，是循环的最后一环没人管。
我们在浏览器端搭 AI 辅助研发的闭环时很轻松：本地起服务、跑端到端用例、截图比对，一条命令跑完。
鸿蒙端做不到。构建产物必须装到真机上验，要在手机、折叠屏、平板几种形态上分别看，要覆盖系统版本矩阵，最后还要过应用市场的合规审核。
腾讯 QQ 飞车团队把这类工作拆成四层粒度：hook 级、CI 级、工作流结构化拆分、团队级编排。他们在 AICon 深圳站的分享里提到月消耗约三百亿 token，同时坦承非工作时间的自动循环还没真正跑起来，完整实录见这场 Loop Engineering 演讲。
把这套框架搬到鸿蒙端，我们得到一个更悲观的结论：能完整外置给机器的环节，比浏览器端少一圈。
| 端形态 | 机器可自行验证的部分 | 需要有人介入的环节 |
|---|---|---|
| 浏览器端 | 构建、单元测试、端到端用例、截图回归 | 复杂交互走查 |
| 桌面端 | 构建、单元测试、安装包冒烟 | 驱动兼容、代码签名 |
| 鸿蒙端 | 构建、静态检查、单元测试 | 真机交互、设备形态适配、上架合规 |
这张表不是说鸿蒙不适合自动化，而是提醒一件事：机器覆盖率最低的那一格，往往就是返工最集中的地方。
平台侧还有另一半解释。模型能力之外，语料与知识库同样是瓶颈，可对照鸿蒙 AI 编码的语料缺口那篇的观察：工具再强，也得先见过这个平台的写法。
我们踩的第一个坑，是把编码规范写进提示词或规则文件，指望模型每次都照做。结果是同一个错误换个写法再犯一次。
改成基于大模型的 linter 插件之后情况变了。文件落盘立刻跑增量 diff，把报错上下文回流给正在工作的代理，让它自己修；pre-commit 阶段再由 git hook 兜第二次。这套东西一天就能做出来，配置进流水线和本地开发环境即可。
那场分享里有句话我们很认同：写规则文件是在向概率模型许愿，写 linter 是把约束固化成规则。
鸿蒙端有三类问题最适合先做成规则，因为它们在 ArkTS 里出现频率最高：
第三条尤其值得警惕。类型检查是 ArkTS 相对动态语言最大的工程优势，一旦被代理用宽泛类型绕过，等于主动把优势丢掉，而编译器不会报错提醒你。
循环不等于全自动。人什么时候进循环、站在循环上、还是完全退出，得按环节分别定。
我们给鸿蒙端的划分是这样的：
| 介入方式 | 对应环节 |
|---|---|
| 完全退出，机器全权处理 | 依赖安装、编译、静态检查、单元测试、包体积检查 |
| 站在循环上，人审机器做 | 真机界面一致性、动效与手势、多设备断点布局 |
| 进入循环，人做机器不碰 | 权限声明、隐私合规文案、上架材料与审核沟通 |
「站在循环上」这一格最容易做砸。我们的做法是把它变成可回放的证据链：每轮真机验证留下录屏、设备日志、关键界面截图，下次同类改动先让机器跑一遍对比，人只看差异部分。
一个具体数字：切换方案后，一次典型的界面改动人工验证时长从约 40 分钟降到 15 分钟上下。省下来的不是钱，是让人愿意在提交前多跑一轮真机。
这套划分和我们写Web 端 AIcoding 的六组实测数据时得到的方向一致，区别只在人工份额：同一套流程搬到鸿蒙端，需要人过目的环节明显更多。
平台侧的官方入口和版本要求建议固定成一个只读清单，交给代理在改动前自行核对，可以参考华为开发者联盟的鸿蒙开发入口，把链接和版本基线写进仓库里的说明文件。
成本叙事很容易跑偏。把 token 账单当成唯一健康指标会得出错误结论，账单异常往往指向流程问题，不是单价问题，相关讨论见这篇关于账单异常的分析。
更该盯的是产出侧。我们建议只看三个指标：单需求周期，从评审到上架；缺陷回流率，同一模块两周内二次修复的占比；人工验证时长占比。前两个下降、第三个也下降，说明循环在往正方向走；只有第一个下降而另外两个上升，说明你在用机器加速制造返工。
口径本身也容易算错。团队规模不大时，先照桌面端这笔多数公司算不平的账把归集方式定下来，再谈投入。
另一个方向是还债。有团队只用了两名工程师，就把核心存储从 Python 重写成 Rust，靠的正是编码代理把技术债的偿还成本压到了人力难以想象的水平。鸿蒙端同理：早期为了赶上线写下的兼容分支，是现在最值得让代理去清理的对象，迁移时的取舍可参考清理遗留代码的三个反直觉决定。
如果拿不准自家鸿蒙端的循环断在哪一环，可以先看我们已交付的 行业案例，或直接联系我们做一次现状诊断。
生成可以，验证不行。真机交互、设备形态适配、上架合规这三类必须有人。把生成交给机器、把验证交给流程，是目前性价比最高的分工。
可以把前者看成 hook 级循环的执行者，后者看成 CI 级循环的编排者。两者不是替代关系，缺了编排层，助手只能补全下一行，改不动跨模块的结构问题。
值得，但顺序要反过来：先做 linter，再做流水线断言，最后才考虑编排。三个人的团队一上来就搭团队级编排，收益为负。
看缺陷是否同类复发。同一个错误第三次出现，说明该沉淀成规则；沉淀之后还复发，说明这一环不适合机器，把人退回来做交互验证更划算。