我是如何利用 AI 进行产品设计的：7 个去糙去烂的实用原则
作为一个不是设计师且讨厌 AI 劣质产物（slop）的工程师。
每一个 Landing page、应用和 TUI 界面看起来都一模一样。它们全是无脑堆砌的劣质产物（slop），而且大多数都让人难以理解。
以下是我在产品设计中摆脱劣质感（de-slop）的方法。
1. 始终具备全局观（Always consider the whole）
设计流程大致分为 3 个步骤：
- 列出你正在为其设计的所有约束条件（Constraints）。
- 思考一整套能够满足这些约束条件的解决方案。
- 如果你意识到必须添加新约束，或者可以移除某个约束，回到第 1 步。
这来自于 Christopher Alexander 所著的《Notes on the Synthesis of Form》（形式合成法要），这是对设计过程一次令人愉悦且严谨的探索。
约束条件可以有多种形式。它们可以是字体和字号规则、你必须支持的工作流，或是业务逻辑状态。关键在于由你来决定约束条件。
常见的错误在于跳过第 3 步，打起了“打地鼠式”的设计（design wackamole）。
当用户感到困惑时，人们很自然地会立刻陷入“寻找解决方案”模式。我们团队也经常在这个陷阱里被吸引走（nerd sniped）。尤其是在左侧边栏，因为它要在极小的空间里挤入巨量的信息。人们很容易忍不住去做局部修修补补（spot-fix），但这无异于自寻死路。
由于跳过了梳理约束条件这一步，导致的问题就是你最终得到的是一个脱节的补丁集合，随机优先考虑了某些交互而忽视了其他交互。AI 更是加剧了这种“打地鼠式设计”的诱惑。它极易诱导你去提示：“让 X 更突出一些”或者“加一个做 Y 的入口”。结果到头来，困惑的用户反而更多了。
当收到反馈时，在匆忙寻找解决方案之前，先评估一下它是否改变了你的设计约束条件。我们在处理这个问题时的方法是：维护一份专门记录“微小痛点（papercuts）和不适感”的文档。对于显而易见的修复，我们迅速迭代；但对于细枝末节的问题则先记录下来，等到需要进行重构设计时，再集中统一、整体协调地解决。关键在于：我们要避免过度反应，从而制造出更多的混乱。
2. 砍掉不必要的东西（Remove stuff）
Agent 极其喜欢加东西。你的工作就是删掉那些不必要的部分。
这一点你应该非常熟悉，因为 Agent 在写代码和制定计划时完全是一模一样的套路。它们极度喜欢“双重保险（belt-and-suspenders）”，动不动就额外套一层 try-catch，或者一遍又一遍地重复实现同一个工具函数。
在 UI 设计中，Agent 也是如出一辙。它们超爱添加额外的文案、线条和图标。最后你拿到的设计虽然看着比绝大多数工程师手写的要好看，但实际上却显得很臃肿糟糕。
一个简单有效的步骤是：仔细审视设计的每一个元素，并对每一个元素提问：“我真的需要这个吗？”
3. 在专业设计工具中进行迭代（Iterate in a design tool）
你不应该直接在真实产品代码里去迭代设计。请使用能给予你精细控制、并能以极少额外上下文快速迭代的专业工具。
“原型重力（Prototype gravity）”是默默无闻的杀手。它是指：当你让 Agent 在你的代码库里写出了第一版后，你就会觉得在此基础上继续微调比去探索其他可能性要容易得多。在真实代码库里设计，还会强行逼迫 Agent 做出一个强行贴合你现有真实系统的版本。
Figma 依然是无可争议的 GOAT（历史最佳），而且它的 AI 集成每周都在变得更好。Cursor Design Mode、Claude Design、一众新成立的初创公司，甚至 HTML 原型也都非常棒。
但请务必使用专门为设计打造的工具，并让 AI 为每样东西生成 3 到 4 种变体方案。
4. 使用组件与组件库（Use components and libraries）
这一点对大多数工程师来说可能显而易见，但它至关重要，因此我快速交代一下。
将视图（Views）与逻辑（Logic）分离。创建可复用的组件。
这并不难，而且会带来巨大的回报。你的 App 在视觉上会保持高度一致，而不是变成一个由各种重新实现的按钮拼凑出来的“百衲衣”。
在 Ref，为了做到这一点，我们维护了一个 /showcase 展示页面。我们会让 Agent 先在那个页面里把 UI 组件构建出来并试用，然后再接入到主应用中。
5. 使用预览部署（Use preview deploys）
评估一项设计的最佳方式就是使用真实数据。预览部署（Preview deploys）能让你配合真实的后端来体验全新的设计。
记住这一点非常重要：打磨和返工总是不可避免的。即便 Agent 完全按照你的指令做出了东西，当你亲手拿着充填了真实数据的成品时，依然可能会发现它感觉不对劲。
对于涉及前端和后端的重大功能，预览部署可能会有些复杂。在 Ref，我们的解决方案是将前端 PR 和后端 PR 进行拆分。后端变更可以通过单元测试和集成测试来验证；而前端变更则需要人工校验，预览部署让分享体验链接变得轻而易举。
6. 拿来主义 / 借鉴好设计（Steal stuff）
绝大多数 UX（用户体验）问题早已经被解决过了，你应该把已有的优秀碎片收集起来并组合在一起。花点时间观察一下那些解决类似问题或传达类似理念的产品。
与我合作过的每一位极具天赋的优秀设计师，在启动每一个项目时，第一件事都是收集大量的参考截图。你也应该这么做，这能为你的 Agent 提供绝佳的上下文。
7. 探索与锤炼你的品味（Explore your taste）
这是最有趣的部分！
品味（Taste）是对你自己对某种事物做出的反应进行反思。顺便向 Kyle Chayka 道个歉：反思个人体验并不是布鲁克林阁楼派对上那些人的专利。想要创造出好东西、避免制造劣质垃圾（slop），反思是不可或缺的。
产品工程师非常擅长识别某种设计何时不起作用，但往往很难知道该如何修复它。工程师所缺乏的，是从经验中积累出来的解决方案库。建立这个库只需要不断尝试和反思。
探索和尝试很有趣。但过程也可能相当残酷，因为在某个设计足够好之前，你需要经受铺天盖地的批评。
在 Ref，我们没有全职设计师，所以我们采取了一种“农具打谷”式的硬核方法来锤炼品味：我们把设计摆在中间，用棍子猛打，直到我们对它感到满意为止。
以上就是我的全部心得。祝大家玩得开心，好运！ (GLHF)