前阵子我做完网页镜像后，最先遇到的不是“模型不够强”，而是一个很现实的问题： 每次用完，关掉网页，下次打开，聊天记录没了。
那种感觉很割裂。AI 聊天明明是一个“持续对话”的工具，但网页临时会话的体验，总让我觉得它像一次性用品。 于是我冒出一个念头：我要把它做成手机 App。能随时打开、随时用、还能接着上次聊。
先说结论：这个项目不是长期打磨产物，而是一个两天完成的 demo。 但这两天很扎实——一天把主链路做出来，一天专门修 bug。
做着做着我又想到：既然都做了，为什么不顺手做成家人和朋友也能直接上手的版本？尤其是长辈，他们其实很需要一个门槛低、随手可问的 AI 助手。
所以这次项目里，很多设计从第一天就不是为了“炫功能”，而是为了“真能用”：
- 字体放大，默认更清晰
- 语音输入，少打字
- 语音播报，少盯屏
- 中文表达尽量大白话，避免技术黑话
这就是 Aura 的起点。
图 1：Aura 启动界面。不是为了做“好看皮肤”，而是让产品从一开始就有可识别、可持续迭代的入口。
不是“我写代码”，而是“我在编排 AI 团队”
这次我用的是很典型的 vibe coding 流程，但不是一句 prompt 跑到底，而是分角色协作：
- Gemini：前期需求整理、阶段拆分、生成结构化大纲与 prompt
- Antigravity：按模块产出主体代码
- Android Studio（含 Gemini）：工程整合、依赖和 Gradle 配置修正
- Claude：救火修 bug、处理“越修越乱”的疑难问题
- 我：架构取舍、联调验收、功能优先级决策
这里必须说一句很真实的话： 有些问题让 Gemini 连续修，确实会越修越偏；但 Claude 接手后，很多 bug 是“修完就能跑”。 这不是谁绝对强，而是我这次的体感很明确：多模型协作比单模型硬刚靠谱得多。
两天完成：一天开发，一天排雷
这个项目不是一天冲完的，而是两天：
- 第一天：功能快速成型
- 第二天：专注 Release 包调试和稳定性修复
第一天主要把主干打通： 原生 Android（Kotlin + Compose）前端 + Cloudflare Worker + D1 后端网关，保证激活、鉴权、对话链路都可用。
第二天基本就是 Android 经典剧情： Debug 正常，Release 出问题。 包括资源压缩导致启动资源异常、混淆引发的序列化/类型问题、Manifest 早期硬编码残留等。
最后的原则很简单：优先稳定，其次体积，再谈“理论最优”。 能稳定交付 demo，比参数更“漂亮”重要得多。
为什么我会从网页转向 App
起点其实很单纯：我需要一个“有记忆”的 AI 助手，而不是每次打开都从零开始。 App 的意义不是把网页搬进手机，而是把“连续使用”这件事做完整。
图 2：历史记录界面。对我来说，这张图比任何功能列表都更能说明为什么必须做 App。
长辈友好不是附加项，而是主路径
很多 AI 产品默认用户是年轻人：打字快、英文术语熟、愿意折腾。 但我实际想覆盖的人群里，恰恰有很多不是这种用户画像。
所以这次我更在意的是：
- 交互是否直觉
- 文案是否听得懂
- 功能是否减少操作负担
比如语音输入和语音播报，对年轻人是“可选项”，对部分长辈其实是“核心能力”。 如果一个 AI 助手只能被技术用户顺畅使用，那它的价值天然被缩小了。
图 3：大字体聊天界面。适老化不是后补功能，而是最初就写进产品约束里的能力。
这次实践到底验证了什么
这个 demo 到这里，目标已经达成： 验证了想法，也验证了 vibe coding 这条路径在真实项目里能跑通。
它不是“未来会完成”的计划，而是一个已经完成的实验结果：
- 想法可落地
- 多 AI 协作可执行
- 两天周期可以做出可用、可分享的 Android AI 助手
最后一点感慨
以前做项目，总觉得要等“万事俱备”才能开始。 这次反过来：先开始，再让系统在实践里长出来。
你会发现，AI 时代最稀缺的不是代码产能，而是你能不能把问题定义清楚、把协作流程搭起来、把取舍做干脆。 当你真的把一个想法塞进手机，自己每天都在用，家人朋友也能直接用——那一刻比任何技术名词都有说服力。
#vibe-coding #android #aura-app #适老化AI