★ FEATURED ARTICLE 1. 从“artcraft”这个名字说起它到底想解决什么问题第一次看到“artcraft”这个标题我脑子里蹦出来的第一反应是“艺术”加“手艺”的组合词。直觉告诉我这不是一个纯技术框架的名字也不是某个具体产品的品牌名它更像是一个定位描述——把“艺术化的表达”和“工程化的手艺”捏在一起。后来我花时间把围绕这个词的常见讨论、社区里的零散需求、以及我自己带过的几个项目经验串了一遍基本确认了它的核心指向用工程化的手段去批量生产、管理、交付带有艺术属性的内容或产品。说白了就是那些“既要好看、又要能规模化落地”的活儿。比如一套需要反复迭代的视觉主题系统、一批需要保持风格统一的插画素材、一个需要同时兼顾设计感和性能的前端组件库、甚至是一套手工制品的标准化制作流程。这些东西的共同痛点是纯靠手工做质量高但效率低、不可复制纯靠机器批量生成效率高但千篇一律、没有灵魂。artcraft 要解决的就是这条中间地带的问题。我之所以对这个方向特别有感触是因为过去几年我参与过好几个“设计驱动”的项目几乎每一个都卡在同一个坎上设计师出了一版很惊艳的稿子开发照着实现第一版还行等到要改配色、换字体、调整间距、适配新场景的时候整个系统就开始崩。要么是改一处崩三处要么是设计师和开发互相甩锅。artcraft 这类思路的价值就在于它试图把“艺术决策”和“工程实现”之间的那层模糊地带用一套可描述、可复用、可验证的规则固化下来。这篇文章适合谁看如果你是从业者不管是偏设计、偏前端、偏内容生产还是偏流程管理只要你手上有一摊“需要保持风格一致性、又需要反复迭代”的活儿这里面的思路和实操细节应该都能直接抄作业。如果你只是刚听说这个词想了解个大概我也会尽量用生活化的类比把底层逻辑讲清楚不堆术语。2. 核心思路拆解为什么是“规则化”而不是“模板化”2.1 艺术与手艺的边界在哪里要理解 artcraft 的设计哲学得先把“艺术”和“手艺”这两个词拆开看。艺术的部分核心是决策——选什么颜色、用什么构图、传达什么情绪、在哪个细节上做取舍。这部分高度依赖人的判断很难被完全自动化。手艺的部分核心是执行——把决策落地成具体的像素、代码、材质、尺寸。这部分是可以被标准化、被工具化、被批量处理的。artcraft 的聪明之处在于它没有试图去自动化“艺术决策”而是把重点放在把艺术决策翻译成工程规则。举个例子一个设计师说“这个按钮要看起来柔和一点”这是一句艺术语言。artcraft 要做的是把它翻译成“圆角半径 8px、阴影模糊 12px、主色饱和度降低 15%”这样的工程参数。翻译的过程需要人参与但翻译完之后这套参数就可以被复用、被继承、被批量应用到一百个按钮上。我见过很多团队在这件事上走弯路。一种常见的错误是直接做“模板库”——把设计师做好的成品存成模板下次直接套。问题是模板是死的场景一变就不适用而且套出来的东西千篇一律用户一眼就能看出来是“模板货”。另一种错误是追求“全自动生成”写一堆算法去猜设计意图结果生成的东西要么丑得离谱要么完全不可控。artcraft 走的是中间路线人定规则机器执行规则规则本身可以被版本化管理。2.2 为什么规则化比模板化更抗变化这里我想展开讲一下“规则化”和“模板化”的本质区别因为这是整个 artcraft 思路里最容易被误解的地方。模板化的逻辑是“复制结果”。你有一个好看的页面存下来下次换个内容直接往里填。它的优势是快劣势是脆。一旦内容长度变了、图片比例变了、或者需要适配一个新的终端尺寸模板就崩了。而且模板的数量会随着场景增加而线性膨胀管理成本极高。规则化的逻辑是“复制决策过程”。你不是存一个结果而是存一套“在什么条件下做什么决策”的规则。比如“当容器宽度小于 600px 时主色饱和度降低 10%字号缩小一档间距压缩 20%”。这套规则可以应用到无数个具体场景每个场景生成的结果都不一样但风格是统一的。它的优势是抗变化——场景变了规则还在重新执行一遍就能得到适配新场景的结果。我用一个更生活化的类比来解释。模板化就像买一件成衣尺码合适就穿不合适就只能将就或者换一件。规则化就像找裁缝量体裁衣裁缝手里有一套“根据肩宽、胸围、腰围怎么放样”的手艺你身材怎么变他都能给你做出一件合身的。artcraft 要沉淀的就是这套“裁缝的手艺”而不是那一件件具体的衣服。2.3 一套典型的 artcraft 系统长什么样基于我自己的实践和观察一个完整的 artcraft 系统通常包含四个层次从下往上依次是原子层最基础的不可再分的元素比如颜色值、字号、间距单位、圆角半径、阴影参数、动效时长。这一层的关键是命名和语义化。不要叫“蓝色-500”要叫“主色-强调”不要叫“16px”要叫“间距-中”。语义化的命名让规则可以被跨场景复用。组合层把原子按一定规则组合成组件或片段比如按钮、卡片、标题组、图片容器。这一层的关键是约束——规定哪些原子可以组合、组合时的比例关系是什么、在什么条件下切换变体。模式层把组合按场景组织成完整的页面或流程比如列表页、详情页、表单流程。这一层的关键是继承和覆盖——模式继承组合的规则但允许在特定场景下做局部覆盖覆盖的范围和方式也要有规则约束。治理层规则的版本管理、变更审批、影响范围分析、回滚机制。这一层最容易被忽略但恰恰是决定 artcraft 能不能长期跑下去的关键。没有治理层规则会越改越乱最后变成一锅粥。这四层不是必须严格分开的小项目可以合并但逻辑上要清楚。我见过太多团队只做了前两层就以为大功告成结果规则一多就失控根本原因就是缺了治理层的设计。3. 核心细节解析从“感觉”到“参数”的翻译手艺3.1 语义化命名整个系统的地基如果让我只给一条建议我会说把命名这件事做到极致。artcraft 系统里 80% 的混乱根源都在命名上。我踩过的一个典型坑是这样的早期我们定义了一套颜色变量命名用的是“蓝色-100”到“蓝色-900”这种色阶命名。刚开始用着挺顺后来业务要换品牌色从蓝色换成紫色。这时候问题来了——所有叫“蓝色-500”的变量值都变成了紫色代码里读起来极其别扭。更麻烦的是有些地方我们其实是想表达“这个元素需要突出”有些地方是想表达“这个元素是次要的”但在色阶命名下这两种语义被混在了一起换色的时候根本分不清哪些该跟着换、哪些不该换。后来我们改成了语义化命名分了三层命名层级示例用途变更频率原始色板palette-blue-500仅作为调色板存在不直接使用极低语义色color-primary、color-danger、color-text-secondary表达用途和语义低组件色button-primary-bg、card-border具体组件的具体属性中这样分层之后换品牌色只需要改“语义色”到“原始色板”的映射关系组件层完全不用动。而且因为语义清晰设计师和开发在沟通的时候可以直接说“把这个改成 danger 色”不用再去翻色值表。提示语义化命名的一个实用检验标准是——把变量名念出来如果非技术人员能听懂它表达的是什么用途而不是什么颜色或尺寸那这个命名就是合格的。3.2 参数化决策把“我觉得”变成“当……则……”命名解决的是“叫什么”的问题参数化解决的是“怎么变”的问题。artcraft 系统里最核心的手艺就是把设计师的感性判断翻译成条件规则。我拿一个真实场景来演示。设计师说“在手机上标题不要太抢眼要收敛一点。”这句话怎么翻译首先拆解“抢眼”这个感觉由哪些参数构成字号、字重、颜色对比度、上下留白。然后定义“收敛”的方向字号降一档、字重从 bold 降到 semibold、颜色从纯黑降到 80% 灰、上下留白减少 25%。最后加上触发条件当视口宽度小于 768px 时生效。翻译完的规则大概长这样/* 基础标题样式 */ .title { font-size: var(--font-size-xl); font-weight: 700; color: var(--color-text-primary); margin: var(--space-lg) 0; } /* 移动端收敛规则 */ media (max-width: 768px) { .title { font-size: var(--font-size-lg); font-weight: 600; color: var(--color-text-secondary); margin: var(--space-md) 0; } }这套翻译过程有几个关键点。第一参数要可量化。“降一档”必须对应到具体的变量不能是模糊的“小一点”。第二条件要可验证。768px 这个断点不是拍脑袋定的是根据目标设备的实际分布和内容在该宽度下的表现测出来的。第三规则要可组合。移动端的收敛规则和暗色模式的适配规则、和不同内容密度的规则要能叠加生效而不冲突。我个人的经验是翻译的颗粒度要控制好。太粗了规则不够用太细了规则爆炸。一个实用的判断标准是如果两条规则在 90% 的场景下都是一起出现的那它们应该合并成一条如果两条规则经常需要单独调整那它们应该拆开。3.3 约束与自由度给规则留出呼吸空间规则化最大的风险是“管得太死”导致系统僵化、创意被扼杀。artcraft 系统必须给使用者留出合理的自由度但这个自由度要有边界。我的做法是定义三个层次锁定层绝对不能改的比如品牌主色、核心字号阶梯、基础间距单位。这些是系统的骨架改了整个系统就散了。可调层允许在限定范围内调整的比如某个组件的圆角可以在 4px 到 12px 之间选但必须从预设的几个档位里选不能随便填。自由层完全开放的比如插画的具体内容、文案的措辞、某个特殊场景的一次性布局。这些不影响系统一致性可以放手让创作者发挥。这个分层的关键在于明确告知。系统要清楚地告诉使用者哪些是红线、哪些是选择题、哪些是开放题。我见过一些团队把规则藏得很深使用者不知道边界在哪要么畏手畏脚什么都不敢改要么乱改一通把系统搞崩。把边界显性化本身就是 artcraft 手艺的一部分。4. 实操过程从零搭一套可落地的 artcraft 流程4.1 第一步盘点与抽象把现有资产摸清楚不管你是在一个已有项目上改造还是从零开始第一步都是盘点。把现有的设计稿、代码、素材全部过一遍找出其中重复出现的模式和一次性特例。我通常会做一张表把所有视觉元素按出现频率和一致性分类类别出现频率当前一致性处理策略颜色极高低到处是硬编码色值优先抽象成语义色字号高中有几套并存的阶梯统一成一套阶梯间距极高低随手写数值定义间距单位系统圆角中高直接固化阴影低低定义 2-3 档标准阴影动效低低定义标准时长和缓动曲线这张表的作用是排优先级。频率高、一致性低的优先处理收益最大。频率低、一致性也低的可以先放着等有精力再收拾。不要一上来就追求大而全那样很容易半途而废。盘点的时候有个技巧不要只看设计稿要看实际运行的代码和线上效果。设计稿里写的是“应该是什么样”代码里写的是“实际是什么样”两者经常对不上。以代码为准因为那才是用户真正看到的东西。4.2 第二步定义原子建立最小可用规则集盘点完之后开始定义原子层。这一步的原则是最小可用——先定义那些最基础、最不可能变、被引用最多的原子不要贪多。颜色方面我一般先定义这几组语义色主色、辅助色、成功色、警告色、危险色、信息色加上文本的 primary/secondary/disabled 三级背景的 primary/secondary/tertiary 三级边框的 default/strong 两级。加起来大概二十个左右的语义变量覆盖 90% 的场景。字号方面定义一套 6 到 8 档的阶梯就够了。我常用的是caption、body-sm、body、body-lg、h3、h2、h1、display。每档之间的比例关系要固定比如 1.25 倍或者 1.333 倍这样整体节奏感是统一的。间距方面用 4px 或 8px 作为基础单位定义 6 到 8 档。我偏好 4px 基础单位因为它的灵活性更好能覆盖更细的调整需求。档位大概是4、8、12、16、24、32、48、64。圆角、阴影、动效这些各定义 2 到 4 档就够。圆角我一般用 none、sm、md、lg、full 五档。阴影用 none、sm、md、lg 四档。动效用 fast、normal、slow 三档时长配两三种缓动曲线。注意定义原子的时候一定要同步定义使用场景说明。比如“md 圆角用于卡片和弹窗sm 圆角用于按钮和输入框full 圆角用于标签和头像”。没有场景说明的原子库使用者根本不知道什么时候该用哪个最后还是会乱用。4.3 第三步搭建组合用约束把原子串起来原子定义好之后开始搭组合。组合的核心不是“把原子拼起来”而是“定义拼的规则”。我拿按钮来举例。一个按钮涉及背景色、文字色、边框、圆角、内边距、字号、字重、阴影、动效、各种状态默认、悬停、按下、禁用、加载中。如果每个属性都自由组合那按钮的变体会爆炸。所以要用约束来收敛。我的做法是先定义按钮的类型primary、secondary、ghost、danger 四种。每种类型固定一套原子组合。然后定义尺寸sm、md、lg 三种每种尺寸固定一套内边距和字号。类型和尺寸交叉得到 12 种基础变体。这 12 种覆盖了绝大多数场景特殊场景再单独处理。这套约束的好处是设计师在设计新页面的时候不需要重新发明按钮直接从这 12 种里选。开发在实现的时候也不需要重新写样式直接引用对应的类名或组件。一致性自然就保证了。组合层还有一个关键点是响应式规则。同一个组件在不同屏幕尺寸下怎么变要在组合层就定义好而不是等到页面层再处理。比如卡片组件在桌面端是横向布局、图片在左在移动端是纵向布局、图片在上。这个切换规则属于卡片组件自己的职责不应该让每个使用卡片的页面都去写一遍。4.4 第四步治理机制让规则能长期活下去前三步做完系统能跑起来了。但能不能长期跑下去取决于第四步——治理。治理机制我一般包含四个部分版本管理。规则库要有版本号每次变更都要记录改了什么、为什么改、影响范围是什么。我用的是语义化版本大版本表示破坏性变更中版本表示新增功能小版本表示修复和微调。变更审批。不是谁都能改规则库的。我通常设一个“规则维护者”的角色由设计和技术各出一人共同担任。任何对锁定层和可调层的变更都要经过维护者审核。自由层的变更不需要审批但要在变更日志里留痕。影响范围分析。改一条规则之前要能快速知道它会影响哪些页面、哪些组件。这要求规则库和实际使用之间有清晰的引用关系。我一般会维护一张“规则-使用方”的映射表改规则之前先查表。回滚机制。规则改错了要能快速回滚。这要求每次变更都是原子化的、可逆的。我习惯用 Git 管理规则库每次变更一个 commit回滚就是 revert 一下的事。这套治理机制听起来有点重但实际跑起来之后维护成本远低于“没有治理、到处救火”的成本。我自己的体会是治理机制的价值在系统规模小的时候不明显一旦规则超过一百条、使用方超过三个没有治理就必然失控。5. 常见问题与排查技巧实录5.1 规则冲突当两条规则打架时怎么办规则冲突是 artcraft 系统里最常见的问题。典型场景是移动端适配规则说“字号降一档”暗色模式规则说“字号不变但颜色变浅”两条规则同时命中一个元素到底听谁的我的解决思路是定义优先级。优先级从高到低一般是场景特定规则 状态特定规则 全局规则。移动端适配属于场景特定暗色模式属于状态特定如果两者冲突场景特定优先。但这个优先级不是死的要根据具体业务判断。关键是优先级规则要显性化、要统一不能每个组件自己定一套。排查冲突的时候我习惯用“规则追溯”的方法把命中的规则按优先级列出来逐条检查找到冲突点。大部分冲突其实不是规则本身的问题而是规则定义的时候没有考虑周全。所以每次解决完冲突我都会回头把相关规则补充完整避免同类问题再出现。5.2 规则蔓延为什么系统越用越乱规则蔓延的表现是规则库越来越大但一致性反而越来越差。根本原因通常是例外太多。我见过一个项目最开始只有 20 条规则半年后变成 200 条其中 150 条都是“某某页面特例”。这种系统的维护成本极高而且新人根本学不会。解决规则蔓延我的做法是定期做规则审计。每个季度把规则库过一遍找出那些只用了一两次的规则分析它们为什么存在。如果是因为某个场景确实特殊那就把它归到“自由层”不纳入规则库如果是因为当初偷懒没抽象好那就重新抽象合并到通用规则里。还有一个技巧是设置规则数量的软上限。比如锁定层不超过 30 条可调层不超过 100 条。超过上限就强制审计逼着团队做减法。这个上限不是硬性规定但它能起到预警作用。5.3 跨职能协作设计师和开发怎么对齐artcraft 系统天然是跨职能的设计师和开发必须对齐。但现实中这两拨人的语言体系、关注点、工作节奏都不一样对齐成本很高。我的经验是用规则库本身作为沟通媒介。不要开那种“设计师讲一遍、开发记一遍”的会效率低还容易漏。直接把规则库摆出来设计师看语义和场景开发看参数和实现有分歧的地方当场改规则库。规则库改完了双方的理解就对齐了。另外我强烈建议让开发参与规则定义。很多设计师觉得“这是设计的事开发别掺和”但实际上开发对“这个规则好不好实现、会不会有性能问题、能不能跨端复用”有更准确的判断。让开发早期参与能避免很多后期返工。5.4 常见问题速查表问题现象可能原因排查方向解决思路同一组件在不同页面表现不一致规则未统一或存在局部覆盖检查该组件的规则引用链收敛到统一规则移除不必要的覆盖改一条规则导致多处崩坏规则耦合过紧或缺少影响分析查规则-使用方映射表解耦规则补充影响分析机制新人上手慢、经常用错规则命名不清晰或缺少场景说明检查命名语义和使用文档重命名补充场景说明和示例规则库膨胀、维护成本高例外过多、缺少审计统计规则使用频率定期审计合并或移出低频规则响应式适配混乱断点定义不统一检查各处的断点值统一断点定义收敛到规则库暗色模式适配遗漏颜色未语义化、存在硬编码全局搜索硬编码色值全部替换为语义色变量提示这张表建议打印出来贴在工位上遇到问题先查表能省下大量重复排查的时间。6. 我踩过的坑和几条实在的经验6.1 不要追求一步到位我最早做 artcraft 系统的时候野心很大想一次性把所有规则都定义好。结果花了两个月定义了几百条规则上线之后发现一半都用不上另一半不够用。后来学乖了改成小步快跑先定义最核心的 20 条规则上线用起来根据实际反馈再迭代。这样虽然前期看起来慢但整体效率高得多而且规则都是被实际需求验证过的不会浪费。6.2 文档和规则同等重要规则库本身只是“是什么”文档才是“为什么”和“怎么用”。我见过太多团队只维护规则库不维护文档结果规则库变成了一本天书除了当初定义的人谁都看不懂。我的做法是每一条规则都必须配一段说明它解决什么问题、什么场景下用、什么场景下不用、有没有例外。这段说明和规则本身一起版本管理改规则必须改说明。6.3 留出“逃生舱”再完善的规则系统也会遇到覆盖不了的场景。这时候要留一个“逃生舱”——允许在特定情况下绕过规则但必须留痕、必须说明原因、必须定期回顾。没有逃生舱的系统遇到特殊情况就会逼着使用者去改规则而改规则的成本远高于绕过规则。逃生舱的存在反而让规则系统更稳定。6.4 定期做“规则健康度”检查我一般每个月做一次规则健康度检查看几个指标规则总数是否在合理范围、新增规则的速度、规则被引用的分布是不是少数规则被大量引用、大量规则几乎没人用、冲突和例外的数量。这些指标能提前预警系统是否在走向失控。健康度好的系统规则数量稳定、引用分布均匀、冲突和例外少。健康度差的系统规则数量持续增长、引用集中在少数规则、冲突和例外频发。这套东西说到底核心就一句话把重复的决策沉淀成规则把规则管理好让创作者把精力花在真正需要创意的地方。artcraft 这个词听起来有点文艺但落地下来全是实打实的工程活。我自己的体会是做这套系统最难的从来不是技术而是克制——克制住“什么都想管”的冲动克制住“一次做完”的贪心克制住“规则越多越好”的误解。把边界划清楚把核心规则做扎实剩下的交给使用者的创造力系统反而能活得更好。
阅读完成 · 觉得有帮助？
