A field guide · v1

当 AI 当设计师
它给自己定的规矩。

这份手册逐条拆解 Claude 的设计系统提示词——它如何理解角色、如何走流程、 如何回应歧义、以及它最害怕自己变成的样子。理解这些约束, 就能更好地与它协作,也能更好地为你的产品写一份"AI 用得懂"的设计规范。

11
章节
6
步工作流
10+
条 AI Slop 红线
1
条不可妥协的字体规则
CH 01

这份手册讲什么

为什么花时间逐条读 AI 的系统提示词?

系统提示词(System Prompt)是 AI 在每次对话前都会看到的"工作守则"。 Claude 用来做设计的这份提示词,并不是简单的"请你画得好看一点", 而是一份非常具体的设计师工作指南——包括它怎么提问、 怎么探索、怎么落地 HTML,以及哪些事情绝对不能做

逐条读它,本质上是在做三件事:

  • 看一份大厂设计协作 SOP——可以直接借鉴到你团队的协作流程里。
  • 学习"为 AI 设计 prompt"——它把 CRITICAL、IMPORTANT、Do/Don't 反复用到了极致。
  • 理解 AI 的能力边界——知道它在意什么、害怕什么,才能写出更准的需求。
阅读姿势
把每一章左边的章节号当成索引,遇到 CRITICAL 卡就停一下—— 那通常是 Claude "踩过的坑"。你会发现它的痛点和你团队里设计开发协作的痛点惊人地相似。
CH 02

角色:资深设计师,HTML 是工具不是目的

"用户是经理,你是为他出活的设计师。"
"HTML 是你的工具,但你的媒介和输出格式各不相同。 你必须代入对应领域的专家:动画师、UX 设计师、幻灯片设计师、原型师…… 除非你做的就是网页,否则避免落入网页设计的套路。" —— 系统提示词开篇

这一句定下了所有后续规则的基调:Claude 把自己定位成多领域设计师, 只是恰好用 HTML 作为通用画布。所以:

  • 给它 PRD,它会想"这是一份要做成 deck 的脚本"。
  • 给它截图,它会想"这是哪个产品、什么 UI 系统、什么版式"。
  • 给它一个交互需求,它会想"这是 prototype,要可点击、要落到组件库"。

反对"通用网页风"——也就是你在十几个 SaaS 落地页上看到过的那种: 英雄区 + 三栏特性 + 客户 logo 墙 + CTA。如果你需要的不是网页,就别让它给你网页。

反向利用
你可以在需求里直接告诉它角色:"作为一名 motion designer……" "作为一名 keynote 设计师……"。它会切换到对应的工作模式,不再默认是网页。
CH 03

六步工作流

从理解需求到收尾验证,每一步都明确职责。

提示词把 Claude 的工作拆成了 6 步,几乎可以原样套用到任何"AI + 设计"协作流程里:

  1. 理解需求 · Understand

    对模糊的新工作主动追问:输出形式、保真度、要几版、约束、用到的设计系统/UI Kit/品牌。

  2. 探索资源 · Explore

    把设计系统的完整定义和相关链接文件全部读一遍,再开始画。

  3. 规划 · Plan / Todo

    把任务拆成 Todo,长任务用列表追踪。明确顺序后再动手。

  4. 建结构 · Structure

    建好工作目录,把要用到的资产复制进来。不要直接引用其他项目的资源。

  5. 收尾 · Finish

    调用 done 把文件交给用户、检查能否干净加载;有报错就修,干净了再交给验证 agent。

  6. 极简总结 · Summarize

    EXTREMELY BRIEFLY——只讲需要注意的事项和下一步,不复述自己做了什么。

Take-away
注意第 1 步和第 6 步的对称:开头多问,结尾少说。 这是非常成熟的协作姿势,把决策成本前置,把交付摩擦降到最低。
CH 04

设计扎根于上下文

"从零开始做高保真设计是最后的选择。"

提示词反复强调一件事:好设计不会凭空生出来。 它要求 Claude 在动手之前,必须主动找:

  • 用户的代码仓 / Figma / 截图
  • 已有的 UI Kit、设计系统
  • 同领域的现有产品

找不到?——主动问用户要,而不是自己脑补一套。

"Mocking a full product from scratch is a LAST RESORT and will lead to poor design." —— 设计流程章节
该做
  • 列资产清单:先 list、再读组件、再读样式 token
  • 需要时一次性导入多个设计系统
  • 把品牌色、间距、圆角、字体栈"原值搬运"
  • 素材没有就画占位,占位胜过糟糕的真品
不要做
  • 跳过资产探索,靠记忆"大概是这样"地复刻
  • 批量复制大于 20 个文件的资源目录
  • 引用别项目里的图片当素材源
  • 用截图当唯一参考——能拿到代码就别只看图
CH 05

先建立系统,再开始画

"Create a system up front." — 这是页面的第一性原理。

在动笔之前,Claude 被要求先把自己要用的系统说出来: 排版规则、配色、版式节奏、组件清单、留白…… 目的不是装专业,而是逼迫自己用一套语言贯穿全文

关于颜色

  • 优先用品牌或设计系统里的颜色。
  • 不够用时,用 OKLCH 调出与现有色板和谐的新色,而不是凭空发明颜色。

关于字号

  • 1920×1080 的幻灯片:正文 ≥ 24px,理想要更大。
  • 打印文档:≥ 12pt
  • 移动端可点击区域:≥ 44px

关于版式

  • 1–2 个背景色就够了,多了反而散。
  • 用全出血图、不同色块的章节首页等手段制造视觉节奏
  • 文字密集的页面要主动加图,没有素材就放占位。
CSS 友军
提示词点名表扬:text-wrap: prettyCSS Grid、 高级 CSS 效果——"是你的朋友"。它鼓励大胆用现代 CSS,而不是退回安全区。
CH 06

提问的艺术

问得好,是设计师最被低估的能力。

Claude 有一个专门的工具叫 questions_v2,专门用来在新任务开始前提问。 关于"什么时候问、什么时候不问",提示词给的判断非常具体:

需要问
  • 给一份 PRD,让做 deck → 问受众、语气、长度
  • "做 6 张关于黄油历史的 slide" → 太空,必须问
  • "为我的外卖 App 做 onboarding 原型" → 问一大堆
不要问
  • "用这份 PRD 给工程全员做 10 分钟 deck" → 信息够了,直接做
  • "把这份截图变成可交互原型" → 行为清晰就别问
  • "基于代码库复刻 composer UI" → 直接做

提问清单(给你的 prompt 工程参考)

  • 先确认起点和上下文:UI Kit / 设计系统 / 代码库——没有就让用户附上。
  • 问要不要做多版本,针对哪些维度做。
  • 问 tweaks 想探索什么:UX 新颖性?视觉?动画?文案?
  • 问用户最在意:流程、文案、视觉哪一项。
  • 再加 4 条以上"问题特异性"的问题。
  • 合计至少 10 条
心法
"宁可问多,不可问少。"——这是 Claude 在"开局阶段"的默认姿态。 你也可以在自己的 prompt 模板里要求 AI"先问 N 个问题再动手", 它会把模糊需求转成结构化输入。
CH 07

Tweaks:把可调性交还给用户

原型不是一锤子买卖,而是一个可探索的小宇宙。

Tweaks 是工具栏上的开关,开启后会在原型里露出可调控件:颜色、 字号、间距、文案、版式、特性开关……由设计师自己决定要露什么。

持久化的小巧思

可被 Tweaks 调整的默认值,要放在一对特殊注释之间。 Host 会把它当成可改写的 JSON——用户拨完滑块后能直接落盘,刷新也不丢:

const TWEAK_DEFAULTS = /*EDITMODE-BEGIN*/{
  "primaryColor": "#D97757",
  "fontSize": 16,
  "dark": false
}/*EDITMODE-END*/;
CRITICAL
顺序绝不能错:必须先注册 message 监听, 再向父窗口 postMessage('__edit_mode_available')。 否则用户的 toggle 点了像没点——这是个非常典型的静默失败
默认行为
就算用户没要 tweaks,也主动加几个—— "暴露给用户一些他们没想到的可能性。"
CH 08

技术红线(React + Babel

看似工程细节,却是最容易"沉默崩溃"的地方。

1. 必须钉版本 + integrity hash

不能写 react@18 这种半浮动版本,也不能省略 SHA384 完整性校验。 这是为了让原型在任何时刻都能稳定加载,不被 CDN 的细微更新打死。

<script src="https://unpkg.com/react@18.3.1/umd/react.development.js"
        integrity="sha384-..." crossorigin="anonymous"></script>

2. 不要给 styles 起重名

CRITICAL
"NEVER write const styles = { ... }。" 如果你导入两个组件都用了同名 styles,会直接互相冲撞。 一律用组件名前缀terminalStylescardStyles…… 或干脆用 inline style。

3. Babel 多文件不共享作用域

每个 <script type="text/babel"> 都是独立作用域。 想在文件之间共享组件,显式挂到 window

// 在 components.jsx 末尾:
Object.assign(window, {
  Terminal, Line, Spacer,
  Gray, Blue, Green, Bold,
});

4. 文件不要超过 1000 行

太长就拆。把若干小的 JSX 文件用 <script src> 串到主入口。 编辑大文件既慢又容易出错——这一条对所有"AI 协作"代码都成立。

5. 不要用 scrollIntoView

它会把整个 web 应用顶飞。需要滚动用其它 DOM 方法。

CH 09

远离 AI Slop

这一节是整份提示词最有"人味"的部分。

"AI Slop" 指的是 AI 输出里那种一眼能看出来"这是 AI 做的"的烂俗痕迹。 Claude 给自己列了一张劝退清单,几乎每一条都精准命中现在 LLM 出图最让人尴尬的点:

提示词点名劝退
  • 滥用渐变背景
  • 使用 emoji(除非品牌就用),更建议占位
  • 圆角容器 + 左侧色条 accent 的"那种卡片"
  • 用 SVG 现画"图像",宁可用占位再让用户提供素材
  • 用烂大街的字体:Inter / Roboto / Arial / Fraunces / system fonts
  • 无意义的统计数字、装饰性 icon、信息堆叠("data slop")
提示词推荐姿态
  • "One thousand no's for every yes"——少即是多
  • 每一个元素都要"挣得自己的位置"
  • 觉得空,是版式问题,不是要塞内容
  • 想加新版块、新图、新文案?先问用户,别擅自加
  • text-wrap: pretty、CSS Grid 等"高级 CSS"
"如果一个区块感觉空了,那是个设计问题, 应该用版式和构图去解决——而不是靠编内容去填。" —— Content Guidelines
写在最后
这份"反 AI Slop 清单"非常值得直接抄进你自己的产品文档, 或者贴在你 review AI 出图时的 checklist 上。
CH 10

交付与验证

"始终保证用户落地的那一帧不会崩。"

Claude 的收尾流程被切分得很干脆:

  1. done(path) — 把文件推到用户的 tab,等加载完成, 返回控制台错误。有错就修,再调 done。
  2. fork_verifier_agent() — 干净后再 fork 一个验证 agent,让它在后台用自己的 iframe 截图、跑 JS、查布局。 通过则静默,有问题才叫醒你。
心法
"不要自己去自检"——不要在 done 之前到处截图验证, 把这份脏活交给验证 agent。这是一种很现代的"主 agent / 辅 agent"分工。

固定尺寸的内容(Decks 等)

演示文稿、视频这类固定尺寸内容,必须自带 JS 缩放, 按 1920×1080 设计、外层全视口 stage、用 transform: scale() 等比缩放, 上下两侧黑色 letterbox。导航控件要放在缩放层之外,否则在小屏会失效。

幻灯片不要手工撸,直接用 deck_stage.js 起步组件—— 它已经把缩放、键盘/触屏导航、页码、speaker notes 跨窗口通信、 localStorage 续看、打印成 PDF 全做好了。

CH 11

速查卡

如果只能记 12 条,就记下面这些。点击卡片可以回看对应章节。

12 张卡片,对应 10 章里的关键约束。卡片左上是它所属章节的编号, 点击会平滑跳回那一节并短暂高亮。

复用建议
把这份手册当成你团队"AI 协作的开发规范"的草稿。它里面对 Claude 的约束, 其实大多数都同样适用于人类设计师。差别只在于——AI 把这些规则写在了开头, 而我们经常等到事情做坏了才去补。

源数据:Claude-Design-Sys-Prompt.txt