当前位置：首页>java>设计师用AI编程,最重要的是选对工具

设计师用AI编程,最重要的是选对工具

2026-02-05 00:44:57

这两天，我看到Inflight联合创始人Michael Riddering（大家都叫他Ridd）在Dive Club上分享了一个特别实用的话题：设计师用AI编程时，怎么选工具？

说实话，这个话题戳中了很多人的痛点。现在AI编程工具层出不穷——Claude、Cursor、Lovable、Figma Make、Conductor......每周都有新产品发布，每个都说自己能"10分钟做个APP"、"不用写代码就能开发"。

问题来了：工具越多，选择越难。

你可能遇到过这种情况：看到别人用某个工具做出了很炫的效果，自己兴冲冲下载试用，结果发现根本不是那么回事。不是工具不好，而是你的需求和工具的定位根本不匹配。就像你要钉个钉子，别人递给你一把电锯。

Ridd的分享特别有价值，是因为他不是在"推荐工具"，而是在讲"怎么选工具"。他有15年的产品设计经验，是前Maven的创始设计师，现在除了创办Inflight，还主持着Dive Club这个设计圈公认的高质量播客。更重要的是，他会编程，能自己做原型，每天在Inflight提交好几个PR。

所以他不是纸上谈兵，而是真刀真枪在用这些工具干活。

他分享了一个特别清晰的"四象限选择模型"，把不同的任务和对应的工具梳理得明明白白。看完之后我发现，这套方法不只适用于设计师，产品经理、运营、甚至写作者都能用。

核心思路就一句话：工具要匹配任务，而不是追风口。

接下来，我详细跟你聊聊这个"四象限模型"到底是怎么回事。

四象限模型：什么情况用什么工具

Ridd的选择模型特别简单，就是一个2×2的矩阵，两个维度：

横轴：任务规模大不大？（从快速修bug到从零开发大项目）纵轴：你有没有现成的代码库？（从零开始还是迭代已有产品）

这样就切分出四个象限，每个象限适合用不同的工具。

左上角：快速修复bug（有代码库 × 小任务）

典型场景：你的产品已经上线了，突然发现几个小bug，或者需要微调一些功能。比如按钮颜色不对、某个交互逻辑有问题、文案需要调整。

听起来好像没什么大不了的？但实际用起来，这个功能解决了一个特别致命的问题：等待AI回复的时间浪费。

以前你处理多个bug的流程是这样的：

给AI发个提示，让它修第一个bug
等AI写代码......（你盯着屏幕发呆）
AI写完了，你审查代码，发现还行
提交代码
开始处理第二个bug
又得等AI写代码......

这种"停-启-停-启"的节奏特别破坏心流状态。研究数据显示，被打断后，平均需要23分钟才能完全恢复专注。更糟糕的是，另一项研究发现，AI编程助手在某些任务上反而让有经验的开发者慢了19%，因为管理AI交互的开销抵消了代码生成的速度提升。

Conductor要解决的就是这个问题。

你可以一口气把5个bug的任务都发出去，让5个AI同时工作。Conductor会为每个任务创建独立的工作空间（技术上叫git worktree，共享代码库但互不干扰），你可以在它们工作的时候去喝杯咖啡，回来后一起审查代码，批量提交。

这就像你去银行办业务，以前只有一个窗口，你得排队一个一个办。现在突然开了5个窗口，5个业务同时办理，你说效率能不高吗？

但更重要的是角色转变：你从"串行任务执行者"变成了"并行工作流指挥者"。你不再问"下一步做什么"，而是问"哪些任务可以并行跑"。

Ridd说，他早上经常这样批量处理问题，在任务管理工具里找出一堆小任务，用Conductor并行处理，一两个小时就能搞定。而且他几乎把所有提示都用语音输入，比打字快多了。

关键点：Conductor还内置了代码审查功能。你可以让另一个AI帮你审查代码，相当于有了个"AI同事"帮你把关。对于不是资深工程师的设计师来说，这是个双重保险。

左下角：小规模原型（无代码库 × 小任务）

典型场景：你想快速验证一个想法，做个简单的原型给团队看看。不需要完美，不需要连接真实数据库，只要能展示核心交互就行。

推荐工具：Lovable、Figma Make、Dessn

这个象限的工具选择比较灵活，取决于你的具体需求：

Figma Make：如果你已经在Figma里设计好了UI，用这个最快。它能从你的Figma设计直接生成可交互的代码原型。适合那种"设计稿已经有了，只是想加点交互"的场景。

Lovable：适合处理10-20次提示的中等规模原型（这是Ridd的经验判断）。他特别提到，Lovable跟Lottie、Rive这些动画工具配合得很好。如果你的原型需要一些动效，Lovable是个不错的选择。

Dessn：这是个比较新的工具，它的特别之处是能连接到你已经上线的产品代码，提取你已有的组件和样式，然后让你在这个基础上设计原型。对于已经有一套设计系统的团队，用Dessn可以保证原型和实际产品的风格一致。

但是——这里有个大坑。

Ridd自己踩过这个坑，他特别强调：不要试图在这些AI原型工具里重建你的生产系统。

有个数据特别说明问题：最近的研究显示，73%的AI生成原型在真实使用的30天内失败。

为什么失败率这么高？因为AI原型和真正能上线的代码之间，有几个致命的差异：

数据结构撑不住：AI擅长生成"对当前用例有效"的代码，但不擅长预测未来需求。比如一个应用，50个测试用户用得挺好，但数据模型有根本问题：用户数据存储成一大团，没法扩展；关键字段没索引，后续没法搜索。有经验的开发者会本能地问："当用户有10,000条数据时会怎样？"但AI不会，它只关注"让当前功能工作"。

安全漏洞：AI生成的代码往往过于信任用户输入，没有充分的验证和权限检查。正常路径工作正常，但边缘情况呢？用户能不能通过修改URL访问别人的数据？

没有测试和错误处理：原型只考虑"正常路径"，没有边缘情况处理，没有自动化测试，没有监控。但真实产品需要考虑所有可能出错的地方。

为什么会掉进这个坑？

本质上是因为AI工具降低了"看起来很好"的门槛，但没有降低"真正能用"的门槛。你以为跨过了80%的距离，其实只跨过了20%。

主要有三个心理陷阱：

陷阱1：打磨的诱惑
AI工具让"让东西看起来很好"变得太容易了。你做着做着就上头了，开始调按钮的圆角、优化动效细节、追求像素级的完美。但如果你还没从原型中验证核心假设，这些打磨就是浪费精力。

陷阱2：过早承诺
一旦原型看起来很"真实"，就很难放弃。你会想："都做到这个程度了，直接用这个不行吗？"但现实是，原型和成品之间还有很长的距离。

陷阱3：对AI能力的误判
看到"能用的原型"就以为可以直接上线，忽视了那些看不见的差距——安全、性能、可维护性。

怎么避免？

有个特别聪明的做法，来自设计师Kyle Lambert：把AI原型当线框图。

在第一个提示中就说明："做一个看起来像线框图的应用。只用黑白，所有文字用Comic Sans，UI用锐利的边缘和粗线条。"

为什么有效？因为这强制你关注交互和流程，而不是视觉。

这个方法的聪明之处在于，它用"丑"来对抗"打磨的诱惑"。当你看到Comic Sans和粗线条，你的大脑会自动把它归类为"草稿"，而不是"成品"。这样你就不会对它产生感情，可以毫不犹豫地扔掉。

判断"做过头了"的信号：

你在调整像素（纠结按钮的圆角半径）
你在优化性能（原型不需要快，只需要能演示）
你在写文档（原型是用来扔掉的）
你在考虑"如果有10万用户"（原型只需要支持测试场景）

Ridd说他在这上面浪费了太多时间。现在他特别清醒：原型就是原型，目的是快速验证想法，不是做成品。

正确的做法是：用AI工具快速做个能看的原型，展示给团队或用户，验证想法行不行。如果行，就回到你已有的产品代码里，用Conductor这类工具认真开发。

这就像你要盖房子，不会用纸板模型当正式的房子。纸板模型的作用是让大家看看房子的样子，验证设计方案。验证完了，还是得用钢筋水泥真正去盖。

右上角：中大型功能开发（有代码库 × 大任务）

典型场景：你要开发一个新功能，需要改动很多文件，工作量比较大。

推荐工具：Claude Mac应用（当CTO） + Conductor（执行）

这个象限的关键不是工具，而是工作方式。

Ridd的做法是：先让AI帮你规划，再动手做。

他会在Claude Mac应用里跟AI进行大量的对话：

这个功能应该分几个阶段做？
每个阶段需要改哪些文件？
有哪些技术风险？
我的实现思路有没有问题？

他把这个过程叫"让Claude当你的CTO"。不是让它帮你写代码，而是让它帮你想清楚。

等规划清楚了，他才会在Conductor里开始执行具体的编码工作。因为已经想清楚了，执行起来就很快，也不会走弯路。

Ridd举了个例子：他正在构建自己的"个人操作系统"来替代Obsidian（他在视频中分享的个人项目）。这是个相当大的项目，涉及笔记管理、任务追踪、知识库等多个模块。他花了大量时间跟Claude讨论，让AI理解他想要什么，帮他拆解成一个个可执行的小任务。

然后在Conductor里，他会用代码审查功能和"CTO反馈"进行双重检查。相当于写完代码后，让AI从两个角度审查：

代码本身有没有问题（代码审查）
实现方案是不是符合最初的规划（CTO反馈）

对于不是专业工程师的设计师来说，这种"三重检查"（自己写 + AI审查 + AI反馈）能大大降低出错的概率。

右下角：大规模创意工作（无代码库 × 大任务）

典型场景：你要从零开始设计一个产品，或者探索一个全新的方向。这时候你需要的不是写代码，而是思考、草图、写作、讨论。

推荐工具：传统方法（纸笔、白板、文档）

Ridd的观点很有意思：这个象限不适合用AI编程工具。

当你在探索一个全新的想法时，最重要的是思考和表达，而不是快速实现。这时候用纸笔画草图、在白板上讨论、写文档梳理思路，反而更高效。

AI工具可以辅助你思考（比如用Claude讨论想法），但不应该直接上手写代码。因为你连要做什么都还没想清楚，就开始写代码，大概率会走偏。

这个观点特别反直觉，因为很多人看到AI工具的演示视频，都是"几分钟做个APP"，就觉得应该直接上手。但Ridd的经验是：越是大的、从零开始的项目，越要慢下来，先想清楚。

四个象限总结一下：

有现成代码库 × 小任务：Conductor并行处理
有现成代码库 × 大任务：Claude规划+Conductor执行
无代码库 × 小任务：Lovable/Figma Make/Dessn
无代码库 × 大任务：纸笔、白板、文档

这个模型的价值不在于告诉你"用什么工具"，而在于教你"怎么想"。

有现成代码的，要考虑如何跟现有系统结合；从零开始的，要考虑是快速验证还是深度探索。小任务追求效率，大任务追求方向正确。

一旦你建立了这个思考框架，即使明天出现10个新工具，你也知道怎么评估、怎么选择。

真正拉开差距的，是选择能力

看完Ridd的分享，我发现这套"四象限选择模型"其实在回答一个更大的问题：在AI时代，什么能力变得更关键了？

不只是学会某个工具。

现在AI工具的门槛已经很低了，大部分工具上手只需要几分钟。Conductor怎么用、Lovable怎么用，看几个教程就懂了。

但真正开始拉开差距的，是**"工具-任务匹配"的判断力**。

这种判断力包括：

知道什么情况该用什么工具
知道什么情况不该用AI工具
知道AI工具的边界在哪里
知道怎么组合多个工具完成复杂任务

以前我们选工具，主要看功能和价格。但现在AI工具功能都很强、价格都差不多，真正的区别在于：这个工具适合什么样的任务？

Ridd的四象限模型，本质上是在训练你的这种判断力。

它不是给你一个"工具清单"，而是给你一个"决策框架"。这个框架告诉你：不要追风口，不要看别人用什么就跟着用什么，而是要根据手上任务的性质来选择。

这个思路，不只适用于设计师用AI编程。

产品经理可以用：小需求用AI快速做原型验证，大需求先用AI帮忙梳理PRD，有现成数据用AI分析，从零开始的市场调研还是得自己做。

运营人员可以用：日常文案、图片用AI批量生成，大型活动策划先用AI头脑风暴，有历史数据的活动用AI优化，全新的创意campaign还是得团队讨论。

写作者也能借鉴：改错别字、润色文字可以用AI，长文章先跟AI讨论结构，有资料的题材让AI帮忙整理，从零开始的创作还是要自己想清楚。

核心逻辑都是一样的：任务性质决定工具选择。

Ridd还提醒了一点，我觉得特别关键：这些工具每周都在变化，方法论比具体的工具名单更重要。

可能几个月后，Conductor不是最好的选择了，Lovable也有了更强的竞争对手。但四象限的思考框架不会变，"工具适配任务"的逻辑不会变。

掌握了这个思考方式，你就不会被工具的更新迭代搞得焦虑，因为你知道怎么评估、怎么选择。

说实话，看完Ridd的分享，我最大的感受是：AI工具带来的不只是效率提升，更是工作方式的根本改变。我们需要学会的，不只是某个具体工具的操作，更要学会在一堆工具中做出正确的选择。

在AI时代，选对工具，往往比学会工具更能决定你的效率。

全文完。

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

设计师用AI编程,最重要的是选对工具

最新文章

热门文章

随机文章

设计师用AI编程,最重要的是选对工具

专业理论 | 多智能体在面向对象编程课程设计中的应用

橱柜代码

最新文章

热门文章

随机文章