技能介绍

移动开发中的失控风险

从想法到上架的过程中，最常见的问题不是写不出代码，而是阶段性目标缺失导致方向偏移。很多团队在需求未明确时就急于选型，结果后期发现技术栈无法支撑核心场景；或者功能开发完成后才意识到合规材料缺失，直接卡住上线计划。

更隐蔽的问题在于阶段间缺乏可验证的产出物。当"需求确认"变成口头共识，当"技术选型"缺少决策记录，团队会在反复返工中消耗信任。

七阶段结构化推进

Mobile App Bootstrapper 通过明确的阶段划分解决上述问题：

Phase 0 需求澄清：产出 PRD.md，包含背景、目标用户、核心功能优先级（P0/P1/P2）与可测试的验收标准
Phase 1 技术栈决策：基于决策树提供 2-3 个候选方案，记录选定理由与放弃原因
Phase 2 项目脚手架：根据技术栈生成可运行骨架，包含 .gitignore、CI 配置与最小可运行 demo
Phase 3 架构落地：定义目录结构、依赖规则与环境配置方案
Phase 4 开发循环：每个功能遵循 TDD，确保测试覆盖与代码质量
Phase 5 质量关卡：覆盖率、性能、无障碍与真机测试形成完整质量门禁
Phase 6 上架发布：国内外商店流程差异处理，灰度与回滚策略

每个阶段都有明确的退出标准，例如 Phase 2 要求"骨架能在本机或模拟器跑通并显示 demo 页"，Phase 6 要求"应用商店过审并上线，崩溃率 < 0.5%"。

适用边界与协作模式

该技能不替代平台级技能。遇到 Android 原生细节时会引导使用 android/skills，RN 场景引用 callstackincubator/agent-skills，Flutter 则对接 flutter-claude-code。这种编排模式要求用户已具备基础工程判断能力，能够审核 AI 生成的代码。

对于只想快速验证想法的场景，可以跳过 Phase 3 的完整架构设计，直接在 Phase 2 基础上开发 MVP。但任何涉及国内上架的项目，必须从 Phase 0 开始就将软著、ICP 备案与隐私合规纳入排期，否则后期调整成本极高。