《为什么 Codex 还没做出 Codex Design》

导语

宝玉借“为什么 Codex 还不推出类似 Claude Design 的产品”这个问题，区分了 Agent 产品的工程层和模型层。他的核心判断是：可交互设计原型的门槛不在 Harness，而在模型是否能同时完成 UI/UX 设计和系统架构设计。

1. Agent 有两层：产品层 Harness 和模型层

作者先拆开两个常被混在一起的概念：Claude Design、Codex 属于产品层，业内常称为 Harness；Claude Opus 4.8、GPT-5.5 则是模型层，是真正执行推理和生成的大脑。

Harness 像厨房，包含工具、提示词、Skills 和交互流程；模型像厨师，同一套厨房换一个厨师，做出来的结果会完全不同。这个比喻为后文铺垫：如果 Claude Design 效果更好，不能只看产品壳，也要看背后的模型能力。

2. Harness 不是真正门槛，工程上可以复刻

作者认为 Claude Design 的 Harness 层并不神秘。提示词、工具代码和交互流程可以通过逆向分析拿到，他也已经做出 baoyu-design，让 Claude Design 的思路能借助 Skill 在其他模型上运行。

这一步的作用是排除一个误解：Codex 没有类似产品，并不是因为工程团队不会搭界面、不会写工具链。真正拉开差距的是模型是否能稳定理解复杂交互，而不是 Harness 是否有秘密配方。

3. 高精度可交互原型难在“先想清楚系统”

Claude Design 容易被误解成 Figma 或 Photoshop 那样的静态设计稿，但作者强调它交付的是融合设计稿和原型的可交互产品。用户不只是看界面，还能点击、切换、返回，并观察状态是否被保持。

作者用 X/微博客户端举例：静态画一个好看的列表，很多模型都能做到；但一旦要求切换不同 Timeline、展示文本/图片/视频推文、点赞变红心、删除后列表消失、详情页返回后状态保持，就需要模型在画 UI 之前先建立数据结构和状态管理。

这里的难点已经从视觉设计进入系统架构：tweet 的数据结构、timeline 类型、按钮状态、状态联动和页面流转都必须提前想清楚。Claude Design 的优势就在于它同时具备较强的 UI/UX 能力和架构能力。

4. 设计产物本身就是代码，降低设计与开发沟通损耗

作者提醒读者去看 Claude Design 的产出物，尤其是 data.jsx。它会清晰定义设计所需的数据结构，生成模拟数据，再用 React 在这套数据上构建 UI。

这意味着设计交付物不是不可执行的图层文件，而是 React、CSS、JSON 等开发者能直接阅读和迁移的代码。按钮圆角、主色、间距和状态变化都能被代码表达；后续修改也能通过 git diff 看清楚。

在作者看来，AI 设计 Agent 与开发 Agent 之间的沟通损耗正在下降，因为设计正在变成一种结构化、可版本化、可执行的代码产物。

5. 用好 Claude Design：给目标，而不是给过细指令

作者把使用 Claude Design 类比为 Vibe Coding：先给一个基本想法，让它做出第一版，再通过对话不断调整。这个过程的价值不只是产出，而是反馈速度快，能帮助用户更快澄清自己的需求。

他给出的技巧是，不要一开始把要求写得过细，而是告诉 Agent 目标是什么，让它自由发挥。原因是模型已经见过大量公共 UI 设计，过细指令反而可能限制它调用已有设计经验。

6. Codex 的当前短板：模型还扛不住完整交互原型

回到开头的问题，作者的结论是：Codex 不推类似设计产品，是因为 GPT-5.5 还不足以稳定完成这类任务。它可以生成能看的界面，也能做一点简单交互，但与 Claude Design 相比，状态保持、侧边栏点击、点赞反馈等细节往往需要多轮迭代才勉强可用。

真正的差距不是“会不会画界面”，而是能不能在动手前把数据结构、状态管理和交互逻辑一次想完整。目前作者认为只有 Claude 的模型比较稳定地做到这一点，领先能持续多久取决于 OpenAI 和其他模型的进化速度。

思想框架

文章从一个产品疑问切入，先把 Agent 拆成 Harness 和模型两层，再排除 Harness 工程难度这个解释。随后作者用可交互 X 客户端的例子说明，设计 Agent 的本质任务已经包含系统架构：数据结构、状态管理、页面流转和 UI 表达必须一起成立。最后他把 Claude Design 的优势落到“设计即代码”的交付形态，并回到 Codex：短板不是产品壳，而是模型还不能稳定生成完整可交互原型。