零经验开发者4小时构建鸿蒙应用：AI编程助手实战指南

哗啦啦的小流弊

348人浏览 · 2026-08-04 16:55:58

哗啦啦的小流弊 · 2026-08-04 16:55:58 发布

1. 从一张皱巴巴的小票说起：一个普通开发者的“鸿蒙焦虑”

那天下午，我正对着办公桌上堆积如山的小票和发票发愁。出差报销、设备采购、日常开销……这些纸质凭证就像时间的碎片，记录着工作，也制造着混乱。我尝试过用手机拍照，但照片很快淹没在相册里；也试过用笔记软件记录，但格式不一，查找起来依旧费劲。就在我对着又一张字迹模糊的餐饮小票叹气时，一个念头闪过：为什么不自己做一个应用来管理它们？一个能拍照、能识别、能分类、能提醒的“智慧收据管家”。

想法很美好，现实却很骨感。我是一名有多年经验的全栈开发者，但我的技术栈主要集中在Web和安卓生态。对于鸿蒙（HarmonyOS），我久闻其名，知道它是华为推出的分布式操作系统，生态发展迅猛，但从未亲手写过一行代码。一想到要学习全新的ArkTS语言、熟悉方舟开发框架、配置鸿蒙开发环境，那股熟悉的、面对新技术栈的“启动摩擦力”就涌了上来。我需要看多少文档？要踩多少环境配置的坑？这个“小想法”会不会最终变成一个“烂尾工程”，耗费我数个周末却无疾而终？

这种“鸿蒙焦虑”我相信很多开发者都有。我们看到了趋势，认可其价值，但被未知的学习成本和时间投入劝退。直到我注意到了CodeBuddy——一个号称能通过自然语言对话辅助编程的IDE插件。它被集成在VSCode中，宣传说能理解开发者的意图，生成代码、解释逻辑、甚至调试排错。一个大胆的想法诞生了：如果我完全依赖CodeBuddy，从一个空项目开始，只用对话和描述来驱动开发，我能在多短的时间内，把一个想法变成可运行的鸿蒙应用？

于是，我决定进行一次极限挑战：用4个小时，从一张小票的创意出发，在CodeBuddy的全程辅助下，完成“智慧收据管家”鸿蒙应用的从零到一。这不是一场严谨的工程实践，而是一次对新兴开发模式的探索和记录。我想知道，在AI辅助编程工具日益成熟的今天，一个开发者跨越技术栈壁垒的门槛，究竟能被降低到什么程度。

2. 起跑线：零鸿蒙经验下的环境搭建与项目初始化

我的开发主力机是macOS，已经安装了Visual Studio Code。根据网络上的信息和CodeBuddy的官方指引，第一步是在VSCode中安装插件。

2.1 安装与初识CodeBuddy

在VSCode的扩展商店中搜索“CodeBuddy”，能够找到两个相关插件：一个是纯粹的CodeBuddy，另一个是名为“CodeBuddy Skills”的扩展包。我选择安装了核心的CodeBuddy插件。安装完成后，侧边栏会出现一个机器人图标，点击后需要登录或注册账号。这里有一个小插曲：初期使用可能需要等待审核或获取兑换码（网络上提到的 codebuddy兑换码 可能与此相关），但我当时直接使用华为开发者账号就完成了关联，过程还算顺利。

登录成功后，界面非常简洁，主要就是一个对话输入框。我输入了第一句指令：“你好，CodeBuddy。我想开发一个鸿蒙应用，用来管理收据和发票，你能帮助我吗？”

CodeBuddy的回复很热情，它首先确认了我的需求，然后并没有直接开始写代码，而是给出了一个清晰的“启动路线图”：

安装鸿蒙开发环境 ：它指出我需要先安装DevEco Studio（鸿蒙官方IDE）或者至少配置好鸿蒙的SDK和工具链。
创建项目 ：它建议我使用DevEco Studio创建项目，或者如果我想完全在VSCode中进行，需要配置好相关插件和构建脚本。
明确应用功能 ：它让我细化“智慧收据管家”的具体功能点。

这个回答让我有点意外，也让我安心。它没有越俎代庖，而是扮演了一个“资深向导”的角色，告诉我正确的起跑姿势。这比直接生成一堆可能跑不通的代码要负责任得多。

注意：网络上有很多关于 vscode中添加codebuddy插件 、 codebuddy安装 的讨论，但需要注意的是，CodeBuddy本身是一个AI编程助手，它不能替代鸿蒙官方的开发工具链。对于鸿蒙应用开发，核心的编译、打包、调试依然依赖华为提供的SDK。

2.2 绕开DevEco Studio：在VSCode中搭建鸿蒙开发环境

我决定接受挑战，尝试在不打开DevEco Studio的情况下进行开发。我向CodeBuddy表达了这一想法：“我希望全程在VSCode里完成，能指导我配置VSCode的鸿蒙开发环境吗？”

CodeBuddy给出了详细的步骤：

安装Node.js和Ohpm ：鸿蒙的包管理工具Ohpm需要Node.js环境。它给出了安装Node.js的官方链接，并指导我通过命令行安装Ohpm： npm install -g @ohos/ohpm 。
安装鸿蒙SDK ：它指导我通过Ohpm安装核心的SDK包，例如： ohpm install @ohos/hypium （测试框架）。但更重要的是，它提醒我需要从华为开发者官网下载并设置完整的HarmonyOS SDK路径，并配置环境变量 HARMONY_HOME 。
安装VSCode鸿蒙插件 ：它推荐了华为官方提供的“HarmonyOS Extension”插件，这个插件提供了ArkTS语法高亮、代码片段、应用运行和调试等功能。

这个过程并非一帆风顺。在配置 HARMONY_HOME 时，我遇到了路径问题。我将错误信息抛给CodeBuddy：“我设置了HARMONY_HOME到SDK目录，但创建项目时还是说找不到工具链。” CodeBuddy没有直接给出新命令，而是让我执行 echo $HARMONY_HOME 并检查目录结构，它发现我指向的是SDK的根目录，而工具链在 /toolchains 子目录下。它建议我检查官方文档中关于环境变量的具体说明，或者直接使用DevEco Studio来自动化管理这些依赖。

实操心得 ：对于纯粹的鸿蒙新手，我个人的体会是，第一次搭建环境时， 直接使用DevEco Studio是最稳妥、最高效的选择 。它集成了所有必要的工具链、模拟器和模板，能避免大量环境配置的坑。CodeBuddy在环境配置上的指导是准确的，但它无法替你解决所有系统级的依赖和路径问题。我的“极限挑战”心态让我选择了更复杂的手动配置路径，这消耗了大约40分钟。对于想快速上手的开发者，请接受CodeBuddy的第一个建议——先用DevEco Studio创建项目。

2.3 创建项目与最初的代码

环境就绪后，我让CodeBuddy帮我创建一个标准的鸿蒙应用项目结构。我输入：“现在，请为我创建一个名为‘SmartReceiptManager’的鸿蒙应用项目结构，使用ArkTS语言和Stage模型。”

CodeBuddy生成了一系列的目录和文件描述，并提供了关键文件的初始代码：

entry/src/main/ets/entryability/EntryAbility.ts ：应用入口能力。
entry/src/main/ets/pages/Index.ets ：首页页面。
entry/src/main/resources/base/profile/main_pages.json ：页面路由配置。

它生成的 Index.ets 首页是一个简单的“Hello World”文本。我运行了构建命令 ohpm build ，并在配置好的模拟器（我使用了远程模拟器服务，本地未安装 鸿蒙系统模拟器 ）上成功看到了这个页面。虽然简单，但这是一个重要的里程碑：证明我的基础环境是通的。

3. 核心功能实现：与CodeBuddy的“需求对话”

有了基础项目，真正的挑战开始：如何在不熟悉ArkTS语法和鸿蒙API的情况下，实现“智慧收据管家”的功能？我的策略是：将复杂功能拆解成一个个具体的、可描述的“任务”，然后像产品经理对待工程师一样，向CodeBuddy提出需求。

3.1 任务一：构建一个简单的收据列表页面

我对CodeBuddy说：“首先，我需要一个首页，用来展示所有已添加的收据列表。每条收据显示商户名称、日期、金额和一张缩略图。请用ArkTS写这个页面，使用List组件。”

CodeBuddy生成的代码质量让我惊喜。它不仅仅给出了List组件的架子，还：

定义了一个 Receipt 数据模型类，包含 id , storeName , date , amount , imageUri 等字段。
创建了一个模拟数据数组 receiptList 。
使用 @Component 装饰器构建了一个 ReceiptItem 自定义组件，用于渲染单条收据。
在主页面的 build() 方法中，使用了 List 组件来遍历 receiptList ，并渲染每个 ReceiptItem 。
甚至为金额添加了简单的格式化（例如 ¥${this.receipt.amount.toFixed(2)} ）。

我复制代码，替换掉原来的 Index.ets ，运行应用。一个虽然简陋但结构清晰、数据完整的列表页面立刻呈现在眼前。我接着提出优化需求：“列表项需要更好看一些，有阴影和圆角，并且点击项能有反馈效果。”

CodeBuddy迅速响应，为 ReceiptItem 的根组件 Column 添加了样式： borderRadius 、 margin 、 padding ，并使用了 Touchable 组件包裹以实现点击效果，通过 opacity 属性变化来模拟按压反馈。整个过程就像在和一位理解力很强的实习生协作，我描述视觉和交互效果，它负责用代码实现。

3.2 任务二：集成相机与图片选择功能

这是应用的核心。我对CodeBuddy说：“现在，我需要一个浮动按钮，点击后可以调起系统的相机拍照或者从相册选择图片，这张图片将作为新收据的凭证。”

这里遇到了第一个真正的技术难点。CodeBuddy最初生成的代码试图导入 @ohos.multimedia.camera 和 @ohos.file.picker 等模块，但构建时报错，提示模块找不到或API使用方式不对。

踩坑过程与排查 ：

权限问题 ：CodeBuddy首先意识到问题，它问我：“你已经在 module.json5 文件中声明了相机和相册的权限了吗？”我检查了一下，果然没有。它指导我添加了 ohos.permission.CAMERA 和 ohos.permission.READ_IMAGEVIDEO 等权限声明。
API版本与导入方式 ：添加权限后依然报错。CodeBuddy开始“思考”，它输出：“让我检查一下HarmonyOS API版本。你项目中使用的是API 9吗？某些API的导入路径或用法在不同版本间有差异。” 我查看了项目的 oh-package.json ，确认是API 9。CodeBuddy随后更正了导入语句，例如将 @ohos.multimedia.camera 的具体类名路径提供给我。
使用 @ohos.multimedia.image 和 @ohos.file.picker ：最终，CodeBuddy提供了一套可工作的方案。它没有直接使用底层的camera API，而是推荐使用 @ohos.multimedia.image 中的 PhotoViewPicker 来拍照，使用 @ohos.file.picker 中的 PhotoSelectOptions 和 PhotoSelectResult 来从相册选择。它生成了两个异步函数： takePhoto() 和 selectFromGallery() ，并详细注释了每一步：创建Picker实例、配置参数、调用 select() 方法并处理返回的URI。

我将这段代码整合到浮动按钮的点击事件中，成功调起了系统的拍照和选图界面！选择照片后，我能获取到一个 uri （如 file://media/Photos/... ）。这个 uri 就是后续处理的关键。

注意：处理系统返回的 uri 时，直接将其用于 Image 组件的 src 属性可能无法显示。鸿蒙系统有安全沙箱机制。CodeBuddy提醒我需要使用 @ohos.file.fs 文件系统API，根据 uri 获取到文件的真实路径，或者使用 Image 组件支持的直接加载 PixelMap 的方式。它为我补充了 getPhotoPixelMap(uri: string) 函数，使用 image.createImageSource(uri) 和 imageSource.createPixelMap() 来获取可显示的图片数据。

3.3 任务三：小票文字识别（OCR）—— 意图框架的威力

仅仅拍照存储还不够“智慧”。我的核心需求是自动识别小票上的文字信息（商户、金额、日期）。这是我预期中最复杂的部分，可能需要集成第三方OCR服务。

我向CodeBuddy描述：“接下来是最关键的一步。用户拍下小票后，应用需要自动识别图片中的文字，提取出商户名、总金额和日期。鸿蒙有相关的OCR能力吗？或者我需要集成第三方服务？”

CodeBuddy的回答超出了我的预期。它没有直接让我去百度搜索AI服务，而是说：“HarmonyOS提供了 Core Vision Kit （核心视觉服务套件），其中包含 TextRecognition （文字识别）能力。我们可以尝试使用它。请先确保你的项目已通过Ohpm安装了 @ohos/core-visual 这个包。”

我按照指示运行 ohpm install @ohos/core-visual 。安装成功后，CodeBuddy开始生成OCR识别代码。它展示了如何使用 TextRecognition.createTextRecognition() 创建识别器，如何将之前拍照获取的 PixelMap 或图片 uri 作为输入，以及如何订阅识别结果。

这里出现了本次开发中最惊艳的部分——意图框架（Intent Framework） 。CodeBuddy在生成代码时，特别强调了一点：“对于文字识别这种系统级能力，建议使用 隐式意图（Implicit Intent） 来调用。这样系统可以匹配合适的、已安装的视觉服务应用来完成识别，即使未来华为更新了视觉服务，你的应用也无需修改。”

它生成的代码片段如下：

// 非完整代码，展示意图调用思路
import want from '@ohos.app.ability.want';
import { BusinessError } from '@ohos.base';

let want: want.Want = {
  action: 'ohos.want.action.recognizeText',
  entities: ['entity.system.image'],
  uri: imageUri, // 需要识别图片的uri
  parameters: {
    // 可配置识别参数
  }
};
let context = getContext(this) as common.UIAbilityContext;
context.startAbilityForResult(want).then((result) => {
  // 处理识别结果
}).catch((err: BusinessError) => {
  console.error(`Failed to recognize text. Code is ${err.code}, message is ${err.message}`);
});

通过意图调用，我的应用无需直接处理复杂的图像算法，只需声明“我想识别这张图片里的文字”，系统就会分派给 Core Vision Kit 去处理。这极大地简化了开发，也保证了体验的一致性和性能。

我让CodeBuddy继续完善，将识别返回的文本结果进行简单的正则表达式匹配，提取出金额（如包含“¥”、“￥”或数字加“元”的字符串）、日期和可能的商户名（常出现在文本开头或结尾）。虽然提取逻辑还很原始，但整个流程跑通了：拍照 -> 获取图片 -> 通过意图调用系统OCR -> 解析文本 -> 填充到新建收据的表单中。

3.4 任务四：数据持久化与分类管理

收据数据需要保存下来。我让CodeBuddy实现本地数据存储。“请使用鸿蒙首选的轻量级数据持久化方案，将收据列表保存到本地。并且，我需要支持为收据添加标签进行分类，比如‘餐饮’、‘交通’、‘办公’。”

CodeBuddy推荐了 @ohos.data.relationalStore （关系型数据库RDB）或 @ohos.data.preferences （首选项）。“对于结构化的收据数据，建议使用RDB。”它随后生成了完整的数据库帮助类 ReceiptDB.ts ，包括：

定义数据库表结构（ RECEIPT_TABLE ）。
创建数据库（ getRdbStore ）。
实现增删改查（ insertReceipt , deleteReceipt , updateReceipt , queryAllReceipts ）的异步方法。
在应用启动时初始化数据库。

对于分类标签，它建议在收据表中增加一个 category 字段，并提供一个预设的分类列表供用户选择。同时，它生成了一个简单的分类筛选界面，在列表顶部添加一个 Segmented 组件，用于切换显示“全部”或某个特定分类的收据。

4. 极限四小时：成果、反思与CodeBuddy的真实定位

距离我开始挑战，正好过去了4个小时。我面前有一个在鸿蒙模拟器上运行的“智慧收据管家”应用。它能实现：

首页列表展示 ：美观地展示带有商户、日期、金额和缩略图的收据卡片。
新增收据 ：通过右下角浮动按钮，调用系统相机/相册拍照选图。
智能识别 ：利用鸿蒙 Core Vision Kit 通过意图框架识别图片文字，自动填充金额、日期等信息（识别准确率依赖系统服务，我的简单正则提取在清晰小票上效果尚可）。
分类管理 ：手动选择或输入分类标签（如餐饮、交通）。
数据持久化 ：所有收据数据保存在本地RDB数据库中，应用重启后不丢失。
基础交互 ：列表项点击查看详情（一个简单的详情页），左滑删除等。

这个应用离一个真正的产品还有很大距离，比如缺少云同步、更强大的OCR解析引擎、报销报告生成等功能。但重要的是， 作为一个零鸿蒙经验的开发者，我在4小时内跨越了从“想法”到“可运行应用”的鸿沟 。

4.1 CodeBuddy在这次挑战中扮演了什么角色？

超级速查手册与语法纠正器 ：我不需要记住ArkTS List 组件的具体属性，不需要背诵 RDB 的API调用顺序。我只需要描述我想要什么（“一个可滑动的列表，每项有图片和文字”），CodeBuddy就能给出符合当前鸿蒙API版本的、语法正确的代码块。这极大地减少了查阅官方文档的时间。
跨技术栈的引路人 ：当我在安卓开发中习惯用 RecyclerView 和 Intent 时，CodeBuddy能准确地告诉我鸿蒙的等价物是 List 和 Want （意图），并写出正确的代码。它帮我完成了技术栈概念的映射。
问题排查的启发者 ：在环境配置和API调用报错时，CodeBuddy不能像魔法一样直接解决问题，但它能提供非常具体的排查方向（“检查权限声明”、“确认API版本”、“查看返回的error code含义”），这比在搜索引擎里漫无目的地查找要高效得多。
最佳实践的提醒者 ：它主动推荐使用 意图框架 调用系统OCR，而不是让我自己去硬编码集成，这体现了它对鸿蒙生态设计理念的理解。

4.2 CodeBuddy的局限性与“驾驶”心得

当然，CodeBuddy不是万能的，它更像一个需要“老司机”驾驭的强力副驾。

它不保证代码100%正确或最优 ：生成的代码可能需要微调，尤其是涉及复杂状态管理或性能优化时。例如，它生成的列表渲染函数在数据量大时可能不够高效，需要开发者自己引入 LazyForEach 进行优化。
它无法理解模糊的业务逻辑 ：如果你说“我要一个好看的主页”，它可能无从下手。你必须拆解成“主页顶部有个搜索栏，中间是分类图标网格，下面是瀑布流卡片”。需求描述越具体、越结构化，它的输出质量越高。
它不能替代对基础原理的理解 ：你可以用它快速生成一个使用 @State 装饰器的页面，但如果你不理解ArkUI的响应式更新机制，当状态变化不符合预期时，你依然无法调试。工具提升了效率，但并未降低知识的深度要求。

我的核心体会是 ：CodeBuddy（以及同类AI编程工具）是 强大的“加速器”和“破冰船” ，尤其适合：

快速原型验证 ：像我的4小时挑战，将想法快速可视化、可交互化。
学习新技术栈 ：降低初始的学习曲线，通过“对话-生成-运行-理解”的循环快速上手。
处理样板代码和常见模式 ：减少在重复性、模式化的代码（如CRUD操作、UI布局）上的时间消耗。
获取排查思路 ：当遇到错误时，提供一个基于经验的排查线索。

但它不是“自动驾驶”。项目的整体架构设计、复杂的业务逻辑、深度的性能调优、以及最终的产品决策，仍然牢牢掌握在开发者手中。这次经历让我相信，对于有经验的开发者，AI辅助编程不是威胁，而是能将我们从繁琐的语法记忆和基础API查阅中解放出来，让我们更专注于创造和价值实现的利器。那张让我头疼的小票，最终成了我探索鸿蒙开发和AI编程协作的起点，这个结果，远比一个完美的应用更有趣。