用 AI 写代码，大部分人的体验是这样的：补全几行、生成一个函数、修一个编译错误，都挺顺；一旦任务变成"把这个功能做完"，它就开始在原地打转——不知道工程结构、不熟悉框架语法、改一处崩三处。省下来的时间，又在验证和返工里赔回去了。

为了解决这个问题，HarmonyOS 把 AI Coding 拆成了"平台能力"和"开放工具"两条路。2026 年 9 月 18 日 HDD·HarmonyOS 创新论坛上海站上，华为终端开发者服务产品总监开场就问了一句：AI 会写代码，然后呢？ 他的回答是：每天多写 300 行意义不大，真正要交给 AI 的是复杂的、重复的开发任务。

本文基于该场分享的现场录音与课件照片整理，按"为什么鸿蒙上更难 → 三种模式 → 工具与知识 → 四个场景化能力"的顺序梳理，数据与案例均出自现场分享。

一、为什么在鸿蒙上做 AI Coding 更难

现场列了四个挑战，每一条都很实际：

挑战	具体表现
语料少	ArkTS / ArkUI 与官方 API 较新，相关文本与代码语料积累偏少
适配难	直板机、折叠屏、平板等设备形态丰富，同一份业务代码要做多端差异化适配
工程大	动辄几万到上百万行的工程，Agent 难以完整解析整体架构与逻辑
工具不利	现有 IDE 偏面向人工交互，原生接口与调用模式不利于 AI 编程

对应的解题思路也是两条：

1. 一站式开箱即用的鸿蒙开发平台——把模型、引擎、工具一起给到开发者；
2. DevEco CLI + Skill 市场——把鸿蒙的开发能力开放出去，让第三方 Coding Agent（现场点名的如 Trae、Qoder）直接接入，同时支持开发者引入自有 LLM 与第三方 MCP 工具。

二、三种模式：从"帮我写"到"交给你完成"

DevEco Code 的三种模式，本质上是三种授权程度：

模式	你要给什么	AI 负责什么	适用场景
Build	一个需求	写代码	最常见、最轻
Plan	需求 + 目标	先出方案，人工审核后再写代码	复杂场景，需要人把关方向
Goal	目标 + 验收标准 + 验证环境	需求澄清、方案设计、写代码、调试、验证全流程	全链路自动闭环

Goal 模式是现场重点讲的方向。开发者的输入是自然语言需求、验收标准与验证环境，剩下的需求澄清、交互确认、方案设计、任务拆解、代码生成、编译检查、推包到模拟器、问题修复都交给 AI；人只在关键节点确认。

带来的角色变化很关键：从"每个环节都深入参与"，变成"定目标、收结果"。

现场给的案例是"像素匠 Pro"用 Goal 模式端到端实现像素风引导流程：

项	结果
业务痛点	UI 生成不精准、不符合鸿蒙设计规范、验证周期长
方案	自主化文件架构理解、ArkUI 组件生成、编译报错修复与语法校验
效果	UI 生成采纳率 > 60%；开发周期从 1 周缩短到 2 天

三、工具与知识：让 AI 用得上、也用得对

DevEco CLI：把开发能力变成命令行

DevEco CLI 提供原子化开发能力：创建工程、语法检查、编译构建、获取设备、知识库。用命令行就能串联开发全旅程，也便于被主流 AI Coding Agent 集成——现场演示了在第三方工具里通过命令行依次执行创建工程、编译打包、获取设备的流程。

意义在于：开发者不必换 IDE，原来用什么继续用什么。

知识库：不要靠记忆写代码

现场对知识库的表述很值得抄："我们不希望 AI 写代码靠记忆，而是实时结合最新知识。"知识库提供的是最新官方文档内容——ArkUI、媒体、安全等开发指南、最佳实践、多设备特性，按需检索而不是全量灌进去。

70+ Skill：知识管"是什么"，Skill 管"怎么做"

现场给了一句很好记的分工：知识让 AI 知道是什么，Skill 帮助 AI 知道怎么做。

目前已积累约 70 类 Skill，覆盖的正是最容易被 AI 搞错的那些地方：

• 语法与规范：ArkTS 语法规则、语法检查、废弃接口检查；
• 架构与迁移：状态管理迁移、MVVM 架构模式；
• 多设备：多设备避让适配、多设备折展适配、多设备屏幕窗口适配；
• 问题修复：Bug 自动修复；
• 知识检索：ArkUI 知识检索、ArkTS 知识检索。

案例：蚂蚁财富

蚂蚁财富本身已有完备的 AI 流水线，所以做法不是换掉它，而是在原有基础上补三块：知识库（提升代码生成准确率）、编译工具（缩短修复时间）、自动化测试工具（补齐多端适配验证）。

串起"方案设计 → 开发 → 测试 → 验收"之后的结果是：开发效率提升 60%+，中小型需求的 AI 生码率可达 70%，千行代码 Bug 率下降约 30%。

四、四个场景化能力：从"帮我写"到"帮我做完"

通用编码能力解决不了具体场景。现场把开发者真实的四类诉求单独做成能力，统一放进 HarmonyOS 开发助手插件——在 Visual Studio Marketplace、JetBrains Marketplace、Open VSX Registry、DCloud 插件市场搜索安装即用。

1. 一站式生成元服务

先说清楚为什么需要它。现场点出了一个很典型的问题：ArkTS 与 TS 语法不兼容。比如在 ArkTS 里，对象字面量不能用作类型声明（编译器有强制类型检查规则），而大模型主要学的是 TS 语料，很容易直接生成 TS 写法，结果就是"乍看还行，一运行就崩"。

这个能力的流程是：自然语言 → 高保真 PRD → 设计稿 → 代码 → 问题自动修复 → 可编译工程 → 打包运行。特点：

• 支持 VSCode、DevEco Studio 等多 IDE，模型可自定义；
• 元服务生成约 10 分钟；
• 覆盖生活消费、生活服务、优惠购物、电影购票、奶茶咖啡、手机充值、出行导航、查寄快递、景区导航等主流场景。

现场案例来自 HDE：之前的流程是"花三天配环境、查文档、编译报错"，现在变成"跟 AI 聊几分钟生成想要的元服务"——中间会经历 PRD 确认、多轮修改直至满意。

2. 小程序转换元服务

存量代码资产无法直接复用，是很多团队的痛。现场引了两段开发者原声，核心诉求都是"代码一键迁移、提升资产复用效率"。

工程上分四段：AI 制定方案 → 执行转换 → 编译验证 → 生成报告；同时支持增量迁移管理（按模块逐步推进，风险可控）。案例的数字很直观：2 万行代码工程，识别并修复 121 处错误后编译运行通过；UX 页面自动适配、布局保真度较高，开发周期从周级缩短到小时级。

3. 三方库鸿蒙化

现场给了一组调研数据：77% 的开发者首选 AI 工具做自动适配转换，而通用 AI 工具只能迁移约 70% 的功能，剩下的要靠人工逐行补。

插件把它做成三步：分析 SDK 源码识别方案 → 依据方案编写代码 → 基于示例工程验证修改效果。目前覆盖主流跨平台框架与原生（现场提到 Flutter、React Native 与安卓原生三类），已有 400+ 三方库完成鸿蒙化适配，平均适配周期下降约 70%。

4. 多设备适配

三个难点说得非常准：范围难识别（不同屏幕尺寸、窗口形态、横竖屏、折叠状态组合太多）、方案难落地（改完要保持原有功能与基线体验不受影响）、结果难验证（问题复现、回归测试要反复做）。

流程是：场景与工程理解 → 方案设计（输出高保真预览，把"三折叠该怎么适配、折叠外屏该怎么设计"先给开发者确认）→ 适配代码开发 → AI 综合能力验证效果 → 输出测试报告。

两个工程细节值得抄：控制修改的影响范围（爆炸半径），尽量限制在本次修改内；以及交付可改可恢复的过程，而不是只给一个结果。

总结

这场分享的核心不是"AI 能写代码"，而是怎么把授权级别交给 AI：

1. 先分任务类型再选模式——轻需求用 Build，复杂场景用 Plan，验收标准清晰的整块任务才用 Goal；
2. 不要让 AI 靠记忆写代码——接上最新知识库与 Skill，比换更大的模型便宜得多；
3. 不换 IDE 是真的优势——能力以 CLI 和插件形式交付，团队不用迁移工作流；
4. 长尾场景单独做工具——元服务生成、小程序转换、三方库鸿蒙化、多设备适配，这四件事通用模型做不好，因为它们缺的不是算力，是领域知识。

如果你的团队正在评估"要不要上 AI 编程"，可以先量一下自己最耗时的那类任务属于哪一档：它是"写出来"，还是"改到能跑"？ 后者才是 AI 现在真正能省时间的地方。

关于我

13 年 IT 全栈，.NET、Python、Office 自动化（VSTO/VBA/Python）都做，也做 AI 应用实操（智能体开发），主业是帮企业和团队把重复劳动自动化——报表一键生成、数据对接、文档批量处理、工具定制。

本科物理化学、硕士计算机化学，在一线实验室待过 13 年（9 年制药 + 4 年第三方检测），现在主要服务药企、检测机构和实验室：SOP、合规、样本流、仪器数据接口这些词不用你解释。

这几年做得比较多的是这几类：Office 自动化（VSTO/VBA/Python）工具定制、数据对接与 LIMS 咨询、技术陪跑。

不是外包码农，是听得懂业务的自己人。有同类场景的朋友欢迎评论区聊聊，先聊清楚再动手不迟。