现在用AI辅助写代码已经很常见了。

不过，有时候AI生成的代码看着挺完整，复制到DevEco Studio里却出现一堆报错。

这时候最让人头疼的，不是代码写得少，而是根本不知道从哪里开始改。

今天就拿一个简单的ArkTS数据处理函数举例，聊聊遇到AI生成代码报错时，应该怎么排查。

一、先看一个类型问题

假设要做一个任务筛选功能，只显示已经完成的任务。

AI可能给出类似代码：

function getCompletedTasks(tasks: any[]) {
  return tasks.filter(item => item.completed);
}

从JavaScript角度看，逻辑没有明显问题。

但ArkTS对类型的要求更加严格，直接使用any并不是一个可靠的方案，在相关ArkTS编译约束下也可能被禁止。

与其让AI继续随意修改，不如先明确数据类型：

interface TodoItem {
  id: number;
  title: string;
  completed: boolean;
}

function getCompletedTasks(
  tasks: TodoItem[]
): TodoItem[] {
  return tasks.filter((item: TodoItem) => {
    return item.completed;
  });
}

这样不仅更符合类型约束，也更方便阅读。

当业务字段发生变化时，编译器还能帮助检查相关代码。

二、报错不要整段丢给AI

实际使用AI Coding时，一个常见做法是把几十条报错直接复制给AI，然后说：

“帮我修一下。”

但我觉得这种方式并不总是高效。

因为后面的很多报错，可能只是前面某个类型错误引起的连锁反应。

更好的做法是先处理第一条关键错误。

比如告诉AI：

这是HarmonyOS ArkTS项目。下面代码存在类型检查错误，请先分析原因，不要重写整个页面，只给出最小修改方案。

把项目环境、错误信息和修改范围说清楚，通常比单纯要求“修复所有报错”更容易得到可检查的结果。

三、让AI做最小修改

假设当前页面只有一个函数报错，完全没有必要让AI把整个页面重新生成一遍。

我更推荐这样的要求：

保留原有函数名称、参数和业务逻辑，只修复类型问题。请分别给出修改前后的代码，并解释原因。

这样有两个好处。

第一，可以明确看到AI到底修改了什么。

第二，可以降低AI顺手改掉其他业务逻辑的风险。

对于已经有一定规模的项目，这一点尤其重要。

四、用测试确认修改结果

即使代码能通过编译，也不代表业务逻辑一定正确。

比如刚才的任务筛选方法，还需要验证它是否真的只返回已完成任务。

const tasks: TodoItem[] = [
  { id: 1, title: '学习ArkTS', completed: true },
  { id: 2, title: '制作Demo', completed: false },
  { id: 3, title: '整理笔记', completed: true }
];

const result: TodoItem[] = getCompletedTasks(tasks);

if (
  result.length !== 2 ||
  result.some((item: TodoItem) => !item.completed)
) {
  throw new Error('任务筛选结果不正确');
}

这个测试没有使用复杂框架，但可以帮助我们快速验证核心逻辑。

正式项目中还可以进一步使用单元测试框架，覆盖异常输入和更多业务场景。

五、几个值得养成的习惯

使用AI Coding开发HarmonyOS应用时，我建议注意四件事。

第一，告诉AI项目使用的是ArkTS，不是普通JavaScript。 尤其要说明SDK版本和相关开发约束。

第二，给出准确的报错信息。 不要只说代码无法运行，最好提供报错位置与上下文。

第三，一次处理一个问题。 先解决类型错误，再处理业务逻辑，最后优化代码结构。

第四，每次修改之后重新验证。 不要因为AI说“已修复”，就认为问题已经解决。

六、最后说几句

AI Coding确实能够帮助开发者排查一些常见问题，但它并不知道项目里的所有业务约束。

有时候，AI给出的解决方案看起来很合理，却可能引入新的问题。

因此，我更愿意把AI当作一个辅助排查工具，让它帮忙分析原因、提出修改建议，再由开发者确认和验证。

AI可以帮忙找答案，但开发者需要知道为什么这样改。

把这个习惯养成之后，AI Coding才更有机会真正融入日常的HarmonyOS开发工作流。