> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 设计师的Claude Code指南 - URL: https://www.hubwiz.com/blog/a-designer-s-guide-to-claude-code/ - Published: 2026-03-30T15:04:26.000Z - Updated: 2026-03-30T15:04:26.000Z - Description: 如何将技能、工具和环境组织成可扩展的AI设计工作流程。 - Author: admin - Tags: TOOL, CLAUDE CODE, #Import 2026-10-14 14:41 *每个人都在谈论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](https://medium.com/design-bootcamp/a-designers-guide-to-organizing-ai-skills-and-tools-in-claude-code-f87477c35b82?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处