AI Coding 已经不只是补全几行代码。对于 HarmonyOS 应用开发者来说，更有价值的方向，是让 AI 参与需求拆解、代码实现、编译构建和问题修复，同时保留开发者对工程质量的控制权。

这次我尝试将 DevEco Code 与 DevEco CLI 引入日常开发流程。DevEco Code 面向 HarmonyOS 应用开发，覆盖代码生成、问题修复、编译构建和功能验证等环节；DevEco CLI 则提供工程创建、语法检查、构建运行等原子化能力，也便于与其他 AI Agent 组合使用。具体能力以对应版本的官方工具文档为准。

从一个小需求开始

我选择给现有工具类应用增加一个历史记录页面。需求本身不复杂，但涉及页面布局、数据结构、列表渲染、空状态和删除交互。如果直接要求 AI 一次性生成完整功能，虽然可能很快得到一批代码，却不容易控制修改范围。

因此，我先把任务拆成几个明确步骤：分析现有项目结构，确定需要修改的文件，定义数据模型，再实现页面和交互，最后执行构建与运行验证。

在给 AI 下达任务时，我会明确约束条件，例如沿用项目现有的状态管理方式，不修改无关业务逻辑，不使用当前 SDK 不支持的 API，并要求说明修改了哪些文件。

为了让每个任务有明确的验收标准，我还会把需求整理成结构化描述：

interface CodingTask {
 goal: string;
 constraints: string[];
 acceptanceCriteria: string[];
}
const task: CodingTask = {
 goal: '增加历史记录页面',
 constraints: [
 '沿用现有项目结构',
 '复用已有数据服务',
 '避免修改无关模块'
 ],
 acceptanceCriteria: [
 '页面能够正常构建',
 '历史记录可以正确展示',
 '空数据时显示空状态',
 '删除操作后列表及时更新'
 ]
};

这只是应用侧的任务描述示例，并非 DevEco Code 或 DevEco CLI 的专用配置格式。

让 AI 生成代码，也让工程工具检查代码

实际开发中，我会让 AI 优先完成一个可独立验证的小模块，而不是一次性改动多个页面。每完成一部分，就通过工程工具进行语法检查和编译构建，再根据实际报错修复问题。

例如，AI 生成的代码可能存在状态变量使用不当、组件参数不匹配、导入缺失等问题。此时应该把真实的编译错误和相关代码交给工具分析，而不是只让 AI 根据一段模糊描述重新生成整个文件。

在工具链配置方面，可以根据官方文档安装对应工具。HarmonyOS 7 开发者联盟公开资料提供了 DevEco Code 与 DevEco CLI 的安装指引；CLI 的安装示例为：

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

安装完成后，还需要确认 Node.js 环境、工具版本和项目配置符合要求。具体命令参数及可用子命令应以安装版本的 CLI 帮助信息为准。

最容易忽略的是验证环节

代码构建成功，并不代表功能已经完成。我会继续验证页面初次加载、列表为空、存在多条记录、删除最后一条记录，以及页面重新进入等场景。如果涉及数据持久化，还需要检查应用重启后记录是否仍然存在。

另外，涉及权限、文件访问、用户数据和网络请求的代码，必须由开发者重点审查。AI 生成的实现可能符合语法要求，却不一定符合产品安全策略或业务规则。

这次实践让我更明确地认识到，AI Coding 的价值不是把开发过程变成一句提示词，而是减少重复劳动，让开发者把更多精力放在架构设计、复杂问题定位和用户体验上。

我更倾向于把 DevEco Code 作为理解需求、生成代码和辅助修复的工具，把 DevEco CLI 作为工程操作和验证链路的一部分。只有将二者放进真实项目的开发闭环中，才能判断 AI 是否真正提高了效率，而不是仅仅缩短了第一版代码的生成时间。