一个下拉菜单，暴露了顶级设计师和普通人的系统思维差距

大多数人做导航栏，只是在“画界面”。这支2018年的Figma教程，却用一个下拉菜单，完整展示了什么叫组件化、状态设计和可扩展系统——而这套思维，恰好是AI从业者最该补的一课。

真正反直觉的地方：下拉菜单不是一个组件

视频一上来就打破了很多人的直觉：下拉菜单不是“一个东西”，而是一组彼此协作的系统。

Joey在拆解导航栏时，先把它拆成三层：最外层是主导航项（Nav Item），第二层是下拉菜单容器（Drop-down Menu），第三层才是最小单元——List Item。更关键的是，每一层都要提前考虑“状态”：默认、激活、可展开、Hover。

这一步看似啰嗦，但它决定了后面所有工作的上限。很多设计（甚至工程）返工，并不是技术问题，而是第一步把系统想简单了。你以为你在做UI，其实你在设计一个未来会被不断复用、扩展、修改的“接口”。

对AI从业者来说，这个点非常熟悉：你如果在一开始就把Prompt、工具调用、状态切换混在一起，后面一定会崩。

组件化的真正价值：不是复用，而是“可预测的变化”

视频最精彩的一段，是对Figma组件和约束（Constraints）的使用。

Joey并没有急着把导航栏“摆好看”，而是先做了一件工程味极重的事：设定约束关系。文字左右居中、箭头右对齐、激活条顶部拉伸——这些规则保证了一件事：当文本变长、菜单变多时，组件的行为是“可预测的”。

这也是为什么他要把文字的左右边距精确设为16px、上下15px。不是审美偏好，而是为了给系统留余量。

更反直觉的是 Hover 状态的处理：他没有把 Hover 当成同一个组件里的一个隐藏状态，而是直接做成了另一个组件（list item / hover）。原因只有一个——这样才能在实例互换（instance swapping）时，完整保留文本覆盖（text override）。

一句话总结：“为了未来的自由，先接受当下的克制。”这和设计AI系统时，为了可维护性而牺牲一点短期灵活度，本质一模一样。

一个小技巧，暴露了老手和新手的差距

如果只能从这支视频里学一个技巧，那一定是：用 Layout Grid 控制下拉菜单的高度。

问题本身很现实：下拉菜单里有2项、5项、8项，设计稿怎么保证永远不多不少？新手的做法是“目测”，老手的做法是“对齐系统”。

Joey的解法是：在 List Item 的主组件上加行布局（Rows），对齐顶部，把高度拆成3行，并直接在Figma里输入公式“70 / 2”。当你拖拽菜单高度时，每一条网格线都在告诉你：现在是不是一个“合法状态”。

这一步几乎没有任何视觉效果，但它极大降低了团队协作和长期维护的成本。

这和AI产品里加校验、加约束、加Guardrail是同一件事：不是为了限制人，而是为了防止系统悄悄变坏。

为什么AI从业者一定要看这种“老设计视频”

这支视频发布于2018年，工具早就更新了，但思维方式完全不过时。

它反复强调三件事：
1）先拆系统，再画界面；
2）为变化设计，而不是为当前状态；
3）让工具替你保证一致性。

如果你在做AI应用、Agent系统、工作流编排，本质上每天都在做“看不见的导航菜单”：状态切换、子流程展开、异常处理。

区别只是：设计师用的是组件和约束，你用的是函数、状态机和工具调用。

真正的专业感，从来不是功能多，而是系统在变化时依然稳。

总结

一个下拉菜单，看似微不足道，却完整展示了系统级思维：拆解、约束、状态、可扩展性。对AI从业者来说，这不是设计课，而是一堂关于“如何让复杂系统长期可控”的实践课。下次你设计Agent流程或多轮交互时，不妨问自己一句：如果需求翻倍，这套结构还能优雅地活下去吗？

关键词： Figma组件化， 下拉菜单设计， 系统思维， 设计约束， AI产品设计

事实核查备注： 需核查：视频发布时间为2018-06-12；作者为Figma Config频道；教程内容是否包含Layout Grid使用与70像素高度示例；是否明确提到instance swapping保留text override的前提是图层同名。