开发 HarmonyOS 应用时，最耗费时间的工作有时并不是实现新功能，而是反复定位编译错误、检查类型定义、修改代码，再重新运行构建。对于规模较大的项目，一个问题还可能引发一连串后续错误。

AI Coding 可以辅助分析和修复问题，但我不希望它只给出一段解释，或者反复生成看似合理的代码。我更关心的是：能否把 AI 的分析与实际工程工具结合，让每次修复都有明确的验证结果？

HarmonyOS 7 的开发工具体系提供了 DevEco CLI。官方介绍显示，它提供工程工具、官方知识库和 Skills，覆盖工程创建、语法检查、编译构建和运行验证等场景。我尝试把这些工具能力组织成一个小型调试闭环。

将修复任务拆成几个阶段

首先，获取真实的编译错误和对应代码，确认错误发生在哪个模块。然后让 AI 分析原因，并给出尽可能小的修改建议。修改后，使用当前版本工具支持的命令重新检查和构建，最后运行相关功能的回归测试。

为了避免 AI 在反复修复时扩大修改范围，我会为任务设置明确的限制：

interface FixRequest {
  errorSummary: string;
  affectedFiles: string[];
  allowedChanges: string[];
  forbiddenChanges: string[];
}

const request: FixRequest = {
  errorSummary: '历史记录页面构建失败',
  affectedFiles: ['历史记录页面', '筛选逻辑模块'],
  allowedChanges: ['修正类型错误', '补齐必要的导入'],
  forbiddenChanges: [
    '修改无关业务模块',
    '删除现有校验逻辑'
  ]
};

这段代码是我用于组织任务信息的示例，并不是 DevEco CLI 的专用配置文件。

实际操作时，CLI 的命令和参数应以安装版本的帮助信息及官方文档为准。我会先确认当前项目可以正常构建，再使用工具执行相应检查，保留每次运行的输出，避免把历史错误和新产生的错误混在一起。

不让自动修复变成盲目试错

我会要求 AI 解释错误的原因，而不仅仅是输出修改后的代码。例如，如果报错与类型不匹配有关，就需要明确哪个值的类型不符合接口要求；如果涉及组件状态，则要进一步检查数据更新路径。

修复完成后，除了重新构建，还要运行与问题相关的功能测试。假设修改的是筛选页面，就要检查列表展示、筛选条件切换、空结果和清除条件等场景，防止解决一个编译问题却引入新的行为错误。

对于权限、数据持久化和网络请求等关键模块，我不会让自动修复直接绕过原有校验。即使 AI 建议删除某个检查以消除报错，也必须先弄清楚该检查的业务意义。

建立可以重复的工程流程

这套方式最大的价值，是把调试从“凭感觉改代码”转变为可追踪的工程过程。每次修改都有错误依据、代码差异和构建结果，必要时还可以通过版本管理回退。

不过，自动化工具并不能替代所有测试。编译通过只能说明代码满足一定的构建条件，不能证明功能逻辑正确，更不能证明用户体验符合预期。

在后续项目中，我计划把这套流程逐渐扩展到更多重复性工作，例如新页面骨架生成、常见类型错误定位和局部模块检查。对于 HarmonyOS 开发者而言，真正高效的 AI Coding，不是让 AI 无限次地尝试，而是让每一次尝试都能被工程工具验证。