每个人都在谈论AI而我完全不知道从哪里开始。这就是我如何停止在工具中溺水最终理清这一切的方法。我在凌晨3:37醒来写这篇文章。不是因为我自律。是因为我在梦到它——真的在梦里编辑段落——醒来时脑子里有一个句子我必须在它消失之前写下来。这就是AI焦虑对设计师的影响。你听说Claude Code、Cursor、MCP服务器、AI代理——你知道你应该学习这些。你的同事在谈论它。你的信息流里全是它。但你打开终端感觉就像降落在另一个星球。你告诉自己这个周末会搞清楚。然后三个周末过去了焦虑只会加剧。因为在你脑海深处有这样一个想法如果我不跟上我将是第一批被淘汰的人。我知道因为我经常从设计师朋友那里听到我想学但我没时间。冲动在那里。门槛阻止了人们。对于非技术背景的设计师来说这个门槛是真实的。我是一名产品设计师。我不是以写代码为生。所以当我第一次开始使用Claude Code做设计工作时这种体验老实说让人不知所措。技能、插件、MCP、终端命令、配置文件、符号链接、JSON配置——这些概念都牢牢属于开发者领域。每个教程都假设我已经知道符号链接是什么。每个指南都说只需添加MCP服务器好像这是正常的句子。技能本身呢到处散落。有些在桌面应用中有些在终端中有些在我必须手动找到的文件夹中。我不知道什么连接到什么哪个工具做什么工作或者如何随着增长而保持组织。如果你是一个盯着Claude Code的设计师想着这很强大但我不知道如何管理这一切——一个月前我就是这样的。开始之前声明我不声称这是权威做法。AI工具发展很快我分享的是今天对我有效的快照。其中一些在你读到时可能已经过时了。但背后的思考——如何组织技能、如何分割环境、如何构建设计知识使其可扩展——这部分我认为会持久。至少我希望这给你一个起点这样你不必盯着空白终端不知道从哪里开始。这里我将分享让一切变得清晰的心智模型各个部分是什么、为什么需要两个环境以及保持一切组织和可扩展的技能架构。观点仅代表我个人。1、建立正确的心智模型在任何设置之前了解你实际在处理什么很有帮助。有很多术语在流传——代理、MCP、技能、插件、提示——它很快变得令人困惑。但重点是你只需要掌握三个核心概念就能开始。其他的会在过程中学会。想象一下你正在入职一位聪明的新设计师他对你的公司零经验。他们聪明、快速、热切——但他们对你的设计系统、产品、原则或工具一无所知。在他们能做真正的工作之前你需要给他们什么你需要转移两种东西。首先是知识——你的设计原则、库中存在什么组件、你的品牌声音和语调。其次是能力——如何审查屏幕、如何将PRD转化为设计简报、如何对照Figma运行QA检查。知识是设计师装在脑子里的东西。能力是他们知道如何做的事情。好的设计师需要两者。Claude也需要。这正是你在设置的┌─────────────────────────────────────────────┐ │ 你设计师 │ │ │ │ 这是你需要知道和做的 │ │ │ │ │ ▼ │ │ ┌────────────────────────────────┐ │ │ │ Claude │ │ │ │ │ │ │ │ 技能 MCP服务器 │ │ │ │ 大脑 手 │ │ │ │ │ │ │ │ • 原则 • Figma │ │ │ │ • 组件 • Jira │ │ │ │ • 如何 • wiki │ │ │ │ 审查 • ... │ │ │ │ • 如何 │ │ │ │ 生成 │ │ │ └────────────────────────────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ ▼ ▼ │ │ ┌────────────┐ ┌────────────┐ │ │ │ Cowork │ │ Terminal │ │ │ │ 思考 │ │ 绘图 │ │ │ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────┘你只需要三个概念技能是让Claude成为你公司称职设计师的一切。有些技能是知识——你的设计原则、组件规范、内容指南。其他是能力——如何运行设计审查、如何从PRD生成Figma框架、如何审查现有屏幕的UX问题。这样想如果你不会期望新设计师在第一天就知道什么那它可能需要成为一项技能。MCP服务器模型上下文协议是工具访问。它们是让Claude与外部工具对话的连接器——Figma、Jira、你的wiki等等。设计师可以用心记住每个原则但他们仍然需要打开Figma才能工作。MCP就是这个——根据技能知识行动的手。环境是工作空间。对设计师来说有两个重要的它们擅长不同的事情。那就是我们开始的地方。2、为什么需要两个环境在我解释设置之前想想你作为设计师每天实际做什么。绘图可能只占工作的30%。其余的阅读PRD并尝试提取真正重要的东西。审查现有屏幕以发现问题。撰写设计理由。将你的工作与原则对比。在文档中为你的设计决策辩护。研究模式。给予和接收批评。与工程师协调规格。设计是一个偶尔产生像素的思考工作。所以当我看AI工具时我不只是需要能绘图的东西。我需要能帮我思考的东西——也能在需要时绘图。这就是为什么我最终使用两个环境而不是一个。**Cowork桌面应用UI**处理思考方面。它有一个视觉界面对不是终端用户的人来说感觉自然——我们大多数人都是。这是我从Figma截图进行设计批评、通过Chrome阅读和注释wiki页面、撰写设计文档和演示文稿、进行研究和分析的地方。对于像我这样的视觉导向的人来说这是完成设计师日常大部分思考工作更直观的地方。这里也是我与Claude一起编写技能的地方——是的这意味着你可以让AI帮助编写自己的训练材料。你描述你想让它知道的内容它为你起草技能文件。你不需要从头写SKILL.md文件。更多内容请参见从哪里开始部分。终端Claude Code处理Figma连接。这是我在哪里通过自定义Figma插件使用设计系统组件生成设计、直接编辑Figma节点以及做任何需要与Figma桌面应用实时连接的事情。分组如下Cowork桌面UI 终端Claude Code ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ │ │ ✅ 设计批评 │ │ ✅ 生成Figma │ │ ✅ 阅读wiki/Chrome │ │ 设计 │ │ ✅ 撰写文档/幻灯片 │ │ ✅ 编辑Figma节点 │ │ ✅ 研究/分析 │ │ │ │ ✅ 与Claude一起 │ │ │ │ 创建技能 │ │ │ │ │ │ │ │ 思考 │ │ 绘图 │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ └──────────┬──────────────────┘ │ 两个环境都能 ✅ Figma截图 ✅ 编辑/创建技能 ✅ 撰写文档和幻灯片 ✅ 设计批评大多数日常工作发生在Cowork中。终端专门用于将东西推入Figma。3、为什么Cowork不能渲染到Figma这开始让我困惑所以值得解释。Cowork在你的Mac上的远程VM中运行。当Claude需要将设计推入Figma时它通过本地WebSocket连接在localhost与Figma桌面插件通信。但VM的localhost和你的Mac的localhost不是同一个——Figma插件无法接收设计数据。终端Claude Code直接在你的Mac上运行与Figma共享相同的localhost。连接工作正常。从Cowork拍摄Figma截图和读取元数据工作正常——那些使用云API而不是本地连接。只有实时渲染将组件推入Figma需要终端。4、真正重要的部分如何组织技能以免变成混乱双环境设置让你连接起来。但我挣扎的真正问题是如何组织技能使其可扩展早期我的技能到处都是——一个技能用于组件一个用于审查一个用于语气全部松散地放在一起。有些重叠。有些相互矛盾。Claude会加载错误的或者一次加载三个并变得困惑。那是一片混乱。修复方法是将技能视为设计系统——具有层次、清晰职责和明确依赖。经过几次迭代我确定了三层架构层1 — 参考技能知识 ┌─────────────────────────────────────────────────┐ │ │ │ 通用跨所有项目共享 │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 设计 │ │ 组件和 │ │ │ │ 原则 │ │ token规范 │ │ │ │ 为什么 │ │ 是什么 │ │ │ └───────────────┘ └─────────────────────┘ │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 内容 │ │ 动效规范 │ │ │ │ 策略 │ │ │ │ │ └───────────────┘ └─────────────────────┘ │ │ │ │ 领域产品特定 │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 产品领域 │ │ 未来小组 │ │ │ │ -设计 │ │ 技能... │ │ │ └───────────────┘ └─────────────────────┘ │ └──────────────────────┬──────────────────────────┘ │ 被加载 ▼ 层2 — 能力技能工作流 ┌─────────────────────────────────────────────────┐ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 生成- │ │ 设计- │ ...以及 │ │ │ 设计 │ │ 审查 │ 更多8个 │ │ │ │ │ │ │ │ │ 加载 │ │ 加载 │ │ │ │ • 原则 │ │ • 原则 │ │ │ │ • 规范 │ │ • 规范 │ │ │ │ • 内容 │ │ • Figma MCP │ │ │ └──────────────┘ └──────────────┘ │ └──────────────────────┬──────────────────────────┘ │ 连接到 ▼ 层3 — 工具和连接器MCP ┌─────────────────────────────────────────────────┐ │ ┌────────┐ ┌────────────┐ ┌──────┐ ┌───────┐ │ │ │ Figma │ │ Figma │ │ Jira │ │ wiki │ │ │ │ 渲染 │ │ 截图 │ │ │ │ │ │ │ └────────┘ └────────────┘ └──────┘ └───────┘ │ └─────────────────────────────────────────────────┘4.1 层1参考技能知识参考技能保存知识——它们本身不做工作。它们被能力技能按需加载。我将这些分为两类通用参考技能跨所有项目共享设计原则——设计系统背后的为什么。评估框架、视觉层次规则、设计哲学。这是教Claude判断的技能。组件和token规范——组件、token和图标的唯一真实来源。这是渲染工具在生成设计时读取的内容。内容策略——声音和语气规则、按UI元素的文案模式、产品词汇。动效规范——时间曲线、持续时间、过渡模式、微交互规范。领域参考技能保存产品特定知识限定在特定垂直领域。例如如果你正在为特定产品领域设计领域技能可能编码该产品特定的UX模式、信息架构、交互流程和微文案指南。我发现最重要的区别组件/token规范技能和设计原则技能扮演互补角色。一个知道什么是正确的规范、token、组件。另一个知道为什么某事是对的或错的哲学、评估、判断。一个执行一个评估。询问规范“使用哪个组件”“token应用正确吗”——任何有明确正确答案的事情。询问原则“这是上下文中正确的组件吗”“这个设计尊重用户需求吗”“视觉层次有效吗”“这在移动设备上有效吗”“流程逻辑吗”——任何需要判断的事情。4.2 层2能力技能工作流能力技能运行工作流——它们编排工具和参考技能以完成设计任务。每个加载它需要的参考技能并调用所需的工具。以下是我构建的能力技能类型独立无依赖read-filter-prd从PRD提取UI/UX需求。create-design-ticket从需求结构化Jira设计工单。define-flow映射用户流和交互状态。research进行设计前基准测试和证据收集。sell-design-vision帮助推销设计项目和报告影响。依赖参考技能identify-ux-problems审计现有设计加载原则可选规范。generate-design创建静态高保真Figma框架加载原则、规范、内容策略。generate-prototype创建交互式动画原型加载动效、规范、原则。依赖参考技能Figma MCPdesign-review对实时设计进行启发式评估加载原则、规范连接到Figma。qa-signoff进行视觉QA比较实现与Figma源文件加载规范连接到Figma。4.3 层3工具和连接器这些是提供外部集成的MCP服务器——Figma的REST API用于截图和元数据、用于推送设计的渲染插件、用于节点级编辑的TalkToFigma以及你使用的任何项目管理集成。5、典型管道流程这个架构的力量在于技能组合成管道PRD驱动read-filter-prd → create-design-ticket → define-flow → generate-design → design-review → qa-signoff设计发起identify-ux-problems → research → sell-design-vision → define-flow → generate-design快速生成你已经知道你想要什么直接向渲染工具描述屏幕——CLAUDE.md确保自动引用原则。设计审查粘贴Figma链接或截图Claude根据你的设计原则批评并推送注释。6、从哪里开始这篇文章有很多概念——层次、管道、两个环境。重点是你不需要在第一天就构建所有东西。架构是目的地。你可以一步一步走到那里。如果我今天从零开始我会按这个顺序做第1周安装Claude Code。连接Figma MCP。创建一个技能——只有一个——描述你的设计原则。这里是消除最可怕障碍的部分你不需要从头写SKILL.md文件。只需告诉Claude帮我创建一个描述我们设计原则的技能然后开始交谈。粘贴你的设计指南文档解释什么是重要的Claude会为你起草技能文件。你审查、调整、完成。然后粘贴截图并要求Claude根据这些原则审查它。你会立即感受到通用AI反馈和真正理解你系统的反馈之间的区别。那个时刻让你上瘾。第2周添加组件/token规范技能。尝试生成一个简单框架。当Claude第一次推送一个真实的、可编辑的Figma框架使用你实际的设计系统组件——不是图像不是线框图而是你可以检查和修改的框架——你会明白为什么这个设置值得最初的摩擦。第3周及以后构建你的第一个能力技能。从设计审查开始——它是最高价值、最低风险的工作流。然后生成。然后原型制作。每个都建立在你已经编写的参考技能之上。分层架构——参考知识、能力工作流和工具连接器——是让整个东西长期可维护的原因。当我更新设计原则或添加新组件规范时依赖它的每个工作流自动获得更新。没有重复没有偏差。这就是早期组织的回报。一个月前我是一个自学校以来就没打开过终端的设计师。现在我有一个AI设计伙伴它比团队中大多数人更了解我的设计系统。这一切发生在大约四周内。我的设置完美吗可能不。其中一些在几个月内会过时吗也许。但差距从来不在于拥有完美的工具链——而在于拥有任何有组织的起点。原文链接设计师的Claude Code指南 - 汇智网
设计师的Claude Code指南
每个人都在谈论AI而我完全不知道从哪里开始。这就是我如何停止在工具中溺水最终理清这一切的方法。我在凌晨3:37醒来写这篇文章。不是因为我自律。是因为我在梦到它——真的在梦里编辑段落——醒来时脑子里有一个句子我必须在它消失之前写下来。这就是AI焦虑对设计师的影响。你听说Claude Code、Cursor、MCP服务器、AI代理——你知道你应该学习这些。你的同事在谈论它。你的信息流里全是它。但你打开终端感觉就像降落在另一个星球。你告诉自己这个周末会搞清楚。然后三个周末过去了焦虑只会加剧。因为在你脑海深处有这样一个想法如果我不跟上我将是第一批被淘汰的人。我知道因为我经常从设计师朋友那里听到我想学但我没时间。冲动在那里。门槛阻止了人们。对于非技术背景的设计师来说这个门槛是真实的。我是一名产品设计师。我不是以写代码为生。所以当我第一次开始使用Claude Code做设计工作时这种体验老实说让人不知所措。技能、插件、MCP、终端命令、配置文件、符号链接、JSON配置——这些概念都牢牢属于开发者领域。每个教程都假设我已经知道符号链接是什么。每个指南都说只需添加MCP服务器好像这是正常的句子。技能本身呢到处散落。有些在桌面应用中有些在终端中有些在我必须手动找到的文件夹中。我不知道什么连接到什么哪个工具做什么工作或者如何随着增长而保持组织。如果你是一个盯着Claude Code的设计师想着这很强大但我不知道如何管理这一切——一个月前我就是这样的。开始之前声明我不声称这是权威做法。AI工具发展很快我分享的是今天对我有效的快照。其中一些在你读到时可能已经过时了。但背后的思考——如何组织技能、如何分割环境、如何构建设计知识使其可扩展——这部分我认为会持久。至少我希望这给你一个起点这样你不必盯着空白终端不知道从哪里开始。这里我将分享让一切变得清晰的心智模型各个部分是什么、为什么需要两个环境以及保持一切组织和可扩展的技能架构。观点仅代表我个人。1、建立正确的心智模型在任何设置之前了解你实际在处理什么很有帮助。有很多术语在流传——代理、MCP、技能、插件、提示——它很快变得令人困惑。但重点是你只需要掌握三个核心概念就能开始。其他的会在过程中学会。想象一下你正在入职一位聪明的新设计师他对你的公司零经验。他们聪明、快速、热切——但他们对你的设计系统、产品、原则或工具一无所知。在他们能做真正的工作之前你需要给他们什么你需要转移两种东西。首先是知识——你的设计原则、库中存在什么组件、你的品牌声音和语调。其次是能力——如何审查屏幕、如何将PRD转化为设计简报、如何对照Figma运行QA检查。知识是设计师装在脑子里的东西。能力是他们知道如何做的事情。好的设计师需要两者。Claude也需要。这正是你在设置的┌─────────────────────────────────────────────┐ │ 你设计师 │ │ │ │ 这是你需要知道和做的 │ │ │ │ │ ▼ │ │ ┌────────────────────────────────┐ │ │ │ Claude │ │ │ │ │ │ │ │ 技能 MCP服务器 │ │ │ │ 大脑 手 │ │ │ │ │ │ │ │ • 原则 • Figma │ │ │ │ • 组件 • Jira │ │ │ │ • 如何 • wiki │ │ │ │ 审查 • ... │ │ │ │ • 如何 │ │ │ │ 生成 │ │ │ └────────────────────────────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ ▼ ▼ │ │ ┌────────────┐ ┌────────────┐ │ │ │ Cowork │ │ Terminal │ │ │ │ 思考 │ │ 绘图 │ │ │ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────┘你只需要三个概念技能是让Claude成为你公司称职设计师的一切。有些技能是知识——你的设计原则、组件规范、内容指南。其他是能力——如何运行设计审查、如何从PRD生成Figma框架、如何审查现有屏幕的UX问题。这样想如果你不会期望新设计师在第一天就知道什么那它可能需要成为一项技能。MCP服务器模型上下文协议是工具访问。它们是让Claude与外部工具对话的连接器——Figma、Jira、你的wiki等等。设计师可以用心记住每个原则但他们仍然需要打开Figma才能工作。MCP就是这个——根据技能知识行动的手。环境是工作空间。对设计师来说有两个重要的它们擅长不同的事情。那就是我们开始的地方。2、为什么需要两个环境在我解释设置之前想想你作为设计师每天实际做什么。绘图可能只占工作的30%。其余的阅读PRD并尝试提取真正重要的东西。审查现有屏幕以发现问题。撰写设计理由。将你的工作与原则对比。在文档中为你的设计决策辩护。研究模式。给予和接收批评。与工程师协调规格。设计是一个偶尔产生像素的思考工作。所以当我看AI工具时我不只是需要能绘图的东西。我需要能帮我思考的东西——也能在需要时绘图。这就是为什么我最终使用两个环境而不是一个。**Cowork桌面应用UI**处理思考方面。它有一个视觉界面对不是终端用户的人来说感觉自然——我们大多数人都是。这是我从Figma截图进行设计批评、通过Chrome阅读和注释wiki页面、撰写设计文档和演示文稿、进行研究和分析的地方。对于像我这样的视觉导向的人来说这是完成设计师日常大部分思考工作更直观的地方。这里也是我与Claude一起编写技能的地方——是的这意味着你可以让AI帮助编写自己的训练材料。你描述你想让它知道的内容它为你起草技能文件。你不需要从头写SKILL.md文件。更多内容请参见从哪里开始部分。终端Claude Code处理Figma连接。这是我在哪里通过自定义Figma插件使用设计系统组件生成设计、直接编辑Figma节点以及做任何需要与Figma桌面应用实时连接的事情。分组如下Cowork桌面UI 终端Claude Code ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ │ │ ✅ 设计批评 │ │ ✅ 生成Figma │ │ ✅ 阅读wiki/Chrome │ │ 设计 │ │ ✅ 撰写文档/幻灯片 │ │ ✅ 编辑Figma节点 │ │ ✅ 研究/分析 │ │ │ │ ✅ 与Claude一起 │ │ │ │ 创建技能 │ │ │ │ │ │ │ │ 思考 │ │ 绘图 │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ └──────────┬──────────────────┘ │ 两个环境都能 ✅ Figma截图 ✅ 编辑/创建技能 ✅ 撰写文档和幻灯片 ✅ 设计批评大多数日常工作发生在Cowork中。终端专门用于将东西推入Figma。3、为什么Cowork不能渲染到Figma这开始让我困惑所以值得解释。Cowork在你的Mac上的远程VM中运行。当Claude需要将设计推入Figma时它通过本地WebSocket连接在localhost与Figma桌面插件通信。但VM的localhost和你的Mac的localhost不是同一个——Figma插件无法接收设计数据。终端Claude Code直接在你的Mac上运行与Figma共享相同的localhost。连接工作正常。从Cowork拍摄Figma截图和读取元数据工作正常——那些使用云API而不是本地连接。只有实时渲染将组件推入Figma需要终端。4、真正重要的部分如何组织技能以免变成混乱双环境设置让你连接起来。但我挣扎的真正问题是如何组织技能使其可扩展早期我的技能到处都是——一个技能用于组件一个用于审查一个用于语气全部松散地放在一起。有些重叠。有些相互矛盾。Claude会加载错误的或者一次加载三个并变得困惑。那是一片混乱。修复方法是将技能视为设计系统——具有层次、清晰职责和明确依赖。经过几次迭代我确定了三层架构层1 — 参考技能知识 ┌─────────────────────────────────────────────────┐ │ │ │ 通用跨所有项目共享 │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 设计 │ │ 组件和 │ │ │ │ 原则 │ │ token规范 │ │ │ │ 为什么 │ │ 是什么 │ │ │ └───────────────┘ └─────────────────────┘ │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 内容 │ │ 动效规范 │ │ │ │ 策略 │ │ │ │ │ └───────────────┘ └─────────────────────┘ │ │ │ │ 领域产品特定 │ │ ┌───────────────┐ ┌─────────────────────┐ │ │ │ 产品领域 │ │ 未来小组 │ │ │ │ -设计 │ │ 技能... │ │ │ └───────────────┘ └─────────────────────┘ │ └──────────────────────┬──────────────────────────┘ │ 被加载 ▼ 层2 — 能力技能工作流 ┌─────────────────────────────────────────────────┐ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 生成- │ │ 设计- │ ...以及 │ │ │ 设计 │ │ 审查 │ 更多8个 │ │ │ │ │ │ │ │ │ 加载 │ │ 加载 │ │ │ │ • 原则 │ │ • 原则 │ │ │ │ • 规范 │ │ • 规范 │ │ │ │ • 内容 │ │ • Figma MCP │ │ │ └──────────────┘ └──────────────┘ │ └──────────────────────┬──────────────────────────┘ │ 连接到 ▼ 层3 — 工具和连接器MCP ┌─────────────────────────────────────────────────┐ │ ┌────────┐ ┌────────────┐ ┌──────┐ ┌───────┐ │ │ │ Figma │ │ Figma │ │ Jira │ │ wiki │ │ │ │ 渲染 │ │ 截图 │ │ │ │ │ │ │ └────────┘ └────────────┘ └──────┘ └───────┘ │ └─────────────────────────────────────────────────┘4.1 层1参考技能知识参考技能保存知识——它们本身不做工作。它们被能力技能按需加载。我将这些分为两类通用参考技能跨所有项目共享设计原则——设计系统背后的为什么。评估框架、视觉层次规则、设计哲学。这是教Claude判断的技能。组件和token规范——组件、token和图标的唯一真实来源。这是渲染工具在生成设计时读取的内容。内容策略——声音和语气规则、按UI元素的文案模式、产品词汇。动效规范——时间曲线、持续时间、过渡模式、微交互规范。领域参考技能保存产品特定知识限定在特定垂直领域。例如如果你正在为特定产品领域设计领域技能可能编码该产品特定的UX模式、信息架构、交互流程和微文案指南。我发现最重要的区别组件/token规范技能和设计原则技能扮演互补角色。一个知道什么是正确的规范、token、组件。另一个知道为什么某事是对的或错的哲学、评估、判断。一个执行一个评估。询问规范“使用哪个组件”“token应用正确吗”——任何有明确正确答案的事情。询问原则“这是上下文中正确的组件吗”“这个设计尊重用户需求吗”“视觉层次有效吗”“这在移动设备上有效吗”“流程逻辑吗”——任何需要判断的事情。4.2 层2能力技能工作流能力技能运行工作流——它们编排工具和参考技能以完成设计任务。每个加载它需要的参考技能并调用所需的工具。以下是我构建的能力技能类型独立无依赖read-filter-prd从PRD提取UI/UX需求。create-design-ticket从需求结构化Jira设计工单。define-flow映射用户流和交互状态。research进行设计前基准测试和证据收集。sell-design-vision帮助推销设计项目和报告影响。依赖参考技能identify-ux-problems审计现有设计加载原则可选规范。generate-design创建静态高保真Figma框架加载原则、规范、内容策略。generate-prototype创建交互式动画原型加载动效、规范、原则。依赖参考技能Figma MCPdesign-review对实时设计进行启发式评估加载原则、规范连接到Figma。qa-signoff进行视觉QA比较实现与Figma源文件加载规范连接到Figma。4.3 层3工具和连接器这些是提供外部集成的MCP服务器——Figma的REST API用于截图和元数据、用于推送设计的渲染插件、用于节点级编辑的TalkToFigma以及你使用的任何项目管理集成。5、典型管道流程这个架构的力量在于技能组合成管道PRD驱动read-filter-prd → create-design-ticket → define-flow → generate-design → design-review → qa-signoff设计发起identify-ux-problems → research → sell-design-vision → define-flow → generate-design快速生成你已经知道你想要什么直接向渲染工具描述屏幕——CLAUDE.md确保自动引用原则。设计审查粘贴Figma链接或截图Claude根据你的设计原则批评并推送注释。6、从哪里开始这篇文章有很多概念——层次、管道、两个环境。重点是你不需要在第一天就构建所有东西。架构是目的地。你可以一步一步走到那里。如果我今天从零开始我会按这个顺序做第1周安装Claude Code。连接Figma MCP。创建一个技能——只有一个——描述你的设计原则。这里是消除最可怕障碍的部分你不需要从头写SKILL.md文件。只需告诉Claude帮我创建一个描述我们设计原则的技能然后开始交谈。粘贴你的设计指南文档解释什么是重要的Claude会为你起草技能文件。你审查、调整、完成。然后粘贴截图并要求Claude根据这些原则审查它。你会立即感受到通用AI反馈和真正理解你系统的反馈之间的区别。那个时刻让你上瘾。第2周添加组件/token规范技能。尝试生成一个简单框架。当Claude第一次推送一个真实的、可编辑的Figma框架使用你实际的设计系统组件——不是图像不是线框图而是你可以检查和修改的框架——你会明白为什么这个设置值得最初的摩擦。第3周及以后构建你的第一个能力技能。从设计审查开始——它是最高价值、最低风险的工作流。然后生成。然后原型制作。每个都建立在你已经编写的参考技能之上。分层架构——参考知识、能力工作流和工具连接器——是让整个东西长期可维护的原因。当我更新设计原则或添加新组件规范时依赖它的每个工作流自动获得更新。没有重复没有偏差。这就是早期组织的回报。一个月前我是一个自学校以来就没打开过终端的设计师。现在我有一个AI设计伙伴它比团队中大多数人更了解我的设计系统。这一切发生在大约四周内。我的设置完美吗可能不。其中一些在几个月内会过时吗也许。但差距从来不在于拥有完美的工具链——而在于拥有任何有组织的起点。原文链接设计师的Claude Code指南 - 汇智网
