别让 Codex 直接写页面：先把 UI 生产线拆成三段

很多人用 Codex 做页面，第一句话就是：帮我写一个后台、帮我写一个落地页、帮我做一个管理界面。

它确实能写，而且很快。但第一版经常有一种熟悉的味儿：功能都在，页面也能跑，就是像一张被组件库拼出来的表格。按钮、卡片、筛选框都有，可信息主次不清楚，用户进来不知道先看哪儿。

问题不一定在 Codex 的代码能力，而在你把 UI 生产线压得太短了。

一个页面要好用，先要回答几个问题：用户是谁？进来要完成什么动作？最重要的信息是什么？异常状态怎么处理？哪些内容应该被弱化？哪些模块未来要复用？

这些问题没想清楚，直接写代码，只是在代码里做产品决策。于是你会不停让 Codex 改颜色、调间距、换布局，改到最后自己也说不清到底哪里不对。

UI 的核心不是把功能摆上去，而是把用户路径、信息层级和动作优先级摆对。

Codex 不应该一上来就写 React 组件。更好的第一步，是让它先把页面目标拆清楚。

比如你要做一个运营看板，不要先说“写个 dashboard”。先让它回答：

这一步像产品经理，不像前端。它决定的是页面骨架，而不是代码文件。

文字方案再完整，也还是抽象的。真正能减少返工的，是尽早把它变成一张能看的 UI 方向。

这就是 gpt-image-2 这类生图模型放进工作流里的价值。它不是单纯“画张漂亮图”，而是把 Codex 拆出来的信息层级、模块关系、主次动作，转成一个可观察的视觉稿。

有了图，你就能直接判断：页面是不是太满，主按钮是不是抢戏，数据卡片有没有压住重点，移动端是不是会崩，整体风格是不是像一个认真打磨过的产品。

视觉稿不是终点，它是讨论对象。

视觉方向确定后，再让 Codex 回来写代码，这时它做的事就清楚多了。

它不再凭空猜页面，而是根据已经确认的视觉方向拆组件、状态、数据结构和样式约束。你可以要求它输出组件树、状态表、接口假设、空态和错误态，再进入实现。

这一段才是 Codex 真正擅长的部分：把明确方案落成工程资产。

第一类，是新产品第一版。需求还没完全想清时，直接写代码容易越写越重。先拆目标，再看视觉，可以尽早暴露模糊点。

第二类，是内部工具升级。很多内部系统不是不能用，而是信息堆得太满。用这条流程能先理清任务和主路径，而不是只换个主题色。

第三类，是自动化交付。比如你经常给客户生成看板、后台、内容页，那每次沉淀下来的不只是一个页面，还有页面结构模板、视觉提示词、组件拆解规范。

Codex + gpt-image-2 不会让设计师和前端不重要。相反，它会把低层试错压缩掉，让人的判断更早出现。

你要判断页面是否符合业务目标，视觉是否服务主路径，哪些细节值得做，哪些只是装饰。AI 可以把可能性摊开，但不能替你决定哪条路值得走。

所以别再只让 Codex 直接写页面了。把 UI 生产拆成三段：先拆目标，再看视觉，最后写组件。代码会更快，返工会更少，页面也更像个真产品。