文章目录

• 先读项目
• 再做修改
• 改完就构建
• 构建失败，就继续看错
• 最后，跑测试
• ExecuteSnippet：它开始学会验证猜想
• RenderPreview：它开始不只是读代码，而是看结果
• 第一，它补的是最后一公里
• 第二，它让 AI 更像执行者，而不只是建议者
• 第三，它特别适合真实开发里的中小型任务
• 它不能代替产品判断
• 工具存在，不等于成熟稳定
• 写操作一定要控权限
• 第一层：先开放只读 + 构建测试
• 第二层：再开放温和写操作
• 第三层：最后再考虑高副作用能力

一份 Xcode 工具清单，为什么让我觉得 AI 开始真正进入开发现场了？

不是 AI 更会写 Swift 了，而是它开始有机会真正碰到 Xcode 的工作流。

前几天，我看到一个公开的 GitHub Gist。

标题很朴素，甚至有点不起眼：

Xcode 26.3 mcpbridge tools/list response

点进去之后，没有海报，没有 Demo，也不是教程。

只有一份 JSON。

但偏偏就是这种看起来很冷的东西，最容易暴露趋势。

我看完之后，脑子里冒出来的判断很直接：AI 开始真正进入 Xcode 的工作流了。

它到底是什么？

先说人话。

这份 Gist 不是 App，不是插件安装包，也不是面向普通用户的文章。

它更像一份“能力清单”：这个 Xcode MCP 服务能调用哪些工具、每个工具能做什么、AI 可以如何去读项目、找文件、改代码、构建、跑测试、查问题。

换句话说，它不是在展示“模型有多聪明”。

它在展示的是：模型现在能在 Xcode 里碰哪些东西。

而这件事，恰恰很关键。

因为过去很多 AI 工具，真正能做的事情其实很有限。

它们会补全，会生成，会解释，会给建议。

但一旦进入真实项目，进入 Xcode，进入构建、测试、报错、预览这些具体环节，很多能力就开始断掉了。

所以这份 Gist 真正让我在意的，不是它列了 20 个工具。

而是它指向了一个更明确的方向：AI 正在从“写代码”，往“参与开发工作流”走。

这不是普通命令行自动化的翻版

很多人第一反应可能会是：这不就是 read、grep、xcodebuild 那一套，换了个包装吗？

表面上看，确实像。

但本质上，不一样。

因为普通命令行自动化，大多站在文件系统和 shell这一层工作。

而这份 Gist 里暴露出来的能力，明显已经在往 Xcode 项目语义层 走。

它关注的不只是磁盘上的文件，而是这些更接近真实开发现场的东西：

• Xcode 项目结构里的路径
• active scheme
• active test plan
• Issue Navigator 当前显示的问题
• SwiftUI Preview 的结果
• workspace 层面的状态

这差别很大。

因为 Apple 平台开发真正麻烦的地方，从来不只是“代码写进去没有”。

而是你要在 Xcode 这个环境里，把一整套动作做完。

所以这份清单真正透露出来的是：AI 不再只是看一堆 Swift 文件，而是开始尝试理解 Xcode 这个工作环境本身。

真正值钱的，是它拼出了一条闭环

这份 JSON 一共列了 20 个工具。

如果只是一条条看名字，它们会显得很散。

但放在一起看，就会发现它其实已经拼出了一条相当完整的链路。

先读项目

AI 可以先搞清楚项目长什么样：

• XcodeRead
• XcodeLS
• XcodeGlob
• XcodeGrep

也就是说，它可以先知道文件在哪、哪些文件相关、某个类或方法出现在哪里、项目大概怎么组织。

这一步听上去普通，其实很要命。

因为很多 AI 改代码失败，根本不是不会写，而是没先看懂上下文。

再做修改

看明白之后，才进入改动阶段：

• XcodeWrite
• XcodeUpdate
• XcodeMV
• XcodeMakeDir

这类工具最有价值的地方在于，它不是单纯地在磁盘上改文本。

它更像是在 Xcode 项目结构 的语义里动手。

对 Swift / Xcode 项目来说，这比裸文件编辑靠谱很多。

改完就构建

接下来不是“理论上应该可以”。

而是直接：

• BuildProject

也就是，改完就 build。

这一点很重要。

因为它意味着 AI 开始从“建议型工具”往“执行型工具”进化。

只有它真的去构建了，后面的反馈才有价值。

构建失败，就继续看错

如果 build 没过，它还能继续往下走：

• GetBuildLog
• XcodeListNavigatorIssues
• XcodeRefreshCodeIssuesInFile

这部分反而是我最看重的。

因为现实里的开发工作，最常见的情况从来不是“一次改对”。

更常见的是：

• 改完编译不过
• 某个文件 warning 一堆
• package 解析出了问题
• Issue Navigator 里冒出一长串诊断

一个真正能用的 Agent，关键不在于第一次写得多漂亮。

而在于：它能不能看懂失败，并继续修。

最后，跑测试

再往后，它还可以验证结果：

• RunAllTests
• RunSomeTests
• GetTestList

这意味着它的目标，不只是“先不报错”。

而是进一步往“改完之后能验证、能确认”走。

把整条链路串起来，其实就是：读项目 → 改代码 → 构建 → 看错误 → 修复 → 跑测试

这就不是玩具了。

这已经开始像一个真正能工作的开发搭子。

为什么这件事对 Apple 平台尤其重要？

Web 世界这几年已经被各种 AI Coding 工具卷麻了。

编辑器插件、命令行 Agent、云端编程助手，一个比一个能吹。

但 Apple 平台开发一直有个特别现实的问题：Xcode 很强，但它也很封闭。

很多事情都和这些东西深度绑定：

• 工程结构
• scheme
• target
• test plan
• 诊断信息
• Preview
• workspace 配置
• Xcode 里的问题导航

所以你会看到一个很典型的现象：

很多 AI 明明很会写 Swift。

但一旦真正进到 Xcode 这个环境里，立刻开始掉链子。

问题不在“它会不会写代码”。

而在“它能不能参与工作流”。

而这份 Gist 最有意思的地方，就在这里：它展示出来的，不是 AI 更会写代码了，而是 AI 开始有机会真正碰到 Xcode 的内部工作流。

有两个工具，尤其值得多看一眼

ExecuteSnippet：它开始学会验证猜想

这个工具允许在某个文件上下文里执行一段代码片段，然后拿到 print 输出。

这特别像开发者脑子里的真实动作：

• 我先验证一个猜想
• 我想看看这个值到底是不是这样
• 我不想为了试一个点，就把整个项目重跑一遍

如果 Agent 能安全地用这种能力，它的调试效率会高很多。

当然，这种工具的副作用也更强，所以绝对不适合默认一路放开。

RenderPreview：它开始不只是读代码，而是看结果

另一个很有意思的工具是：RenderPreview

它可以构建并渲染 Preview，然后返回 UI 快照。

这对 SwiftUI 来说，意义很大。

因为很多问题根本不是“能不能编译”，而是：

• 间距是不是怪
• 字号是不是顺
• 布局有没有挤
• 深色模式有没有炸
• 状态切换看起来对不对

过去很多 AI 写 UI 的问题就在这里：它只会读代码，不会看结果。

一旦 Preview 真能稳定接进来，事情就会变得很不一样。

因为它开始有机会真正理解：这个界面最后长什么样。

这套 Xcode MCP，值不值得接进工作流？

我的判断很直接：值得。

而且如果你本来就在持续做 iOS / macOS 开发，它不是“有了更好”，而是很可能会明显提升 AI 的可用性。

第一，它补的是最后一公里

很多 AI 已经很会生成代码了。

但真正落到 Xcode 项目上时，常常卡在这些地方：

• 找不准文件
• 改坏工程结构
• 不会看真实编译错误
• 不知道测试怎么跑
• 不知道当前 workspace 到底是什么状态

而这类工具，补的恰恰就是这些坑。

第二，它让 AI 更像执行者，而不只是建议者

不是甩给你一段代码说“你可以试试”。

而是开始变成这样一种工作方式：

• 先查
• 再改
• 再 build
• 再读日志
• 再跑测试
• 再继续修

这和单纯聊天式的 AI，不是一个层级。

第三，它特别适合真实开发里的中小型任务

我反而不觉得它最适合“从零生成一个超复杂 App”。

它最吃香的，应该是这些更真实、也更高频的工作：

• 修一个编译错误
• 改一个页面布局
• 加一个小功能
• 搜一条调用链
• 跑一个失败测试
• 定位一个 SwiftUI 显示异常

这些事情最怕的，就是上下文断裂。

而 Xcode MCP 的意义，就是尽量把这个上下文补起来。

别太早兴奋

该泼冷水还是得泼。

它不能代替产品判断

AI 能 build，不代表它知道这个功能到底该不该这样设计。

工具存在，不等于成熟稳定

Gist 列出来的是能力清单，不是稳定性报告。

能不能在大工程里跑顺，还得看具体实现到底稳不稳。

写操作一定要控权限

像这些工具，本身风险就更高：

• XcodeWrite
• XcodeUpdate
• XcodeMV
• XcodeRM
• ExecuteSnippet

尤其是 XcodeRM。

一个不小心，真可能把工程删坏。

所以正确姿势不是“全开”，而是分层接入。

如果让我来接，我会怎么接？

我的建议是分三层。

第一层：先开放只读 + 构建测试

优先开放这些就已经很够用了：

• 读文件
• 查文件
• 搜代码
• 构建
• 取构建日志
• 看 issues
• 跑测试
• 查 Apple 文档

这一层，已经足够支撑大量分析、排错和验证工作。

第二层：再开放温和写操作

• XcodeUpdate
• XcodeWrite
• XcodeMakeDir
• XcodeMV

这样 Agent 就能做成体系的小范围改动。

第三层：最后再考虑高副作用能力

• XcodeRM
• ExecuteSnippet
• RenderPreview

不是不能开。

而是别默认给它一把电锯就让它满屋跑。

这份 Gist 真正说明了什么？

说到底，这份 Gist 最值得看的，不是那 20 个工具名本身。

而是它背后的方向。

它说明 AI Coding 正在从“文本生成”，一步步走向“工具化执行”。

而在 Apple 开发生态里，这件事尤其关键。

因为一旦 AI 不只是会写 Swift，而是真的能：

• 理解 Xcode 项目结构
• 参与构建
• 消化错误
• 运行测试
• 读取 Preview
• 查官方文档

那它就不再只是一个“帮你补代码的工具”。

它会更像一个真正能协作的开发搭子。

从这个角度看，这份看起来很技术、很冷门的 JSON，其实一点都不无聊。

它像一份还很早期、但方向已经很清楚的信号：AI 正在学会怎么在 Xcode 里工作。

而一旦这件事成熟，iOS / macOS 开发的工作流，大概率会被重写一遍。

---

原始参考：
https://gist.github.com/ethanhuang13/aa486eb3a41d06097c24da633be4070f