Codex 写不好界面时，我先让 ChatGPT 画 UI 稿

这不是第一次用 Codex 改代码。后端链路、API 对接、测试修复、报告生成这类任务，我通常直接把目标扔进去，让它读文件、改代码、跑验证、提交。问题出在前端重构这里：我没有先做 UI 稿，前面又已经把业务结构铺开了。旧界面一旦存在，模型看到的就不只是需求，还有现成组件、现成路由、现成样式和一堆历史惯性。

我一开始的反应也很普通：继续加提示词。允许破坏性重构，重新设计 UI 和交互逻辑，元素不要太密集，适配 24 寸和 32 寸显示器，聚焦核心功能，不要保守。每句话单独看都对，但合在一起仍然缺一个东西：最后到底应该长什么样。

卡住的不是按钮颜色

strategy_studio 不是一个只有两三个按钮的小工具。README 里对它的定位已经是中文优先的策略研究平台：Next.js 前端、FastAPI API、PostgreSQL、Worker、Scheduler 和 Yahoo 同步链路一起跑。前端 README 又把页面收敛成一个研究工作台：样本准备、实验配置、任务跟踪、结果复盘、模板维护，还有报告详情和运行维护入口。

这种项目的前端问题，表面上是“不够好看”，实际是信息秩序没定下来。用户先看行情，还是先看回测任务？报告详情里曲线、指标、输入参数和重跑按钮谁更重要？首页是导航页，还是工作台？大屏上是铺满，还是留出呼吸感？

这些判断只用文字描述，Codex 很容易理解成“在现有页面里优化一下”。它会改组件、调间距、换颜色，但仍然沿着旧结构走。允许破坏性重构也不够，因为破坏性重构解决的是“能不能大改代码”，不是“有没有一个可验收的视觉目标”。

我白天出去一趟，晚上突然想到，别继续让 Codex 猜 UI 了。先在 ChatGPT 网页端把 UI 设计稿画出来，再把图交给 Codex 还原。

当时用的提示词很直接：

https://github.com/ttf248/strategy_studio 分析当前项目的前端代码，理解业务逻辑，作为专业的UI设计师、交互设计师，帮我重新设计一套前端页面，每个页面单独出图，记得适配 24寸、32寸显示器，元素不要太密集，方便用户使用聚焦核心功能。

这一步出来的效果，比我继续在 Codex 里堆形容词要稳定得多。它先给了一个可见的目标：页面怎么排、模块比例怎么分、视觉中心在哪里、留白大概到什么程度。Codex 后面再接手时，任务就从“凭审美重设计”变成了“按图理解业务并还原代码”。

配色也要先变成材料

第一轮图已经解决了版面问题，但默认配色还是常规后台系统的蓝白，不太符合我的审美。如果这个时候再把“不喜欢蓝白，换个高级点的配色”丢给 Codex，本质上还是让它猜。

这张就是最初那版蓝白配色。它已经能说明页面结构，但气质仍然偏普通管理后台。

Strategy Studio 初版蓝白 UI 稿

后面我换了做法：先在 ChatGPT 网页端沟通配色方向，把底色、强调色、卡片层级和研究工具感说清楚，再让图像模型按这个方向出示意图。它不等于正式 Figma，也不是完整设计系统，但已经足够把前端重构最容易漂移的东西固定下来。

最后拿到的不是一张“大而全首页”，而是按页面拆开的设计稿：首页、行情研究、回测实验、报告中心、报告详情、策略模板、运行维护。这个拆法很关键。strategy_studio 的前端不是营销页，而是研究工具；首页、行情页和报告详情页承担的阅读任务不一样，不能都塞进同一套卡片网格。

Strategy Studio 首页设计稿

Strategy Studio 报告详情设计稿

图出来以后，Codex 的角色就清楚了。它不是从零当 UI 设计师，而是读现有业务逻辑、拆组件、调布局、对齐交互状态、跑 lint/build，再把旧前端重构到接近设计稿的目标状态。

不是简单的“网页版更聪明”

后来我又查了一圈官方资料，想确认这件事能不能解释成“不同渠道的 ChatGPT 智力能力不一样”，或者“Codex 直接使用时功能被阉割”。这个说法太粗。

OpenAI 对 Codex CLI 的描述，是本地终端里的 coding agent：它能在当前目录里读代码、改代码、运行命令。Codex web 则是在云端环境里处理代码任务。OpenAI 讲 Codex agent loop 时，重点也不是“模型凭空想出所有东西”，而是模型推理、上下文管理、工具调用、文件读写和命令执行一起构成软件任务。

ChatGPT Images 是另一种入口。OpenAI Help 里对 Images in ChatGPT 的说明，是用户可以在对话里创建和编辑图片，也可以做 mockup 或创意视觉。这个产品形态天然更适合先探索视觉目标，因为它的交付物就是图，而不是马上动代码。

所以这次差异，更准确地说不是“谁更聪明”，而是任务形态不同。把“重新设计 UI”直接交给 Codex，它会站在代码仓库里思考：哪些文件要改、哪些组件不能破坏、怎么让构建通过。把同样的业务背景先交给 ChatGPT Images，它会先把抽象的审美和信息层级压成一张可见的目标图。

这也解释了为什么后来 Codex 反而更好用。不是设计稿绕开了 Codex，而是设计稿给 Codex 补了上下文和验收标准。官方 Codex prompting 文档也强调，要给 Codex 相关文件、图片和清楚的完成标准。没有图时，“元素不要太密集”只是形容词；有图以后，它才变成可还原的布局约束。

更顺的链路

这次之后，我会把这类前端重构拆成三段。

第一段，先做视觉探索。让 ChatGPT 网页端读仓库、理解业务、按页面出图，再围绕配色、密度、大屏适配和视觉层级来回调。这个阶段的产物不是代码，而是目标图。

第二段，把目标图和工程约束交给 Codex。提示词不要停在“重新设计 UI”，而要写清楚：以哪些图片为目标，哪些业务逻辑不能破坏，哪些页面允许破坏性重构，哪些测试和构建必须通过。

第三段，进入工程还原。这里才适合让 Codex 开 goal 或连续任务模式：先读前端结构，再按页面拆分实施，每个页面完成后跑验证，最后统一检查交互和响应式。

我以前容易把“提示词写得更狠”当成解决办法。现在看，前端重构里更有用的不是狠，而是把缺失的中间产物补上。没有 UI 稿时，破坏性重构只是拆得更大；有了 UI 稿以后，破坏性重构才有方向。

这套流程也不是只适合 strategy_studio。任何已经有业务逻辑、但前端长期靠边做边补的个人项目，都可以这么处理：先让图像模型把界面目标画出来，再让 Codex 把目标变成代码。模型之间不是谁替代谁，而是各自接自己更像工种的那一段。

参考资料

写作附记

原始提示词

$blog-writer 日常使用 codex 调用 ChatGPT 模型进行代码，开源项目 https://github.com/ttf248/strategy_studio 开发的时候，开始没做 UI 稿，直接进行业务逻辑开发，导致前端界面没有规划，尝试直接在 codex 里面写提示词：允许破坏性重构，重新设计 UI、交互逻辑，怎么调整效果都不太行。这个时候，还没怀疑 codex 的问题，白天出去一趟，晚上灵光闪现，我是不是能在网页版，调用 image2 出一组 UI 设计稿，然后交付给 codex 开启 goal 模型进行还原开发，简单尝试下，没有任何问题，这是用到的提示词: https://github.com/ttf248/strategy_studio 分析当前项目的前端代码，理解业务逻辑，作为专业的UI设计师、交互设计师，帮我重新设计一套前端页面，每个页面单独出图，记得适配 24寸、32寸显示器，元素不要太密集，方便用户使用聚焦核心功能。此时已经效果不错了，但是这个默认的配色，常规的蓝白色，不符合我的审美，继续调整方案，我们先在网页沟通一组合适的配色，然后 image 根据配色，出个演示图，再用配色方案，结合前面的提示词，我们就能拿到：https://github.com/ttf248/strategy_studio/tree/main/ui。我写的内容很多，你整理下，用一篇稿子写完，我有疑惑的地方，你自己联网查资料，提供的 https://github.com/ttf248/strategy_studio/tree/main/ui 里面有很多图片，随便抽两张贴到博客里面。

写作思路摘要

这次重写保留了原文的判断和材料，但把开头从“先给完整答案”改成“先进入前端重构卡住的现场”。文章压掉了泛化模型评测，只写这次工作流里真正有效的转向：先把视觉目标变成图，再让 Codex 做工程还原。