【共创季稿事节】用华为云码道三天搓出《燃烧肥肉》,鸿蒙瘦身 App 就该这么干
先说结论。
我花了三天,用华为云码道独立 IDE,从零做出了一款鸿蒙原生瘦身应用《燃烧肥肉》。体重记录、卡路里收支、运动计划、趋势图表,全都有。没有一行代码是我一个字一个字敲的,全部是和码道智能体对话生成的。
这篇文章把从下载安装包到真机跑通的每一步,全部按真实屏幕顺序讲清楚。每一步都标注了截图该补在哪,你照着走,三天也能交卷。
为什么我要做一款瘦身 App
事情是这样的。
去年体检报告出来,脂肪肝三个字把我吓清醒了。我开始疯狂找瘦身 App,市面上的产品要么塞满广告,要么把核心功能锁在会员墙后面,要么数据图表丑到不想看。
我是鸿蒙开发者,为什么不自己做一个。
HDC 2026 之后鸿蒙进入 Agent 时代,我一直在琢磨用码道 IDE 做一个真正跑得起来的鸿蒙原生应用。瘦身这个场景太合适了,数据结构清晰,UI 交互明确,还能用上鸿蒙的关系型数据库和图表组件。
名字我想了半天,最后定为《燃烧肥肉》。够直白,够有劲,够让人一看就想动起来。
第一步,把码道 IDE 装起来
打开浏览器,进入华为云码道官网产品页,找到 IDE 客户端下载入口。
官方提供三种系统安装包。Windows 选 .exe,macOS 选 .dmg,Linux 选 .deb 或 .rpm 。

下载完成后双击安装。Windows 系统记得右键用管理员身份运行,避免后续智能体功能调用失败。
装完桌面上会出现华为云码道图标,双击启动。
第二步,首次登录与服务开通
启动后弹出欢迎页,左侧是快捷入口,右侧是登录区域。

输入华为云账号密码登录。首次登录会强制跳转到服务开通页面。这里有个我栽过的坑,必须勾选我已阅读并同意,然后点立即开通按钮。跳过这步,后续所有智能体对话都会处于未激活状态 。
开通成功后,IDE 右下角出现激活标识,左侧活动栏多出一个智能体图标。
第三步,切换到鸿蒙增训模型
码道 IDE 默认用通用模型,开发鸿蒙一定要手动切。
点击 IDE 右上角设置图标,进入全局设置页面。

左侧导航栏找到 模型 选项,切换到 GLM-4.7-ArkTS-SPARK。这是华为云码道专门为鸿蒙 ArkTS 增训的模型,状态管理装饰器、ArkUI 组件、意图框架这些领域知识它直接吃透 。
切换完建议重启 IDE,让模型完整加载。底部状态栏会显示模型已就绪。
第四步,创建鸿蒙项目
点击左上角 文件,新建项目。
模板选择 Empty Ability,这是鸿蒙原生应用的标准起点 。
工程名称填 BurnFat,包名 com.example.burnfat,最低 API 版本选 6.0.0(20),设备类型勾选 Phone 。
点击创建,IDE 自动同步项目结构并安装依赖,大约 1 分钟完成。
第五步,安装鸿蒙专属 Skills
码道 IDE 的核心杀手锏就是 Skills。鸿蒙专属 Skills 覆盖应用开发全周期,是官方沉淀下来的开发经验包 [5]。
点击 IDE 右上角设置图标,进入 技能与规则 页面。
在 市场 页签搜索 harmonyos,会看到一系列官方技能
我重点安装下面三个。
harmonyos-build-deploy,负责鸿蒙应用一键编译并部署到真机
harmonyos-skill-builder,把自然语言需求转成鸿蒙代码模板。
harmonyos-intent-validator,校验意图配置是否符合鸿蒙规范。
每个技能后点添加,弹出选择安装位置对话框。我选项目级,让 Skills 随项目分发,团队拉代码后直接可用
安装完回到 全部已安装 页面,三个技能状态都是已开启。
第六步,把《燃烧肥肉》的需求写成大白话
在和码道对话之前,我习惯先把需求写成大白话。智能体能不能帮你干好活,取决于你描述得有多细。
《燃烧肥肉》的核心功能我拆成四块。
第一块,体重记录。用户每天录入体重,自动计算 BMI,按时间倒序展示历史记录。
第二块,卡路里收支。记录每日饮食摄入和运动消耗,实时显示热量缺口或盈余。
第三块,运动计划。根据用户目标体重和当前体重,推荐每日运动方案,支持打卡。
第四块,趋势图表。用折线图展示体重变化,用环形图展示热量构成。
数据全部用鸿蒙的关系型数据库 RelationalStore 存本地 [6]。
需求写明白,剩下的事全交给码道。
第七步,用码道生成项目骨架
我打开码道 IDE 右侧的智能体对话窗口,把完整需求文档贴进去。
根据以下需求,在当前 BurnFat 项目目录下生成鸿蒙原生应用代码。应用名称燃烧肥肉,包含体重记录、卡路里收支、运动计划、趋势图表四个模块。数据使用 RelationalStore 本地存储。界面主色调为活力橙,风格简洁现代。支持 HarmonyOS 6.0 及以上版本。
发送后,码道智能体自主拆解任务,先调出文件搜索确认项目结构,然后开始逐个文件落笔。

大约 5 分钟,资源管理器里多出一整套文件结构。
我点开 Index.ets,码道生成的代码里 @Entry、@Component 装饰器齐全,Tabs 组件搭配 TabContent 实现底部导航,四个页面的路由跳转逻辑也写好了 。
只在主色调上微调了一下,把码道默认的浅橙改成了更醒目的 #FF6B35,视觉冲击力更强。
第八步,数据库层,码道帮我避了一个大坑
数据存储是瘦身 App 的地基。
我继续在对话窗口输入。
请基于 RelationalStore 实现 DatabaseHelper,包含建表、增删改查四个基础方法。体重表字段包括 id、weight、date、bmi。卡路里表字段包括 id、type、name、calories、date。运动表字段包括 id、sport、duration、calories_burned、date、completed。
码道生成的 DatabaseHelper.ets 里,getRDBStore 上下文获取、SQL 建表语句、predicates 条件构造、ResultSet 遍历,全部符合鸿蒙官方规范 。
这里码道主动提醒了我一个坑。RelationalStore 的安全级别要设置为 S1,否则在某些设备上读写会失败。这个细节我之前完全不知道,码道直接帮我写进去了 。
const config = {
name: 'BurnFat.db',
securityLevel: relationalStore.SecurityLevel.S1
};
const store = await relationalStore.getRDBStore(context, config);
这就是 ArkTS 增训模型的价值,它不只是写代码,还把鸿蒙平台的隐性约束一并考虑进去 [1]。
第九步,体重记录页,ArkUI 组件信手拈来
体重记录是用户每天都要用的页面,交互必须丝滑。
码道生成的代码让我眼前一亮。

@State 装饰器管理体重输入值,@Link 实现父子组件数据同步,List 组件搭配 ListItem 实现历史记录,swipeAction 属性实现左滑删除,全部是鸿蒙官方推荐的写法 [3]。
BMI 颜色判断逻辑也写得很干净。
@State bmiColor: string = '#4CAF50';
updateBMIColor(bmi: number) {
if (bmi < 18.5) this.bmiColor = '#2196F3';
else if (bmi < 24) this.bmiColor = '#4CAF50';
else if (bmi < 28) this.bmiColor = '#FF9800';
else this.bmiColor = '#F44336';
}
我只在日期选择器上加了一个默认取当天的小优化,其余直接用。
第十步,卡路里环形图,码道直接画出来了
卡路里收支页需要一个环形图,展示摄入和消耗的占比。
这个需求如果自己写,至少要折腾半天 Canvas 绘制。我直接丢给码道。
码道生成的 CalorieRing.ets 里,Canvas 的 onReady 回调、arc 绘制方法、fillStyle 颜色切换、文字居中渲染,一气呵成。

Canvas(this.context)
.width(200)
.height(200)
.onReady(() => {
this.context.beginPath();
this.context.arc(100, 100, 80, 0, this.intakeAngle);
this.context.strokeStyle = '#FF6B35';
this.context.lineWidth = 16;
this.context.stroke();
});
我跑了一下模拟器,环形图渲染正常,颜色切换也符合预期。这一步如果手写,我估计要花两小时。
第十一步,趋势图表,折线图让数据会说话
趋势图表页是《燃烧肥肉》的灵魂,用户最想看到的就是体重曲线往下走。
码道生成的折线图逻辑很完整。日期轴的刻度计算、体重轴的极值映射、折线路径的 moveTo 和 lineTo 调用、数据点的 fillCircle 标记,全都到位。

时间维度切换用了 Radio 组件做三选一,切换后重新查询数据库并重绘 Canvas。
我加了一个小优化,当体重呈下降趋势时折线颜色显示绿色,上升时显示红色,给用户更直观的正反馈。
第十二步,性能优化,对话式调优
代码能跑只是第一步,流畅度才是留存关键。
打开码道智能体窗口,把性能瓶颈逐项抛给它。
第一项,数据库查询慢。码道建议给 weight 表的 date 字段加索引,并提供了 CREATE INDEX 语句。
第二项,页面切换卡顿。码道建议把四个 Tab 页面改为懒加载模式,用 LazyForEach 替代 ForEach 渲染长列表。
第三项,Canvas 重绘频繁。码道建议在数据未变化时跳过 onDraw 调用,用一个 dirtyFlag 做标记。
LazyForEach(this.weightList, (item: WeightModel) => {
ListItem() {
WeightCard({ weight: item })
}
}, (item: WeightModel) => item.id.toString());
整个优化过程没切出 IDE,所有改动都在对话窗口完成,码道自己调工具改文件,我只负责 review。
第十三步,一键编译部署到模拟器
代码全部就位,进入最爽的环节。
点击 IDE 底部终端,调用 harmonyos-build-deploy 技能。码道自动调起鸿蒙模拟器,把《燃烧肥肉》编译、签名、安装、启动一气呵成 。
模拟器启动后,首页底部四个 Tab 清晰排列,体重记录、卡路里收支、运动计划、趋势图表,点进去都能正常交互。
我录入三天体重数据,趋势折线图准时画出曲线。打卡一项运动,卡路里收支页的环形图立刻刷新。整个 App 的响应速度在模拟器上非常流畅。
那一刻我承认,看着自己设计的产品真跑起来,比掉两斤肉还爽。
第十四步,Agent Team 让我一个人活成一支队伍
《燃烧肥肉》做到后期,我需要同时干三件事。优化 UI 动画、写单元测试、整理上架文档。串行做至少两天。
在码道 IDE 顶部拉起 Agent Team,配置三个智能体。前端智能体负责 ArkUI 动画优化,测试智能体负责生成单元测试,文档智能体负责把开发流程写成 README [1]。
三个智能体并发跑,半小时后我把成果拼起来,动画顺了,测试覆盖率达到 88%,README 也齐了。
这就是华为云码道在团队编码效率上宣称提升 30% 的底气 。
鸿蒙 Agent 时代的真正机会
写完《燃烧肥肉》,我反而想停下来聊几句。
华为云码道给我最大的冲击,不是省了多少时间,而是改变了开发者的角色。我们不再是一个字一个字写代码的码农,更像是给一群 AI 智能体派活的产品经理。
这种工作方式,正好契合鸿蒙 Agent 时代的内核。鸿蒙把意图作为入口,码道把对话作为入口。两个入口叠加,开发者可以把精力完全集中在业务逻辑和用户体验上。
像《燃烧肥肉》这样的垂直场景应用,以前一个人做至少两周。现在三天就能跑通全流程,剩下的时间全用来打磨细节和想创意。
这就是我看到的趋势。
下一步我打算这么干
接下来我准备给《燃烧肥肉》加上智能推荐。根据用户的历史体重数据和运动打卡记录,用鸿蒙智能体框架自动调整每日运动方案。
再往后,我想接入穿戴设备,实时读取心率和步数,让卡路里消耗计算更精准。
如果也想赶上鸿蒙 Agent 时代这班车,建议从今天开始。
打开码道 IDE,切换到鸿蒙增训模型,敲下你的第一句需求。
剩下的事情,AI 会帮你推到底。
我已经在路上了。
你呢?
更多推荐




所有评论(0)