概览
使用 Codex 搭建 iOS SwiftUI 项目，通过 `xcodebuild` 或 Tuist 保持以 CLI 为先的构建循环，并在工作变得更深入时添加 XcodeBuildMCP 或针对性的 SwiftUI skills。
适合场景
- 适用于全新的 iOS SwiftUI 应用：你希望 Codex 从零开始搭建应用和构建循环
- 适用于现有的 iPhone 和 iPad 项目：在工作完成前，Codex 需要获取 schemes、模拟器输出、截图或进行 UI 自动化
- 适用于希望长期运行的 iOS UI 任务保持 agentic 和以 CLI 为先，而不是依赖 Xcode 图形界面的团队
搭建应用和构建循环
搭建一个入门 SwiftUI 应用，并添加一个构建和启动脚本，以便我能在本地环境中将其连接到 `Build` 操作。 约束： - 保持以 CLI 为先。优先使用 Apple 的 `xcodebuild`；如果更整洁的设置更有帮助，也可以使用 Tuist。 - 如果这个仓库已经包含完整的 Xcode 项目，请使用 XcodeBuildMCP 列出 targets，选择正确的 scheme，进行构建、启动，并在迭代时截取屏幕截图。 - 如果已有现成的模型、导航模式和共享工具，请复用它们。 - 除非我明确要求共享的 Apple 平台实现，否则让应用专注于 iPhone 和 iPad。 - 每次修改后先使用小而可靠的验证循环，只有在较小范围检查通过后，再扩展到更广泛的构建。 - 告诉我你是将其视为全新搭建，还是对现有项目的更改。 交付内容： - 应用脚手架或所请求的功能切片 - 一个包含精确命令的小型构建和启动脚本 - 你运行过的最小相关验证步骤 - 你使用的确切 scheme、模拟器和检查项
搭建应用和构建循环
对于全新项目，先从直接提示开始。让 Codex 搭建一个入门级 iOS SwiftUI 应用，并编写一个小型构建和启动脚本，你可以将它连接到本地环境中的 Build 操作。
保持以 CLI 为先的循环。Apple 的 xcodebuild 可以从终端列出 schemes，并处理 build、test、archive、build-for-testing 和 test-without-building 操作，这样 Codex 就能保持在 agentic 循环中，而不必来回切换到 Xcode 图形界面。
如果你希望使用更整洁的项目生成器，并且能接受第三方工具，Tuist 是一个很好的下一步。它可以在不依赖图形界面的情况下生成并构建 Xcode 项目，同时仍然让 Codex 能从终端构建和启动应用。
当你已经进入一个完整的 Xcode 项目并需要更深入的自动化时，请使用 XcodeBuildMCP。这时，schemes、targets、模拟器控制、截图、日志和 UI 交互的重要性已经高到，单纯的 shell 命令不再足以覆盖全部需求。
利用 skills
在第一轮尝试时，你通常不需要 skill 或 MCP 服务器。等工作变得更专业化，或者你希望在运行过程中内置更强的 SwiftUI 约定时，再添加 skills。
- SwiftUI expert 是一个通用能力很强的 SwiftUI skill，内置了大量最佳实践。
- SwiftUI Pro 是一个覆盖面广的 SwiftUI 审查 skill，适用于现代 API、可维护性、无障碍和性能。
- Liquid Glass expert 可帮助 Codex 采用新的 iOS 26 Liquid Glass API，并调整自定义组件，使其符合最新的系统设计。
- SwiftUI performance 适用于功能感觉运行缓慢，或 SwiftUI 视图更新路径看起来可疑的时候。它会扫描常见的 SwiftUI 错误，并生成一份按优先级排序的报告，说明应该修复什么以及最大收益在哪里。
- Swift concurrency expert 适用于晦涩的错误和编译器警告开始妨碍你想做的更改时。在 GPT-5.4 上，你可能不那么经常需要它，但当 Swift 并发诊断变得嘈杂时，它仍然很有用。
- SwiftUI view refactor 有助于让文件更小，并让整个仓库中的 SwiftUI 代码更加一致。
- SwiftUI patterns 有助于随着应用增长，采用可预测的
@Observable和@Environment架构模式。
要进一步了解如何安装和使用 skills，请参阅我们的skills 文档。
迭代
当你已经完成第一轮可用版本，或者你是从现有项目开始时，就可以开始迭代 UI 或行为。
在这一部分，请具体说明你想改什么，以及你希望如何修改。
把这一层提示明确说出来：告诉 Codex，它处理的是全新仓库还是现有的 Xcode 项目，哪些 iOS 设备或部署目标必须继续正常工作，以及你期望怎样的验证循环。
示例提示
例如，如果你想给现有应用添加一个功能，你可以这样请求 Codex 进行更改：
实用提示
从基础开始
对于全新项目，先从直接提示开始。让 Codex 搭建一个入门级 SwiftUI 应用，并编写一个小型构建和启动脚本，你可以将它连接到本地环境中的 Build 操作。在第一轮尝试中，你通常不需要任何 skill 或 MCP 服务器。
使用小而可靠的验证循环
每次修改后，告诉 Codex 运行那个能够真正证明你所触及契约的最小命令。之后再扩展到更广泛的构建。这样可以让 Codex 保持高效，而不会假装每次编辑都必须进行完整的应用构建。
保持以 CLI 为先的循环
保持以 CLI 为先的循环。Apple 的 xcodebuild 工具可以从终端列出 schemes，并运行 build、test、archive、build-for-testing 和 test-without-building 操作，这样 Codex 就能保持在 agentic 循环中，而不必来回切换到 Xcode 图形界面。
利用 XcodeBuildMCP
一旦你进入完整的 Xcode 项目并需要更深入的自动化，就使用 XcodeBuildMCP。这正是 schemes、targets、模拟器控制、截图、日志和 UI 交互的重要性高到单纯 shell 命令不再足以覆盖全部需求的时刻。