English
主导航
Codex

Codex 用例

为 macOS 构建

使用 Codex 为原生的 Mac 应用搭建脚手架、构建并使用 SwiftUI 进行调试。

难度 高级
时间周期 1h

使用 Codex 构建 macOS SwiftUI 应用,建立以 Shell 为中心的构建与运行循环,并在应用成熟时添加桌面原生场景、窗口、AppKit 和签名工作流。

适用场景

  • 需要 Codex 搭建桌面原生应用外壳和可重复构建脚本的全新 macOS SwiftUI 项目
  • 需要 Codex 处理窗口、菜单、侧边栏、设置、AppKit 互操作或签名问题的现有 Mac 应用
  • 希望 macOS 开发保持以 Shell 为中心,同时兼顾原生桌面 UX 惯例的团队

目录

    ← 所有用例

    为 macOS 构建

    使用 Codex 为原生的 Mac 应用搭建脚手架、构建并使用 SwiftUI 进行调试。

    使用 Codex 构建 macOS SwiftUI 应用,建立以 Shell 为中心的构建与运行循环,并在应用成熟时添加桌面原生场景、窗口、AppKit 和签名工作流。

    高级
    1h

    使用 Codex 构建 macOS SwiftUI 应用,建立以 Shell 为中心的构建与运行循环,并在应用成熟时添加桌面原生场景、窗口、AppKit 和签名工作流。

    高级
    1h

    适用场景

    • 需要 Codex 搭建桌面原生应用外壳和可重复构建脚本的全新 macOS SwiftUI 项目
    • 需要 Codex 处理窗口、菜单、侧边栏、设置、AppKit 互操作或签名问题的现有 Mac 应用
    • 希望 macOS 开发保持以 Shell 为中心,同时兼顾原生桌面 UX 惯例的团队

    技能与插件

    技能 为什么使用它
    使用 macOS SwiftUI 模式、窗口管理、AppKit 互操作以及构建/运行技能,创建侧边栏-详情-检查器布局,连接菜单和设置,并在外壳优先的循环中验证应用。 使用以 Shell 为中心的开发工作流来构建和调试 macOS 应用,设计桌面原生 SwiftUI 场景和窗口,按需桥接 AppKit,并准备签名和公证流程。

    起始提示词

    使用 Build macOS Apps 插件来搭建一个 macOS SwiftUI 初始应用,并添加一个项目本地的 `script/build_and_run.sh` 入口,以便我将它关联到 `Run` 操作。 约束: - 保持以 Shell 为中心。Xcode 项目首选 `xcodebuild`,以包为主的应用首选 `swift build`。 - 明确地使用主窗口对 Mac 场景进行建模,仅在符合产品需求时才添加 `Settings`、`MenuBarExtra` 或实用工具窗口。 - 桌面端首选原生侧边栏、工具栏、菜单、键盘快捷键和系统材质,而非 iOS 风格的推送导航。 - 仅当 SwiftUI 无法干净地表达桌面行为时,才使用最小化的 AppKit 桥接。 - 每次更改保持一个小型的验证循环,并确切地告诉我你运行了哪些构建、启动或日志命令。 交付: - 应用脚手架或请求的 Mac 功能切片 - 可复用的构建与运行脚本 - 你执行过的最小验证步骤 - 任何你建议的桌面特定后续工作
    使用 Build macOS Apps 插件来搭建一个 macOS SwiftUI 初始应用,并添加一个项目本地的 `script/build_and_run.sh` 入口,以便我将它关联到 `Run` 操作。 约束: - 保持以 Shell 为中心。Xcode 项目首选 `xcodebuild`,以包为主的应用首选 `swift build`。 - 明确地使用主窗口对 Mac 场景进行建模,仅在符合产品需求时才添加 `Settings`、`MenuBarExtra` 或实用工具窗口。 - 桌面端首选原生侧边栏、工具栏、菜单、键盘快捷键和系统材质,而非 iOS 风格的推送导航。 - 仅当 SwiftUI 无法干净地表达桌面行为时,才使用最小化的 AppKit 桥接。 - 每次更改保持一个小型的验证循环,并确切地告诉我你运行了哪些构建、启动或日志命令。 交付: - 应用脚手架或请求的 Mac 功能切片 - 可复用的构建与运行脚本 - 你执行过的最小验证步骤 - 任何你建议的桌面特定后续工作

    搭建应用和构建循环

    对于新的 Mac 应用,请先让 Codex 选择正确的场景模型: WindowGroup, Window, Settings, MenuBarExtra, or DocumentGroup。这使应用从首次编写起就保持桌面原生体验,而不是从 iOS 风格 ContentView.

    保持执行循环以 Shell 为中心。对于 Xcode 项目,请使用 xcodebuild。对于包优先的应用,请使用 swift build and a project-local script/build_and_run.sh 该包装脚本会停止旧进程、构建应用、启动新产物,并可选择暴露日志或遥测数据。

    如果纯 SwiftPM 应用是一个 GUI 应用,请将其打包并作为 .app 启动,而不是直接运行原始可执行文件。这可以避免本地验证期间出现缺少 Dock 图标、应用激活和 Bundle 标识的问题。

    利用技能

    添加 构建 macOS Apps 插件 一旦工作变得更加侧重于桌面端特性时。它涵盖了以 Shell 为中心的构建和调试循环、SwiftPM 应用打包、原生 SwiftUI 场景和窗口模式、AppKit 互操作、统一日志记录、测试分类以及签名/公证工作流。

    要了解更多关于如何安装和使用插件及技能的信息,请参阅 Codex 插件文档 and 技能文档.

    构建桌面原生 UI

    优先使用 Mac 惯例而非 iOS 导航模式。使用 NavigationSplitView for sidebar/detail layouts, explicit Settings 场景作为偏好设置,工具栏和命令用于可发现的操作,菜单栏额外项用于轻量级的常驻实用工具。

    优先使用系统材质、语义颜色和标准控件。仅当产品需要独特的桌面外观时,才添加自定义窗口样式、拖拽区域或 Liquid Glass 表面。

    如果 SwiftUI 接近但未完全满足需求,请添加尽可能小的 AppKit 桥接。典型的例子包括打开/保存面板、第一响应者控制、菜单验证、拖放边缘以及封装的 NSView for one specialized control.

    调试、测试并准备发布

    关于运行时行为,让 Codex 添加一些围绕窗口打开、侧边栏选择、菜单命令或后台同步的 Logger 事件,然后在应用启动后使用 log stream 来验证这些事件。

    对于失败的测试,让 Codex 先运行最小可用的 xcodebuild test or swift test 测试范围,并分类问题是编译、断言失败、崩溃、偶发故障,还是环境/配置问题。

    当工作从本地迭代转向分发时,要求 Codex 准备一条 Xcode 中的手动归档路径,以及一条基于脚本的归档和公证路径,以实现可重复的交付。让它检查应用包、授权和 hardened runtime,使用 codesign and plutil,并使用 App Store Connect CLI 当你希望上传也保留在终端中时。

    示例提示词

    使用 Build macOS Apps 插件来构建此应用功能的原生 macOS SwiftUI 版本。约束条件:- 使用桌面原生的场景结构,包含主窗口、设置,以及工具栏/命令操作(在合理的地方)。- 如果该功能受益于始终可见的结构,请优先使用侧边栏/详情布局,而不是 iOS 风格的推送导航。- 仅当 SwiftUI 无法干净地表达某个特定的桌面行为时,才添加微小的 AppKit 桥接。- 创建或更新 `script/build_and_run.sh`,使构建/运行循环保持在 shell 优先的状态。- 告诉我你使用了哪些构建、启动、测试和日志命令。交付该功能切片,使用最小的相关构建或测试循环进行验证,并总结在分发之前所需的任何签名或打包后续工作。

    实用技巧

    保持场景明确

    将主窗口、设置窗口、实用工具窗口和菜单栏 extras 建模为独立的场景根节点,而不是将整个应用隐藏在一个巨大的视图中。

    让系统 UI 承担更多工作

    在创建自定义侧边栏、工具栏或材质之前,检查标准的 SwiftUI 场景和窗口 API 是否已经为你提供了所需的 Mac 行为。

    将 AppKit 视为有限的边缘

    使用 NSViewRepresentable, NSViewControllerRepresentable,或专注的 NSWindow 辅助工具,用于弥补某项缺失的桌面功能,但将 SwiftUI 保留为选择和应用状态的可靠数据源。

    独立于本地构建成功来验证签名和公证

    本地启动成功并不能证明应用已签名或具备公证条件。保留一个手动的 Xcode 归档流程用于一次性发布检查,添加一个基于脚本的归档和公证流程用于可重复的分发,并在任务涉及交付(而不仅仅是本地迭代)时运行 codesign and plutil 检查。

    技术栈

    需求

    UI 框架

    默认选项

    SwiftUI

    为何需要它

    适用于窗口、侧边栏、工具栏、设置和场景驱动的 Mac 应用结构的强大默认配置。

    需求

    AppKit 桥接

    默认选项

    AppKit

    为何需要它

    当 SwiftUI 无法满足你所需的某项桌面行为时,使用小型的 NSViewRepresentable, NSViewControllerRepresentable, or NSWindow 桥接。

    需求

    构建与打包

    默认选项

    xcodebuild, swift build,且 App Store Connect CLI

    为何需要它

    将本地构建、手动归档、基于脚本的公证和 App Store 上传保持在可重复的终端优先循环中。

    需求 默认选项 为何需要它
    UI 框架 SwiftUI 适用于窗口、侧边栏、工具栏、设置和场景驱动的 Mac 应用结构的强大默认配置。
    AppKit 桥接 AppKit 当 SwiftUI 无法满足你所需的某项桌面行为时,使用小型的 NSViewRepresentable , NSViewControllerRepresentable , or NSWindow 桥接。
    构建与打包 xcodebuild , swift build ,且 App Store Connect CLI 将本地构建、手动归档、基于脚本的公证和 App Store 上传保持在可重复的终端优先循环中。

    相关用例