最近 AI 圈子几乎都在往 Agent 这件事上卷。 大厂在卷模型、卷基础设施、卷平台能力，小团队没那么多资源，反而更应该把注意力放在另一件更现实的事情上：

怎么把现成的 AI 工具接起来，变成一条真能提升交付效率的工作流。

这段时间我们内部也在折腾这件事。最直观的感受是，AI 已经不只是“帮你写点代码”或者“帮你画个原型”了，而是开始往产品定义、UI 设计、工程搭建、细节迭代这一整条链路里渗透。

尤其是当我看到非技术背景的人，已经能借助 Codex 这类工具，把一个产品从想法一路推到可交付状态时，冲击还是挺大的。 虽然这里面当然还有很多边界，也远没到“一个工具包打天下”的程度，但有一点已经很明确了：

软件交付的门槛，确实在变薄。

这篇就不谈太大的趋势判断，直接讲一个更实用的点：
怎么在 Codex 里接入 Stitch MCP，让设计和实现真正串起来。

一、为什么是 Stitch MCP

现在 AI 设计工具很多，但真正想往工程化落地上走，光能生成界面图还不够。 更关键的是：

• 设计资产能不能被程序访问
• 项目信息能不能被 AI 读取
• 页面能不能继续被 AI 编辑和扩展
• 最终能不能和你的代码仓库接起来

Stitch 比较有意思的地方就在这里。 它不只是一个“帮你出几张效果图”的工具，而是把项目、屏幕、设计系统这些能力，通过 MCP 暴露出来了。

也就是说，当 Codex 能连上 Stitch 之后，它看到的就不再只是几张静态截图，而是一个可访问、可操作的设计上下文。

这一步的意义其实很大。

因为从这时候开始，AI 编码工具和 AI 设计工具之间，不再是“两套各干各的系统”，而是可以真正协作起来。

二、Codex 其实也能接 Stitch，只是官方没直接写

Stitch 官方文档里给了不少 AI 工具的接入说明，比如 Claude Code、Gemini 之类，但没有直接写 Codex CLI。

一开始看上去像是不支持，实际上不是。

原因很简单：MCP 是通用协议。

只要 Codex 这边支持 MCP client，那理论上就可以接 Stitch。 所以这件事本质上不是“能不能接”，而是“怎么配”。

我这里用的是 API Key 方式授权，配置起来相对直接，也更适合自己本地先跑通。

三、先改 Codex 的全局配置

先找到 Codex 的全局配置文件：

~/.codex/config.toml

我本地的配置大致像这样：

personality = "pragmatic"

model = "gpt-5.4"

model_reasoning_effort = "medium"

experimental_use_rmcp_client = true

[features]
skills = true

[[skills.config]]
path = "~/.codex/skills"
enabled = true

[projects."/Users/kk/Documents/MiniProgram/AIProjects"]
trust_level = "untrusted"

[projects."/Users/kk/Documents/Private/Site"]
trust_level = "untrusted"

这里面真正和 Stitch MCP 相关的关键点，是：

experimental_use_rmcp_client = true

没有这类 MCP client 能力开关的话，后面 Stitch 服务就算配上了，也不会真正被 Codex 接起来。

四、去 Stitch 里拿 API Key

接下来去 Stitch 的设置页面，生成自己的 API Key。

拿到之后，把它补进 Codex 配置文件里：

[mcp_servers.stitch]
url = "https://stitch.googleapis.com/mcp"

[mcp_servers.stitch.http_headers]
X-Goog-Api-Key = "你的 Stitch API Key"

配完之后，整个配置大致会变成这样：

这一步其实没什么花活，重点就两件事：

• MCP Server 地址写对
• Header 里的 X-Goog-Api-Key 带上

如果你不是用 API Key，而是后面 Stitch 支持了别的鉴权方式，思路也类似，本质上还是给 Codex 一个能访问 Stitch MCP 的入口。

五、重启 Codex，确认 Stitch MCP 已经挂上来

配置完成后，重启 Codex。

然后查看当前可用的 MCP 服务列表，如果配置正确，就能看到 stitch。

走到这里，其实就已经打通了。

后面你在 Codex 里做的事情，不再只是“让它帮你写代码”，而是可以让它直接去读取 Stitch 上的项目、页面和设计信息，再结合你的本地工程继续往下干。

六、接上之后，真正有价值的用法是什么

很多人第一次接这类能力，最先想到的是：

“那我是不是可以直接让 AI 把设计稿还原成代码了？”

答案是：可以，但不要只停在这个层面。

如果只是让它对着设计图写一个静态页面，那价值其实并没有拉满。 我觉得更有意义的用法，是把它放进一条更完整的交付链路里：

• Stitch 提供项目和 UI/UX 设计上下文
• Codex 读取本地仓库、需求文档和工程约束
• AI 一边参考设计，一边搭实际项目结构
• 后续再进入细节打磨和功能补全

这时候 Stitch 就不再只是“出图工具”，而更像是 AI Coding 的设计输入源。

七、我现在是怎么用它的

比如最简单的第一步，可以先让 Codex 去读 Stitch 上的项目信息：

请告诉我我 Stitch 上的项目列表

这一步的价值看起来不大，但它其实是在确认一件事：

Codex 已经不只是在本地文件夹里工作了，它开始具备访问设计空间的能力。

更进一步，我会直接把设计和需求文档一起交给它，比如：

使用 Stitch 上“语音口算训练营”的 UI/UX 设计，同时结合我的功能说明文档 docs/requirements.md，来完成项目的搭建和功能的实现。如果有新的页面添加，设计风格参考 DESIGN.md。

方案采用：
1. Vue 3 + Vite + script setup
2. 样式体系：scoped css / scss / tailwindcss
3. 组件拆分粒度：页面级、区块级、卡片级
4. 保真还原的同时，注意组件的提取和划分

这里我比较看重的，不是“它一次性能不能完美生成”，而是它终于有了同时理解这几类信息的能力：

• 设计长什么样
• 产品需求是什么
• 技术栈怎么选
• 代码组织怎么约束

也就是说，AI 开始拿到的是一个更接近真实工程环境的输入，而不是一张图加一句“帮我还原”。

八、效果怎么样

Stitch 上的设计大概是这样：

最终让 Codex 结合工程约束去实现后，效果能比较快地落到这个程度：

如果只看第一轮结果，我的评价是：

风格能对上，结构也能搭起来，但保真度通常还差最后那一截。

这很正常。

因为从“设计上下文可访问”到“高保真工程实现”，中间本来就还隔着不少事情，比如：

• 组件抽象是否合理
• 布局细节是否精确
• 状态交互是否补全
• 字体、间距、动效有没有还原到位
• 工程代码是不是足够可维护

所以我现在更愿意把这套链路理解成：

Stitch MCP 负责把设计送进 Codex，Codex 负责把工程骨架和第一轮实现拉起来，最后再进入真正的 vibe coding 和细节修正阶段。

这个过程很像多了一个不会嫌烦的初级到中级实现层，把原来最耗时间的“搭骨架、对风格、补页面”先干掉一大半。

九、这件事真正改变的，不只是效率

我觉得它更重要的地方，不只是“省时间”，而是把设计和开发之间那道原本很硬的墙，往下推了一截。

以前常见的情况是：

• 设计在设计工具里
• 需求在文档里
• 开发在 IDE 里
• 最后靠人脑来回翻译

现在 MCP 这类协议把工具之间的缝接上之后，AI 能开始同时理解这些上下文，工作方式就变了。

它不一定一步到位，也不一定每次都做得漂亮，但它确实在把交付链路改造成一种新的形态：

设计不再只是给人看的，需求不再只是给人读的，代码也不再只能由人亲手一行一行敲出来。

对于技术人员来说，这不代表工程能力不重要了，反而意味着要求更高了。

因为后面真正有价值的能力，越来越像是：

• 你能不能把约束讲清楚
• 你能不能把上下文组织好
• 你能不能让 AI 在正确的环境里工作
• 你能不能判断它生成的结果哪些能用，哪些必须重做

说白了，门槛没有消失，只是位置变了。

十、最后

如果你本来就在用 Codex，又正好在找一条把 AI 设计工具和 AI 编码工具串起来的路，那 Stitch MCP 确实值得接一下。

它最大的意义，不是“又多了一个能连的服务”，而是让从设计到实现这段原本很割裂的流程，开始变得连续起来。

至少在我现在的使用里，它已经不是一个“看起来很酷”的演示能力，而是能实际参与工程交付的东西了。

当然，也别把它神化。

它还不能代替你做所有判断，也还做不到把设计稿百分百自动变成高质量工程代码。 但如果只是问一句：

它有没有把从 UI 设计到项目落地这条链路，往前推进一大步？

我的答案是：有，而且很明显。