别等联调才看空状态：用 AI + Xcode Preview 提前验收 iOS 界面

开工前先问一个小问题：这个功能在「没数据」「接口慢」「用户搜不到结果」时，屏幕上到底长什么样？如果答案是「等联调再看」，今天这一技就派得上用场。

做法很简单：让 AI 先帮团队列出界面状态，再让开发用 Xcode Preview 把这些状态一屏屏摆出来。Xcode 的 coding intelligence 已经支持和 agent 或模型对话，用来生成代码、理解工程、修复或重构代码；苹果也在 Xcode 26.3 的技术分享里展示了 Codex、Claude Agent 这类 coding agents 可以通过 Xcode 工具构建项目、运行测试、搜索 Apple 文档。1 2

AI 辅助生成界面状态卡片示意 — AI 生成的界面状态示意图，用来表达「一个功能至少要看多种状态」，无外部原图。

它解决的不是「写界面更快」，而是「少漏边界状态」

PM 看原型时，最容易盯着理想路径：列表有内容、按钮能点、网络顺畅。上线后真正刺眼的，常常是另一批画面：新用户没有数据、搜索无结果、权限没开、接口失败、加载很久。

这些状态不是技术细节，而是产品体验的一部分。用户第一次进来看到空白页，会以为产品坏了；搜索无结果没有引导，会以为自己搜错了；错误态没有下一步，会直接退出。

SwiftUI 的 ContentUnavailableView 就是为这类「内容当前不可用」的界面准备的标准组件。Apple 对它的定义是：当 app 内容对用户不可用时，用来显示由标题、说明和其他内容组成的界面。3

操作法：先让 AI 列状态，再让 Preview 变成验收面板

你不需要让 PM 读代码。更合适的协作方式，是把 AI 当成「状态清单助理」。在需求评审后，直接让开发或设计把功能说明丢给 AI，要求它输出这张表：

状态	PM 要确认什么	开发要落到 Preview 里的样例
加载中	等待时是否有反馈	骨架屏或进度提示
空数据	新用户是否知道下一步	空状态标题、说明、行动按钮
搜索无结果	用户是否能换词或清空条件	无结果文案与重试入口
接口失败	用户是否知道不是自己操作错了	错误提示、重试按钮
正常内容	主路径是否符合预期	真实数量级的样例数据

接下来，开发把这些状态做成几个 #Preview。Apple 在 WWDC23 介绍过，#Preview macro 可在 Xcode 15 中快速迭代 SwiftUI、UIKit 或 AppKit 的 UI；Preview 还可以同时查看多个 UI 变体，比如深色模式、不同字号和不同设备方向。4

Xcode Previews 官方演示封面 — Apple 在 WWDC23 用这场 session 讲解 Xcode Previews 的快速迭代和多变体查看能力。4

到这里，Preview 就不只是开发自测工具了。它变成了一个轻量验收面板：PM 不需要等完整后端、不需要等测试环境稳定，也能先看见产品在边界条件下的样子。

给 PM 的一句提示词

把下面这段发给开发或直接发给编码助手：

请根据这个功能说明，列出 iOS 界面必须覆盖的 5 个产品状态：加载中、空数据、搜索无结果、接口失败、正常内容。每个状态给出用户看到的文案目标、推荐行动按钮、以及 SwiftUI Preview 需要准备的样例数据。不要先写完整业务代码，先输出状态清单和预览用样例。

这里的重点不是让 AI 一次写完功能，而是先把「可能被漏掉的屏幕」逼出来。AI 负责补全状态清单，Xcode Preview 负责把状态变成可看的界面。

产品价值：更早发现「体验债」

这个技巧最适合三类场景：新功能的首版 UI、依赖接口的列表页、强搜索或筛选的页面。它的价值不是省掉设计评审，而是把评审提前。

如果团队今天只做一个最小动作，就选一个正在开发的列表页，让开发补 4 个 Preview：加载中、空数据、搜索无结果、接口失败。PM 看完后只回答两个问题：用户知道发生了什么吗？用户知道下一步能做什么吗？

这两个问题过了，再谈视觉润色和交互细节。