ARTICLE · 1293987
从编程0基础到上架 App,Vibe Coding里我踩过的那些坑.
从编程0基础到上架 App,Vibe Coding里我踩过的那些坑.我是编程 0 基础。年初用 AI 做了一个 App，现在已经上架了。 开始之前我想：自己好歹会做界面设计，这总该是个优势吧。 后来才发现，UI 可能是整个开发里最简单的一步。 真正让我头疼的是——我根本不知道，还有哪些问题是我需要问的。 你好，我是 Yoko。这一期想聊聊 AI 编程，也就是这两年很热门的 Vibe Coding。 这不是编程教程。只是想拿自己开发并上架的「独木成林」当例子，讲讲一个新手小白借助 AI 从零做出产品，大概要经历哪些流程、又会遇到哪些坑。 先简单介绍一下「独木成林」。 
它每天给你三四张图文卡片，主题涵盖美术、音乐、文学、电影、历史、天文、自然科学这些。收到过的卡片都在历史仓库里，喜欢的可以收藏。它没有信息流，不会一直推下一条——每天看完这几张，就没有了。 做这个的初心很简单：我兴趣很杂，什么都想了解一点；可兴趣一多，反而很难每天主动去找、去读。 所以我想要一个 App，每天帮我挑几条——一幅画、一首诗、一段历史，或者一个我从没听说过的自然现象。花几分钟看完，继续过日子。不用无限刷，但日复一日，自己的世界好像又扩展了一点。 这就是做产品的第一步：立项。也是我踩的第一个坑。 规范的流程里，你得先想清楚：目标用户是谁，有没有类似的产品，先做 iOS、安卓还是 Web，内容和数据从哪来，怎么盈利，你的产品有什么不可替代的地方；甚至再早一点，还有技术方案和开发成本。 
但这些我当时几乎都没想。只觉得我想要这样一个应用，那就做出来。 后来才发现，很多决定是连在一起的：在哪些地区上架，会影响云服务和合规方案；怎么收费，会影响账户体系和订阅设计。我没提前想，结果内容结构、订阅方式、平台选择都反反复复返工。 现在我才意识到：做个人项目，不一定要先写几十页的商业计划书，但会影响整个方向的问题，最好提前想一遍。不然后面要改的，可能不是几个按钮，而是整个系统。 接下来终于动手了。俗话说万事开头难，这一步我真的反反复复卡了一个多月。 最开始我只是一直和 AI 聊卡片设计：页面长什么样，图片怎么展示，卡片怎么翻，点进去出现什么。AI 一边听一边写代码，写着写着，UI 都差不多了，示例卡片也能翻了。 我一度觉得，进度还挺快的嘛。 
直到有一天突然想到：用户下载 App 的时候，难道要把这么多图片和文字都下到手机里？以后每天更新内容怎么办？每个用户每天收到的卡片不一样，又该怎么实现？ 这时候我才意识到：我一直让 AI 帮我做页面，却没搞清楚内容从哪来、怎么处理、存在哪，又怎么到用户手机上。所以只能重新梳理架构。 打个通俗点的比方：开发 App 有点像开餐厅。 前期，你需要备菜——买菜、洗菜、切菜、腌制，准备各种食材。 中期，你需要烹饪——炒、煮、炖、蒸，控制火候，兼顾调味。 最后才是上菜——餐具、摆盘、上菜顺序，以及客人吃饭时的体验。 客人是来吃这盘菜的。他不需要知道你在哪里买的菜、怎么洗的菜，更不需要自己跑进厨房炒菜。 
但我当时做的东西，就好像在锅里洗菜、切菜、炒菜，最后甚至打算把锅一起端上桌。 于是我开始大规模调整，重新梳理内容制作、云端存储和用户交互的关系，也重新组织代码。这又折腾了我快两个月。 最终我把项目拆成三个主要的代码仓库：备菜是工具端，烹饪是后端，上菜是前端。当然这只是我的管理方式。 简单点的项目一个仓库就够，复杂的产品可能要更多独立服务。重要的不是仓库数量，而是搞清楚每部分负责什么。 「独木成林」是以内容为核心的产品，所以备菜是整个开发里很繁琐的一部分。 我专门做了一个工具端，批量收集、生成、整理和处理卡片内容。它运行在电脑上，有自己的界面，每个功能背后都是一套处理逻辑。 
先说图片。根据卡片主题不同，我需要艺术画作、天文照片、自然摄影、AI 生成图，渠道各不相同。我得研究博物馆、NASA 这些机构的公开资源，找合适的图片接口，或者用 AI 生成素材。有的接口限制访问频率，有的下载很慢，有的分辨率不够。 还有一个很容易忽略的问题：公开能看到的图片，不代表就能随便用在自己的产品里。每张图的版权和使用许可可能完全不同——能不能用在 App 里、要不要署名、有没有别的限制，都得判断。图片定下来，还要筛选、压缩、统一规格。 而文字比图片还麻烦。卡片选什么主题，一张卡片写多长，版权怎么处理？用 AI 写文案，怎么避免它一本正经地胡说八道？历史和科学内容，又怎么核对事实？ 我希望卡片不只好看，还尽量真实、准确，有一点阅读价值。再加上简中、繁中、英文三个版本，写完还得翻译、校对，让三种语言意思一致。 光图文这两步就已经很复杂了，最后还要图文匹配。假设今天选了一首关于孤独的诗，AI 给它配了一张色彩明艳、特别热闹的图——单看都不错，放一起就很违和。所以不同类型的卡片，我又要设计不同的匹配规则。 
正因为前期没梳理好思路和流程，工具端一直在改：做着做着，少了个筛选环节；再做着做着，生成规则不够完善；终于能批量生成了，又发现语言和图片对不上。真把我愁得焦头烂额。 一款产品看起来越简单，背后有时越需要一套复杂的系统，替用户把麻烦事做完。 当我终于准备好了很多符合要求的卡片，就像菜备好了，接下来是烹饪：后端。 后端很多问题是通用的：数据存哪，怎么注册登录，收藏怎么保存，权限怎么控制，怎么防数据泄露和接口滥用。 拿「独木成林」来说，工具端做好的图片和文案，得放在 App 能访问的地方，不然 App 都不知道去哪拿今天的内容。这就要用到云端存储和数据库。 我选的是 Cloudflare R2 和 Supabase：图片主要存在 R2，卡片信息和用户数据由 Supabase 等服务管理。一个重要原因是它们对新手比较友好，很多基础能力有现成的一条龙服务和文档，不用自己从零搭。 
环境变量、数据库权限、邮件验证这些，我一开始都不懂，基本是遇到一个问一个。AI 对这些常见服务也熟，所以那些让我不明觉厉的专业概念虽多，推进起来反而比我想的顺利。 不过，用成熟的云服务，不等于安全就自动解决了。平台给的是工具；怎么配置权限、哪些数据谁能访问，还得自己负责。 最容易出问题的是边缘情况：同一个账号两台设备登录，数据能不能正确同步？一台手机先后登两个账号，会不会把前一个人的数据给后一个人看？频繁改密码、多设备同时操作，又该怎么处理？ 这些细枝末节，有些实现起来不算难，难的是你得先想到它们会发生——尤其是没有编程经验的时候。AI 也许很快就能做出登录功能，但不代表它足够安全、异常情况都处理好了。 我在这儿还碰到一个影响方向的坑：服务器和目标市场。 虽然这些海外服务在中国大陆也可能访问，但稳定性、速度和实际部署的合规要求都得另外考虑。如果认真做大陆版，就得调整整套服务方案。我当时试着迁移到阿里云，服务覆盖面也很广，但对我这样的新手来说，上手有点吃力。 
所以综合技术、合规和维护成本，最终我暂时搁置了开发到一半的大陆版。现在「独木成林」的 iOS 原生 App，只在包括港澳台在内、中国大陆以外的大约 13 个 App Store 地区上架。 这个决定，其实又绕回了立项。至于为什么暂时放弃大陆、为什么没做安卓原生版，展开讲又很长——以后有机会再单独聊。 终于到了上菜。前端就是用户看得见、摸得着的部分：界面好不好看，按钮好不好用，卡片滑得顺不顺，每次点击有没有正确反馈。 UI 是我最熟悉、最容易上手的部分。但我很快发现：好看的界面，和能长期稳定运行的交互系统，完全是两回事。 比如我自己很喜欢的桌面小组件：不用打开 App，在手机桌面上就能看到最新的卡片。听起来很简单，做起来又是一堆坑。 App 里已经是今天的卡片，小组件还停在昨天；每次都联网下载图片，会不会太费流量；提前缓存的话，留几天、什么时候清；用户很多天没打开 App，小组件还显示得对不对？而且 iOS 小组件不是你想几点刷新，系统就一定几点执行。这又牵涉到系统调度、缓存管理、时区计算和图片存储等各种问题。 
还有另一个大坑：收费。 如果你的产品完全免费，能省很多事；可一旦涉及免费试用、付费、内购或自动续订，那就是另一套系统了。 「独木成林」有免费试用期，之后按年订阅；不订阅也能用，只是卡片每天只有一张。各种规则叠在一起，付费系统已经相对复杂，真的折磨了我很久。 例如，iOS 要在苹果的沙盒环境里测购买和订阅：第一次订阅能不能解锁会员？到期了怎么办？取消自动续订后，剩下的会员时间算不算？换了手机怎么恢复购买？退款后会员状态怎么更新？ 还有测试和真实环境的数据、状态要分开管，不能让测试影响正式用户。如果 App 需要登录，提交审核时可能还得给审核人员准备能用的演示账号或测试说明。 我原本以为，付费无非就是加个按钮：点一下，跳出付款页面，付完结束。后来才发现，付款只是其中一步；真正麻烦的是付款前后的各种情况，你准备怎么处理。 等功能都能正常跑了，我以为总算能松口气。没想到，上架又折腾了我大半个月。 
我只做了 iOS 原生版，面对的是苹果审核。比起从零搭分发渠道，它的规则算比较清晰了——但清晰不代表第一次就能顺利走完。 App Store Connect 里要准备应用介绍、各种尺寸的截图、隐私政策、年龄分级、审核信息；有订阅的话，还要配置商品信息、价格和说明。每项都有细节要求。 举个我踩过的坑。创建应用时我主语言填的是简体中文，当时没认真想过以后主要面向哪里。后来决定暂时不上大陆、把香港作为重要的首发市场，才发现这件事不像我以为的那样随时点一下就能改。 当时我没能直接改过来，只好先用简体中文提交，通过后再补繁体中文资料。不算大问题，但又花了些时间。类似的细节坑还有很多。 想到如果做安卓原生版，可能还要应对不同应用市场的分发和审核要求，我就暂时没继续，而是做了一个 Web 版。 安卓用户可以用浏览器打开，也能添加到桌面；它和 iOS 用同一套账户和数据，内容和收藏都能同步。虽然没有桌面小组件，但大部分核心功能都能用。 
我真的太喜欢开发 Web 版了——没有那么多审核上架和繁杂的资料。不过 Web 版也有短板，比如收费：iOS 可以用苹果的应用内购买；Web 要做自己的订阅和支付，就得考虑支付接入、订阅管理和不同地区的合规要求，复杂程度很看你选的支付平台和服务的市场。这些我还没完全解决，这期先不展开。 从立项到上架，这就是我用 AI 开发「独木成林」的大致流程。 当然，实际开发不是流水线，做完一环就不回头。更多时候是在几部分之间来回改：前端发现问题，回去调后端；后端数据结构一改，工具端又得跟着改。有时候加一个不起眼的小功能，就牵动整个系统。 回头看，AI 编程确实改变了很多。 以前想做这样一款 App，可能得先花很长时间学编程语言、研究技术框架，或者找专业程序员。现在我可以先有个想法，边做边向 AI 学——不需要先掌握所有技术，才有资格开始。 但 AI 也没法替我做完所有事。它能告诉我一个功能怎么实现；可如果我连需要什么功能、会出什么问题都没意识到，它就未必能替我想周全。 这就是我这次最大的感受： AI 降低了写代码的门槛，但没有消除做产品需要的判断力。 
你仍然需要决定自己想做什么，需要理解用户真正需要什么。需要做选择、承担取舍，也需要为产品的安全性、稳定性和最终体验负责。 本期分享的只是整个开发流程的大致轮廓。很多具体问题和方法没办法逐一讲解，毕竟这不是一期手把手的编程教程。而且不同产品面对的问题也不一样；甚至我遇到的问题，可能过不久你就不会遇到了——因为模型能力一直在增强。 随着 AI 不断增强，流程可能会越来越简单，门槛也可能会越来越低。 如果你有任何想问的，或者你也正在用 AI 做自己的产品，欢迎在评论区和我交流。 我是 Yoko。 脑子里总是长出一些奇怪的问题，然后试着去找很多种答案。 欢迎点赞关注，我们下一期再见。
一、立项：我想要一个什么样的产品？
二、架构：我把后厨搬上了餐桌
三、工具端：原来备菜比我想的麻烦得多
四、后端：大厨是否专业，决定了产品能不能正常运行
五、前端：看起来终于做完了，没想到还有这么多细节
六、上架：以为终于到终点了，结果又是一场考试
七、AI 编程，究竟降低了什么门槛？
