在 AI 辅助前端开发越来越普遍的今天真正拉开产品体验差距的往往不是模型能生成多少代码而是开发者如何使用提示词、如何组织设计系统、如何把界面组件从“能用”推进到“好看且一致”。Claude 作为当前常见的 AI 编程助手并不缺少生成 HTML、CSS、Tailwind 组件的能力缺少的是使用者对设计体系的拆解能力。这篇博客会围绕“用 Claude 构建设计良好的网站”这条主线从设计意识、环境准备、提示词策略、组件生成、验证优化、常见失败模式和工程化落地几个层面展开目标是让读者在读完以后能用一套可复现的方法借助 Claude 生成层次清晰、视觉稳定、交互合理的页面而不是简单的“让 AI 帮我画一个网页”。1. 先建立设计判断力再谈 Claude 生成能力1.1 为什么设计不良的 AI 页面总有一股“模板味”很多开发者让 Claude 生成页面时习惯直接说“帮我做一个漂亮的落地页”Claude 也确实会输出一个结构完整的页面。但结果经常是大圆角、强烈渐变、多个卡片堆叠、居中的大标题、略显空洞的图标区域。页面看起来不算丑但也没有设计感放在真实产品里会让人觉得“这是 AI 写的”。问题不在 Claude而在于提示词里缺少设计约束。Claude 在缺乏明确设计语言时会倾向于输出它在大规模数据中见过最多的“通用漂亮网页”样式。这种样式适合演示不适合真实产品。真正有效的做法是在让 Claude 写代码之前先自己定义好设计规则再把这些规则作为约束交给 Claude。这里需要区分一个关键概念设计感不是“装饰多”而是“秩序和一致性”。字体层级、间距体系、颜色语义、圆角大小、阴影轻重、内容密度这些视觉变量只要稳定统一页面就会显得专业。反过来哪怕每个组件单独看都不错变量一旦互相冲突整体就会显得杂乱。1.2 Claude 适合承担什么设计任务Claude 适合承担的设计任务是“在约束清晰的情况下用代码实现视觉方案”。它擅长的事情包括把一份设计 token 转成可复用的 Tailwind 类或 CSS 变量。根据语义拆分 React、Vue 组件。将口头描述的功能区块转化为页面结构。在已有组件库基础上补全缺失状态例如加载态、空态、错误态。将模糊的页面需求拆成一版可评审的 HTML 原型。Claude 不适合承担的任务是代替产品经理和设计师完成方向性决策。如果开发者自己都不清楚目标用户是谁、页面重点是什么、视觉基调是专业还是活泼Claude 不可能替用户回答这些问题。它只能给出一个平均答案。所以本文第一条建议是把 Claude 当作一位“执行力极强的初级前端”而不是“设计总监”。所有设计决策都应该在开发者这一侧完成Claude 负责把这些决策翻译成代码。1.3 一个可复用的设计检查清单在开始生成页面之前先用下面这份清单做一次快速设计体检。这份清单也可以作为后续提示词的组成部分。检查项说明常见问题字体层级标题、正文、辅助文字是否有明确的字号梯度标题和正文差距过小视觉没有重心间距体系是否使用 4 的倍数作为间距基准间距随意卡片内外边距不一致颜色语义主色、辅助色、成功、警告、错误是否明确全页面颜色过多或者全部依赖默认色圆角风格大圆角、中圆角、小圆角是否有固定规则每个卡片圆角不同风格割裂阴影层级普通卡片、悬浮卡片、弹窗阴影是否分层所有元素阴影一样重层次感弱内容密度移动端和桌面端的信息密度是否分别处理只做桌面布局移动端直接挤压空状态无数据、加载中、出错时页面长什么样只画了正常态其他状态完全没考虑如果这七个方面在项目开始时就有明确答案Claude 生成出来的页面基本不会跑偏。接下来的核心问题就是如何把这份设计规则转化为 Claude 可执行的构建上下文。2. 环境准备把 Claude Code 接入本地项目2.1 选择适合自己的 Claude 使用方式Claude 的使用方式很多可以按场景分成三类。第一类是网页版。适合快速验证设计想法、生成单页 HTML、写一段样式代码。优点是零配置缺点是上下文很难与本地项目结构打通也不太适合反复迭代一个完整项目。第二类是 API 接入。开发者可以通过 Claude API 将模型能力集成到自建工具、脚本或 CI 流程中。优点是可控性强缺点是如果要调试网页效果依然需要自己处理代码落地和浏览器预览。第三类是 Claude Code。这是安装在本地终端中的命令行编程工具它能够读取项目目录、修改文件、执行命令并在一个会话中持续维护项目上下文。对于“完整地构建网站”这个目标Claude Code 是最合适的选择因为它不是生成一段代码让你复制而是直接参与工程项目的构建过程。本文后续步骤以 Claude Code 为主因为设计一个网站不只是一次生成而是多次修改、查看、调整的迭代过程。终端工具更贴近这种工作流。2.2 安装 Claude Code 的完整过程安装 Claude Code 之前先确认本机环境满足基本要求Node.js 版本建议使用 18 以上的 LTS 版本Claude Code 依赖 Node 运行时。终端环境能正常执行 npm 或 npx 命令。需要一个可用的 Claude 账号并确认已获得 Claude Code 的访问权限。安装命令如下npm install -g anthropic-ai/claude-code安装完成后先验证命令是否可用claude --version如果终端提示“claude 不是内部或外部命令”说明全局安装路径没有加入系统 PATH。此时可以检查 npm 全局安装目录再把它添加到 PATH或者使用 npx 方式运行npx anthropic-ai/claude-code本地安装完成并确认命令可用后在需要构建网站的项目目录中启动cd your-project claude首次启动时Claude Code 会引导完成登录与项目授权。授权完成后它会获得读取项目文件和在项目内执行命令的权限。这里要注意权限边界在生产环境或包含敏感信息的仓库中不要随意授权 Claude Code 执行全局命令建议先限制为只读审查它提出的文件修改方案后再执行。2.3 VSCode 集成方式在 VSCode 中使用 Claude Code 有两种常见路径。第一种是直接在 VSCode 内置终端中使用命令行工具。这种方式最简单项目上下文、终端输出和编辑器都在同一界面内适合大多数开发者。第二种是安装社区提供的 Claude Code 扩展将对话面板嵌入编辑器侧边栏。扩展的体验更接近聊天式编程但在部分工作区配置下权限控制不如命令行直观。如果从稳定性出发优先选终端方式扩展只作为辅助。一个实用的项目启动配置是先把项目根目录在 VSCode 中打开再新建终端窗口执行 claude这样 Claude Code 能直接看到整个项目结构后续修改组件、引入依赖时不需要额外提供路径信息。注意Claude Code 安装和登录属于本地开发工具配置。不同版本的安装命令、权限提示和模型名称可能不同如果看到“模型无法识别”之类的提示先确认当前 Claude Code 版本支持的模型列表再决定是否升级。3. 用设计上下文文件约束 Claude 的视觉输出3.1 在项目里建立 design.md 设计上下文很多开发者低估了上下文文件的作用。让 Claude 生成网站时如果每次对话都重新描述一遍设计偏好一方面容易遗漏信息另一方面 Claude 在不同轮次之间可能产生不一致。更好的做法是在项目根目录建立一个设计上下文文件例如design.md把设计规则固化下来。这个文件的用途是每次与 Claude 对话时让它先读取并遵守该文件再开始生成或修改代码。这样即使用户中途切换任务从“首页”切换到“关于页”设计风格也能保持一致。一个最小可用的design.md可以包含以下内容# 网站设计上下文 ## 目标 - 面向小型 SaaS 产品官网风格专业、清晰。 - 目标用户是企业内部工具使用者不接受过于花哨的表现形式。 ## 字体 - 标题字体Inter字重 700。 - 正文字体Inter字重 400。 - 标题字号40px / 32px / 24px / 18px 四级。 - 正文字号16px辅助文字 14px微标签 12px。 ## 颜色 - 主色#2563EB。 - 背景色#FFFFFF次级背景#F8FAFC。 - 文字色#0F172A辅助文字#64748B。 - 成功#16A34A警告#D97706错误#DC2626。 ## 间距 - 基准间距 4px所有间距使用 4 的倍数。 - 区块内边距24px 或 32px。 - 区块间距64px。 ## 圆角与阴影 - 按钮8px 圆角。 - 卡片12px 圆角。 - 弹窗16px 圆角。 - 阴影分为三层普通、悬浮、弹窗。 ## 组件规范 - 所有按钮必须有明确的 hover 和 disabled 状态。 - 所有链接必须有 underline 或颜色变化。 - 表单输入框必须包含 label、placeholder、错误提示。 - 图片必须有 alt 文本。 - 空数据时必须显示空状态提示不能是白屏。这份文件不需要很长但必须具体。最忌讳的是“风格现代、色彩柔和”这类无法量化的描述。Claude 能理解的不是感觉而是数值和关系。3.2 用 CLAUDE.md 或项目说明让 Claude 自动读取设计约束Claude Code 支持读取项目根目录中的CLAUDE.md文件把它作为项目的长期记忆。可以把设计上下文放在这个文件中也可以在CLAUDE.md里写一句话要求 Claude 先读取design.md# 项目说明 在生成或修改任何页面、组件、样式之前必须先读取并遵守根目录下的 design.md。 如果设计需求与 design.md 冲突向用户说明冲突点并等待用户确认后再执行。 输出代码时优先使用项目内已有组件不要重复造轮子。这样做的价值在于设计约束不再是临时提示词而是项目的持久规则。团队协作时其他成员也能通过CLAUDE.md和design.md理解这个项目对 AI 的使用规范。3.3 在提示词中显式引用设计上下文即使建立了设计上下文文件也不能在对话里直接说“按照设计规范做”。Claude Code 的上下文是否自动加载取决于配置方式。为了稳定起见第一轮对话建议显式说明请先读取根目录下的 design.md然后根据里面的设计上下文为这个项目生成一个首页。首页需要包含产品介绍、功能特性、使用流程、FAQ 和底部导航。这种写法有两个优点第一Claude 明确知道自己要遵守什么第二用户把页面区块也预先定义清楚了Claude 不需要自己猜测页面应该包含哪些内容。4. 从零生成一个设计良好的电商风格官网4.1 场景设定与页面结构拆分下面用一个具体案例演示完整流程。假设要构建一个面向独立设计师的作品集与数字产品售卖站点风格偏简洁、温暖视觉重点在作品展示和购买转化。在生成代码之前先把页面拆成模块顶部导航Logo、导航菜单、购物车入口、移动端菜单按钮。Hero 区域主标题、副标题、主按钮、代表性作品图。信任条客户数量、作品数量、平均评分。精选作品区卡片式展示包含分类筛选。产品服务说明三个核心卖点。用户评价横向卡片。购买流程四步说明。FAQ折叠面板。页脚社交链接、订阅框、版权信息。模块拆得越细Claude 生成时越不会遗漏关键内容。页面是否好看很大程度上取决于结构是否完整而不是某个组件是否炫酷。4.2 第一轮生成本体页面在 Claude Code 项目中如果还没有前端工程先让 Claude 初始化一个简单项目。这里选择原生 HTML Tailwind CDN 作为演示因为最容易快速预览不依赖 Node 构建链路。请使用原生 HTML Tailwind CDN在项目根目录创建一个 index.html实现一个独立设计师作品集与数字产品售卖官网首页。页面必须包含顶部导航、Hero 区域、信任条、精选作品区、服务说明、用户评价、购买流程、FAQ、页脚。整体风格严格遵循 design.md。Tailwind CDN 版本可以通过 link 标签引入适合原型验证。实际生产项目建议使用 Tailwind 的构建链路否则无法进行类名内容提取和体积优化。4.3 检查 Claude 输出并追问设计细节Claude 第一次生成的页面通常可以作为骨架但不一定达到“设计良好”。常见问题是模块间距一致但视觉层级不够颜色没有越界但页面缺少重点组件齐全但交互细节缺失。第一轮生成后不要急着继续堆功能先问自己三个问题页面哪个区块第一眼最吸引人它是不是我希望用户最先关注的内容有没有某个区块看起来与整体风格不一致移动端宽度下布局是否仍然可读然后把这些发现反馈给 Claude。比如页面整体方向可以但存在三个问题 1. Hero 区标题不够突出标题字号和正文字号差距太小。 2. 作品卡片的信息密度偏高每张卡片文字太多建议只保留作品名、价格和一句简短描述。 3. FAQ 的折叠交互在移动端容易误触建议加大点击区域并增加过渡动画。这种反馈方式的核心是“具体到可修改”而不是说“感觉不太好看”。Claude 没有审美直觉但可以执行具体的样式调整指令。4.4 逐步完善细节状态设计良好的网站不只是静态页面好看还要考虑交互反馈和异常状态。可以让 Claude 为关键组件补充状态请检查页面中的所有按钮补充 hover、focus、active 和 disabled 状态。 为精选作品区增加一个加载中的骨架屏样式。 为 FAQ 增加展开和收起动画。 为移动端菜单增加一个简单的显示隐藏交互。这些细节是区分“AI 原型”和“可上线页面”的关键。骨架屏、焦点样式、空状态、加载状态这些在视觉稿里不明显但真实用户一定会遇到。5. 深入理解 Claude 的构建能力边界5.1 组件级生成 vs 页面级生成在真实项目中建议以组件为单位让 Claude 工作而不是整页重写。页面级生成适合原型验证组件级生成适合工程落地。组件级生成的优势是可控性更强。比如只对 Claude 说在 components/ProductCard.jsx 中新建一个产品卡片组件。要求 - 接收 title、price、coverUrl、tags 四个 props。 - 卡片包含封面图、标题、价格、标签。 - 点击时触发 onSelect 回调。 - 视觉遵循 design.md。这比“帮我写一个产品列表页”更精准。因为组件边界清晰、props 明确、样式约束单一Claude 出错概率低后续也容易单独调整。5.2 Claude 在处理依赖和构建脚本时的常见问题Claude Code 可以执行命令也能读取构建日志。但要清楚它不是一个包管理器不一定理解每一个构建工具的特殊行为。常见问题集中在下面这些场景现象可能原因处理建议pnpm install 阶段有依赖的 postinstall 脚本被忽略pnpm 默认阻止依赖执行构建脚本检查 pnpm approval在 onlyBuiltDependencies 中添加被忽略的包npm run build 报找不到某个模块依赖未完整安装或本地 Node 版本不兼容删除 node_modules 和 lockfile 后重装或切换 Node 版本Claude 修改文件后页面样式未更新本地开发服务器热更新失败或缓存问题重启 dev server清除浏览器缓存后再看效果页面构建成功但样式缺失Tailwind 类名未进入构建产物确认使用了正确的 Tailwind 内容扫描配置并检查页面类名是否拼写正确这里要补充一个常见场景pnpm run build产出的静态文件需要部署到 Nginx 时很多人不知道如何配置。对于单页应用Nginx 需要将未命中的路由重定向到 index.html对于纯静态站点只需把构建产物目录映射到站点根路径即可。Claude 可以帮你生成这份 Nginx 配置但你必须能看懂它否则部署后路由刷新 404 时会无从下手。server { listen 80; server_name example.com; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } }5.3 学习环境、开发环境与生产环境的差异使用 Claude 构建设计时要明确区分三种环境。学习环境的目标是快速看到页面效果。此时可以直接使用 CDN、单 HTML 文件、内存数据模拟不需要考虑工程化。目的是验证设计方向。开发环境的目标是稳定迭代。此时需要引入组件化、状态管理、路由、接口请求。Claude 的输出需要纳入代码审查重点检查 props 命名、组件边界、样式是否与设计系统一致。生产环境的目标是可维护和可监控。此时还需要考虑错误边界、埋点、性能优化、资源压缩、无响应状态、可访问性、文案校对、数据容错。Claude 生成的代码只是起点真实上线前还需要人工做一次完整走查。6. 设计提示词的进阶策略6.1 用“角色扮演”提升输出的设计一致性Claude 输出风格可以通过角色设定来稳定。不要在每轮都改变角色而是固定一个适合项目的身份。比如你是一位有 10 年经验的产品设计师兼前端工程师。你的工作方式不是先写代码而是先描述设计思路等用户确认后再输出实现。这个设定会把 Claude 从“直接写码机器”切换成“先思考再编码”的模式。对设计类任务来说这一步很有价值因为可以减少无效输出。另一种角色设定更适合品牌感强的页面你是一位专注于极简主义视觉设计的艺术总监擅长通过留白、字体对比和克制配色传递高级感。你的每一个设计决策都必须有理由。但这种设定不要滥用。如果每次任务都使用强风格角色产品整体会倾向“设计感优先”可能牺牲信息清晰度。6.2 用“先方案后代码”控制生成节奏设计类任务最怕 Claude 一次性输出大量代码然后用户发现方向不对浪费一整轮上下文。更好的节奏是让 Claude 先输出方案再确认再编码。不要直接写代码。请先浏览 design.md然后列出这个页面的设计方案包括 - 视觉层级怎么安排。 - 配色如何运用。 - 区块顺序与内容优先级。 - 每个区块大致使用什么组件形态。 等我确认后再开始生成 HTML。这种“先方案后代码”的方式有两个作用一是强迫用户思考设计目标而不是盲目生成二是在 Claude 输出完整代码前发现方向偏差避免大量返工。6.3 用“负面约束”告知 Claude 不该做什么正面描述指令之外加入负面约束能显著提升输出质量。Claude 在没有约束时可能输出太多装饰负面约束可以把它拉回来。在实现页面时遵守以下约束 - 不要使用渐变背景除非明确要求。 - 不要使用外发光阴影。 - 不要使用超过三种颜色的强调色。 - 不要添加动画除非是交互反馈。 - 不要使用夸张的衬线字体搭配。 - 不要让卡片悬浮阴影过大。负面约束越具体Claude 越不容易走偏。但也要注意负面约束不能与设计目标冲突否则会约束到页面失去活力。6.4 通过“对比与参考”提升审美质量Claude 无法像人一样看图但可以从文本中理解设计参考。在提示词中可以这样描述参考 linear.app 的简洁科技感参考 Stripe 的柔和渐变和精致阴影参考 Apple 官网的大留白和清晰字体层级。 注意不要照搬这些网站的代码只提取设计感觉并转化为符合 design.md 的项目页面。这种描述能帮助 Claude 找准“设计感觉”但不要指望它精确复刻某家公司的设计系统。它是一个语言模型不是网页截图工具。7. 从生成走向工程化组件化、token 与代码审查7.1 引入设计 token如果项目要长期维护样式不能散落在每个组件里。建议把颜色、字体、间距、圆角、阴影统一抽象为 token。对于 CSS 变量方案可以生成如下结构:root { --color-primary: #2563EB; --color-background: #FFFFFF; --color-background-secondary: #F8FAFC; --color-text: #0F172A; --color-text-secondary: #64748B; --color-success: #16A34A; --color-warning: #D97706; --color-error: #DC2626; --font-family-sans: Inter, sans-serif; --font-size-title-xl: 40px; --font-size-title-lg: 32px; --font-size-title-md: 24px; --font-size-title-sm: 18px; --font-size-body: 16px; --font-size-caption: 14px; --font-size-micro: 12px; --space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px; --space-6: 24px; --space-8: 32px; --space-16: 64px; --radius-button: 8px; --radius-card: 12px; --radius-modal: 16px; --shadow-default: 0 1px 2px rgba(15, 23, 42, 0.06); --shadow-hover: 0 4px 12px rgba(15, 23, 42, 0.1); --shadow-modal: 0 12px 32px rgba(15, 23, 42, 0.18); }设计 token 的价值在于当品牌色调整或字体调整时不需要搜索所有组件只需要修改 token 文件。Claude 在处理这类重复替换时非常擅长可以让它批量梳理并替换。7.2 把页面拆成组件并生成组件树如果使用 React 或 Vue建议在 Claude 生成页面后再要求它把页面拆成组件树。拆分规则包括每个区块对应一个目录或文件。组件之间通过 props 传递数据不要在组件内部写死业务数据。样式文件的命名与组件名一一对应。公共组件放到 components/common 或 components/ui 目录。请把 index.html 中的内容拆分为 React 组件目录结构如下 src/components/layout/Header.jsx src/components/layout/Footer.jsx src/components/home/Hero.jsx src/components/home/TrustBar.jsx src/components/home/ProductShowcase.jsx src/components/home/ServiceIntro.jsx src/components/home/Testimonials.jsx src/components/home/PurchaseSteps.jsx src/components/home/FAQ.jsx拆分完成后页面与数据流的边界会清晰很多。此时再做状态管理、接口接入、权限控制都会比单文件容易。7.3 代码审查不要交给 Claude 自己完成Claude 可以生成代码但最终审查要由开发者完成。审查重点包括审查项检查内容常见问题props 边界组件是否依赖外部传入数据而不是写死业务值组件内部硬编码了推荐商品列表可访问性img 是否有 alt按钮是否有键盘可操作性表单 label 是否绑定控件图片无替代文本按钮无 focus 样式响应式页面在 375px、768px、1280px 宽度下是否表现正常移动端横向溢出或字体过大挤压布局性能是否加载了不必要的图片、字体、脚本使用 CDN 方式引入了整库资源未做按需加载语义化是否使用合理的 HTML 标签大量 div 替换了 header、main、section、footer安全是否存在 dangerouslySetInnerHTML 或 innerHTML 注入风险用户输入未转义直接渲染在实际项目中可以让 Claude 先自查一遍例如请检查当前页面代码列出所有不符合可访问性规范的地方并直接修复。但“自查”只能作为辅助。最终合并代码前需要人工走查一遍交互逻辑和样式细节。8. 常见失败模式与调试路径8.1 页面生成出来了但不符合设计预期这是最高频的问题。现象是页面功能完整、代码没有报错但视觉结果与设想差别很大。排查顺序如下确认 Claude 是否读取了design.md。如果没有先让 Claude 读取再重新生成。检查提示词是否只写了“好看”而没写具体约束。好看不可执行具体数值才可执行。检查是否存在互相冲突的约束例如“简约风格”和“大量渐变装饰”同时出现。检查实际浏览器渲染结果是否有 CSS 没有被正确加载。如果是 Tailwind CDN 模式网络加载失败会导致页面完全无样式。打开浏览器开发者工具检查 Tailwind 脚本是否加载成功这是最常见的一步。8.2 Claude Code 无法识别模型或提示当前版本不支持这类提示通常出现在 Claude Code 升级后或者本地配置了模型名称但模型名在当前版本中已失效。处理方式是先升级到最新版本然后查看当前支持的模型列表不要使用网络教程中已经很古老的模型名。npm update -g anthropic-ai/claude-code claude --version如果升级后依然提示模型无法识别检查是否有历史配置文件残留例如.claude配置目录中指定了旧模型。删除配置或修正模型名后重试。8.3 页面在本地预览正常构建后样式丢失这类问题大多与 Tailwind 的类名提取有关。Tailwind 构建时会扫描指定目录下的文件只生成出现在文件中的类名。如果页面类名是通过字符串拼接生成的Tailwind 无法识别样式就会丢失。!-- 错误动态拼接类名Tailwind 扫描不到完整类名 -- div :classcolor-${theme}text/div !-- 正确使用完整类名或 safelist -- div :classtheme dark ? bg-gray-900 : bg-whitetext/div在 Claude Code 中调试时可以先让 Claude 查看构建产物中的 CSS 文件大小如果远小于预期大概率是扫描配置或动态类名问题。8.4 Claude 反复修改同一个地方但问题没有解决这是典型的上下文漂移现象。Claude 在长时间对话中会逐渐偏离最初的设计目标修改越来越局部忘掉最初的约束。解决办法是开启新会话把设计上下文重新加载一遍然后精确描述当前问题和希望的结果。不要继续在旧会话中无限修改。短会话、高覆盖率的迭代方式更适合 AI 辅助设计。8.5 安装或运行时的工具链问题如果安装时遇到 npm 全局包权限问题、Node 版本过低、网络不稳定导致下载失败可以按顺序尝试node -v npm -v npm uninstall -g anthropic-ai/claude-code npm install -g anthropic-ai/claude-code --registryhttps://registry.npmjs.org如果使用 pnpm 管理依赖遇到构建脚本被忽略先查看 pnpm 日志再决定是否需要为某个依赖放行构建脚本。不要一次性全部放行避免安全风险。9. 最佳实践清单与扩展方向9.1 构建网站时的 AI 协作清单每次使用 Claude 构建设计页面建议按顺序走完下面这份清单明确页面目标和目标用户。建立design.md至少覆盖字体、颜色、间距、圆角、阴影和组件状态。在CLAUDE.md中声明设计约束读取规则。把页面拆成模块逐个模块给 Claude 描述。第一轮生成时让 Claude 先出方案确认后再写代码。要求 Claude 为所有交互元素补充 hover、focus、active、disabled 状态。检查移动端、平板、桌面三种宽度下的布局表现。对表单、图片、按钮做可访问性审查。将页面拆分为组件传入数据使用 props不写死。将视觉变量提取为 token。在真实浏览器中预览截图确认视觉效果。构建产物验证并处理路由、静态资源和部署问题。上线前安排人工走查确认用户路径完整。9.2 将 Claude 能力平滑扩展到多页面项目完成首页后可以把同样的设计上下文应用到其他页面。此时建议不要再单独描述视觉风格而是明确说基于首页已经使用的组件和 design.md为项目生成一个列表页。列表页包含筛选栏、搜索结果、空状态和分页。 请复用已有的 Header、Footer 组件不要重新创建布局组件。这样做可以让 Claude 以首页为基准保持项目内的一致性。如果多轮生成后出现风格漂移回到首页对应的组件文件让 Claude 对比差异并统一。9.3 真实项目中的取舍建议AI 辅助设计目前更适合以下场景快速验证产品概念和页面结构。建立设计原型供团队讨论。生成组件库的初始版本。将设计稿中的想法快速转化为代码。AI 辅助设计尚不适合的场景需要深入品牌策略的视觉设计。需要精确到像素级实现交互的复杂动效。需要严格遵循大型设计系统规范的组件库建设。在这些场景中Claude 可以作为辅助工具加快开发但最终设计决策应该由具备设计能力的开发者或设计师完成。换句话说AI 提升了从“想法”到“页面”的执行效率但没有替代设计思考本身。9.4 下一步练习建议如果希望真正掌握“用 Claude 构建设计良好的网站”建议按下面三个层次练习。第一个层次用同一个设计上下文让 Claude 生成三种不同类型的页面例如官网首页、后台列表页、移动端活动页。通过对比发现哪些约束是通用的哪些约束需要按页面类型调整。第二个层次给 Claude 一个残缺设计系统例如只有主色和字体要求它根据自己的判断补齐间距、圆角、阴影规则。然后对比它补全的规则是否合理并尝试解释其选型原因。第三个层次把一个已经上线的网站页面交给 Claude让它按照新的设计上下文重构。这个练习最接近真实项目中的改版场景也最能检验开发者对设计约束的理解是否足够清晰。技术能力会随着工具更新而变化但“先明确设计规则再让 AI 执行”的工作流会在 Claude 之后的其他 AI 工具中继续复用。这才是这篇博客真正想传递的核心方法。
用Claude构建设计良好的网站：设计上下文与提示词策略
在 AI 辅助前端开发越来越普遍的今天真正拉开产品体验差距的往往不是模型能生成多少代码而是开发者如何使用提示词、如何组织设计系统、如何把界面组件从“能用”推进到“好看且一致”。Claude 作为当前常见的 AI 编程助手并不缺少生成 HTML、CSS、Tailwind 组件的能力缺少的是使用者对设计体系的拆解能力。这篇博客会围绕“用 Claude 构建设计良好的网站”这条主线从设计意识、环境准备、提示词策略、组件生成、验证优化、常见失败模式和工程化落地几个层面展开目标是让读者在读完以后能用一套可复现的方法借助 Claude 生成层次清晰、视觉稳定、交互合理的页面而不是简单的“让 AI 帮我画一个网页”。1. 先建立设计判断力再谈 Claude 生成能力1.1 为什么设计不良的 AI 页面总有一股“模板味”很多开发者让 Claude 生成页面时习惯直接说“帮我做一个漂亮的落地页”Claude 也确实会输出一个结构完整的页面。但结果经常是大圆角、强烈渐变、多个卡片堆叠、居中的大标题、略显空洞的图标区域。页面看起来不算丑但也没有设计感放在真实产品里会让人觉得“这是 AI 写的”。问题不在 Claude而在于提示词里缺少设计约束。Claude 在缺乏明确设计语言时会倾向于输出它在大规模数据中见过最多的“通用漂亮网页”样式。这种样式适合演示不适合真实产品。真正有效的做法是在让 Claude 写代码之前先自己定义好设计规则再把这些规则作为约束交给 Claude。这里需要区分一个关键概念设计感不是“装饰多”而是“秩序和一致性”。字体层级、间距体系、颜色语义、圆角大小、阴影轻重、内容密度这些视觉变量只要稳定统一页面就会显得专业。反过来哪怕每个组件单独看都不错变量一旦互相冲突整体就会显得杂乱。1.2 Claude 适合承担什么设计任务Claude 适合承担的设计任务是“在约束清晰的情况下用代码实现视觉方案”。它擅长的事情包括把一份设计 token 转成可复用的 Tailwind 类或 CSS 变量。根据语义拆分 React、Vue 组件。将口头描述的功能区块转化为页面结构。在已有组件库基础上补全缺失状态例如加载态、空态、错误态。将模糊的页面需求拆成一版可评审的 HTML 原型。Claude 不适合承担的任务是代替产品经理和设计师完成方向性决策。如果开发者自己都不清楚目标用户是谁、页面重点是什么、视觉基调是专业还是活泼Claude 不可能替用户回答这些问题。它只能给出一个平均答案。所以本文第一条建议是把 Claude 当作一位“执行力极强的初级前端”而不是“设计总监”。所有设计决策都应该在开发者这一侧完成Claude 负责把这些决策翻译成代码。1.3 一个可复用的设计检查清单在开始生成页面之前先用下面这份清单做一次快速设计体检。这份清单也可以作为后续提示词的组成部分。检查项说明常见问题字体层级标题、正文、辅助文字是否有明确的字号梯度标题和正文差距过小视觉没有重心间距体系是否使用 4 的倍数作为间距基准间距随意卡片内外边距不一致颜色语义主色、辅助色、成功、警告、错误是否明确全页面颜色过多或者全部依赖默认色圆角风格大圆角、中圆角、小圆角是否有固定规则每个卡片圆角不同风格割裂阴影层级普通卡片、悬浮卡片、弹窗阴影是否分层所有元素阴影一样重层次感弱内容密度移动端和桌面端的信息密度是否分别处理只做桌面布局移动端直接挤压空状态无数据、加载中、出错时页面长什么样只画了正常态其他状态完全没考虑如果这七个方面在项目开始时就有明确答案Claude 生成出来的页面基本不会跑偏。接下来的核心问题就是如何把这份设计规则转化为 Claude 可执行的构建上下文。2. 环境准备把 Claude Code 接入本地项目2.1 选择适合自己的 Claude 使用方式Claude 的使用方式很多可以按场景分成三类。第一类是网页版。适合快速验证设计想法、生成单页 HTML、写一段样式代码。优点是零配置缺点是上下文很难与本地项目结构打通也不太适合反复迭代一个完整项目。第二类是 API 接入。开发者可以通过 Claude API 将模型能力集成到自建工具、脚本或 CI 流程中。优点是可控性强缺点是如果要调试网页效果依然需要自己处理代码落地和浏览器预览。第三类是 Claude Code。这是安装在本地终端中的命令行编程工具它能够读取项目目录、修改文件、执行命令并在一个会话中持续维护项目上下文。对于“完整地构建网站”这个目标Claude Code 是最合适的选择因为它不是生成一段代码让你复制而是直接参与工程项目的构建过程。本文后续步骤以 Claude Code 为主因为设计一个网站不只是一次生成而是多次修改、查看、调整的迭代过程。终端工具更贴近这种工作流。2.2 安装 Claude Code 的完整过程安装 Claude Code 之前先确认本机环境满足基本要求Node.js 版本建议使用 18 以上的 LTS 版本Claude Code 依赖 Node 运行时。终端环境能正常执行 npm 或 npx 命令。需要一个可用的 Claude 账号并确认已获得 Claude Code 的访问权限。安装命令如下npm install -g anthropic-ai/claude-code安装完成后先验证命令是否可用claude --version如果终端提示“claude 不是内部或外部命令”说明全局安装路径没有加入系统 PATH。此时可以检查 npm 全局安装目录再把它添加到 PATH或者使用 npx 方式运行npx anthropic-ai/claude-code本地安装完成并确认命令可用后在需要构建网站的项目目录中启动cd your-project claude首次启动时Claude Code 会引导完成登录与项目授权。授权完成后它会获得读取项目文件和在项目内执行命令的权限。这里要注意权限边界在生产环境或包含敏感信息的仓库中不要随意授权 Claude Code 执行全局命令建议先限制为只读审查它提出的文件修改方案后再执行。2.3 VSCode 集成方式在 VSCode 中使用 Claude Code 有两种常见路径。第一种是直接在 VSCode 内置终端中使用命令行工具。这种方式最简单项目上下文、终端输出和编辑器都在同一界面内适合大多数开发者。第二种是安装社区提供的 Claude Code 扩展将对话面板嵌入编辑器侧边栏。扩展的体验更接近聊天式编程但在部分工作区配置下权限控制不如命令行直观。如果从稳定性出发优先选终端方式扩展只作为辅助。一个实用的项目启动配置是先把项目根目录在 VSCode 中打开再新建终端窗口执行 claude这样 Claude Code 能直接看到整个项目结构后续修改组件、引入依赖时不需要额外提供路径信息。注意Claude Code 安装和登录属于本地开发工具配置。不同版本的安装命令、权限提示和模型名称可能不同如果看到“模型无法识别”之类的提示先确认当前 Claude Code 版本支持的模型列表再决定是否升级。3. 用设计上下文文件约束 Claude 的视觉输出3.1 在项目里建立 design.md 设计上下文很多开发者低估了上下文文件的作用。让 Claude 生成网站时如果每次对话都重新描述一遍设计偏好一方面容易遗漏信息另一方面 Claude 在不同轮次之间可能产生不一致。更好的做法是在项目根目录建立一个设计上下文文件例如design.md把设计规则固化下来。这个文件的用途是每次与 Claude 对话时让它先读取并遵守该文件再开始生成或修改代码。这样即使用户中途切换任务从“首页”切换到“关于页”设计风格也能保持一致。一个最小可用的design.md可以包含以下内容# 网站设计上下文 ## 目标 - 面向小型 SaaS 产品官网风格专业、清晰。 - 目标用户是企业内部工具使用者不接受过于花哨的表现形式。 ## 字体 - 标题字体Inter字重 700。 - 正文字体Inter字重 400。 - 标题字号40px / 32px / 24px / 18px 四级。 - 正文字号16px辅助文字 14px微标签 12px。 ## 颜色 - 主色#2563EB。 - 背景色#FFFFFF次级背景#F8FAFC。 - 文字色#0F172A辅助文字#64748B。 - 成功#16A34A警告#D97706错误#DC2626。 ## 间距 - 基准间距 4px所有间距使用 4 的倍数。 - 区块内边距24px 或 32px。 - 区块间距64px。 ## 圆角与阴影 - 按钮8px 圆角。 - 卡片12px 圆角。 - 弹窗16px 圆角。 - 阴影分为三层普通、悬浮、弹窗。 ## 组件规范 - 所有按钮必须有明确的 hover 和 disabled 状态。 - 所有链接必须有 underline 或颜色变化。 - 表单输入框必须包含 label、placeholder、错误提示。 - 图片必须有 alt 文本。 - 空数据时必须显示空状态提示不能是白屏。这份文件不需要很长但必须具体。最忌讳的是“风格现代、色彩柔和”这类无法量化的描述。Claude 能理解的不是感觉而是数值和关系。3.2 用 CLAUDE.md 或项目说明让 Claude 自动读取设计约束Claude Code 支持读取项目根目录中的CLAUDE.md文件把它作为项目的长期记忆。可以把设计上下文放在这个文件中也可以在CLAUDE.md里写一句话要求 Claude 先读取design.md# 项目说明 在生成或修改任何页面、组件、样式之前必须先读取并遵守根目录下的 design.md。 如果设计需求与 design.md 冲突向用户说明冲突点并等待用户确认后再执行。 输出代码时优先使用项目内已有组件不要重复造轮子。这样做的价值在于设计约束不再是临时提示词而是项目的持久规则。团队协作时其他成员也能通过CLAUDE.md和design.md理解这个项目对 AI 的使用规范。3.3 在提示词中显式引用设计上下文即使建立了设计上下文文件也不能在对话里直接说“按照设计规范做”。Claude Code 的上下文是否自动加载取决于配置方式。为了稳定起见第一轮对话建议显式说明请先读取根目录下的 design.md然后根据里面的设计上下文为这个项目生成一个首页。首页需要包含产品介绍、功能特性、使用流程、FAQ 和底部导航。这种写法有两个优点第一Claude 明确知道自己要遵守什么第二用户把页面区块也预先定义清楚了Claude 不需要自己猜测页面应该包含哪些内容。4. 从零生成一个设计良好的电商风格官网4.1 场景设定与页面结构拆分下面用一个具体案例演示完整流程。假设要构建一个面向独立设计师的作品集与数字产品售卖站点风格偏简洁、温暖视觉重点在作品展示和购买转化。在生成代码之前先把页面拆成模块顶部导航Logo、导航菜单、购物车入口、移动端菜单按钮。Hero 区域主标题、副标题、主按钮、代表性作品图。信任条客户数量、作品数量、平均评分。精选作品区卡片式展示包含分类筛选。产品服务说明三个核心卖点。用户评价横向卡片。购买流程四步说明。FAQ折叠面板。页脚社交链接、订阅框、版权信息。模块拆得越细Claude 生成时越不会遗漏关键内容。页面是否好看很大程度上取决于结构是否完整而不是某个组件是否炫酷。4.2 第一轮生成本体页面在 Claude Code 项目中如果还没有前端工程先让 Claude 初始化一个简单项目。这里选择原生 HTML Tailwind CDN 作为演示因为最容易快速预览不依赖 Node 构建链路。请使用原生 HTML Tailwind CDN在项目根目录创建一个 index.html实现一个独立设计师作品集与数字产品售卖官网首页。页面必须包含顶部导航、Hero 区域、信任条、精选作品区、服务说明、用户评价、购买流程、FAQ、页脚。整体风格严格遵循 design.md。Tailwind CDN 版本可以通过 link 标签引入适合原型验证。实际生产项目建议使用 Tailwind 的构建链路否则无法进行类名内容提取和体积优化。4.3 检查 Claude 输出并追问设计细节Claude 第一次生成的页面通常可以作为骨架但不一定达到“设计良好”。常见问题是模块间距一致但视觉层级不够颜色没有越界但页面缺少重点组件齐全但交互细节缺失。第一轮生成后不要急着继续堆功能先问自己三个问题页面哪个区块第一眼最吸引人它是不是我希望用户最先关注的内容有没有某个区块看起来与整体风格不一致移动端宽度下布局是否仍然可读然后把这些发现反馈给 Claude。比如页面整体方向可以但存在三个问题 1. Hero 区标题不够突出标题字号和正文字号差距太小。 2. 作品卡片的信息密度偏高每张卡片文字太多建议只保留作品名、价格和一句简短描述。 3. FAQ 的折叠交互在移动端容易误触建议加大点击区域并增加过渡动画。这种反馈方式的核心是“具体到可修改”而不是说“感觉不太好看”。Claude 没有审美直觉但可以执行具体的样式调整指令。4.4 逐步完善细节状态设计良好的网站不只是静态页面好看还要考虑交互反馈和异常状态。可以让 Claude 为关键组件补充状态请检查页面中的所有按钮补充 hover、focus、active 和 disabled 状态。 为精选作品区增加一个加载中的骨架屏样式。 为 FAQ 增加展开和收起动画。 为移动端菜单增加一个简单的显示隐藏交互。这些细节是区分“AI 原型”和“可上线页面”的关键。骨架屏、焦点样式、空状态、加载状态这些在视觉稿里不明显但真实用户一定会遇到。5. 深入理解 Claude 的构建能力边界5.1 组件级生成 vs 页面级生成在真实项目中建议以组件为单位让 Claude 工作而不是整页重写。页面级生成适合原型验证组件级生成适合工程落地。组件级生成的优势是可控性更强。比如只对 Claude 说在 components/ProductCard.jsx 中新建一个产品卡片组件。要求 - 接收 title、price、coverUrl、tags 四个 props。 - 卡片包含封面图、标题、价格、标签。 - 点击时触发 onSelect 回调。 - 视觉遵循 design.md。这比“帮我写一个产品列表页”更精准。因为组件边界清晰、props 明确、样式约束单一Claude 出错概率低后续也容易单独调整。5.2 Claude 在处理依赖和构建脚本时的常见问题Claude Code 可以执行命令也能读取构建日志。但要清楚它不是一个包管理器不一定理解每一个构建工具的特殊行为。常见问题集中在下面这些场景现象可能原因处理建议pnpm install 阶段有依赖的 postinstall 脚本被忽略pnpm 默认阻止依赖执行构建脚本检查 pnpm approval在 onlyBuiltDependencies 中添加被忽略的包npm run build 报找不到某个模块依赖未完整安装或本地 Node 版本不兼容删除 node_modules 和 lockfile 后重装或切换 Node 版本Claude 修改文件后页面样式未更新本地开发服务器热更新失败或缓存问题重启 dev server清除浏览器缓存后再看效果页面构建成功但样式缺失Tailwind 类名未进入构建产物确认使用了正确的 Tailwind 内容扫描配置并检查页面类名是否拼写正确这里要补充一个常见场景pnpm run build产出的静态文件需要部署到 Nginx 时很多人不知道如何配置。对于单页应用Nginx 需要将未命中的路由重定向到 index.html对于纯静态站点只需把构建产物目录映射到站点根路径即可。Claude 可以帮你生成这份 Nginx 配置但你必须能看懂它否则部署后路由刷新 404 时会无从下手。server { listen 80; server_name example.com; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } }5.3 学习环境、开发环境与生产环境的差异使用 Claude 构建设计时要明确区分三种环境。学习环境的目标是快速看到页面效果。此时可以直接使用 CDN、单 HTML 文件、内存数据模拟不需要考虑工程化。目的是验证设计方向。开发环境的目标是稳定迭代。此时需要引入组件化、状态管理、路由、接口请求。Claude 的输出需要纳入代码审查重点检查 props 命名、组件边界、样式是否与设计系统一致。生产环境的目标是可维护和可监控。此时还需要考虑错误边界、埋点、性能优化、资源压缩、无响应状态、可访问性、文案校对、数据容错。Claude 生成的代码只是起点真实上线前还需要人工做一次完整走查。6. 设计提示词的进阶策略6.1 用“角色扮演”提升输出的设计一致性Claude 输出风格可以通过角色设定来稳定。不要在每轮都改变角色而是固定一个适合项目的身份。比如你是一位有 10 年经验的产品设计师兼前端工程师。你的工作方式不是先写代码而是先描述设计思路等用户确认后再输出实现。这个设定会把 Claude 从“直接写码机器”切换成“先思考再编码”的模式。对设计类任务来说这一步很有价值因为可以减少无效输出。另一种角色设定更适合品牌感强的页面你是一位专注于极简主义视觉设计的艺术总监擅长通过留白、字体对比和克制配色传递高级感。你的每一个设计决策都必须有理由。但这种设定不要滥用。如果每次任务都使用强风格角色产品整体会倾向“设计感优先”可能牺牲信息清晰度。6.2 用“先方案后代码”控制生成节奏设计类任务最怕 Claude 一次性输出大量代码然后用户发现方向不对浪费一整轮上下文。更好的节奏是让 Claude 先输出方案再确认再编码。不要直接写代码。请先浏览 design.md然后列出这个页面的设计方案包括 - 视觉层级怎么安排。 - 配色如何运用。 - 区块顺序与内容优先级。 - 每个区块大致使用什么组件形态。 等我确认后再开始生成 HTML。这种“先方案后代码”的方式有两个作用一是强迫用户思考设计目标而不是盲目生成二是在 Claude 输出完整代码前发现方向偏差避免大量返工。6.3 用“负面约束”告知 Claude 不该做什么正面描述指令之外加入负面约束能显著提升输出质量。Claude 在没有约束时可能输出太多装饰负面约束可以把它拉回来。在实现页面时遵守以下约束 - 不要使用渐变背景除非明确要求。 - 不要使用外发光阴影。 - 不要使用超过三种颜色的强调色。 - 不要添加动画除非是交互反馈。 - 不要使用夸张的衬线字体搭配。 - 不要让卡片悬浮阴影过大。负面约束越具体Claude 越不容易走偏。但也要注意负面约束不能与设计目标冲突否则会约束到页面失去活力。6.4 通过“对比与参考”提升审美质量Claude 无法像人一样看图但可以从文本中理解设计参考。在提示词中可以这样描述参考 linear.app 的简洁科技感参考 Stripe 的柔和渐变和精致阴影参考 Apple 官网的大留白和清晰字体层级。 注意不要照搬这些网站的代码只提取设计感觉并转化为符合 design.md 的项目页面。这种描述能帮助 Claude 找准“设计感觉”但不要指望它精确复刻某家公司的设计系统。它是一个语言模型不是网页截图工具。7. 从生成走向工程化组件化、token 与代码审查7.1 引入设计 token如果项目要长期维护样式不能散落在每个组件里。建议把颜色、字体、间距、圆角、阴影统一抽象为 token。对于 CSS 变量方案可以生成如下结构:root { --color-primary: #2563EB; --color-background: #FFFFFF; --color-background-secondary: #F8FAFC; --color-text: #0F172A; --color-text-secondary: #64748B; --color-success: #16A34A; --color-warning: #D97706; --color-error: #DC2626; --font-family-sans: Inter, sans-serif; --font-size-title-xl: 40px; --font-size-title-lg: 32px; --font-size-title-md: 24px; --font-size-title-sm: 18px; --font-size-body: 16px; --font-size-caption: 14px; --font-size-micro: 12px; --space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px; --space-6: 24px; --space-8: 32px; --space-16: 64px; --radius-button: 8px; --radius-card: 12px; --radius-modal: 16px; --shadow-default: 0 1px 2px rgba(15, 23, 42, 0.06); --shadow-hover: 0 4px 12px rgba(15, 23, 42, 0.1); --shadow-modal: 0 12px 32px rgba(15, 23, 42, 0.18); }设计 token 的价值在于当品牌色调整或字体调整时不需要搜索所有组件只需要修改 token 文件。Claude 在处理这类重复替换时非常擅长可以让它批量梳理并替换。7.2 把页面拆成组件并生成组件树如果使用 React 或 Vue建议在 Claude 生成页面后再要求它把页面拆成组件树。拆分规则包括每个区块对应一个目录或文件。组件之间通过 props 传递数据不要在组件内部写死业务数据。样式文件的命名与组件名一一对应。公共组件放到 components/common 或 components/ui 目录。请把 index.html 中的内容拆分为 React 组件目录结构如下 src/components/layout/Header.jsx src/components/layout/Footer.jsx src/components/home/Hero.jsx src/components/home/TrustBar.jsx src/components/home/ProductShowcase.jsx src/components/home/ServiceIntro.jsx src/components/home/Testimonials.jsx src/components/home/PurchaseSteps.jsx src/components/home/FAQ.jsx拆分完成后页面与数据流的边界会清晰很多。此时再做状态管理、接口接入、权限控制都会比单文件容易。7.3 代码审查不要交给 Claude 自己完成Claude 可以生成代码但最终审查要由开发者完成。审查重点包括审查项检查内容常见问题props 边界组件是否依赖外部传入数据而不是写死业务值组件内部硬编码了推荐商品列表可访问性img 是否有 alt按钮是否有键盘可操作性表单 label 是否绑定控件图片无替代文本按钮无 focus 样式响应式页面在 375px、768px、1280px 宽度下是否表现正常移动端横向溢出或字体过大挤压布局性能是否加载了不必要的图片、字体、脚本使用 CDN 方式引入了整库资源未做按需加载语义化是否使用合理的 HTML 标签大量 div 替换了 header、main、section、footer安全是否存在 dangerouslySetInnerHTML 或 innerHTML 注入风险用户输入未转义直接渲染在实际项目中可以让 Claude 先自查一遍例如请检查当前页面代码列出所有不符合可访问性规范的地方并直接修复。但“自查”只能作为辅助。最终合并代码前需要人工走查一遍交互逻辑和样式细节。8. 常见失败模式与调试路径8.1 页面生成出来了但不符合设计预期这是最高频的问题。现象是页面功能完整、代码没有报错但视觉结果与设想差别很大。排查顺序如下确认 Claude 是否读取了design.md。如果没有先让 Claude 读取再重新生成。检查提示词是否只写了“好看”而没写具体约束。好看不可执行具体数值才可执行。检查是否存在互相冲突的约束例如“简约风格”和“大量渐变装饰”同时出现。检查实际浏览器渲染结果是否有 CSS 没有被正确加载。如果是 Tailwind CDN 模式网络加载失败会导致页面完全无样式。打开浏览器开发者工具检查 Tailwind 脚本是否加载成功这是最常见的一步。8.2 Claude Code 无法识别模型或提示当前版本不支持这类提示通常出现在 Claude Code 升级后或者本地配置了模型名称但模型名在当前版本中已失效。处理方式是先升级到最新版本然后查看当前支持的模型列表不要使用网络教程中已经很古老的模型名。npm update -g anthropic-ai/claude-code claude --version如果升级后依然提示模型无法识别检查是否有历史配置文件残留例如.claude配置目录中指定了旧模型。删除配置或修正模型名后重试。8.3 页面在本地预览正常构建后样式丢失这类问题大多与 Tailwind 的类名提取有关。Tailwind 构建时会扫描指定目录下的文件只生成出现在文件中的类名。如果页面类名是通过字符串拼接生成的Tailwind 无法识别样式就会丢失。!-- 错误动态拼接类名Tailwind 扫描不到完整类名 -- div :classcolor-${theme}text/div !-- 正确使用完整类名或 safelist -- div :classtheme dark ? bg-gray-900 : bg-whitetext/div在 Claude Code 中调试时可以先让 Claude 查看构建产物中的 CSS 文件大小如果远小于预期大概率是扫描配置或动态类名问题。8.4 Claude 反复修改同一个地方但问题没有解决这是典型的上下文漂移现象。Claude 在长时间对话中会逐渐偏离最初的设计目标修改越来越局部忘掉最初的约束。解决办法是开启新会话把设计上下文重新加载一遍然后精确描述当前问题和希望的结果。不要继续在旧会话中无限修改。短会话、高覆盖率的迭代方式更适合 AI 辅助设计。8.5 安装或运行时的工具链问题如果安装时遇到 npm 全局包权限问题、Node 版本过低、网络不稳定导致下载失败可以按顺序尝试node -v npm -v npm uninstall -g anthropic-ai/claude-code npm install -g anthropic-ai/claude-code --registryhttps://registry.npmjs.org如果使用 pnpm 管理依赖遇到构建脚本被忽略先查看 pnpm 日志再决定是否需要为某个依赖放行构建脚本。不要一次性全部放行避免安全风险。9. 最佳实践清单与扩展方向9.1 构建网站时的 AI 协作清单每次使用 Claude 构建设计页面建议按顺序走完下面这份清单明确页面目标和目标用户。建立design.md至少覆盖字体、颜色、间距、圆角、阴影和组件状态。在CLAUDE.md中声明设计约束读取规则。把页面拆成模块逐个模块给 Claude 描述。第一轮生成时让 Claude 先出方案确认后再写代码。要求 Claude 为所有交互元素补充 hover、focus、active、disabled 状态。检查移动端、平板、桌面三种宽度下的布局表现。对表单、图片、按钮做可访问性审查。将页面拆分为组件传入数据使用 props不写死。将视觉变量提取为 token。在真实浏览器中预览截图确认视觉效果。构建产物验证并处理路由、静态资源和部署问题。上线前安排人工走查确认用户路径完整。9.2 将 Claude 能力平滑扩展到多页面项目完成首页后可以把同样的设计上下文应用到其他页面。此时建议不要再单独描述视觉风格而是明确说基于首页已经使用的组件和 design.md为项目生成一个列表页。列表页包含筛选栏、搜索结果、空状态和分页。 请复用已有的 Header、Footer 组件不要重新创建布局组件。这样做可以让 Claude 以首页为基准保持项目内的一致性。如果多轮生成后出现风格漂移回到首页对应的组件文件让 Claude 对比差异并统一。9.3 真实项目中的取舍建议AI 辅助设计目前更适合以下场景快速验证产品概念和页面结构。建立设计原型供团队讨论。生成组件库的初始版本。将设计稿中的想法快速转化为代码。AI 辅助设计尚不适合的场景需要深入品牌策略的视觉设计。需要精确到像素级实现交互的复杂动效。需要严格遵循大型设计系统规范的组件库建设。在这些场景中Claude 可以作为辅助工具加快开发但最终设计决策应该由具备设计能力的开发者或设计师完成。换句话说AI 提升了从“想法”到“页面”的执行效率但没有替代设计思考本身。9.4 下一步练习建议如果希望真正掌握“用 Claude 构建设计良好的网站”建议按下面三个层次练习。第一个层次用同一个设计上下文让 Claude 生成三种不同类型的页面例如官网首页、后台列表页、移动端活动页。通过对比发现哪些约束是通用的哪些约束需要按页面类型调整。第二个层次给 Claude 一个残缺设计系统例如只有主色和字体要求它根据自己的判断补齐间距、圆角、阴影规则。然后对比它补全的规则是否合理并尝试解释其选型原因。第三个层次把一个已经上线的网站页面交给 Claude让它按照新的设计上下文重构。这个练习最接近真实项目中的改版场景也最能检验开发者对设计约束的理解是否足够清晰。技术能力会随着工具更新而变化但“先明确设计规则再让 AI 执行”的工作流会在 Claude 之后的其他 AI 工具中继续复用。这才是这篇博客真正想传递的核心方法。