在 HarmonyOS 项目开发中，从零生成一个页面并不算太难，真正考验开发效率的往往是老项目迭代。已有项目可能使用了特定的状态管理方式、公共组件和数据访问层，如果 AI 不理解这些约束，生成的代码即使看起来完整，也可能无法融入现有工程。

这次我尝试将 DevEco Code 用于一个已有的工具类应用，为其增加历史记录筛选功能。与直接输入“帮我写一个筛选页面”不同，我先让 AI 分析现有目录结构、页面入口、数据模型和相关组件，再把修改范围限制在几个明确的模块内。

DevEco Code 是 HarmonyOS 应用开发专属 AI Agent，覆盖代码生成、问题修复、编译构建和功能验证等开发环节。它更适合进入已有工程的开发流程，而不只是用来生成孤立的代码片段。

先定义需求边界

历史记录筛选看似简单，实际上需要考虑关键词匹配、时间范围、空结果和清除筛选条件等行为。我会先写出验收标准，再让 AI 提出修改方案，避免它一次性重构整个页面。

例如，先定义筛选条件和纯数据处理逻辑：

interface HistoryItem {
  id: string;
  title: string;
  createdAt: number;
}

interface HistoryFilter {
  keyword: string;
  startTime?: number;
  endTime?: number;
}

function filterHistory(
  items: HistoryItem[],
  filter: HistoryFilter
): HistoryItem[] {
  const keyword = filter.keyword.trim().toLowerCase();

  return items.filter((item) => {
    const titleMatched =
      !keyword || item.title.toLowerCase().includes(keyword);

    const startMatched =
      filter.startTime === undefined ||
      item.createdAt >= filter.startTime;

    const endMatched =
      filter.endTime === undefined ||
      item.createdAt <= filter.endTime;

    return titleMatched && startMatched && endMatched;
  });
}

我会先独立验证这段逻辑，再让 AI 将它接入现有页面。这样，即使界面出现问题，也能判断是筛选逻辑、状态更新还是组件绑定出了问题。

用构建结果约束 AI

在生成代码后，我会要求工具说明修改文件、设计理由和潜在影响，然后运行项目构建。如果编译失败，就把实际报错和相关代码交给 AI 分析，而不是让它重新生成整个页面。

这一过程有一个值得注意的细节：AI 给出的修复建议不一定适用于当前 SDK，也可能忽略已有组件的接口约束。因此，我会优先接受范围较小、原因明确的修改，并在每次修复后重新构建。

除了编译，我还会验证关键词为空、没有匹配结果、时间边界相同以及连续修改筛选条件等情况。若页面使用 ArkUI 状态变量，还需要确认筛选条件变化后，界面是否按照预期刷新。

AI 负责提效，开发者负责判断

这次实践让我发现，AI Coding 的效果与任务描述质量密切相关。需求越模糊，AI 越容易擅自补充设计；修改范围越大，越难定位潜在回归问题。

因此，我现在更愿意把开发任务拆成可以独立验收的小步骤：先理解工程，再明确约束，然后修改、构建、测试。DevEco Code 帮助我减少重复编码，但最终的架构选择和质量判断仍然由开发者完成。

对于已有 HarmonyOS 应用，我认为最值得尝试的不是一次性让 AI 重写整个项目，而是从一个边界清晰的迭代需求开始，逐步验证它在真实工程中的效率和可靠性。