为什么要重构

Lody 因为技术栈和人手的原因，网页、桌面、移动三端全部用 Web 统一构建。最早只做网页，后来桌面端、移动端一路堆上去，再加上几乎全程 vibe coding，代码里到处都是 isMobile() 的判断，移动端布局基本就是把桌面端压窄、塞个 sidebar 完事。

说白了就是"适配"了移动端，并没有"设计"移动端。字号小、按钮小、交互别扭，问题一大堆。等到远程控制和多端同步这些核心能力稳定下来后，移动端优化的优先级就顶上来了。

这次重构想一次解决两件事：

  • 多端通用的部分组件化，给移动端单独搭一个入口，和旧布局彻底解耦
  • 完全重新设计移动端的 UI 和交互

先摸清模型的脾气

我现在 Codex 和 Claude Code 双持，使用前先搞清楚两者各自擅长什么。

这种差异用几次就能明显感觉到，不是 80 分和 90 分的区别，而是能用和不能用的区别。所以做大任务之前先试探一下边界，每次模型更新都得重新摸一遍。这也是为什么我之前一直强调，异构的 multi-agent 能真正提升生产力——不是凑数，是各干各擅长的活。

时间花在 spec 上，不是在催 AI 写代码

我让 Codex 先把代码库里所有和移动端耦合的地方梳理出来，整理成一份文档。结果挖出了大概 40 个文件的耦合。

然后根据 Codex 写的重构文档继续抠细节：文件怎么分、怎么命名、移动端用什么路由方式、移动端组件怎么组织。最后再和 Codex 对齐一次，确保它真的理解我的需求。

这时候已经是一份将近一千行的计划文档。任务太大了，我让 Codex 再把它拆成阶段：

  • 阶段 0：再次搜索确认耦合位置，固化共享/分端的维护边界
  • 阶段 1：拆出纯移动端使用、没有耦合的组件
  • 阶段 2：较大重构，拆出 chat / session / settings / archive 等核心 feature 的移动端布局
  • 阶段 3：评估新的移动端组件、手势，敲定新 UI 设计方案
  • 阶段 4：测试可访问性、设备矩阵和渐进发布

每个阶段我都会再 review 一遍方案文档，做几轮 comment 讨论，前一阶段实现完了再开下一轮。Lody 里可以直接点开 diff 评论，很顺手。Codex 在埋头重构的时候，我这边就开始设计新版 UI。

不是设计师，怎么设计 UI

不是设计师就别先纠结美不美。功能服务优先，整体规整、不出戏，就是合格线。

虽然不会设计，但你总用过一堆别人设计过的好软件。不懂设计语言、不知道怎么交互，就去看别的软件——但不能光看，要主动分析它为什么这么设计。前提是你看的是好软件。

Lody 这次重设计难度还好，因为功能都是已有的，我自己又是自己软件的用户。带入用户视角想几个问题：

  • 一进来希望看到什么？
  • 哪些是最热的路径？
  • 哪些功能希望最快被触达？
  • 哪些可以增加层级，做更明确、更符合直觉的区分？

这一步最值得花时间。脑子里有了几个蓝图之后，我直接用 iPad 把所有主要界面和组件都画了出来。

草稿能表达内容和布局，但没有样式和风格。这时候把草稿发给 Codex，加上你想要的风格描述，让它去模拟真机的渲染图。不断调整 prompt、不断抽卡，直到拿到你想要的视觉效果。

描述交互这件事，专业名词能省一半 token

Codex 那边重构得差不多了，diff review 一下，就可以开个新对话或者新 Tab，请 Opus 老师出场——Opus 真的蛮会写前端。

接下来真要让 AI 写前端代码了。手里有"真实"渲染图，也有交互想法，问题是怎么让 AI 准确理解。

如果你没做过设计或前端，建议去 shadcn ui 或者其他组件库官网，把所有组件都看一遍。拿着你的渲染图，对不知道怎么描述的部分挨个比对，在组件网站上点一点，看效果是不是你想要的，然后把组件名字记下来。

和 AI 描述时就不用这么说：

我想要一个问题和答案的列表，默认只展示问题，点击之后可以在下面显示答案，点击别的问题时候已经展开的需要自动收起。不同的问题之间有个分割线分开。问题和答案分别是 Question A，Answer A……

而是直接：

使用 Accordion 组件，Trigger 和 Content 分别是 Question A，Answer A……

非专业的朋友学 vibe coding，平时浏览网站看到这种专业名词就记下来。不但省 token，AI 理解得也更清楚。

让 Opus 复原渲染图的时候，从上到下把图上所有组件描述一遍：是什么、功能是什么、希望的交互是什么。第一遍一般只能复现个大概，先看架构和主题风格对不对，然后有偏差的地方一点一点磨——这就全看个人对细节的把控了。

磨 UI/UX 的时候，Web 技术栈的好处就体现出来了：Codex 的预览模式、Cursor 的 design 模式、Lody 的预览模式都能用。在 Lody 上甚至可以直接在手机上给对应组件评论发给 Agent。HMR 热更新，改完就能看到效果，省非常多时间。

Storybook 是组件的体检表

组件写完不等于结束。AI 随时可能把已经设计好的样式或交互搞坏。

最后强烈推荐 Storybook。它用于独立展示和测试 UI 组件，不依赖真实接口，非常适合同屏展示组件的所有可能状态：正常态、空态、加载态、错误态、禁用态等等。

我在 AGENTS.md 里加了一条规则：新增组件必须创建枚举所有状态的 Storybook。之后不用每次都端到端测组件样式，全在 Storybook 里看就行。而且很多容易被忽略的空状态、异常状态，也不会再被漏掉。

写在最后

整个流程拆开看其实就三件事：把需求写清楚（spec）、把图画出来（草稿+渲染）、把组件名字说对（专业词汇）。AI 写代码只占整体时间的一小段，前两步做得越扎实，后面磨细节的回合就越少。

如果你也在 vibe coding 自己的软件，别上来就让 AI 写代码——先花一晚上写文档，第二天的效率会让你回不去。