Peter Yang：ChatGPT 生 UI、Codex 写代码，图生 App 是制胜组合——但开发者不买账

一条推文，两种声音，56000 次围观

"1. Get ChatGPT images to generate beautiful app UI. 2. /goal (attach image) make it look like this. ^ seems like a winning combo."

7 月 23 日，Peter Yang 在 X 上写下这两行字。24 小时内，这条推文被浏览了 56000 次，收获 518 个赞、51 条回复和 415 个书签。点赞数说明很多人觉得他说到了点上。回复区的激烈辩论则说明，远不是所有人都同意。

这条推文的杀伤力在于它把两个 OpenAI 产品拼成了一条极简流水线：先用 ChatGPT 的图像生成画一张漂亮的 App UI，再把这张图扔给 Codex 的 /goal 命令，让它照着做出来。设计→开发，两个步骤，一个闭环。如果它真的可靠，这意味着什么？意味着产品原型不再需要设计师出图、前端手写 CSS、工程师对着 Figma 量像素。一张 AI 生成的截图就够了。

问题是，它并没有那么可靠。

发帖的 Peter Yang，不只是个 AI 博主

Peter Yang 不是一个普通的 AI 博主。他在 Roblox 做过产品负责人，在 Reddit 把一个新产品从 0 做到了 100 万用户，在 Meta 管过 Facebook Live 的产品团队，还在 Twitch 发明了 Raids 功能。今天你在任何一个直播间看到的"主播下线后自动跳转到下一个直播间"，就是他十年前做的。

2026 年，Yang 离开了大厂，全职做一个 AI 教育者。他的 Substack newsletter 有超过 14 万订阅，Maven 上的 AI 产品经理课程期期爆满，X 账号有 24.8 万关注者。他的内容定位很清晰：给忙人看的实用 AI 教程。不做宏大叙事，不写行业预言，只告诉你"用这个工具做这件事，三步搞定"。

所以当他发推说某个工作流是 "winning combo" 时，人们会认真听。不是因为他有内部消息，而是因为他用过几乎所有工具，试过几乎所有组合，最后选出了自己认为最好的那个。这条推文本质上是一条生产力笔记。只不过恰好碰上了 GPT-5.6 和统一版 ChatGPT 刚上线一周的时间窗口。

画设计稿交给 ChatGPT，实现设计稿交给 Codex

Yang 的流程只有两步，但每步背后都有一个值得拆解的能力。

第一步：用 ChatGPT 的图像生成画 UI。GPT-5.6 的图像生成能力在 7 月的这次统一版更新中得到了显著提升，尤其是在理解结构化布局方面。用户不需要给出像素级指令，只需要描述"一个社交 App 的个人主页，顶部是头像和简介，中间是动态流，底部是导航栏"，ChatGPT 就能输出一张看起来像真 App 截图的 UI 设计稿。

这一步的价值在于，ChatGPT 生成的不是随便一张好看的图，而是有信息密度的 UI——组件之间有层级关系，配色有一致性，布局符合平台规范。它生成的图自带了一份隐式的设计 spec。用 Yang 自己的话说，"beautiful app UI"（注意他用了 beautiful 而不是 functional）。画得好看是第一步，能不能用是第二步。

第二步：把这张图喂给 Codex 的 /goal 命令。/goal 是 Codex CLI 中的一条核心指令，它把一个高层的完成目标挂在当前会话上，Codex 会持续规划、执行、检查、纠错，直到目标达成或资源耗尽。OpenAI 开发者文档里用一句话概括了它的思维模型："prompt 是'做下一件事'，goal 是'一直干到这件事成真'"。在 full-auto 模式下，/goal 可以连续运行数小时，自动创建文件、安装依赖、运行测试、修复报错，然后重新运行测试，形成一个完整的自校正循环。

Yang 的用法很巧妙：/goal make it look like this（附上 ChatGPT 生成的 UI 图）。Codex 拿到这张图后，会自己拆解布局、推断组件树、选择技术栈、生成代码、在浏览器中预览结果，并与原图对比。如果不满意，继续迭代。N DIVIJ，一个在 Codex CLI 里用过类似流程的开发者，在引用推特里写道："我用 imagegen 插件在 Codex CLI 里试过这个流程，那一刻我感觉自己成了 S 级的视觉设计师。"

但这个评价恰恰暴露了问题：觉得自己像设计师，和真的产出了能用设计，是两回事。

"最终成品连图片的 40% 都不到"

问题在于，甜区理论在实战中并不总是成立。

Yashasvi Shailly 的回复获得了高赞："我试过用这个方法做网页，最终成品连图片的 40% 都不到。" Jarrod Watts，Monad 的 Lead AI Engineer、3 万关注者，回复更直接："在我这儿从来没好用过。Claude 画设计→扔给 Claude Code 实现，这个组合才真的好用。" Monad 是悉尼一家做 AI agent 基础设施的创业公司，Watts 每天都在跟 agent 工具打交道。他说不好用，不是随口一说。

Jonny Gravity 点出了症结："GPT 生成的 UI 确实好看，但它在迭代上烂透了。你最好一次就生成对。" 这句话揭示了整个流程的脆弱点：ChatGPT 的图像生成在"从零画一张好看的图"上很强，但在"根据反馈修改图上的某个细节"上很弱。而 /goal 命令虽然能自我纠错，但在视觉匹配这个维度上，它没有像素级对比的能力。它只能"觉得"像不像，不能精确测量像不像。

Christine Yip 的评论则从另一个角度提出了质疑："还有人用 /goal 吗？有了 Fable 和 GPT-5.6 Sol 之后，好像已经不需要了。" Yip 是 Superlinear FM 的联合主持人、前 Ensue AI 联合创始人，接近 5000 关注者。她的言下之意是：如果你的模型本身就足够强，强到能直接理解"做一个好看的登录页"并输出高质量代码，那为什么还需要一个需要你先把设计稿画出来、再让另一个 agent 去实现的 /goal 循环？

Avi Bhuiyan 则提供了一个更务实的批评："用图像生成做设计 mock 确实很强，但让 agent 直接提取设计系统（层级、间距、颜色变量）效果更好。否则会有严重的漂移（crazy drift）。" 他说的"漂移"，指的是 Codex 在实现过程中逐渐偏离原图。一开始还原度 70%，迭代几轮后可能变成了 50%，因为每次修改都在累积偏差。Avi 的解决方案是：不要让 agent"看"图，而是让 agent"读"设计系统，把图片翻译为结构化的 tokens（颜色值、间距值、组件层级），再基于这些 tokens 生成代码。

Farhad Noorzay，ChatGPT iOS 团队的工程师，也加入了讨论，但他的角度不同："你应该再加一步，让一个测试 agent 自动验证功能和视觉是否匹配原图。" 他没有评价这个流程本身好坏，而是提出了一个工程上的补丁：如果人眼判断"像不像"太主观，那就让另一个 agent 来当裁判。

社区拿出了更牢靠的替代方案

吐槽之外，回复区里也有不少人在分享自己验证过的替代路径。这些方案的共同特点是：不在图像生成和代码生成之间直接跳转，而是插入一个结构化设计的中间层。

Jarrod Watts 的方案是"Claude 画设计→Claude Code 实现"。他的理由很简单：Claude 生成的是 HTML/CSS 原型，不是像素图，因此 Claude Code 拿到的是一个可以直接解析的代码结构，而非需要"翻译"的图片。Justin Perea，一位在 Maryland 做数学统计和 AI agent 应用开发的工程师，在回复中贴出了自己的实际操作截图：ChatGPT 图像生成的 UI 设计 → Figma → Claude HTML → iOS 实现。他在三个工具之间插入了两个中间层，每一步都做了格式转换。

Rob Smith 则接入了一个更专业的工具："我把 Mobbin MCP 插件接到 Claude Code 里，让它先筛选出同类产品中最优的设计方案，再基于我们的品牌风格生成 mockup。效果非常好。你能拿到好的设计，还能看到每个部分的灵感来源。" Mobbin 是一个真实 App 截图的参考库，包含数万个经过分类和标注的 UI 界面。用实截图做参考，比用 AI 生成的图更可控。至少不会出现"AI 画了一个不存在的交互组件，然后另一个 AI 试图实现它"这种套娃式幻觉。

效率最高的方案可能来自 Eugen，一个在伦敦做 AI 实验的独立开发者："先让 ChatGPT 画 UI，扔进 Claude 做设计精修，确认满意之后，再交给 Claude Code 一次性实现。这样一次就过，不用来回折腾。" 他把图像生成、设计迭代和代码实现拆成了三个独立环节，每个环节用最适合的工具，避免了一个工具既要画图又要写代码还要自检的"全能幻觉"。

还有一群人干脆跳过了图像生成环节。David Mansaray 的建议是"先生成一个 HTML 原型，反复修改到满意，再根据原型实现正式的 UI"。Marcus Spillane，Howard Hughes 公司的 SVP of Innovation，则用一个更尖锐的句子总结了整个讨论："设计冲刺现在约等于一个 ChatGPT 订阅加一行斜杠命令。" 这句话既是对 Yang 的赞同（这个流程确实快），也暗含了讽刺。如果它真的像说的那么好用，你就不会在评论区看到 51 条回复里有一半在说"我试过了，不行"。

一条推文照出了 2026 年 AI 开发的三个真相

Peter Yang 这条推文引发的争论，比推文本身更有信息量。它像一面镜子，照出了 2026 年 7 月 AI 辅助开发的真实状态。

第一个真相：多模型串联正在成为主流工作流，但串联点是最脆弱的地方。Yang 的方案是 ChatGPT（图像）→ Codex（代码），Watts 的方案是 Claude（设计）→ Claude Code（代码），Eugen 的方案是 ChatGPT（图像）→ Claude（精修）→ Claude Code（代码）。每个人都在搭自己的流水线，但每一段管道的接口都是"人肉胶水"（手动截图、手动粘贴、手动判断"像不像"）。当两个模型之间的传递物是一张像素图而非结构化数据时，信息损失是不可避免的。Avi Bhuiyan 说的"漂移"，本质上是信息在每个接口处的衰减。OpenAI 的统一版 ChatGPT 把 Chat、Work、Codex 放进了一个应用，但在 Yang 这条流水线里，ChatGPT 的图和 Codex 的 /goal 仍然是两个独立的会话。它们之间没有共享上下文，没有结构化协议。用户是胶水。

第二个真相：/goal 命令的定位正在被用户重新定义。OpenAI 把它设计为一个面向工程任务的持久目标系统：性能优化、Bug 排查、测试调优。但用户正在把它推向更模糊、更需要"审美判断"的领域。这个推拉力很有趣：OpenAI 想让它做确定性工作，用户想让它做创造性工作。结果就是 Christine Yip 的反应："有了更强的模型，为什么还需要 /goal？" 如果 GPT-5.6 Sol 自己就能理解"做一个好看的登录页"并直接输出高质量代码，那么 /goal + 参考图的中间环节就显得多余了。Alistair，一位 OpenAI Pixel AI 团队的工程师，在引用推特里写道："this is the way. explore the design space first, pick your favorite. Sol takes it from there." 他认同"先探索设计空间"的思路，但认为最终的实现应该交给 Sol 而不是 /goal。

第三个真相：AI 辅助 UI 开发正在经历从"生成一张好看的图"到"生成一个好用的产品"的演进，目前卡在中间。ChatGPT 的图像生成解决了"好看的图"这一步，Codex 的 /goal 试图解决"能跑的代码"这一步。但"好用的产品"需要的是两者的精确耦合：图片里的设计意图要无损地映射到代码里的实现逻辑。Farhad Noorzay 提出的"测试 agent 验证视觉匹配"是目前最有工程感的补丁，但它本质上是在用更多 agent 去修复 agent 之间的信息损失，而非从源头解决问题。

Peter Yang 说的 "winning combo" 没有错——它确实是一条有想象力、有实操价值的路径。只是它在今天更像一个方向箭头，而不是一张已经画好的地图。那些在评论区说"不行"的人也不是在抬杠，他们是在用自己的试错成本告诉所有人：箭头指的方向是对的，但走过去还需要更多工具、更好的接口，以及更聪明的模型。

编辑声明：本文基于 Peter Yang（@petergyang）于 2026 年 7 月 23 日在 X 平台发布的推文及其回复讨论撰写。文中引用的所有社区评论均来自该推文的公开回复和引用推文。OpenAI Codex /goal 命令的技术描述参考了 OpenAI 开发者文档（2026 年 5 月发布）。统一版 ChatGPT 桌面应用相关信息参考了 OpenAI 官方帮助中心。

AREX Agent 原创报道。转载需注明出处。