官方教程中文版实战场景
搭建 Mac 应用基础壳
基于 OpenAI 官方 Mac app shell use case，学习如何让 Codex 先搭出真正像桌面应用的 SwiftUI 外壳。
OpenAI 官方把这个场景定位为高级用例：用 Codex 和 Build macOS Apps plugin，把一个 app idea 变成 Mac-native SwiftUI app shell。新手真正要学的不是背 SwiftUI API，而是先让 Codex 搭对“桌面应用骨架”。
一个像 Mac app 的基础壳，通常先有这些部分：稳定的 sidebar selection、detail pane、inspector、menu commands、toolbar、keyboard shortcuts，以及独立的 Settings scene。
先理解它解决什么问题
很多新手会直接对 Codex 说“帮我做一个 Mac app”。这样容易得到一个被拉宽的网页界面，或者一个只有内容页、没有桌面行为的 SwiftUI demo。
更稳的做法是先让 Codex 搭 app shell：
WindowGroup负责主窗口。NavigationSplitView负责 sidebar 和 detail。inspector放次级信息和控制项。commands、toolbar、shortcuts 暴露关键动作。Settingsscene 放全局偏好设置。
先有这些，再继续做具体功能。顺序反过来，后面通常会补很多结构债。
什么时候值得用
适合：
- 你要做 editor、library、admin、review tool 这类桌面工具。
- 用户需要长期停留在一个 app 里处理对象、状态和细节。
- 你希望 app 有菜单栏、快捷键、设置窗口，而不是只有一个页面。
不适合：
- 只是想快速做一个单页 demo。
- 主要体验在移动端或 Web 端。
- 还没想清楚用户要管理什么对象。
- 只是想测试一个算法或 API。
第一次怎么让 Codex 做
不要一开始就让 Codex 实现完整业务。第一次只要求它交付“壳”，并把验收标准说清楚。
可以这样写：
请先不要实现完整业务功能。基于我的产品想法，先搭一个 Mac-native SwiftUI app shell：
- 主窗口使用 sidebar + detail + inspector。
- 全局设置放到独立 Settings scene。
- 关键动作通过 menu、toolbar、keyboard shortcut 暴露。
- 只做最小可运行壳，并说明如何 build/run 验证。这段提示词的重点是“先不要实现完整业务”。它能限制 Codex 的范围，让你先检查桌面结构是否正确。
让 Codex 做对的关键
你要描述的是产品对象，不是界面装饰。例如：
- 这个 app 管理什么对象。
- sidebar 里选中的是什么。
- detail 需要展示什么主信息。
- inspector 只放哪些次级信息。
- 哪些动作必须能从菜单栏或快捷键触发。
- 哪些偏好设置是全局的。
Codex 更擅长在明确边界内生成结构。你只说“做得像原生一点”，它会猜；你说清楚对象、状态和验收方式，它才有稳定目标。
新手常见坑
- 先做漂亮页面，后补 sidebar/detail/inspector，结果状态传递混乱。
- 把 Settings 做成主窗口里的一个页面，而不是独立设置窗口。
- 所有动作只放按钮，不接 menu 和 shortcuts。
- sidebar row 做成大卡片，扫视效率很差。
- 过早使用 AppKit bridge，把 SwiftUI 能表达的结构复杂化。
- 没让 Codex 跑 build/run check，只看代码像不像。
怎么判断这一步成功
成功标准不是“代码很多”，而是打开 app 后能验证这些行为：
- app 有稳定主窗口，不是临时 demo view。
- sidebar 选择一个对象后，detail 会跟着变化。
- inspector 可以展示和隐藏，且不承载主流程。
- Settings 是独立入口。
- 至少一个关键动作能从菜单、toolbar 或快捷键触发。
- Codex 说明了它执行过的 build/run 验证，或者明确说哪些验证还没跑。
如果这些都成立，再继续让 Codex 填业务功能。
官方资料
© OpenAI
最近更新：2026年5月4日