用 AI 写 Mac App 真能落地：从 UI 设计到 AppKit 开发的实战经验

想用 AI 写 Mac App？完全可以。

别再停留在“让 AI 写个按钮、写个弹窗”的玩具阶段了。现在你真的可以靠 AI 搭出一个像样的 macOS 应用：有窗口、有菜单、有状态栏、有原生交互，甚至还能做得挺好看。

但这里有个关键点：

别把 AI 当成许愿池。

你不能只丢一句“帮我写一个 Mac App”，然后期待它给你端出一个能上架的成品。更靠谱的玩法是：你负责把方向拆清楚，AI 负责把代码、界面和细节快速堆出来。

这篇文章聊一套我更推荐的流程：

• 技术栈怎么选
• UI 该在哪一步做
• Claude、Codex、GPT 类模型怎么分工
• 写 Mac App 时最容易踩哪些坑
• 怎么让 AI 产出的东西更像“产品”，而不是“Demo”

结论先说：写 Mac App，优先选 AppKit

如果你要做一个认真点的 Mac App，我更建议你选：

AppKit，而不是 SwiftUI。

很多人一听 AppKit 就头大。

觉得它老、啰嗦、API 多、写起来不如 SwiftUI 爽。

这话没错。

可问题是，现在你有 AI 了。

过去 AppKit 最大的问题是：写起来麻烦。现在这个短板，AI 已经帮你补了大半。

你只要把需求说清楚，比如：

• 我要一个三栏布局
• 左边是列表
• 中间是详情页
• 右边是配置面板
• 顶部要工具栏
• 支持快捷键
• 支持菜单栏操作
• 窗口大小变化时布局别崩

AI 用 AppKit 写起来并不吃力。

而 AppKit 的优势很明显：

• 原生 macOS 味道更足
• 窗口、菜单、工具栏、状态栏控制更细
• 复杂交互更稳
• 兼容老一点的 macOS 更舒服
• 做专业工具类 App 更合适

SwiftUI 当然也能写 Mac App。

做简单应用没问题。比如计时器、记账小工具、菜单栏小插件、个人效率工具。

可一旦你开始碰这些场景：

• 多窗口管理
• 复杂列表拖拽
• 自定义工具栏
• 菜单栏深度集成
• NSPanel、Popover、StatusItem
• 文档型应用
• 类似 Finder、Xcode、Notion 桌面版这种复杂布局

SwiftUI 很容易让你边写边骂。

不是不能做，是经常绕路。

而 AppKit 直接给你底层能力。

AI 又能帮你处理那些繁琐代码。

这组合，挺香。🍺

SwiftUI 不是不能用，但别把它当万能钥匙

咱们说得更具体点。

SwiftUI 的优点是：

• 写法短
• 预览方便
• 入门舒服
• 做简单界面很快
• 适合 iOS / macOS 多端共用一些逻辑

可它在 Mac App 上的问题也很现实：

• 很多原生行为需要桥接 AppKit
• 复杂窗口控制不顺手
• 一些细节样式不够 Mac
• AI 生成的 SwiftUI UI 经常像移动端套壳
• 遇到系统级交互时，代码会突然变丑

比如你想做一个类似 Raycast、CleanShot、TablePlus、Transmit 这种工具型 Mac App。

SwiftUI 能不能做？

能。

但你大概率会写着写着发现：

“我怎么又开始包 NSViewRepresentable 了？”

“这个窗口怎么又要转 AppKit？”

“菜单栏怎么又得写 NSMenu？”

那不如一开始就用 AppKit。

尤其是你准备靠 AI 主力编码时，AppKit 的复杂反而没那么可怕。

你让 AI 写，它不嫌累。

你负责验收就行。

推荐工作流：先设计，再写代码

很多人用 AI 写 App 的姿势不对。

一上来就说：

帮我写一个 macOS App，用来管理待办事项。

然后 AI 给你一堆代码。

你跑起来一看：

界面像课程作业。

按钮间距奇怪。

颜色没层次。

交互也很糙。

这时候你再让 AI 改 UI，它就开始东补一块、西补一块。越改越乱。

更好的顺序是：

先用 Claude Design 打磨 UI 和 UX，再进入编码阶段。

你可以把它当成一个“产品设计搭子”。

先别急着要代码。

先让它帮你确定：

• 应用定位
• 核心用户场景
• 页面结构
• 信息层级
• 导航方式
• 空状态
• 错误状态
• 快捷键设计
• macOS 原生交互习惯
• 深色模式表现

把这些设计清楚，后面写代码会顺很多。

不然你会陷入一个很烦的循环：

写代码 → 发现 UI 不对 → 改布局 → 交互变怪 → 再改代码 → 新 bug 出现。

这不是开发，这是泥潭摔跤。

Claude Design 适合做什么？

Claude Design 很适合拿来做 UI/UX 前期方案。

尤其是你脑子里有个大概想法，但还没形成完整界面时。

比如你想做一个 Mac 上的截图管理工具。

你可以这样问：

我想做一个 macOS 截图管理 App，目标用户是经常写文档、做教程、整理素材的人。

请帮我设计这个 App 的主界面和核心交互。

要求：
- 使用 macOS 原生桌面应用风格
- 适合 AppKit 实现
- 主界面不要像网页
- 支持深色模式
- 支持快捷键
- 需要有空状态、搜索状态、筛选状态
- 给出布局说明、组件层级、交互流程

这个阶段，你要的不是代码。

你要的是产品骨架。

让它输出类似这样的内容：

• 左侧：图库分类、标签、智能筛选
• 中间：截图网格，支持多选、拖拽、右键菜单
• 右侧：图片详情、OCR 文本、备注、导出选项
• 顶部：搜索框、导入按钮、视图切换
• 底部：当前选中数量、同步状态

有了这个结构，再让 AI 写 AppKit，就不会乱飞。

UI 想好看一点，Claude Opus 更值得试

如果你的重点是界面质感，Claude Opus 的表现通常更稳。

尤其是这几类任务：

• 设计桌面应用布局
• 调整视觉层级
• 优化控件间距
• 设计空状态文案
• 让界面更像 macOS 原生应用
• 让工具型产品看起来不廉价

有些模型写功能很猛，但做 UI 容易出现一种味道：

“能用，但像内部后台。”

按钮是有了。

列表是有了。

搜索也有了。

可你就是不想每天打开它。

Mac App 很吃审美。

用户对桌面应用的容忍度很低。

一个工具如果每天都要打开，界面丑真的会劝退。

所以我的建议是：

• Claude Opus：适合 UI/UX、产品结构、文案、体验细节
• Codex：适合把设计落成代码，处理工程问题
• GPT 类模型：适合查漏补缺、解释错误、生成测试方案、拆需求

别指望一个模型包打天下。

让它们各干擅长的事。

这才是 AI 编程里最省心的玩法。

Codex 的 “Build macOS Apps” 插件值得用

如果你用 Codex，记得找一下官方插件：

Build macOS Apps

这个插件的价值在于，它更懂 macOS App 的工程结构。

你不是只要一段 Swift 代码。

你要的是一个能跑的工程。

包括：

• Xcode 项目结构
• AppDelegate / SceneDelegate 或对应入口
• Info.plist 配置
• macOS 权限声明
• 资源文件管理
• 打包运行
• 常见编译错误修复
• AppKit 组件组织

很多 AI 写代码时容易犯一个毛病：

它给你的片段看着对，但放进项目就红。

少 import。

类名对不上。

文件结构乱。

生命周期写错。

权限没配。

然后你开始一边复制错误，一边让 AI 修。

用专门的 macOS 插件，至少能减少这类低级折腾。

一套更顺手的 AI Mac App 开发流程

你可以直接照这个流程走。

1. 先写产品说明，不写代码

准备一份简短 PRD。

不用很正式，但要说清楚。

模板如下：

我要做一个 macOS App：Clipboard Shelf。

用途：管理剪贴板历史，适合经常写代码、写文章、整理资料的人。

核心功能：
- 自动记录文本剪贴板
- 支持搜索历史
- 支持收藏常用片段
- 支持快捷键呼出主窗口
- 支持菜单栏常驻
- 支持隐私过滤，比如密码、银行卡号不保存

目标风格：
- 原生 macOS 工具型应用
- 界面简洁
- 深色模式好看
- 不要网页感

技术偏好：
- 使用 AppKit
- Swift
- 本地存储优先

这个东西非常重要。

你说得越清楚，AI 越不容易跑偏。

2. 让 Claude Design 输出 UI/UX 方案

提示词可以这样写：

请基于上面的产品说明，设计 macOS App 的界面和交互方案。

要求：
- 面向 AppKit 实现
- 给出窗口结构
- 给出主要控件
- 给出菜单栏设计
- 给出快捷键设计
- 给出空状态、错误状态、加载状态
- 给出深色模式建议
- 不要写代码

注意一句：不要写代码。

这很关键。

设计阶段就专心做设计。

别让它提前进入实现细节。

3. 让模型把设计拆成开发任务

拿到 UI/UX 方案后，让 AI 拆任务。

请把这个 macOS App 拆成开发任务。

要求：
- 按模块拆分
- 每个任务都能独立实现和测试
- 标出依赖关系
- 标出适合先做的 MVP 范围
- 技术栈使用 Swift + AppKit

你要得到类似这样的任务列表：

• 项目初始化
• 主窗口布局
• 剪贴板监听
• 本地数据存储
• 搜索功能
• 收藏功能
• 菜单栏图标
• 快捷键注册
• 隐私过滤
• 偏好设置页
• 打包和权限配置

这一步能防止 AI 一次生成一大坨代码。

一大坨代码最可怕。

看起来很完整，调起来想哭。

4. 交给 Codex 实现工程

到这里再让 Codex 写代码。

不要一次性做完整 App。

从最小版本开始。

比如：

请创建一个 Swift + AppKit 的 macOS App 最小工程。

目标：
- 主窗口显示一个三栏布局
- 左侧是分类列表
- 中间是剪贴板历史列表
- 右侧是详情面板
- 使用原生 AppKit 控件
- 支持深色模式
- 代码结构清晰，按文件拆分
- 暂时使用内存数据，不接入真实剪贴板

先让界面跑起来。

再接功能。

这个节奏最稳。

5. 每次只让 AI 改一个点

别这样提需求：

帮我优化 UI，修复 bug，增加搜索，加入收藏，顺便做菜单栏。

这叫给 AI 上强度。

它很可能给你整出一锅乱炖。

更好的方式：

现在只做搜索功能。

要求：
- 在工具栏加入 NSSearchField
- 输入关键词后过滤中间列表
- 搜索范围包括 title 和 content
- 不改变当前项目结构
- 不重写已有 UI
- 只给出需要修改的文件

重点是：

• 只改一个点
• 明确不要重写
• 明确输出哪些文件
• 明确验收标准

你会少很多崩溃时刻。

示例：让 AI 写 AppKit 三栏主界面

下面是一个更实用的提示词。

你可以直接复制改。

请使用 Swift + AppKit 实现一个 macOS App 的主窗口界面。

界面结构：
- 使用 NSSplitViewController 做三栏布局
- 左栏宽度 220，用于显示分类
- 中栏宽度自适应，用于显示条目列表
- 右栏宽度 320，用于显示详情

视觉要求：
- 原生 macOS 风格
- 支持深色模式
- 控件间距自然
- 列表选中状态清晰
- 不要使用 SwiftUI

代码要求：
- 拆分为 MainWindowController、SidebarViewController、ListViewController、DetailViewController
- 每个文件职责清楚
- 使用 mock 数据
- 可以直接在 Xcode 中运行

请输出完整代码，并说明每个文件放在哪里。

这个提示词比“帮我写个三栏界面”靠谱多了。

因为它告诉 AI：

• 用什么技术
• 用什么控件
• 宽度怎么设
• 文件怎么拆
• 视觉要什么感觉
• 暂时不用真实数据

AI 最怕模糊。

你越像产品经理，它越像工程师。

当然，别学坏了，别只会甩锅。😄

Mac App 常见功能，建议这样分配给 AI

菜单栏 App

适合让 AI 用 AppKit 写。

关键词：

• NSStatusItem
• NSMenu
• NSPopover
• NSPanel

提示词里可以明确说：

请使用 NSStatusBar 创建菜单栏图标，点击后显示 NSPopover，不要使用 SwiftUI。

快捷键

系统级快捷键别让 AI 瞎写。

你要确认使用方式。

常见方案：

• 本地快捷键：App 内有效
• 全局快捷键：需要额外处理，可能涉及 Carbon API 或第三方库

提示词建议：

请实现 App 内快捷键 Command+K，用于聚焦搜索框。不要实现全局快捷键。

先做 App 内。

全局快捷键后面再上。

本地存储

别一开始就上复杂数据库。

MVP 阶段可以先用：

• UserDefaults：配置项
• JSON 文件：简单数据
• SQLite：结构化数据
• Core Data：复杂对象关系

让 AI 先从 JSON 文件开始，最容易调。

请先用 JSON 文件做本地持久化，不要引入 Core Data。

权限申请

macOS 权限很容易漏。

比如：

• 文件访问
• 辅助功能权限
• 屏幕录制权限
• 自动化权限
• 剪贴板相关行为

让 AI 写权限相关功能时，要让它同时检查：

• Info.plist
• entitlements
• sandbox
• 用户授权提示
• 权限不足时的 UI

不要只写功能代码。

权限没配，功能就像摆设。

避坑清单：这些地方最容易翻车

坑 1：一上来就让 AI 写完整 App

别这么干。

完整 App 不是一段代码。

它是需求、界面、状态、数据、权限、异常处理、打包流程的组合。

正确做法：

• 先做可运行骨架
• 再做核心界面
• 再接真实数据
• 再补设置、权限、空状态
• 再优化视觉

坑 2：让 AI 同时改 UI 和业务逻辑

这很危险。

UI 一改，状态绑定可能断。

业务一改，界面刷新可能乱。

建议分开：

• 只改 UI
• 只改数据层
• 只改交互
• 只修一个 bug

坑 3：不指定 AppKit，结果生成 SwiftUI

很多模型默认爱写 SwiftUI。

你要直接写死：

不要使用 SwiftUI。请使用 AppKit 和 NSViewController。

必要时再加一句：

如果需要自定义视图，请使用 NSView 子类实现。

坑 4：没有验收标准

“界面好看一点”太虚了。

换成：

左侧栏背景使用系统 sidebar 材质风格。
列表行高 44。
详情页标题字号 18。
空状态居中显示图标、标题和说明文字。
窗口最小宽度 900，高度 600。

AI 不怕要求多。

它怕要求玄。

坑 5：忽略 macOS 原生习惯

Mac App 不是网页套壳。

你要考虑：

• 菜单栏
• 快捷键
• 右键菜单
• 拖拽
• 工具栏
• 偏好设置窗口
• 深色模式
• 窗口恢复
• Dock 菜单

这些东西会让你的 App 更像真的 Mac App。

一个靠谱的提示词模板

下面这个模板可以反复用。

你是一名资深 macOS AppKit 开发者。

我要实现的功能：
【写清楚功能】

当前项目情况：
【写已有文件结构、当前问题、已实现内容】

技术要求：
- Swift
- AppKit
- 不使用 SwiftUI
- 使用 NSViewController / NSWindowController
- 保持现有项目结构

实现要求：
- 只修改必要文件
- 不重写无关代码
- 给出完整代码
- 标出文件路径
- 说明如何运行和测试

验收标准：
- 【标准 1】
- 【标准 2】
- 【标准 3】

这个模板的核心是：

• 给角色
• 给上下文
• 给限制
• 给验收标准

AI 不是你肚子里的蛔虫。

上下文越完整，返工越少。

推荐工具搭配

| 阶段 | 推荐工具/模型 | 用法 | |---|---|---| | 产品想法 | Claude / GPT 类模型 | 梳理功能、定位、MVP | | UI/UX 设计 | Claude Design / Claude Opus | 设计页面结构、交互、状态 | | 代码实现 | Codex + Build macOS Apps | 生成 AppKit 工程和功能模块 | | Debug | Codex / GPT 类模型 | 读报错、修编译问题、补测试 | | 文案与空状态 | Claude Opus | 写更自然的界面文案 | | 代码审查 | GPT 类模型 | 查结构问题、潜在 bug、边界情况 |

不要迷信单一模型。

AI 开发更像组队。

有人负责设计，有人负责写代码，有人负责挑刺。

你是项目负责人。

别把方向盘交出去。

写到能上手的程度，建议从这个小项目练

如果你还没用 AI 写过 Mac App，别一上来做复杂产品。

可以从这个练手：

菜单栏剪贴板历史工具

MVP 功能：

• 菜单栏常驻
• 点击打开列表
• 记录最近 20 条文本
• 支持搜索
• 点击复制回剪贴板
• 支持清空历史

技术点覆盖得刚好：

• NSStatusItem
• NSPopover
• NSTableView
• NSPasteboard
• 本地存储
• 搜索过滤
• 菜单操作

做完这个，你基本就摸到 AI 写 Mac App 的门了。

再往后加收藏、快捷键、隐私过滤、iCloud 同步，都有路可走。

关键建议

用 AI 写 Mac App，真正拉开差距的不是“谁会提一句需求”。

而是你能不能做到这几件事：

• 技术栈选对：复杂 Mac App 优先 AppKit
• 设计先行：别一上来写代码
• 模型分工：Claude 做设计，Codex 做工程
• 小步迭代：每次只改一个模块
• 验收明确：别用“好看一点”这种玄学要求
• 尊重 macOS：菜单、快捷键、窗口、右键菜单都要考虑

AI 可以把大量脏活累活接过去。

可产品判断、取舍、审美和验收，还是得你来。

这反而是好事。

你不用再被样板代码拖住，可以把精力放在真正影响产品质感的地方。

一个人做 Mac App，已经没以前那么遥远了。现在更像是：你把需求拆清楚，AI 帮你把砖一块块码上去。

码得稳不稳，取决于你这个“包工头”会不会指挥。