X 上看到一个 Codex 的使用案例，将 Codex 内置一个图片标注工具，这样修改标注工具里的图，Codex 就能读取数据进行重新生成，案例分享给大家
通过内嵌浏览器 + Codex Image 2 + 无限画布（Excalidraw / tldraw），构建一个多模态画布系统，让 Codex 直接读取画布的 Base64 标注图，实现“看图理解 + 生成”。
这样 Excalidraw / tldraw 就不只是白板，而是变成前端的 Multi-modal Canvas，用来拼一个低配但可控的生图工作流。
其他在线白板工具：
此想法的原帖： https://x.com/zhongerxin/status/2068027614300893383
原作者 Cowart：Codex + 无限画布工具插件开源： https://github.com/zhongerxin/cowart#
换白板工具原帖： https://x.com/cellinlab/status/2068193900570046502
操作步骤原帖： https://x.com/liyue_ai/status/2068545434818400526
标签页分组功能允许您在 Figma 桌面应用程序中对标签页进行分组、着色、展开和折叠。保持井然有序，再也不用担心找不到要查找的文件。
网址：https://www.figma.com/release-notes/
FigmaEX 客户端已经更新到 126.6.8 版本，可自行下载安装。
展示收藏了非常多 iOS 的经典应用图标，并支持搜索，非常喜欢被精心设计的图标包围的充实感，后续会开放 macOS 应用图标库。
网站收集了一波应用商店的优化图片和用户引导流程的设计案例。
App Store 截图库包含，350 万+ 截图 、40 万+ 应用，永久免费
网址：https://screenshotsclub.xyz/
每个应用程序都需要矩阵加载器，55+个免费且开源的加载器，基于 React、TypeScript、Tailwind CSS 和 shadcn 构建。安装一个，复制代码，然后将其变成属于你自己的作品。
网址：https://dotmatrix.zzzzshawn.cloud/
精选 X 中设计、交互的最佳设计，每日更新，并且还有应用截图和应用图标等信息，AI 时代提升"看"的能力
umanmade 是一个由真人创作的数字作品精选目录，收录优秀的设计灵感和交互案例
免费的、随时可用的 Figma UI 块库。 复制任意组件，将其粘贴到你的文件中，即可立即开始构建。 非常适合着陆页、布局和 UI 部分。
网址：https://blocks.lander.studio/
转载：优设
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
转载：优设
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
兰亭妙微UI设计公司：今天分享的是「图标设计准则」。图标是界面设计里的 “刚需元素”，一个小图标能快速传递很多信息。好的图标需要兼顾简洁、现代、友好。但图标的尺寸很小，设计时既要严格遵守设计规则，又得清晰表达信息，这样才能保证整套图标的风格统一、辨识度高。
今天就来聊聊大厂在用的图标设计原则和设计规范，配合案例进行设计分析~
给大家举个例子，就说下面的小船图标，想让图标清晰好认，就得做减法，那么用正面的简约船身造型最合适。
如果图标设计的过于细致，例如图标中添加了船帆、桅杆或者旗帜等细节，太写实的图标不仅会降低识别速度，还会破坏整套图标的视觉统一性。
设计总结：
✅ 简化图标造型，提升清晰度和辨识度
❌ 拒绝过度写实，避开复杂繁琐的设计
使用几何图形和统一的基础形状来设计图标，能打造出清晰醒目的视觉感受。哪怕结构简单，也能保持清晰的形态，缩小到小尺寸时也照样容易分辨。
反过来讲，尽量少用那些纤细、松散的不规则形状，它们会破坏线条的连贯性，让整套图标看起来乱糟糟的，没个统一的调性。
设计总结：
✅ 靠几何图形和统一的造型，打造醒目视觉效果
❌ 少用纤细、不规则的形状
这里给大家看一组风格统一的图标示例。对品牌识别和系统适配来说，保持图标集的视觉一致性太重要了。
要是把不同风格的图标混在一起用，用户根本没法把它们当成“一家人”。所以同一套图标里，不管是形状、线条粗细，还是比例、边角处理，都得按同一个标准来。
设计总结：
✅ 单套图标集里视觉风格要保持统一
❌ 千万别混搭不同风格的图标
在谷歌的Material Design 3 设计规范中，标准 (基线) 图标尺寸是24dp×24dp，设计时建议按100%的比例来做，这样能保证像素级的精准度。
除了这个标准尺寸，还有20dp、40dp、48dp这几种常用尺寸可以选：
20dp：适合用在桌面端、紧凑布局，或者那些小尺寸的视觉元素
40dp/48dp：针对显示器、大屏幕，还有标题栏这类特殊场景
设计图标时，内容需要放在有效区域内里。有效区域是指页面滚动或适配不同设备时图标不会被遮挡的“安全可视区域”。
如果想让图标的视觉冲击力更强，可以让内容延伸到有效区域和裁剪区域之间的留白处，但不能超出裁剪区域，不然图标很容易被裁剪显示不全。
具体要怎么布局呢？看下面这两点就够了：
① 有效区域：图标内容要放在20dp×20dp的范围内，四周各留2dp的边距
② 边距：给有效区域留出2dp边距，既能让图标和周围元素拉开视觉距离，又能让整体看起来更平衡
接下来通过一个图标案例来简单总结一下：
上图从左到右分别代表了在有效区域、在有效区域和裁剪区域、在裁剪区域之外创建的图标案例。
设计总结：
✅ 图标内容保持在20dp×20dp的有效区域里，记得留2dp边距⚠️ 想加视觉冲击力？内容可以延伸到边距区域
❌ 任何情况下，图标都不能超出裁剪区域
① 网格和关辅助线
一套图标中可能有的是圆形，有的是方形，那怎么才能保证形状不同的图标保持视觉大小的一致性呢？
这种情况大家在设计图标时应该都碰到过，解决方法可能大多是通过眼睛对比查看，把看着小的图标调大一些或者把看着大的图标调小一点。这种方法效率不高，而且设计出来的图标大小不容易保持一致性。
这里提供一个更科学和高效的辅助图标设计方法——使用网格和辅助线，照着这些辅助线来设计图标，能轻松保持比例一致。
例如常用的24dp×24dp图标网格，由正方形、圆形、竖矩形、横矩形这四种基础辅助线构成。它们就像图标的“骨架”，能帮所有图标保持统一的比例和对齐效果，哪怕放大10倍看，结构也照样清晰。
给大家拆解一下这四种辅助线：
方形辅助线：边长18dp，是图标的基础平衡基准。比如图表类图标就可以照着这个方形来画，保证比例稳定。
圆形辅助线：直径20dp，用来设计圆润平衡的图标。像地球图标用这个圆形打底，就能和其他图标和谐搭配。
垂直矩形辅助线：高20dp、宽16dp，适合强调纵向比例的图标。比如文档图标围着这个竖矩形设计，比例会特别清晰。
水平矩形辅助线：高16dp、宽20dp，适合横向比例的图标。像邮件图标用这个横矩形当基础，形状会很均衡。
一个完整的图标，由圆角、起始/结束点、内部形状、外部轮廓等组成。
这里重点说下大家容易踩坑的“圆角”的设计：例如下图的银行卡图标，采用外角2dp圆角、内角尖角的设计，这样既柔和又利落。
如果把圆角做得太大，如下图左侧文档图标，图标的辨识度就会下降；如果一个图标中混用不同半径的圆角，如下图右侧的图标，整个图标看着就会很杂乱。
设计总结：
✅ 按规则设置圆角，统一圆角半径
❌ 避免圆角半径过大/半径混用的情况
推荐的图标描边粗细是2dp或常规 (400)，也可以根据需求灵活调整，例如在MD3设计规范中就提供了100 (细)到700 (粗)的多种选择。
这里有两个小技巧：
设计直角线性图标时，描边的末端尽量做成直角，例如下图左侧的箭头图标，45度切割的直角就很清晰；在下图右侧的添加图标中，内部的加号也采用了2dp的描边粗细，与外轮廓保持一致。
另外要注意一套图标需要保持相同的描边粗细。如果描边x粗细不一致，不仅会模糊图标形状，还会破坏视觉一致性。
设计总结：
✅ 描边粗细保持统一，直角图标末端也用直角
如果图标需要一些精细的细节，可以通过一些灵活的调整来提升辨识度，但不能扭曲基础的几何形状或破坏整体比例。
比如回形针图标，为了在24dp的空间里放下多个曲线，可以把 2dp的标准描边粗细微调成1.5dp；再比如拉面图标，下面的碗作为托底采用2dp的粗描边，上面的筷子拉面等元素细节更多，则采用1.5dp的细描边，让细节更清晰。
还有一个小原则：设计复杂图标时，尽量保持正面视角，别做倾斜、旋转的等距或者3D效果——多余的深度感会增加识别难度。
设计总结
✅ 正面视角设计，细节微调不跑偏
❌ 少用倾斜、旋转的等距/3D呈现方式
图标是一种高效的视觉语言，能打破语言壁垒，快速传递信息。但它的优势，必须建立在清晰的结构和统一的规则之上。
设计时基于标准的辅助网格走，保持比例均衡、视觉重量一致，设计出的图标才不会喧宾夺主，反而能提升整个产品的用户体验。
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
兰亭妙微UI设计公司分享：过去，产品经理谈界面设计，常常只需要说一句：“这个页面按后台系统常规样式做就行。”
但今天，这句话已经不够用了。
一方面，AI 产品、SaaS 工具、内容平台、数据看板、运营后台越来越多，产品的第一印象越来越依赖界面质感。另一方面，前端开发已经不再是从零开始写每一个按钮、表单和弹窗，大多数团队都会基于成熟的 UI 框架或组件库快速搭建产品。
所以，产品经理虽然不一定要会写代码，但至少应该知道：市面上有哪些常见的前端 UI 框架？它们分别适合什么产品？什么时候该用现成框架，什么时候需要做定制设计？如果你完全不了解这些，很容易在需求评审时提出“不现实的设计要求”，或者在产品视觉层面输给竞品。
这篇文章，就帮产品经理系统梳理一次。
简单理解，前端 UI 框架就是一套已经设计好、开发好的界面组件集合。
比如：
按钮、输入框、下拉选择器、表格、弹窗、标签页、菜单、日期选择器、上传组件、通知提醒、侧边栏、数据卡片……
这些都是产品页面中高频出现的基础元素。
如果没有 UI 框架，前端工程师就需要从零开始写这些组件，不仅开发效率低，也很难保证不同页面之间的风格统一。
而有了 UI 框架之后，团队可以直接调用现成组件，再根据品牌风格进行主题定制。对于产品经理来说，这意味着：
所以，UI 框架并不只是“让页面变好看”的工具，它本质上是产品研发效率的一部分。
很多产品经理会觉得：“UI 框架不是前端工程师的事情吗？我为什么要懂？”
原因很简单：你不需要会用，但你需要会判断。
产品经理至少要知道三个问题：
第一，这个产品适合用什么类型的 UI 框架？
一个企业管理后台，和一个 AI 聊天产品，和一个营销活动页面，对界面风格的要求是不一样的。后台系统更看重表格、表单、权限、筛选和数据展示；AI 产品更看重现代感、轻量感、动效和交互体验；官网落地页则更看重视觉冲击力和转化路径。
第二，UI 框架会影响产品气质。
同样是一个管理系统，用 Ant Design、Element Plus、shadcn/ui、HeroUI 做出来的感觉可能完全不同。有的偏企业化，有的偏清爽，有的偏现代，有的偏国际化。
第三，UI 框架会影响需求实现成本。
有些组件框架本身就提供复杂表格、表单校验、日期选择、上传、权限布局等能力，实现成本较低；但如果产品经理提出的交互和框架默认能力差异很大，研发成本就会上升。
所以，懂 UI 框架，不是为了替前端做技术选型，而是为了让产品经理在设计需求、评估成本、判断风格时更专业。
前端 UI 框架很多，但产品经理不需要全部掌握。你只需要知道以下几类。
如果你做过中后台产品，大概率听说过 Ant Design。
它最适合的场景是：企业管理后台、CRM、ERP、数据平台、运营后台、权限系统、审批系统、配置系统等。
Ant Design 的优势是组件非常完整，尤其适合复杂表格、复杂表单、数据筛选、弹窗、菜单、导航、分页、上传等中后台场景。对于国内很多 B 端产品来说，它几乎已经是一种“默认选择”。
但它也有一个明显问题：默认风格比较“企业化”。如果不做主题调整，产品容易看起来像传统后台，缺少年轻感和高级感。
产品经理在使用 Ant Design 时要注意一点：它适合提高效率，但不代表产品一定好看。如果是面向外部客户的 SaaS 产品，最好在颜色、间距、卡片、图标和数据可视化上做二次设计。
适合场景：
不太适合：
Element Plus 是 Vue 生态里非常常见的 UI 组件库，很多国内团队做后台系统都会用它。
如果你的技术团队使用 Vue 3，那么 Element Plus 通常会是一个很容易被考虑的选项。它上手成本低，文档友好，组件也比较完整，适合快速搭建管理系统。
它的产品气质和 Ant Design 有点类似，都是偏中后台、偏效率、偏稳定的路线。对于产品经理来说，Element Plus 的核心价值不是“多么惊艳”，而是“稳定、通用、开发快”。
适合场景：
需要注意的是，如果产品对视觉高级感要求很高，Element Plus 默认风格也需要二次设计，否则容易显得普通。
Naive UI 也是 Vue 3 生态中值得产品经理了解的一套组件库。
和 Element Plus 相比，Naive UI 的气质更轻、更现代，视觉上也更清爽一些。它比较适合那些既需要后台能力，又希望界面不要太传统的产品。
比如 AI 工具后台、内容管理系统、知识库产品、数据分析工具、轻量 SaaS 控制台等，都可以考虑 Naive UI。
对产品经理来说，Naive UI 的价值在于：它不那么“老派后台”，同时又具备比较完整的组件能力。如果你希望产品既有效率，又看起来更年轻，它是一个不错的选择。
适合场景：
Arco Design 是一套偏企业级的设计系统和组件库，既有 React 版本，也有 Vue 版本。它的整体风格比传统企业后台更年轻，适合需要兼顾效率和视觉感的产品。
如果说 Ant Design 更像成熟稳重的企业后台，那么 Arco Design 相对更轻、更活泼一些。它适合做企业协同产品、效率工具、数据平台、SaaS 后台、运营系统等。
产品经理可以把 Arco Design 理解为：在企业级能力和年轻化视觉之间做平衡的一套方案。
适合场景：
MUI 是 React 生态里很成熟的一套组件库，基于 Google 的 Material Design 风格。
它的特点是规范感强、组件完整、国际化程度高。很多海外产品、开发者工具、SaaS 产品会使用 MUI。
不过，MUI 的默认风格有比较明显的 Material Design 特征。如果你的产品希望看起来更“Google 系”，MUI 会比较合适；但如果你希望做出独特品牌感，就需要进行较多主题定制。
适合场景：
Mantine 是一套比较全能的 React 组件库。
它的优势在于组件丰富、hooks 完整、主题定制能力强，适合做各种 Web 应用，尤其适合 SaaS、后台系统、工具型产品。
和 Ant Design 相比，Mantine 的视觉气质更轻一些；和 shadcn/ui 相比，它又更像一个完整的组件库，开箱即用能力更强。
如果你的团队使用 React，并且想要一个既能快速开发、又不会太传统的 UI 框架，Mantine 是值得考虑的选择。
适合场景：
近几年，Shadcn ui 在 React 和 Next.js 圈子里非常受欢迎。
严格来说，它并不是传统意义上的组件库。它更像是一套可以复制到自己项目里、再自由改造的组件体系。它的设计风格非常现代，配合 Tailwind CSS 使用，很容易做出高级、干净、有质感的界面。
这类风格非常适合 AI 产品、SaaS 官网、开发者工具、数据看板、知识库产品、内容平台等。
shadcn/ui 的优势是好看、灵活、可控；缺点是它对前端团队能力要求更高，不像传统组件库那样“一装即用”。如果团队前端能力不错，它可以做出非常有差异化的产品视觉；如果团队比较依赖现成组件，使用成本可能会更高。
适合场景：
对产品经理来说，shadcn/ui 值得重点关注。因为现在很多新一代 AI 产品的界面风格，已经不再是传统后台，而是更轻、更白、更克制、更高级的设计语言。
HeroUI 也是一套适合 React 项目的现代 UI 组件库。
它的特点是默认视觉比较好，组件带有更明显的现代感和动效感，适合做 AI 工具、创作者产品、社区产品、轻量 SaaS 产品等。
如果产品经理希望产品一开始就有不错的视觉表现，而不是完全依赖设计师和前端从零调整，HeroUI 会是一个不错的选择。
适合场景：
Tailwind CSS 严格来说不是 UI 组件库，而是一套 CSS 工具框架。
你可以把它理解成一套“原子化样式系统”。它不会直接给你一个完整的表格或弹窗，但它可以让前端非常灵活地搭建各种界面。
现在很多现代 UI 框架和组件方案都会基于 Tailwind CSS，比如 shadcn/ui、HeroUI 等。
产品经理不需要理解 Tailwind CSS 的写法，但要知道它代表了一种趋势：越来越多团队不满足于直接套用传统组件库，而是希望通过更灵活的样式系统，做出更有品牌感的界面。
适合场景：
产品经理不需要决定最终技术选型，但可以和设计师、前端一起从以下几个维度判断。
如果是企业后台、管理系统、配置平台，可以优先考虑 Ant Design、Element Plus、Arco Design。
如果是 AI 产品、SaaS 工具、开发者工具，可以重点关注 shadcn/ui、HeroUI、Mantine。
如果是 Vue 技术栈，可以看 Element Plus、Naive UI、Arco Design Vue。
如果是官网、落地页、活动页，可以关注 Tailwind CSS 及其生态组件。
React 项目常见选择：
Vue 项目常见选择：
不同框架并不是随便选的，它和团队技术栈高度相关。产品经理不要只说“我喜欢这个风格”，还要问一句：“我们现在的前端技术栈适合用它吗？”
如果产品里有大量复杂表格、筛选、表单、权限、弹窗、上传、日期选择，组件完整度非常重要。
这类产品更适合选择成熟组件库，比如 Ant Design、Element Plus、Mantine、Arco Design。
如果产品更重视视觉表达、页面质感和品牌差异化，可以选择 shadcn/ui、HeroUI、Tailwind CSS 生态。
很多产品的问题不是“没有 UI 框架”，而是“所有页面都长得像模板”。
如果你希望产品有自己的品牌感，就不能只依赖默认样式。产品经理需要关注：
一个成熟产品，最终一定不是简单套模板，而是形成自己的设计系统。
如果你是做企业中后台：
优先看 Ant Design、Element Plus、Arco Design。它们组件成熟，适合复杂业务场景，尤其是表格、表单、筛选、权限等能力比较重要的系统。
如果你是做 AI 产品：
优先看 shadcn/ui、HeroUI、Mantine。它们更容易做出现代感和高级感，适合 AI 工具、AI 工作台、AI 内容平台、AI Agent 控制台等产品。
如果你是做 SaaS 产品：
可以根据风格选择 Mantine、shadcn/ui、Ant Design、Arco Design。如果是偏后台管理，可以选 Ant Design 或 Arco；如果是偏现代工具，可以选 shadcn/ui 或 Mantine。
如果你是做官网和营销页：
可以关注 Tailwind CSS 生态。相比传统后台组件库，它更适合做品牌官网、课程页、活动页、产品介绍页。
如果你是 Vue 团队：
可以重点看 Element Plus、Naive UI、Arco Design Vue。如果想稳妥，就选 Element Plus；如果想更现代，可以看 Naive UI；如果要企业级完整方案，可以看 Arco Design Vue。
第一个误区：以为 UI 框架等于设计稿。
UI 框架只是基础组件，不等于完整设计。真正的产品体验还包括信息架构、页面布局、视觉层级、交互路径、文案表达和品牌调性。
第二个误区：只看好不好看，不看业务复杂度。
有些框架看起来很美，但不一定适合复杂后台。如果产品有大量表格、筛选和表单，组件能力比视觉炫酷更重要。
第三个误区：只追求差异化，忽略开发成本。
如果每个组件都要重写，每个交互都要高度定制，产品看起来可能更特别，但研发成本和维护成本也会大幅上升。
第四个误区：认为用了某个框架就一定高级。
同样使用 shadcn/ui，有的产品很高级，有的产品也会很普通。框架只是起点，最终效果取决于设计能力、前端实现和产品细节。
产品经理了解 UI 框架，不是为了和前端争论“到底用哪个库”，而是为了提升产品判断力。
你至少要能判断：
当你能回答这些问题，和设计师、前端沟通时就会更专业。
AI 时代，产品经理的能力边界正在变化。
过去，产品经理重点关注需求、流程和功能；现在，产品经理还需要懂一点界面审美、组件思维、设计系统和研发效率。
前端 UI 框架就是连接产品、设计和研发的重要桥梁。
你不需要成为前端工程师，但你需要知道：
真正优秀的产品经理，不只是会写需求文档，也要能判断一个产品该用什么方式被更高效、更美观、更可持续地做出来。
这，就是产品经理应该了解前端 UI 框架的原因。
转载：人人都是产品经理
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
当 Toast 内图标、装饰元素较多时，画面容易杂乱松散。可以在主体元素后方增加专属背板，既能收拢零散元素、强化整体感，还能快速增加视觉层次。
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
附 Figma 官方文案节选：无论多少次被宣告 “消亡”，设计始终生生不息。它藏在帮你避免坐过站的地铁图里，藏在一目了然的菜单里，也藏在贴心的 App 通知里。设计不是转瞬即逝的潮流，也不是可被替代的技术，它关乎体验、关乎感受，而非仅仅追求功能可用。设计屡遭唱衰，却一次次证明自身不可替代。官方链接：https://x.com/figma/status/2061101954034442293
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
谈论 AI 就绕不开大模型，它是 AI 技术应用的核心。
简单解释 AI 大模型，就是一个通过特定方法和大量数据训练出来的 “自主化程序”，这个程序可以根据用户输入的指令自己做出 “判断和思考” 后再进行回复。
传统程序虽然也可以执行用户的指令，但回复的内容和方式不会超出一开始预设的范围，非常有限。
而 AI 大模型则大大拓展了这个边界，我们不用提前预设各种条件和逻辑，它就会自己去理解问题再决定给出什么结果。
当然，这个边界只是不能生成图片(截止到2026年初)。而 Google 开发的 Gemini 大模型则是多模态模型，可以生成图片和视频等内容。
不同模型会有不同的表现和优劣，但因为大模型的开发需要尖端的技术和庞大的规模（训练），门槛极高，所以市面上主流的大模型数量并不多，可以简单分为国内和国外两个阵营。
国外的主流大模型包括 OpenAi 开发的 ChatGPT，Google 开发的 Gemini，Anthropic 开发的 Claude，xAI 的 Grok 等。
国内的主流大模型则包括字节开发的豆包，阿里开发的千问 Qwen，深度求索开发的 Deepseek，月之暗面开发的 Kimi 等。
因为前面说过大模型的局限性，所以为了应对不同的应用场景，团队就会将它们裂变出不同的版本。比如千问既有 Max 语言大模型，还有 Omni 全模态（文字、图片、音频、视频）大模型，针对处理问题的难易度又分成了 Max、Plus、Flash、Lite 等版本。
完整的大模型体积和参数都非常庞大，需要部署到专属的算力中心，并通过云服务来实现用户的访问和使用。也就是需要联网使用，但因为国内网络服务的限制（不可抗力），我们无法通过国内电信访问国外的主流大模型。
虽然说国内大模型的水平在这几年突飞猛进，但离国外的大模型还有一定的差距，在实际工作场景中多数应用的也是国外大模型，所以访问它们就需要大家自己发挥主观能动性解决了。
顺便再解释一个基础的问题，大模型除了远程访问以外，也可以在本地进行安装。部分团队（如千问）会在网上开源自己的大模型供其它人下载和使用，当我们下载到本地后就可以用 GPU 来运行它。但因为大模型对性能的要求极高（旗舰显卡起步），所以本地运行的效果要大打折扣。
而一些企业内部或行业专属的大模型，往往都是使用这些开源大模型进行二次训练和调试后的结果。还有一些针对特定硬件（如手机、眼镜）和特殊应用场景开发的小模型，就暂时不在我们的讨论范围之内。
前面讲过大模型可以类比成一种 “程序”，且它还是后端服务器上运行的程序。想要对这个程序实现命令的输入并返回它处理的结果，就需要应用前端的工具来实现。
比如我们打开豆包的官网，就可以使用这个网页对豆包大模型提出问题和要求，然后网页上就会返回它处理后的结果。这个网页就是使用大模型的工具，而这只是 AI 工具的其中一种形式，还可以是本地应用程序、手机 APP、小程序、硬件定制系统等等。
我们大多数人开始接触 AI 大模型，都是从这些官方的工具开始，它们最基本的功能就是根据指令返回文字或图片信息，我们会把它们当成是一种可以对话的人工智能客服。
但实际上它们可以发挥的作用远不止于此，比如帮你整理本地的文件夹清理重复的文件，帮你自动修图并完成动态相片的剪辑，帮你编写程序并自己运行和检测等等。想要实现对话以外的其它功能，就需要借助特定的工具才能实现。
所以除了最基础的对话工具外，行业还衍生出了很多激发大模型潜力的 AI 工具。它们可以借助大模型完成程序开发、视频剪辑、操作托管、热点整理、消息推送等等。
到这里我们就要清楚，AI 大模型是大模型，工具是工具，大模型是基座，而工具是大模型的具体表现和应用形式。
我们更进一步认识 AI 工具，就可以把AI工具分成官方工具和第三方工具两个种类。
官方工具就是 OpenAI、Google 等大模型企业自己开发并绑定自家大模型的产品，而第三方工具则是其它团队开发，再接入到大模型进行使用的工具。
比如本地聊天机器人 Cherry Studio，它本身只是个简单的聊天对话工具，可以自己创建对话角色/助手，但需要接入大模型以后才能进行对话。还有著名的AI编程工具 Cusror，只有接入大模型以后，它才可以实现 AI 编程和代码管理。还有前阵子火遍全球的龙虾 Openclaw，也只是个本地工具，需要接入大模型后才能识别本地的文件和执行命令。
官方能提供的 AI 工具与服务往往很有限，所以在真实项目流程中，我们就会混合使用多种工具来完成工作。就像以前做一套项目除了用 Figma以外，还要结合使用 Adobe PS、AI、C4D、AE 等软件。
而第三方工具和官方不同的是，官方工具默认连接自家的大模型，用户直接登录就能使用。而第三方工具要接入大模型，就需要进行额外的配置，也就是添加大模型的 —— API。
API 就是接口，是前端工具连接后端服务器的通道，而这个通道默认是上锁的，还需要提供对应的密钥（API Key）才能正常访问。
部分工具会自己接入各大模型的 API，用户只能选择它提供的模型，并只需要对这个工具进行付费即可。
另一部分工具则需要用户自己选择模型和配置 API，需要我们访问大模型的 API 开放平台进行申请，然后再将它们生成的 API Key 填入到工具中完成连接。
API Key 就像是一个电话号码，当我们申请完并进行使用，就会产生一定的 “流量”，而 AI 产生的流量用专业术语形容叫词元 Token。
使用 API 完成的任意 AI 服务，都会消耗 Token，且因为 AI 的计算成本极高，所以主流大模型都会针对 Token 消耗量进行收费。就像电信运营商一样，既有包月服务附带一部分流量，超出部分还要按量计费。
在实际的 AI 工具使用过程中，Token 的消耗是极其巨大的，往往会造成沉重的成本，而这个市场也遵循一分钱一分货的真理，越好的大模型价格就越贵。以最适合编程的大模型 Claude Opus 为例， 一个程序员高频使用消耗的 Token 账单可以从数千到数万元不等。所以我们也会从性价比的角度出发，来搭配不同的模型进行使用。
总结我们应用 AI 的本质，就是通过工具来操作大模型。而工具的作用不同，大模型本身的特性和价格也不同，就导致我们在面对一个复杂的任务时，需要选择多种 AI 工具和不同大模型来实现。
学习使用 AI，和传统的单一软件教学不同，不是只学会某个工具的功能和操作方法，而是了解不同的 AI 工具以及大模型的特性，通过组合它们来实现自己目标的方式。这不是设计或产品思维，而是工程思维的具体应用。
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
通过制造视觉元素的差异—— 让 “不一样” 的元素从周围环境中凸显出来，自然成为视觉焦点。
引导用户注意力优先落在关键信息或操作点上，这就是对比原则，我们可以通过形状的对比让卡片突出，增加视觉表现力：
在一些视觉页面中，也可以用异形容器增加视觉表现力，可以结合主题设计容器，例如下方就是一个以纸质火车票造型作为卡片背景的例子：
也可以结合内容设计容器，例如页面的内容是感谢用户，就可以从感谢信或者信纸的角度设计容器：
在设计中，想要为卡片或页面增加形式感，丰富背景是直接且高效的方式，可以从颜色、底纹、装饰元素这三个核心维度展开，让背景不再单调，为整体设计加分：
1. 优化颜色增加背景的形式感
可将背景的无彩色（如黑白、灰度色）替换为带有明确色相的有彩色（如柔和的薄荷绿、清新的天蓝、低饱和的珊瑚橙等）
借助 “无彩色与有彩色” 的属性差异，让卡片与周围的浅灰背景或普通卡片形成直观色彩对比，快速从整体布局中跳脱出来：
也可以将卡片的单一纯色设计，升级为多种颜色的渐变效果 —— 通过这种渐变色，让卡片与周围的背景、其他组件形成鲜明对比
从而快速从整体布局中凸显出来，成为视觉焦点，快速抓住用户注意力：
2. 给背景增加底纹
在背景中增加底纹（如低透明度的几何纹理、轻微的肌理质感等），不仅可以强化视觉层次，还可以向用户传递页面的风格氛围，增强记忆点。
例如科技类产品用细线条网格底纹增强科技感，古风类产品可以用纸张等营造复古的氛围感：
下面列举了一些常见的底纹元素，可搭配图层的混合模式、不透明度使用：
3. 在背景上增加装饰
可以根据页面/活动添加合适的装饰元素，装饰可以是图形、文字等与页面相关的元素。
装饰元素主要是为了平衡界面视觉，优化整体协调性：当界面存在 “大面积空白” 或 “元素分布不均” 时，装饰元素可起到 “视觉平衡” 作用。
这里的文字不仅是卡片标题，也可以是活动标题或者页签导航，那么文字的设计感可以怎么加呢？我们可以从图形装饰、线条装饰、文字装饰、背景装饰四个方面给文字添加设计感：
1. 图形装饰
将图形放在标题空白处增加标题的设计感：
也可以用来填补标题的空白区域，平衡视觉：
用图形代替文字的某一个笔画，传递产品的氛围：
2. 线条装饰
用简单的线条突出标题，辅助信息分层，突出重点信息，降低认知成本：
3. 文字装饰
用风格独特的字体写一句英文作为标题的装饰：
另一种方法是将文字放大起到装饰作用：
4. 背景装饰
在标题后面增加背景，不仅可以保证标题的可读性，还能让标题抓住用户的眼球，进一步强化视觉表现力：
尽管上面的案例分别展示了不同的提升形式感的方法，但在实际设计中，不必局限于单一形式。
将多种手法灵活组合（比如为卡片搭配有彩色背景的同时，叠加轻量底纹并点缀细节装饰），更能放大视觉表现力，让界面摆脱单调感，呈现出更丰富的层次与质感。
如果这篇内容对你有启发，或是你有其他提升形式感的实用思路，欢迎在评论区分享交流，一起探索更多设计可能性～
转载：优设
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
响应式是一种网页前端技术，让网页可以根据分辨率、设备的变更，自动调整样式和布局。
它的诞生起源于移动互联网兴起的热潮，彼时智能手机访问网站的需求激增，但多数网站的适配都是面向电脑端的大屏幕，仅有少数网站会额外开发符合移动端显示需求的版本（自适应）。
响应式的提出，就是为了解决这种问题，通过建立一套约定好的设计、开发方法，用一套代码自动适配台式电脑、笔记本、平板、移动端等各种设备，提高网站的兼容性和开发效率。
而学习响应式，首先就要从浏览器开始说起。
浏览器是一个非常特殊的软件，比如大家熟知的 Chrome、Safari、Eage 等，我们日常访问的所有网页，都需要通过浏览器加载并渲染出最终的样式。
可以把网页 HTML 文件理解成是一个程序，而浏览器就是运行这个程序的系统（环境），也就是说解析网页依靠的是浏览器而不是 Windows、Mac、iOS、Android、Linux 等客户端系统。
浏览器即系统中的系统（类似虚拟机)，不管在任何系统或设备上，只要安装了浏览器，就可以用大体相同的规则、逻辑去加载、渲染出网页。
但不同设备的屏幕有很大差异，网页如何识别并匹配这些设备呢？
方法主要有两种，第一种是浏览器会识别当前系统和设备，并提供接口让网页读取。而部分网站会准备多种规格的网页，根据获取的设备类型推送对应的规格，这种做法叫做自适应模式。
通常自适应只区分桌面端和移动端两种，较大的门户、购物、工具类网站，普遍使用自适应模式。因为移动端访问网页的需求并不高，所以会对移动端版本做大量的精简，降低开发、维护成本。
另一种方法，则是读取浏览器视图区域的分辨率。任何浏览器的界面，都包含功能区域和视图区域两个部分，功能区域提供相关的软件菜单、操作按钮，视图区域则是显示网页界面的区域。随着设备和屏幕分辨率的变化，浏览器的大小也会不同，网页视图区域也会跟着缩放。
网页视图注定小于整个浏览器的软件窗口，而浏览器作为软件，在系统中的尺寸不等于系统分辨率（或设备分辨率），一方面有系统的全局组件影响，另一方面窗口并不是非得全屏，用户可以任意调整。
所以响应式网页就是根据浏览器的视图区域做适配，不管你是在电脑上缩放软件窗口，还是在不同的设备、系统中打开，本质上都只是显示区域大小的变更。而在浏览器的检查选项中，模拟不同的设备其实就是缩放出一个指定的视图窗口出来。
这种依赖关系延伸出一个新的知识点，即网页显示的分辨率，和显示设备的屏幕分辨率，是两套不同的体系。
这是因为硬件分辨率和系统渲染的分辨率是两个概念，尤其在今天高分辨率屏幕普及的背景之下。比如我的 Macbook Pro14 寸笔记本，硬件分辨率是 3024 x 1964 (254 ppi)，但在系统的屏幕分辨率选择中，默认的却是 1512*982（即原来的 1/2）。
这是因为硬件分辨率太高了，1:1 渲染的话，那么大多数图标、文字是无法被看清的，所以默认使用了 2x 的规格渲染。但这只是其中一个选项，在 HIDPI 技术的加持下，用户还可以选择别的分辨率，比如我会进一步调高到 1800*1169。
在 Windows 系统中同理，虽然有很多高分辨率的屏幕，但是用户为了看清内容，会在系统中设置 120%、150% 的放大效果，等于为系统分辨率做出变更。
说到底，系统显示分辨率的规格也是无穷无尽的。但是不管外部的转换逻辑有多复杂，规格有多少，都和响应式网页无关，它只需要认准浏览器的视图区域分辨率即可。
所以了解线上案例的响应式布局规则，或者检查已经开发好的响应式页面，并不需要切换不同设备查看，只要拖拽缩放浏览器的大小（主要是宽度）即可获得完整的响应效果。
最后总结起来，响应式网页是面向浏览器视图区域做适配的布局方法，而不是面向系统、屏幕分辨率的适配，这和自适应布局有本质的差异。
在 B 端领域，绝大多数项目都只部分兼容响应式，放弃移动端的适配，即使支持移动端也是使用自适应的混合模式。要面对这些复杂的场景，就月需要理解上面这些基础的概念，否则设计师就无法真正满足响应式项目的前期创建和后期交付需要。
转载：优设
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
设计组件库是提升设计效率和一致性的重要工具，但如何在频繁迭代和动态调整中高效赋能业务设计交付，一直是行业面临的挑战。兰亭妙微UI设计公司，分享了他们在设计组件库建设中的新思考和实践，供大家参考学习。
本文将分享我们对于“什么是好的设计组件”的看法，并给出一种搭建复杂组件的实用思路。我们还会从资产消费的角度，提供一些优化建议。虽然过程中会涉及不少基于Figma软件的操作细节，但核心思路就像一把“万能钥匙”，无论在哪个设计平台都行之有效，希望这些内容能给广大设计师们带来一些新的启发。
从网上搜索设计组件，我们能找到各种对外公开的设计组件库，同样还有不少或概括或详细的文章，手把手教你“如何搭建一个好的设计组件库”，但这些方法论很少探讨面对C端组件频繁增改、设计规范动态调整，如何高效赋能业务设计交付的相关内容，但这恰恰是搜索业务面临的关键问题。
搜索是一个“牵一发而动全身”的业务，每一个微小的设计细节都有可能影响各个业务的数据指标，一个“好的设计组件库”需要以一种潜移默化的方式让设计师掌握设计规范，完成合规的设计，从这个角度而言它应该比较「好懂」。
而作为服务于整个设计团队的公用设计组件库，面对每月数以万计的调用次数，它必须保障最基本的易用性，应该非常「好用」。
同时，面对频繁迭代，“好的设计组件”还需要保持最快的更新速度，为各个横向团队提供正确的样式，从这个角度来说它还要「好维护」。
因此，「好懂、好用、好维护」是搜索设计语境下，对一个“好的设计组件”的定义。
接下来，我们将从这三个「好」入手，分享搜索设计组件库在升级过程中的一些思考，希望能和大家共同探讨。
“万丈高楼平地起”，我们先来说说如何从零开始构建一个既符合设计规范又易于理解的设计组件。
首先，在搭建组件时，我们可以考虑采用多层嵌套的方式，即组件(Component)内部嵌套变体(Instance)。这种方式不仅能省去组件搭建和修改过程中的重复操作，甚至还能在解绑组件时，通过选中内部的子组件图层进行解绑，大大简化了搭建和使用双方的操作流程。
在多层嵌套的思路下，我们可以进一步用“底层灵活、上层收敛”来指导组件的搭建。这意味着底层变体的形式足够多样，能够支持大部分的状态切换，而在上层组件搭建的过程中显性地加强规范的指引(如规范中不允许使用的样式不对外展示)，以降低超出规范设计的可能。
具体的搭建流程可以大致分为三步：场景收集和分析、搭建基本变体组、拓展高阶变体组。
我们将通过视频组件搭建的生动案例，具体介绍如何依据“底层灵活、上层收敛”原则来搭建组件库，使得组件本身既足够灵活，又能起到足够的约束作用。
在着手搭建某类组件时，我们首先通过规范确认和场景遍历，广泛收集各类变体。
随后，从我们能想到的所有维度出发，对这些变体进行细致定义。
这样，我们就能得到一张详尽描述组件变体性质的表格。表格的第一列依次列出变体1、变体2、变体3等，而第一行则罗列出各种维度，如宽度、比例等。
通过这种方法，我们可以将原本零散、杂乱的组件变体描述，系统地归纳整理成一张清晰明了的表格。
表格通过不同维度来唯一确定一个变体，这些维度可大致分为两个特性和一个共性。共性指的是所有变体在这一维度上均保持一致，常见特性则涵盖了最常见的分类性质，如宽度、高度、数量和优先级等，而业务特性则与具体业务紧密相关。
在搭建组件时，我们可以遵循「共性-常见特性-业务特性」顺序，这样的顺序有助于降低理解成本，因为最符合心智的分类被置于外层，同时底层的组件又保持了足够的灵活性，便于切换各种变量。对于业务特性，我们可以根据实际情况灵活处理，既可以将其作为基本组件的延展，也可以不将其纳入组件范畴。
以视频组件为例，我们从表格中获取的信息如下：
据此，我们可以轻松梳理出视频组件搭建流程的优先级：
值得注意的是，“封面槽位”是“播放状态”中的一个图层。根据“底层灵活、上层收敛”的原则，我们将其插入到搭建播放状态之前。
因此，视频组件的最终搭建流程为：
完成对视频组件搭建的分析，我们就可以有条不紊地开始搭建组件了。
先搭建基本组件视频组件，再用基本组件搭建高阶组件。
这一步骤虽然为大家所熟知，但仍需格外注意，如配置项的设置要力求合理，也可以融入设计规范和使用规范，同时还应将一些搭建过程中的零散组件集中收纳避免被调用。
关于这些具体的注意事项，我们将在后续部分进行详细阐述。
至此我们完成了组件搭建的基本流程，一个达到及格线的视频组件就诞生了。
据统计，优化后每次调用视频组件将节省至少10步的点击操作！
完成了一个基本组件的搭建后，我们可以转换视角，从使用的角度来审视并检查这个组件。
我们期望，从插入组件变体、切换组件配置，再到最后的解绑组件，整个流程都能纵享丝滑且稳定可靠，确保业务设计师在使用过程中获得最佳体验。
我们可以一步步来审视组件的使用过程。
首先是插入组件，据观察，通常有三种方式：
①在左侧的资产面板(Assets)中直接找到对应组件并插入；
②通过查阅设计规范，锁定所需的变体后复制粘贴；
③选中一个不需要的组件，通过右侧的“切换变体”面板(Swap instance)切换成所需的变体。
很明显，在这个过程中依赖的是组件的精准搜索和快速定位。
为了提升搜索精度，我们可以从组件命名入手，采用中、英、数字结合的方式，实现模糊匹配；也可以在发布时隐藏不希望被调用的组件，以减少无用的搜索结果。
如果组件是采用前文提到的“多层嵌套”方式搭建的，我们可以添加“Preferred”子组件，这样在切换时会优先展示这些子组件，这个功能在切换图标时尤为实用。
对于习惯边查阅设计规范边使用组件的设计师，我们增加了更多实际使用的正误案例，这些案例直观展示了组件变体的正确选择和使用方式，进一步降低了规范的理解成本，有效辅助设计决策。同时，我们专门维护了一个固定区域，用于平铺展示所有组件变体。
为了确保能够轻松点选，我们将变体放在最外层展示(即不在任何Frame、Group或Section中)。这样能让设计师一目了然地看到所有变体，从而快速选择所需的组件。
在组件配置阶段，有三项注意点能让组件更加易用，即“重视组件的可视化效果、设置高效易用的配置项、贴心地保存修改”。
考虑到C端组件的多样性和用户的使用习惯，我们应避免使用过于复杂的分组方式。相反，应更注重组件的样式展示，并尽量简化组件的层级结构。这样，设计师在使用时能够更直观地看到组件的外观，而无需深入复杂的层级去查找。
另外值得注意的是，Figma会默认用组件集合中最左上角的组件生成预览样式，因此应当把视觉上最有代表性的变体放在左上角，这个效果在切换变体(Swap instance)时很重要，因为目前在该面板中没法查看组件细节，只能靠缩略图和名称来推测是哪个组件。
其次对于配置项的设置也大有讲究，业界有组件库为了实现C2D2C，从源头上将设计组件和前端组件的配置项打平，这是不错的思路，但有可能会提升设计侧的理解成本。
针对搜索业务的特殊语境，我们还是选择了从「规范理解」角度去设置组件的配置项，将所有允许自定义的配置尽可能外露，并清晰地说明修改限制，如字数限定、选项个数等，这样能够在使用的过程中强化业务设计师对规范的掌握。
另一个常常被忽视的关键点是选项和配置的排序问题。为了提高浏览和选择的效率，建议对选项和选项之间，以及外层的不同配置项，都按照一定的逻辑顺序进行排序。
最后一点，我们称之为“贴心地保存修改”机制，这个针对的是文字修改的场景。
在实际操作中，使用一个组件可能需要对多个配置项进行修改。有时在修改完文字内容后再去调整其他配置时，已修改的文字会被重置。这时文本属性(text property)的设置就显得尤为重要，它能够记忆并保存修改过的文字内容，从而免于重复输入。
还有一些情况是，某个组件变体实际上并没有与某个值相对应的组件(尽管Figma机制允许选择该值)，用户切换后就会发现组件完全变了，只能撤回。
为了避免这类情况，建议使用另外的标记来表明组件某个设置项是不可切换的。
完成了组件的搭建和检查，接下来让我们聚焦于组件的日常维护。
这一环节可以从两个维度展开，一是依托中台的日常数据监控进行维护，二是通过团队内部的紧密协同机制来保障。后者更多侧重协作流程和机制上的建设，在本文中我们不做更多展开，重点讨论前者。
数据监控的方式主要依托Figma中的组件数据看板(查看路径：View libraries-Analytics)，看板中展示了各个组件的调用数和解绑数数据，这些数据不直接反映组件的优劣，但如果我们观测到某个组件解绑率偏高，我们会考虑直接把它作为模板而不是创建成组件。
以上是百度搜索设计团队在设计组件库升级过程中的心得分享，包括搜索业务对于“好的设计组件”的诉求，以及一些搭建和优化组件的实用思路，核心是探讨如何从组件库建设的角度入手，成功助力团队提升设计资产消费效率。
当前我们已经完成设计资产工程化的前序环节，我们对设计资产的升级和探索并没有结束，未来我们将持续探索设计系统工具化的形态、与AI大模型结合的机会，通过丰富消费途径，实现在业务交付的不同阶段下全方位提效。
这部分内容后续有机会也将会和大家见面，请大家期待！
转载：人人都是产品经理
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
蓝蓝设计的小编 http://www.lanlanwork.com
