鸿蒙AI编码质量闭环：DevEco Code校验循环与Skill分级路由

鸿蒙专家

AI Coding正在成为移动端研发的主流范式，但鸿蒙生态在这条路上的起点和iOS、Android并不一样。Android有超过十年积累的Java/Kotlin语料，iOS也有体量可观的Swift/Objective-C代码库，而ArkTS问世时间不长，公开可得的鸿蒙代码语料非常有限。语言层面的差距会直接影响大模型的生成质量，且这是模型自身很难补足的短板。与此同时，鸿蒙的设备形态又不止直板机一种，双折叠、三折叠都需要差异化适配，同一份业务代码在不同形态上的呈现逻辑差异明显。叠加鸿蒙应用工程普遍庞大、传统IDE交互面向人而非AI工作流这两个事实，鸿蒙环境下的AI编码面对的并不是单点问题，而是四点叠加的系统性挑战。

面对这种局面，华为在工具链上采取了一套"两层工具+一个开放市场"的布局：DevEco Code定位开箱即用的Coding Agent，覆盖项目创建、需求分析、代码生成、验证、集成测试到运维的完整链路；DevEco CLI则把IDE里的能力原子化，拆成可供AI Agent直接调用的命令行工具；两者之上还有格物市场，用来聚合官方和生态伙伴的Skills、MCP工具与知识库。这套方案的核心思路是分层：面向需要快速上手的开发者提供DevEco Code，面向已有AI流水线的团队提供DevEco CLI，市场则承担能力进一步扩展的职能。

质量是AI Coding落地中最关键的一环，DevEco Code用"三循环Harness"来解决这个问题。第一个循环是轻量级语法校验，结合LSP做依赖分析与引用关系查找，让Agent在动大手术之前先理解项目结构。第二个循环是编译诊断，直接调用原子化命令行编译工具，把编译错误反馈给AI修复。第三个循环是UIAI意图功能校验，它的存在直指AI编码长期被忽视的一个盲区：编译通过不等于功能正确，功能正确不等于UI符合预期。UI验证Agent会基于多模态模型自动拉起模拟器，模拟人工的点击、滑动、长按、输入等交互操作，在执行过程中截图并生成视觉对比报告，开发者只需查看结果做决策，不必再反复手动回归验证。

代码修复Agent也是这套体系里的重要组成部分。它覆盖语法错误、类型错误、边界错误、引用错误、URI错误等十几种典型问题。针对运行时的崩溃问题，代码修复Agent还配有专属Skill：自动采集崩溃日志并做分析，基于团队对一百多个崩溃定位案例的积累，修复成功率保持在80%以上，单次崩溃能够在分钟级内完成修复。

开发模式方面，DevEco Code给出了Build、Plan+Build、Goal三种选择，方便开发者在自主度和人工介入之间取平衡。Build模式适合需求明确、追求速度的场景，Agent写完就改，几乎不需要交互。Plan+Build模式则要求先规划后执行：Plan Agent先扫描代码库、梳理依赖关系并给出结构化任务清单，由开发者确认后，Build Agent按计划逐步实施，每完成一个任务就自动构建验证。Goal模式采用的思路是SDD，也就是规格驱动开发。开发者用自然语言描述需求后，Agent会先和开发者对齐验收标准，进入自主开发循环，完成从代码生成、静态检查、修复、构建出包、推送到模拟器到功能自验证的完整链路，开发结束后模拟器会自动拉起运行，开发者只需要做最终确认。

如果说DevEco Code更多是面向人的Agent化开发环境，DevEco CLI则是在做更深层的工程化适配。它的思路很直接：传统IDE是面向人的可视化集成环境，但当AI Agent是开发主体时，GUI反而成了瓶颈。Agent想要的不是界面，而是可编程调用的原子接口。于是devecocli被拆成create、build、device、emulator、run等一条条命令，再加上check、知识检索和Skills管理入口，通过一行devecocli init就能完成鸿蒙环境初始化和Skills安装。这种"命令行即接口"的设计，让Agent可以把构建、运行、模拟器、日志、知识检索等环节串成完整的工作流。

DevEco CLI内置的官方知识库解决了另一个重要问题——语料不足。这个知识库涵盖最佳实践、开发指南、API参考、FAQ、版本说明和变更预告，总规模达到两千万字。为保证Agent使用时不会过载，知识库做了本地响应、渐进式读取、鸿蒙专有术语映射和结构化输出适配。本质上是把华为沉淀的官方结构化知识封装成Agent能直接调用的能力，在公开语料还不够厚的时候，用工程手段弥补模型在鸿蒙领域认知的不足。

Skills是这套体系的另一个关键变量，目前DevEco CLI和格物市场累计提供了70余个Skills，覆盖ArkTS语法规则、ArkUI开发技能、多设备适配、自动Bug修复、日志分析、测试与质量等场景。但Skill数量一多，问题也随之出现：大模型面对过多选择时会出现劣化，Agent往往要反复加载多个Skill才能找到真正有用的那个。为了解决这个问题，华为设计了Skill分级路由方案，把Skill拆成L0到L3四个层级。L0是ArkTS语法框架层，解决模型把ArkTS写成TS的典型问题；L1是组件与系统API层，当Agent要调用鸿蒙API时，路由到对应文档，确保系统接口使用准确；L2是工程上下文层，按当前工程的构建方式、常见错误修复路径做适配；L3是业务规则层，把业务约束和规范注入生成过程。四层遵循"先核心、后场景"的原则，先把语言和API层面的通用问题处理掉，再按工程和业务场景分发，避免把所有Skill一股脑塞进上下文造成的信息过载。

多设备适配Skills的效果可以直观说明这套机制的价值。在没有加载hmos-multidevice-scenario-entry时，AI针对双折叠屏生成的是单列布局，针对三折叠屏生成的是双列布局；叠加多设备Skill后，双折叠屏正确生成双列布局，三折叠屏也能按三列布局输出。这就是Skills对模型在鸿蒙多设备适配能力上的直接补强。

回到验证层面，华为还把"AI代码怎么验证"提炼成了HarmonyOS Verify体系，分递进四层。第一层是ETS语法检查和编译构建修复，属于最基础的静态保障。第二层是UI自动化操作加多模态图片验证：工具集模拟点击、滑动、长按、输入，Agent按需求文档执行操作后，用截图工具采集界面并交给多模态模型做视觉比对，判断实际行为是否符合预期。第三层是辅助定位工具，遇到问题不能只停留在"看到不对"，还得知道"哪里不对"——Hidumper负责打印UI元素树，协助识别组件坐标与属性，日志采集分析工具则拿到编译或运行时的实时日志，两者构成问题定位的诊断依据。第四层是一多适配验证，也就是在直板机、双折叠、三折叠、平板多种形态上自动跑验证，确认代码在不同设备形态下都能正确呈现。从静态语法、构建、运行态UI到多端一致性，正好回应了鸿蒙场景下AI Coding最难处理的那几个环节。

鸿蒙的AI Coding布局里还有几个值得长期关注的方向：鸿蒙专属高质量代码语料体系的建设、超大复杂鸿蒙工程的全局理解能力，以及长程复杂开发任务中的目标约束与分段锚定。这三件事都不能靠单点功能补丁解决，需要生态层面的持续投入。鸿蒙作为后发者，在AI Coding时代有一个结构性优势：工具链不必背负"面向人的历史包袱"，可以从零开始按AI工作流设计。DevEco Code的Agent定位、DevEco CLI的原子化拆分、格物市场的开放式聚合，都是这种思路的体现。

（本文内容整理自InfoQ技术分享，嘉宾为华为终端软件部AI技术专家许云红与Agent产品架构师姜钰潇。）

热心网友4

这个帖子信息量真大，把鸿蒙AI编码的完整链路梳理得很清楚。尤其是“三层循环Harness”这个设计，确实点到了AI编码落地的关键痛点——很多工具只顾生成代码，却忽略了编译、运行、UI验证这套闭环，最后还是要人肉去兜底。 我个人最感兴趣的是Skill分级路由的设计思路。先核心后场景，把L0语法层、L1 API层和L2/L3工程业务层剥开，确实能避免上下文被无效信息塞满。多设备适配那个例子也很直观，同一个模型有没有挂载Skill，在折叠屏布局上的输出差异居然这么大，看来官方知识库和Skill的补充真的能弥补模型语料不足的短板。 另外DevEco CLI“命令行即接口”的定位我觉得挺务实的。很多团队的CI/CD流程里已经跑着各种Agent，与其让Agent去操作GUI，不如直接给它可编程的原子命令，这样嵌入现有工作流也会顺滑很多。 想问一下楼主：实际项目里如果开发者对鸿蒙开发还不太熟，直接使用Plan+Build或者Goal模式会不会有门槛？还是说Agent能把大部分复杂度屏蔽掉，让新手也能照着流程走完？

热心网友2

楼主这篇分析把鸿蒙AI Coding的系统性挑战梳理得很清楚。公开语料少、设备形态多、工程规模大，这些问题确实是鸿蒙生态独有的，而且互相叠加，不是单点优化能解决的。尤其“三循环Harness”的设计思路很有启发，语法校验、编译诊断、UIAI功能验证层层递进，尤其是第三步把“编译通过不等于功能正确”这个盲区单独拎出来，确实是AI编码落地时容易被忽略但非常关键的一环。 Skill分级路由那部分也让人印象深刻。模型面对一堆Skill时确实容易“选择困难”，按L0到L3分层的做法相当于给Agent搭了一条清晰的决策路径，先保证语言和API层面不出大错，再进入工程和业务场景，能省下不少无效加载的上下文开销。 想请教一下楼主，三折叠屏的验证在第四层“一多适配验证”里是自动遍历所有形态，还是说也有优先级或动态路由策略？毕竟设备形态越多，验证成本也会成倍增加，不知道实际工程里是怎么平衡的。

热心网友1

这个帖子信息量真大，把鸿蒙AI编码从工具链到质量验证的逻辑讲得很完整。我特别有共鸣的是“编译通过不等于功能正确，功能正确不等于UI符合预期”这句——以前用AI生成代码，经常栽在最后这步上，能跑但界面一塌糊涂，手动回归验证又很费时间。DevEco Code那套三循环Harness相当于把“写完代码”和“真正能交付”之间的距离用工程手段补齐了。 另外Skill分级路由的思路我也觉得挺巧妙。现在各种Agent工具动不动就堆一堆插件，模型反而不知道该调哪个。按“先核心、后场景”的L0到L3分层，至少让加载顺序有了优先级，避免了上下文塞满但都用不上的尴尬。多设备适配那个例子也挺直观，同一个模型加不加Skill，生成结果差得很明显。 不过有一点我比较好奇：官方知识库两千万字听起来很庞大，但渐进式读取具体是靠什么机制做的？是Agent自己判断该读哪一段，还是路由规则先做了一层筛选？如果只是简单切块喂给模型，可能还是会碰到关键细节被截断的问题。还有三折叠的设备适配，多设备Skill能生成三列布局，但实际折叠屏铰链位置、悬停态这些动态场景也能覆盖到吗？不知道楼主的实测体验里有没有遇到过类似边界情况。