Concise Summary简洁概述
Claude Design's edge over a hypothetical 'Codex Design' isn't the harness (prompts/tools/UI flow, which is easily reverse-engineered) — it's that Claude Opus 4.8 alone can simultaneously handle UI/UX design and system-architecture reasoning (data structures, state management) needed for a fully interactive prototype.
The author demonstrates this with a Mac Twitter-client prompt: Claude Design produces smooth, stateful interactions end-to-end, while the same prompt on Codex yields a static-looking shell with broken buttons and non-scrolling sidebars.
Claude Design 相较假想中「Codex Design」的优势不在 Harness(提示词、工具链可被逆向复制),而在于目前只有 Claude Opus 4.8 能同时胜任 UI/UX 设计与系统架构推理(数据结构、状态管理),才能交付真正可交互的原型。
作者用「做一个 Mac 版 Twitter 客户端」的提示词做对比:Claude Design 一次性给出流畅、状态一致的交互,而同样提示词在 Codex 上只能得到按钮无反应、侧边栏不可点的半成品。
Infographic信息图
Kitchen vs. chef analogy
厨房与厨师的比喻
Harness (prompts, tools, UI flow) is the kitchen; the model is the chef. Same kitchen, different chef, wildly different dish — this reframes 'why can't Codex copy this' as a model question, not an engineering one.
Harness(提示词、工具链、交互流程)是厨房,模型是厨师。同一套厨房换个厨师,菜完全不一样——这把「Codex 为何做不出来」从工程问题重新定位成了模型能力问题。
Architecture before pixels
先架构,后画面
A convincing interactive prototype requires the model to define data structures and state transitions (tweet shape, timeline types, like/delete states) before drawing any UI — this is system design work, not visual design work.
要做出可信的可交互原型,模型必须先定义好数据结构和状态流转(tweet 结构、timeline 类型、点赞/删除状态),再动手画界面——这是系统架构的活,不是视觉设计的活。
Design output is code
设计产物即代码
Claude Design ships React/CSS/JSON (e.g. data.jsx), not Figma files — developers can read spacing/colors directly and diff changes with git, collapsing the designer-developer handoff loss.
Claude Design 交付的是 React/CSS/JSON(如 data.jsx),而非 Figma 文件——开发者可直接读出间距、颜色,用 git diff 追踪变更,设计到开发的沟通损耗被压到最低。
Vague goals beat detailed specs
目标导向优于具体指令
The author's usage tip: state the goal, not exact specs, and iterate via chat — because the model has absorbed nearly all public UI patterns and often free-associates better solutions than a literal brief.
作者的使用心得:说目标而非具体要求,靠对话反复调整——因为模型见过几乎所有公开 UI 模式,自由发挥往往比字面指令给出更好的结果。
Detailed Summary详细解读
The article opens by dismantling a common conflation: people talk about 'Codex vs. Claude Design' as if comparing products, but really they're comparing GPT-5.5 against Claude Opus 4.8 through a thin product wrapper. The author separates 'agent' into two layers — harness (prompts, tool orchestration, UI/UX flow, i.e. product engineering) and model (the reasoning core) — using a kitchen/chef metaphor: same tools and recipes, different chef, wildly different results. This framing matters because it redirects the reader's attention from 'why hasn't OpenAI shipped this product' to 'can GPT-5.5 do this task at all,' which is the actual bottleneck the piece investigates.
Next, the author de-mystifies the harness: he claims to have fully reverse-engineered Claude Design's prompts and tool code into an open project (baoyu-design), implying the engineering layer holds no real secrets. This is a strong, falsifiable claim — it shifts the entire burden of explanation onto the model layer, setting up the piece's central thesis that Anthropic's advantage is not IP-protected tooling but raw model capability.
The core technical argument follows: building a high-fidelity *interactive* prototype (not a static mockup) requires the model to solve a systems-design problem before touching pixels — defining a tweet's data shape, enumerating timeline variants, tracking per-button state, and wiring state transitions (like → filled heart, delete → item vanishes, detail view → back preserves scroll position). The author's key insight is that this is architecture work disguised as design work, and most models are good at one but not both.
Empirical support comes from a concrete side-by-side test: the same prompt ('Design a Mac X client like Tweetbot') fed to both systems. Claude Design produces persistent state across navigation (timeline↔notifications↔detail), while Codex's output has non-scrolling sidebars and unresponsive like buttons, requiring many manual correction rounds to reach mediocrity. This is the piece's strongest evidence, though it rests on a single anecdotal trial rather than a systematic benchmark.
The piece then pivots to output format: Claude Design's deliverable is literal source code (React components, CSS, a data.jsx defining the data model), not Figma/PSD files. This means any developer can read the exact border-radius, colors, and spacing directly, and future design changes are trackable via git diff — collapsing the traditional handoff friction between designers and engineers into something closer to two AI agents (design agent, dev agent) coordinating through code as a shared language.
The piece closes with a practical usage tip (state goals, not exact specs, and iterate conversationally — the model has absorbed near-comprehensive public UI patterns) and a forward-looking, appropriately hedged conclusion: OpenAI could close this gap once a future model matches Opus 4.8's combined design+architecture competence — the advantage is a training/capability lead, not a structural moat.
文章开篇先拆解一个常见的混淆:大家谈论「Codex vs. Claude Design」时,实际是把 GPT-5.5 和 Claude Opus 4.8 透过一层薄薄的产品包装在比较。作者把「Agent」拆成两层——Harness(提示词、工具编排、UI/UX 流程,即产品工程)与模型(真正的推理内核)——用厨房与厨师的类比说明:同样的锅碗瓢盆和菜谱,换个厨师做出来天差地别。这个框架很关键,它把读者的注意力从「OpenAI 为什么还没推出这个产品」引向「GPT-5.5 到底能不能干这活」,这才是文章真正要探讨的瓶颈。
接着作者揭开 Harness 的神秘面纱:他称已经把 Claude Design 的提示词和工具代码完整逆向,做成了开源项目 baoyu-design,暗示工程层其实没有什么秘密。这是一个很硬、可证伪的论断——它把解释的全部重量都压到了模型层,为文章的核心论点铺路:Anthropic 的优势不是受保护的工具链,而是赤裸裸的模型能力。
核心技术论点随之展开:构建高精度的*可交互*原型(而非静态 mockup)要求模型在动手画像素之前先解决一个系统设计问题——定义 tweet 的数据结构、列出 timeline 的种类、追踪每个按钮的状态、并串联好状态转移(点赞→变实心红心,删除→项目消失,进详情再返回→滚动位置要保持)。作者的关键洞察是:这本质是伪装成设计工作的架构工作,而多数模型只擅长其中一项,不能两者兼顾。
实证支持来自一次具体的对比测试:同一提示词(「做一个类似 Tweetbot 的 Mac 版 X 客户端」)分别喂给两个系统。Claude Design 在 timeline↔通知↔详情页之间跳转时状态始终保持,而 Codex 的产出侧边栏无法点击、点赞按钮没反应,要反复修正多轮才勉强凑合。这是全文最有力的证据,但它建立在一次轶事性试验上,而非系统化的基准测试。
文章随后转向产出形式:Claude Design 交付的是真正的源代码(React 组件、CSS、定义数据模型的 data.jsx),而非 Figma 或 PSD 文件。这意味着任何开发者都能直接读出精确的圆角、颜色、间距,未来的设计变更也能靠 git diff 追踪——把设计师与工程师之间传统的交接摩擦,压缩成了设计 Agent 与开发 Agent 之间以代码为共同语言的协作。
结尾给出实用建议(说目标而非具体要求,靠对话反复调整——模型几乎见过所有公开 UI 模式)和一个留有余地的展望:一旦未来某个模型在设计+架构能力上追平 Opus 4.8,OpenAI 完全可能补齐这道差距——这是训练/能力领先,而非结构性护城河。
FAQ常见问答
Is the harness (prompts/tools) really irrelevant, as the author claims?Harness(提示词/工具)真的像作者说的那么不重要吗?
Mostly, per the author's own reverse-engineering into baoyu-design — but this is a self-reported, unverified claim; some prompt-engineering nuance could still matter at the margins even if not decisive.
基本如此,依据是作者自称已逆向复现为 baoyu-design 项目——但这是未经第三方核实的自我陈述,边际上提示词工程的细节仍可能有影响,只是不是决定性的。
Why can't a static-UI model just be prompted harder to add interactivity?为什么不能靠加强提示词让只会画静态界面的模型也变得可交互?
Because interactivity requires upfront data-structure and state-machine design (tweet schema, timeline variants, per-button state), which is a systems-architecture skill separate from visual UI generation — prompting alone can't substitute for that reasoning capability.
因为可交互性要求提前设计好数据结构和状态机(tweet 结构、timeline 变体、按钮状态),这是独立于视觉 UI 生成的系统架构能力——单靠提示词无法替代这种推理能力。
How strong is the Codex-vs-Claude Design comparison evidence?Codex 与 Claude Design 的对比证据有多可靠?
It's a single anecdotal test (one prompt, one app type) by the author, not a controlled benchmark across many prompts or app categories — suggestive but not rigorous proof of a systemic gap.
它只是作者做的一次轶事性测试(一个提示词、一种 App 类型),并非跨多种提示词和应用类型的受控基准测试——具有启发性,但不足以严格证明存在系统性差距。
Does 'design output as code' actually eliminate designer-developer friction?「设计产物即代码」真的能消除设计师与开发者之间的摩擦吗?
It reduces translation loss for spacing/colors/component structure, but doesn't address brand consistency, accessibility review, or design-system governance — those still need human or separate-agent oversight.
它减少了间距、颜色、组件结构方面的转译损耗,但没有解决品牌一致性、无障碍审查或设计系统治理问题——这些仍需人工或其他 Agent 把关。
Will OpenAI likely close this gap soon?OpenAI 会很快补上这道差距吗?
The author leaves this open, framing it as dependent on GPT's training roadmap for combined design+architecture reasoning — no timeline is claimed, and the piece is explicit this is speculative.
作者对此持开放态度,认为取决于 GPT 后续训练是否补上设计+架构综合推理能力——没有给出具体时间线,文章明确表示这只是推测。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece uses the Codex-vs-Claude-Design gap to draw a sharp line between the 'harness' (product engineering layer) and the underlying model, arguing the gap is almost entirely a model-capability story.
这篇文章借「Codex 为何做不出 Claude Design」这个问题,划清了 Harness(产品工程层)与底层模型之间的界限,论证这道差距几乎完全是模型能力问题。
- Sharp conceptual framing框架清晰锐利The harness/model two-layer distinction, backed by the kitchen/chef analogy, cleanly resolves a genuinely confusing public debate and is reusable for analyzing other agent-product comparisons.Harness/模型两层区分,配合厨房/厨师类比,干净利落地解答了一个真实存在的公众困惑,且这个框架可复用于分析其他 Agent 产品对比。
- Falsifiable, hands-on claim可验证的实证主张The author didn't just assert the harness is copyable — he built and open-sourced baoyu-design as proof, giving readers something concrete to check rather than taking his word for it.作者没有空口断言 Harness 可复制,而是真的做出并开源了 baoyu-design 作为证明,让读者有具体东西可核实,而非只能听信一面之词。
- Concrete, replicable test case具体可复现的测试案例Giving the exact prompt used (Mac X client like Tweetbot) lets any reader independently verify the Codex vs. Claude Design gap rather than trusting a vague impression.给出确切的测试提示词(类似 Tweetbot 的 Mac X 客户端),使任何读者都能自行验证 Codex 与 Claude Design 的差距,而不必只信任一个模糊印象。
- Practical usage advice included附带可操作的使用建议Beyond diagnosis, the piece offers an actionable workflow tip (goal-first prompting, iterative chat refinement) that readers can apply immediately, not just theory.文章不只是诊断问题,还给出了可立即应用的工作流建议(目标导向式提示、对话式迭代打磨),而不只是停留在理论层面。
- Single anecdotal comparison仅一次轶事性对比The Codex-vs-Claude Design gap rests on one prompt and one app category tested by the author alone; no systematic multi-prompt benchmark or third-party replication is cited.Codex 与 Claude Design 的差距结论仅基于作者一人做的一个提示词、一种应用类型的测试,没有引用系统化的多提示词基准测试或第三方复现。
- No mention of prompt/tool version drift未考虑版本迭代因素GPT-5.5 and Codex's harness are moving targets; the piece doesn't specify test dates or versions precisely enough for readers to know if the gap still holds after subsequent updates.GPT-5.5 和 Codex 的 Harness 都在持续更新,文章没有精确说明测试的具体版本和日期,读者难以判断后续更新后差距是否依然成立。
- Harness claim not independently verifiedHarness 主张未经第三方验证The assertion that baoyu-design fully replicates Claude Design's harness is self-reported; readers can't tell from the article alone whether subtle harness details (e.g. specific tool sequencing) were missed.baoyu-design 完整复现了 Claude Design 的 Harness 这一说法是作者自述,仅凭文章本身,读者无法判断是否遗漏了某些细微的 Harness 细节(如具体的工具调用顺序)。
- Overlooks cost and latency trade-offs忽略了成本与延迟权衡The piece focuses entirely on output quality but says nothing about inference cost, generation latency, or context-window limits, which matter for whether this capability is practical to productize at scale.文章完全聚焦于产出质量,只字未提推理成本、生成延迟或上下文窗口限制,而这些都关系到这项能力能否规模化落地为产品。
A sharp, well-argued explainer for anyone puzzled by why Claude Design has no Codex equivalent — read it for the harness/model framework, but treat the head-to-head comparison as one data point, not a rigorous benchmark, and expect the gap to narrow as competing models catch up on combined design+architecture reasoning.
对任何好奇「Claude Design 为何没有 Codex 版」的人来说,这是一篇框架清晰、论证扎实的解读——值得读它的 Harness/模型二分框架,但对比测试本身只是一个数据点而非严谨基准,且随着其他模型补齐设计+架构综合推理能力,这道差距很可能会缩小。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
Why hasn't Codex launched a product like Claude Design yet?
Anthropic recently launched Claude Design, and besides coding it's the agent I use most and have recommended many times. It's genuinely impressive: describe the app you want in one sentence, and it directly generates an interactive prototype where every click responds — if you don't look closely, you'd think you were operating a real app.
A reader asked: why hasn't Codex launched something like Codex Design yet?
Simply put, GPT-5.5's model capability isn't there yet. But to explain why clearly, you first need to understand a key distinction.
The two layers of an agent: model and harness
Many people lump Codex, Claude Design, GPT-5.5, and Claude Opus 4.8 together, but they're actually two completely different layers.
Claude Design and Codex are the "product layer," what the industry calls the harness — prompts, toolchains, UI interaction flows, all engineering-level stuff. Claude Opus 4.8 and GPT-5.5 are the "model layer," the brain that actually does the work.
An analogy: the harness is the kitchen, with pots and pans (tools) and recipes (skills); the model is the chef. Swap the chef in the same kitchen and the dishes turn out completely different.
Once you understand this distinction, everything that follows makes sense.
The harness isn't the barrier
The harness layer of Claude Design isn't technically complex. With a bit of effort you can reverse-engineer it — the prompts and tool code are almost all obtainable. I've already done this; the result is baoyu-design (https://github.com/JimLiu/baoyu-design), which lets you run Claude Design's skill on other models. There's no secret on the engineering side.
What really creates the gap is the model behind it.
High-fidelity interactive prototypes are hard because of the model
The name "Claude Design" is easy to misunderstand — people assume it delivers static design images like Figma or Photoshop. In fact what it delivers goes further than Figma: a high-fidelity interactive prototype that merges the design and the prototype — you don't just see the design, you can directly operate it.
This demands a lot from the model.
Here's an example. Say I want to build a client similar to X/Weibo. Getting a model to draw a nice-looking static interface — many models can do that. But making that interface interactive is far more complex: switching between different timelines, displaying different types of tweets (text, images, video), turning the heart red on a like, removing a deleted tweet from the list, clicking into a detail view from the list and back while preserving state.
To pull this off, the model has to think through the entire data structure and state management before it even starts drawing the UI: what a tweet looks like, how many kinds of timelines there are, what state each button is currently in, how the states link together. This is systems architecture work, not UI-drawing work.
What Claude Design demands of a model is excellent UI/UX design ability combined with systems architecture design ability at the same time — missing either one and the result suffers badly. This is also why I've previously argued against producing plain HTML mockups alone — that's just static UI design, without UX interaction baked in.
If you're able to, try testing it yourself and see how it feels. For example, use this prompt:
Design a X Client for Mac, similar to Tweetbot for Mac from Tapbots
Giving the same prompt to Codex also produces something — viewable, and simply interactive. But comparing the two reveals the gap: the list scrolls, but the sidebar isn't clickable; the like button doesn't respond. It takes several rounds of back-and-forth iteration to reach a barely passable level.
What Claude Design produces is completely different. Switching from the timeline to the notifications page, clicking into details from a list and back — it's smooth throughout, and state is preserved the whole time. If you don't look closely, you'd really think you were operating a highly polished app, even though all the data is mocked.
Claude Opus 4.8 has clearly undergone extensive training and optimization for scenarios like this involving design and architecture.
The output is code itself
Look at what Claude Design produces, and pay attention to the data.jsx file inside it. It defines the entire design's data structure very clearly, mocks up a complete dataset based on that structure, and then builds the UI on top of that data using React.
The design output itself is code (React, CSS, JSON), not Figma or PSD files — any developer who gets it can immediately see the button's corner radius, the primary color, the spacing, and implement it directly in their own stack. A later design change? A quick git diff shows exactly what changed. The communication overhead between design and development is reduced to a minimum.
To put it more precisely, the communication overhead between the design agent and the development agent is now very low. Nowadays it's a human directing an agent to design, and a human directing an agent to write code.
How to make the most of Claude Design
Many people don't know how to use Claude Design well. It's actually a bit like vibe coding: you have a basic idea, let it produce a first version, then use chat to direct the agent to help you revise it — after a few adjusted versions, your own thinking becomes clear.
The whole adjustment process is remarkably magical, with a kind of "speak and it shall be done" feeling — however you want it changed, it can pretty much deliver. That's also why I'm so hooked on Claude Design right now — the feedback loop is so fast it's addictive.
Here's one more small tip: don't state overly specific requirements — instead, state your goal, what you're aiming for, and let it improvise freely. This often produces better results, since it has been trained on nearly all publicly available UI designs.
Back to the original question. Codex hasn't launched a similar design product because GPT-5.5 still can't handle this work. Many models can draw a good-looking interface, but the hard part is thinking through the data structure, state management, and interaction logic before you even start, then delivering a complete, interactive prototype in one shot.
Right now, only Claude's models can do this. As for how long the lead will last, it depends on how fast OpenAI's or other companies' future models evolve.
为啥 Codex 还不推出类似 Codex Design 的产品?
Anthropic 最近推出了 Claude Design,是我除了编程之外用得最多的 Agent,也推荐过很多次。效果真的好:你用一句话描述想要的 App,它直接给你生成一个可交互的原型,点哪哪都有反应,不仔细看还以为在操作真实的 App。
有网友问:为啥 Codex 还不推出类似 Codex Design 的产品?
简单来说,GPT-5.5 的模型能力还做不好这件事。但要解释清楚为什么,得先理解一个关键区分。
【1】Agent 的两层:模型和 Harness
很多人把 Codex、Claude Design 和 GPT-5.5、Claude Opus 4.8 混在一起说,其实它们是完全不同的两层。
Claude Design 和 Codex 是"产品层",业界叫 Harness,包括提示词、工具链、UI 交互流程这些工程层面的东西。Claude Opus 4.8 和 GPT-5.5 是"模型层",是真正干活的大脑。
打个比方:Harness 是厨房,里面有锅碗瓢盆(工具)和菜谱(Skills),模型是厨师。同一套厨房,换个厨师,做出来的菜完全不一样。
理解了这个区分,后面的事情就好说了。
【2】Harness 不是门槛
Claude Design 的 Harness 层技术上不复杂。花点心思逆向一下,提示词、工具代码几乎都可以拿到。我已经做过了,成果在 baoyu-design(https://github.com/JimLiu/baoyu-design),可以借助 Skill 把 Claude Design 在其他模型上运行。工程上没秘密。
真正拉开差距的是背后的模型。
【3】高精度可交互原型,难在模型
Claude Design 这个名字容易让人误解,以为交付的是 Figma、Photoshop 那样的静态设计图。实际上它交付的比 Figma 更进一步,是融合了设计稿和原型的高精度可交互原型:你不光能看到设计,还能直接上手操作。
这对模型的要求很高。
举个例子。我要做一个类似 X/微博的客户端。让模型画一个好看的静态界面,很多模型都做得到。但要让这个界面能交互就复杂了:切换不同 Timeline,展示不同类型的推文(文本、图片、视频),点赞要变红心,删推要从列表消失,从列表点进详情再返回,状态还要保持住。
要做到这些,模型必须在动手画 UI 之前,先把整套数据结构和状态管理想清楚:tweet 长什么样、timeline 有哪几种、每个按钮当前是什么状态、状态之间怎么联动。这是系统架构设计的活,不是画 UI 的活。
Claude Design 对模型的要求,是同时具备优秀的 UI/UX 设计能力和系统架构设计能力,缺一个效果就大打折扣。这也是为什么我之前反对只产出纯 HTML 的设计稿,那只是静态的 UI 设计,没有融合 UX 交互。
有条件的话可以自己测试感受一下。比如用这个提示词:
Design a X Client for Mac, similar to Tweetbot for Mac from Tapbots
同样的提示词让 Codex 去做,也能出个东西,能看,也能简单交互。但对比一下就知道差距了:列表能滚动,sidebar 不能点;点赞按钮没反应。来回迭代好几轮,才能达到一个勉强凑合的水平。
Claude Design 做出来完全不一样。从 Timeline 切到通知页,从列表点进详情再返回,全程流畅,状态都保持住了。不仔细看真以为在操作一个完成度很高的 App,虽然数据都是模拟的。
Claude Opus 4.8 显然在设计和架构这类场景上做了大量训练和优化。
【4】产出物就是代码
去看 Claude Design 的产出物,注意里面的 data.jsx 文件。它把整个设计的数据结构定义得很清晰,基于这个结构模拟了一套完整数据,然后用 React 在这套数据上构建 UI。
设计产物本身就是代码(React、CSS、JSON),不是 Figma 或 PSD,任何开发者拿到都能直接看出按钮的圆角、主色、间距,照着自己的技术栈实现就行。后续设计变更?git diff 一看就知道改了什么。设计和开发之间的沟通损耗降到了最低。
说得不严谨,应该说设计 Agent 和开发 Agent 之间的沟通损耗很低了。现在都是人在指挥 Agent 去设计,人指挥 Agent 写代码了。
【5】怎么用好 Claude Design
很多人不知道该怎么用好 Claude Design,其实有点像 Vibe Coding:有个基本的想法,先让它做一个版本出来,然后通过 Chat 去指挥 Agent 帮你改,调整几个版本你的思路就清晰了。
整个调整的过程非常神奇,有一种"言出法随"的感觉,你想让它怎么改它总能给你实现出来。这也是为啥我现在很痴迷用 Claude Design,反馈来得太快太过瘾了。
还有一个小技巧:不要说太具体的要求,而是说你的目标是想要什么,让它自由发挥。往往能得到更好的效果,毕竟它训练过几乎所有公共的 UI 设计。
回到最初的问题。Codex 不推类似的设计产品,是因为 GPT-5.5 还扛不住这个活。画个好看的界面很多模型都行,难的是在动手之前把数据结构、状态管理、交互逻辑都想清楚,然后一次性交付一个完整的可交互原型。
目前只有 Claude 的模型做到了。至于能领先多久,就看 OpenAI 或者其他家后面模型的进化速度了。
See all posts