Android 开发中的 AI：非开发者的经验

# 非开发者用 AI 构建并维护 Android 应用：项目中期分析

一位零编程经验的业务分析师，仅用 AI 聊天工具（Claude）和 Android Studio 发布了两个 Android 应用。人类角色：定义任务、测试、集成变更并部署。AI 负责代码生成、错误诊断和架构建议。目标：验证这种方法能否支撑真实产品，包括有实际用户的 bug 修复和新功能开发。

方法不断演进：从零生成功能，到最小化差异修复。AI 任务需提供上下文，如症状、重现步骤、约束（不引入新库、数据持久化）和错误日志。

工具与工作流程

核心组件：

• Claude：代码生成、构建错误分析、持久化存储和 Activity 生命周期建议。
• Android Studio：构建、模拟器、手动变更集成。
• RuStore：发布、收集反馈、部署更新。

向 AI 报告 bug 的格式：

• 症状描述和预期行为。
• 重现步骤。
• 应用版本和约束。
• 之前修复尝试及日志。

AI 回复包括：可能原因、需检查文件、2–3 个解决方案（含风险），然后提供补丁。

发布后的结果

已发布应用：

• “168 小时”——基于每周 168 小时预算的规划器。
• “F1 大亨”——模拟器。

首篇文章后，下载量激增：“168 小时”从 1 次增至 71 次，“F1 大亨”从 13 次增至 45 次。真实用户暴露了未测试场景下的 bug。

案例 1：重启后计时器重置

症状：启动计时器 → 退出 → 返回 → 重置为零。AI 解决方案：从存储已过时间改为存储启动时间戳并重新计算。修复耗时 2 小时（诊断 + 构建 + 部署）。问题源于 Activity 生命周期和持久化存储缺失。

案例 2：手动活动创建

新增功能：用户输入自定义实体。AI 提出集成到数据模型、界面和存储中，并验证边缘情况（空字段、列表更新）。

对项目结构的理解

无深层语法知识下，形成操作模型：

• 类：分离界面、模型、存储。
• 数据模型：变更波及 UI 和持久化。
• 状态：主要 bug 来源——生命周期、重启、线程。
• 逻辑 vs 数据：界面处理 UI，存储管理数据。

这有助于精准 AI 提示，针对系统节点。

方法局限性

项目完整性：AI 生成局部变更，但忽略依赖。人类负责架构。

调试：适用于可重现 bug（计时器、状态）。间歇性问题（并发、设备特定）需日志和迭代。

UI/UX：功能实现，但无用户指标下人体工程学欠佳。

维护：反馈转为需求，更新为独立流程，确保向后兼容。

边界：适用于发布和修复，但需基础技能（生命周期、状态管理）。

关键收获

• 真实用户（71+45 安装）暴露 bug，从原型演变为产品。
• 修复（计时器、功能）在 AI 辅助下 2 小时完成。
• 人类作为集成者：测试、部署、把握结构。
• 局限：架构和复杂调试靠人类。
• 轨迹：应用上线并持续更新。

开发计划

• 稳定“168 小时”：测试检查清单、可预测计时器状态。
• 迭代功能：仅限当前架构内。
• 基础技能：生命周期、诊断、结构。
• 下次报告指标（bug、更新、趋势）。

— Editorial Team