当前位置：首页 > news >正文

Weft：为AI编码智能体设计的专业级设计系统蓝图

news 2026/5/3 15:43:21

1. 项目概述：Weft，为AI编码智能体设计的专业级设计蓝图

如果你和我一样，经常和Claude Code、Cursor或者GitHub Copilot这类AI编码助手打交道，那你肯定遇到过这个痛点：你让它“给我做个好看的后台管理页面”，它吭哧吭哧写出来的代码，样式要么是东拼西凑的，要么就是毫无设计逻辑的“默认风”。你得到的可能只是一个颜色代码列表，但为什么用这个颜色？间距怎么定？按钮在不同状态下应该是什么样子？这些关乎产品气质和用户体验的“设计思维”，AI往往一片空白。这就是Weft这个项目要解决的核心问题。

Weft不是一个从现有网站上抓取CSS样式的工具包。恰恰相反，它是一套精心“设计”出来的设计系统蓝图，以DESIGN.md文件的形式呈现。你可以把它理解为一个资深产品设计师写给开发者的、事无巨细的设计需求文档。它包含了从视觉识别、色彩语义、排版系统，到组件行为、无障碍访问规范，甚至是各种边界情况（比如数据为空、加载中、出错状态）的处理方案。你只需要把这个DESIGN.md文件丢到你的项目根目录，然后告诉你的AI助手：“照着这个文件里的规范来设计界面”。接下来，你就能看到AI生成出具有一致性和专业感的UI，仿佛真的有一个设计团队在背后支撑。

这个项目的价值在于，它把“设计决策”前置并固化成了机器可读的指令。对于独立开发者、创业团队或者后端转全栈的朋友来说，这相当于瞬间获得了一个免费的、高水准的“虚拟设计合伙人”。你不用再为UI的细节纠结，也不用担心AI产出物风格混乱，可以更专注于业务逻辑的实现。

2. Weft的核心设计哲学与差异化优势

2.1 从“提取”到“生成”：两种截然不同的路径

市面上已经有一些收集DESIGN.md的项目，比如awesome-design-md。但它们大多采用“提取”模式：爬取像Stripe、Linear这样设计优秀的网站，把它们的CSS变量（设计令牌）扒下来，整理成文件。这种方法的问题在于，你只拿到了“结果”（一串#6366f1这样的色值），却丢失了产生这个结果的“过程”和“逻辑”。为什么Stripe用这个蓝色？它的次级按钮和主要按钮在间距和字重上有什么微妙的区别？这些设计背后的原则和思考，在提取过程中被过滤掉了。

Weft走的是“生成”路径。它的每一个设计系统，都是从一个明确的“设计原型”出发，基于一套完整的设计原则从头构建的。比如“企业级SaaS”这个系统，它的设计原则会明确要求：界面必须清晰、数据密度可以稍高以提升效率、视觉上要传递出可靠和信任感、交互必须高效且可预测。基于这些原则，再去推导出具体的色彩系统（可能偏向冷色调、低饱和度以显得专业）、排版策略（可能使用等宽字体族来展示代码或数据）、以及组件规范。

注意：这种“原则先行”的方法，其优势在于赋予了设计系统强大的适应性和解释性。当AI遇到一个设计规范里没明确写出的新组件时，它可以回溯到设计原则去进行推理和创造，而不是简单地复制粘贴样式。这更接近人类设计师的工作方式。

2.2 超越样式表：一份完整的设计简报

一个典型的WeftDESIGN.md文件，其内容深度远超一份样式指南。它包含12个标准章节，可以分为两大块：

1. 标准章节（与Google Stitch等工具兼容）：这部分确保了与主流AI设计工具的互操作性，涵盖了视觉设计的基础构件。

设计概述：定义产品的视觉个性与品牌基调。
色彩系统：不是简单的色板，而是定义了主色、辅助色、语义色（成功、警告、错误等）及其具体使用场景的规则。
排版系统：包括字体族、字阶、行高、字重，以及字体配对背后的逻辑（比如为什么标题用这个字体，正文用另一个）。
组件样式：详细规定按钮、输入框、卡片、表格、模态框等基础组件的所有状态（默认、悬浮、聚焦、禁用、激活）。
布局与间距：基于一个间距基数（如4px或8px）构建的整套间距系统，以及响应式栅格和断点定义。
阴影与深度：定义不同层级（如卡片、导航栏、模态框、提示框）应该使用的阴影强度，以构建清晰的空间层次。
图标与图像：规定图标的风格（线性、面性、粗细）、尺寸规范，以及图片的裁剪比例、圆角等处理方式。
动效与交互：定义动画的缓动函数、持续时间和交互反馈模式（如下压效果、渐变出现）。
设计护栏：明确列出“应该做”和“不要做”的事项，这是防止设计走偏的关键。

2. 扩展专业章节（Weft的特色）：这部分是Weft的精华，它将专业产品设计中的隐性知识显性化，直接灌输给AI。

无障碍访问标准：强制集成WCAG 2.1 AA级标准。它会明确规定文本与背景的最小对比度（如正常文本4.5:1，大文本3:1）、焦点指示器的样式、为所有图像和图标提供替代文本等。这确保了生成的UI天生就具备良好的可访问性。
边界情况与错误模式：这是很多设计系统忽略的“魔鬼细节”。它预先定义了数据为空时显示的插画和文案、加载中的骨架屏样式、表单验证错误的呈现方式、以及超长文本或数据的截断规则。提前处理好这些，能极大提升产品的鲁棒性和用户体验。
智能体指令：这是专门写给AI看的“说明书”。它会用明确的、无歧义的语言告诉AI如何解读和应用前面的设计规范。例如：“当设计数据表格时，优先考虑可读性，使用斑马纹，并确保表头在滚动时固定。”

2.3 开箱即用的设计系统原型

Weft预置了8个针对不同产品类型的、高度凝练的设计系统原型。每个原型都是一套完整、独立且内部一致的设计世界观。

系统	设计原型	最佳适用场景	核心设计特征
企业级SaaS	洁净、数据密集、可信赖	B2B仪表盘、管理后台、数据分析平台	冷色调为主，布局高效，信息密度高，强调清晰的数据层级和操作效率。
金融科技仪表盘	精确、机构化、数字导向	银行应用、交易平台、支付工具	深色背景搭配高对比度数据可视化，字体多使用等宽或数字优化字体，营造严谨、可靠的氛围。
创意机构	大胆、编辑感、字体驱动	作品集网站、设计工作室、品牌导向网站	大胆的排版实验，可能使用超大字号、非常规布局，色彩鲜艳或有冲击力，强调视觉叙事。
极简电商	产品聚焦、转化驱动	商品店铺、产品详情页、结算流程	大量留白突出产品图片，清晰的视觉动线引导用户完成购买，按钮和提示醒目。
非洲移动优先	数据友好、受USSD启发、高对比度	针对非洲市场的移动端应用	考虑到网络条件和设备性能，设计极度轻量，UI元素大且易于点击，色彩对比强烈确保在户外强光下可读。
开发者工具	代码友好、原生深色、信息密集	开发工具、命令行界面、文档网站	深色主题为主，语法高亮色经过精心调配以减少视觉疲劳，界面布局紧凑以展示大量代码和信息。
健康与 wellness	平静、可访问、建立信任	健康科技、远程医疗、健康平台	使用柔和的、令人放松的色彩（如浅蓝、淡绿），圆角元素多，动效舒缓，整体传递出安全、关怀的感觉。
媒体与 editorial	内容优先、易读、杂志节奏	博客、新闻平台、内容型应用	专注于长篇内容的可读性，有清晰的排版节奏（标题、引文、正文），可能集成杂志化的布局元素。

选择其中一个原型，就相当于为你的项目选择了一位拥有特定专长的“首席设计师”。这比让AI从零开始或漫无目的地模仿要高效和可靠得多。

3. 实战：如何将Weft集成到你的开发工作流中

3.1 环境准备与系统获取

开始之前，你不需要安装任何复杂的运行时或依赖。Weft的本质是文本文件（Markdown），因此获取它非常简单。根据你的使用习惯，有三种主流方式：

方式一：克隆整个仓库（推荐给想要探索或贡献的开发者）这是最全面的方式，让你可以本地查看和比较所有设计系统。

# 克隆仓库到本地 git clone https://github.com/Donald-Edinam/weft.git # 进入仓库目录 cd weft # 此时你可以浏览 systems/ 目录下的所有系统，选择你需要的 # 例如，复制企业级SaaS系统到你的项目根目录 cp systems/enterprise-saas/DESIGN.md /path/to/your/project/

方式二：直接下载单个设计系统文件如果你已经确定要使用某个特定系统，这是最快捷的方式，无需克隆整个项目。

# 使用 curl 直接下载目标 DESIGN.md 文件到当前目录 # 以企业级SaaS为例 curl -O https://raw.githubusercontent.com/Donald-Edinam/weft/main/systems/enterprise-saas/DESIGN.md # 下载后，将其移动到你的项目根目录即可

方式三：集成到特定AI工具（如Claude Code）一些AI工具支持自定义技能或上下文。以Claude Code为例，你可以将Weft作为技能安装，以便在任意项目中快速调用。

# 假设你已经克隆了仓库 cp -r weft/ ~/.claude/skills/ # 之后，在与Claude对话时，你可以直接说： # “请使用 weft 技能中的 enterprise-saas 设计系统来指导本项目的UI开发。”

实操心得：我个人的习惯是克隆整个仓库到本地一个固定的位置（如~/dev/resources/weft）。这样，每当启动一个新项目，我就像走进一个设计库，根据项目类型挑选一个最合适的DESIGN.md，复制过去。这个过程本身也帮助我再次思考项目的产品定位。

3.2 与主流AI编码智能体协同工作

将DESIGN.md文件放置在你的项目根目录后，如何让AI识别并遵循它？不同的工具有不同的交互方式。

1. 与 Claude Code / Claude Desktop 配合：Claude对项目根目录下的DESIGN.md有天然的关注度。你只需要在指令中明确提及它。

“请为这个用户管理系统开发一个前端界面。所有样式和组件设计，请严格遵循项目根目录下的 DESIGN.md 文件中的规范。特别是色彩系统、间距和按钮组件样式。”

更高级的用法是，在对话开始时就让Claude“学习”这个文件。

“请先仔细阅读项目根目录下的 DESIGN.md 文件，理解我们项目的设计系统。之后的所有UI代码生成，都请基于此系统进行。”

2. 与 Cursor 配合：Cursor的优势在于它能深度理解项目上下文。只需将DESIGN.md放在项目根目录，Cursor在分析项目时就会自动将其作为重要参考。当你使用Cmd+K打开AI指令框并输入“创建一个设置页面”时，Cursor生成的代码会自然地倾向于符合DESIGN.md中定义的样式。

3. 与 GitHub Copilot 配合：Copilot主要通过注释来获得提示。你可以在组件文件的开头添加类似这样的注释：

// @design-system: 遵循 ./DESIGN.md 中的企业级SaaS规范 // 色彩使用语义色，间距基于8px基数，组件状态需完整。

当你开始输入<button时，Copilot给出的补全建议就会倾向于符合注释中引用的设计系统。

4. 与 Google Stitch 配合：Stitch本身就是一个AI驱动的UI设计工具。你可以直接将Weft的DESIGN.md内容导入到Stitch项目的“设计系统”面板中。这样，Stitch在生成设计稿或代码时，就会完全基于这套系统，实现从设计到代码的一致性。

3.3 自定义与扩展：打造属于你自己的设计系统

Weft提供的8个原型是优秀的起点，但你的品牌或产品可能有独特的需求。这时，自定义就变得非常重要。项目提供了一个清晰的/_template/DESIGN.md文件作为模板。

自定义步骤通常如下：

复制模板：cp weft/_template/DESIGN.md ./MY_PROJECT_DESIGN.md
定义设计概述：思考你的品牌个性。是“专业可信”还是“活泼创新”？用3-5个关键词描述。
构建色彩系统：确定主色、辅助色、中性色和语义色。关键点：不要只写色值，一定要定义每个颜色的使用场景（如：主色用于主要按钮和关键标识；错误色用于表单验证信息和危险操作）。
制定排版规则：选择字体，建立字阶（如：--text-xs: 0.75rem）。解释字体配对的原因（例如：无衬线字体用于UI，衬线字体用于长文阅读以提升可读性）。

详述组件样式：这是最繁重但也最重要的部分。为每个组件定义所有状态。以按钮为例：

### 按钮 - **基础样式**：内边距（垂直`0.75rem`，水平`1.5rem`），边框圆角`0.375rem`，字体重量`600`。 - **主要按钮**：背景色使用 `--color-primary-600`，文字白色。 - **次要按钮**：背景透明，边框 `1px solid --color-neutral-300`，文字色 `--color-neutral-700`。 - **状态**： - 悬浮：主要按钮背景色加深至 `--color-primary-700`；次要按钮边框色加深至 `--color-neutral-400`。 - 禁用：透明度降至 `0.5`，鼠标指针变为 `not-allowed`。

填充专业章节：务必认真填写“无障碍访问”和“边界情况”。这能极大提升产品的专业度和完整性。

注意事项：自定义时，保持内部一致性至关重要。你的间距基数、圆角大小、阴影强度最好能形成比例关系。例如，如果基础间距是8px，那么组件的内边距可以是16px (8*2)，外边距可以是24px (8*3)，大圆角可以是16px (8*2)。这种数学关系能让视觉体验非常和谐。

4. 深入解析：Weft设计系统中的关键实现细节

4.1 色彩系统的语义化构建

一个专业的色彩系统绝不是一堆色卡的集合。Weft中的色彩系统是语义化的。这意味着颜色是通过其“用途”来命名的，而不是其“外观”。

糟糕的命名（基于外观）：

--blue-500: #3b82f6; --red-500: #ef4444; --gray-200: #e5e7eb;

这种命名方式对开发者不友好。当需要修改主题色时，你需要把所有--blue-500找出来替换，容易出错。

Weft采用的语义化命名（基于用途）：

/* 基础色板 - 用于派生语义色 */ --color-primary-500: #3b82f6; --color-error-500: #ef4444; --color-neutral-200: #e5e7eb; /* 语义化变量 - 在UI中实际使用 */ --color-bg-primary: var(--color-primary-500); /* 主要按钮背景 */ --color-text-error: var(--color-error-500); /* 错误提示文字 */ --color-border-default: var(--color-neutral-300); /* 默认边框 */

在DESIGN.md中，我们会明确规定：

--color-bg-primary用于：主要操作按钮、关键标识、激活状态。
--color-text-error用于：表单验证错误信息、删除操作确认文本。
--color-border-default用于：输入框、卡片、分割线的默认边框。

这样做的好处是，如果我们想将品牌色从蓝色改为绿色，只需修改--color-primary-500的定义，所有使用--color-bg-primary的地方都会自动更新，UI的语义保持不变。AI在生成代码时，也应该直接使用这些语义化变量，而不是具体的色值。

4.2 间距与布局的体系化思维

混乱的间距是让UI看起来“不专业”的元凶之一。Weft强制推行基于基数的间距系统。

1. 定义基数：通常选择4px或8px作为基础单位。绝大多数现代屏幕分辨率能被8整除，因此8px是一个非常安全且高效的选择。2. 创建间距尺度：基于基数生成一系列尺度值。

--space-unit: 0.5rem; /* 假设 1rem = 16px, 则 0.5rem = 8px */ --space-1: calc(var(--space-unit) * 0.5); /* 4px */ --space-2: var(--space-unit); /* 8px */ --space-3: calc(var(--space-unit) * 1.5); /* 12px */ --space-4: calc(var(--space-unit) * 2); /* 16px */ --space-5: calc(var(--space-unit) * 3); /* 24px */ --space-6: calc(var(--space-unit) * 4); /* 32px */ /* ... 以此类推 */

3. 规定使用场景：在DESIGN.md中明确：

元素内部填充（padding）：通常使用--space-3或--space-4。
元素之间的外边距（margin）：通常使用--space-4或--space-5。
区块之间的间距：使用--space-6或更大。
行高（line-height）：通常设置为无单位值，如1.5或1.75。

4. 响应式栅格：定义不同屏幕宽度下的栅格列数和槽宽（gutter）。例如：

移动端 (< 768px)：4列，槽宽--space-4。
平板端 (768px ~ 1024px)：8列，槽宽--space-4。
桌面端 (> 1024px)：12列，槽宽--space-5。

当AI需要创建一个卡片布局时，它就知道应该使用栅格类或CSS Grid，并应用预定义的间距变量，从而保证跨页面、跨组件的一致性。

4.3 组件状态的完整定义与无障碍访问集成

一个按钮不仅有默认状态。Weft要求完整定义组件的所有交互状态，并将无障碍访问要求融入其中。

以输入框组件为例，在DESIGN.md中会这样描述：

### 文本输入框 - **容器**：背景色 `--color-bg-surface`，边框 `1px solid --color-border-default`，圆角 `--radius-md`。 - **状态**： - **默认**：如上所述。 - **悬浮**：边框色变为 `--color-border-hover`（通常比默认边框深一个色阶）。 - **聚焦**：边框色变为 `--color-border-focus`（通常使用主色），并添加 `box-shadow: 0 0 0 3px var(--color-primary-100)` 作为聚焦环。**（关键：这个阴影环是WCAG要求的高可见性焦点指示器，不能仅用边框色变化代替）**。 - **禁用**：背景色变为 `--color-bg-disabled`，边框色变浅，文字颜色变淡，设置 `cursor: not-allowed`。 - **错误**：边框色变为 `--color-border-error`，左侧可能附加一个错误图标，下方显示错误提示文字（使用 `--color-text-error`）。 - **无障碍要求**： - 必须关联 `<label>` 元素，或使用 `aria-label`。 - 错误状态必须通过 `aria-invalid="true"` 和 `aria-describedby` 关联到错误提示元素。 - 聚焦环的样式不能被 `outline: none` 覆盖，除非提供了同等可见的替代方案。

通过如此详细的定义，AI生成的输入框代码就会是完整、健壮且具备可访问性的。它知道不仅要写样式，还要添加正确的ARIA属性。

4.4 边界情况：设计系统的试金石

“边界情况”的处理能力是区分业余设计和专业设计的关键。Weft为每个系统都预定义了这些场景的模式。

1. 空状态：

设计原则：空状态不是错误，而是引导用户进行下一步操作的机会。
规范示例：“当列表无数据时，显示一个居中的插画（使用--color-neutral-300），下方配一句鼓励性的文案（如‘还没有任务，创建一个吧？’），并放置一个主要操作按钮。”
AI实现提示：AI在生成列表组件时，应该同时生成一个条件渲染的空状态UI片段。

2. 加载状态：

设计原则：提供即时反馈，缓解用户等待焦虑。
规范示例：“使用骨架屏。骨架屏元素应使用比背景色稍浅的颜色（--color-neutral-100），并添加微弱的脉动动画。骨架屏的形状应尽量接近最终内容的轮廓。”
AI实现提示：AI应能生成通用的骨架屏CSS动画和组件。

3. 错误处理：

设计原则：清晰告知问题，并提供恢复路径。
规范示例：“网络错误或操作失败时，使用顶部横幅通知（背景色--color-bg-error-subtle，边框色--color-border-error）。通知内容应包括错误图标、简明扼要的错误描述，以及一个‘重试’或‘了解更多’的链接。”
AI实现提示：AI在编写涉及网络请求的代码时，应能同时生成错误状态下的UI渲染逻辑。

将这些模式写入DESIGN.md，就等于提前为AI处理各种复杂场景编写了“剧本”，确保了用户体验的完整性。

5. 常见问题、排查技巧与进阶实践

5.1 AI不遵循DESIGN.md？问题排查指南

即使有了详细的DESIGN.md，AI有时也会“跑偏”。以下是常见问题及解决方法：

问题现象	可能原因	解决方案
AI完全忽略设计文件，生成默认样式。	1. 文件未放在项目根目录。 2. AI智能体（如Copilot）未正确加载项目上下文。 3. 指令中未明确提及`DESIGN.md`。	1. 确认`DESIGN.md`在项目最外层文件夹。 2. 重启你的AI工具或编辑器，确保其重新索引项目文件。 3.在每次相关指令中，明确加上“请参考根目录下的DESIGN.md文件”。
AI部分遵循，但在某些细节（如圆角、阴影）上不一致。	1. 设计规范描述不够精确或存在歧义。 2. AI对某些CSS属性的优先级理解有误。	1. 检查`DESIGN.md`，确保规范是量化的（如`border-radius: 0.5rem`，而不是“中等圆角”）。 2. 在`DESIGN.md`的“组件样式”章节，为关键组件提供接近完整的CSS示例，减少AI猜测的空间。
AI生成了正确的样式，但HTML结构或ARIA属性不符合无障碍要求。	无障碍规范可能被AI视为“建议”而非“强制规则”。	1. 在`DESIGN.md`的“智能体指令”章节，用最强硬的语气强调无障碍规则必须遵守。 2. 在生成组件后，手动检查并补充指令，如：“为刚才生成的按钮添加适当的ARIA标签。”
在不同会话中，AI对同一规范的解释不一致。	AI的上下文窗口有限，可能“忘记”了之前读过的部分规范。	1. 将`DESIGN.md`文件内容提炼成更简短的“设计提示”，放在每个需要生成UI的代码文件顶部作为注释。 2. 考虑将核心的设计令牌（色彩、间距变量）提取到单独的CSS变量文件中，让AI直接引用这些变量，而非记忆具体值。

5.2 与CSS框架（如Tailwind CSS）的协同策略

Weft的设计规范是框架无关的。但如果你使用像Tailwind CSS这样的实用类优先框架，如何结合？

策略一：将Weft规范映射为Tailwind配置这是最彻底的方法。根据DESIGN.md，修改你的tailwind.config.js。

// tailwind.config.js module.exports = { theme: { extend: { colors: { primary: { 50: '#eff6ff', 100: '#dbeafe', // ... 根据 DESIGN.md 的色板定义所有颜色 600: '#2563eb', // --color-primary-600 }, error: { 500: '#ef4444', // --color-error-500 } }, spacing: { 'unit': '0.5rem', // 8px '1': '0.25rem', // 4px = 0.5 * unit '2': '0.5rem', // 8px = 1 * unit '3': '0.75rem', // 12px = 1.5 * unit '4': '1rem', // 16px = 2 * unit // ... 映射所有间距尺度 }, borderRadius: { 'md': '0.375rem', // 与 DESIGN.md 中的 --radius-md 对应 } } } }

之后，你可以指示AI：“使用Tailwind CSS类名，并遵循我们配置文件中的设计令牌。”

策略二：混合使用CSS变量与Tailwind在CSS中定义Weft的CSS变量，然后在Tailwind中通过@apply或直接使用[var(--xxx)]来引用。

/* styles/globals.css */ :root { --color-bg-primary: #2563eb; --space-4: 1rem; }

<!-- 在组件中 --> <button class="bg-[var(--color-bg-primary)] px-[var(--space-4)] ..."> <!-- 按钮内容 --> </button>

这种方式更灵活，但生成的类名可能较长。

实操心得：对于新项目，我强烈推荐策略一。它能让AI生成的代码（如bg-primary-600 px-4）既符合设计规范，又保持了Tailwind的简洁性。对于已有项目引入Weft，策略二的侵入性更小。

5.3 维护与迭代：让设计系统随着产品成长

一个设计系统不是一成不变的。随着产品功能增加，你可能会发现需要新的组件或变量。

1. 如何添加新组件？假设DESIGN.md里没有“时间线”组件，但你的产品需要。

步骤一：在DESIGN.md的“组件样式”章节新增“时间线”小节。
步骤二：参照现有组件的描述格式，定义它的所有视觉样式（颜色、间距、连接线样式、节点图标等）和所有状态（当前步骤、已完成步骤、未来步骤）。
步骤三：思考它的无障碍访问要求（如何用屏幕阅读器感知步骤？），并在“无障碍访问标准”章节补充说明。
步骤四：在“边界情况”中思考，如果时间线步骤非常多怎么办？是否需要折叠？如何显示？
步骤五：在“智能体指令”中增加一条：“当需要渲染时间线或步骤流程时，请使用新定义的‘时间线’组件规范。”

2. 如何更新设计令牌？如果你想将主色从蓝色调整为绿色。

步骤一：在DESIGN.md的“色彩系统”章节，更新--color-primary-*系列的所有色值。
步骤二：至关重要：检查所有引用这些颜色的语义化变量（如--color-bg-primary）是否会自动更新（如果使用了CSSvar()，则会自动更新）。
步骤三：运行一个全局搜索，检查是否有硬编码的旧色值残留在代码或AI提示中，并更新它们。
步骤四：告知你的团队成员和AI（通过更新提示），设计系统的主色已更新。

3. 版本化你的DESIGN.md对于团队项目，可以考虑将DESIGN.md也纳入版本控制。你可以在文件顶部添加一个版本号和历史记录。

# 设计系统 v1.2.0 ## 更新日志 - v1.2.0 (2023-10-27): 新增“时间线”组件；将主色从 `#2563eb` 调整为 `#059669`。 - v1.1.0 (2023-09-15): 完善了错误状态的视觉规范。 - v1.0.0 (2023-08-01): 初始版本，基于企业级SaaS原型。

这样，任何人都能清晰地看到设计系统的演变过程。

5.4 衡量效果：如何评估Weft带来的价值

引入Weft后，如何判断它是否真的提升了效率和质量？可以从以下几个维度观察：

UI一致性：随机抽查不同页面或由不同AI会话生成的组件，检查它们在颜色、间距、圆角等细节上是否一致。一致性越高，说明设计系统被遵循得越好。
开发速度：记录在引入Weft前后，完成一个典型UI页面（如仪表盘、设置页）所需的平均时间和与AI的沟通回合数。理想情况下，沟通成本应显著下降。
设计决策时间：观察团队成员或你自己在面临“这个按钮应该用什么颜色？”这类问题时，是开始争论还是能迅速在DESIGN.md中找到答案。
无障碍基线：使用浏览器开发者工具的无障碍检查器或 Lighthouse 工具，扫描AI生成的页面。由于Weft内置了WCAG规范，你的页面无障碍评分应该有一个基础保障。
设计还原度：如果你有设计师提供的设计稿，对比AI直接生成（无Weft）和基于Weft生成的代码，看哪一方在视觉上更接近设计稿。通常，基于原则的Weft能更好地还原设计意图，尤其是在处理设计稿中未明确标注的边界情况时。

从我个人的使用经验来看，Weft最大的价值在于它将设计决策从一次次的、重复的、临时的AI对话中，前置并固化为了一个可重复使用的、可迭代的单一事实来源。它可能不会让你第一次就得到100分的设计，但它能确保你每次都能稳定地输出80分以上的、专业的、一致的设计成果，从而让你能将宝贵的精力集中在更核心的业务逻辑和创新上。

查看全文

http://www.jsqmd.com/news/745248/