我是怎样用 AI 做设计的
文章摘要
作者是文档搜索 MCP 服务 Ref（ref.tools）的创始人，自我定位是「一个不是设计师、但讨厌 slop 的工程师」。他的出发点很直接：现在每个落地页、应用和 TUI 看起来都一模一样，都是 slop，而且大多数根本看不懂。这篇文章讲的是他如何给自己的产品设计「去 slop 化」，一共七条。
一、永远考虑整体。 他把设计过程概括为三步：（1）列出你要为之设计的所有约束；（2）考虑一组能满足这些约束的方案；（3）如果你意识到必须新增一条约束或某条约束可以去掉，回到第一步。他推荐了 Christopher Alexander 的《Notes on the Synthesis of Form》，称其为对设计过程的一次令人愉悦的严谨探索。约束的形式可以多种多样——字体和字号规则、必须支持的工作流、业务逻辑状态——重要的是约束由你来定。
常见的问题是跳过第三步，变成「打地鼠式设计」。用户困惑了，人的本能是立刻跳进解决方案模式；他说自己团队经常被这种冲动带偏，尤其是左侧边栏，因为它在很小的空间里塞了太多信息。诱惑在于头痛医头，但那条路通向毁灭。跳过「列出约束」这一步的后果是你得到一块拼接起来的破布，随机地把某些交互置于另一些之上，最终让更多用户困惑。AI 加剧了打地鼠式设计的诱惑，因为它鼓励你输入「把 X 弄得更显眼」或者「给 Y 加个可供性」。他的做法是维护一份记录小毛病和恼人之处的文档：明显的小修立刻做，次要的先记下来，等到重新设计时成批地、有内聚地处理，避免过度反应制造更多混乱。收到反馈时，先评估它是否改变了你的设计约束，再跳到解决方案。
二、Agent 爱加东西，你的工作是删掉不必要的部分。 他说这对工程师应该非常熟悉，因为 agent 在代码和方案里干的是同一件事：它们热爱「双保险」，多包一层 try-catch，或者把同一个工具函数反复重新实现。在 UI 设计里它们同样如此，热衷于加额外的文案、线条和图标。结果是看起来比大多数工程师手写的要好、但实际上相当糟糕的设计。一个简单的做法是：逐个审视设计里的每个元素，问「我真的需要它吗」。清理 agent 留下的垃圾。
三、不要在产品里迭代设计。 用一个能给你精细控制、并且能在最少额外上下文下快速迭代的工具。他提出了一个概念叫「原型引力（prototype gravity）」，称其为无声的杀手：当你让 agent 先在你的代码库里做出第一版，之后就会觉得继续打磨它比探索其他方案更省事；而且在真实代码库里做设计还会迫使 agent 做出一个能嫁接到现有代码上的版本。他的评价是 Figma 依然是王者（GOAT），而且 AI 集成每周都在变好；Cursor Design Mode、Claude Design、一批新创业公司乃至 HTML 原型也都不错。关键是用专门用于设计的工具，并让 AI 为每样东西生成三到四个变体。
四、使用组件和库。 他说这对多数工程师应该是显而易见的：分离视图与逻辑，创建可复用组件。这不难，而且回报丰厚——你的应用会视觉上内聚，而不是一堆重复实现的按钮拼成的补丁。在 Ref 他们维护一个 /showcase 页面，让 agent 先在那里构建 UI 组件、把玩过后再接入主应用。
五、使用预览部署。 评估设计最好的方式是用真实数据。他强调即使 agent 完全按你说的做出来了，你拿到手配上真实数据，仍然可能发现它不对，总会需要一些打磨和返工。对于同时涉及前后端的大功能，预览部署会比较棘手；Ref 的做法是把前端和后端 PR 分开——后端变更用单元测试和集成测试验证，前端变更需要人工验证，而预览部署让分享链接变得容易。他们用 GitHub Action 为每个前端 PR 自动建预览部署。
六、多数 UX 问题已经被解决过了。 你应该做的是把现成的部件拿来组合。花点时间去看那些解决类似问题或传达类似理念的产品。他说他共事过的每一个厉害的设计师，做每个项目的第一步都是搜集一堆截图——你也该这么做，那是发给 agent 的绝佳上下文。
七、探索你自己的品味。 这是他说的「有趣的部分」。品味就是反思你自己对某样东西的反应；他顺带调侃了一句：反思自己的体验并不是布鲁克林 loft 派对参与者的专利，而是「创造而不是制造 slop」的必要条件。他观察到产品工程师非常擅长识别一个设计哪里不对，但很难知道怎么修——工程师缺的是从经验中积累的方案库，而建立它只需要反复尝试和反思。这个过程好玩，但也可能相当残酷，因为在东西变得足够好之前是一连串的批评轰炸。Ref 团队没有全职设计师，他们采用一种「农业脱粒式」的方法来磨练品味：把一个设计丢在中间，用棍子抽它，直到大家感觉良好为止。
需要说明的是：ref.tools 的博客是纯客户端渲染的单页应用，直接抓取只能拿到空的 HTML 骨架，Cloudflare 也拦截了第三方阅读器；以上内容是从站点的 JavaScript bundle 中提取字符串字面量还原的，因此配图说明和部分链接锚文本可能有缺失。
HN 评论精华
这个帖子只有 24 分和 12 条评论，讨论相当稀疏，这里如实呈现全部有实质内容的发言。
最受认同的一点：agent 爱加东西
seizethecheese 是本帖最高共鸣的评论：关于「agent 爱加东西」的洞察远不止适用于设计——它们在技术架构上也这样，添加不必要的守卫、为无关的边界情况增加复杂度；写作上也这样，堆砌不必要的限定和澄清。exolymph 回应说文章本身就写到了这一点，并引用了原文里那句关于「双保险、多包一层 try-catch、反复重新实现同一个工具函数」的话。
关于「约束」的一处细读
yipinwong 提出这篇文章本身「感觉可以做成一个 skill」，并指出他最欣赏的是文章对约束的处理：约束是你不能改变的东西，AI 应当遵守它。他注意到作者用的动词是「新增」或「移除」，而不是「修改/更新」——因为约束只能被增删，这一点不同于可以被修改的非功能性需求。他还说作者推荐的《Notes on the Synthesis of Form》看起来很不错，打算去读。
「我用 AI 设计出来的东西总是长一个样」
firemelt 问了一个很实际的问题：有谁知道怎样用 Claude Design 有效地设计 Web 应用？他每次让 Claude 改造他的应用，最后都得到相似的设计。这条问题下面聚集了本帖最实用的几个回答：
samtimalsina推荐了 impeccable.style，yipinwong回复说这看起来是不错的下一步，第一次见到。yipinwong同时提醒：作者的路子更定制化（也更不容易产出 AI slop），但如果你不熟悉 Web 设计可能会迷失；如果你没有 Web 设计经验只是在做原型，可以去 getdesign.md 找你喜欢的然后让 AI 用它。rfgplk给出了一套具体流程：少即是多；做出东西后剥掉所有臃肿，只留下必要的（导航栏、菜单），然后用你喜欢的字体和舒服的配色去迭代。他最推荐的一招是去 Adobe 的色轮工具里玩各种配色和谐方案，找到喜欢的组合后把字体加配色带回 Claude Design，让它套用到你精简过的设计上。jamesponddotco的做法最彻底也最有说服力：他花钱请了一位真正的设计师为他的项目做了一套设计系统，然后让 Claude 遵循它。具体来说，设计师在 Figma 里建了这套系统，并写了一份供人类使用的指南文档；他把这些文件交给 Claude（用 Claude Design）转成代码。此后项目里任何与设计有关的事情，他都让 Claude 遵循这套系统，而那份指南让他可以核对 Claude 是否严格照做了。他的评价是「效果好极了」。
其他角度
esafak 提出了一个工具链层面的痛点：现在的设计工具都在模仿 Figma 用 JSON 表示设计（这源自 JS），却不把它渲染成 HTML 和 CSS 来得到像素级准确的呈现；结果 MCP 只能想象这份 JSON 会变成什么样，而它永远不完美。他的判断是：现有工具连单向都做不准确，更没有一个能让你编辑「渲染后的视觉」并把改动准确反映回代码、或者与 Figma 同步。「这里有钱可赚。」
Vishal_Max 说自己最近在做完全用 AI 设计网站的副业项目，收获的只有失望——网站有多「AI 味」，人们又有多容易仅仅因为看到它就被劝退。
Gualdrapo 给出了本帖唯一的一句冷嘲：「这听起来就是所谓的『设计思维（design thinking）』，只不过加了 AI 和额外的步骤。」