设计师该不该写代码？一个被问错的问题——AI时代的设计价值与慢思考

设计师该不该写代码？

类似的话题隔几年就会火一次。最近随着 Cursor、v0 这些 AI 工具的成熟，用代码做设计变得前所未有地容易，于是这话题在设计圈又成了热门话题。

Linear 的创始人 Karri Saarinen 最近写了一篇文章，他的观点让我挺有共鸣：这个问题本身就问错了。

【1】问对问题

最让我共鸣的其实是他思考问题的框架：

我学会的第一件事就是：先质疑问题本身，而不是把它当作既定假设。如果有人让我做一个东西，我会先问：这是一个真问题吗？如果我们不做这个会怎样？是谁定义了这个问题？

就像前几天我分享的自己的失败的 Agent 落地故事，就是问题没有定义清楚，错把重点放在如何构建 Agent 上，而不是我们的设计系统是要解决什么问题？Agent 能带来什么价值？

还有日常工作中，项目拖延或失败，最常见的原因不是方案不好，而是大家脑子里想的根本不是同一个问题。

人们在解决方案上无法达成一致，是因为他们脑子里想解决的问题根本就不一样。最终的方案变成了针对许多不同问题的妥协，而不是针对一个核心问题的漂亮解答。当利益相关者太多时，情况会变得更糟。

你以为在讨论“怎么解决 A”，他以为在讨论“怎么解决 B”。方案当然对不上。最后的妥协版，变成了同时解决 A、B、C 三个问题的缝合怪，哪个都没解决好。

职场上多少惨痛的教训都来源于没有问对问题。

回到开头说的“设计师该不该写代码？”的问题，Karri 认为，争论这个问题太表面了。真正该问的是：“AI 时代，我们对设计师的期待会变成什么？”

设计师会变成工程师吗？工程师会被期望承担设计职责吗？以后还会有“设计负责人”和“工程负责人”的区分，还是会合并成一个“产品工艺负责人”？

这些问题归根结底问的是我们对“设计的价值”到底怎么理解。

如果你觉得设计就是把按钮放到屏幕上，那用什么工具确实不重要，越快越好。

但如果设计还包括别的东西：比如想清楚为什么要做这个功能、这个功能的整体形态应该是什么？那工具的选择就不只是效率问题了。

这里有个微妙的问题：工具会塑造行为。

当你打开 Figma，你会想着画界面；当你打开 VS Code，你会想着写逻辑。工具暗示了一个起点，而起点往往决定了你会跳过什么。如果代码成为设计的默认起点，那些“动手之前的思考”会不会被悄悄挤掉？

那什么才是动手之前应该想清楚的？Karri 分享了他的一套方法。

【2】Karri 的设计方法论

Karri 不是科班出身，二十年实战自学成才。他之前在 Airbnb 做设计系统，后来创办了 Linear。他分享了自己做设计的一套方法，我觉得很有参考价值。

简单说，他把设计分成三个阶段：问题、概念、执行。

第一步是质疑问题本身。

接到一个需求，他第一反应不是动手，而是问：这是真问题吗？如果不做会怎样？谁定义的这个问题？

这听起来有点“杠精”，但他发现，设计项目拖延或失败，最常见的原因不是方案不好，而是大家对“到底要解决什么问题”没达成共识。每个人脑子里想的问题不一样，自然对方案有不同意见。最后做出来的东西，往往是各种问题的妥协，而不是一个问题的漂亮解法。

他有个小技巧：给利益相关方展示方案时，先复述一遍你理解的问题。如果有人皱眉头或者提出异议，先停下来，把问题对齐了再继续。

第二步是概念探索。

问题想清楚了，接下来要想的是：这个东西的整体形态应该是什么？

这一步很容易被跳过。很多人拿到需求就开始画界面、写代码，但 Karri 认为，在动手之前，应该先在更高的抽象层面想清楚几种可能的方向。

他举了 Linear 做“项目”功能的例子。问题是明确的：公司需要用项目来组织工作。但项目在产品里可以有很多形态——它可以是一个大任务下面挂一堆子任务，可以是一个标签或文件夹，也可以是一个独立的实体。

这几种形态，不需要写代码就能比较取舍。它们背后是不同的产品理念。Linear 团队认为项目是公司最重要的工作单元，产品围绕项目发布，团队围绕项目协作，所以项目应该是一个独立的、有自己“长相和性格”的东西，而不是降格成一个标签。

这个决策发生在概念层面，是在写代码之前就想清楚的。

第三步才是执行。

把概念落地成真实可用的东西。这一步确实需要代码，需要和材料搏斗。但因为前面已经有了方向和信心，遇到细节问题时，你知道自己在往哪推。

Karri 用了一个很妙的比喻：前两个阶段像是给 AI 写 prompt——你在构建目标、上下文和约束条件；执行阶段，是你引导 Agent 完成具体任务。prompt 写得好，输出才靠谱。

用过 Claude 或者 ChatGPT 的人应该有体会。你给 AI 一个模糊的指令，比如“帮我写个文章”，它会给你一堆泛泛的东西。但如果你先花时间想清楚：这篇文章是给谁看的、要解决什么问题、有什么约束、想要什么风格——然后把这些写进 prompt 里，AI 的输出质量会好得多。

Karri 说的“概念阶段”就是这个意思。你不是在画图，你是在建立一个清晰的“问题定义”：我们要解决什么、为什么这样解决、边界在哪里。这套东西，就是你后续所有工作的“prompt”。

那“执行阶段引导 Agent”是什么意思？

用过 AI 写代码或者写文章的人知道，AI 不是一次就能给你完美答案的。它会给你一个初稿，你看完说“这里不对，换个方向”，它再改；你又说“这个细节再深入一点”，它再调。整个过程是你在不断引导、纠偏、做判断。

设计的执行阶段也是一样。你打开 Figma 或者编辑器开始做，做着做着发现这个交互不顺、那个布局太挤、这个概念用户理解不了。你得不断做决策：这里妥协一下，那里坚持原来的想法，这个地方干脆推翻重来。

这个过程不是机械执行，而是持续的判断和引导。

【3】Karri 真正担心的是什么

Karri 说，他担心的不是代码，也不是工具。他担心的是“慢思考”的消亡。

当工具让执行变得太容易，人们会跳过问题定义和概念探索，直接开干。迭代是快了，但迭代的方向可能从一开始就没想清楚。

更麻烦的是，这会变成一种文化。当“直接用代码做设计”成为默认选项，当组织开始用“代码产出”来衡量设计师的贡献，那些花时间思考问题、探索概念的人，会显得很慢、很没效率。久而久之，没人愿意做那种“慢功夫”了。

他的原话是：我们开始贬低设计背后的“为什么”，而只看重产出。

最后的结果是什么？产品会越来越同质化。因为大家都在用差不多的工具、差不多的流程、差不多的节奏，在差不多的时间压力下做差不多的决策。那些独特的、深思熟虑的产品，会变得越来越稀少。

【4】我的看法

Karri 这套方法论，我觉得在很多场景下是对的，尤其是他做的那类产品——B2B 工具，用户需求相对清晰，产品需要长期打磨。

但它也有边界。

在 C 端消费产品、游戏、社交这些领域，用户动机很难预测，有时候“先做出来试试”反而是更高效的探索方式。快速原型、快速验证本身也是一种思考，只是形态不同。

Karri 担忧的“用代码做设计会让人跳过慢思考”，问题不在于用什么工具，而在于人有没有思考的习惯和空间。

AI 时代，执行会越来越快、越来越便宜。但“写 prompt”的能力——也就是定义问题、建立上下文、明确方向的能力反而会变得更值钱。因为 Agent 跑得再快，如果方向不对，也只是更快地跑偏。

AI 时代需要的，可能不是“慢下来”，而是一种新能力：在更快的节奏中保持思考深度。 你可以用 AI 快速生成十个方向，但你得有判断力选出对的那个。你可以用代码快速原型，但你得先想清楚要验证什么假设。

工具变了，节奏变了，但 “想清楚再动手” 这件事的价值没变。

Karri 文章最后写道：

设计从来不是关于按钮是什么、放在哪。设计是找到对的问题、对的意图、对的愿景。你今天做的每个功能，都应该是迈向那个愿景的深思熟虑的一步。

这话放在 AI 时代，依然成立。