事半功倍，点石成金：用 AI 助力鸿蒙开发

如今，AI 辅助编程已经是很多开发者离不开的开发方式。但由于鸿蒙生态相对新兴，公共大模型在 ArkTS 和声明式 UI 上的训练数据相对有限，使用通用 AI 编程产品，效果并不总是令人满意。

好在，华为在 HDC 2026 上发布了官方的 AI 编程方案 DevEco Code 和 DevEco CLI，针对的正是这些痛点。

这一章中，我们就看看怎么利用这两个新工具，搭出一套既快又稳的鸿蒙开发 AI 工作流；我们还将讨论除了代码，AI 还能给鸿蒙应用的顺利开发和上架提供哪些帮助。

两个新工具，两条路线

DevEco Code 是一个在终端里跑的鸿蒙开发智能体 Agent，基于华为 BitFun 技术与开源的 OpenCode 构建。它保留了 OpenCode 的终端交互，以及 Model、Provider、MCP、Skill 这一整套配置能力，另外集成了 DevEco Studio 的开发工具链、HarmonyOS 知识库和一批官方 Skills，支持代码编写、编译构建、运行调试、ArkTS 问题修复和文档查阅。

DevEco CLI 则是把同一套工具集、知识库和 Skills 封装成适配 AI 调用的标准化接口。DevEco Code 内部调用的就是它。但与此同时，DevEco CLI 也兼容给各类通用 AI 开发工具，可以无缝衔接到你已经在用的 Agent。

因此，如果你是初次接触 AI 编程，或者希望获得一站式的体验，可以优先安装使用 DevEco Code，不用额外配置；如果你已经有了习惯的第三方 AI 编程工具，可以考虑先装 DevEco CLI，用它赋予现有工具有关鸿蒙开发的能力。当然，两者同时安装也不冲突。

环境要求与安装

DevEco Code 和 DevEco CLI 都通过 npm 分发，分别可通过以下命令安装：

npm install -g @deveco/deveco-code@stable
npm install -g @deveco/deveco-cli@stable

装完在终端执行 deveco 启动 DevEco Code，或执行 devecocli 启动 DevEco CLI，按引导登录华为账号即可开始使用。

如果 DevEco Studio 装在非默认位置，需要在初始配置中显式指定工具链根目录。

用 DevEco Code 交付功能

了解了基本功能和安装流程后，下面我们就看看在实际工程中该怎么运用。DevEco Code 提供了三种不同自动化程度的交互模式，帮助你以最合适的节奏完成功能交付。

三种模式的选择

在 DevEco Code 的对话框里输入 /agents 可以看到当前可用的模式，也可以在输入框按 Tab 键快速切换。

Build 模式适合较为简单、明确的需求，是最直接的模式。你输入需求描述，Agent 依次完成需求理解、代码生成、代码修复、构建出包和推送至模拟器，然后交给你测试验证，不满意再输入指令继续改。

Plan + Build 模式面向复杂一些的需求，用起来分为两步。先切到 Plan 模式，输入提示词，Agent 会结合你的需求、工程目录结构、代码文件、依赖关系和技术约束理解背景，主动识别需求描述里的模糊点、缺失信息和潜在约束，然后通过进一步追问，产出一份可执行的任务列表。确认之后，再切换到 Build 模式执行。

Goal 模式是从需求到验证的全自动流水线，官方建议的适用场景包括完整的特性开发、关键质量模块开发、多人协作开发和从零搭建项目等。你给出需求描述之后，它同样先通过交互的方式做需求分析、架构设计和任务拆分，确认设计方案和验收标准，并把这些落成一份结构化文档；接下来就按这份文档闭环跑代码生成、语法校验、编译打包、模拟器部署、自动化验证与问题修复，持续迭代到达成目标为止。

需要留意的是，官方文档写明 Build 和 Goal 模式的推包验证都要先配好模拟器。你可以用 devecocli emulator list 确认本地有可用实例。

延伸开去，这三个模式的背后，其实绕不开当下流行的两种开发范式。

Andrej Karpathy 在 2025 年初带火了 vibe coding 这个词，它描述的是一种把大量编码工作交给 AI、靠对话和运行结果不断推进的方式。你说出需求，AI 修改代码，随后运行工程，再把界面问题或错误信息交回 AI。这也是 Build 模式的核心逻辑。

而 SDD（规格驱动开发，Spec-Driven Development）则是一套更为严谨的用法，也是 Goal 模式的基础。你需要先在规格（spec）里列明需求、接口定义、数据流和异常处理，然后交给 AI 去实现。如果有修改需求，就改 spec，然后让 AI 重新处理，保证规格和代码始终一致。Plan 夹在中间，用规划换掉一部分不确定性，但把执行权还给你。

在实际工程里，这几种模式完全可以组合使用。项目还在验证想法时，Build 模式效率很高。从一个点子到真机上能跑的测试版，可能只需几个晚上。到了功能打磨阶段，如果只靠 vibe coding，AI 就会开始变得难以控制；此时换用 Goal 模式，能让高风险改动变得更加可控。

具体到场景，可以这样对应：

如何把需求说清楚

不论选哪个模式，想让 AI 一次命中需求，关键都在于给足上下文。一个可以参考的做法，是在提示词里交代清楚目标、允许修改的文件范围、不能破坏的现有行为、失败状态怎么处理，以及怎么算验证通过。例如：

请先阅读以下文件并复述现有数据流，先别改代码：
- entry/src/main/ets/pages/HomePage.ets
- entry/src/main/ets/viewmodel/HomeViewModel.ets
- docs/specs/home-refresh.md

目标：用户下拉首页后刷新列表；失败时保留旧数据并弹出重试提示。
限制：不要改动数据模型、路由和其他页面，不要增加第三方依赖。
兼容范围：以工程现有配置和目标 API 为准。
验收：空数据、弱网、连续下拉三种情况均可用，现有测试通过。

请先列出计划和可能改动的文件，我确认后再实施。

诚然，Plan 和 Goal 模式都会主动追问，但它只能追问它意识到的模糊点。上下文给得越具体，被追问的轮次越少，跑偏的机会也越少。

还值得提醒的是，并不存在什么「万能提示词模板」。与其背诵复杂的模板，不如把重心放在怎么把业务需求转化成对输入、输出和边界条件的准确界定。用得多了，你自然会形成一套适合自己项目的说法。

用好 Goal 模式的需求文档

如上所述，Goal 模式在动手之前会跟你确认需求分析、架构设计、验收标准和任务列表，然后把这些落成一份结构化文档。后续所有的代码生成、语法校验、自动验证和问题修复，都以这份文档为准。

也就是说，到了版本迭代阶段，改需求要改的是这份文档，而不是在对话里追加一句「顺便把那里也改一下」。后者会让文档和代码逐渐对不上，而 Goal 模式的自动验证正是拿文档当参照的，参照失效，自动验证也就跟着失效了。

一般而言，一份规格大致会写清功能概述、用户场景与验收场景、边界情况、功能需求与关键实体、可度量的成功标准、前提假定，以及尚未确定的问题。自然语言负责说明业务意图，编号后的需求条目和成功标准负责界定实现细节。以「首页下拉刷新」为例，这是 Goal 模式生成的需求文档：

Goal 模式会在生成后询问是否有额外修改或补充。你也可以手动修改（一般位于工程目录的 spec 子目录下），但应当注意保持原来的文档结构。

验证代码的实际可用性

代码写出来了，跑起来对不对是另一回事。对此，DevEco Code 的两项功能有助于验证代码的实际可用性。

一个是 UI 验证。它可以在模拟器上把应用跑起来，做点击、滑动、输入这些操作，再交给多模态模型判断界面显示和交互逻辑是否正确，最后给出一份问题报告。

对于 Goal 模式而言，DevEco Code 通常会在任务执行到尾声时主动开始 UI 验证。你也可以通过输入「验证 UI」或类似意思的提示词主动开始验证。

需要指出，UI 验证功能只是线索，验证成功并不代表代码完全不用改。例如，我们在第 1 章提到的启动页停留时长、底部导航条的安全区适配、深色模式下的对比度等设计规范，并不影响界面功能，因此还是需要自己在真机上过一遍。

另一个是自动修复。对于语法错误、编译构建错误、运行崩溃和运行时的功能问题，DevEco Code 会自己翻看日志、定位问题、修改代码，再重新构建和验证。

绿灯模式与授权边界

默认情况下，每次工具调用都要手动确认。嫌太频繁的话，可以在配置文件 deveco.jsonc 里打开绿灯模式。

deveco.jsonc 文件在项目和用户目录下各有一份，若不存在需新建该文件，优先级如下：

• Windows：.deveco/deveco.jsonc（项目级） > C:/Users/用户名/.config/deveco/deveco.jsonc（用户级）
• macOS：.deveco/deveco.jsonc（项目级） > ~/.config/deveco/deveco.jsonc（用户级）

找到后，在其中加入：

{
  "permission": "allow"
}

之后，所有工具调用会自动执行，不再逐次确认。当然，其中的风险需要自己权衡。在带着签名配置和真实凭据的主工程里，逐次检查确认或许是更稳妥的选择。

用文档和 Skill 让 AI 更懂鸿蒙

无论你是选择开箱即用的 DevEco Code，还是准备将鸿蒙能力接入其他 Agent，要想让 AI 写出合乎规范的代码，都离不开底层的知识储备。下面我们就来看看，如何通过知识库、技能模块（Skills）和模型配置，将官方规范转化为工具能直接理解的约束条件。

命令行查文档

DevEco CLI 内置了官方知识库，覆盖版本说明、开发指南、API 参考、最佳实践、FAQ 和变更预告六类文档，检索语法如下：

devecocli docs search 沉浸光感
devecocli docs search '@State' '@Prop' --catalog best-practices --limit 10
devecocli docs search Row Column --format json

其中，--catalog 用来限定分类，默认为 all，也可以在 harmonyos-releases、harmonyos-guides、harmonyos-references、best-practices、harmonyos-faqs、harmonyos-roadmap 等类别中指定。

搜索结果里包含文档 ID、标题和内容概要，拿到文档 ID 就可以读全文：

devecocli docs read 开发指南/应用框架/UI_Design_Kit_UI设计套件/沉浸光感/ui-design-hds-component-material

对于习惯了命令行的代码工作者来说，这比在文档站里一层层点目录快得多。当然，由于这是本地版的文档，在涉及 API 版本和上架要求等时效性强的信息时，还是应当回到在线文档核对一遍。

Skills 的使用与编写

在 DevEco Code 对话框输入 /skills 可以看到当前可用的 Skill。官方内置了四个：

除了内置技能，你也可以自己创建技能。复习一下，一个 Skill 就是一个包含 SKILL.md 的文件夹，文件名固定为全大写的 SKILL.md，必须以 YAML frontmatter 开头。其中：

• name 和 description 是必填的：name 是唯一标识符，不超过 64 个字符，只能由小写字母、数字和中划线组成，而且要与所在文件夹同名；
• description 不超过 1024 个字符，用一句话说清这个技能做什么、什么时候该用。
• license、compatibility 和 metadata 是可选字段，超出这几个字段的内容会被忽略。
• 正文指令不超过 32768 个字符，整个文件夹不超过 100 MB。

写好之后，建一个与 name 同名的文件夹，把 SKILL.md 放进去，然后把文件夹放在以下四处之一（Windows 下把 ~ 换成 C:/Users/用户名）：

• 项目级 .deveco/skills/
• 用户级的 ~/.config/deveco/skills/
• 兼容其他智能体的 .agents/skills/ 和 ~/.agents/skills/。

DevEco Code 启动时就会自动扫描解析。

Skill 装得多了，还可以在 deveco.jsonc 里控制 Agent 能访问哪些 Skill，支持通配符：

{
  "permission": {
    "skill": {
      "*": "allow",
      "internal-*": "deny",
      "experimental-*": "ask"
    }
  }
}

这里，allow 表示立即加载，deny 表示对 Agent 隐藏并拒绝访问，ask 表示加载前提示你确认。也可以为某个 Agent 单独覆盖全局默认值。

项目级的 Skill 会随代码库一起提交，团队成员拉下代码就共享同一套 AI 开发约束。这是它比个人提示词库更有价值的地方。

模型与 MCP

DevEco Code 内置了 GLM-5.1 模型，登录后即可使用，无需额外配置，单账号默认每分钟 50 次请求。

要切换模型，在对话框输入 /models 进入切换界面。例如，内置支持图片输入的多模态模型目前仅限 Qwen 系列，如果你打算用 UI 验证，就可以优先选用该模型。此外，要接入第三方模型，输入 /connect，选择提供商（如 ZhipuAI、Alibaba），填入 API Key，再选具体模型。

此外，也可以直接修改 deveco.jsonc 达到同样目的：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "deveco": {
      "name": "DevEco Code",
      "models": {
        "glm-5": {
          "tool_call": true,
          "limit": { "context": 200000, "output": 8192 }
        }
      },
      "options": {
        "baseURL": "https://api.openbitfun.com/v1",
        "apiKey": "{env:DEVECO_API_KEY}"
      }
    }
  }
}

注意这里的 apiKey 写的是 {env:DEVECO_API_KEY}，读的是环境变量而不是明文。原因在于，项目级的 deveco.jsonc 是会跟着代码库走的，密钥直接写进去等于提交进了仓库，不是好的安全实践。

此外，deveco.jsonc 的 mcp 段可以接入浏览器、数据库这类第三方服务：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "playwright": {
      "type": "local",
      "command": ["npx", "@playwright/mcp@latest"],
      "enabled": true
    }
  }
}

顺带一提，DevEco CLI 自己也提供一个 MCP 服务，用 devecocli serve mcp 启动，暴露出来的是 ArkTS 和 C/C++ 的代码分析能力：check 做静态语法分析并返回结构化诊断信息，hover、definition、references、callHierarchy 分别负责看类型、跳转、查引用和看调用关系。

到 Matrix 格物平台上找现成的 Skill

当然，轮子不一定都要自己造。Matrix 格物平台是官方推动 AI 开源共建的平台，除了 Skill 广场，还有 MCP 广场、模型库、数据集、智能体和知识库几个模块。质量上，Skill 申请上架时平台会做安全扫描和预审核，再由管理员审批，相比于完全零准入门槛的 GitHub 更有保障。

Skill 广场提供搜索框，也可以按精品集、标签、分类和组织四个维度浏览。跟鸿蒙开发相关的标签有 HMOS、DevEco、ArkUI、ArkTS、OpenHarmony、鸿蒙PC 等。

例如，本教程的读者可能对以下几个技能感兴趣：

• hmos-multidevice-avoid-areas、hmos-multidevice-screen-window-size 等一组多设备适配技能，对应第 1 章提到的折叠屏、大屏与挖孔区适配；
• hmos-account-kit-quicklogin-client 封装了华为账号一键登录的客户端接入，对应第 1 章提到的华为账号登录生态规范；
• hmos-jscrash-analysis、hmos-appfreeze-analysis、hmos-memleak-analysis 这一组分析技能，对应第 4 章提到的崩溃与卡顿排查；
• hmos-arkui-develop-skill 和 hmos-arkts-syntax-checker 则特别适合其他平台迁移而来的开发者解决语法问题。

找到需要的 Skill 后，在详情页里，选择「一键下载」或「安装」即可。另外还有一个「复制安装 skill 提示词」按钮，可以把提示词发给你的 Agent，让它自己去装。

此外，也可以用 Matrix 自己的命令行工具：

npm install -g @matrixopenharmony/matrix-cli
matrix --version
matrix skill install hmos-arkui-develop-skill

或者用 npx 直接从平台的注册表装：

npx skills add https://matrix.openharmony.cn/api/registry/skills/hmos-arkui-develop-skill

需要注意，Matrix 格物平台上的许多 Skill 往往假定你已经把前面说的 MCP 服务配好了。比如 hmos-arkui-develop-skill 生成完代码之后，验证时就会调用 deveco-mcp_check_ets_files；如果检测不到 MCP，就只能退回人工走查。所以在执行相关 Skill 之前，可以先用 devecocli init --mcp 将 MCP 跑起来。

让鸿蒙能力接入你熟悉的 Agent

如果你已经有了一套用得趁手的通用开发 Agent，完全可以不改变原有习惯，通过 DevEco CLI 直接赋予它编写和构建鸿蒙应用的能力。

以接入 Claude Code 为例：

devecocli init --agent claude-code # 安装 deveco-cli Skill
devecocli init --mcp --agent claude-code --project ./MyApp # 配置工程级 MCP 服务

其中：

• --skill 安装技能，让 Agent 知道有哪些鸿蒙命令可以调（缺省时默认）。
• --mcp 配置 MCP 服务，让它通过协议调用语法检查工具（不能与 --skill 同时使用）。
• --project 指定工程路径；不指定则装在用户目录下。
• --agent 后面跟智能体名称，多个用英文逗号分隔，缺省时装到所有已检测到的智能体里。
• -f 用于覆盖重装。

如果你用的 Agent 不在 --agent 的取值范围内，可以用 --path 直接指定配置目录：

devecocli init --path ~/work/ArkTS/NewsData -f

配好之后，用起来跟 Agent 里的其他技能没什么两样，直接用自然语言「派活」即可。

以下是第三方 Agent 可以通过 devecocli 使用的能力范围：

那么，用第三方 Agent 加上 DevEco CLI，跟直接用 DevEco Code 有什么差别呢？主要在自动化程度上。DevEco Code 的 Plan 和 Goal 是把鸿蒙的开发流程预先编排好了的；挂了 CLI 的 Agent 拿到的是一组可调用的命令，怎么串起来要看它自己的规划能力。如果你对手上这个 Agent 的规划能力有信心，挂 CLI 更省事；如果只是想尽快跑通第一个鸿蒙工程，DevEco Code 的现成流程更稳当。

用 AI 辅助起草上架材料

除了帮你写代码，AI 在面对繁复的上架材料时也能大显身手。应用审核需要提交大量结构化的说明文字，只要给出准确的输入，AI 能帮你节省不少咬文嚼字的时间。

以隐私政策和「双清单」为例。你可以先自行整理一份数据列表，包含应用请求的权限、引入的第三方 SDK，以及相关数据收集情况。然后，使用如下提示词让 AI 起草：

根据如下应用权限、引入的第三方 SDK，以及相关数据收集情况，起草一款移动应用上架所需的「已收集个人信息清单」和「与第三方共享个人信息清单」。

- 网络权限（用于基础网络请求）：[…]
- 本地存储权限（用于保存用户阅读进度，数据仅保存在本地设备）：[…]
- 微信 SDK（用于文章分享，仅在点击分享时收集设备型号与网络状态）：[…]
- [继续整理的其他数据收集项…]

要求：

1. 分成两大部分输出：第一部分是本应用自身收集的信息，第二部分是第三方 SDK 收集的信息。
2. 用客观、严谨的法律文书口吻起草。
3. 每一项数据必须明确包含「收集目的」「收集方式」和「保存期限」这三个要素。
4. 如果发现提供的信息不足以符合一般应用的隐私合规要求，指出缺漏并在草稿中留出填空位置，不要自行编造。

除了隐私政策，如果你的应用调用了 AI 能力，上架时还需要提供 AI 功能声明和算法备案。你同样可以让 AI 帮忙整理模型提供方、应用场景和数据处理方式，形成结构化的声明素材。

此外，应用介绍和截图的文案也可以让 AI 帮忙润色。写完以后，建议逐句核对入口是否存在，不要让修饰过度的流畅文案掩盖了功能的缺失。

审慎使用 AI 的注意事项

AI 能显著提效，但它同样带来了新的风险。首先是信息安全：AI 编程工具需要读取代码、日志和对话内容，因此在使用前应当看清服务条款，并遵守团队的保密要求。签名私钥、ClientSecret、访问令牌、生产数据库凭据和真实用户数据，都应当避免进入对话框。如果必须向模型展示配置结构，可以使用 ${CLIENT_SECRET} 之类的占位符来替代。

其次是代码质量与合规性。如果生成代码中出现了陌生的 API，建议先依次检查 DevEco Studio 类型提示和华为开发者官网文档。在找到准确文档确认之前，不应当让它进入发布分支。

以下列举了其他一些建议人工验收、测试的事项：

• 检查代码差异中是否残留 TODO、mock、测试域名和硬编码的账号凭据；
• 核对每项权限声明是否由真实功能触发，并与隐私政策、双清单保持一致；
• 从干净的环境重新构建，运行单元测试、Code Linter 和真机关键路径；
• 对账号、支付、数据迁移、弱网和拒绝权限等场景执行一遍回归测试；
• 使用 DevEco Testing 或 AGC 上架自检，复核性能、兼容性与隐私问题。

总结

善用工具，往往事半功倍。使用 DevEco Code，你可以结合使用快慢由人的三种交互模式；而 DevEco CLI 则把鸿蒙的工具链交给你已经在用的 Agent。在代码生成、修复错误和起草上架材料等场景下，它们能为你省下大量重复劳动的时间。但要真正发挥它们的威力，依然需要你养成写清目标、给足上下文的习惯，并亲自去验证它的产出。

到这里，这套指南也就接近尾声了。从图标设计、到打包测试，再到备案填表，这一路走下来流程确实不少，但只要认清方向，每一项规则都有迹可循。祝各位朋友早日拿到通过审核的通知，期待在鸿蒙应用市场里看到你们的作品！

延伸阅读：

• 《DevEco Code 工具概述》
• 《DevEco Code 下载与安装》
• 《DevEco Code Agent 模式》
• 《DevEco Code 模型配置》
• 《DevEco Code 常用配置》
• 《DevEco CLI 工具概述》
• 《DevEco CLI 常用命令》
• DevEco Code 与 DevEco CLI 的开源仓库：deveco-code、deveco-cli
• Matrix 格物平台与它的《Skill 平台使用指南》
• 《应用审核指南：用户隐私》
• 《配置 AI 功能声明》
• 《人工智能生成合成内容标识常见问题》
• 少数派《GitHub 都没用明白，我这样用 Gemini 零起点开发应用》