Figma 团队聊“Craft”：真正的高手，都在逃离流程和功能崇拜

在这场来自 Figma 内部的对谈里，设计师和工程师反复强调一件反直觉的事：好产品不是流程跑得多标准、功能堆得多完整，而是敢于承认“不确定”，并持续对质量、细节和“是否做对了事”保持执念。这对今天的 AI 从业者，尤其刺耳，也尤其重要。

最反直觉的一点：Craft 从来不是在屏幕里完成的

Figma 设计师 Laura 对 craft 的定义，几乎和“设计流程最佳实践”背道而驰。她说，真正的 craft 开始于你“离开屏幕”，从自然、工业设计等非数字世界中汲取灵感，而不是在同行产品之间反复 benchmark。

这句话对 AI 产品团队尤其扎心。今天太多 AI 产品的设计起点，是“别家怎么做的”“行业默认交互是什么”，最后做出来的只是更快的同质化。Laura 的态度很明确：当你只是在复用行业流程，你已经在牺牲 craft 了。

这不是反流程，而是反‘被流程绑架’。流程是结果，不是起点。起点应该是你对世界、对用户真实行为的观察。对 AI 从业者来说，这意味着：不要只盯着 prompt、模型参数和竞品截图，去看真实的人如何理解、误解和依赖你的系统。

设计里的 Craft：不是“主流程+边角料”，而是全程都在

另一位设计师 Natalie 提到一个很多团队心照不宣却很少承认的问题：我们嘴上都说重视细节，但实际工作中，错误状态、边缘场景往往被当成“之后再补”的活。

她的观点很直接——craft 不是 checklist，也不是 Asana 里的待办，而是把细节当成主流程的一部分。讨论核心用户问题时，错误状态、极端情况就应该坐在桌子上，而不是躺在 backlog 里。

这对 AI 产品尤为关键。因为 AI 的失败模式，往往比成功路径更能定义体验。模型胡说八道、拒答、过度自信，这些都不是“边缘情况”，而是用户每天都会撞上的现实。如果你的团队把这些当成后期优化项，那你基本已经放弃了 craft。

工程师眼中的 Craft：不是写得多漂亮，而是有没有“建对东西”

工程侧的共识同样耐人寻味。工程师们承认，代码质量有一个技术底线，但真正拉开差距的，是你是否理解产品和用户，是否在“解决对的问题”。

其中一个关键点是：quality 往往不是技术指标，而是团队共识。什么是“对的东西”？这件事本身就值得花时间争论。一个愿意为此投入讨论、允许分歧、甚至推翻方向的团队，本身就体现了 craft。

放到 AI 领域，这意味着什么？意味着你不只是问“这个模型能不能上线”，而是反复问：这个能力现在上线，对用户到底是帮助还是干扰？我们是在解决真实问题，还是只是在展示技术进步？很多 AI 项目失败，并不是技术不行，而是从一开始就没对齐‘对的事情’。

真正成熟的团队，都允许“坏想法”存在一段时间

讨论中最被低估的一点，是对“失败”和“坏想法”的态度。Figma 的团队成员明确表示：一个有好 craft 的团队，往往是承认过程混乱、答案不清晰的团队。

他们甚至直说：做到一半发现不该做，是可以、也是健康的。比起按计划交付一个平庸功能，及时止损、回到起点，反而是在保护产品体验。

这对今天节奏极快的 AI 行业是一个危险但必要的提醒。当发布速度成为 KPI，当 demo 驱动一切决策，craft 最先被牺牲的，往往是“我们是不是该做这件事”。而真正顶级的产品团队，恰恰敢在半路按下暂停键。

总结

这场 Figma 内部关于 craft 的对谈，本质上不是在聊设计或工程技巧，而是在聊一种更稀缺的能力：在不确定中坚持质量判断的勇气。对 AI 从业者来说，最大的 takeaway 不是学会某个流程，而是反问自己三个问题：我们有没有把失败场景当成核心体验？我们是否真的对齐了‘做对的事’？以及，当方向看起来不对时，我们敢不敢停下来？也许，真正拉开 AI 产品差距的，不是模型参数，而是这些看似“慢”的决定。

关键词： Figma， Craft， 产品设计， 工程文化， AI产品

事实核查备注： 需要核查：视频实际发布时间（2025-03-13）；视频标题与频道名称是否完全一致；引用观点是否均来自对话原意而非延伸推断