高德联合鸿蒙 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 从“会写”进一步变成“能跑、能验、能改”。