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 项目上稳定下来的组合是：
| 环节 | 我的选择 | 原因 |
|---|---|---|
| 主导 IDE | Cursor | 对项目上下文的理解能力好，全局 MD 文档挂载方便 |
| 对话式主力 | Claude Code（CLI 模式） | 适合多文件重构，批量改动时效率极高 |
| 代码补全 | 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、@Environment），AI 在生成页面代码时经常混用。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 产品最核心的引擎。
