用代理式构建迴圈设计 Slack 风格界面

我最近完成了一个专案：在单次 Codex session 里，把一个 Slack 风格界面重新设计并实作出来，过程受到五小时使用限制与 GPT-5.5 的约束。

真正重要的不是限制本身，而是整个顺序：

1. 从一个用 placeholder block 做出的旧式模拟界面开始
2. 先把 app 视为传统的 header、sidebar、main view 版面
3. 用 planning skills 设计较新的 sidebar rails、workspace list 与主要视图
4. 在碰实作之前，先反复调整视觉计划
5. 等形状足够清楚，再让构建工作开始

旧式外壳

起点刻意保持朴素。我希望旧结构一眼就能看懂，这样新版面就能被拿来和既有框架比较，而不是和一张空白画布比较。

这代表我保留了熟悉的产品骨架：

• 顶部 header
• 导览 sidebar
• 主要内容视图

从这里开始，问题就不是「模型能不能产生 UI？」而是「如果设计意图已经足够明确，模型能不能建出正确的 UI？」

先规划，再写程序

在实作之前，我用 Superpowers workflow 做了几轮视觉规划。

这让我先固定住几个第一版最容易漂移的细节：

• sidebar rails 应该如何框住 workspace list
• workspace list 的密度应该要有多高
• main view 应该如何平衡结构感与内容空间
• 哪些部分应该看起来是刻意设计，而不是 placeholder

这一步比程序生成本身更重要。计划越强，实作要猜的东西就越少。

第一版输出

第一版已经足够有用。

它抓到了整体方向，但仍然有一些小的 UI 瑕疵，特别是 tabs 和 buttons 没有干净对齐。即使大方向正确，这类细节也很难在第一轮完全消掉。

我会把第一轮评为 7 分，满分 10 分。

迭代之后

经过几次调整后，界面达到了我想要的大部分 UI 功能。

到了这个阶段，成果比较接近 8 分：形状是对的，互动表面可读，计划也被转换成一个大致连贯的界面。

这已经足够进入下一层 review。

为什么这属于 systems

这里的教训不是一次生成就够了。

真正的教训是，界面设计可以被视为系统表面的一部分：

• 先规划 layout
• 把结构明确化
• 接受第一版仍然需要 cleanup
• 用下一轮迭代缩小「能运作」与「设计良好」之间的差距

这正是我想保存在这个网站上的工程判断。