前言

聊 HarmonyOS 7 的开发工具链时，很多人第一反应会放在 AI 写代码上。

这个反应很正常。过去一年里，不管是通用 AI IDE，还是各类编程 Agent，大家最容易感知到的能力都是代码生成、报错解释、文件修改、批量重构。可是回到 HarmonyOS 应用开发里，真正麻烦的地方往往不只是写一段 ArkTS 代码。

• 一个页面无法跳转，可能是路由参数问题。
• 一个组件没有刷新，可能是状态管理问题。
• 一个接口无法调用，可能是 SDK、Kit、权限或者版本问题。
• 一个应用无法安装，可能是签名、证书、设备系统版本问题。
• 一个页面性能异常，可能要结合日志、Profiler、启动耗时和内存数据一起判断。

所以，DevEco Code 和 DevEco CLI 更值得关注的地方，是它们能不能进入鸿蒙工程验证流程。

DevEco Studio 本身已经覆盖 AI 辅助编程、编译构建、UI 实时预览、代码调试、性能调优、模拟器等能力。DevEco Code 面向 HarmonyOS 开发场景，覆盖需求、设计、开发、验证四个阶段；DevEco CLI 则面向编程 Agent，提供从工程创建、语法检查、编译构建到运行调测的全流程工具，并将鸿蒙开发知识资源提供给 Agent 调用。

这意味着，后续做 HarmonyOS 开发时，我们不能只问 AI 能不能生成代码，还要继续追问几个更具体的问题。

• 生成的代码能不能编译。
• 修复建议能不能复现。
• 报错解释能不能回到官方 API 和项目上下文。
• 构建结果能不能在真机或者远程云调试里验证。
• 每一轮修改能不能留下日志、截图和结论。

今天我们就围绕这个问题展开：

DevEco Code 和 DevEco CLI，真正改变的是鸿蒙工程验证流程。

一、先把 AI 工具放回工程闭环里理解

如果我们只把 DevEco Code 当成代码生成器，那就容易低估它对鸿蒙开发流程的影响。

真实项目里，代码生成只是其中一个环节。一个功能从需求到上线，通常会经过需求拆分、页面设计、数据结构、代码实现、编译构建、真机调试、问题修复、日志确认、性能检查这些步骤。中间任何一个环节不稳定，最终都不能算完成交付。

DevEco Code 的价值，可以先放到这个流程里看。

这个表里有一个关键点：AI 可以参与每个阶段，但最终结论仍然要回到工程结果上。

比如 AI 解释了一个编译错误，这个解释只是排查线索。项目重新编译通过，才算当前修复有效。真机运行结果正常，才算当前问题在设备侧得到确认。日志和截图保存下来，后续才能复查。

这就是工程闭环的价值。

对于 HarmonyOS 开发来说，这一点更重要。因为很多问题并不来自单个函数，而是来自工程上下文。页面路径、模块配置、SDK 版本、权限声明、签名配置、设备系统版本、AGC 服务状态，都可能影响最终结果。

DevEco Code 面向 HarmonyOS 开发场景，默认包含鸿蒙专属的软件工程能力；DevEco CLI 则让 Agent 能够调用鸿蒙开发工具和知识资源，这会让 AI 从单纯生成代码，进一步进入工程任务执行过程。

AI 工具的价值，要通过编译、运行、日志和真机结果来确认。

如果你正在使用 DevEco Code 或 DevEco CLI，建议第一阶段不要追求一次性自动完成整个功能。更稳的方式，是先让工具参与低风险环节，比如需求拆分、报错解释、局部代码生成、验证清单整理。等这些环节稳定以后，再逐步增加自动修改和多文件联动。

二、DevEco Code 适合先进入低风险工程环节

DevEco Code 的定位很容易让人产生一个期待：让它直接理解需求，然后把一个功能完整写出来。

这个方向可以期待，但在真实项目里，第一轮更适合从低风险环节开始。尤其是你手里已经有一个 HarmonyOS 6 原生项目时，项目里往往有自己的目录结构、命名规范、状态管理方式、数据模型和页面组织方式。AI 直接大范围改动，很容易碰到上下文不完整的问题。

更稳妥的方式，是先把 DevEco Code 放到以下这些位置。

比如一个页面出现状态不刷新，直接让 AI 大范围重写页面并不稳妥。更合理的方式，是先把当前页面代码、状态变量、触发事件和错误现象交给工具，让它解释可能原因。然后只改一个最小位置，重新编译和运行。

可以把这类流程整理成这样。

问题现象 → 提供上下文 → 获取修复建议 → 最小修改 → 重新编译 → 真机验证 → 记录结论

这个流程很朴素，但特别适合 Beta 阶段。因为 Beta 阶段的不确定性更多，单次修改范围越大，越难判断问题来源。

以会议类应用为例，假设会议详情页里点击 生成纪要 后页面没有更新，排查顺序可以这样安排。

这里不需要一开始就让 AI 重写整个页面。先解决一个清楚的小问题，确认工具建议是否可靠，然后再扩大使用范围。

DevEco CodeGenie 在 DevEco Studio 中已经覆盖智能问答、代码生成、页面生成、万能卡片生成、单元测试用例生成、代码智能解读和编译报错分析等场景。你可以先从这些低风险环节开始，而不是直接把主流程交给工具自动改。

我们可以使用下面的验证记录模板进行表述。

{  "tool": "DevEco Code",  "scenario": "compile-error-analysis",  "input": "编译错误信息和相关代码片段",  "suggestion": "工具给出的修复建议",  "changeScope": "单文件局部修改",  "buildResult": "passed | failed",  "runResult": "passed | failed | pending",  "conclusion": "可采纳 | 继续观察 | 不采纳"}

这个模板的作用，是把工具建议和工程结果绑在一起。工具说得是否有道理，最终要看构建和运行结果。

三、DevEco CLI 更适合连接 Agent 和工程工具

DevEco CLI 的价值，需要从 Agent 的角度理解。

很多通用编程 Agent 有一个问题：它能生成代码，也能修改文件，但不一定真正理解 HarmonyOS 工程结构。比如项目创建、语法检查、编译构建、运行调测、官方知识查询，这些都需要工具支撑。没有这些工具，Agent 很容易停留在文本推理阶段，给出看似合理、实际无法执行的建议。

DevEco CLI 让这个问题有了新的处理方式。它面向编程 Agent 提供鸿蒙全流程工具，并且让 Agent 能够调用工程创建、语法检查、编译构建、运行调测等流程；同时还将鸿蒙开发文档和知识资源整理成可被 Agent 调用的知识能力。

这意味着，DevEco CLI 更适合放在 Agent + 工程执行 的位置。

大家可以这样理解。

这条链路里，Agent 不再只是回答问题。它可以通过 CLI 触达工程操作。我们也不再只看生成代码是否好看，而是要看它能不能完成工程任务。

比如一个典型流程可以这样拆。

描述需求 → Agent 拆分任务 → 查询鸿蒙知识 → 调用 CLI 检查工程 → 修改代码 → 编译构建 → 读取日志 → 给出下一步建议

这个流程比单次问答更接近真实开发过程。

但这里也要保持边界。CLI 可以帮助 Agent 操作工程，不代表所有操作都应该自动执行。创建工程、查询文档、运行检查、读取日志这类动作可以更自动；删除文件、大范围重构、修改签名配置、改动依赖版本这些动作，仍然需要人工确认。

可以先把 CLI 动作分成三类。

这个分层对 Agent 工程化非常重要。因为 CLI 一旦进入工程层，影响就会变大。没有确认边界，很容易从 辅助开发 变成 不可控修改。

如果你已经在使用通用 AI IDE 或编程 Agent，DevEco CLI 更像一个 HarmonyOS 工程能力适配层。它让 Agent 不只是理解自然语言需求，还能进一步理解鸿蒙工程、查询鸿蒙知识、执行鸿蒙工具链。而这个变化会让 AI 辅助开发从 生成代码 走向 执行验证闭环。

四、工程验证流程要从单次回答变成多轮闭环

当 AI 工具进入 HarmonyOS 工程后，最值得调整的是验证习惯。

以前遇到问题，常见流程是搜索报错、查文档、改代码、重新运行。现在可以让 DevEco Code 或 Agent 参与其中，但流程不能变成 AI 回答一次就结束。更能提升生产力的方式，是把每次修改都放进多轮闭环。

我们可以把工程验证闭环整理成下面的七步。

这个流程的关键，是 最小修改 和 结果记录。

如果 AI 一次修改很多文件，那么我们在编译失败以后很难判断哪一处引入了新问题。如果 AI 只修改一个局部，重新编译和运行之后，结果就容易判断。这个习惯对 HarmonyOS 项目特别重要，因为页面、状态、权限、签名、设备版本、SDK 版本经常交织在一起。

大家可以准备一个工程验证记录模板。

{  "task": "修复会议详情页状态不刷新",  "tool": "DevEco Code | DevEco CLI | Agent",  "context": {    "file": "MeetingDetailPage.ets",    "symptom": "点击生成纪要后页面没有刷新",    "log": "填写关键日志"  },  "suggestion": "填写工具建议",  "changeScope": "单文件局部修改",  "buildResult": "passed | failed",  "runResult": "passed | failed | pending",  "finalConclusion": "已修复 | 未修复 | 继续观察"}

这个模板不复杂，但它能让工具建议变成工程证据。

DevEco Studio 本身提供编译构建、UI 实时预览、代码调试、性能调优、模拟器等能力。把这些能力和 DevEco Code、DevEco CLI 放在同一个闭环里，工程验证才会完整。

对于 HarmonyOS 7 API 26 Beta 阶段，这套闭环还有额外价值。Beta 阶段的问题可能来自系统、SDK、文档、设备或者项目本身。每次修改都留下记录，后面才能判断问题是否因为版本变化而消失，或者是否需要继续等待文档和 SDK 更新。

五、真实项目里先从三类场景开始接入

DevEco Code 和 DevEco CLI 进入项目，不建议大家一开始就处理最复杂的主流程。

更实际的方式，是先选择三类场景。

以会议随记类应用为例，第一轮可以这样安排。

这类场景的共同特点，是输入清楚、改动可控、结果可验证。它们很适合作为 DevEco Code 和 DevEco CLI 的第一轮接入范围。

等这几类场景稳定以后，再逐步扩大到更复杂的能力。

比如：

• 多端适配页面生成
• Skill 候选能力拆分
• Agent 任务链代码整理
• API 26 迁移问题修复
• 性能日志分析
• 自动生成单元测试或 UI 测试思路

工具链提升效率的前提，是工程验证不能缺席。

如果 AI 生成了一个页面，但没有编译记录、运行截图和交互验证，这个结果仍然不完整。如果 AI 修改了一个问题，但没有保存日志和修改范围，后续出现回归也很难定位。如果 Agent 通过 CLI 做了多步修改，但没有人工确认关键动作，风险就会变高。

所以，DevEco Code 和 DevEco CLI 进入项目后，最好同步建立三张表。

这三张表不用复杂，但要大家持续维护。真正做项目时，AI 工具带来的效率提升，很多时候就体现在这些记录里。你会知道哪些场景适合交给工具，哪些场景只能作为参考，哪些建议经常能通过编译，哪些建议看起来合理但实际跑不通。

总结

DevEco Code 和 DevEco CLI 对 HarmonyOS 开发的影响，不应该只理解成 AI 帮忙写代码。

更重要的变化，是它们把 AI 带进了鸿蒙工程验证流程。

我们可以按照下面的五步进行处理。

如果你已经有 HarmonyOS 6 原生项目，第一轮不要急着让 AI 工具大范围重构主流程。可以先从一个具体问题开始，比如编译报错、页面状态不刷新、权限配置不生效、API 26 验证清单整理。每一次都记录工具建议、修改范围、编译结果、运行结果和最终结论。