Artcraft项目实战：如何将审美拆解为可复用技术方案

1. 从“artcraft”这个名字说起：它到底想解决什么问题

第一次看到“artcraft”这个标题，我脑子里蹦出来的第一反应是“艺术”加“手艺”的组合词。直觉告诉我，这大概率不是一个纯艺术项目，也不是一个纯工程工具，而是那种把审美和动手能力揉在一起的东西。后来跟几个做独立开发的朋友聊，发现大家对这个词的理解出奇一致：它代表一种“把想法用手做出来，并且做得好看”的诉求。这个诉求听起来很虚，但落到实际项目里，它非常具体——比如你要做一个个人作品集网站、一个手作电商的展示页、一个生成艺术的小工具，甚至是一个给非设计师用的海报生成器，这些都属于 artcraft 的范畴。

我之所以对这个方向感兴趣，是因为过去几年我参与过好几个类似的项目，踩过的坑几乎一模一样：一开始觉得“不就是画个界面吗”，做到一半发现配色怎么调都不对，字体一换整个版式就崩，动效加多了像廉价广告，加少了又显得死板。更麻烦的是，这类项目往往没有明确的需求文档，甲方或者自己脑子里只有一个模糊的“感觉”，而“感觉”是最难翻译成代码和参数的东西。所以 artcraft 这个标题背后，真正要解决的核心问题是：如何把主观的审美判断，拆解成可执行、可复用、可调试的技术方案。

这篇文章我想聊的就是这个。我会从整体设计思路、核心细节、实操过程、常见问题四个大块展开，把我在 artcraft 类项目里积累的经验尽量倒干净。适合谁看？如果你正在做一个跟视觉、手作、创意工具相关的项目，不管你是前端、全栈还是独立开发者，只要你需要自己搞定“好看”这件事，那这些内容应该对你有用。我不打算讲太多空泛的设计理论，重点放在“我实际是怎么做的”和“为什么这么做”。

2. 内容整体设计与思路拆解

2.1 为什么 artcraft 类项目不能按普通 CRUD 的思路做

普通的管理系统或者工具类应用，核心是数据和逻辑：输入什么、存什么、输出什么，路径清晰，对错分明。但 artcraft 类项目不一样，它的核心是感知。用户看到界面的第一眼，零点几秒内就形成了判断，这个判断不是逻辑推理出来的，是直觉。这就导致一个很尴尬的局面：你按照需求把功能都实现了，测试也过了，但拿给人看的时候，对方说“感觉不对”。你问哪里不对，他说不上来。

我吃过这个亏。早期做一个手作展示平台，功能列表列了三十多项，全部做完花了两个月，结果内测的时候用户停留时间极短。后来复盘发现，问题出在首屏的视觉重心上——我们把最重要的手作图片放在了轮播图里，而轮播图的高度被压缩到只有屏幕的三分之一，下面塞了一堆分类入口和推荐位。用户第一眼看到的是密密麻麻的入口，而不是作品本身。这就是典型的“功能思维”压过了“感知思维”。

所以 artcraft 类项目的设计思路，我总结下来应该是先定感知目标，再倒推功能和技术。具体来说，在写第一行代码之前，我会先问自己三个问题：第一，用户看到这个界面的前 3 秒，我希望他感受到什么？是安静、是热闹、是专业、还是亲切？第二，这个感受主要由哪些视觉元素承载？是色彩、留白、字体、还是动效？第三，这些元素里，哪些是我能用现有技术低成本实现的，哪些是需要额外投入的？

这三个问题看起来简单，但能帮你省掉大量返工。我现在的习惯是，在项目启动阶段先做一张“感知关键词表”，把抽象的感觉翻译成具体的视觉参数。比如“安静”对应低饱和度、大留白、细字体、慢动效；“热闹”对应高饱和度、密集元素、粗字体、快节奏切换。这张表不需要很精确，但必须有，因为它是你后续所有技术决策的依据。

2.2 技术选型的核心考量：可控性大于先进性

artcraft 类项目在技术选型上有一个很明显的陷阱：容易被新工具吸引。今天看到某个新的 CSS 框架，明天看到某个动效库，都想往里塞。我早期也这样，结果项目里堆了四五套不同的样式方案，维护起来痛不欲生。后来我给自己定了一条规矩：在 artcraft 项目里，可控性比先进性重要。

什么叫可控性？就是当你想调整一个像素、一个颜色、一个缓动曲线的时候，你知道去哪里改，改完之后影响范围有多大。举个例子，Tailwind 这类原子化 CSS 在普通项目里效率很高，但在 artcraft 项目里我反而会谨慎使用。原因是当你要做精细的视觉调整时，类名会变得极其冗长，而且很难看出哪些样式是相互关联的。相比之下，我更喜欢用 CSS Modules 或者原生 CSS 变量配合一套自定义的设计令牌（Design Token）体系。设计令牌说白了就是把你所有的颜色、间距、字号、圆角、阴影都定义成变量，放在一个统一的地方管理。这样做的好处是，当你想把整体色调从冷色改成暖色，只需要改几个变量值，而不是满项目搜索替换。

动效方面也是同样的逻辑。GSAP 功能强大，但学习曲线陡峭，而且和某些框架的集成需要额外处理。Framer Motion 在 React 生态里很顺手，但如果你用的是 Vue 或者原生 JS，就不太合适。我的建议是，如果项目动效需求不复杂，优先用 CSS transition 和 animation 搞定；如果确实需要时间线控制、物理缓动这些高级功能，再引入专门的库。不要为了一个淡入淡出效果引入一个 50KB 的库，这是 artcraft 项目里最常见的过度工程。

2.3 设计系统的搭建：从“每次重新想”到“按规则组合”

artcraft 类项目做到后面，你会发现一个规律：大部分界面其实是由少数几种“模式”组合而成的。比如卡片、列表、详情、表单、空状态、加载状态，这些模式在不同页面反复出现。如果你每次做新页面都从头写样式，不仅效率低，而且很容易出现同一个组件在不同页面长得不一样的情况。

所以搭建一个轻量的设计系统是很有必要的。注意我说的是“轻量”，不是那种大公司级别的组件库。对于个人项目或者小团队来说，设计系统只需要包含三样东西：设计令牌、基础组件、布局规则。

设计令牌前面说了，就是变量。基础组件不需要多，按钮、输入框、卡片、标签、弹窗，这五个覆盖 80% 的场景。布局规则指的是栅格系统和间距节奏。我习惯用 8px 作为基础间距单位，所有间距都是 8 的倍数，这样视觉上会有一种内在的秩序感，用户说不出来但能感觉到。字号方面，我会定义一个模数比例，比如 1.25 或者 1.333，用基准字号乘以比例得到各级字号，这样标题和正文之间的层级关系是数学上和谐的，而不是拍脑袋定的。

这套东西搭起来大概需要两三天，但后面每做一个新页面都能省下大量时间，而且整体一致性会好很多。我实测下来，有了设计系统之后，做一个中等复杂度的页面从原来的大半天缩短到两三个小时，而且返工率明显下降。

3. 核心细节解析与实操要点

3.1 色彩系统的搭建：别再用取色器随便吸了

色彩是 artcraft 项目里最容易出问题的地方。我见过太多项目，颜色是从某个喜欢的网站上吸下来的，单独看每个颜色都挺好看，放在一起就打架。原因很简单：那些颜色来自不同的色彩体系，明度、饱和度、色相之间的关系没有逻辑。

我的做法是，先确定一个主色，然后基于这个主色生成一套完整的色阶。具体操作是，把主色转换到 HSL 色彩空间，固定色相 H，然后调整饱和度和明度，生成从 50 到 900 的十个层级。这个过程可以用工具辅助，但理解原理很重要。为什么用 HSL 而不是 RGB？因为 HSL 更符合人对颜色的直觉：H 是颜色种类，S 是鲜艳程度，L 是明暗。当你需要“同一个颜色但浅一点”的时候，只需要调 L 值，色相不会跑偏。

生成色阶之后，还需要定义语义色。什么叫语义色？就是不要直接用“蓝色”“红色”这样的名字，而是用“主色”“成功色”“警告色”“危险色”“中性色”这样的功能名。这样做的好处是，当你想把主色从蓝色换成紫色，只需要改一个映射关系，所有用到主色的地方自动更新。中性色尤其重要，artcraft 项目里大量的背景、边框、次要文字都是中性色，一套好的中性色阶能让界面看起来干净、有层次。

注意：中性色不要用纯灰。纯灰（饱和度 0）在屏幕上会显得死板，稍微加一点点主色的色相偏移，比如饱和度 5% 到 10%，会让整体色调更统一。这个技巧很多设计师都在用，但文档里很少写。

还有一个实操细节：深色模式和浅色模式不要简单地反转颜色。我试过直接反转，结果对比度完全不对，有些文字在深色模式下几乎看不清。正确的做法是，为深色模式单独定义一套语义色映射，背景用深灰而不是纯黑，文字用浅灰而不是纯白，主色适当降低饱和度。这样切换模式的时候，视觉体验才是连贯的。

3.2 字体与排版：行高和字距比字体本身更重要

很多人在 artcraft 项目里会花大量时间挑选字体，但实际影响阅读体验的，往往是行高、字距、段落间距这些“看不见”的参数。我的经验是，字体选一套靠谱的无衬线体作为正文，再选一套有特点的作为标题，基本就够了。正文优先考虑可读性，标题可以稍微有个性一点，但不要用那种装饰性太强的字体，否则在小屏幕上会糊成一团。

行高方面，正文的行高设置在 1.5 到 1.7 之间比较舒服。标题的行高要收紧，大概 1.2 到 1.3，因为标题通常只有一两行，行高太大反而显得松散。字距这个参数很多人忽略，其实它对质感影响很大。大字号标题适当收紧字距（负值），会显得更紧凑有力；小字号文字适当放宽字距（正值），会显得更清晰易读。这个调整幅度很小，通常以 em 为单位，零点零几的变化就能感觉到差别。

段落间距我习惯用行高的 0.75 倍左右。比如行高是 1.6，段落间距就是 1.2em。这样段落之间的呼吸感刚好，不会太挤也不会太散。另外，正文的行宽要控制，太宽了眼睛扫视会累，太窄了频繁换行也累。一般控制在 45 到 75 个字符之间，中文的话大概 25 到 35 个字。这个可以用 max-width 配合 ch 单位来实现，比如max-width: 65ch。

3.3 动效的节奏感：缓动曲线决定“高级感”

artcraft 项目里，动效是区分“能用”和“好用”的关键。但动效不是越多越好，也不是越快越好。我见过一些项目，每个元素都在动，结果整个界面像在抽搐。动效的核心是节奏，而节奏由持续时间和缓动曲线共同决定。

持续时间方面，我的经验值是：微交互（比如按钮按下、开关切换）控制在 100 到 200 毫秒；元素入场出场控制在 200 到 400 毫秒；页面级转场控制在 400 到 600 毫秒。超过 600 毫秒用户就会觉得慢，低于 100 毫秒又感觉不到。这个范围不是绝对的，但可以作为起点。

缓动曲线比持续时间更影响感知。默认的ease其实很平庸，我一般会用自定义的贝塞尔曲线。入场用cubic-bezier(0.16, 1, 0.3, 1)，这个曲线起步快、收尾慢，有一种“轻盈落定”的感觉。出场用cubic-bezier(0.7, 0, 0.84, 0)，起步慢、收尾快，显得干脆。这两个曲线我用了很久，在大多数场景下都比默认值更有质感。

提示：动效要尊重用户的系统设置。如果用户开启了“减少动态效果”，你的动效应该自动降级为简单的淡入淡出或者直接切换。这个用 CSS 的prefers-reduced-motion媒体查询就能实现，几行代码的事，但体现了对用户的尊重。

还有一个细节：多个元素同时动的时候，不要用同一个持续时间，稍微错开一点会更有层次。比如列表项入场，每个项延迟 30 到 50 毫秒，形成一种波浪式的效果。这个延迟不要太大，否则用户会觉得卡。我一般用 CSS 的transition-delay配合nth-child来实现，或者用 JS 在渲染时计算延迟。

4. 实操过程与核心环节实现

4.1 从零搭建一个 artcraft 项目的样式基础

假设现在要从零开始一个 artcraft 类项目，我会按下面的顺序来搭样式基础。第一步是建立设计令牌文件，用 CSS 变量定义所有基础值。这个文件通常叫tokens.css，内容大概长这样：

:root { /* 色阶 */ --color-primary-50: hsl(220, 80%, 97%); --color-primary-100: hsl(220, 80%, 93%); --color-primary-500: hsl(220, 80%, 55%); --color-primary-900: hsl(220, 80%, 20%); /* 语义色 */ --color-bg: var(--color-neutral-50); --color-text: var(--color-neutral-900); --color-text-secondary: var(--color-neutral-600); --color-border: var(--color-neutral-200); /* 间距 */ --space-1: 0.25rem; --space-2: 0.5rem; --space-3: 0.75rem; --space-4: 1rem; --space-6: 1.5rem; --space-8: 2rem; /* 字号 */ --text-sm: 0.875rem; --text-base: 1rem; --text-lg: 1.125rem; --text-xl: 1.25rem; --text-2xl: 1.5rem; --text-3xl: 1.875rem; /* 圆角 */ --radius-sm: 0.25rem; --radius-md: 0.5rem; --radius-lg: 1rem; --radius-full: 9999px; /* 阴影 */ --shadow-sm: 0 1px 2px rgba(0,0,0,0.05); --shadow-md: 0 4px 6px rgba(0,0,0,0.07); --shadow-lg: 0 10px 15px rgba(0,0,0,0.1); /* 动效 */ --ease-out: cubic-bezier(0.16, 1, 0.3, 1); --ease-in: cubic-bezier(0.7, 0, 0.84, 0); --duration-fast: 150ms; --duration-normal: 300ms; --duration-slow: 500ms; }

这个文件是整个项目的视觉基石。所有组件样式都引用这些变量，不写死任何具体值。这样做的好处是，当你想调整整体风格，只需要改这个文件。比如把主色从蓝色改成紫色，只需要改--color-primary-*这一组值，全站自动更新。

第二步是建立基础组件样式。我一般会写一个base.css，处理重置样式、全局字体、链接样式、选中样式这些。重置样式不要用那种特别激进的，把所有的 margin 和 padding 都清零，那样后面还得一个个加回来。我习惯只重置必要的：box-sizing: border-box、margin: 0、padding: 0，然后给 body 设置基础字体和背景色。

第三步是布局系统。我不用复杂的栅格框架，就用 CSS Grid 和 Flexbox 组合。定义一个.container类，设置最大宽度和水平居中；定义一个.stack类，用display: flex; flex-direction: column; gap: var(--space-4)来处理垂直排列；定义一个.cluster类，用display: flex; flex-wrap: wrap; gap: var(--space-3)来处理水平排列。这三个类覆盖了大部分布局需求，而且语义清晰，一看就知道是干什么的。

4.2 一个卡片组件的完整实现过程

卡片是 artcraft 项目里最常用的组件之一，我拿它来演示完整的实现过程。首先明确卡片的构成：容器、图片区、内容区、标题、描述、底部操作区。然后确定交互状态：默认、悬停、按下、聚焦。最后确定变体：带图片和不带图片、横向和纵向、可点击和不可点击。

先写基础结构：

<article class="card"> <div class="card__media"> <img src="..." alt="..." /> </div> <div class="card__body"> <h3 class="card__title">标题</h3> <p class="card__desc">描述文字</p> </div> <div class="card__footer"> <button class="btn">操作</button> </div> </article>

然后写样式。这里的关键是，卡片的视觉层次要靠阴影和边框来建立，而不是靠背景色差异。我见过很多卡片用浅灰色背景，结果和页面背景混在一起，边界模糊。正确的做法是卡片用白色背景，加一层很淡的阴影，再加一条极细的边框。阴影负责“浮起来”的感觉，边框负责“有边界”的感觉，两者配合，卡片在视觉上就立住了。

.card { background: var(--color-surface); border: 1px solid var(--color-border); border-radius: var(--radius-lg); box-shadow: var(--shadow-sm); overflow: hidden; transition: box-shadow var(--duration-normal) var(--ease-out), transform var(--duration-normal) var(--ease-out); } .card:hover { box-shadow: var(--shadow-md); transform: translateY(-2px); } .card__media { aspect-ratio: 16 / 9; overflow: hidden; } .card__media img { width: 100%; height: 100%; object-fit: cover; transition: transform var(--duration-slow) var(--ease-out); } .card:hover .card__media img { transform: scale(1.05); } .card__body { padding: var(--space-4); } .card__title { font-size: var(--text-lg); line-height: 1.3; margin-bottom: var(--space-2); } .card__desc { font-size: var(--text-sm); color: var(--color-text-secondary); line-height: 1.6; }

这段代码里有几个值得说的点。aspect-ratio用来固定图片区域的比例，避免图片加载前后布局跳动。object-fit: cover保证图片填满区域且不变形。悬停时图片轻微放大，配合卡片的位移，形成一种“被吸引”的感觉。这些细节单独看都很小，但组合起来就是质感。

注意：transform和box-shadow的过渡不要用all，要明确指定属性。用all会导致一些意外的属性也被过渡，比如颜色变化会变得很慢，而且性能也不好。明确指定属性是更好的实践。

4.3 响应式处理的实操策略

artcraft 项目的响应式，我的原则是移动端优先，但不要教条。移动端优先的意思是，先写小屏幕的样式，然后用min-width媒体查询逐步增强。这样做的好处是，移动端的样式更简单，先写简单的，再叠加复杂的，逻辑更清晰。

断点设置我不喜欢用太多，三个就够了：640px（大屏手机横屏或小平板）、1024px（平板横屏或小笔记本）、1280px（桌面）。超过 1280px 的屏幕，内容区域用 max-width 限制住就行，不需要额外的断点。

响应式里最容易出问题的是导航和网格。导航在移动端通常折叠成汉堡菜单，这个交互要处理好焦点管理和滚动锁定，否则用户体验很差。网格方面，我习惯用grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))这种自适应写法，让浏览器自动计算列数，而不是手动写每个断点的列数。这样代码更简洁，而且在不同屏幕宽度下过渡更平滑。

还有一个细节：移动端的点击目标不要小于 44px。这是人手指的平均触摸精度决定的，小于这个尺寸用户很容易点错。按钮、链接、开关这些交互元素，都要保证足够的点击区域。如果视觉上需要小一点，可以用 padding 把实际点击区域撑大。

5. 常见问题与排查技巧实录

5.1 视觉不一致的排查思路

视觉不一致是 artcraft 项目里最常被抱怨的问题。表现是：同一个按钮在不同页面颜色不一样，同一个间距在不同模块大小不同，同一个圆角在不同组件上不一致。排查这种问题，我的方法是从设计令牌往下查。

先检查所有颜色值是否都来自令牌。如果发现某个地方写了硬编码的颜色值，比如#3b82f6而不是var(--color-primary-500)，那就是问题源头。这种情况通常发生在赶工的时候，直接复制了一个颜色值，后面忘了替换。我的做法是，在代码检查工具里加一条规则，禁止在组件样式里出现十六进制颜色值，强制使用变量。这个规则一加，视觉不一致的问题能减少一大半。

间距不一致也是类似的原因。有些地方用margin: 16px，有些地方用margin: 1rem，有些地方用margin: var(--space-4)，虽然值一样，但维护起来容易乱。统一用令牌之后，这个问题就消失了。圆角不一致通常是组件之间没有共享样式，各自写各自的。解决办法是把圆角也纳入令牌体系，所有组件都引用同一组圆角变量。

5.2 动效卡顿的性能排查

动效卡顿在低端设备上特别明显。排查思路是看动效影响了哪些 CSS 属性。如果动效改的是width、height、top、left、margin这些属性，浏览器需要重新计算布局，性能开销很大。正确的做法是只动transform和opacity，这两个属性可以由 GPU 直接处理，不触发重排重绘。

我遇到过一个案例，一个列表的入场动效用的是height从 0 到 auto 的过渡，在电脑上看着没问题，在手机上卡成幻灯片。后来改成transform: scaleY()配合opacity，瞬间流畅了。还有一个常见问题是同时动太多元素，比如一个页面上几十个卡片同时做入场动效，GPU 也扛不住。解决办法是分批动，或者只对可视区域内的元素做动效，屏幕外的等滚动到了再触发。

提示：用浏览器的性能面板录制一段动效，看看有没有掉帧。如果帧率低于 60fps，就要找原因。常见原因包括：动效属性不对、同时动的元素太多、阴影或模糊效果太重、图片太大没有压缩。

5.3 常见问题速查表

这张表里的问题，我几乎每一个都实际遇到过。最想强调的是“滚动穿透”这一条，因为它在开发阶段很容易被忽略，但用户一用就能发现。弹窗打开的时候，背景还能滚动，体验非常糟糕。解决办法是在弹窗打开时给 body 加一个overflow: hidden，关闭时移除。如果弹窗内部需要滚动，给弹窗内容区单独设置overflow: auto。

5.4 几个我踩过的坑和对应的经验

第一个坑是过度依赖设计工具。我早期做项目，喜欢先在设计工具里把每个页面画出来，然后照着实现。问题是设计工具里的效果和浏览器里的效果往往有差异，字体渲染、阴影、渐变这些都不一样。照着做出来总觉得哪里不对，然后反复调，效率很低。后来我改成直接在浏览器里调，用开发者工具实时改样式，看到满意了再写回代码。这样所见即所得，效率高很多。

第二个坑是忽略内容的变化。做设计的时候用的是占位文字，长度刚好，看起来很美。换成真实内容之后，有的标题特别长，有的描述特别短，整个布局就乱了。解决办法是在开发阶段就用真实内容或者接近真实长度的内容来测试。标题要测试最长的情况，描述要测试最短和最长的情况，图片要测试不同宽高比的情况。这样才能保证布局的健壮性。

第三个坑是动效加得太满。刚开始做 artcraft 项目的时候，觉得每个元素都应该有动效，结果整个页面像在跳舞。后来学会做减法，只给关键交互加动效，其他保持静止。静止不是缺点，静止是节奏的一部分。有静才有动，全都在动等于没有动。

第四个坑是忽视无障碍。颜色对比度不够、焦点状态不明显、图片没有 alt 文本，这些问题在视觉上可能看不出来，但对一部分用户来说是致命的。我现在的习惯是，每做完一个页面，用无障碍检查工具跑一遍，确保对比度达标、焦点可见、语义标签正确。这些检查花不了几分钟，但能避免很多问题。

6. 工具链与协作方式的个人选择

6.1 我实际在用的工具组合

工具这块我不追求最新最热，追求的是稳定和顺手。样式方面，我用 PostCSS 配合几个插件：autoprefixer 处理兼容性，postcss-nested 支持嵌套写法，postcss-custom-media 管理媒体查询。不用 Sass 或者 Less，因为 CSS 变量已经能解决大部分问题，原生嵌套也在逐步支持，没必要引入额外的预处理器。

构建工具我用 Vite，启动快，热更新快，配置简单。对于 artcraft 类项目来说，构建速度很重要，因为你需要频繁地改样式看效果，等构建的时间越短越好。Vite 在这方面的体验目前是最好的。

版本控制用 Git，这个没什么好说的。但我想强调一点：artcraft 项目的提交信息要写清楚改了什么视觉元素。比如“调整主色色阶，提高对比度”比“更新样式”有用得多。因为视觉调整往往是反复的，过一段时间你可能忘了为什么改，好的提交信息能帮你回忆起来。

6.2 设计令牌的维护方式

设计令牌不是定完就不管了，它会随着项目演进不断调整。我的做法是，把令牌文件当作一个独立的模块来维护，每次调整都记录变更原因。比如“把主色从 500 调到 600，因为 500 在白底上对比度不足”。这样后面如果有人问为什么是这个值，你能答上来。

令牌的命名也要有规律。我习惯用“类别-属性-变体”的格式，比如color-primary-500、space-4、text-lg、radius-md。这样在代码里引用的时候，一看名字就知道是什么。不要用blue、big、round这种模糊的名字，后面一定会乱。

还有一个实操建议：令牌文件里加注释，说明每个令牌的用途和使用场景。比如--color-text-secondary用于次要文字，不要用于正文。这样团队协作的时候，别人不会用错。注释不用多，一句话就行，但能省很多沟通成本。

6.3 和设计师协作的注意事项

如果你是和设计师协作，有几个点要提前对齐。第一，设计稿的尺寸和实际开发的尺寸要一致，不要一个用 375px 一个用 390px，否则间距和字号都要重新算。第二，设计稿里的颜色、字号、间距要标注清楚，最好直接对应到你的设计令牌。如果设计师用的工具能导出令牌，那就更好了。第三，动效的描述要具体，不要只说“淡入”，要说清楚持续时间、缓动曲线、延迟。这些参数不明确，实现出来肯定和预期有差距。

我遇到过设计师给了一个“弹跳”的动效描述，我按自己的理解做了，结果设计师说不是这个感觉。后来我们坐下来一起调，发现他想要的是那种“落地后轻微回弹”的效果，缓动曲线要用cubic-bezier(0.34, 1.56, 0.64, 1)。这个曲线我记到现在，因为它确实好用。所以协作的时候，参数要具体，感觉要翻译成数值。

7. 这个方向后续可以怎么扩展

artcraft 这个方向往下走，有几个我觉得值得尝试的扩展点。一个是把设计令牌和主题系统结合起来，让用户能自己切换主题，甚至自定义主色。这个技术上不难，用 CSS 变量覆盖就行，但体验上会很加分。另一个是引入生成式的方法，比如根据用户上传的图片自动提取配色方案，生成匹配的界面主题。这个需要一些色彩算法的知识，但实现起来并不复杂。

还有一个方向是把手作和数字结合起来，比如做一个工具，让用户上传手作过程的照片，自动生成一个带时间线和步骤说明的展示页面。这个涉及图片处理、布局生成、动效编排，是 artcraft 的典型应用场景。我最近在琢磨这个，等有进展了再单独写一篇。

最后分享一个小技巧：如果你觉得界面“差点意思”但又说不上来哪里不对，试试把整个界面的饱和度降低 10%，或者把圆角统一加大一档，或者把阴影的模糊半径增加 20%。这三个调整任意一个，往往就能让质感提升一个档次。原理我说不太清楚，但实测有效，你可以试试。