设计师的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 MCP： design-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设计伙伴，它比团队中大多数人更了解我的设计系统。这一切发生在大约四周内。我的设置完美吗？可能不。其中一些在几个月内会过时吗？也许。但差距从来不在于拥有完美的工具链——而在于拥有任何有组织的起点。
原文链接: A Designer's Guide to Claude Code
汇智网翻译整理，转载请标明出处