我是如何用 AI 做设计的
How I Design with AI.
*作为一个不是设计师、深恶痛绝垃圾产物（slop）的工程师。 *
每个落地页、应用和 TUI 看起来都一个样。它们都是垃圾产物，而且其中大多数令人费解。
下面讲讲我是如何给产品设计去垃圾化的。
1. 始终着眼整体。
设计过程大致分为三步：
- 列出你要为之设计的所有约束条件。
- 考虑一批满足这些约束条件的解决方案。
- 如果意识到必须新增或可以移除某个约束条件，就回到第 1 步。
这源于 Christopher Alexander 的《形式综合论》（*Notes on the Synthesis* of Form）。这是对设计过程一次令人愉悦的严谨探索。
约束条件可以有多种形态：字体和字号规则、你必须支持的工作流，或是业务逻辑状态。关键在于由你来决定约束条件。
常见的问题是跳过第 3 步，陷入打地鼠式的设计修补。
用户一旦犯迷糊，人自然而然就会跳进解决问题模式。我们团队经常被这种难题勾走注意力，左侧边栏尤其如此，因为它在狭小空间里塞了太多信息。诱惑在于局部修补，但这条路通向毁灭。
跳过罗列约束条件的后果是，你会得到一堆互不相干的拼凑物，随机地让某些交互凌驾于另一些之上。AI 加剧了打地鼠式设计的诱惑。它诱导你用提示词说"把 X 做得更突出"或"加一个做 Y 的入口"。到头来，更多用户反而更糊涂。
收到反馈时，先评估它是否改变了你的设计约束条件，再跳进解决方案。 我们的做法是维护一份文档，记录各种细碎小毛病和烦人之处。明显的修复我们快速推进，但小的问题先记录下来，这样等到重新设计时，我们手头就有一批问题可以统筹解决。关键是避免过度应激反应、制造更多混乱。
2. 做减法。
智能体总喜欢加东西。你的职责是删掉不必要的部分。
这一点你应该非常熟悉，因为智能体在代码和方案里做的正是同样的事。它们喜欢双保险式的过度防御写法，多套一层 try-catch，或者一遍又一遍地重写同一个工具函数。
在 UI 设计里，智能体也一样。它们爱加多余的文案、线条和图标。最后你得到的设计，看着比大多数工程师手工做出来的更漂亮，实际上却并不怎么样。
一个简单的做法是：审视设计中的每个元素，逐个问自己"我真的需要它吗？"
3. 在设计工具里迭代。
你不应该在产品里迭代设计。要用一款能给你精细控制、让你带着最少额外上下文快速迭代的工具。
原型引力是沉默的杀手。 它指的是：你让智能体在你的代码库里做出第一版，然后觉得直接打磨它比探索其他方案更省事。在真实代码库里做设计，还会迫使智能体去造一个硬嫁接到你的真实
Figma 依然是最强标杆，而且它的 AI 集成每周都在变得更好。Cursor Design Mode、Claude Design、一大批新创业公司的产品，甚至 HTML 原型，也都很棒。
拜托，就用一款为设计而生的工具，让 AI 给每样东西都生成三四个变体。
4. 使用组件与库。
这一条对大多数工程师来说可能不言自明，但它太重要了，我快速说两句。
把视图和逻辑分开。创建可复用的组件。
这不难，而且回报丰厚。你的应用会视觉统一，而不是一堆反复重写的按钮拼成的补丁。
在 Ref，我们的做法是维护一个 /showcase 页面。我们先让智能体在那里搭好 UI 组件、随意试玩，然后再接入主应用。
5. 使用预览部署。
评估设计最好的方式是用真实数据。预览部署让你能带着真实后端试用新设计。
有一点要牢记：总免不了要打磨和返工。就算智能体完全按你说的做出来了，你把它拿在手里、配上真实数据一看，仍可能发现不对劲。
对于同时涉及前端和后端的大功能，预览部署可能比较棘手。在 Ref，我们靠把前端和后端的 PR 分开来解决。后端改动可以用单元测试和集成测试验证；前端改动需要人工验证，而预览部署让分享链接变得很容易。
6. 偷师。
大多数 UX 问题早就有人解决过了，你该做的是把零散的部件拿来拼装。花点时间看看那些解决类似问题的产品，或是传达类似想法的产品。
我合作过的每一位牛人设计师，每个项目都是从收集一堆截图开始的。你也该这样做，这些截图是发给智能体的绝佳上下文。
7. 探索你的品味。
这是最有趣的部分！
品味就是反思自己对某个事物的反应。抱歉了，Kyle Chayka，但反思自身体验并不是布鲁克林阁楼里那帮派对客的专利。它是创造的必需，也是不制造垃圾产物的必需。
产品工程师极擅长看出设计哪里不行，却很难知道该怎么改。 工程师缺的是从经验中提取解决方案的素材库。构建这个库只需要反复尝试、反复反思。
玩耍和探索很有趣，但也可能相当残酷，因为在作品足够好之前，扑面而来的是铺天盖地的批评。
在 Ref，我们没有全职设计师，于是用农业里打谷脱粒的办法来打磨品味：把设计往场子中间一扔，拿棍子一通敲打，直到自己觉得顺眼。
就这些了。祝好运，玩得开心（GLHF）。