← All Articles

Claude Design 系统提示词工程拆解

elder-plinius (collected leak) · 2026-04-20 · Original

这份笔记把 Claude Design 的系统提示词当成”工程样本”来读——不是为了抄它做设计 agent，而是为了提取可迁移的 prompt / skill 设计原理，将来做 html skill 改造、prototype skill、其他垂直设计 skill 时的参考手册。

适用场景：

不适用：抄词造句、直接复制规则清单（每个 skill 的场景不同，原理可迁移，具体规则不行）

快速索引

A. 骨架层：prompt 如何组织

A1. 三段式分层架构（全局结构）

原文位置：L161-L201（Role + Workflow 开篇）

整份 prompt 严格按这个顺序铺：

人格 (Role)   →   工作流 (Workflow)   →   规则库 (Rules & Protocols)
一句话             6 个离散步骤              几十条 MUST/NEVER

具体文本：

为什么这样组织更好使：

  1. 模型可以按层归位：漂移时能自己找锚点——“我现在在工作流第几步？”比”我该做什么？“更容易回答
  2. 规则不是堆在一起而是挂在工作流的具体步骤上：比如 Tweaks 规则挂在”原型产出”分支、questions_v2 挂在 step 1、done 挂在 step 5
  3. 事后审计友好：用户质疑”你为什么没问我”时，可以指向 step 1 + questions_v2 规则的具体行

可迁移原理：先定身份 → 再定流程 → 最后列规则。这是信息架构的”由粗到细”，不要反过来写（从规则开始逆推身份）。

给自己 skill 的启示：

A2. 技能冷加载（架构级巧思）

原文位置：L143, L895-L977（Available Skills 章）

Claude Design 有 13 个专项技能，但系统 prompt 里只列一句话描述，不塞具体内容：

- Animated video — Timeline-based motion design
- Interactive prototype — Working app with real interactions
- Make a deck — Slide presentation in HTML
- Make tweakable — Add in-design tweak controls
- Frontend design — Aesthetic direction for designs outside an existing brand system
- Wireframe — Explore many ideas with wireframes and storyboards
- Export as PPTX (editable)
- Export as PPTX (screenshots)
- Create design system
- Save as PDF
- Save as standalone HTML
- Send to Canva
- Handoff to Claude Code

用户需要哪项时，agent 调 invoke_skill 加载对应 prompt。

设计意图：

对比反面教材：把 13 个技能的 prompt 都塞进系统 prompt 里——上下文 10x 膨胀、模型注意力稀释、跨技能规则互相打架。

可迁移原理：skill hub 架构 ≈ 操作系统的按需加载。系统启动只加载 kernel，应用按需启动。

给自己的启示：

B. 语言层：Anthropic 用的”说话套路”

B1. 三档强制词

原文位置：散见全文，高浓度区 L343-L349 (CRITICAL), L461 (Avoid), L653-L667 (Verification)

三档强制词的用法差异：

档位 语义 用在哪
MUST / NEVER 硬底线，不可商量 技术契约（工具参数、文件路径规则）
CRITICAL 容易忘但忘了就崩 踩坑级规则（变量命名、版本锁定）
Always / Avoid / Resist the urge to... 强倾向但留余地 品味 / 产出质量规则

具体例子：

为什么分三档很重要：

  1. 全用 MUST/NEVER → 模型会”规则疲劳”：当所有规则都是必须，模型对重要性的判断反而失效
  2. 全用 Avoid → 软得像没说：品味类的软约束模型很容易漂移回训练语料的均值
  3. 分档使用 → 模型可以分配注意力：CRITICAL 和 MUST 不能让步，Avoid 可以权衡

可迁移原理：强度要和后果匹配——代码必崩的坑用 CRITICAL，品味偏好用 Avoid，技术契约用 MUST。乱用强度等于没用。

给自己的启示：

B2. 负面清单 > 正面清单（反 AI slop 秘诀）

原文位置：L863-L891（Content Guidelines - Avoid AI slop tropes）

整章 Content Guidelines 的杀手锏是显式列”不要做什么”：

Avoid AI slop tropes:
- Avoiding aggressive use of gradient backgrounds
- Avoiding emoji unless explicitly part of the brand; better to use placeholders
- Avoiding containers using rounded corners with a left-border accent color
- Avoiding drawing imagery using SVG; use placeholders and ask for real materials
- Avoid overused font families (Inter, Roboto, Arial, Fraunces, system fonts)

为什么这招有效：

  1. 训练语料均值即 AI slop：所有”AI 生成设计”长得都一个样（渐变背景、emoji、圆角卡片 + 彩色左边条、Inter 字体）——因为训练数据里这种风格最多，模型的默认输出就是这个
  2. 正面清单不管用：写”请有美学品味”、“请参考优秀设计”——这些都是模糊指令，模型不知道具体该怎么做
  3. 负面清单是栅栏：不要 X 明确可判定，比”要有品味”强 10 倍
  4. 反训练回音：直接点名禁用那些”训练数据里最常见但实际最俗”的模式，就是告诉模型”偏离你的默认分布”

可迁移原理：当你要对抗模型的默认偏好时，用负面清单。正面引导只适合在没有默认偏好的白纸上。

给自己的启示：

B3. 例子模板化（让规则可泛化）

原文位置：L577-L588（questions_v2 场景示例）

给了 6 个场景对照：

make a deck for the attached PRD
  → ask questions about audience, tone, length, etc

make a deck with this PRD for Eng All Hands, 10 minutes
  → no questions; enough info was provided

turn this screenshot into an interactive prototype
  → ask questions only if intended behavior is unclear from images

make 6 slides on the history of butter
  → vague, ask questions

prototype an onboarding for my food delivery app
  → ask a TON of questions

recreate the composer UI from this codebase
  → no questions

为什么需要例子：

  1. 抽象规则”信息够就别问，不够就问” → 模型不知道”够”和”不够”的分界
  2. 6 个场景对照 → 模型从 6 个点外推出判别函数
  3. 覆盖不同 ambiguity 等级 + 不同信息密度：从”完全给足（codebase 还原）“到”完全模糊（黄油历史）”

可迁移原理：抽象规则 + 具体 dos/don’ts 对照 = 高泛化。不要只写规则，要给 3-6 个跨光谱的例子。

给自己的启示：

C. 机制层：最有工程巧思的 5 个设计

C1. questions_v2 — 把”先问再做”编码成硬工具

原文位置：L572-L648（Asking questions 章）

机制：

原文引用（L611-L627）：

“Always confirm the starting point and product context – a UI kit, design system, codebase, etc.” “Always ask whether they’d like variations, and for which aspects.” “Always ask what tweaks the user would like” “Ask at least 4 other problem-specific questions” “Ask at least 10 questions, maybe more.”

精髓：把行为规范从 prompt 的软约束降维成工具 API 层面的硬契约——工具签名就”无法跳过”。

对比反面：只写”请先问用户” → 模型会经常直接开干，因为工具层面没有阻塞点。

可迁移原理：软规则 → 工具/协议层硬化，当你希望某个行为”100% 发生”而不是”大部分时候发生”。

给自己的启示：

C2. 验证两阶段 — done + fork_verifier_agent

原文位置：L651-L668（Verification 章）

机制：

写完
  ↓
done(path)  ← 打开用户 tab + 返回 console 错
  ↓ 干净了
fork_verifier_agent()  ← 后台 subagent（独立 iframe）做截图+布局+JS 复检
  ↓
本回合直接结束（不等后台）
  ↓
通过 = 静默；出问题 = 叫醒主 agent

三层工程巧思：

  1. 主 agent 不做视觉自查（L659-L667）： > “Do not perform your own verification before calling done; do not proactively grab screenshots to check your work; rely on the verifier to catch issues without cluttering your context.”

    为什么？截图/复检会消耗巨量上下文，把主 agent 拖累。

  2. 后台 agent 有独立 iframe 上下文：验证器的工作不污染主对话流，只有发现问题才回传。

  3. 非阻塞异步（L655-L656）： > “Silent on pass — only wakes you if something’s wrong. Don’t wait for it; end your turn.”

可迁移原理：验证 = 独立 agent + 异步 + 按需唤醒。把”验证”从主流程里解耦出去，靠 subagent 做，主 agent 只关心”出问题时被通知”。

给自己的启示：

C3. Tweaks 协议 — 把”可调节性”产品化

原文位置：L669-L743（Tweaks 章，包括 Protocol + Persisting state + Tips）

这是整个 prompt 里最精巧的一块。

机制：HTML 原型和宿主 IDE 通过 postMessage + JSON 注释栅栏双向通信。

关键三步（L677-L709）：

// Step 1: 先注册监听（顺序敏感！）
window.addEventListener('message', e => {
  if (e.data.type === '__activate_edit_mode') { /* 显示 Tweaks 面板 */ }
  if (e.data.type === '__deactivate_edit_mode') { /* 隐藏 */ }
});

// Step 2: 再宣布可用
window.parent.postMessage({type: '__edit_mode_available'}, '*');

// Step 3: 用户改值时，既实时应用又持久化
window.parent.postMessage(
  {type: '__edit_mode_set_keys', edits: {fontSize: 18}},
  '*'
);

关键顺序警告（L677）：

“Order matters: register the listener before you announce availability. If you post __edit_mode_available first, the host’s activate message can land before your handler exists and the toggle silently does nothing.”

这是典型的分布式系统竞态条件——在 prompt 里显式教给模型，这很罕见。

磁盘持久化机制（L713-L725）：

const TWEAK_DEFAULTS = /*EDITMODE-BEGIN*/{
  "primaryColor": "#D97757",
  "fontSize": 16,
  "dark": false
}/*EDITMODE-END*/;

为什么这是分水岭：

可迁移原理（两条）：

  1. 产出物要有”可调面”：每个产出都该显式暴露 2-5 个 knob，而不是交付一个”最优解”
  2. 状态持久化 = 活物 vs 死物：如果产出只是静态交付，迭代成本极高；把”上次调到哪”存下来，迭代成本降 10 倍

给自己的启示：

ROI 评估：这条是 6 条借鉴里最重但收益最独特的一条——建议放后面做，先把架构和品味栅栏搞定再碰

C4. snip — 上下文管理的延迟 GC

原文位置：L562-L570（Context management 章）

机制：

原文（L564-L568）：

“Each user message carries an [id:mNNNN] tag. When a phase of work is complete — an exploration resolved, an iteration settled, a long tool output acted on — use the snip tool with those IDs to mark that range for removal. Snips are deferred: register them as you go, and they execute together only when context pressure builds.”

“Snip silently as you work — don’t tell the user about it.”

对比三种 context 管理策略：

策略 优点 缺点
暴力截断早期消息 简单 丢上下文，对话连续性崩
实时压缩总结 保留语义 贵（额外 LLM 调用）+ 失真
Snip 延迟执行 agent 自己标记 + 压力触发 需要宿主配合实现

Snip 的双重权衡：

可迁移原理：垃圾回收不必实时，延迟执行 + 压力触发是更优的工程答案。

给自己的启示：

C5. 版权栅栏 — 合规编码进 prompt

原文位置：L985-L991（Do not recreate copyrighted designs 章）

原文：

“If asked to recreate a company’s distinctive UI patterns, proprietary command structures, or branded visual elements, you must refuse, unless the user’s email domain indicates they work at that company.”

<user-email-domain>______</user-email-domain>

机制：

为什么这条重要：

可迁移原理：合规 / 安全 / 边界规则要编码进 prompt，而不是留在外部文档或后处理。

给自己的启示：

D. 对照表：软要求 → 硬实现

Claude Design 最值得学的不是具体条款，而是系统化的”软→硬”降维思路：

常见软要求 Claude Design 的硬实现载体 设计机制
“先问清楚再做” questions_v2 阻塞式工具 工具调用契约
“检查你的产出” fork_verifier_agent 后台 agent 异步子 agent
“改版别散文件” Tweaks postMessage 协议 + JSON 注释栅栏 双向通信协议
“别污染上下文” snip 标记 + 压力触发 延迟 GC
“别被 AI 训练数据带偏” 显式负面清单（AI slop tropes） 负面约束
“别侵权” 邮箱域名白名单 + prompt 注入 合规栅栏
“按需加载能力” invoke_skill + 13 技能索引 冷启动最小 + 热加载
“理解已有代码再做” github_import_files 强制链路 + CRITICAL 警告 链路硬化
“产出要能验证” done 返回 console errors 工具返回值契约
“长对话不失位” [id:mNNNN] + localStorage 持久化位置 状态外置

一句话总结：

Anthropic 把每一条”希望模型做到的事”，都找了一个比自然语言约束更强的载体（工具 / 协议 / 结构 / 栅栏）。这是把 prompt 当系统工程在做，不是当 chat message 在写。

E. 给自己做 skill 的启示

结合当前 skill 生态（html / learning hub / research hub / investment / apple-ui-design 等）做的自我审视：

E1. 架构层（优先级：中高）

E2. 语言层（优先级：高，改造成本低）

E3. 机制层（优先级：因场景而定，成本高）

E4. 不做的事

下一步（候选）

  1. 首刀（推荐）：按 handoff 第 3 步，给 html skill 写 content-guidelines.md（抄 AI slop 清单 + 合并 apple-ui-design 禁用项）
  2. 架构改造：重构 html skill 的 SKILL.md 开头为”人格一句话 / 6 步工作流 / 硬约束”三段式
  3. 单独评估：Tweaks 协议的 ROI 和技术可行性（需要探索 claude code 环境）
  4. 复盘：再过 1-2 周回来看这份笔记，检查哪些 takeaway 真的用上了（feedback loop）

附：原文行号速查

章节 行号
Role（人格） L161-L171
Your workflow（6 步工作流） L201-L229
Output creation guidelines L245-L289
React + Babel（CRITICAL 级规则密度区） L329-L367
How to do design work L418-L468
Context management（snip） L562-L570
Asking questions（questions_v2） L572-L648
Verification（done + fork_verifier_agent） L651-L668
Tweaks Protocol L669-L743
Starter Components L771-L809
GitHub（强制链路） L811-L843
Content Guidelines（AI slop 负面清单） L845-L893
Available Skills（13 个） L895-L977
Do not recreate copyrighted designs（合规栅栏） L985-L991
Tool invocation protocol（XML 工具契约） L993-L1012
Functions in JSONSchema（37 个工具清单） L1014+