需要从品牌规范与真实产品截图生成 App Store…

当用户要 App Store / iOS 商店截图素材（有 brand.md、产品截图或公开 App Store 链接）时，按 hook→value→feature→proof→close 叙事生成 5–6 张可直接上传 App Store Connect 的截图。

适用场景

解决思路

1. 付费调用前先调用 identity_balance({verbose: true}) 一次，展示余额、近期消耗速率与剩余额度，并用固定话术告知预估成本（典型 5–6 屏约 150–300 credits / $1.50–$3.00），等用户回复 proceed 才继续；回复 cancel 则停止；非交互的 --quick/--config 调用需在配置中带 cost_ack=proceed，否则只输出预估并停止。
2. 交付物为 5 或 6 张编号 PNG，保存到 ~/Desktop/[app-name]-app-store-screens/：01_hook.png、02_value.png、03_feature_a.png、04_feature_b.png、05_proof.png、06_close.png（可选），外加一张 _preview.png 联系表（3×2 网格缩略图）。
3. Step 0 收集输入：若参数为空且无可用品牌/截图/演示上下文，原样打印菜单并停止；必需输入为 brand.md 或等价品牌规范（名称、色板、字体、语气、图像方向），以及一个产品来源（原始截图、可导出的 Figma/源文件、或可经 Pika MCP 抓取的 App Store URL/应用名）；虚构发布演示需 demo_mode: true 加 demo_brief。交互模式下只追问缺失项并停止。
4. Step 0.5 非交互快速通道：当传入 --quick 或 --config <path>，或调用方声明来自 CI、子代理、批处理等非交互环境时启用，优先级高于交互式询问；--config 指向含 brand_spec、product_screenshots、app_store_url、website_url、reference、style、screen_count、narrative_arc、demo_mode、demo_brief、output_folder 的 JSON；--quick 表示默认风格、自行推断品牌、自行拟定 5–6 屏叙事并继续；不在风格选择、品牌复述、参考规则复述、策略提案处停下确认，改为内联记录假设后继续；若既无真实截图也无 demo_mode: true 加 demo_brief，只停一次并给出紧凑的缺失字段列表。
5. 虚构应用演示模式：仅当调用方明确说明是虚构/概念/发布演示或配置 demo_mode: true 时启用；需 demo_brief 或足够的产品概念细节（核心用途、受众、3–5 个功能、证明/CTA 角度）；生成的 UI 状态须与 brief 自洽，不得暗示真实客户、评价、指标或集成；交付说明与联系表标注“Demo UI concept — not production assets and not real product screenshots.”；非交互模式下配置未设 demo_mode: true 且无 demo_brief 则停止。
6. 交互模式下开场给出简短流程说明，并只问一个前置风格问题：默认风格（干净克制、截图原样呈现、全幅设备、标题+副标题在上、纯品牌色背景，见 references/default-layout.md）还是指定参考（App Store 页面截图、Figma 文件、moodboard）；未指定则用默认。不要自动做“花哨”风格，因为缺少参考时的自由发挥往往显得业余。
7. Step 1 读取品牌与产品：若产品来源是 apps.apple.com URL、数字 App Store ID 或应用名搜索词，优先调用 Pika MCP fetch_appstore_screens(query, country: "us", max_screens: 10, include_icon: true)，用返回的 metadata、icon、screenshots 作为产品来源，返回的 url 已是 Pika 托管的 HTTPS 资源可直接用于后续 html_to_png；用户给了特定国家 URL 就保留该 storefront，不明确则默认 "us"；MCP 不可用或无截图时说明情况，改用其他读取/抓取工具、官方 App Store/iTunes 元数据端点或用户提供的截图，不得凭空编造产品 UI。
8. 对每张抓取或用户提供的源截图分类并记录 source_treatment：clean_ui_capture（可直接嵌入设备 mockup 的原始 UI）、composed_marketing（已完成的营销屏，如 2025 Notion 列表：已烘焙标题、手机出血、背景已是活动美术、本身就是成品 1290×2796）、legacy_footer_cleanup（仅需清理列表品牌页脚/水印的干净 UI）。
9. 若源为 composed_marketing，不要重新套设备 mockup，也不要在已烘焙标题上再加生成标题；优先改用 clean_ui_capture（对产品网站/引导页/Web 应用调用 capture_website，或索取模拟器/Figma/原始 UI 导出）；无干净 UI 时用 source_treatment=composed_passthrough，原样呈现并只做最小交付框定、编号或联系表标注；不要靠裁掉底部 6–8% 来修复 composed 源。
10. 对干净的旧版源截图，检查底部水印或列表品牌页脚（如 R4 Notion 列表底部裸露的 “NOTION · NOTES, TASKS, AI”）；若存在，嵌入设备前裁掉或遮罩底部 6–8%。
11. 使用带自身几何定义的截图包装器并锚定源图顶部，不要依赖 height:100%（除非设备到父级每层都有显式高度）：<div class="source-screen-crop source-screen-crop--phone" style="width:100%; aspect-ratio:1290 / 2796; overflow:hidden; position:relative;"><img src="s://screen01" style="width:100%; height:calc(100% / 0.92); object-fit:cover; object-position:top center; display:block;"></div>；若裁 8% 会切掉真实 UI，改用品牌色渐变遮罩底部页脚，但仍须在进入最终设备 mockup 前去除水印。
12. 处理 Mac 或混合应用截图：fetch_appstore_screens 可能返回横版 Mac 截图（如 1290×806）而非 iPhone 竖版（1290×2796），如 Things 3、Drafts、Numbers、Day One、OmniFocus、BBEdit；判定规则为 aspect_ratio_w > aspect_ratio_h，或仅有像素尺寸时 width > height：mac_shots = [s for s in screenshots if s.aspect_ratio_w > s.aspect_ratio_h]（等价 mac_shots = [s for s in screenshots if s.width > s.height]）；若 mac_shots 非空，改用 references/mac-app-layout.md 的嵌入卡片布局，把每张横版截图作为圆角 UI 卡片嵌入 1290×2796 竖版画布，不要裁进 iPhone 框、不要加黑边、不要当全幅设备；Mac 卡片同样要检查列表品牌页脚/水印，用 source-screen-crop--mac 保持横版比例，必要时在卡片内做窄底遮罩/渐变或小幅保比例底部裁剪。
13. 薄列表护栏：fetch_appstore_screens 后统计展示真实产品 UI 的可用截图数，少于 3 张即视为薄列表；不得靠幻觉 UI 凑 5–6 屏。交互模式在策略前停下并给两个选项：1) 网站抓取路径——用 capture_website 或提供的网站/引导 URL 抓取真实产品界面后继续；2) 真实截图路径——索取模拟器导出、Figma 帧或其他产品 UI 截图。不得为真实产品合成设备 UI；用户明确转向虚构发布/概念演示时，走虚构应用演示模式并要求 demo_mode: true 加 demo_brief。非交互快速通道：有 website_url 或明显产品网站时优先网站抓取路径；无可抓取界面时只停一次并给紧凑缺失字段列表，除非配置显式 demo_mode: true 且提供 demo_brief。
14. 抓取后仅从列表与视觉推断草稿品牌解读：应用名、类别、可见色板、可能的字体方向、来自副标题/描述的语气、显著 UI 时刻；交互模式作为临时品牌规范复述并请用户纠正后再提 5–6 屏叙事；非交互快速通道记录为临时品牌规范并继续。
15. 参考驱动路径：参考决定布局/风格长什么样，品牌决定用什么颜色/字体/语气/摄影；从参考提取结构规则——设备尺寸（占画布百分比）与倾角、标题处理（字号、位置、颜色逻辑、关键词强调、底色药丸）、背景处理（纯色、照片、渐变、抽象元素）、主视觉模式（手持手机、过肩、真人破屏、3D 物体漂浮）、标注/引出模式（带箭头气泡、浮动卡片、拍立得框）、重复规则（每屏同布局还是逐屏变化）；从品牌套用具体项——色板（替换参考中的纯色块）、字体（替换所有排版）、语气（用品牌语气重写全部标题/副标题，不抄参考文案）、摄影方向（生成图像遵循品牌摄影规则）、情绪（温暖 vs 冷静、俏皮 vs 专业）。
16. 生成主视觉时把参考作为 images 传给 gpt-image-2 的 generate_image_edit（最多 16 张参考图），用于参考有独特照片构图（手持手机、过肩、人物破屏、3D 角色浮现）时；提示词示例：“In the EXACT composition and lighting style of the reference image — hand holding a phone at the same angle and scale — but render the subject and scene per [BRAND] photography rules: documentary 35mm, golden hour window light, real apartment, butter-yellow ceramic mug visible, mid-30s mixed-race cast, 35mm film grain. Vertical 9:16 portrait.”——这样只迁移参考的风格而非内容。
17. 交互模式在动手设计前把提取的规则以短列表形式复述给用户确认（如“设备占画布 75% 倾斜 -8°，标题在黄色药丸上位于设备上方，过肩主视觉，墨色标注带弧形箭头”）；非交互快速通道内联记录规则并继续；随后 6 屏一致套用这些规则，中途不偏离。
18. 实际读取 brand.md：提取品牌名、标语、色板（含 hex）、展示字体与正文字体、语气形容词、语气示例、禁用词、摄影/插画方向、情绪词；若为其他格式（PDF、纯笔记）则解析现有内容，交互模式追问缺口，非交互快速通道对非关键缺口记录合理假设，不要凭空造品牌。
19. 打开每张产品截图形成诚实的产品理解：这个应用到底做什么？记录核心 UI 模式（信息流、聊天、画布、列表、地图等）、主要操作面、以及“哇时刻”屏幕（生成结果、漂亮状态、独特交互）；可用 analyze_media 快速扫描截图而不必作为图像加载。
20. 用 3–5 行对话式复述发现：“ok — reading [brand name]: [tagline]. palette: [colors]. voice: [adjectives]. the app looks like it does [X] — i see [specific UI cue 1] and [specific UI cue 2]. the standout screen is [screen N] because [reason]. correct me where i'm wrong, otherwise i'll pitch the 6-screen arc.”；交互模式等确认后再提策略，非交互快速通道视为临时解读、内联记录假设并继续。
21. Step 2 设计前先用纯文本写出 6 屏叙事弧，每屏包含：角色（hook/value/feature/proof/close）、标题（5–8 词、品牌语气）、可选副标题（一行）、布局原型（命名即可，先不画）、所配原始截图文件名（或“无，全幅排版”）、仅证明屏需要的可见证明物（星级行、Editors' Choice 徽章、用户评价卡、评论数标签、奖项徽章或其他有来源的视觉证明，证明屏不得纯文字）。按“**Screen 1 — HOOK** / Headline: ... / Sub: ... / Layout: ... / Featured screenshot: ...”格式呈现。
22. 交互模式在生成或合成前请用户签署叙事弧，文案在此阶段迭代最便宜；非交互快速通道按配置或推断的叙事弧直接生成，不停下等签署。
23. 证明屏规则：必须有可见证明物而非仅一句主张；不得只放“Loved by millions...”之类纯文字社交证明；若 App Store 列表或品牌规范提供真实证明，以星级行、Editors' Choice 徽章、评价卡、评论数标签、奖项徽章或有来源的引用卡可见呈现；若无真实证明，把证明节拍做成由产品截图支撑的视觉差异化点，不得编造评价、奖项、评分或用户数。
24. Step 3 为需要花哨背景/主视觉的屏幕用 generate_image（或按参考驱动路径传参考图时用 generate_image_edit）生成品牌世界图像；默认 provider: gpt-image-2、quality: medium（仅用户明确要快速迭代时用 low）、aspect_ratio: 9:16（匹配 iPhone 画布）、默认 1K；若某屏确实需要更高分辨率（如被放大的超精细背景），把 gpt-image-2 升到 2K/4K 档（9:16 背景支持）或升级到 seedream，并先说明取舍再询问。
25. 品牌世界图像提示词结构：1) 主体+构图（“a wide cinematic shot of a single ceramic mug on weathered oak…”）；2) 以命名颜色给出品牌色板（“limited to ink black #0E0E10, oat #F5F0E6, and a single accent of rust #C84B2F”）；3) 光线+情绪（“soft overcast window light, slight film grain, documentary feel”）；4) 负面提示（“no text, no logos, no people unless specified, no stock-photo gloss”）；5) 9:16 背景加“vertical composition with negative space in upper third for headline”；明确告诉模型标题将放在上方以留出空间。
26. 生成图像保留 HTTPS/CDN URL 供服务端渲染；用户提供的本地产品截图或背景图先用 upload_asset 上传并使用返回的 public_url（html_to_png 无法读取本地 file:// 路径）；当某阶段重复出现长 CDN URL 时，在 HTML/CSS 中用短 token（如 s://screen01）并通过 short_link_map 传完整 URL；含空白或缺 https:// 的畸形资源 URL 会在渲染前被拒。
27. Step 4 每屏写一个 HTML 阶段，再用 Pika MCP html_to_png 渲染为 PNG；参见 references/render-pipeline.md 获取 html_to_png 请求结构、服务端资源/字体规则、安全区参考线与常见坑（字体加载、retina 文字锐度、曲线中段裁剪）。
28. 每个 HTML 阶段精确为 1290×2796px；用 @font-face 配 fonts.gstatic.com 的 WOFF2 字体文件直链或内联 data:font/... 源；不要在渲染 HTML 里用 GitHub raw 的 Google Fonts 链接（可能以 text/html 返回而无法通过字体 MIME 白名单）；本地品牌字体文件须通过公开 HTTPS URL 暴露或内联（upload_asset 不接受字体 MIME）；可复制粘贴的 Google Fonts 片段见 references/fonts.md。
29. 对 CJK 或其他非拉丁应用名、标题、评价或 UI 标签，每个 CSS font-family 栈都要加广泛文字回退，如 "Noto Sans SC", "Noto Sans TC", "Noto Sans JP", "Noto Sans KR", "Noto Sans Arabic", system-ui, sans-serif；Chromium 会对支持的拉丁字形用品牌字体、对缺失文字逐字回退，避免豆腐块。
30. 深色背景使用深色模式副标题 token，而非复用中灰：用 --subhead-on-dark: #B5B4B0 或品牌色板中同等浅中性色且全不透明；绝不在近黑背景上用 #787774 类灰，也绝不用浅色背景的 opacity: 0.7–0.75 规则压暗深色 token；#787774 类灰仅用于浅色背景；标题可翻成奶油/白色，但副标题也必须翻成可读的深色模式颜色。
31. 每次渲染后、接受 PNG 前做交付前 QA：对渲染图调用 analyze_media，并在可用时检查作者 HTML 位置；任何把承重标题、眉题、副标题、CTA 或产品 UI 放到 references/render-pipeline.md 所述安全内容区之外的屏幕，一律拒绝并重渲。
32. Step 5 全部 6 张干净渲染后：1) 用 html_to_png 构建 _preview.png 联系表——6 张缩略图 3×2 网格、约 25% 尺寸、中性背景、按角色标注；2) 展示联系表 URL 及每张截图的 file_url，若另存了本地副本则单独给出本地路径；3) 询问是否修改（文案调整便宜、布局更换中等、新图像最贵）。在 _preview.png 存在并纳入交付前，不得宣称截图集完成；联系表渲染失败就先修联系表 HTML 或重渲缺失 PNG，不得只交付单张 PNG 就收工。
33. 交付前质量门：对 _preview.png 联系表调用 analyze_media 做活动级多样性检查，再对含证明文案、深色背景或预处理源截图的屏幕以全分辨率单张 PNG 检查；25% 联系表太小，无法单独验证页脚水印渗出、深色背景副标题对比度、精细证明物或 composed-marketing 源的双标题失败。
34. 必须做全分辨率单张 PNG 检查的屏幕：证明屏；所有近黑/深色背景屏；所有嵌入可能带列表品牌页脚文字的抓取或用户源截图的屏；所有 source_treatment=composed_passthrough 或分类为 composed_marketing 的源；所有使用 mac_shots 的 Mac 横版卡片屏。
35. 联系表结构化判定提示词：Return JSON only: { "verdict": "clean" | "degraded" | "catastrophic", "observations": string[], "quality_warning": string | null, "re_roll_suggestion": string | null }；检查联系表是否展示所有请求的截图、App Store 安全区是否遵守、产品 UI 是否可读、标题在缩略图尺度是否清晰、生成文字是否乱码。
36. 单张渲染 PNG 判定提示词：Return JSON only: { "proof_artifact_visible": boolean | null, "dark_subhead_contrast_ok": boolean | null, "footer_watermark_bleed_visible": boolean, "composed_source_double_headline_visible": boolean | null, "mac_card_preserves_landscape_ui": boolean | null, "verdict": "clean" | "degraded" | "catastrophic", "observations": string[], "re_roll_suggestion": string | null }；在可读分辨率下检查：证明屏须含可见证明物（星级行、Editors' Choice 徽章、评价卡、评论数标签、奖项徽章或有来源引用卡）；深色背景副标题须用浅色深色模式 token 且可读；源截图与 Mac 卡片不得出现页脚水印渗出或列表品牌页脚杂乱；composed-marketing 源须确认没有在已烘焙标题上叠加生成标题、也没有额外设备 mockup 包裹源图。
37. 按判定处理：clean 则交付联系表加单张 PNG URL；degraded 则交付 URL 并附 quality_warning 供用户发布前审阅；catastrophic 则不得称活动完成，改为给出判定与 re_roll_suggestion；若证明屏缺可见证明物、深色背景副标题对比度低、源截图页脚水印渗出仍可见、或 composed_source_double_headline_visible 为 true，至少按 degraded 处理并在正常交付前重渲受影响屏幕；composed 源同时有烘焙标题和生成标题时不得称活动完成。
38. 每屏使用 5 种布局原型之一，不要堆叠设备，每屏一个大胆想法（完整 CSS 骨架见 references/layout-archetypes.md）：1) Floating device——倾斜手机置于花哨背景，主力，适合价值/功能屏；2) Full-bleed UI——手机画布充满画面，排版叠在顶部或底部，适合 hook；3) Side-by-side——一侧设备、另一侧生成的生活方式图像，适合情感功能；4) Parallax stack——手机在前、品牌形状/图像漂浮在后，适合“哇时刻”功能屏；5) Quote card——大号引用配角落小设备，适合证明屏。
39. 文案不可妥协：标题 5–8 词；严格贴合品牌语气（brand.md 说“dry, deadpan, never exclamatory”就绝不加感叹号；说“warm and a little teasing”就要有节奏）；做主张而非描述（“Sleep like you mean it” 优于 “Track your sleep”，“Built for one quiet hour a day” 优于 “Productivity app”）；前两屏要能独立当缩略图（更大字号、最清晰钩子，App Store 搜索只展开前 2–3 张）。
40. 禁用文案（App Store 版的“crafted with love”）：“Stay organized.”、“Your daily companion.”、“All-in-one [category].”、“Designed to help you [verb].”、“Track. Plan. Achieve.”，以及任何含 seamlessly、effortlessly、powerful、smart、intelligent 的表述；若标题放在 500 个其他应用上也没人察觉，就重写。
41. 视觉标准：设备是主角、文字是说明——1290×2796 画布上设备宽 1050–1150px（约画布 81–89%），更小显得胆怯；排版层级每屏一个主导（通常是设备），标题 100–140px Funnel-Display 级、副标题 36–44px，字重与字号有明显差异（超过 150px 标题会与设备抢眼）。
42. 不要用 SVG 描边 iPhone 框（描边半内半外、圆角与灵动岛比例对不上真实 iPhone）；优先用 Figma/模拟器导出的透明截图或带透明挖空的真实 iPhone mockup PNG；若只有矩形源截图，用一致的 CSS border-radius + overflow:hidden 包装并目视 QA 圆角；旧的本地 clean_phone_uniform() PIL 方案现为已记录的 MCP 缺口，不作为默认依赖。
43. 二选一：出血或全幅，绝不中段裁底部曲线；默认全幅（设备顶部 y=580、宽 1000，圆角底完全在画布内、下方留约 48px 呼吸空间）；出血变体（设备顶部 ≥ 819）把圆角底完全推过 y=2796，适合想要戏剧性的 hook 屏；介于两者之间会出现画布从圆角弧中段切过的可见半切曲线，这正是该规则要避免的失败模式。
44. Apple 安全区：严格规则——承重文字与产品 UI 必须留在 y=180..2616 内；顶部和底部 100px 带永不用于关键内容，额外 80px 缓冲避免 App Store 界面元素、搜索结果裁剪和文字上伸部挤到边缘；装饰可以，关键主张和可读应用 UI 不行。
45. 每屏一个大胆设备；大字号、生成图像、引用三者只选其一，花哨 ≠ 混乱；颜色只用品牌色板，不为截图发明新颜色（若色板太受限，那是品牌要解决的问题，不是你的）。
46. 截图来源：原始截图可来自 Pika MCP 抓取的 App Store 列表、Figma 帧、Sketch 导出、模拟器截图或本地文件；若来源是 App Store URL/应用 ID/应用名，走上面的 App Store 列表路径；若来源是 Figma 且有 Figma MCP 访问权限：get_screenshot(fileKey, nodeId) 返回节点渲染 PNG（无需用户在 Figma 桌面端选中任何东西）；一排手机布局优先索取单机导出，若只有整排则从设计源手动裁剪或等未来服务端裁剪/清理工具，不要把本地 PIL 裁剪作为本技能默认依赖；自然渲染通常是逻辑像素尺寸（如 iPhone 15 Pro 每台 393×852），放大到默认 1000px 设备宽对非像素关键内容可接受，更高保真需索取更高分辨率导出。
47. 交付前做眯眼测试：1) 眯眼看联系表——6 屏能否一眼区分（不同标题、布局、视觉重心）？若像同一屏的 6 个版本就重设计；2) 前两屏缩略图测试——裁到 25% 尺寸，标题是否仍清晰、钩子是否仍明确？需要凑近看就是字号太小；3) 品牌测试——遮住每屏设备，周围设计是否仍像该品牌（颜色、字体、情绪、标题语气）？否则截图太通用；4) 反通用测试——这些屏是否可能属于该类别中任何其他应用？是则重写文案并重做视觉层级；5) 安全区审计——检查每张渲染 PNG，把承重文字或产品 UI 超出安全内容区的屏幕拒绝并重渲。
48. 关键短语锚点：生成背景提示词中加 “vertical composition with negative space in upper third for headline”（为真实标题留空间）；视觉标准中 “The device is the hero — type is the caption”（防止文案压过产品 UI）；视觉标准/渲染 QA 中 “Apple safe zones”（让关键主张避开状态栏与 App Store 覆盖区）；生成背景提示词中 “no text, no logos”（避免不可用的生成排版，真实文案在 HTML 中加）；设备布局规则中 “Pick one: bleed OR full-frame”（防止看起来像渲染 bug 的半切圆角裁剪）。
49. 引擎选择：最终截图用确定性 HTML/CSS 合成经 html_to_png 渲染，因为 App Store 文案、设备遮罩、安全区和品牌排版需要精确控制；gpt-image-2 只用于花哨/背景/品牌世界图像以增加视觉丰富度，真实产品 UI 保持为截图；仅当某生成背景确实需要高于 1K 的分辨率时，才把 gpt-image-2 升到 2K/4K 档或升级到 seedream。
50. 典型运行时间 10–25 分钟：输入+风格选择 1–5 分钟（需要参考时由用户节奏决定）；品牌/截图读取 2–5 分钟（含视觉检查与功能映射）；策略提案 2–5 分钟（最便宜的文案迭代点）；图像生成 2–8 分钟（仅背景或参考驱动主视觉）；HTML 合成+渲染 5–10 分钟（6 张 1290×2796 PNG 加联系表）；QA 修订不定（文案调整便宜，新图像较慢）。
51. 失败模式与修复：六屏像同一布局的变体——默认骨架重复且内容对比不足，重新分配布局原型并轮换视觉重心、颜色与截图选择；联系表标题不可读——字号太小，加大标题、缩到 5–8 词并重渲；生成背景含文字或假 UI——提示词过度描述品牌/产品细节，加 no-text/no-logo 护栏重生成，真实 UI 留给截图；App Store 列表可用截图少于 3 张——薄列表（常见于配套应用或早期列表），走网站抓取路径、索取真实截图或停止，仅虚构发布演示概念可用 demo_mode: true 加 demo_brief 加 demo-only 声明；虚构应用无真实截图——发布演示概念需要代表性 UI 但生产规则禁止幻觉 UI，仅在 demo_mode: true、具体 demo_brief、代表性 UI mock 与 demo-only 声明齐备时用虚构应用演示模式；承重文字太贴上下边缘——跳过安全区 QA 或只看渲染观感未查文字块边界框，拒绝并让文字块边界框落在严格安全区内后重渲；设备圆角不齐——源截图圆角区已含背景或 CSS 半径与源不匹配，索取透明/高分辨率源导出、用真实 mockup 挖空或统一 CSS 遮罩并目视 QA（服务端统一圆角清理仍是工具缺口）；遮住截图后品牌显得通用——周围设计忽略 brand.md 的语气、色板或图像规则，重渲前先按品牌规范重建屏壳；渲染模糊或被缩放——阶段尺寸或栅格选项错误，核对 1290×2796 阶段尺寸与 html_to_png 的 viewport_px:1290x2796、device_scale:1。
52. 何时向用户说不：想要“花哨”版本但不给参考——说不，索取喜欢的 App Store 页面截图、Figma 文件或 moodboard，说明无参考时只会交付默认加品牌色，这比猜“刺激”更好（此规则来自真实活动经验，自动花哨每次都产出业余结果）；想要 10 屏——说不，5–6 屏是甜点区，更多会疲劳；brand.md 语气通用（“modern, friendly, intuitive”）——指出问题，仍可出屏但标题只会和语气规范一样独特，提议先打磨语气（在 brand.md 的 Voice & Tone 部分）；没有真实产品截图且未明确要求虚构应用演示模式——不要发明 UI，索取截图、网站/引导抓取目标，或明确的 demo_mode: true 加具体 demo_brief；完全没有品牌——不要凭感觉推进，先引导到 build-a-brand，或至少让用户写出名称、色板 hex、展示字体、正文字体、一行语气描述。

适用边界 · 注意事项

• 没有品牌规范（brand.md 或等价物）时不要凭感觉推进，应先走 build-a-brand 或至少补齐名称、色板 hex、展示字体、正文字体与一行语气描述。
• 没有真实产品截图且未明确要求虚构应用演示模式时，不要发明 UI；应索取截图、网站/引导抓取目标，或明确的 demo_mode: true 加具体 demo_brief。
• 用户想要“花哨”版本但不提供参考时不要自动发挥，应索取 App Store 页面截图、Figma 文件或 moodboard；也不要接 10 屏以上的需求（5–6 屏是甜点区）。