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

从 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 指南,敬请关注 ⟡˖
