我在零 Android 经验的情况下，用 4 天时间构建了一个 Android 应用——使用 Claude Code 和双层 AI 协议

Source: Dev.to

背景

我是一名控制系统工程师，而不是程序员。过去 15 年，我为欧洲运动摩托车制造商设计摩托车 ECU 的控制逻辑——牵引控制、快速换挡、线控系统。我的日常工作包括绘制流程图和编写规格说明，供软件工程师转化为代码。我能阅读 C 语言，但并不专业编写；我最擅长的语言是 VBA。

Kotlin、Jetpack Compose、Gradle —— 完全陌生的领域。

我需要为个人问题寻找解决方案：我持有一款带有投资成分的寿险产品。供应商的在线门户几乎没有任何有用信息——没有图表、没有趋势可视化，也无法将表现与基准指数进行比较。该产品的价值一直在缓慢下降，且在新年后进一步跌了好几步。我需要看到实际数据，而不是仅凭感觉。

没有现有的应用能够满足这些需求，于是我决定自己动手构建一个。

早期 AI 尝试

最初，我尝试了一种单工作流的 AI 方法：描述我想要的内容，让 AI 提出方案，批准后让它实现全部。结果是代码看似可运行，但充斥着浅显的修补、对需求的误解以及反复出现的 bug。AI 在它并未完全理解的基础上进行构建，而我因为信任它在我不擅长的实现细节上的判断，未能捕捉到这些问题。

这次经历给我上了重要的一课：AI 需要和人类工程团队使用的相同的关注点分离。

双层 AI 协议

设计 AI – 架构师

• 负责需求分析和系统设计。
• 将实现指令以 Markdown 文件的形式结构化。
• 永不直接编写代码。

实现 AI（Claude Code）– 构建者

• 接收具体、范围明确的指令并执行。
• 编写代码，运行构建，报告结果。
• 不 做设计决策。

我 – 桥梁

• 传递指令，在真实设备上测试，做出判断并处理 Git。
• 在修复前先进行调查：当出现问题时，实施 AI 报告问题；设计 AI 和我一起分析结果，并在编写任何新代码之前决定处理方案。

关键规则： 修复前先调查。 禁止盲目敲代码。

项目时间线

第 1 天 – 设置与拆分

• 选择技术栈：Kotlin + Jetpack Compose。
• 将项目拆分为 7 步。
• 当天结束前在模拟器上构建了第一个版本。

第 2 天 – 数据层

• 实现了数据层。
• 碰到障碍：Room（Android 的数据库库）因 kapt 弃用而与 AGP 9.0 不兼容。
• 决策（在 2 小时内）：放弃 Room，使用 SharedPreferences + Gson。虽不优雅，但能满足 MVP 范围的功能。
• 损失时间：约 2 小时。

第 3 天 – 抓取与归一化

• 实现了对保险提供商数据的 HTML 抓取。
• 为基准指数添加了 CSV 解析。
• 进行基于日期的内部连接归一化。
• 构建检测逻辑：4 种判断类型和 10 级排名系统。

第 4 天 – UI 与后台工作

• 集成 MPAndroidChart 进行图表绘制。
• 添加设置页面、导航、应用图标。
• 配置 WorkManager 进行带指数回退的后台调度。
• 实现推送通知。
• MVP 完成。

生成的制品

• 53 个结构化指令文件。
• 7 个步骤聊天文档。
• 1 个汇总聊天，协调所有内容。

经验教训

• 库兼容性: Room + kapt 在 AGP 9.0 上是一个意外的阻碍。Design AI 与我讨论了权衡，并接受在 MVP 中使用 SharedPreferences。
• 工具熟练度检查: 最初使用 Vico 进行图表绘制，但在 Implementation AI 无法生成可运行代码时改用了 MPAndroidChart。在投入使用前，请验证 AI 对库的实际熟练程度。
• 故障遏制: 两层协议防止了故障使项目脱轨。先进行调查，讨论方案，然后实施修复。
• 可复用协议: 我之前在 Bridgiron——一款桌面开发支持工具中使用了相同的协议。这种做法在不同领域和技术栈中都有效。

结论

我已经使用 Claude Code 大约四周，并且系统化了一套可重复使用的 AI 增强开发协议。如果你是一位在某一领域有经验的工程师，想知道 AI 是否能让你在不熟悉的技术栈中保持高效：是的，但前提是你把 AI 当作一个需要工程化的系统，而不是仅仅写一个提示。

控制系统工程师，拥有 15 年摩托车 ECU 开发经验。目前正在探索 AI 增强的开发工作流并记录有效的方法。