Day 074 · AI 独立开发：设计不能等功能做完再补

最近做产品，我遇到了一个很直接的问题：

功能已经做了不少，但产品特别丑。

不只是颜色、字体不好看，而是不同页面放在一起明显不是一套东西：

信息层级不一样
相似操作用了不同交互
页面结构各做各的
组件也越来越散

我当时的流程大概是：

ChatGPT/Claude 梳理需求 → Codex/Claude Code 实现 → 功能基本完成 → Claude Design 再处理设计

和 Codex 复盘时，它给我的判断是：

设计介入太晚了。

但我第一反应其实是困惑。

独立开发本来就是边做边确定。很多需求在真正实现以前，我自己都不知道最后会长成什么样。

难道为了让设计早点介入，要在开发前先完整做一遍 UX 和 UI？

后来我发现，不需要走到另一个极端。

真正的问题是：

不能等功能做完以后，才第一次认真处理体验和设计。

Coding Agent 写代码时，其实已经在替你定UI/UX

一个功能只要开始实现，就必须回答很多问题：

用户从哪里进入
第一眼看到什么
信息怎么分组
主要操作放在哪里
用 modal、drawer 还是新页面
用卡片、列表还是表格
loading / empty / error 怎么处理
做完以后去哪里

如果前面没有定义，Codex 为了完成任务，只能自己选。

单看某一个页面，方案可能都说得过去。

问题是，不同页面是在不同任务、不同上下文里生成的。

最后就很容易变成：

这个地方用 modal，另一个类似操作却跳新页面；
这个页面全是卡片，另一个页面完全是表格；
每一次都有理由，合起来却不像一个产品。

所以等功能全部完成，再让设计工具“统一一下”，有时候已经不是换颜色、调间距的问题了。

页面结构和交互本身都可能要返工。

但设计也没必要在开发前一次做完

另一边的问题也很现实。

独立开发里，很多事情确实只有做出来以后才能判断：

真实内容到底有多少
AI 输出实际有多长
用户会在哪里卡住
页面放入真实数据以后挤不挤
某个功能是不是真的需要存在

所以我现在不会走：

需求全部确定 → UX 全部完成 → UI 全部完成 → 开始 Coding

我更倾向于让设计分三次进入。

第一次：开发前，先把体验骨架定下来

这一步很轻，不需要完整设计稿。

谁来做：

我 + ChatGPT 为主。

如果是全新的产品，或者第一次确定整体视觉方向，会让 Claude Design 轻量介入。

先确定什么：

ChatGPT 不只是帮我写“这个功能要做什么”，还要补到体验这一层：

用户来这里做什么
从哪里进入，完成后去哪里
最重要的信息是什么
主要操作是什么
有哪些 loading / empty / error 状态
哪些问题还没有确定

Claude Design 如果介入，主要看更全局的东西：

产品整体气质
navigation / app shell
基本页面结构
信息密度
最基础的视觉方向

产出：

两个很轻的东西就够：

UX skeleton

User goal
Entry / exit
Primary flow
Information hierarchy
States
Open questions

DESIGN.md v0

产品气质
UX 原则
navigation / app shell
layout 原则
明确不希望出现的做法

它不是完整 Design System。

更像是先画几条边界，不让 Coding Agent 每次从零开始决定。

第二次：一条真实路径跑通后，正式做设计

这是我现在觉得最重要的时间点。

不是刚开始，也不是全部做完。

而是已经有一件真实的事情，可以让用户从头做到尾。

这时终于有：

真实数据
真实内容
真实页面
真实交互
真实的信息密度

谁来做：

我 + Claude Design。

先基于已经运行的产品看 UX：

流程顺不顺
信息层级对不对
用户知不知道下一步
有没有不必要的复杂度

再做 UI：

页面结构
typography
spacing
color
components
visual hierarchy

设计确定以后，Codex马上回来实现。

不然 Claude 那边已经是一套设计，Codex 还在按旧结构继续开发，很快又会分叉。

产出：

这一轮开始有比较实在的公共基础：

几个代表页面
App shell
typography / spacing / color tokens
button / input / card / table 等基础组件
empty / loading / error patterns
真正落进代码里的 shared components
DESIGN.md v1

也就是说，公共设计不是一开始凭空想出来的。

它是从真实页面里慢慢长出来的。

第三次：后面哪里变了，就让对应的工具回来

第二次结束，不代表“设计完成”。

但也没必要每改一个字段都重新找 Claude。

我现在会先判断变的是什么。

只是内容变化

例如多一个字段、少一段说明。

→ Codex 复用已有模式。

用户流程或需求变化

例如增加新入口、完成后要去新的地方。

→ 先和 ChatGPT 更新 UX skeleton。

出现新的页面或复杂交互

例如第一次出现：

Review AI output
Compare
Timeline
Complex filter
Bulk action

→ Claude Design 再介入，把这个新模式设计清楚。

如果以后还会反复使用，再加入 DESIGN.md 和公共组件。

页面开始越长越不像

→ Claude Design 做一次整体 design audit，再由 Codex 统一修正。

所以 DESIGN.md 也不是一次写完的

我之前会觉得：

产品都没做完，怎么可能先定义 Design System？

现在觉得，本来就不需要。

它可以分阶段长出来。

早期先定比较稳定的：

产品气质
UX 原则
navigation
app shell
layout

真实页面出现后再补：

tokens
基础组件
common states
interaction patterns

某种业务模式真的重复出现后，再抽象它。

不是先造完整 Design System 再做产品。

也不是所有页面做完以后再统一。

而是先解决真实问题，再把反复有效的解法留下来。

回头看我原来的流程：

ChatGPT 写需求 → Codex 全部开发 → Claude 最后设计

现在我会改成：

ChatGPT 把需求补到 UX 层→ Codex 先跑通一条真实路径→ Claude Design 基于真实产品做 UX + UI→ Codex 把设计基础真正落进代码→ 后面哪里发生变化，再让对应工具回来

几个 AI 工具可以分别提供产品、设计、工程能力。

但它们不会自动组成一个产品团队。

ChatGPT 没讲清楚的体验，Codex 会为了把功能做出来自己补。

Codex 已经补出来的页面结构，Claude 最后只能在上面继续改。

最后还是需要人不断判断：

现在缺的是产品判断、体验设计、视觉设计，还是实现？

所以这次“产品为什么这么丑”，最后并没有让我得出：

以后要先把设计全部做完。

反而是一个更简单的结论：

设计不用一次做完，但不能最后才开始。