不写一行代码：用AI编程开发安卓iOS双端闪卡APP全流程

一个17分钟视频，为什么值得花48小时去做

B站UP主「程序员小程」发布了一期时长17分钟、制作耗时48小时的实战教程，完整演示了如何通过AI编程（Vibe Coding）从零开发一款闪卡应用。这款APP包含首页闪卡列表、卡片详情、全息3D翻转、制作闪卡、个人卡册管理等模块，覆盖安卓和iOS双端以及后台管理系统。

与其他AI编程教程最大的不同在于：这期视频不是做一个玩具Demo，而是按照真实产品开发的标准流程走了一遍——从设计图出发，经过前端静态开发、后端接口实现、前后端联调、双端真机验证，到后台管理系统配置，每个环节都有明确的验收标准。

UP主在视频中提出了一个核心判断标准：浏览器跑通不算完，必须上安卓真机、上苹果真机，后台改了推荐后刷新前端能看到，这才叫真正跑通。

Vibe Coding（氛围编程）是2025年初由AI研究者Andrej Karpathy提出的概念，指开发者用自然语言描述需求、由大语言模型生成代码的一种编程方式。它的核心特征是人不再逐行敲代码，而是扮演「需求描述者」和「结果验收者」的角色，通过多轮对话迭代来逼近目标产品。这种模式下，代码质量高度依赖提示词的精确度以及开发者对结果的判断力，因此「分对话管理上下文」「用具体描述指出问题」等技巧成为关键工程经验。

为什么从设计图开始，而不是参考截图

前几期教程的起点通常是参考某个小程序的截图，直接让AI照着做。这一期换了路径：先出设计图，再把设计图和开发规范一起交给AI工具。

这个改变看似微小，实际影响很大。从截图出发，AI只能模仿已有产品的视觉结果；从设计图出发，更接近真实产品开发中「先有设计再有代码」的流程。UP主建议多生成几版设计图，从中挑选满意的效果作为开发参考，这样在后续对话中，AI对目标效果的理解会更准确。

闪卡应用被选为实战项目的原因也很务实——它功能闭环完整但体量适中，包含图片上传、卡片生成、翻转交互、收藏管理、后台推荐等模块，做完一个项目就能对完整产品需要哪些模块建立清晰认知。

工具链设计：前端、后端、后台分对话处理

这期教程在工具链上有一个值得注意的决策：前端继续用UniApp，后端复用已有项目，前后端放在不同的AI对话中处理，管理后台单独生成。

分开处理的原因很直接——避免上下文互相干扰。如果前端和后端代码放在同一个对话里，AI在处理页面样式时可能会被接口逻辑带偏，反之亦然。UP主在视频中多次强调「分对话管理各自上下文」，这是使用AI编程工具时保持代码质量的一个实用技巧。

另一个关键细节是敏感配置的处理。对象存储等密钥信息只在本地读取，不写死在代码里，也不提交到代码仓库。UP主透露后续准备公开代码，所以对配置安全格外注意。

上下文窗口（Context Window）是大语言模型单次对话中能同时「记住」的文本总量上限。当前端与后端代码放在同一个对话里时，两部分内容会共同占用这一窗口，模型在生成新代码时容易把页面样式逻辑和接口逻辑混淆，甚至遗忘早期约定。分对话处理的本质是把不同模块隔离到各自独立的上下文窗口中，降低信息串扰和「遗忘」概率，这与软件工程中模块解耦的思想一致。

前端开发：从静态页面到闪卡核心交互

前端开发的推进节奏很清晰：先让AI用项目已有的图鸟组件实现首页、卡片详情、制作页面和我的页面这四个主要静态页面，确保页面结构符合预期后，再引入开源的闪卡skill来处理卡片制作和翻转展示。

实际操作中遇到的问题很有代表性。第一轮生成的静态页面结构没问题，但卡片背面的图片比例不对——图片换了，显示适配却没跟上。UP主的处理方式是把参考图和程序实际效果放在一起对比，把问题用具体描述说清楚，而不是笼统地说「背面不对」。

真机检查时还发现了几个典型问题：制作页面顶部切换异常、我的页面布局问题、个人资料页出现两个返回按钮。这些细节在浏览器预览时不容易暴露，只有上了真机才能发现。

前后端联调：一个值得记住的Bug

后端接口开发同样分步骤推进：先让AI根据前端页面梳理需要哪些接口，确认清单后再开始实现。接口覆盖了首页分类、卡片详情、生成状态、风格配置、图片上传、用户资料、卡册和收藏信息。

联调阶段暴露了一个关键Bug：制作页面提交生成后，我的页面看不到对应的闪卡。UP主没有急于让AI修，而是先用实际操作复现问题，确认现象能稳定重现后才把问题描述清楚提交。

AI定位到的原因很具体：接口只创建了待处理任务，没有真正生成卡片记录，所以卡册查询不到。 补齐生成后的卡片记录后，重新走上传和生成流程，数据就正常了。

这个Bug的排查过程展示了AI编程中一个重要原则——「提交成功」和「结果可见」是两件事，必须分别验证，不能因为弹窗提示成功就跳过下一步检查。

双端真机验证与后台管理系统

浏览器联调通过后，UP主把应用部署到安卓真机和苹果真机分别验证。安卓端重点测试了图片上传、卡片生成、大图展示和卡册查询的完整链路；苹果端则验证了分类切换、搜索、卡片翻转、收藏、新卡制作等主要功能。

真机验证中发现了浏览器上看不到的问题：首页和我的页面背景偏黑，与设计图的暗色风格有差距。UP主的调整要求也很精确——保留暗色风格，但不要整片纯黑。

后台管理系统在一开始被AI理解错了形态，UP主需要再次强调「管理后台应该是独立的网站」，让工具把应用登录页与管理后台的页面和入口分开处理。后台的核心功能包括：查看用户制作的闪卡、将合适的卡片设置到首页展示、管理用户列表、配置首页轮播图。

联调最后一步验证的是双向数据流：在APP中制作一张卡片，打开后台刷新，确认数据出现在列表中；再把卡片设置到首页推荐，回到APP刷新首页，确认推荐内容出现。两端数据连通，整个开发流程才算闭环。

浏览器预览与真机运行存在本质差异：浏览器的渲染引擎、视口尺寸、网络请求策略都与移动端原生容器不同。在UniApp这类跨端框架中，同一份代码经编译后，在安卓和iOS上会调用不同的原生渲染层，因此字体度量、安全区域、图片解码、权限弹窗等表现可能不一致。真机验证正是为了捕获这类仅在原生环境下暴露的问题，这也是「浏览器跑通不算完」这一判断标准的技术依据。

从学技术到做产品，这一步跨出去意味着什么

UP主在总结时点出了这期教程与前八期的根本区别：前八期是在学技术，这一期是在做产品。 从设计到开发到验证，每一步都按真实产品开发的标准流程走。

对于想入门的开发者，视频最后留了一个作业：打开你的AI工具，从一张设计图开始做一个小产品，不用复杂，一个页面也行。

这期教程的价值不在于展示了AI多强大，而在于呈现了一个真实的AI编程工作流——会遇到Bug、需要复现问题、需要精确描述现象、需要分模块验证。AI编程降低的是编码门槛，但产品思维、问题定位能力和验收标准意识，仍然需要开发者自己建立。

验收标准（Acceptance Criteria）是敏捷开发中的核心概念，指一项功能被视为「完成」之前必须满足的可验证条件。在这期教程的语境中，它体现为一系列具体的检查点：接口提交成功后卡册必须能查询到记录、后台修改推荐后前端刷新必须能看到变化、双端真机都必须通过。把模糊的「做完了」转化为可逐条勾选的验收清单，是AI编程区别于随意生成Demo的关键，也是保证AI产出可用的有效手段。