怎么使用 Codex 和 Claude Code 重构前端 UI

背景声明：我不是设计师，也不是专业的前端，重构之后的设计也存在各种 UI UX 问题，一切都还是以我个人的评价能力来做的，不存在专业向的意见，只是想分享如何通过 vibe coding 的方式来做比较大的 UI 和架构的重构。欢迎大家评论区讨论，提供更多建议。

Lody 由于底层技术栈和人力的原因，完全使用 Web 来统一构建的网页端、桌面端和移动端。最开始只做了网页端，后续慢慢添加了桌面端和移动端，同时又是几乎在 vibe coding，所以 Lody 代码中移动端的 UI 几乎是到处使用 isMobile() 来判断，并且整体布局也就是直接将桌面端变窄并且添加一个 sidebar 。只能说是适配了移动端，但并没有专门为移动端做设计，不可避免地存在交互别扭、字体过小和按钮过小等问题。随着当前远程控制和多端同步的能力趋于稳定了，移动端优化的优先级就变高了。

所以这次重构我希望同时完成两个比较大的任务，一个是多端通用部分组件化，重新构建新的入口供移动端单独布局与旧的布局解耦。另一个就是完全重新设计移动端的 UI 和交互。

干之前了解模型的特点

每个模型在当前阶段都有不同的擅长的事情，我们是 codex 和 claude code 双持，就 codex 和 claude code 来说

GPT 擅长的事情：

GPT 不擅长的事情：

Opus 擅长的事情：

Opus 不擅长的事情：

这些差异是使用了几次就能够明显感受得到的，因为不是 80 和 90 的差别，而是能用和不能用的差别。所以在做大的任务之前，先了解这些模型，每一次模型更新都需要重新去试探这种边界，这可以更好地事半功倍地完成任务。这也是为什么我在之前的文章中提的为什么异构的 multi-agent 能够提升生产力的原因。

把绝大部分的重心都放在文档 spec 上

那么对于我的需求，我先让 codex 整理了当前代码库的所有有关移动端存在耦合的地方，把整理出来的放在一个文档中。

找出来大概 40 个文件的耦合。然后根据 codex 写的重构文档调整了一些细节，文件的分隔，命名，移动端的路由方式和移动端组件之类的。最后和 codex 进行一次对齐，确保理解了我的真实需求。

现在这是一篇近一千行的计划文档，我们的任务也是需求比较大，我让 codex 进一步拆分这个大任务

理解一致的话，帮我将这个大需求进一步地拆分成不同阶段的需求和实现方案文档，放到 docs 下的统一文件夹里

拆成了以下几个阶段 0. 再次搜索确认耦合位置，固化共享/分端的维护边界

  1. 拆出纯移动端使用没有耦合的组件

  2. 较大重构拆出 chat/session/settings/archive 等核心 feature 的移动端布局

  3. 评估新的移动端组件，手势以及询问新的 UI 设计方案

  4. 测试可访问性、设备矩阵和渐进发布

再根据每一阶段的具体需求和方案文档做一些 comment 讨论几轮，前一个阶段实现完了再讨论下一轮。lody 中就可以直接点开 diff 进行评论，很好用。codex 在做这些重构的时候，我们就可以去设计新版的 UI 了。

不是设计师怎么设计 UI

不是设计师的话就先不用考虑美不美的事情，为你的功能服务，让人能看得过去，整体规规矩矩的是第一要务。自己不会设计，但总归是用过很多软件，很多被设计师设计过的软件。不懂设计语言设计系统，不知道该怎么交互的时候就去看别的软件。但不能光看，要主动分析为什么会这样设计。前提你看的是好软件。 对于 Lody 这次重新设计难度还好，因为功能都是已有的功能，自己又是自己软件的用户。那么在对这样的有限集去做考虑的时候就可以简单地带入用户视角，一进来希望看到什么，哪些是最热的路径，哪些功能希望是最快被触达的，哪些可以增加层级做更明确且符合直觉的区分。这一步是最需要花费时间多多考虑的。 大概考虑好之后脑子里就有了几个蓝图，大概的结构。我就拿 iPad 去把所有的主要的界面和组件画了出来。

有了草稿之后现在还只能表达想要的内容和布局，但是没有样式和风格。这时候就可以将草稿发给 codex 并且告诉它你大概想要的风格去模拟真机的渲染图。

这期间可以不断调整 prompt，不断抽卡，直到获得你想要的视觉效果。 现在我们有了大致想要的真实效果了，codex 那边也重构得差不多了，把 diff review 一下，我们就可以开一个新的对话或者 Lody 中新的 Tab，有请 Opus 老师出场。Opus 真的蛮会写前端的。

怎么向 AI 描述想要的交互

接下来我们就开始真的让 AI 编写前端代码了，我们有了“真实”的渲染图和一些交互的想法，但是该如何有效地让 AI 理解你的想法。 如果你没有做过设计或者前端，那你就需要去 shadcn ui 或者其他的组件库的官网，把所有的组件都看一遍，拿着你的渲染图上不知道怎么描述的组件挨个去比对，去组件的网站上挨个去点一点看效果是不是你想要的，然后记住这个组件的名称。 和 AI 描述的时候就不用说“我想要一个问题和答案的列表，默认只展示问题，点击之后可以在下面显示答案，点击别的问题时候已经展开的需要自动收起。不同的问题之间有个分割线分开。 问题和答案分别是 Question A，Answer A；…”，而是“使用 Accordion 组件，Trigger 和 Content 分别是 Question A，Answer A；…”

https://x.com/leon7hao/status/2058904923769840103?s=20

非专业的朋友学习 vibe coding 就可以在日常工作的时候浏览网站的时候看到这种专业名词就记下来，不但节省 tokens 而且 AI 理解得更加清楚。

让 Opus 复原渲染图时就可以从上到下描述一遍当前图上的所有的组件，它是什么它的功能是什么你希望的交互效果是什么。

第一遍 AI 应该只能复现个大概，很多地方会有偏差，先看一下大概的架构和主题风格是不是你想要的，然后有出入的地方就需要一点一点继续磨，就全看个人对细节的把控了。

在磨 UI UX 的时候，当前阶段使用 web 技术栈的好处就体现出来了，这时候就可以使用 codex 的预览模式，cursor 的 design 模式或者是 Lody 的预览模式。在 Lody 上甚至可以直接在手机上给对应的组件直接评论发送给 Agent。 web 可以 HMR 热更新，改完就能看到效果，节省很多时间。

善用 Storybook 便于走查

最后推荐一下 Storybook，它是用于独立展示和测试构建 UI 组件的，不依赖真实的接口，非常适合同屏展示组件的所有可能的状态，正常态、空态、加载态、错误态、禁用态等等。我们在 AGENTS.md 中就添加了一条，新增的组件就要创建枚举所有状态的 Storybook，之后就不需要特别地每次都端到端地测试组件样式。都在 Storybook 中看就行，而且很多不会注意的空状态，异常状态也都不会被忽略。