🌲 Design to Build | AI 时代的设计师

2026-04-10T18:43:51Z

我在设计行业工作了七年。除去各种用户调研和产品定义，主要的任务是画图：画线框、画视觉稿，交给开发，然后等他们实现。像是一个翻译，把需求翻译成想法，把想法翻译成图稿，最后等别人把图稿翻译成代码。

从 2024 年起，我的工作方式发生了很大的转变。现在我主要用的工具是 Claude Code、Figma Make 和 ChatGPT/Gemini，它们重建了我的整个工作流。

我用一个可以运行的 demo 代替了传统的静态交付和 Figma 的连线原型，不再到组件库里找来找去，而是把设计系统接入 Claude Code，让它帮我生成界面。我在 ChatGPT 创建项目，然后做调研和信息整合。这个过程里，我不再像一个翻译，更像一个指挥：发出指令，把我的意图和经验转化成 AI 可以执行的任务，同时用老员工的判断力评估它的产出。在最核心的部分，我亲自上手。

七年的经验没有过时，只是它起作用的地方变了，而作为设计师的技能和职能也迎来了一次重大升级。

i. 培养在代码中的「设计手感」

设计师一直有一种特殊的被困感：你能想象得到，但你造不出来。或者更准确地说，你产出的和真正运行的，并不是同一个东西。

Figma 是很好的工具，它可以让我们慢下来思考，因为它是一个中间媒介。你在上面建立的手感是「空间和视觉」的，通过拖动图形来感知变化，其实和在纸上是一样的。而真实的产品里，设计手感建立在「系统和时间」上：数据填进来之后整个界面的变化，动画的阻尼，操作与操作间的逻辑链条。这两种手感不太一样。

那么我们可以如何培养在代码里的「设计手感」？

显化你的隐性知识↘

AI 编程降低了设计初稿的成本，难点在于生成高质量 First shot 以及后续进行有效的迭代。这个过程考验的是，你能不能把自己的隐性知识传达给 AI。

AI 能理解的是这个世界的显性知识：网上可查的资料、已经被写下来的文档、已经被结构化的概念。而你在工作中运用的，很大一部分是通过多年实践积累出的隐性知识。它更像是一张个人的知识图谱：有公开的部分，也有只有你自己知道的那些判断依据、经验直觉、和「为什么这样做才对」的隐藏逻辑。如果不把这些隐性知识传递出去，AI 的产出就会乏善可陈。

对此我们可以使用 3C 框架，即 Context、Components、Criteria。

Context（背景）：这决定了 AI 能看到的一切。你需要把项目的背景信息完整地传递出去：你在做什么、为谁做、约束条件是什么、已经做过哪些决定。在长期的项目里，我会直接在项目文件夹里建一个 context 文件，让 AI 每次都能读取，并保持更新。

Components（工具）：你要给 AI 执行任务所需的工具。大语言模型本身有推理能力和网络检索能力，但更专业的任务，比如代码审查、前端设计、单元测试，它需要额外的剧本。这时候就要调用对应的 Skills 或者配置 MCP。也就是说，不要假设 AI 本身具备完成你任务的所有能力，你得把工具递到它手上。

Criteria（标准）：这是对输出质量的衡量。一方面是告诉 AI 要生成什么，另一方面同样重要的是告诉它不能生成什么，反向约束有时候比正向指令更有效。另一方面是对格式、风格、准确性设定具体的标准，并建立一个让 AI 自己评判输出的机制。比如我会让 AI 在产出界面设计后，自查有没有用默认的蓝紫色、有没有用 Arial 这种默认字体，以此判断它有没有在生成 AI slop。

有了这三层，你脑子里那些平时说不清楚的判断标准和依据，就可以毫无保留地传递给 AI，它的产出也会有质的变化。

亲自跑一遍↘

眼睛学会和脑子学会是两码事情，虽然现在有无数的 AI 教程，但最好的学习方式还是自己下场做点东西。

具体来说，你需要亲自经历这些：让 AI 生成项目架构，看它怎么组织文件和模块；要求它写测试，看它对边界情况的理解；顺着报错一路 Debug 下去，理解错误信息在说什么。跑通一次之后，你会发现之前对技术的很多恐惧其实是想象出来的。

而更重要的是，只有亲自做过具体的东西，你才能总结出属于自己的一般规律，知道什么情况下该怎么做。比如当 Agent 一直围绕一个 bug 打转，这时可以借助其他 AI 产出解题思路，跳出失败循环。这种判断力/经验可以从别人那里学到，但更多源于自己的积累。

当你 Vibe coding 了 5 个产品后，就能感受到一种轻微的「手感」，本质是基于状态的肌肉记忆。

ii. 重构设计流程

Claude 的设计负责人 Jenny Wen 在 Lenny's Podcast 上提出传统的设计流程（调研-发散-收敛-交付）已死。具体表现在：

工程速度碾压了线性的设计流程；
设计师没有时间再去「精雕细琢」静态视觉稿；
长期的「设计愿景」变得不切实际。

这样看来，设计流程的消亡其实是被工程师极度膨胀的执行力所「倒逼」的，同时夹杂一些科技行业惯有的夸大其词。传统的发散-收敛流程并没有失效，症结在于：它假设每一步都需要大量的前期准备才能推进到下一步，因为做一个 Mockup 或者 Demo 的代价很高。而这个假设，现在已经不成立了。

直觉 → Demo → 必然感↘

以前，严谨的前期调研是必要的，因为做出一个可以被验证的东西太费力了。现在这个成本几乎降为零，整个游戏规则因此改变。资深的产品人可以依靠直觉生成一个 Demo，然后用这个 Demo 去验证判断，而不是在白板前空谈「这个方向对不对」。

更关键的是，一个真实跑在浏览器里的 Demo 会产生一种特殊的说服力。前 Facebook 设计师 Cleo 称之为「不可抗拒的必然感」（Aura of Inevitability）。当一个设计理念不再是静态的视觉稿，而是已经通过真实的代码构建出来并能实际运行时，它就会产生一种强大的「必然感」。在这种情况下，团队很难再去争论「我们该不该做这个」，因为它已经近乎存在了，于是会自然而然地觉得可以去实现它。

静态的图稿做不到这件事，只有真实运行的原型才有这种重量。

回归「第一性原理」↘

在 AI 出现之前，大多数设计师很难真正接触到软件运行的底层逻辑，更多停留在它的抽象层：视觉，交互，信息架构。这不是能力问题，是门槛问题。光是把设计本身做好、把原型跑通，就已经耗去了大半的精力，没有余地再往深处想。

AI 改变的，恰恰是这个比例。它把「如何实现」的成本压到了最低，反而把时间和认知资源还给了设计师，让我们可以花更多力气去想一个更根本的问题：这个东西究竟应该是什么。
而当你开始认真问「是什么」，第一性原理就会变得锋利起来。

这个问题有两层。第一层是产品的底层概念，软件到底以什么形式被呈现出来。

TikTok 的本质是一个自动循环的视频列表；
Notion 的核心是块（Block），页面和数据库；
Cursor 的核心是代理、编辑器和模型。

这些概念看起来简单，但只有看透它们，你才能找到功能之间最简单、最有弹性的联系。第二层，是在理解了底层之后，你可以开始「推导」一个产品的理想状态，从内向外生长出逻辑，而不是对照竞品逐条核实功能清单，在别人划好的地图上做选择。

这种理解给了设计师真正的空间，去探索产品「最大可能性的边界」。

iii. 为自己搭建脚手架

设计师在工作中难免遇到流程有摩擦、工具不顺手的时候。以前的应对方式基本只有两种：忍着，或者花更多人工成本硬撑过去。等待新工具出现是一种奢望，更多时候你只能将就。
但现在，设计师可以随时根据手头的任务需求，自建(Bootstrap)专属的脚手架工具。

以我自己为例，以前找 icon 的时候需要在网上到处翻找，这是一种典型的重复性消耗。后来我用 Figma Make 做了一个专属 icon 库，整合了网上开源的各类 icon，可以在里面调颜色、粗细、风格样式，直接导出 PNG 或 SVG。这件事从「每次都要做」变成了「做过一次就完了」。这是最小颗粒度的脚手架，但它实实在在改变了一个环节的摩擦。

Cursor 的设计负责人 Ryo Lu 也做过类似的事，只是规模大了一个量级。他提到设计师经常被复杂的后端服务器和生产环境阻碍，为此他给自己搭了 Baby Cursor，一个高度简化的、脱离了真实业务负担的「微型沙盒」（miniature environments），让他可以不受限制地快速验证想法。

这背后有一个可以复用的判断：当你发现工作流里某个环节在反复消耗精力，而且它是重复性的，那就是你应该造工具的信号。花一次性的成本搭好，后续省下来的是真正可以用于判断和创作的时间。

以前这种事只有会写代码的人能做。这个门槛，现在已经不存在了。

写到这里我意识到一件事。这篇文章里我反复在说的其实是同一句话：

AI 没有让设计师变得不重要，它让「设计师是谁」这个问题变得比以前更重要。

工具谁都能用，而你是谁决定了你会用它来 Build 什么。

这也是为什么这一系列的 Newsletter 叫做 Design to Build。

后续我会分享更多 Design + AI 的 No code 指南，敬请关注 ⟡˖