高德联合鸿蒙 DevEco CLI:鸿蒙 AI Native 规模化交付实践

一、背景与挑战
在工信部相关要求和明确交付时间点下,高德需完成鸿蒙L6级适配目标。这并非从零建设,而是基于已有鸿蒙工程,对照Android、iOS多年积累,盘点三千多项基础能力,识别到近一半需要适配和补齐。真正的难点不只在生成准确的ArkTS代码,更在于每项能力都要经过检查、编译、签名、安装、真机运行和回归验证。
面对如此庞大任务规模,单纯扩张人力或只用AI辅助编码,都无法支撑规模化交付。因此,团队推进AI Native体系化建设,将工程知识、标准化流程、执行工具、任务状态和运行证据连接起来,使AI持续执行编码、验证与修复,推动研发从局部编码提效走向规模化闭环交付。
二、建设思路:从“AI 辅助写代码”到“AI 闭环完成任务”

*初,我们让 AI 根据需求和参考代码生成 ArkTS,再由工程师修改。但实践很快证明,代码看似合理,不等于符合鸿蒙规范;能够构建安装,也不代表运行正确。如果构建、安装、验证和修复仍由人接手,AI 只是缩短了首次编码时间,无法形成规模化收益。
因此,团队将目标从“提高单次生成质量”转向“让任务端到端闭环”。一个能力项只有完成调试签名、构建、安装启动、真机功能验证、静态检查和结果归档,才算真正完成。每个动作都有明确输入和机器可读输出,失败能够触发修复,重试超过上限后再转人工。
人做决策,AI 做执行。在这一过程中,人负责需求口径、优先级、架构方向、验收标准和*终质量判断;AI 负责代码检索与生成、工具调用、构建验证、运行诊断、修复重试和结果归档。补全计划、疑难问题、Code Review、*终业务验收和代码合入仍保留人工卡点。
为让 Agent 稳定执行,团队还将重复处理路径整理为 SOP,并转化为包含输入、步骤、判断条件和输出的作业指令。目前已形成 32 项可复用工程知识,其中 14 篇为标准化 SOP。AI Native 不是让 AI 替代人,而是让人聚焦关键决策,让系统承担标准化执行。生成质量决定单轮成功率,闭环能力决定*终完成率。
三、能力体系:让 AI 知道、看见、执行并验收

通过上述整体架构图可知,Agent 要真正参与工程,需要补齐四种能力:知道约束、看见状态、能执行动作、能验收结果。
3.1 真正缺的不是更强模型,而是研发 Harness
把“修复一次 Scheme 崩溃”交给 Agent,它通常不缺生成代码的能力,真正缺的是工程上下文:代码在哪里、需要遵守什么规范、如何构建签名、怎样在真机复现,以及凭什么判断问题已经解决。这些信息分散在代码仓库、知识库、工程工具、设备状态和开发者经验中。模型即使理解需求,也无法只靠推理完成交付。
大模型提供智能,Harness 提供工程确定性。Harness 位于模型与真实鸿蒙工程之间,将需求约束、工作流、工具调用、状态记录和验收证据组织为可持续执行的工程环境。上层可以接入不同模型和 Agent,底层工程能力则持续复用。模型决定推理上限,Harness 决定交付下限。
3.2 工作流编排:不同任务不能共用一个“超级提示词”
Feature 开发、跨端转码和 Bug 修复都会产生代码,但执行路径并不相同:Feature 开发从需求和架构出发,转码关注跨平台语义与行为一致性,Bug 修复则从现场证据出发,完成定位、*小修改和场景回归。
因此,系统不依赖一个覆盖所有场景的“超级提示词”,而是由 Skill 定义不同任务的阶段、规则和工作流,Agent 按约束执行。主控流程负责阶段推进和能力调度,具体动作由下层能力完成。工作流编排的价值,不是让 Agent 一次执行更多步骤,而是让每一步都知道为何发生,失败后应该回到哪里。
3.3 业务与基建:把鸿蒙经验变成可组合能力
工作流解决“按什么顺序做”,具体任务还需要业务能力和基础能力支撑。业务能力定义多设备、深色模式、无障碍、HiCar 等场景约束,回答“这个场景必须满足什么”;基础能力封装组件、切面、NAPI 接入等稳定动作,回答“工程中有哪些能力可以直接调用”。
两类能力与知识规范结合后,Agent 可以根据任务选择约束、参照和验证方式,再组合所需动作。关键不在于沉淀多少能力,而在于每项能力边界清晰、输入输出明确,并且能够进入统一工作流。
3.4 鸿蒙系统能力:让文本真正进入工程世界
业务能力*终必须进入真实工程。鸿蒙 Skill 提供知识检索、语法检查、多设备适配和稳定性分析;DevEco CLI 提供构建、签名、安装、运行、测试及证据采集能力。两类能力共同补齐 Agent 的四个关键缺口:

其中,DevEco CLI 承担工程执行接口,把 Agent 的文本决策转化为构建产物、设备行为和运行证据。其具体能力将在下一章展开。
3.5 两条质量轨:项目评测与验证闭环
项目评测判断“是否达到交付标准”,用于统一衡量任务质量、工程结果和规模化表现,并识别持续失败的环节。验证闭环回答“真实环境里发生了什么”。编译证明代码可以构建,真机运行证明应用可以启动,UI、日志和数据链路证据才能证明业务行为正确。出现问题时,这些证据还要能够回溯到对应任务、修改和修复轮次。
项目评测给出标准,验证闭环提供事实。缺少前者,Agent 不知道何时停止;缺少后者,Agent 不知道是否真的做对。
传统 AI 辅助研发仍由人驱动,AI 只提供局部编码帮助。鸿蒙 AI Native 则从 Agent 执行任务出发,要求知识可读取、动作可调用、状态可观察、结果可判定、失败可恢复。它的先进性不在于更快生成 ArkTS,而在于把鸿蒙工程改造成 Agent 可理解、可执行、可验证、可恢复的系统。
四、华为 DevEco CLI:把文本变成真实产物

DevEco CLI 是面向 AI Agent 的 HarmonyOS 命令行开发工具集。它将构建、签名、部署、运行和验证等工程能力封装为可调用、可组合、可判断的接口,使 Agent 的工作从代码生成延伸到真实工程交付。
4.1 为什么DevEco CLI 是关键一环
大模型擅长理解需求、生成代码和分析错误,但代码文本并不等于可交付产物。在真实的鸿蒙研发中,一次修改还需要经过编译、签名、安装、启动和运行验证。传统 IDE 主要面向开发者操作,许多关键能力依赖图形界面和人工判断,Agent 即使完成了代码修改,也很难独立推进后续流程。
DevEco CLI 改变了这种交互方式。它把工程动作转化为结构化命令,把执行结果转化为退出码、日志和产物路径,使 Agent 能够连续完成:修改代码 → 构建 → 签名 → 安装 → 启动 → 验证 → 基于证据修复
因此,DevEco CLI 的价值不只是“在终端里运行 IDE 功能”,而是为 Agent 提供一套稳定的工程执行接口:动作可以调用,结果可以判断,失败可以恢复。
4.2 六个研发环节中的执行位置
围绕真机验证闭环,我们将鸿蒙研发中的关键动作归纳为六个环节:

这些能力共同构成了一条从代码到真机证据的执行链。Agent 不再以“代码已经生成”作为任务终点,而是根据每一步的真实反馈决定下一步动作:构建失败就读取错误并修复,安装失败就检查设备和签名,运行异常就结合日志和状态继续定位。
生成质量决定单轮成功率,闭环能力决定*终完成率。
4.3 自动签名:打通端到端闭环的关键突破
在整条链路中,自动签名是*容易被忽略、却*直接影响端到端闭环的环节。代码可以自动生成,工程也可以自动构建,但如果签名仍然依赖开发者打开 IDE、选择证书并手工配置,自动化流程就会在真机安装之前中断。Agent *终只能证明“代码能够编译”,无法证明“功能能够运行”。
高德提出自动签名需求后,华为研发团队快速完成能力支持。通过devecocli signature generate命令,签名相关操作被纳入可执行流程,打通了“编译—签名—真机运行—验证”的关键路径,为推进端到端自动化交付提供了关键支撑。
4.4 从人机界面到协议化调用
面向 Agent 的 CLI,不能只是把图形界面的菜单名称改写成命令。开发者操作 IDE 时,可以结合界面提示理解上下文,也能在异常发生后临时调整。Agent 则需要更加明确的执行协议:
▪ 输入参数必须清晰,避免依赖隐含状态;
▪ 输出结果必须结构化,能够判断成功或失败;
▪ 错误信息必须可定位,能够驱动下一轮修复;
▪ 构建产物和日志位置必须明确,便于继续处理;
▪ 相同命令在不同环境中应保持稳定语义。
因此,DevEco CLI 的核心并非“命令数量”,而是将鸿蒙工程能力改造成 Agent 可以理解和调用的协议。当构建结果、设备状态、安装反馈和运行日志都能以统一方式进入上下文,Agent 才能基于工程事实行动,而不是依靠文本推测。
4.5 预设降级链保障连续执行
真实工程环境并不总是稳定。工具版本、设备连接、插件状态和运行环境都可能导致某个执行入口暂时不可用。为了保障执行链连续,关键动作需要预先定义降级顺序,而不是在失败后临时猜测。
在AI Native中设定的降级链路为:devecocli → deveco-mcp → hdc + hvigor,优先使用 DevEco CLI 完成标准化操作;当对应能力不可用时,切换到 MCP 接口;仍然无法执行时,再回退到更底层的 hdc 与 hvigor 命令组合。降级并不意味着无条件重试。每一次切换都必须保留失败原因、当前状态和已完成步骤,避免重复执行产生新的不确定性。
这套机制让执行流程具备了基本的可恢复能力:单个工具失败,不再等同于整个任务终止。
DevEco CLI 不是又一个开发命令,而是把 Agent 的文本输出接入真实工程世界的执行器,让 AI 从“会写”进一步变成“能跑、能验、能改”。
五、运行机制:让体系持续转起来

DevEco CLI 打通了单次工程执行链,但要让任务跨越等待、中断和失败持续推进,还需要一套保存状态、恢复执行和约束回环的运行机制。
这套机制建立在既有 AI 基建之上:7×24 机制负责持续调度,端云一体基建连接云端任务与本地工程、设备和运行时,Spec 抗熵架构则固化目标、状态、证据和验收标准。三者共同支撑任务恢复、失败回环、质量门禁和人工决策。详见“高德技术”微信公众号推文《超级应用的 AI 原生研发模式探索》。
5.1 7×24 的关键是任务持续,而不是 Agent 常驻
一个鸿蒙能力项通常需要经过知识检索、代码修改、构建、签名、安装和真机验证。其间,构建需要等待,设备可能离线,工具调用可能超时,任务也可能跨越多个工作时段。
如果状态只保存在一次对话中,会话中断就意味着重新理解需求、恢复现场并重复试错。所谓7×24,并不是让一个 Agent 永远在线,而是保存任务阶段、执行结果和继续条件,让任务在任何一次中断后都能继续。
5.2 Spec 是任务的状态契约
需求、约束、进度和验收标准需要写入 Spec,不能只存在于 Agent 的上下文里。
一份可执行的 Spec 至少要说明:目标是什么,哪些边界不能突破,当前做到哪一步,已经尝试过什么,留下了哪些证据,以及下一步需要满足什么条件。
每个阶段完成后,Agent 将状态、产物和证据写回 Spec。任务恢复时,再结合 Spec、当前代码和工具结果,从*近的有效检查点继续,而不是重新生成一套方案。这就是 Spec 抗熵的作用:对抗长任务中的上下文丢失、目标漂移和重复试错,让多轮执行始终围绕同一个目标推进。
5.3 主控流程是一台可恢复状态机
Feature 开发、跨端转码和 Bug 修复采用不同流程,由对应 Skill 定义阶段、产物、质量门禁和回退路径,Agent 按约束执行。
流程并非单向推进:编译失败回到实现阶段,真机行为不符回到分析阶段,工程约束被破坏则重新检查设计。关键节点会保存检查点,任务中断后可从*近的有效位置继续。Skill 定义流程,Harness 维护状态,Agent 执行任务。
5.4 失败信号驱动下一轮执行
失败既不是流程终点,也不能成为无限重试的起点。Harness 根据 Skill 定义的质量门禁、超时规则和重试预算,判断任务是否继续推进。失败后,系统保留错误类型、现场上下文、已尝试方案和工具结果。Agent 基于新证据进行*小范围修改,再次执行同一道质量门禁。
不同错误进入不同处理路径:
▪ 环境错误:检查 SDK、依赖、设备连接和签名状态;
▪ 代码错误:根据编译和静态检查结果修复;
▪ 行为偏差:结合 UI、日志和数据链路重新验证;
▪ 质量不达标:回到对应阶段调整实现或设计;
▪ 连续失败:停止自动执行并转入人工决策。
回环必须有上限。同一问题连续修复仍未通过质量门禁,达到重试上限后,系统便停止自动执行,保留现场和证据,转由开发者判断。失败不是流程出口,而是有证据、有预算、有人工兜底的下一轮输入。
六、从单点提效到规模化交付:闭环能力被持续验证

6.1 单点提效:快的不是代码生成,而是交付闭环
当看到网络 Mock 从 10 天缩短到 2 小时,很容易把提效归因于“AI 写代码更快”。但代码生成只是起点,并不代表任务已经完成。跨语言调用能否构建、异常能否在真机消失、指标能否持续上报,才是决定效率是否成立的*后一公里。
这些案例覆盖能力建设、缺陷修复、规范适配和指标治理,均以构建结果、真机行为或数据链路作为完成证据。

五个案例的项目提效分布在 15 倍至 40 倍之间。被压缩的不只是编码时间,还包括检索参照、定位影响范围、构建验证、失败修复和结果确认所需的人工投入。
单点提效证明的不是 AI 能一次写对,而是任务能够交付闭环。
6.2 规模化提效:把一次成功变成持续交付
单个案例验证闭环有效,数千项能力的集中建设,则进一步验证了这套体系能否规模化运行。项目从数千项能力中识别出千余项待补能力。Skill定义执行流程和质量门禁,Spec保存目标、状态与验收证据,Harness负责任务调度、状态恢复和失败回环;超过重试预算仍无法收敛的任务,再转由开发者判断。
*终,整体能力完成率从约五成提升至99%以上,高等级能力完成率超过九成,质量指标保持在较低水平。一个小团队在数月内,以数百人日投入完成了传统模式下需要数千人日的工作,综合效率提升20倍以上,人力投入下降90%以上。
单点提效回答“能不能更快”,规模化交付回答“能不能持续、稳定地完成”
七、通用能力沉淀:从专项实践走向跨项目复用

高德项目完成数千项能力建设后,我们开始追问:哪些经验可以脱离原项目,在新项目中继续发挥作用?
仓库结构、内部工具和业务流程难以直接复制。真正能够复用的,是任务从需求走向运行证据的方法,包括设计先行、规范约束、状态推进、质量门禁、有限修复和过程留痕。基于这些原则,项目进一步沉淀出一套面向 HarmonyOS 研发的通用 AI Native 能力框架。
它不是提示词集合,也不是项目数据的展示工具,而是一套连接需求、实现、验证与反馈的可执行约束。
7.1 六层两轨:通用能力的稳定内核
整套能力按职责划分为六层。上层负责流程推进和质量判断,下层负责专项执行、工程约束、环境调度与宿主适配。

编排引擎定义阶段、闸门和推进规则,专项能力根据任务场景加载。知识规范层是代码修改的约束来源:修改前读取规范,修改后执行增量审查,发现高风险问题时不得继续放行。基础设施层负责环境、构建和设备链路,分发安装层负责适配不同宿主。
六层之外还有两条贯穿轨道:
▪ 运行时执行轨负责把文本决策转化为工程产物、设备行为和运行结果;
▪ 过程留痕轨负责记录能力调用、执行结果、降级路径和修复过程,为后续分析与改进提供依据。
六层拆分职责,两条轨道保证执行能够落地、结果能够回溯。
7.2 五条核心原则:把“全自主”变成硬约束
全自主不等于放弃控制。真正决定流程能否稳定运行的,是每道闸门、每次降级和每份报告都要遵守同一组原则。

这五条原则把自主执行与工程控制放在同一套规则里:过程可以减少人工打断,但完成标准不能被跳过。
7.3 六个阶段:把模糊需求推到真机交付
一次交付被拆为六个阶段:环境就绪、需求澄清、架构设计、任务拆解、编码实现,以及验证、评测与提交。每个阶段结束都设置一道硬闸门,由编排引擎自动判断是否继续推进。

流程不是单向推进。环境不满足要求时停止执行,构建失败时回到实现阶段,运行行为与预期不符时回到需求或任务阶段,触及架构、安全和发布边界时转由开发者判断。
不同项目可以替换构建工具、设备链路和交付方式,但不能绕过需求边界、运行验证和质量门禁。跨项目复用的关键,不是让所有项目使用同一套工具,而是让它们遵守同一套完成路径。
7.4 三类质量检查,用同一套规则判断是否完成
质量门禁不只检查工程产物,也检查能力本身。它由三类检查组成。

这套设计把工程质量和能力质量放进同一个检查体系。工程结果不达标,需要回退整改;能力不符合规范或未能改善结果,也不能直接扩大使用范围。质量门槛可以根据项目特点调整,但运行证据、问题回退和结果留痕不能省略。
7.5 可复用的不是代码,而是完成标准
通用 AI Native 能力的核心不是复用代码,而是复用完成标准。需求必须沿统一流程形成代码、运行证据、质量评测和提交结果,不同 Agent 与项目据此通过同一套门禁。
从专项实践走向跨项目复用,并不是复制原有工程,而是进一步抽象其中的工作流、工程约束、运行证据和质量标准。具体工具可以替换,项目环境可以变化,但判断任务是否完成的方法应当保持稳定。
专项实践留下的*好资产,不是某段代码,而是一套换了项目仍能判断“是否完成”的方法。
八、展望未来
这次实践说明,AI Native 已经能够从单点辅助走向规模化交付。但规模化交付不是终点,它只是证明这套方法具备持续运行的可能。
下一阶段,一方面要让状态契约、运行时执行、质量门禁和反馈闭环成为研发默认流程,将验收范围从“能构建、能安装、能运行”进一步延伸到启动性能、流畅度、功耗、崩溃率和多设备一致性;另一方面,要继续抽象可迁移的流程与标准,让这些能力适配不同工程和研发环境,服务更多 HarmonyOS 项目与生态伙伴。
随着自动执行范围扩大,人的职责不会消失,而会更加聚焦于体验目标、架构取舍和风险判断;AI 则承担检索、实现、验证与修复等可标准化工作。
工程化不是终点。只有将研发效率持续转化为稳定、流畅、一致的产品体验,AI Native 的价值才真正抵达用户。
相关工具
如果想了解更多鸿蒙应用开发工具,欢迎体验鸿蒙应用 AI 开发能力套件 DevEco CLI:
▪ DevEco CLI安装指令:npm install -g @deveco/deveco-cli
▪ DevEco CLI帮助文档:请登录HarmonyOS开发者官网,按照“文档-工具-AI Coding-DevEco CLI”路径获取。

▪ 格物市场:登录Matrix格物平台,进入Skill频道查看详情。

X
-
微博认证登录
-
QQ账号登录
-
微信账号登录
企业俱乐部
Copyright (C) 1997-2026 Chinabyte.com, All Rights Reserved
