一、背景与挑战

在工信部相关要求和明确交付时间点下，高德需完成鸿蒙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频道查看详情。