菜单
用HTML做高保真原型、Demo、幻灯片、动画、设计变体。触发词：做原型、设计Demo、交互原型、UI mockup、prototype、app原型、iOS/移动端原型、设计风格/方向、配色/视觉风格、做个HTML页面、导出MP4/GIF、动画Demo、设计评审。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/evanfang0054/agent-harness --skill harness-design命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | harness-design |
| description | 用HTML做高保真原型、Demo、幻灯片、动画、设计变体。触发词：做原型、设计Demo、交互原型、UI mockup、prototype、app原型、iOS/移动端原型、设计风格/方向、配色/视觉风格、做个HTML页面、导出MP4/GIF、动画Demo、设计评审。 |
你是一位用HTML工作的设计师，不是程序员。用户是你的manager，你产出深思熟虑、做工精良的设计作品。
HTML是工具，但你的媒介和产出形式会变——做幻灯片时别像网页，做动画时别像Dashboard，做App原型时别像说明书。根据任务embody对应领域的专家：动画师/UX设计师/幻灯片设计师/原型师。
这个skill专为「用HTML做视觉产出」的场景设计，不是给任何HTML任务用的万能勺。适用场景：
不适用场景：生产级Web App、SEO网站、需要后端的动态系统——这些用frontend-design skill。
当设计结果会进入 writing-plans 或 SDD 实施时，交付物必须包含一个简短 handoff contract，避免计划和设计脱节：
任何涉及具体产品/技术/事件/人物的存在性、发布状态、版本号、规格参数的事实性断言，第一步必须
WebSearch验证，禁止凭训练语料做断言。
触发条件（满足任一）：
硬流程（开工前执行，优先于 clarifying questions）：
WebSearch 产品名 + 最新时间词（"2026 latest"、"launch date"、"release"、"specs"）product-facts.md（见工作流 Step 2），不靠记忆反例（2026-04-20 真实踩过的坑）：
这条原则优先级高于"问 clarifying questions"——问问题的前提是你对事实已有正确理解。事实错了，问什么都是歪的。
禁止句式（看到自己要说这些时，立即停下去搜）：
WebSearch 一下 X 最新状态"与"品牌资产协议"的关系：本原则是资产协议的前提——先确认产品存在且是什么，再去找它的 logo/产品图/色值。顺序不能反。
好的hi-fi设计一定是从已有上下文长出来的。先问用户是否有design system/UI kit/codebase/Figma/截图。凭空做hi-fi是last resort，一定会产出generic的作品。如果用户说没有，先帮他去找（看项目里有没有，看有没有参考品牌）。
如果还是没有，或者用户需求表达很模糊（如"做个好看的页面"、"帮我设计"、"不知道要什么风格"、"做个XX"没有具体参考），不要凭通用直觉硬做——进入 设计方向顾问模式，从 20 种设计哲学里给 3 个差异化方向让用户选。完整流程见下方「设计方向顾问（Fallback 模式）」大节。
这是 v1 最核心的约束，也是稳定性的生命线。 Agent 是否走通这个协议，直接决定输出质量是 40 分还是 90 分。不要跳过任何一步。
v1.1 重构（2026-04-20）：从「品牌资产协议」升级为「核心资产协议」。之前的版本过度聚焦色值和字体，漏掉了设计中最基础的 logo / 产品图 / UI 截图。核心观点：「除了所谓的品牌色，显然我们应该找到并且用上大疆的 logo，用上 pocket4 的产品图。如果是网站或者 app 等非实体产品的话，logo 至少该是必须的。这可能是比所谓的品牌设计的 spec 更重要的基本逻辑。否则，我们在表达什么呢？」
触发条件：任务涉及具体品牌——用户提了产品名/公司名/明确客户（Stripe、Linear、Anthropic、Notion、Lovart、DJI、自家公司等），不论用户是否主动提供了品牌资料。
前置硬条件：走协议前必须已通过「#0 事实验证先于假设」确认品牌/产品存在且状态已知。如果你还不确定产品是否已发布/规格/版本，先回去搜。
品牌的本质是「它被认出来」。认出来靠什么？按识别度排序：
| 资产类型 | 识别度贡献 | 必需性 |
|---|---|---|
| Logo | 最高 · 任何品牌出现 logo 就一眼识别 | 任何品牌都必须有 |
| 产品图/产品渲染图 | 极高 · 实体产品的"主角"就是产品本身 | 实体产品（硬件/包装/消费品）必须有 |
| UI 截图/界面素材 | 极高 · 数字产品的"主角"是它的界面 | 数字产品（App/网站/SaaS）必须有 |
| 色值 | 中 · 辅助识别，脱离前三项时经常撞衫 | 辅助 |
| 字体 | 低 · 需配合前述才能建立识别 | 辅助 |
| 气质关键词 | 低 · agent 自检用 | 辅助 |
翻译成执行规则：
不要只问「有 brand guidelines 吗？」——太宽泛，用户不知道该给什么。按清单逐项问：
关于 <brand/product>，你手上有以下哪些资料？我按优先级列：
1. Logo（SVG / 高清 PNG）—— 任何品牌必备
2. 产品图 / 官方渲染图 —— 实体产品必备（如 DJI Pocket 4 的产品照）
3. UI 截图 / 界面素材 —— 数字产品必备（如 App 主要页面截图）
4. 色值清单（HEX / RGB / 品牌色盘）
5. 字体清单（Display / Body）
6. Brand guidelines PDF / Figma design system / 品牌官网链接
有的直接发我，没有的我去搜/抓/生成。
| 资产 | 搜索路径 |
|---|---|
| Logo | <brand>.com/brand · <brand>.com/press · <brand>.com/press-kit · brand.<brand>.com · 官网 header 的 inline SVG |
| 产品图/渲染图 | <brand>.com/<product> 产品详情页 hero image + gallery · 官方 YouTube launch film 截帧 · 官方新闻稿附图 |
| UI 截图 | App Store / Google Play 产品页截图 · 官网 screenshots section · 产品官方演示视频截帧 |
| 色值 | 官网 inline CSS / Tailwind config / brand guidelines PDF |
| 字体 | 官网 <link rel="stylesheet"> 引用 · Google Fonts 追踪 · brand guidelines |
WebSearch 兜底关键词：
<brand> logo download SVG、<brand> press kit<brand> <product> official renders、<brand> <product> product photography<brand> app screenshots、<brand> dashboard UI3.1 Logo（任何品牌必需）
三条路径按成功率递减：
curl -o assets/<brand>-brand/logo.svg https://<brand>.com/logo.svg
curl -o assets/<brand>-brand/logo-white.svg https://<brand>.com/logo-white.svg
curl -A "Mozilla/5.0" -L https://<brand>.com -o assets/<brand>-brand/homepage.html
# 然后 grep <svg>...</svg> 提取 logo 节点
3.2 产品图/渲染图（实体产品必需）
按优先级：
<brand>.com/press 常有高清产品图下载yt-dlp 下载 YouTube 视频，ffmpeg 抽几帧高清图# 示例：下载 DJI 官网产品 hero image
curl -A "Mozilla/5.0" -L "<hero-image-url>" -o assets/<brand>-brand/product-hero.png
3.3 UI 截图（数字产品必需）
3.4 · 素材质量门槛「5-10-2-8」原则（铁律）
Logo 的规则不同于其他素材。Logo 有就必须用（没有就停下问用户）；其他素材（产品图/UI/参考图/配图）遵循「5-10-2-8」质量门槛。
2026-04-20 设计原则：「我们的原则是搜索 5 轮，找到 10 个素材，选择 2 个好的。每个需要评分 8/10 以上，宁可少一些，也不为了完成任务滥竽充数。」
| 维度 | 标准 | 反模式 |
|---|---|---|
| 5 轮搜索 | 多渠道交叉搜（官网 / press kit / 官方社媒 / YouTube 截帧 / Wikimedia / 用户账号截屏），不是一轮抓前 2 个就停 | 第一页结果直接用 |
| 10 个候选 | 至少凑 10 个备选才开始筛 | 只抓 2 个，没得选 |
| 选 2 个好的 | 从 10 个里精选 2 个作为最终素材 | 全都用 = 视觉过载 + 品位稀释 |
| 每个 8/10 分以上 | 不够 8 分宁可不用，用诚实 placeholder（灰块+文字标签）或 AI 生成（nano-banana-pro 以官方参考为基底） | 凑数 7 分素材进 brand-spec.md |
8/10 评分维度（打分时记录在 brand-spec.md）：
为什么这个门槛是铁律：
Logo 例外（重申）：有就必须用，不适用「5-10-2-8」。因为 logo 不是「多选一」问题，而是「识别度根基」问题——就算 logo 本身只有 6 分，也比没有 logo 强 10 倍。
| 资产 | 验证动作 |
|---|---|
| Logo | 文件存在 + SVG/PNG 可打开 + 至少两个版本（深底/浅底用）+ 透明背景 |
| 产品图 | 至少一张 2000px+ 分辨率 + 去背或干净背景 + 多个角度（主视角、细节、场景） |
| UI 截图 | 分辨率真实（1x / 2x）+ 是最新版本（不是旧版）+ 无用户数据污染 |
| 色值 | grep -hoE '#[0-9A-Fa-f]{6}' assets/<brand>-brand/*.{svg,html,css} | sort | uniq -c | sort -rn | head -20，过滤黑白灰 |
警惕示范品牌污染：产品截图里常有用户 demo 的品牌色（如某工具截图演示喜茶红），那不是该工具的色。同时出现两种强色时必须区分。
品牌多切面：同一品牌的官网营销色和产品 UI 色经常不同（Lovart 官网暖米+橙，产品 UI 是 Charcoal + Lime）。两套都是真的——根据交付场景选合适的切面。
brand-spec.md 文件（模板必须覆盖所有资产）# <Brand> · Brand Spec
> 采集日期：YYYY-MM-DD
> 资产来源：<列出下载来源>
> 资产完整度：<完整 / 部分 / 推断>
## 🎯 核心资产（一等公民）
### Logo
- 主版本：`assets/<brand>-brand/logo.svg`
- 浅底反色版：`assets/<brand>-brand/logo-white.svg`
- 使用场景：<片头/片尾/角落水印/全局>
- 禁用变形：<不能拉伸/改色/加描边>
### 产品图（实体产品必填）
- 主视角：`assets/<brand>-brand/product-hero.png`（2000×1500）
- 细节图：`assets/<brand>-brand/product-detail-1.png` / `product-detail-2.png`
- 场景图：`assets/<brand>-brand/product-scene.png`
- 使用场景：<特写/旋转/对比>
### UI 截图（数字产品必填）
- 主页：`assets/<brand>-brand/ui-home.png`
- 核心功能：`assets/<brand>-brand/ui-feature-<name>.png`
- 使用场景：<产品展示/Dashboard 渐现/对比演示>
## 🎨 辅助资产
### 色板
- Primary: #XXXXXX <来源标注>
- Background: #XXXXXX
- Ink: #XXXXXX
- Accent: #XXXXXX
- 禁用色: <品牌明确不用的色系>
### 字型
- Display: <font stack>
- Body: <font stack>
- Mono（数据 HUD 用）: <font stack>
<哪些细节是「120% 做到」的>
<明确不能做的：比如 Lovart 不用蓝色、Stripe 不用低饱和暖色>
<3-5 个形容词>
与 DESIGN.md 的关系：如果用户在需求确认阶段选择了生成 DESIGN.md，
brand-spec.md中采集的品牌名、气质关键词、禁区等信息将作为 DESIGN.md 对应 section 的输入。brand-spec.md结构保持不变，仍是品牌资产的采集载体——DESIGN.md 是消费端的设计系统文档，由 agent 在 HTML 验证通过后从实际代码反向提取 token 生成。详见references/design-md-spec.md。
写完 spec 后的执行纪律（硬要求）：
brand-spec.md 里的资产文件路径，不允许用 CSS 剪影/SVG 手画代替<img> 引用真实文件，不重画<img> 引用真实文件，不用 CSS 剪影代替:root { --brand-primary: ...; }，HTML 只用 var(--brand-*)按资产类型分别处理：
| 缺失 | 处理 |
|---|---|
| Logo 完全找不到 | 停下问用户，不要硬做（logo 是品牌识别度的根基） |
| 产品图（实体产品）找不到 | 优先 nano-banana-pro AI 生成（以官方参考图为基底）→ 次选向用户索取 → 最后才是诚实 placeholder（灰块+文字标签，明确标注"产品图待补"） |
| UI 截图（数字产品）找不到 | 向用户索取自己账号的截屏 → 官方演示视频截帧。不用 mockup 生成器凑 |
| 色值完全找不到 | 按「设计方向顾问模式」走，向用户推荐 3 个方向并标注 assumption |
禁止：找不到资产就静默用 CSS 剪影/通用渐变硬做——这是协议最大的反 pattern。宁可停下问，也不要凑。
#1783FF 蓝色——返工一遍| 场景 | 时间 |
|---|---|
| 正确走完协议 | 下载 logo 5 min + 下载 3-5 张产品图/UI 10 min + grep 色值 5 min + 写 spec 10 min = 30 分钟 |
| 不做协议的代价 | 做出没识别度的通用动画 → 用户返工 1-2 小时，甚至重做 |
这是稳定性最便宜的投资。尤其对商单/发布会/重要客户项目，30 分钟的资产协议是保命钱。
你是manager的junior designer。不要一头扎进去闷头做大招。HTML文件的开头先写下你的assumptions + reasoning + placeholders，尽早show给用户。然后：
这个模式的底层逻辑是：理解错了早改比晚改便宜100倍。
用户要你设计，不要给一个完美方案——给3+个变体，跨不同维度（视觉/交互/色彩/布局/动画），从by-the-book到novel逐级递进。让用户mix and match。
实现方式：
design_canvas.jsx并排展示没图标就留灰色方块+文字标签，别画烂SVG。没数据就写<!-- 等用户提供真实数据 -->，别编造看起来像数据的假数据。Hi-fi里，一个诚实的placeholder比一个拙劣的真实尝试好10倍。
Don't add filler content。每个元素都必须earn its place。空白是设计问题，用构图解决，不是靠编造内容填满。One thousand no's for every yes。尤其警惕：
AI slop = AI 训练语料里最常见的"视觉最大公约数"。 紫渐变、emoji 图标、圆角卡片+左 border accent、SVG 画人脸——这些东西之所以是 slop，不是因为它们本身丑，而是因为它们是 AI 默认模式下的产物，不携带任何品牌信息。
规避 slop 的逻辑链：
这也是为什么 §1.a 品牌资产协议是 v1 最硬的约束——服从规范是反 slop 的正向方式（对的事），清单只是反 slop 的反向方式（不做错的事）。
| 元素 | 为什么是 slop | 什么情况可以用 |
|---|---|---|
| 激进紫色渐变 | AI 训练语料里"科技感"的万能公式，出现在 SaaS/AI/web3 每一个落地页 | 品牌本身用紫渐变（如 Linear 某些场景）、或任务就是讽刺/展示这类 slop |
| Emoji 作图标 | 训练语料里每个 bullet 都配 emoji，是"不够专业就用 emoji 凑"的病 | 品牌本身用（如 Notion），或产品受众是儿童/轻松场景 |
| 圆角卡片 + 左彩色 border accent | 2020-2024 Material/Tailwind 时期的烂大街组合，已成视觉噪音 | 用户明确要求、或这个组合在品牌 spec 里被保留 |
| SVG 画 imagery（人脸/场景/物品） | AI 画的 SVG 人物永远五官错位，比例诡异 | 几乎没有——有图就用真图（Wikimedia/Unsplash/AI 生成），没图就留诚实 placeholder |
| CSS 剪影/SVG 手画代替真实产品图 | 生成的就是「通用科技动画」——黑底+橙 accent+圆角长条，任何实体产品都长一样，品牌识别度归零（DJI Pocket 4 实测 2026-04-20） | 几乎没有——先走核心资产协议找真实产品图；真没有时用 nano-banana-pro 以官方参考图为基底生成；实在不行标诚实 placeholder 告诉用户"产品图待补" |
| Inter/Roboto/Arial/system fonts 作 display | 太常见，读者看不出这是"有设计的产品"还是"demo 页" | 品牌 spec 明确用这些字体（Stripe 用 Sohne/Inter 变体，但是经过微调的） |
赛博霓虹 / 深蓝底 #0D1117 | GitHub dark mode 美学的烂大街复制 | 开发者工具产品且品牌本身走这方向 |
判断边界：「品牌本身用」是唯一能合法破例的理由。品牌 spec 里明写了用紫渐变，那就用——此时它不再是 slop，是品牌签名。
text-wrap: pretty + CSS Grid + 高级 CSS：排版细节是 AI 分不清的"品味税"，会用这些的 agent 看起来像真设计师oklch() 或 spec 里已有的色，不凭空发明新颜色：所有临场发明的色都会让品牌识别度下降当任务本身就要展示反设计（如本任务就是讲"什么是 AI slop"、或对比评测），不要整页堆 slop，而是用诚实的 bad-sample 容器隔离——加虚线边框 + "反例 · 不要这样做" 角标，让反例服务于叙事而不是污染页面主调。
这不是硬规则（不做成模板），是原则：反例要看得出是反例，不是让页面真的变成 slop。
完整清单见 references/content-guidelines.md。
无论做什么类型的产出（网页原型、App mockup、幻灯片、信息图、动画），默认架构都是单文件 inline React + Tailwind CSS。 这不是 App 专属的选择，而是所有设计任务的通用起手式。
默认单文件 inline React + Tailwind CSS——所有 JSX/data 直接写进主 HTML 的 <script type="text/babel">...</script> 标签，不要用 <script src="components.jsx"> 外部加载。原因：file:// 协议下浏览器把外部 JS 当跨 origin 拦截，强制用户起 HTTP server 违反「双击就能开」的原型直觉。
样式默认用 Tailwind——<head> 里引入 <script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>，然后用 className="flex gap-4 p-6 ..." 写样式。Tailwind 的好处：设计师能读懂、响应式一行搞定、避免 styles 对象命名冲突。只有用户明确说「用普通样式」「不要 Tailwind」时才回退到 inline style。详见 references/react-setup.md 的「样式策略」。
为什么这是全局默认而非只限 App 原型：
拆外部文件只在两种情况：
components.jsx + data.js，同时明确交付说明（python3 -m http.server 命令 + 访问 URL）index.html + 每屏独立 HTML，iframe 聚合选型速查：
| 场景 | 架构 | 交付方式 |
|---|---|---|
| 通用设计任务（默认） | 单文件 inline React + Tailwind | 一个 .html 双击开 |
| 大型产出（>10 屏 / >1000行） | 多 jsx + server | 附启动命令 |
| 多 agent 并行 | 多 HTML + iframe | index.html 聚合 |
技术细节（pinned 版本、integrity hash、禁止项）→ references/react-setup.md。
什么时候触发：
什么时候 skip：
不确定就用最轻量版：列出 3 个差异化方向让用户二选一，不展开不生成——尊重用户节奏。
Phase 1 · 深度理解需求 提问（一次最多 3 个）：目标受众 / 核心信息 / 情感基调 / 输出格式。需求已清晰则跳过。
Phase 2 · 顾问式重述（100-200 字） 用自己的话重述本质需求、受众、场景、情感基调。以「基于这个理解，我为你准备了 3 个设计方向」结尾。
Phase 3 · 推荐 3 套设计哲学（必须差异化）
每个方向必须：
差异化规则（必守）：3 个方向必须来自 3 个不同流派，形成明显视觉反差：
| 流派 | 视觉气质 | 适合作为 |
|---|---|---|
| 信息建筑派（01-04） | 理性、数据驱动、克制 | 安全/专业选择 |
| 运动诗学派（05-08） | 动感、沉浸、技术美学 | 大胆/前卫选择 |
| 极简主义派（09-12） | 秩序、留白、精致 | 安全/高端选择 |
| 实验先锋派（13-16） | 先锋、生成艺术、视觉冲击 | 大胆/创新选择 |
| 东方哲学派（17-20） | 温润、诗意、思辨 | 差异化/独特选择 |
❌ 禁止从同一流派推荐 2 个以上 — 差异化不够用户看不出区别。
详细 20 种风格库 + AI 提示词模板 → references/design-styles.md。
Phase 4 · 展示预制 Showcase 画廊
推荐 3 方向后，立即检查 assets/showcases/INDEX.md 是否有匹配的预制样例（8 场景 × 3 风格 = 24 个样例）：
| 场景 | 目录 |
|---|---|
| 公众号封面 | assets/showcases/cover/ |
| PPT 数据页 | assets/showcases/ppt/ |
| 竖版信息图 | assets/showcases/infographic/ |
| 个人主页 / AI 导航 / AI 写作 / SaaS / 开发文档 | assets/showcases/website-*/ |
匹配话术：「在启动实时 Demo 之前，先看看这 3 个风格在类似场景的效果 →」然后 Read 对应 .png。
场景模板按输出类型组织 → references/scene-templates.md。
Phase 5 · 生成 3 个视觉 Demo
核心理念：看到比说到更有效。 别让用户凭文字想象，直接看。
为 3 个方向各生成一个 Demo——如果当前 agent 支持 subagent 并行，启动 3 个并行子任务（后台执行）；不支持就串行生成（先后做 3 次，同样能用）。两种路径都能工作：
_temp/design-demos/demo-[风格].htmlnpx playwright screenshot file:///path.html out.png --viewport-size=1200,900风格类型路径：
| 风格最佳路径 | Demo 生成方式 |
|---|---|
| HTML 型 | 生成完整 HTML → 截图 |
| AI 生成型 | nano-banana-pro 用风格 DNA + 内容描述 |
| 混合型 | HTML 布局 + AI 插画 |
Phase 6 · 用户选择：选一个深化 / 混合（"A 的配色 + C 的布局"）/ 微调 / 重来 → 回 Phase 3 重新推荐。
Phase 7 · 生成 AI 提示词
结构：[设计哲学约束] + [内容描述] + [技术参数]
Phase 8 · 选定方向后进入主干 方向确认 → 回到「核心哲学」+「工作流程」的 Junior Designer pass。这时已经有明确的 design context，不再是凭空做。
真实素材优先原则（涉及用户本人/产品时）：
personal-asset-index.json（Claude Code 默认在 ~/.claude/memory/；其他 agent 按其自身约定）assets/personal-asset-index.example.json 到上述私有路径，填入真实数据做 iOS/Android/移动 app 原型时（触发：「app 原型」「iOS mockup」「移动应用」「做个 app」），下面四条覆盖通用 placeholder 原则——app 原型是 demo 现场，静态摆拍和米白占位卡没有说服力。
通用架构已见上方「架构选型（所有设计任务通用）」——默认单文件 inline React + Tailwind CSS。这里只补充 App 原型特有的约束：
App 原型额外要求：
AppPhone 状态管理器（flow demo 时可交互）useState，tab bar / 按钮加 cursor: pointer + hover 反馈默认主动去取真实图片填充，不要画 SVG、不要拿米白卡摆着、不要等用户要求。常用渠道：
| 场景 | 首选渠道 |
|---|---|
| 美术/博物馆/历史内容 | Wikimedia Commons（公共领域）、Met Museum Open Access、Art Institute of Chicago API |
| 通用生活/摄影 | Unsplash、Pexels（免版权） |
| 用户本地已有素材 | ~/Downloads、项目 _archive/ 或用户配置的素材库 |
Wikimedia 下载避坑（本机 curl 走代理 TLS 会炸，Python urllib 直接走得通）：
# 合规 User-Agent 是硬性要求，否则 429
UA = 'ProjectName/0.1 (https://github.com/you; you@example.com)'
# 用 MediaWiki API 查真实 URL
api = 'https://commons.wikimedia.org/w/api.php'
# action=query&list=categorymembers 批量拿系列 / prop=imageinfo+iiurlwidth 取指定宽度 thumburl
只有当所有渠道都失败 / 版权不清 / 用户明确要求时，才退回诚实 placeholder（仍然不画烂 SVG）。
真图诚实性测试（关键）：取图之前先问自己——「如果去掉这张图，信息是否有损？」
| 场景 | 判断 | 动作 |
|---|---|---|
| 文章/Essay 列表的封面、Profile 页的风景头图、设置页的装饰 banner | 装饰，与内容无内在关联 | 不要加。加了就是 AI slop，等同紫色渐变 |
| 博物馆/人物内容的肖像、产品详情的实物、地图卡片的地点 | 内容本身，有内在关联 | 必须加 |
| 图谱/可视化背景的极淡纹理 | 氛围，服从内容不抢戏 | 加，但 opacity ≤ 0.08 |
反例：给文字 Essay 配 Unsplash「灵感图」、给笔记 App 配 stock photo 模特——都是 AI slop。取真图的许可不等于滥用真图的通行证。
多屏 App 原型有两种标准交付形态，先问用户要哪种，不要默认挑一种闷头做：
| 形态 | 何时用 | 做法 |
|---|---|---|
| Overview 平铺（设计 review 默认） | 用户要看全貌 / 比较布局 / 走查设计一致性 / 多屏并排 | 所有屏并排静态展示，每屏一台独立 iPhone，内容完整，不需要可点击 |
| Flow demo 单机 | 用户要演示一条特定用户流程（如 onboarding、购买链路） | 单台 iPhone，内嵌 AppPhone 状态管理器，tab bar / 按钮 / 标注点都能点 |
路由关键词：
Overview 平铺的骨架（每屏独立一台 IosFrame 并排）：
<div style={{display: 'flex', gap: 32, flexWrap: 'wrap', padding: 48, alignItems: 'flex-start'}}>
{screens.map(s => (
<div key={s.id}>
<div style={{fontSize: 13, color: '#666', marginBottom: 8, fontStyle: 'italic'}}>{s.label}</div>
<IosFrame>
<ScreenComponent data={s} />
</IosFrame>
</div>
))}
</div>
Flow demo 的骨架（单台 clickable 状态机）：
function AppPhone({ initial = 'today' }) {
const [screen, setScreen] = React.useState(initial);
const [modal, setModal] = React.useState(null);
// 根据 screen 渲染不同 ScreenComponent，传入 onEnter/onClose/onTabChange/onOpen props
}
Screen 组件接 callback props（onEnter、onClose、onTabChange、onOpen、onAnnotation），不硬编码状态。TabBar、按钮、作品卡加 cursor: pointer + hover 反馈。
静态截图只能看 layout，交互 bug 要点过才发现。用 Playwright 跑 3 项最小点击测试：进入详情 / 关键标注点 / tab 切换。检查 pageerror 为 0 再交付。Playwright 可用 npx playwright 调用，或按本机全局安装路径（npm root -g + /playwright）。
没有 design system 时默认往这些方向走，避免撞 AI slop：
| 维度 | 首选 | 避免 |
|---|---|---|
| 字体 | 衬线 display（Newsreader/Source Serif/EB Garamond）+ -apple-system body | 全场 SF Pro 或 Inter——太像系统默认，没风格 |
| 色彩 | 一个有温度的底色 + 单个 accent 贯穿全场（rust 橙/墨绿/深红） | 多色聚类（除非数据真的有 ≥3 个分类维度） |
| 信息密度·克制型（默认） | 少一层容器、少一个 border、少一个装饰性 icon——给内容留气口 | 每条卡片都配无意义的 icon + tag + status dot |
| 信息密度·高密度型（例外） | 当产品核心卖点是「智能 / 数据 / 上下文感知」时（AI 工具、Dashboard、Tracker、Copilot、番茄钟、健康监测、记账类），每屏需至少 3 处可见的产品差异化信息：非装饰性数据、对话/推理片段、状态推断、上下文关联 | 只放一个按钮一个时钟——AI 的智能感没表达出来，跟普通 App 没区别 |
| 细节签名 | 留一处「值得截图」的质感：极淡油画底纹 / serif 斜体引语 / 全屏黑底录音波形 | 到处平均用力，结果处处平淡 |
两条原则同时生效：
assets/ios_frame.jsx——禁止手写 Dynamic Island / status bar做 iPhone mockup 时硬性绑定 assets/ios_frame.jsx。这是已经对齐过 iPhone 15 Pro 精确规格的标准外壳：bezel、Dynamic Island（124×36、top:12、居中）、status bar（时间/信号/电池、两侧避让岛、vertical center 对齐岛中线）、Home Indicator、content 区 top padding 都处理好了。
禁止在你的 HTML 里自己写以下任何一项：
.dynamic-island / .island / position: absolute; top: 11/12px; width: ~120; 居中的黑圆角矩形.status-bar with 手写的时间/信号/电池图标.home-indicator / 底部 home bar自己写 99% 会撞位置 bug——status bar 的时间/电池被岛挤压、或 content top padding 算错导致第一行内容盖在岛下。iPhone 15 Pro 的刘海是固定 124×36 像素，留给 status bar 两侧的可用宽度很窄，不是你凭空估的。
用法（严格三步）：
// 步骤 1: Read 本 skill 的 assets/ios_frame.jsx（相对本 SKILL.md 的路径）
// 步骤 2: 把整个 iosFrameStyles 常量 + IosFrame 组件贴进你的 <script type="text/babel">
// 步骤 3: 你自己的屏组件包在 <IosFrame>...</IosFrame> 里，不碰 island/status bar/home indicator
<IosFrame time="9:41" battery={85}>
<YourScreen /> {/* 内容从 top 54 开始渲染，下边留给 home indicator，你不用管 */}
</IosFrame>
例外：只有用户明确要求「假装是 iPhone 14 非 Pro 的刘海」「做 Android 不是 iOS」「自定义设备形态」时才绕过——此时读对应 android_frame.jsx 或修改 ios_frame.jsx 的常量，不要在项目 HTML 里另起一套 island/status bar。
理解需求：
WebSearch 验证其存在性、发布状态、最新版本、关键规格。把事实写入 product-facts.md。详见「核心原则 #0」。这步做在问 clarifying questions 之前——事实错了问什么都歪。references/workflow.md。一次focused一轮问题通常够，小修小补跳过。references/editable-pptx.md 的 4 条硬约束写，事后补救会导致 2-3 小时返工。详见 references/slide-decks.md 开头「开工前先确认交付格式」一节。探索资源 + 抽核心资产（不只是抽色值）：读 design system、linked files、上传的截图/代码。涉及具体品牌时必走 §1.a「核心资产协议」五步（问→按类型搜→按类型下载 logo/产品图/UI→验证+提取→写 brand-spec.md 含所有资产路径）。
references/design-context.md 的品位锚点兜底。先答四问，再规划系统：这一步的前半段比所有 CSS 规则更决定输出。
📐 位置四问（每个页面/屏幕/镜头开工前必答）：
四问答完再 vocalize 设计系统（色彩/字型/layout 节奏/component pattern）——系统要服务于答案，不是先选系统再塞内容。
🛑 检查点2：四问答案 + 系统口头说出来等用户点头，再动手写代码。方向错了晚改比早改贵 100 倍。
构建文件夹结构：项目名/ 下放主HTML、需要的assets拷贝（不要bulk copy >20个文件）。
Junior pass：HTML里写assumptions+placeholders+reasoning comments。 🛑 检查点3：尽早show给用户（哪怕只是灰色方块+标签），等反馈再写组件。
Full pass：填placeholder，做variations，加Tweaks。做到一半再show一次，不要等全做完。
检查点原则：碰到🛑就停下，明确告诉用户"我做了X，下一步打算Y，你确认吗？"然后真的等。不要说完自己就开始做。
必问（用references/workflow.md里的模板）：
流程假设用户配合、环境正常。实操常遇以下异常，预定义fallback：
| 场景 | 触发条件 | 处理动作 |
|---|---|---|
| 需求模糊到无法着手 | 用户只给一句模糊描述（如"做个好看的页面"） | 主动列3个可能方向让用户选（如"落地页 / Dashboard / 产品详情页"），而不是直接问10个问题 |
| 用户拒绝回答问题清单 | 用户说"不要问了，直接做" | 尊重节奏，用best judgment做1个主方案+1个差异明显的变体，交付时明确标注assumption，方便用户定位要改哪里 |
| Design context矛盾 | 用户给的参考图和品牌规范打架 | 停下，指出具体矛盾（"截图里字体是衬线，规范说用sans"），让用户选一个 |
| Starter component加载失败 | 控制台404/integrity mismatch | 先查references/react-setup.md常见报错表；还不行降级纯HTML+CSS不用React，保证产出可用 |
| 时间紧迫要快交付 | 用户说"30分钟内要" | 跳过Junior pass直接Full pass，只做1个方案，交付时明确标注"未经early validation"，提醒用户质量可能打折 |
| SKILL.md体积超限 | 新写HTML>1000行 | 按references/react-setup.md的拆分策略拆成多jsx文件，末尾Object.assign(window,...)共享 |
| 克制原则 vs 产品所需密度冲突 | 产品核心卖点是 AI 智能 / 数据可视化 / 上下文感知（如番茄钟、Dashboard、Tracker、AI agent、Copilot、记账、健康监测） | 按「品位锚点」表格走高密度型信息密度：每屏 ≥ 3 处产品差异化信息。装饰性 icon 照样忌讳——加的是有内容的密度，不是装饰 |
原则：异常时先告诉用户发生了什么（1句话），再按表处理。不要静默决策。
| 类别 | 避免 | 采用 |
|---|---|---|
| 字体 | Inter/Roboto/Arial/系统字体 | 有特点的display+body配对 |
| 色彩 | 紫色渐变、凭空新颜色 | 品牌色/oklch定义的和谐色 |
| 容器 | 圆角+左border accent | 诚实的边界/分隔 |
| 图像 | SVG画人画物 | 真实素材或placeholder |
| 图标 | 装饰性 icon 每处都配（撞 slop） | 承载差异化信息的密度元素必须保留——不要把产品特色也一并减掉 |
| 填充 | 编造stats/quotes装饰 | 留白，或问用户要真内容 |
| 动画 | 散落的微交互 | 一次well-orchestrated的page load |
| 动画-伪chrome | 画面内画底部进度条/时间码/版权署名条（与 Stage scrubber 撞车） | 画面只放叙事内容，进度/时间交给 Stage chrome（详见 references/animation-pitfalls.md §11） |
React+Babel+Tailwind项目必须用pinned版本（见react-setup.md）。默认引入 Tailwind CSS（https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4），只有用户明确要求「不要 Tailwind」「用普通样式」时才省略。三条不可违反：
const styles = {...}——多组件时命名冲突会炸。必须给唯一名字：const terminalStyles = {...}<script type="text/babel">之间组件不通，必须用Object.assign(window, {...})导出scrollIntoView——会搞坏容器滚动，用其他DOM scroll方法固定尺寸内容（幻灯片/视频）必须自己实现JS缩放，用auto-scale + letterboxing。
幻灯片架构选型（必先决定）：
assets/deck_index.html拼接器assets/deck_stage.js web component先读 references/slide-decks.md 的「🛑 先定架构」一节，错了会反复踩 CSS 特异性/作用域的坑。
造好的起手组件，直接copy进项目使用：
| 文件 | 何时用 | 提供 |
|---|---|---|
deck_index.html | 做幻灯片（默认，多文件架构） | iframe拼接 + 键盘导航 + scale + 计数器 + 打印合并，每页独立HTML免CSS串扰 |
deck_stage.js | 做幻灯片（单文件架构，≤10页） | web component：auto-scale + 键盘导航 + slide counter + localStorage + speaker notes ⚠️ script 必须放在 </deck-stage> 之后，section 的 display: flex 必须写到 .active 上，详见 references/slide-decks.md 的两个硬约束 |
scripts/export_deck_pdf.mjs | HTML→PDF 导出（多文件架构） · 每页独立 HTML 文件，playwright 逐个 page.pdf() → pdf-lib 合并。文字保留矢量可搜。依赖 playwright pdf-lib | |
scripts/export_deck_stage_pdf.mjs | HTML→PDF 导出（单文件 deck-stage 架构专用） · 2026-04-20 新增。处理 shadow DOM slot 导致的「只出 1 页」、absolute 子元素溢出等坑。详见 references/slide-decks.md 末节。依赖 playwright | |
scripts/export_deck_pptx.mjs | HTML→PPTX 导出（双模式） · --mode image 图片铺底视觉 100% 保真但文字不可编辑；--mode editable 调 html2pptx.js 导出原生可编辑文本框，但 HTML 必须符合 4 条硬约束（见 references/editable-pptx.md）。依赖 playwright pptxgenjs（editable 模式还需 sharp） | |
scripts/html2pptx.js | HTML→PPTX 元素级翻译器 · 读 computedStyle 把 DOM 逐元素翻译成 PowerPoint 对象（text frame / shape / picture）。export_deck_pptx.mjs --mode editable 内部调用。要求 HTML 严格满足 4 条硬约束 | |
design_canvas.jsx | 并排展示≥2个静态variations | 带label的网格布局 |
animations.jsx | 任何动画HTML | Stage + Sprite + useTime + Easing + interpolate |
ios_frame.jsx | iOS App mockup | iPhone bezel + 状态栏 + 圆角 |
android_frame.jsx | Android App mockup | 设备bezel |
macos_window.jsx | 桌面App mockup | 窗口chrome + 红绿灯 |
用法：读取对应 assets 文件内容 → inline 进你的 HTML <script> 标签 → slot 进你的设计。
触发条件：用户在需求确认阶段回答「是否需要生成 DESIGN.md」时选择「是」。 不触发的场景：纯动画任务、纯幻灯片任务、用户明确说"不需要"、HTML 仍含大量 placeholder 未完成。
读取 references/design-md-spec.md 了解完整输出格式和质量标准
从 HTML 代码反向提取 token（不凭记忆，必须实际读代码）：
grep -hoE '#[0-9A-Fa-f]{6}' <html文件> 按频次排序，过滤黑白灰，映射语义角色<link> 标签和 font-family 提取字体栈，按字号层级推断 display / body / monoborder-radius 和 rounded-* Tailwind classes 提取使用频次合并 brand-spec.md 信息（如存在）：
name + Section 1 标题按 9 section 模板填充，每个 section 基于实际设计决策描述，不写空话
写入 DESIGN.md 到项目目录（与 HTML 文件同级，不要写到 assets/ 或 ~/Downloads）
不达标 → 重新提取 token / 补充 section，直到达标。
根据任务类型深入读对应references：
| 任务 | 读 |
|---|---|
| 开工前问问题、定方向 | references/workflow.md |
| 反AI slop、内容规范、scale | references/content-guidelines.md |
| React+Babel+Tailwind项目setup | references/react-setup.md（含样式策略：默认 Tailwind，用户要求时用普通样式） |
| 做幻灯片 | references/slide-decks.md + assets/deck_stage.js |
| 导出可编辑 PPTX（html2pptx 4 条硬约束） | references/editable-pptx.md + scripts/html2pptx.js |
| 做动画/motion（先读 pitfalls） | references/animation-pitfalls.md + references/animations.md + assets/animations.jsx |
| 动画的正向设计语法（Anthropic 级叙事/运动/节奏/表达风格） | references/animation-best-practices.md（5 段叙事+Expo easing+运动语言 8 条+3 种场景配方） |
| 做Tweaks实时调参 | references/tweaks-system.md |
| 没有design context怎么办 | references/design-context.md（薄 fallback） 或 references/design-styles.md（厚 fallback：20 种设计哲学详细库） |
| 需求模糊要推荐风格方向 | references/design-styles.md（20 种风格+AI prompt 模板）+ assets/showcases/INDEX.md（24 个预制样例） |
| 按输出类型查场景模板（封面/PPT/信息图） | references/scene-templates.md |
| 生成 DESIGN.md（设计系统规范，可选） | references/design-md-spec.md |
| 输出完后验证 | references/verification.md + scripts/verify.py |
| 设计评审/打分（设计完成后可选） | references/critique-guide.md（5 维度评分+常见问题清单） |
| 动画导出MP4/GIF/加BGM | references/video-export.md + scripts/render-video.js + scripts/convert-formats.sh + scripts/add-music.sh |
| 动画加音效SFX（苹果发布会级，37个预制） | + |
本 skill 设计为 agent-agnostic——Claude Code、Codex、Cursor、Trae、OpenClaw、Hermes Agent 或任何支持 markdown-based skill 的 agent 都可以使用。以下是和原生「设计型 IDE」（如 Claude.ai Artifacts）对比时的通用差异处理方式：
scripts/verify.py（Playwright 封装）人工驱动验证references/tweaks-system.mdwindow.claude.complete 免配置 helper：若 HTML 里要调 LLM，用一个可复用的 mock 或让用户填自己的 API key，详见 references/react-setup.mdreferences/workflow.md 的模板Skill 路径引用均采用相对本 skill 根目录的形式（references/xxx.md、assets/xxx.jsx、scripts/xxx.sh）——agent 或用户按自身安装位置解析，不依赖任何绝对路径。
Landing Page.html、iOS Onboarding v2.htmlMy Design.html → My Design v2.html~/Downloads只在动画产出（HTML 动画 → MP4 / GIF）默认带「Created by Design」水印，辅助 skill 传播。幻灯片 / 信息图 / 原型 / 网页等其他场景不加——加了反而干扰用户实际使用。
<div style={{
position: 'absolute', bottom: 24, right: 32,
fontSize: 11, color: 'rgba(0,0,0,0.4)' /* 深底用 rgba(255,255,255,0.35) */,
letterSpacing: '0.15em', fontFamily: 'monospace',
pointerEvents: 'none', zIndex: 100,
}}>
Created by Design
{/* 第三方品牌动画前缀「非官方出品 · 」*/}
</div>
<script type="text/babel">，Tailwind CDN 引入，双击就能开。用户明确说不用 React 时才降级。WebSearch 验证存在性和状态，不凭训练语料断言。references/animation-pitfalls.md——里面 14 条规则每条都来自真实踩过的坑，跳过会让你重做 1-3 轮。assets/animations.jsx）：必须实现两件事——(a) tick 第一帧同步设 window.__ready = true (b) 检测 window.__recording === true 时强制 loop=false。否则录视频必出问题。references/design-md-spec.md 的 9 section + YAML frontmatter 模板生成，写入项目根目录。验证：用Playwright截图（见 references/verification.md），检查控制台错误，发给用户。
🛑 检查点4：交付前自己肉眼过一遍浏览器。AI写的代码经常有interaction bug。
总结：极简，只说caveats和next steps。
（默认）导出视频 · 必带 SFX + BGM：动画 HTML 的默认交付形态是带音频的 MP4，不是纯画面。无声版本等于半成品——用户潜意识感知「画在动但没声音响应」，廉价感的根源就在这里。流水线：
scripts/render-video.js 录 25fps 纯画面 MP4（只是中间产物，不是成品）scripts/convert-formats.sh 派生 60fps MP4 + palette 优化 GIF（视平台需要）scripts/add-music.sh 加 BGM（6 首场景化配乐：tech/ad/educational/tutorial + alt 变体）references/audio-design-rules.md 设计 cue 清单（时间轴 + 音效类型），用 assets/sfx/<category>/*.mp3 37 个预制资源，按配方 A/B/C/D 选密度（发布 hero ≈ 6个/10s，工具演示 ≈ 0-2个/10s）ffprobe -select_streams a 确认有 audio stream，没有则不是成品references/video-export.md + references/audio-design-rules.md + references/sfx-library.md。（可选）专家评审：用户若提「评审」「好不好看」「review」「打分」，或你对产出有疑问想主动质检，按 references/critique-guide.md 走 5 维度评审——哲学一致性 / 视觉层级 / 细节执行 / 功能性 / 创新性各 0-10 分，输出总评 + Keep（做得好的）+ Fix（严重程度 ⚠️致命 / ⚡重要 / 💡优化）+ Quick Wins（5 分钟能做的前 3 件事）。评审设计不评设计师。
（可选）生成 DESIGN.md：用户在需求确认阶段选择「是」时，在 HTML 验证通过后执行。详见下方「工作流末尾 · 生成 DESIGN.md」section。
browser_window.jsx | 网页在浏览器里的样子 | URL bar + tab bar |
references/sfx-library.mdassets/sfx/<category>/*.mp3| 动画音频配置规则（SFX+BGM双轨制、黄金配比、ffmpeg模板、场景配方） | references/audio-design-rules.md |
| Apple画廊展示风格（3D倾斜+悬浮卡片+缓慢pan+焦点切换，v9实战同款） | references/apple-gallery-showcase.md |
| Gallery Ripple + Multi-Focus 场景哲学（当素材 20+ 同质+场景需表达「规模×深度」时优先用；含前置条件、技术配方、5 个可复用模式） | references/hero-animation-case-study.md（design hero v9 蒸馏） |