Vibe Coding实战：从零到上架App Store的完整工作流

2024年底我决定把躺在我备忘录里一年多的想法做成一个真正的应用。过去我试过好几次每次都是打开Xcode、新建工程、写几个页面之后就搁置了原因出奇一致白天上班已经写了大量代码回到家实在没有精力再为一个“小玩具”熬到凌晨。这次我换了一条路——全程用 Vibe Coding 的方式来做结果让我自己都意外一个叫 Tiqlo 的应用从零开始到最后通过 App Store 审核上架我只写了极少量的手写代码大部分时间花在“想清楚需求”和“指导 AI 干活”上。这篇文章想把整套工作流完完整整拆给大家包括全局 MD 文档怎么组织、AI 工具之间怎么配合、上架前后哪些坑你绝对绕不开。如果你也是独立开发者、产品经理或者手里有几个“早就想做但一直没动手”的点子这篇文章应该能帮你省下大量试错时间。我先说一下本文适合什么人有一定编程基础、但不想在每一个技术细节上亲力亲为的人或者完全不写代码、但愿意花时间把逻辑讲清楚的产品型选手。两种身份我都见过成功案例核心差别不在代码能力而在“把需求讲明白”的能力。1. 我的第一次 Vibe Coding 尝试为什么会选这条路1.1 传统开发流程对我的慢性消耗之前我做过两个半成品应用每个都死在同一个地方功能还没做全热情先被重复劳动耗光了。做登录注册页面、搭导航框架、写列表页和详情页这些工作对我来说毫无新鲜感但又绕不开。到了 2024 年年中AI 编程工具的实用性已经到了一个临界点——它们不再是只能生成十来行示例代码的玩具而是能够理解整个项目结构的“结对程序员”。我开始认真考虑能不能把我不想干的活儿全交给 AI我只负责定义“做出来是什么样”。Tiqlo 这个想法其实很简单核心是一个“轻量任务时间盒管理工具”给每个任务设定一个时间盒到点自动提醒并记录实际消耗时长用历史数据帮你估算同类任务下次要留多少时间。市面上的时间管理应用要么太重项目管理那一套要么太轻就是番茄钟Tiqlo 我想做成中间形态——不需要建复杂的项目结构扫码一样快速开始但又能积累个人时间数据。1.2 Vibe Coding 到底是什么以及它适合解决哪类问题Vibe Coding 这个词第一次出现的时候很多人理解成“聊聊天就能让 AI 把应用写出来”我觉得这个描述害了不少人。它确实让人用自然语言就能控制 AI 生成代码但核心不是“ChatGPT 自动生成一整个应用”而是人用「文档 对话 明确验收标准」驱动 AI 持续产出可运行的代码增量。拿我搭 Tiqlo 的经历来说这个方式最擅长解决三类问题重复性强的模板代码导航结构、列表页、表单页、设置页AI 生成的质量非常高。需要来回调整的机械改动改按钮样式、调整内边距、统一颜色变量以前要全局搜索替换现在跟 AI 说一句就行。跨语言、跨框架的“翻译”我脑子里想的是 SwiftUI 的写法但 AI 能直接帮我查出来最新 API 或者生成对应的 Core Data 迁移代码。不适合的场景我也要给各位泼盆冷水如果你的应用核心是一个从未有人做过的复杂算法或者涉及底层性能优化极限Vibe Coding 目前很难给你惊喜。它擅长的是把你已经想清楚的东西高效落地而不是替你想出你自己都说不清楚的东西。1.3 定下目标和边界Vibe Coding 不等于什么都交给 AI我给自己定了三条边界这三条在后来救了我很多次产品逻辑边界我不放手用户可以做什么、不能做什么、流程怎么走必须由我来定。数据模型我亲自审数据库的表结构、字段类型、本地持久化方案AI 的初稿我可以接受但最终合并进项目前必须过一遍。上架资料我全程把关隐私政策、权限说明、审核材料这些AI 生成的只是初稿核对责任在我。这个边界设定很关键因为它决定了你什么时候信任 AI 的输出、什么时候必须人工介入。我见过不少翻车案例无一例外都是把这三条里的某一条完全交给了 AI。2. 全局 MD 文档整套工作流真正的中枢神经2.1 一个文档胜过一百次重复解释Vibe Coding 工作流最大的痛点不是 AI 写不出代码而是 AI 经常“忘记”项目的整体设计——你让它改某个页面的布局它可能在别的地方引入了跟原有风格完全不一致的组件。我在做第二个原型的时候吃了这个亏AI 生成了一个新的按钮样式结果跟整个应用的主题间距系统完全不搭改样式花了整整一下午。后来我研究了很多人的做法发现大家都在不约而同地做同一件事维护一份“全局 MD 文档”让 AI 在每次动手前先读一遍。这个文档不是一个简单的 README而是整个项目的「宪法」。我帮大家拆解一下我的 Tiqlo 文档里到底写了什么。2.2 我的 Tiqlo 全局 MD 文档目录结构这份文档我放在项目根目录下命名为GLOBAL_PROMPT.md全局提示文档每次跟 AI 对话前我会明确告诉它“先读 GLOBAL_PROMPT.md 再动手”。文档区块核心内容为什么必须写产品定位Tiqlo 是什么、给谁用、解决什么问题让 AI 永远知道自己在做的东西服务什么场景不至于偏航目标平台与版本iOS 17、SwiftUI、最低支持的 iPhone 型号避免 AI 用了不兼容的 API设计规范间距系统、色板、字体层级、圆角半径保证所有 AI 生成的 UI 风格统一数据模型实体定义、字段、关系、迁移策略防止多个页面生成了不同版本的同一个模型页面清单每个页面的 URL/路由、用途、跳转关系让 AI 知道完整的导航结构通用规则错误提示风格、加载态处理、空态设计统一交互细节避免一处有骨架屏一处没有待办与决策记录每期要做什么、之前为什么这样决定记录 ADR架构决策记录防止 AI “反悔”重点说一下「待办与决策记录」这个区块我觉得是绝大部分人文档里最容易漏但最有用的一部分。AI 对话本身是上下文无关的你新建一个会话它什么都不记得。你可能会说“那我继续用同一个会话就好了”但实际项目做到后期一个会话的上下文会越来越长AI 的响应质量和速度都会下降。所以我每完成一个阶段就把结论和原因写进文档下次开新会话时让 AI 先读一遍这样它就像“前一天刚跟你开过会的人”一样清楚状态。2.3 文档驱动的一个典型操作循环我用一个具体例子来说明这玩意儿怎么落地。假设我要让 AI 做 Tiqlo 的“任务列表滑动删除”功能整个操作循环是我告诉 AI读一下GLOBAL_PROMPT.md的数据模型和页面清单部分。AI 回复已了解Tiqlo 的任务列表页位于 TasksView数据模型是 Task 实体。我提出具体需求给任务列表增加滑动删除删除前弹出确认框文案风格参考文档里的「错误与确认提示」规范。AI 生成并修改代码给出改动文件清单和摘要。我检查关键部分是否误删了其他逻辑、是否用了正确的持久化上下文。确认无误后我把这次改动的记录追加到文档的「决策记录」里。这六步循环我每天执行几十遍积累下来AI 的输出质量稳定得不像话。最明显的收益是每次只改一个页面的时候它不会突然“发挥创意”搞出新的结构来。2.4 文档迭代的节奏和技巧全局 MD 文档不是一蹴而就的我大约每完成一个功能迭代就花 15 分钟整理一次。重点更新两块一是数据模型有没有变化二是新增了哪些交互规范。如果你用的是 Cursor、Claude Code 这类可以直接指定上下文文件的工具把GLOBAL_PROMPT.md作为“系统提示词”挂载进去AI 每次回答前都会自动加载体验比人工说“先读文档”更顺滑。另外一个小技巧文档不要追求大而全。一开始只写最重要的几条规则比如“所有日期时间用相对时间描述”“深色模式下颜色对比度要达到 AA 级别”“列表页统一使用 .sheet 弹出新建界面”。规则超过 40 条之后 AI 的遵循度会下降这时候要做的是合并同类项、删掉那些“它已经天然会做对”的废话。3. 从 Idea 到 MVP我是如何把一个念头变成可点开的应用的3.1 需求拆解让 AI 帮你把大问题切成小任务块很多人拿到一个想法就直接跟 AI 说“帮我做一个时间管理 App”结果 AI 生成出来一个大而全但每个细节都粗糙的东西。我的做法是反过来的先自己把第一版范围砍到最小再让 AI 做补充和挑战。Tiqlo 第一版我就定死了三个核心能力创建任务时输入预计耗时应用自动生成时间盒。计时开始后全屏显示倒计时结束时通知。记录每一轮实际用时任务完成后写入历史库。用这三个功能去问 AI“这个范围还有什么坑”它的反馈极其有价值——比如提醒我后台运行计时器的模式比如 timer 和 background task 的区别、通知权限的申请时机、以及时间计算要处理 App 被杀死后的恢复问题。这些都不是我一开始能想到的但 AI 在这些领域积累了大量“知识”可以在几分钟内帮我把需求补全。3.2 从空工程到第一个可运行版本的工具链选择这一节是纯实操经验。我用过 Cursor、Claude Code、GitHub Copilot最后在 Tiqlo 项目上稳定下来的组合是环节我的选择原因主导 IDECursor对项目上下文的理解能力好全局 MD 文档挂载方便对话式主力Claude CodeCLI 模式适合多文件重构批量改动时效率极高代码补全Cursor 内置的 Tab 补全简单重复的代码可以直接让它“猜”架构审查我自己 AI 交叉复核避免 AI 自我合理化必须有一个人做最终裁判初始工程我让 Cursor 生成的是一个 SwiftUI 空壳应用包含 TabView 结构和三个占位页面。这一步耗时大约 20 分钟核心目的是把项目基础骨架、版本控制、构建配置都跑通之后再逐个页面填充功能。一个我踩过的坑千万别让 AI “顺手”帮你把项目配置全部搞定。它经常会把Info.plist里的权限描述写得很敷衍或者把deployment target偷偷改高导致审核或者真机调试出问题。配置文件你要自己打开看一遍哪怕你并不精通也要大致理解每个字段的作用。3.3 一个核心功能的完整实战任务时间盒的创建与启动拿“创建任务”这个功能来讲我完整的提示词大致是这样在 TasksView 中新增一个“新建任务”按钮点击后通过 .sheet 弹出创建表单。 表单字段任务名称必填、计划耗时必填以分钟为单位、备注选填。 保存后调用 TaskStore.addTask(...) 写入内存和 SwiftData并立即刷新列表。 UI 风格和间距系统请参考 GLOBAL_PROMPT.md 中的设计规范。AI 返回的代码质量很高但并不是一次过。它生成的表单里计划耗时的输入框用的是TextField这就需要我手动指出这里应该用Picker或者自定义滚轮来限定分钟范围避免用户输入 -5 这种非法值。这个修改如果从零开始写大概要 10 分钟AI 改起来 1 分钟就够了。但是请注意这种能力不在 AI而在我——我明确知道“这里不应该允许自由输入”这个产品决策。3.4 第一个 MVP 上线自测哪些细节是 AI 永远做不好的第一版跑通之后我在真机上试了两天发现了几类 AI 很难自动处理的问题真实设备上的触感反馈强度AI 生成的震动反馈代码理论没问题但真机上感觉偏弱/偏强只有人手能感知。键盘弹起时的页面避让AI 用的默认设置在小屏设备上经常出现输入框被遮挡的情况需要反复调scrollDismissesKeyboard和safeAreaInset。空态和错误态文案AI 默认生成的“暂无数据”干巴巴的换成“你今天还没有时间盒记录试着给第一个任务添加计时吧”需要产品判断。所以我的结论是技术代码部分你可以大胆让 AI 写但在体验细节上一定要自己动手去摸、去感受这部分偷懒等于把产品质感扔掉了。4. 数据模型、状态管理与设计规范的持续磨合4.1 数据模型初审为什么它是 Vibe Coding 项目的“承重墙”在 Tiqlo 项目里我花时间最多的地方不是 UI 代码而是数据模型的评审。原因很简单UI 代码改起来成本低但数据模型一旦定错后面所有页面和逻辑都要跟着返工。SwiftData 里我定义了三个模型TaskRecord任务记录、TimeBoxSession时间盒会话、Tag标签。AI 初稿生成的TimeBoxSession里没有存“预定结束时间”只存了“开始时间”和“计划耗时时长”。从纯计算角度看这没错但产品上我需要看“当时这个盒子预定几点结束”而倒计时结束时可能已经前后偏移了几分钟。这个字段缺失导致统计页面没法画“计划 vs 实际”的对比时间轴。这就是数据模型评审的价值我不会直接要求 AI “加一个字段”而是把“我要看什么数据、画什么图”描述给 AI让它自己拆解出需要哪些字段。经过这次修改我意识到一个规律——AI 倾向于设计“最小够用”的数据结构但产品演进通常需要“稍微冗余”一些的字段。你要么一开始多预留字段要么深刻理解自己的报表需求后再定模型。4.2 状态管理AI 生成代码最容易埋雷的区域SwiftUI 的状态管理方式很多State、Binding、ObservableObject、EnvironmentAI 在生成页面代码时经常混用。Tiqlo 项目我统一采用了最新的Observable宏方案配合一个全局AppStore来管理跨页面共享数据。但 AI 经常犯一个错在某个视图中直接创建State的 store 实例而不是从环境里取共享实例。结果就是页面 A 改了数据页面 B 根本感知不到。这个 bug 排查起来极其隐蔽因为单页面调试完全正常一旦跨页面联动就“幽灵”一样地丢数据。我的解决方法是把这条规则写进全局 MD 文档数据获取统一从Environment(AppStore.self)读取禁止在视图内部State创建 store 实例。写进去之后AI 再生成的代码几乎不会再犯这个错。这件事给我的启发是Vibe Coding 的很多“坑”其实是“规则不明确”的坑。你花时间把项目约束写清楚单位时间的生产力会大幅提升。4.3 设计规范的颗粒度细到什么程度才算够第一次让 AI 改界面时我给的规范是“按钮风格圆润一点”结果它给我生成了一整套AppleWatch风格的圆角按钮跟应用的标签风格完全不搭。后来我把规范改成了这样- 主按钮背景色 Color.accentColor文字颜色 .white字体 .headline圆角 14pt内部水平间距 16pt垂直间距 10pt。 - 次按钮背景透明边框 1pt 灰色Color(.systemGray4)其余与主按钮一致。 - 禁用状态背景色 Color(.systemGray5)文字颜色 Color(.systemGray2)。当规范精确到这个程度AI 几乎不会自由发挥。但也要注意不要把过于琐碎的决定写进文档比如“按钮阴影偏移 0,2,3,0”这种AI 有能力自己处理。规范的核心是「视觉一致性的边界」不是「每个像素的指定」。4.4 遇到“AI 和你对着干”怎么办决策记录的力量项目开发到第四周时我遇到一次让人崩溃的“AI 反复无常”。当时我让 AI 重构统计页面的数据组装逻辑它给出了一个“看起来更简洁”的方案并且很自信地改了核心方法。结果我在 UI 层发现图表数据对不上找了一晚上最后发现它悄悄改了数据的排序逻辑——而我之前明明在文档里写过“时间轴序列按开始时间升序排列”。这就是为什么我坚持在全局 MD 文档里写决策记录。我打开记录找到当时写下的原因“为什么按升序因为用户阅读时间轴的习惯是从早到晚倒序会违反直觉。”我把这段话原样贴给 AI它立刻道歉并重新生成了符合要求的代码。这件事后我想了一套应对固定流程当 AI 提出一个与现有设计不同的方案不要直接接受先问它“你觉得为什么现在的设计不够好”。如果它有合理理由更新文档、再实施如果没有就明确告诉它“维持现有设计”。所有变更必须在决策记录里留痕。这套流程拯救了我不计其数的“返工时间”强烈推荐。5. 从“能跑”到“上架”App Store 审核绕不开的硬仗5.1 上架前的准备证书、权限描述与应用图标Vibe Coding 能帮你写代码但开发者账号、证书、描述文件这些账号体系的事情它帮不了太多除非用fastlane自动化但前期我建议还是手动过一次流程。Tiqlo 用到的权限主要是通知本地通知和可选的照片访问用来给任务添加图片备注。这里我要重点提示一个审核高频被拒点权限用途描述。很多人生成应用后容易随便写一句“用于提醒”但苹果审核会仔细读文案如果和你实际使用的功能对不上大概率被拒。我的描述是通知“用于在时间盒结束时向您发送提醒并显示任务名称。”照片仅在 iOS 系统相册权限弹窗时出现文案写“用于为任务选择参考图片可选”。另外应用图标和截图是很多开发者忽略的硬指标。Tiqlo 的图标我是在 Figma 里画了一个简单的时间盒图形导出 1024px 大小的 PNG然后配置到 Xcode 的Assets.xcassets里。截图是用xcrun simctl io booted screenshot命令从模拟器截取的每种尺寸截了 3 张再用预览 App 简单排了一下版没有用任何第三方工具。5.2 审核被拒记录两个真实拒因和我的解决过程Tiqlo 第一次提审被拒拒因是2.1 Performance: App Completeness。苹果认为应用中有一个“退出”按钮引导用户回到登录页但实际上 Tiqlo 是纯本地应用不需要登录。这个按钮是我早期原型里留下的残留一直没删。被拒之后我在全局 MD 文档里加了一条规则“应用不包含登录/注册流程也不得包含退出登录入口。”AI 后续帮我清理了相关代码和资源第二次提交顺利通过。第二次被拒是审核员认为应用“缺少恢复购买机制”这个让我觉得有点奇怪因为 Tiqlo 没有内购项目。后来看了邮件发现是一个占位用的“高级版”页面还留在 app 里——是我早期为了测试 StoreKit 配置加的后来忘记删了。审核员看到它就会认为你有未实现的购买功能。我删掉页面并清理了 StoreKit 配置文件并在提交审核的备注里解释了 Tiqlo 是一个一次性付费/完全免费应用没有订阅也没有内购。这次解释之后顺利通过。5.3 审核元数据与 App Store Connect 的填写经验App Store Connect 里有一堆字段需要填最容易让开发者头疼的是“隐私政策网址”和“审核备注”两个。隐私政策 Tiqlo 是纯本地应用但苹果依然要求有隐私政策。我没有买域名而是用 Notion 公开页面生成了一份简单的说明内容包括收集哪些数据基本上只有本地存储的任务记录、是否分享给第三方否、用户如何删除数据删除应用即删除所有本地数据。审核备注是很多独立开发者忽略的沟通窗口。我的写法是这样这是一个本地优先的任务时间管理应用。 所有数据仅保存在用户设备本地不收集任何个人数据。 无账号系统、无内购、无广告。 首次启动会申请本地通知权限用于任务结束提醒。备注里把应用的核心逻辑、权限用途、以及“为什么没有账号/内购”都讲清楚审核员的判断成本就大大降低过审概率自然提高。5.4 上架后的第一周崩溃日志、用户反馈与持续迭代App Store 上架不是终点。Tiqlo 上线第一周我收到了几条用户反馈主要集中在两个方面一是部分用户希望时间盒可以暂停二是倒计时结束后声音不够明显。我在GLOBAL_PROMPT.md的「待办」区域加了这两条每周用 Vibe Coding 工作流迭代一次让 AI 生成新版本的功能代码我负责测试、写版本说明、提审。有意思的是用户的反馈反过来帮助我优化了全局 MD 文档。比如“希望可以暂停”这件事我原本的产品定义里没这个设计但用户行为告诉我“时间盒这个功能在实际生活中会遇到被打断的场景”。我把这个决策写进文档TimeBoxSession 新增 paused 状态恢复后结束时间顺延。AI 执行起来毫无障碍因为文档规则它都读过。6. 这套工作流的真实收获与几个让我“真香”的细节运行了接近三个月我对 Vibe Coding 工作流的看法比最初冷静了不少。它不会帮你从零创造一个“改变世界的 idea”但它能把你脑子里已经成型的“小产品”以比你预期快 3 到 5 倍的速度拿到真实用户面前验证。Tiqlo 这个项目让我重新体验到了做产品的乐趣大部分时间花在想清楚产品逻辑、看用户反馈、打磨体验上而不是消耗在机械的样板代码里。几个让我“真香”的细节最后分享给大家AI 生成的单元测试直接可用Tiqlo 的数据计算逻辑时间盒时长、顺延、历史统计我让 AI 写了将近 40 个单元测试它生成的边界用例覆盖比我手写的还全。AI 是极好的“技术顾问”遇到 SwiftUI 新 API 不确定时我先问 AI 能不能用再对比官方文档。比自己在搜索引擎大海捞针快太多。但 AI 遇到“未知”会一本正经地胡编我在集成某个系统框架时它给我编了一个不存在的 API 名称。解决方法是编译报错 查官方文档双重校验不要盲信。如果你也想像我一样把脑子里某个想法变成 App Store 里的真实应用我建议你从今天开始做一件事把你手头项目的产品定义、数据模型、设计规范写成一个 MD 文档然后用一个 AI 编程工具让 AI 给你生成第一个可运行的页面。别想着一上来就全自动先解决“一个页面跑通”的小闭环再逐步扩展到整条链路。这套工作流的魔力不在某个工具多智能而在于你一次次和 AI 配合后建立起来的那套“让它懂你”的方法论——它才是把 Idea 变成 App Store 产品最核心的引擎。