技术方向：DevEco Code、Vibe Coding、ArkTS、AI 辅助开发

最近做 HarmonyOS 开发，我越来越习惯先让 AI 帮忙梳理思路，再决定自己怎么写代码。

例如，要给应用增加一个图片搜索页面，我可以先让 AI 生成页面结构、定义数据模型，再逐步接入实际的视觉能力。这样确实能节省一部分重复劳动。

HarmonyOS 开发工具体系也在持续引入 AI 辅助编程能力，官方介绍中提到了 DevEco Code、Vibe Coding 等工具和开发模式。

但我发现，AI 生成代码并不意味着开发过程可以少做验证。尤其是涉及新版本 SDK、系统级 AI 能力时，代码看起来完整，不代表接口真的存在。

第一件事：把 SDK 版本告诉 AI

如果我只说“帮我写一个 HarmonyOS AI 识图页面”，AI 可能会混合不同版本的 API，甚至生成普通 JavaScript 项目里的写法。

所以，我更倾向于明确项目使用的 API 版本、开发语言、已有组件和目标功能，并要求 AI 在不确定系统接口时明确指出，而不是自行编造。

例如，页面中的数据模型可以先独立出来：

interface SearchState {

keyword: string;

resultCount: number;

loading: boolean;

}

function validateSearch(

state: SearchState

): boolean {

return state.keyword.trim().length > 0 &&

state.resultCount >= 0 &&

state.resultCount <= 100;

}

这段代码只处理搜索参数校验，不涉及任何 AI 系统 API。先让 AI 帮忙完成这些容易验证的基础代码，再逐步接入具体能力，通常更容易控制风险。

第二件事：不要让 AI 一次性重写整个页面

假设只有一个类型错误，我不会直接要求 AI 重写整个页面。因为它可能顺手改变组件结构、状态变量或业务逻辑，反而引入更多问题。

我会要求它先分析错误原因，再给出最小修改方案，并解释修改前后的区别。

对于 AI 生成的视觉识别调用、Skill 声明文件或 Agent 配置，我还会要求它列出对应的官方文档依据。无法核实的接口，先标记为待确认，而不是直接合并进项目。

第三件事：能编译不等于功能正确

AI 可能生成一段完全符合语法、却不符合业务需求的代码。

比如，搜索结果返回了 10 条记录，但其中有重复项；识别结果看起来正常，却没有处理用户取消操作；异步请求失败后，页面仍然显示“识别成功”。

因此，我会为核心逻辑补充测试：

const state: SearchState = {

keyword: '台灯',

resultCount: 10,

loading: false

};

if (!validateSearch(state)) {

throw new Error('搜索参数校验失败');

}

const emptyState: SearchState = {

keyword: ' ',

resultCount: 10,

loading: false

};

if (validateSearch(emptyState)) {

throw new Error('空关键词不应通过校验');

}

这只是一个简单的逻辑测试示例，实际项目还应覆盖异常输入、服务失败、权限拒绝和并发请求等场景。

我现在更愿意把 AI 当作协作开发者

AI 很适合帮助我们生成代码框架、解释陌生概念、分析编译错误以及补充测试用例。但对于系统接口是否存在、权限是否合理、数据处理是否安全这些问题，开发者仍然需要自己确认。

特别是在 HarmonyOS 7 这类持续增加新能力的版本中，官方文档和实际 SDK 的匹配非常重要。

我觉得，AI Coding 最有价值的地方，不是让我们跳过理解代码的过程，而是让我们把时间从重复劳动中释放出来，投入到真正需要判断的架构设计、业务逻辑和质量验证上。