你的第一个
Mac 应用，
从这里开始。

想做一个自己的 Mac 小工具，却不知道从哪里开始？这一篇，我们从安装工具开始，用 Codex 或 WorkBuddy 做出一个可以双击打开的原生应用。遇到命令就照着运行，遇到提示词就复制给 AI；每一步都知道该看什么、怎样才算完成。

本文实操项目：「今日三件事」。它是一个很小的待办工具：输入任务、标记完成、删除任务，退出后数据仍然保留。功能不花哨，但足以走完一个真正 Mac 应用的完整流程。

开篇先说结论：你不用会写代码，但要会验收

过去学 macOS 开发，往往要先看很久的 Swift 语法，然后学 Xcode，最后才能拖出一个窗口。现在路径变了。Codex 和 WorkBuddy 都能读取项目文件、编写 Swift 代码、运行命令，还能根据编译错误继续修正。

但这不等于你可以闭眼点「全部允许」。你的新分工是：

1. 把需求说清楚；
2. 确认 AI 没有做超出范围的事；
3. 看懂「编译成功」和「真的能用」之间的差别；
4. 亲手打开应用，把核心功能走一遍。

这篇教程不会让你学会整本 Swift，却会让你建立一种更有用的能力：知道怎么把一个想法变成可验收的应用。

STEP 01第一步：检查你的 Mac

1. 确认系统和芯片

点屏幕左上角的苹果图标，选「关于本机」。记下两个信息：

• macOS 版本；
• 芯片是 Apple M 系列，还是 Intel。

下载 WorkBuddy 时，Apple M 系列选择 ARM64 版本，Intel 机型选择 X64 版本；安装包支持的最低系统版本以官网下载页为准。本教程把应用的最低运行目标设为 macOS 14，并使用 Swift 6 工具链。先确认这两项条件，再开始建项目。

2. 安装 Xcode Command Line Tools

打开「终端」。最快的方法是按 Command + 空格，输入「终端」，回车。然后复制这行命令：

xcode-select --install

如果系统弹出安装窗口，点「安装」，完成后再回到终端。如果提示已经安装，也没问题。连续运行下面三行：

xcode-select -p
swift --version
git --version

你应该看到一个开发工具路径、Swift 版本和 Git 版本。其中 Swift 的主版本需要是 6 或更高，因为后面的项目要求使用 Swift 6。如果还是 Swift 5，先通过系统的软件更新安装兼容的新版开发工具；旧 macOS 无法安装所需工具时，需要先升级系统。不要跳过这项检查，否则后面的构建会卡在工具链版本上。

第一次打开终端也不用紧张。复制代码框里的命令，粘贴到终端后按回车；看到新的命令提示符，才输入下一行。教程不会让你复制开头的 $，也不需要你把终端输出重新当作命令执行。

要不要装完整 Xcode？ 这个教程使用 Swift Package Manager 和终端完成本机开发，Command Line Tools 已经足够。当你需要图形化断点调试、复杂签名、App Store 上传或 iPhone 模拟器时，再安装完整 Xcode。

STEP 02第二步：在 Codex 和 WorkBuddy 之间选一个

两者都能完成本教程。你不需要同时安装，也不必讨论谁绝对更强。先把第一个应用做出来，比反复挑工具有用得多。

路线 A：用 Codex

1. 从 OpenAI 官方快速入门 下载并打开桌面端，登录账号。
2. 在产品切换器里选择 Codex。
3. 选择「打开文件夹」，把稍后创建的项目目录作为工作区。
4. 小白先保留默认权限。Codex 修改工作区内文件时可以直接执行；如果要联网、安装系统级东西或写入工作区以外，它会根据权限设置请求你批准。

Codex 里最有用的不是「一次生成几千行」，而是这个循环：先读项目，再修改，运行构建，查看差异，最后验收。看到权限弹窗时别习惯性点允许，先看它要运行的是什么。

路线 B：用 WorkBuddy

1. 访问 WorkBuddy 官网，按芯片选择 ARM64 或 X64 版本。
2. 打开 .dmg，将 WorkBuddy 拖入 Applications，然后从启动台或 Spotlight 打开。
3. 登录后创建工作空间，选中稍后创建的项目目录。
4. 新手可以直接用当前的内置模型。不要因为模型名字多，就在第一天花两小时跑分。

可选：接入自己的模型。 第一次做项目可以跳过这一段，直接使用内置模型。已经有 9Router 或其他 OpenAI 兼容网关时，再进入 WorkBuddy 的模型设置，配置自定义 API。下面是沿用本教程原有本地服务地址的示例；实际地址和端口以你正在运行的网关为准：

Base URL: http://localhost:20128/v1
API Key: 填写 9Router 当前显示的密钥
Model: 填写你在提供商中实际开通的模型 ID

先查看当前版本的模型配置说明，确认 URL 字段接收的是基础地址，还是完整请求路径；不要把 /v1 和 /chat/completions 重复拼接。保存后先用一条简单对话验证连接，再让它修改项目。API Key 只填在本地配置页，不要粘贴到对话、源码、截图或 Git 仓库。

STEP 03第三步：创建一个干净的项目文件夹

请不要把第一个项目放在桌面的一堆截图中，也不要直接放在 WorkBuddy 或 Codex 应用的安装目录里。在「文稿」下建一个专用文件夹：

mkdir -p "$HOME/Documents/MyMacApps/TodayThree"
cd "$HOME/Documents/MyMacApps/TodayThree"
git init

在 Finder 里看不到 .git 很正常，它是隐藏目录。git init 只建立本地版本仓库，不会上传代码，也不会自动保存每一次修改。等第一个版本跑通，我们还要做一次 git commit，才算留下可回看的记录。

现在回到 Codex 或 WorkBuddy，将 TodayThree 设为当前工作区。检查界面上显示的路径，确保最后一层确实是 TodayThree。路径选错是新手最容易忽略的问题：AI 不是不干活，而是在另一个文件夹干活。

STEP 04第四步：把需求写成 AI 不容易误解的样子

「帮我写个待办应用」不是一条好需求。它没说平台、界面、存储、技术栈，也没说怎样才算完成。你不需要用专业黑话，但要把自己脑子里的画面说出来。

一条好指令至少包含四件事：

• 目标：做什么；
• 背景：现在是空文件夹，你不会 Swift；
• 约束：必须是 SwiftUI 原生应用，不要 Electron，不加第三方依赖；
• 完成标准：要编译、打包、打开并完成验收。

把下面这段完整复制给 Codex 或 WorkBuddy：

请在当前空工作区中创建一个 macOS 原生应用，名称为「今日三件事」，英文产品名为 TodayThree。

我是新手，不会 Swift。请先检查本机 Swift 和当前目录，然后给出一份简短执行计划，等我确认后再修改文件。

技术要求：
1. 使用 Swift 6、SwiftUI 和 Swift Package Manager，最低支持 macOS 14。
2. 不使用 Electron，不使用第三方依赖，不请求网络权限。
3. 窗口保持简洁：顶部是标题和今天日期，中间只显示最多 3 条任务，底部有输入框和添加按钮。
4. 每条任务可以标记完成和删除；已有 3 条时禁止继续添加，并显示友好提示。
5. 使用 UserDefaults 保存任务，退出再打开后仍然存在。
6. 提供 package_app.sh，用 release 模式构建，通过 swift build -c release --show-bin-path 定位产物，生成 dist/TodayThree.app，写入有效 Info.plist，并做 ad-hoc 签名供本机调试。
7. 加一份 README.md，告诉新手怎样构建、打包、运行和清理产物。

验收要求：
- 运行 swift build 必须成功。
- 运行打包脚本后，dist/TodayThree.app 必须存在。
- 运行 plutil -lint 检查 Info.plist。
- 运行 codesign --verify --deep --strict --verbose=2 检查签名。
- 打开应用，确认进程存活且没有立即崩溃。
- 最后向我列出你创建的文件、执行过的检查，以及仍需要我亲手验证的界面功能。

这段指令并不神奇。它只是把「我想要一个小工具」拆成了可执行、可检查的条件。你以后做剪贴板工具、图片压缩工具、定时器，都可以沿用这个骨架。

STEP 05第五步：别急着执行，先看计划

正常情况下，AI 会先检查目录和 Swift 环境，然后给出类似下面的计划：

1. 创建 Package.swift 和 Sources/TodayThree/；
2. 创建数据模型和 UserDefaults 存储；
3. 创建 SwiftUI 窗口与任务列表；
4. 编译并修正构建问题；
5. 创建打包脚本和 Info.plist；
6. 检查包结构、签名和启动状态；
7. 完成 README 和人工验收清单。

你不需要看懂每个技术名词，但要做三个检查：

• 有没有把项目改成 iOS 或网页？
• 有没有悄悄加数据库、云服务或第三方库？
• 有没有包含构建、打包和验收？

都没问题，再回复：

计划没问题，按计划执行。遇到编译问题请先根据完整错误信息定位，不要为了绕过错误而删除我要的功能。

这句话很重要。AI 遇到难题时，有时会倾向「先把这个功能去掉，让构建通过」。构建绿了，但你要的东西也没了。完成标准就是用来拦住这种「看上去成功」的。

STEP 06第六步：看懂 AI 创建了什么

执行完后，你的文件夹大致会变成：

TodayThree/
├── Package.swift
├── README.md
├── package_app.sh
├── Sources/
│   └── TodayThree/
│       ├── TodayThreeApp.swift
│       ├── ContentView.swift
│       ├── TaskItem.swift
│       └── TaskStore.swift
├── .build/          # Swift 构建缓存，不需要手工编辑
└── dist/
    └── TodayThree.app

Package.swift 是项目说明书，告诉 Swift 项目名、平台版本和要构建的程序。Sources 是源码。.build 是中间产物。dist 是你最后要去找应用的地方。

打包脚本不应该猜测二进制在 .build/debug。更稳妥的做法是让 Swift 自己报告路径：

swift build -c release
swift build -c release --show-bin-path

打包后的 .app 实际是一个特殊文件夹。Finder 把它显示成一个应用图标，里面有可执行文件和 Info.plist。Info.plist 至少要正确声明应用名、可执行文件名、Bundle ID 和最低系统版本。

完成后，先运行 git status，再打开 Codex/WorkBuddy 的「变更」面板。普通 git diff 不显示尚未跟踪的新文件：第一次生成项目时，要点开这些新文件看内容；文件已被 Git 跟踪后，再用 diff 比较改动。先看文件名，再留意意外的网络请求、密钥、删除操作和工作区外路径。不会 Swift，也可以完成这一层审查。

STEP 07第七步：按顺序构建、打包和启动

即使 AI 说「已完成」，你也可以在项目终端里亲手跑一遍。下面每行都要在 TodayThree 目录中执行；上一行成功后，再运行下一行。 先确认目录并编译：

pwd
swift build

然后给打包脚本执行权限，生成应用包：

chmod +x package_app.sh
./package_app.sh

检查包结构与签名：

plutil -lint dist/TodayThree.app/Contents/Info.plist
codesign --verify --deep --strict --verbose=2 dist/TodayThree.app

两项检查通过后，再打开应用：

open dist/TodayThree.app

第一行 pwd 用来防止路径跑偏。swift build 成功时，终端最后会显示构建完成，不应该有 error:。chmod +x 只是给打包脚本可执行权限。plutil 返回 OK，代表 plist 格式有效。codesign 没有报错，代表当前 app bundle 通过了签名结构检查。

open 执行后，应用窗口应该出现。这时不要立刻说「成功了」，照着下面的人工清单点一遍：

• 窗口标题正常，没有白屏、闪退或字体截断；
• 输入一条任务，按回车或点按钮可以添加；
• 连续添加到 3 条，第 4 条不能添加；
• 标记完成后，界面有清楚变化；
• 删除一条后，可以再添加；
• 退出应用，再打开，剩余任务仍在。

这六项全过，才是「第一个可用版」。编译成功只能证明代码能变成程序，不能证明按钮真的做了你想要的事。

STEP 08第八步：出错时别乱改，把信息收集齐

终端出现红字，先停在出错的那一步。把现场留完整，通常比连改五个设置更快解决问题。按这个顺序处理：

1. 停下来，不要连续运行网上复制的 sudo 或删除命令；
2. 复制从命令开始到最后一行的完整输出；
3. 告诉 AI 你刚才做了什么、期望看到什么、实际看到什么；
4. 要求它先判断原因，再做最小修改，修改后重跑原来的检查。

可以复制这个模板：

我在当前项目执行「[写你运行的命令]」时失败。
预期：[你希望出现的结果]
实际：[完整错误输出]

请先说明根因，检查当前文件和环境，只做修复该问题所必需的改动。不要删除已实现的功能，不要使用 sudo，不要改我的系统设置。修复后重新执行同一条验收命令。

如果是「应用打开了，但按钮不对」，别只说「不能用」。说得像一个现场目击者：

我已经添加 3 条任务。输入第 4 条后，添加按钮仍然可点，点击后列表出现了 4 条。预期是按钮禁用，列表最多只有 3 条。请修正这一处逻辑并重新构建，其他功能保持不变。

一条具体的现象，往往比一大段情绪化描述更能帮 AI 修对问题。

STEP 09第九步：迭代时一次只改一件事

第一版能用后，你肯定会开始有新想法：加菜单栏图标、定时提醒、iCloud 同步、开机启动、多台 Mac 同步。这里最容易犯的错，是一口气把五个功能都塞给 AI。

更稳的做法是「一次一个可验收变化」。例如：

请只做一个改动：在任务全部完成时，标题下方显示「今天收工」。不要改数据结构、存储方式和打包脚本。修改后运行 swift build，并告诉我怎样人工验收。

每次改完都跑构建，再做一个小验收，然后提交本地 Git。让 AI 先创建 .gitignore，至少写入 .build/、dist/ 和 .DS_Store，再运行：

git status
git add .gitignore Package.swift Sources package_app.sh README.md
git commit -m "Build the first working TodayThree app"

提交前看一眼 git status，别把构建缓存、应用产物或密钥配置一起提交。第一次使用 Git，如果提示缺少作者身份，先配置这个项目的姓名和邮箱，再重跑提交命令。提交成功后，git log -1 --oneline 会显示刚才的记录；本地提交仍然不会把文件上传到网上。

STEP 10第十步：「我自己用」和「发给别人」是两件事

教程前面使用的 codesign --sign - 是 ad-hoc 签名，适合本机开发和调试。它不等于 Apple 认证的 Developer ID 签名，更不等于已经公证或上架 App Store。

当别人的 Mac 提示无法检查应用时，不要教对方关闭整台 Mac 的安全机制。如果对方确认应用来自你，正确的临时处理是：先尝试打开，然后到「系统设置 → 隐私与安全性」里找到该应用的「仍要打开」。长期分发则应该做正式签名和公证，不应该让每个用户绕过警告。

另外，只要应用开始处理个人文件、剪贴板、摄像头、麦克风、位置、SSH 密钥或服务器管理，就要重新评估权限。不要把管理员密码、API Key 或 SSH 私钥粘贴给 AI；对删除、部署、修改防火墙等高风险操作，应该先显示将执行的命令，再等人工确认。

延伸阅读一张可打印的完成清单

做完第一个项目时，你可以逐项打勾。网页会在当前浏览器保存勾选状态；换设备或清理浏览器数据后，需要重新勾选。

• 我能在「关于本机」中说出自己的 macOS 版本和芯片类型。
• xcode-select -p、swift --version 和 git --version 都有正常输出。
• 项目有自己的文件夹，Codex 或 WorkBuddy 打开的就是这个路径。
• 我没有在对话、代码或 Git 中放 API Key 和密码。
• AI 在写代码前给了计划，我检查过范围。
• swift build 成功，终端里没有 error:。
• dist/TodayThree.app 存在，plutil 和 codesign --verify 通过。
• 我亲手验证了添加、三条上限、完成、删除和重启后保存。
• 我知道 ad-hoc 签名只适合本机调试，不会把它写成「已经 Apple 认证」。
• 我用 Git 记录了第一个可用版本。

如果这些都完成，你已经不是「让 AI 吐了一堆代码」。你做出了一个有明确需求、有可回滚版本、通过构建和人工验收的 Mac 原生应用。这两者差得很远。

延伸阅读接下来怎么学，才不会越学越乱

不要立刻去做「一个完整的 Notion」或「自己的微信」。先在这个小应用上完成三次小迭代：

1. 加一个「清空已完成」按钮；
2. 给任务加上拖拽排序；
3. 加一个菜单栏入口，但保留主窗口。

每次都重复同一个循环：先说完成标准，再让 AI 修改，看变更，跑构建，亲手验收，提交 Git。做完三次，你就会自然开始认识 View、State、数据模型和存储，而不是靠背语法记住它们。

Codex 和 WorkBuddy 是工具，不是一键应用自动售货机。它们最适合的位置，是坐在你旁边干活：你定义什么值得做，它们帮你把实现、检查和修正的周期大幅缩短。第一个小应用不需要惊艳，它只需要真的打开，真的解决你的一个小问题。

延伸阅读官方资料

• Codex / ChatGPT 桌面端快速入门
• Codex 最佳实践
• Codex 权限、沙箱与审批
• WorkBuddy Mac 安装指南
• WorkBuddy 模型配置
• 9Router 官网
• Apple：安装 Xcode Command Line Tools
• Apple：在 Mac 上安全打开应用
• Apple：在分发前公证 macOS 软件
• Swift Package Manager

2026 年 10 月阅读修订版。补充 Swift 6 前置条件、Git 新文件检查和分步验收命令。初版示例于 2026 年 8 月完成本机构建、打包与启动检查。工具界面与分发要求会变化，安装和发布时请以相应官方文档为准。