所谓的一天开发一个 App，听起来有点恐怖，实际上也确实恐怖，然而最终可能是问题也不太大。为什么能这样玩不是我们变厉害了，而是，我们可以利用的 AI 工具变的越来越厉害了，只要你掌握基本的流程，完全可以赋值这个过程。
当然，需求的澄清是一个极其需要时间的过程，这里，我们假设需求已经澄清了，最理想的情况下，这个是你自己的一个想法。然后我们接下来需要做的是4 个部分。
- 根据需求画交互稿
- API 设计与实现
- 前端实现
- 后端部署、前端打包发布
交互设计部分
有人说这两个也很耗费时间把，其实不然，都可以利用 AI 的能力，尤其是 API 生成这里，我们团队已经设计了一个工作流工具，这个还是得益于大师小黄的牛逼想法，扯远了，回答交互上来。
比如我话交互就使用MasterGo
比如说，我内心有个想法，希望做一个帮做我创作的工具： 然后我就基于我的想法，将功能点一一说出来就好，提醒一下，如果你本身没有什么美感，你完全不要说怎么布局摆放，MasterGo直接会给你合理安排，你要做的就是告诉他你有哪些主要功能就好。
api设计于实现部分
然后就是 api 设计，其实 api 也是一样的道理，你说出你的功能，交给 Claude，他就 可以将你的 api 和数据模型都定义出来，接下来的一步，就是库表都给你设计出来，使用 Prisma，你甚至都不用写 sql，数据库就放在那里可用了，基本的增删改查什么得都有了，然后 api 是啥，api 就是基于你的功能点出来的，这些AI 做得又快又好，我们只需要 check，check，就 ok 了。
api 设计好了之后，就是实现 api，有人说，这个时候总该出马了吧！我会告诉你，七万不要，请收手！
依然不需要，我们出测试用例，让 AI 先把测试用例给完善了，Ai 完善测试用例之后，在然他写api 的实现，他 api 实现的对不对，跑一跑测试用例就知道了，如果不对，把测试用例的错误信息回馈给 AI，让他修复。也就是你用api 定义和测试用例把代码实现给限制死了，就是是个猴子去敲键盘，也能把代码敲出来，一万年不行就一亿年，你不要忘记，宇宙中地球上的人类是怎么诞生的，这个概率不也挺小的，但是，他却是事实。
这个过程下来，ok，咱们的 API 也用 AI 给实现了。
我姑且算这个时间是 1 个小时已经过去了，其实比较简单的，10 个以下的 API，是根本用不上这么久。。。
问个问题，需求文档到 api 的设计与实现真难吗？
其实，刚才提到的大师小黄设计的这个工作流，需求文档喂给工作流，半个小时出来的是 api 文档基于 api 的测试用例，以及 api 的实现代码，完全自动，人都不用管。有人说数据库你总得部署吧，假如我告诉你使用 Prisma 屏蔽呢，本地使用 sqlite，上线无缝切换到 pg or MySQL 呢？
当然，比较复杂的需求，是有人工干预环节的，然后 api 测试多次不通过有告警，此时也需要人为干预，但是整个过程人力释放的很干脆。
后端，这种纯粹逻辑的东西，一堆增删改查，一堆逻辑，完全就可以直接交给 AI。
可能复杂的地方在于前端了，前端因为交互上的复杂，以及难以对界面进行测试的客观原因，人为干预的节奏要强一些，但是不要担心，也不需要你干太多的活。因为我们在好几个项目中，实战下来，沉淀了不少的 prompts，专门应对前端模块化研发中的不同场景。
前端部分的实现
前段部分就花样贼多，如 Next.js 网页，移动端 Expo，小程序等等，不用怕，咱们把技术栈确定好，以后万金油，比如，我们团队就 React 了，雷打不动。虽然 Vue 也不是不能搞，但是切来切去一个是不容易积累。
比如，咱们这次要做的是 App，我们就选择 Expo，咱们直接打开 Cursor。
使用咱们团队沉淀的一套 prompts，从里面跳出专门针对移动端 App 场景的初始化框架生成，然后看效果：
代码已经给生成了，我们跑的试一试。
哈哈，缺了点东西，但是基本的架子已经给我们整好了，而且目录文件都创建好，接下来按图索骥，填充各个模块就好了。
时间已经过去了，1.2 个小时，算这么多吧。
前端一定要做到模块化开发：接下来就是挨个模块的开发和串联了哦
有人说，这个总需要人来开发了吧，no,no,no ，还是别冲动，我们对于每个模块，准备 3 个东西
- 交互稿
- 需求文档
- api 文档
ok，有了这个，配合咱们的 prompts 集合，Cursor会给你惊喜的，你知悉要告诉，开干，基本他就给你把代码写个 7788 了，接下来即使试错 2 轮。然后实在不 OK，自己改改就差不多了。
按照经验，基本上小模块半个小时搞定一个。大的模块也差不多是 1 个小时，2 个小时算是非常复杂的了。
所以，基本是 8 个模块，大哥，总不至于 8 个，个个都难把，所以，预测 5 个小时可以搞定。
这么算下来，是不是 8 个小时内，可以基本完成一个 App 的开发，连后端都写了。
接下来就是后端部署、前端发布的事情了。
后端部署
后端部署，我感觉真的没有什么好说的、直接，Docker 部署，简单粗暴，docker-compose一些好，后面的事情真的美滋滋。
前端部署
这次咱们是使用的 Expo 来开发，我就提一下。
避免一些小白踩坑。进入项目之后，直接执行 npx expo prebuild ，为什么要执行这个命令，因为这样可以直接把咱们的原生的目录给创建出来，方便，我们在必要的时候，直接上手给原生代码中加一些能力，当然，如果 Expo 提供的库已经足够可以用了，我们完全没有必要把原生的目录显示出来，直接使用 Expo 提供的组件，基本上可以覆盖 80% 的场景需求。
增加 3 个命令
"buildAndroid": "expo prebuild && expo run:android",
"buildIOS": "expo prebuild && expo run:ios",
"buildAndroidLocal": "expo prebuild && expo run:android --local"
方便我们本地打包。
打包失败怎么办
打包失败怎么办。
Expo 可能不知道你本地 Android sdk 的路径，所以需要你配置下。
打出包很大
一个 Android App，直接打包出来就是 75 多 M 了，这谁受得了。其实打包大不全是 Expo 的锅，比如，就 Android 来说，打包大的一个直接原因是，Android 构建的时候，默认就是将所有的架构的 so 库都打进了包里，因为这么做可以尽可能多的覆盖更多的 Android 手机，总所周知，Android 的碎片化实在是太过于严重了。所以，我们只需要在 Android的 App 目录的 build.gradle中配置所需要的架构就 ok 了。
再次打包，你就会发现，才 40M 了，直接缩小了一半。
一些感想
得益于我们的一套成熟的工作流，现在非特殊需求的后端，我们基本上能够全部交给 AI 实现，人工干预非常少，已经是美滋滋，这个还得是大师小黄，前端部分因为现阶段成熟的工具。我们也并不需要过多的人工编码，几乎都是先架构，在模块化的套路。
所以，现在我问你，一天开发一个功能不是很特殊的 App，你觉得可行吗？
