AI 越来越懂设计后，我开始重新思考怎么用它
杭州/设计爱好者/12天前/476浏览
版权
AI 越来越懂设计后，我开始重新思考怎么用它
AI 到底应该怎么帮助设计师？
其实在 GPT-6 之前，我对所谓的“AI 提效”一直比较保守。
不是排斥 AI，而是过去实际使用下来，我经常会有一种感觉：
为了让 AI 帮我工作，我反而需要先花很多时间教它怎么工作。
写 Prompt、整理规范、制作 Skill、告诉它组件怎么使用、解释设计稿、不断纠正生成结果……
有些事情最后算下来，甚至还不如自己做得快。
但最近连续在几个真实需求中使用 GPT-6 后，我第一次比较明显地感受到了一条分界线。
并不是它突然“会设计”了。
而是：
我告诉 AI 的东西变少了，它理解我的东西反而变多了。
这件事让我开始重新思考，我们过去关于 Prompt、Skill，甚至关于“设计能力”本身的一些理解。
01 从“怎么教 AI”，到“还有什么需要教 AI”
过去讨论 AI 做设计，很容易走向一个方向：
把设计师的经验沉淀下来，做成 Skill。
比如把组件库里每个组件的使用方式、交互规范、页面规范、设计原则都告诉 AI，让它学会按照设计师的方式工作。
这个思路听起来很合理。
之前我也觉得，这是一个值得探索的方向。
但真正开始使用更强的模型后，我越来越想问：
我们真的需要把这些东西全部重新教 AI 一遍吗？
最近我尝试让 AI 使用现有组件库设计页面。
我没有告诉它：
每个组件是干什么的、什么情况下使用、具体交互规则是什么、应该和哪些组件组合……
我只告诉它几件事情：
使用哪个组件库；什么情况下允许修改组件变量；什么情况下允许拆组件；什么情况下可以不用组件。
然后让它自己处理。
实际结果比我预想得好很多。
它已经可以通过组件名称、属性、结构、已有页面和上下文，再结合本身已有的 UI/UX 知识，推断大量组件的使用方式。
这让我开始重新思考：
什么东西真的值得被 Skill 化？
我现在并不是觉得 Skill 没有价值。
而是如果模型已经能够从环境和上下文中推断出来，我可能没必要再花大量时间把这些通用知识重新写一遍。
相比之下，公司内部的特殊业务规则、隐藏约束、设计边界，以及模型无法从当前环境知道的信息，可能更值得明确提供给 AI。
所以对我来说，Skill 的价值可能正在从：
尽可能完整地教 AI“应该怎么做”
逐渐转向：
补充 AI 自己无法知道的东西。
02 我开始怀疑，我们是否高估了“蒸馏设计师”的可能性
这里又延伸出了另一个问题。
我们经常会说：
把优秀设计师的经验沉淀下来，让 AI 学会优秀设计师的设计方式。
但我越来越觉得，这件事情可能没有想象中那么简单。
设计当然存在大量可以总结和复用的知识。
组件规范、间距、交互原则、设计系统、流程规范……
这些都是显性知识，也都有沉淀价值。
但即使只是这些东西，如果真的完整整理出来，可能都足够写一本书。
更何况，设计工作中还存在大量难以被完整语言化的东西。
有时候我看到一个页面，第一反应只是：
“这里感觉不太对。”
然后开始调整。
改了几个版本以后，某一个版本突然让我觉得：
“这样好像就对了。”
为什么？
当然可以解释。
可能是因为用户需要保持上下文，可能是因为任务频率比较高，也可能是因为这样能够减少操作层级。
这些理由可能完全成立。
但如果认真回忆，我最初想到这个方案的时候，真的经过了一套这么完整的逻辑推导吗？
未必。
所以我现在越来越觉得：
方案是怎么被想到的，与方案为什么合理，可能是两件相关但不完全相同的事情。
03 设计并不总是一条完整的理性推导链
我们有时候会把设计过程描述成：
用户问题 → 设计原则 → 分析 → 推导 → 得出方案
但真实工作未必总是这么线性。
很多时候可能更接近：
长期经验和直觉先让我产生一个方向 → 把它做出来 → 判断它是否成立 → 再通过业务、用户和设计原则不断验证和修正。
最终在设计评审里，我们当然可以清楚地解释：
“为什么这个方案成立。”
但这套解释未必完整还原了：
“这个方案最开始是怎么被想到的。”
这并不是说设计没有逻辑。
恰恰相反，人的每一个判断背后通常都有长期经验、业务背景和历史案例在发挥作用。
只是这些东西经过多年积累以后，可能已经变成了一种很难被完整展开的模式识别和直觉。
所以我并不认为设计经验无法沉淀。
我只是越来越觉得：
能够被明确写出来的规则，可能只是设计能力的一部分。
这也是为什么，我开始对“把一个设计师完整蒸馏成一个 Skill”这件事保持谨慎。
04 也许 AI 不需要我们先把自己完全解释清楚
那么问题来了。
如果设计师自己都很难把自己的设计判断完整总结出来，AI 又应该怎么学习？
以前我会觉得：
设计师做完方案以后，把“为什么这么设计”告诉 AI，AI 就可以逐渐学习设计师的判断。
现在我觉得这个想法可能也需要稍微修正。
AI 未必需要设计师先把自己的经验整理成一套完整方法论。
它也可以经历：
真实需求 → 尝试方案 → 被设计师否定 → 修改 → 再尝试 → 被接受 → 最终方案
设计师甚至不一定每一次都能够给出非常完整的解释。
有时候只是：
“这个不对。”
“这个方向可以。”
“这里换成抽屉试试。”
“这个信息不用这么突出。”
“这个版本可以了。”
这些选择和反馈本身也是信息。
所以相比：
让设计师把自己的判断逻辑全部教给 AI。
我现在更愿意把它理解成：
让 AI 经历更多设计师真实做判断的过程。
案例、试错、修改、接受、拒绝，以及背后能够被表达出来的原因，共同构成了 AI 理解设计判断的材料。
至于这种方式最终能让 AI 学到多少，我现在也没有答案。
但至少它让我开始不再执着于：
一定要先把自己总结成一套方法，才能教给 AI。
05 我甚至开始重新理解“会设计”这件事
设计这个行业还有一个很有意思的特点：
设计的好坏很难被准确量化。
代码能不能运行、接口有没有报错、测试有没有通过，都存在大量相对明确的反馈。
但一个页面到底是 70 分还是 80 分？
A 方案和 B 方案到底哪个更好？
很多时候没有一个绝对标准。
甚至我一直有一个比较个人的感受：
设计不只是看你画得有多好，有时候也看你能不能把自己的设计讲清楚。
同样一个方案。
一个人说：
“我感觉这样体验比较好。”
另一个人说：
“这里减少一级操作，是因为这是一个高频连续任务，如果每次进入二级页面，用户都需要重新建立上下文，所以我把核心操作提升到了当前层级。”
后者在设计评审里显然更容易让人理解这个方案为什么成立。
但现在我会把这件事再拆开一点：
设计能力和设计表达能力有关，但并不是同一种能力。
一个设计师很会解释自己的方案，并不代表这套解释就是方案产生时完整的思维路径。
反过来，一个设计师可能有很强的设计直觉，也未必能够把所有隐性的判断完整语言化。
这可能也是设计很难被完整规则化的原因之一。
06 GPT-6 给我最大的变化，是人与结果之间的“翻译层”开始变薄
这让我想到 AI 绘画的发展。
早期使用 AI 绘画的时候，大家需要学习大量 Prompt。
关键词、权重、Negative Prompt、画质词、风格词、各种参数……
那时候甚至形成了一套专门的“提示词技巧”。
人需要学习：
怎么用机器更容易理解的方式表达自己的想法。
后来模型越来越强。
我们开始可以直接用自然语言描述：
“给我画一只坐在窗边晒太阳的橘猫，下午暖色阳光，照片质感。”
剩下的事情模型自己理解。
人的意图和最终结果之间，那层为了迁就机器而存在的“翻译层”开始变薄。
最近使用 GPT-6 做设计相关工作，我也有类似的感受。
以前可能是：
设计意图 → Prompt → UX 规则 → 组件规则 → Skill → AI 执行
现在越来越接近：
设计目标 + PRD + 设计稿 + 组件库 → AI 自己理解 → AI 执行
比如最近做交互 Demo。
以前 AI 做出来以后，我需要修改很多东西。
但最近部分真实需求里，最终结果已经能够非常接近我的设计稿。
再比如交互说明。
我没有专门告诉它应该“怎么阅读设计稿”。
只是给它静态设计稿、页面之间的连线和布局关系，它已经可以反推出大部分交互意图。
这些当然只是我最近几个真实需求里的个人体验，并不是什么通用测试结果。
但它确实让我第一次明显感觉到：
AI 越来越不需要我教它“怎么理解我”。
07 但这不代表现在已经可以把设计完全交给 AI
这一点我反而觉得需要说清楚。
至少目前，我完全不认为 AI 已经能够稳定完成一整套复杂业务、高精度、可以直接交付开发的 Figma 设计。
尤其是复杂 B 端系统。
一两个页面做得不错，和连续十几个页面保持组件、状态、权限、业务规则和交互逻辑一致，是完全不同的难度。
AI 目前让我感觉进步最大的地方，更多还是：
理解已有信息、补充遗漏、探索方案、执行已有设计意图。
但如果从一个高度模糊的业务问题开始：
定义问题 → 找到设计目标 → 发散可能性 → 做判断 → 进行取舍 → 必要时重新理解问题 → 最终形成方案
这仍然是另一件困难得多的事情。
所以我现在并不是觉得：
“AI 已经会做设计了。”
而更像是：
“AI 已经开始真正进入我的设计工作了。”
这两句话对我来说差别很大。
08 我也开始重新思考：产品真的需要用 AI 帮设计师做 Demo 吗？
之前有一种想法：
设计团队可以把自己的经验沉淀成 Skill。
产品使用这个 Skill，就可以把自己原本可能只有 50～60 分的 Demo，提高到 70～80 分。
没有设计资源的项目可以直接使用；有设计资源的项目，也可以让产品提前制作一个更好的 Demo，帮助设计理解产品思路。
这个目标本身我能理解。
但我对具体实现方式一直有一些不同想法。
首先还是前面的问题：
我不确定设计师能够把自己的设计能力完整蒸馏成一个 Skill。
但更重要的是：
产品提前给设计一个完成度很高的 Demo，一定是在帮助设计吗？
我现在觉得，这取决于 Demo 出现的阶段，以及我们把它当成什么。
09 AI 让方案出现得越来越快，但问题未必已经理解清楚
之前就发生过一个让我印象比较深的事情。
一个需求里，业务原始诉求并没有要求 Banner。
产品用 AI 生成了一个 Demo。
AI 根据常见页面模式，在页面里主动生成了一个 Banner 区域。
产品看到以后觉得：
“这里好像确实应该有一个 Banner。”
后来这个 Banner 反而被加进了需求。
这件事让我意识到一个以前不太明显的问题：
AI 大幅降低了方案生成的成本，但我们对方案的判断成本并没有同步消失。
AI 生成 Banner 本身并没有错。
它也可能恰好提出了一个很好的设计方向。
真正值得注意的是：
这个 Banner 到底是业务事实、明确需求，还是 AI 根据常见模式提出的一个设计假设？
如果没有意识到这个区别，AI 对解决方案的一次猜测，就可能在不知不觉中被当成需求本身。
而且被锚定的不一定只是设计师。
产品自己可能会。
业务也可能会。
本来我们还在讨论：
“到底需要解决什么问题？”
当一个完成度很高的 Demo 摆在面前以后，讨论很容易自然变成：
“这个 Banner 放什么内容？”“这个按钮叫什么？”“这里是不是再增加一个字段？”
大家可能在没有意识到的情况下，从
问题空间
进入了
方案空间
。
所以我并不反对产品使用 AI 做 Demo。
我真正开始警惕的是：
Demo 在什么阶段出现，以及大家把它当成什么。
10 Demo 可以是很好的沟通工具，但不一定需要成为设计前置方案
如果产品脑子里已经有一个非常具体的想法，有时候写一千字，确实不如直接做出来。
这种情况下 Demo 非常有价值。
它可以表达：
“大概是这样的业务过程，你不用照着设计，我只是想让你快速理解我的想法。”
这时候 Demo 是一种非常高效的
沟通工具
。
但如果问题本身还没有被充分理解，一个单一、具体、完成度很高的 Demo 过早出现，也可能让大家过早围绕这个方案收敛。
所以对我来说：
Demo 作为沟通和探索工具，很有价值。Demo 过早成为默认设计方案，则需要谨慎。
有时候在需求早期，流程图、状态图、低保真框架，可能反而比一个非常精致的高保真 Demo 更适合讨论问题。
因为不同阶段需要解决的问题，本来就不一样。
11 相比帮设计“画一遍”，我更希望产品用 AI 把问题梳理完整
这也是我现在对 AI 协作理解变化比较大的地方。
以前我们很容易思考：
上游怎么通过 AI 帮下游多做一点？
现在我越来越觉得：
帮助下游，不一定意味着提前替下游完成一部分工作。
产品最了解的是：
业务背景、需求来源、字段、数据逻辑、权限、状态、历史问题和上下游关系。
这些东西恰恰也是设计师真正需要的信息。
设计过程中经常出现这样的情况：
做到一半发现还有一个状态。
去问产品。
继续做。
又发现某个角色没有权限。
再问。
做到 Demo 才发现还有历史数据兼容问题。
继续改。
如果 AI 可以在 PRD 阶段帮助产品：
梳理字段 → 梳理状态 → 梳理权限 → 找逻辑冲突 → 推演异常情况 → 补边缘场景 → 主动反问 → 补齐需求
最后交给设计一个：
逻辑更清楚、边界更明确，但仍然保留设计开放空间的问题。
我觉得这本身就是非常大的提效。
设计不一定需要产品提前帮忙完成一个“80 分设计”。
如果文字背后的业务逻辑已经非常清楚，设计师反而拥有更完整的信息和更开放的方案空间。
12 我下一步想探索的，反而不是让 AI 给我生成更多东西
最近我还发现了另一个很有意思的问题。
以前我会让 AI：
“帮我完整分析一下这份 PRD。”
然后 AI 会给我很多内容。
需求总结、页面清单、字段、流程、风险、边缘场景……
看起来非常全面。
但实际使用的时候，我发现：
我根本不会认真看完。
我真正会看的往往只有：
需求背景是什么？
有哪些边缘场景？
PRD 漏了什么？
有没有什么问题是我在设计之前必须知道的？
这让我意识到：
AI 能生成多少内容，和 AI 真正帮我减少多少工作，不是一回事。
所以我下一阶段反而想探索：
怎么让 AI 少给我东西。
不是继续要求：
“把这份 PRD 分析得更加全面。”
而是尝试：
“你自己把它理解完整，只把真正需要我注意和判断的问题告诉我。”
如果 AI 找到了 30 个问题，其中 20 个是常规问题，它已经能够处理；7 个可以从现有规范和上下文中找到答案；最终只有 3 个真正涉及设计判断——
那么我真正需要看到的，也许只有这 3 个。
当然，这目前更多是我想继续验证的一种工作方式。
但它让我开始用另一种标准理解“AI 提效”：
不是 AI 替我生成了多少，而是它替我消化了多少。
13 从“AI 能帮我做什么”，到“还有什么必须让我参与”
写到这里，我发现自己使用 AI 时提出的问题已经慢慢发生了变化。
以前我不断探索：
AI 能不能分析 PRD？
AI 能不能画 UI？
AI 能不能写交互说明？
AI 能不能做 Demo？
AI 能不能使用组件库？
现在我越来越想问的是：
在一个真实设计需求里，到底还有哪些事情必须让我参与？
AI 能从上下文理解的，就让它自己理解。
AI 能处理的常规问题，就尝试让它自己处理。
AI 能从组件库、设计稿和已有案例里推断出来的，也许就不需要我再重新教一遍。
真正涉及业务取舍、设计判断、方案选择、开放问题，以及 AI 无法知道的内部约束时，再让我介入。
这并不是说我认为 AI 已经能够自主完成设计。
恰恰相反。
我只是开始重新寻找人与 AI 之间更合理的分工边界。
写在最后：我暂时没有答案
写到这里，我其实并没有得出一个“AI 应该怎样做设计”的明确答案。
我也不知道继续发展下去，Skill 会变成什么样，AI 最终又能承担多少设计工作。
这些都还需要继续验证。
但至少在最近这段真实使用里，我越来越少问：
“我要怎么把自己的方法全部教给 AI？”
而越来越多地问：
“这件事情，AI 是真的不知道，还是其实已经不需要我教了？”“这部分工作真的需要我参与，还是我只需要在关键节点做判断？”
这可能是 GPT-6 之后，我自己使用 AI 最大的一次思路变化。
我不再急着让 AI 学会“像我一样设计”。
我更想先看看，当我逐渐减少那些不必要的指导以后，它究竟能自己走到哪里。
～～ 以上内容纯个人牛马胡思乱想 ～～
7
举报
声明
3
分享
相关推荐
评论你的想法~
表情
喜欢TA的作品吗？喜欢就快来夸夸TA吧！
推荐素材
你可能喜欢
相关收藏夹
登录注册
7登录即可同步推荐记录哦
3登录即可加入我的收藏
评论登录即可评论想法
分享分享