我如何在 4 小时内用 AI 构建了一个 iOS MVP

网上到处都是"我用 AI 5 分钟就搭了个应用"的说法。作为一名软件工程师，我知道现实完全不是那回事。生成一段脚本很容易；架构一个可扩展、可维护、拥有出色用户体验的 iOS 应用才是真正的难题。

这个周末，我挑战自己，使用 Claude Code 在短短 4 小时内为一个名叫 ItemMaster 的库存管理应用构建了一个生产就绪的 MVP。

我并不是靠输入一个神奇的一次性提示词来实现的。我把 AI 不是当作资深开发者，而是当作一个需要严格、滴水不漏的工程和产品工作流的超快速初级开发者。

以下是我将一个想法在一个下午变成可运行 SwiftUI 应用的完整框架和提示词执行流水线。

第一阶段：前置准备（先别写代码）

使用 AI 最大的错误是在系统设计和产品逻辑锁定之前就让它写代码。我的第一个小时没有一行 Swift 代码。

竞品分析与 UI/UX 设计： 我没有凭空猜测用户需要什么。我下载并深入分析了市面上五款类似的库存管理应用。我无情地剖析了它们的引导页、功能集和 UI 交互。通过提取最佳概念、摒弃笨拙的机制（“取其精华，去其糟粕”），我设计了一套精简的功能集和高度直觉化的 UI/UX 流程。
“三位一体"的上下文： 在脑海中建立好思维模型后，我将原始需求输入 Claude Code，让它打磨和正式化三个基础文件。在这三个文件完美之前，不生成任何 UI 或逻辑代码：
- CLAUDE.md（设计文档）： 终极真理之源，规定项目结构、技术栈（SwiftData、Swift Charts）和严格规则（如"不使用第三方库”）。
- Models.swift： 完整的数据库 schema 和关系。
- Constants.swift： 默认枚举、分类和配置。

这三个文件成为后续每个提示词的常驻上下文。

基础打好后，我执行了一个高度纪律化的有序提示词策略。绝不要一次让 AI 构建整个功能。

以下是我的确切执行顺序：

搭建架构： “严格按照 CLAUDE.md 中的定义创建文件夹结构。为每个 view 和 view model 创建空的占位文件。”
构建基础 UI 骨架： “实现导航结构和 Tab 栏。确保空 view 之间能正确路由。”
分块的 CRUD 操作： 我将增删改查操作拆分开来。对于复杂数据类型，我甚至进一步拆分为多个提示词。例如：一个提示词严格只做’添加项目表单 UI’，另一个完全独立的提示词做’SwiftData 插入逻辑’。
逐模块添加功能： 只有在核心 CRUD 闭环完成后，我才开始提示特定功能，比如原生仪表盘图表或动态列表排序。

这是 AI 驱动开发工作流中最关键的部分。AI 会产生幻觉，如果你不小心，它会引入回归问题。我为每一个提示词都实施了严格的验证循环：

立即编译和调试： AI 为某个提示词生成代码后，我立刻在 Xcode 模拟器中运行。在继续下一步之前，我测试该特定功能的完整性和 bug。
“提示词历史"台账： 我维护了一个持续更新的 Prompt History.md 文件。我记录了每一个使用过的提示词。如果某个提示词产生了 bug，我不会手动修复；我会写一个专门的"Bug 修复提示词”，交给 AI，并在历史文件中记录这个修复提示词。这创建了整个项目的可复现轨迹。
原子化提交是必须的： 我在每一次成功的提示词和调试会话后都将代码提交到 Git。当 AI 最终走进死胡同并破坏了路由时，我没有浪费时间去解开它的烂摊子。我只需 git revert 到上一个稳定的提示词状态，然后调整我的指令。

这个工作流的价值在硬件测试中得到了验证。在模拟器上，一切正常。在真机 iPhone 上，点击"相机"按钮添加物品照片时应用立刻崩溃了。

因为我有原子化提交和模块化配置，我没有慌。我写了一个高度定向的 bug 修复提示词：

“检查 AddItemView 中的相机调用。在 Info.plist 中添加 NSCameraUsageDescription。添加 isSourceTypeAvailable 检查，并在用户拒绝相机权限时构建一个 alert 流程，引导用户跳转到系统设置。”

AI 生成了安全包装代码，我在设备上测试了它，验证了边界情况，然后提交了代码。

AI 不会取代软件工程或产品直觉——它放大了它们。如果你的流程是混乱的，AI 只会帮你以前所未有的速度写出意大利面条代码。

但如果你应用严格的系统设计——从竞品研究开始、锁定数据模型、执行有序的提示词流水线、保持严格的提示词台账、并强制执行原子化 Git 提交——你就能以一年前不可能的速度构建出健壮、生产就绪、拥有出色 UI/UX 的 MVP。