实测 Vibe Coding：快速开发 HarmonyOS 玩 Android 客户端

最近我用 Vibe Coding 的方式做了一个 HarmonyOS 版玩Android 客户端。

这个项目对我来说挺特别。它不是那种"一句话生成一个 App"的演示，也不是完全把代码丢给 AI 不管。更真实的情况是：我不断提需求、贴报错、给接口文档、发运行截图、挑 UI 细节；AI 负责读项目、改代码、跑构建、补页面、整理文档。中间来来回回很多轮，最后把一个可以正常使用的 App 做了出来。

项目已经开源：

github.com/andoter0501...

最后做出来的效果

这个 App 基于 WanAndroid 开放 API，主要做了这些能力：

• 首页文章、Banner、置顶文章、常用网站
• 体系、项目、广场、搜索、文章详情
• 登录注册、Cookie 会话恢复
• 收藏、取消收藏、我的收藏列表
• 我的页面积分、排名、收藏数
• 下拉刷新、分页加载、Tab 页面缓存
• 系统设置、清除缓存、关于、源码地址、隐私协议

一些运行效果如下。

首页	体系	项目
广场	我的	我的收藏

技术栈比较直接：HarmonyOS、ArkTS、ArkUI、hvigor、WanAndroid Open API。

我对 Vibe Coding 的真实感受

做之前我对 Vibe Coding 的理解也比较模糊，以为就是"把想法告诉 AI，然后等它生成代码"。

真的做完一个项目后，我发现不是这样。

Vibe Coding 更像是把 AI 当成一个执行力很强的工程搭档。它可以很快读代码、定位问题、补齐功能、修编译错误，但方向、取舍、验收和审美还是要靠人。

比如我经常不是说"帮我优化一下"，而是直接把问题描述清楚：

目前每次切换 tab 页都会重新请求网络，感觉好慢。
请排查原因并优化，但不要影响手动刷新和分页加载。

或者：

这个接口说明如下，cid 是二级分类 id，页码从 0 开始。
点击二级分类后进入文章列表，点击文章打开详情页。

这种表达比一句"帮我做体系页面"要有效很多。AI 不怕任务复杂，它怕的是目标含糊、上下文不够、验收标准不明确。

UI 是最难一次到位的部分

这个项目里，我花时间最多的不是接口，而是 UI。

我的实际流程是这样的：

1. 先用 Minimax 做 UI 设计方向。
2. 对满意的设计图，用"高保真 1:1 还原"的提示词，让 AI 先还原成 HTML。
3. 在浏览器里看 HTML 效果，继续微调到比较满意。
4. 再把 HTML 交给 Codex，让它基于当前 ArkUI 项目实现最终页面。

这里"高保真 1:1"非常关键。

一开始我也尝试过直接让 Codex 看效果图改 ArkUI，但三次以内很难满意。不是它不会写 UI，而是图片到 ArkUI 中间缺少一个可验证的过渡层。HTML 更适合作为中间稿，布局、间距、字体、颜色都能先跑出来看。等视觉稳定后，再落到 ArkUI，效果会好很多。

我后面比较常用的提示词是：

这是目标效果图，请先高保真 1:1 还原成 HTML。
要求保留布局层级、间距、字体比例、颜色和卡片圆角。
先不要考虑 ArkUI 实现，先把视觉稿还原出来。

HTML 稳定后，再继续：

请参考这个 HTML 效果，在当前 ArkUI 页面中实现。
结构和视觉跟 HTML 对齐，但尺寸要适配现有项目比例，
不要破坏原来的数据绑定和点击逻辑。

这个流程比直接"照图改 App"稳定很多。

比如"我的页面"一开始只是显示积分、排名、收藏数三个数字，看起来不知道每个数字是什么意思。我让 AI 优化后，它做出了统计卡片。后来我又给了参考图，整体结构对了，但尺寸太大，菜单行、字体、图标块都不符合原项目比例。

这时候我没有只说"不好看"，而是继续补了一句：

整体都太大了，不符合设计比例，整体格式是可以的，但是要尺寸大小跟以前的保持一致。

这句话其实很重要。它告诉 AI：结构可以保留，但比例要收回来。后面它就把统计卡高度、字体、图标块、菜单行高都调整回移动端更舒服的尺寸。

UI 这块我最大的经验是：不要期待一次到位。要把"不舒服"说成可以执行的反馈，比如比例太大、文字没左对齐、头像区域要保持原样、类型标签需要换位置、卡片间距过宽。

这次踩过的几个坑

第一个坑是 ArkUI 语法。

HarmonyOS ArkTS 和普通 TypeScript 不太一样，ArkUI 的 Builder、组件调用、状态管理都有自己的规则。一开始首页编译失败，日志里有这种错误：

Property 'sectionTitle' does not exist on type 'HomePage'
'this.sectionTitle(...)' does not meet UI component syntax

这类问题不能只按 JavaScript 的习惯去猜。AI 需要先看当前页面结构，再按 ArkUI 的 Builder 语法补方法、改调用方式。后来我给报错时都会尽量贴完整 hvigor 日志，这比只说"编译失败"有用得多。

第二个坑是接口文档一定要给完整。

WanAndroid 有些接口看起来简单，但细节会影响实现。比如分类文章接口页码从 0 开始，page_size 一旦传了，后续分页也要一直带上；收藏接口更容易混，文章列表取消收藏和我的收藏页面取消收藏用的不是同一个接口。

如果只说"完善收藏功能"，AI 很可能会只实现最常见的一种情况。把官方 API 说明、参数规则、返回示例都贴出来后，它就能把 Repository、ViewModel、页面状态和登录失效处理一起补完整。

第三个坑是登录态。

WanAndroid 的收藏、个人信息这些接口都需要登录，登录后要保存 Cookie。这个地方如果没有处理好，页面看起来写完了，但一请求就是未登录。后来我把重点放在"登录后持久化 Cookie，后续请求自动带上 Cookie"，收藏列表、个人积分、收藏数量这些数据才稳定出来。

第四个坑是 Tab 切换反复请求网络。

开发到后面我发现 App 切换 Tab 很慢，每次回来都重新请求。排查后发现主页面是按当前 Tab 条件渲染的，切走页面就销毁，切回来又重新创建，于是 aboutToAppear() 又触发加载。

最后改成了访问后缓存挂载：第一次进入某个 Tab 时创建页面，之后保持挂载，切换时只控制显示隐藏。这个优化不复杂，但体验提升很明显。

第五个坑是有些布局问题不是 padding。

系统设置页曾经出现过标题下面一大块空白。一开始我们一直怀疑是间距问题，调 padding 没用。后来结合截图重新看布局，发现问题出在容器组合上，Scroll + Column 在那个页面里没有按预期贴顶排列。最后换成 List + ListItem，空白才消失。

这个坑给我的提醒是：截图很重要。你给 AI 一张运行图，它更容易判断是样式数值问题，还是组件结构问题。

我现在会怎么跟 AI 提需求

做完这个项目后，我发现好用的提示语大概有几类。

给报错时，不要省日志：

这是当前 hvigor 编译日志，请先判断原因，再做最小修改，并跑构建验证。

给接口时，不要只贴 URL：

这是官方接口说明，包括请求方式、参数、分页规则和返回示例。
请补齐模型、请求、页面展示、空状态和错误处理。

给 UI 时，不要只说照着改：

结构参考效果图，但尺寸保持当前项目比例。
文字左对齐，标签放在标题下方，不要影响原来的点击逻辑。

控制范围时，要明确边界：

这个页面只做清除缓存、关于、源代码地址、联系方式、隐私协议。
不要增加额外设置项。

这些话看起来啰嗦，但实际很省时间。因为 AI 少猜一次，就少返工一轮。

AI 帮我省了什么，也没省掉什么

这次项目里，AI 确实帮我省了很多时间。

它适合做读代码、补接口、修编译、改 UI、整理 README 这类工作。尤其是 ArkTS 编译报错、页面字段补齐、重复列表样式调整，这些以前会消耗很多耐心，现在可以推进得很快。

但它没有省掉人的判断。

哪些功能先做，哪些功能不做，UI 到底舒不舒服，页面是不是真的符合预期，App 切换起来顺不顺，这些都需要我自己看、自己判断、自己反馈。

所以我不会说 AI 替我完成了这个项目。更准确地说，是我用 AI 把很多原本耗时间的开发环节压缩了，然后把更多精力放在产品体验和最终验收上。

最后

如果你也想尝试 Vibe Coding，我不建议一上来就让 AI "写一个完整 App"。可以从一个真实的小项目开始：一个页面、一个接口、一个报错、一次 UI 调整，慢慢把协作方式跑顺。

这次对我最大的收获不是"AI 能写多少代码"，而是我开始形成一套和 AI 协作开发的方法：目标说清楚，资料给完整，反馈要具体，改完要验收。

项目已经放到 GitHub，README 里也整理了运行截图和实现说明：

github.com/andoter0501...