app-store-screens

App Store 截图

结合品牌与真实产品界面，制作一组 5–6 张、适配 iPhone 6.9 英寸尺寸（1290×2796）的 App Store 宣传截图。产品界面可以来自原始导出文件、Figma/源文件，或通过 Pika MCP 获取的公开 App Store 页面。以故事为主线，视觉效果醒目，并严格遵循品牌规范。

这是 build-a-brand 的姊妹技能——它会使用该技能的 brand.md 规范，也同样适用于用户提供的任何品牌规范。

费用透明度关卡

在进行任何付费 MCP 调用之前，先调用一次 identity_balance({verbose: true})。展示当前余额、近期消耗速率和剩余可用时间，然后通过以下确切消息进行确认：

预计费用：使用 GPT-image-2 生成常见的 5–6 张截图组，包括 PNG 渲染、渲染后 analyze_media 质检，以及单张全分辨率 PNG 质检，约需 150–300 点数（约 $1.50–$3.00）。费用低于 $5，但请回复 proceed 继续，或回复 cancel 停止。

在用户回复 proceed 之前，不要调用任何付费 MCP 工具。如果用户回复 cancel，则停止生成。对于非交互式 --quick 或 --config 调用方，要求配置中包含 cost_ack=proceed；如果缺少此项，则显示费用预估并停止，不要消耗点数。

交付内容

5 或 6 张 PNG，按编号保存到 ~/Desktop/[app-name]-app-store-screens/（或用户指定的位置）：

01_hook.png            ← biggest claim, works as a search-result thumbnail
02_value.png           ← the one thing the app does best
03_feature_a.png       ← specific capability
04_feature_b.png       ← another specific capability
05_proof.png           ← social proof, awards, "loved by", differentiator
06_close.png           ← optional 6th — closer / CTA / brand flourish

另附一张联系表（_preview.png），一览全部 6 张截图。

工作流

Step 0 — 收集信息并选择风格

如果调用时参数为空，且没有可用的品牌/截图/演示相关信息，则原样打印以下菜单并停止。必需输入齐备前，不要生成图像或渲染 HTML。

你想制作什么样的 App Store 截图组？ 必需信息：

• 品牌规范 — brand.md 或同等的品牌说明，包含名称、配色、字体、品牌语调和图像方向；如果你希望我先获取页面并拟定品牌概览，也可以提供 App Store URL/应用名称
• 原始产品截图 — 导出的 PNG、可用于导出截图的 Figma/源文件、截图文件夹，或我可以通过 Pika MCP 获取内容的 App Store URL/应用名称
• 或者虚构应用演示简报 — 仅用于不存在真实产品的发布演示/概念设计；请注明 demo_mode: true，并说明虚构应用的功能

可选：App Store 截图参考、情绪板、首选截图数量（5 或 6 张）、输出文件夹。

在交互模式下，如果用户只提供了部分信息，只询问缺少的必需内容，然后停止。如果适用非交互式快速通道，则使用 Step 0.5。必需输入：

• brand.md 或同等的品牌规范，包含名称、配色、字体、品牌语调和图像方向；如果用户提供了 App Store URL 并要求你“帮忙创建”，则先获取页面，并根据页面、图标和截图拟定品牌规范供其确认
• 一个产品来源：原始产品截图、可用于导出截图的 Figma/源文件，或可通过 Pika MCP 获取的 App Store URL/应用名称
• 仅针对虚构应用发布演示，demo_mode: true 和 demo_brief 可替代真实产品截图；请使用下文的虚构应用演示模式路径
• 如果用户希望采用特定的 App Store 风格，可选提供参考截图或情绪板

步骤 0.5 — 非交互快速通道

当调用方传入 --quick 或 --config <path>，或者表示正在从 CI、子代理、批处理作业或其他非交互式运行环境中运行时，请使用此路径。

本节优先于下方的交互式询问／等待说明。适用时，请使用此快速通道，不要转入多轮信息收集流程；只有在确实缺少所需品牌信息，以及产品截图或明确的演示模式输入时，才例外。

• --config <path> 指向一个包含预设选项的 JSON 文件：brand_spec、 product_screenshots、app_store_url、website_url、reference、style、 screen_count、narrative_arc、demo_mode、demo_brief 和 output_folder。
• --quick 表示使用默认风格，除非提供了参考；根据提供的品牌规格或 App Store 商品页推断品牌印象；自行拟定由 5-6 个屏幕组成的故事线，然后继续。
• 对于 --quick 或 --config，不要在风格选择、品牌印象复述、参考规则复述或 5-6 屏策略提案环节停下来等待确认。请在文中记录假设，然后继续设计／渲染。
• 如果既没有真实产品截图，也没有明确提供 demo_mode: true 和 demo_brief，请一次性停止，并用简洁列表列出缺失字段，而不要启动多轮问答。

虚构应用演示模式

仅当调用方明确说明这是一个虚构应用、假应用、发布演示、概念演示，或在配置中传入 demo_mode: true 时才使用此模式。真实产品不得使用演示模式。

当不存在真实产品截图时，演示模式可以用品牌语调创建具有代表性的 UI 模拟图，但输出必须标注为仅供演示的概念作品，而非生产素材。将虚构的屏幕视为分镜式 QRT/演示产物，而不是可用于 App Store Connect、证明真实产品的材料。

• 需要提供 demo_brief，或提供足够的产品概念细节，以便明确应用的核心用途、目标受众、3–5 项功能，以及证明/行动号召角度。
• 生成的 UI 状态必须与简报内部一致；除非提示中明确提供，否则不得暗示存在真实客户、真实评价、真实指标或真实集成。
• 在交付说明和联系表标签中添加仅供演示的免责声明： "Demo UI concept — not production assets and not real product screenshots."
• 在非交互模式下，只有当配置设置了 demo_mode: true 并提供了 demo_brief 时才继续；否则应停止并简洁列出缺失字段。

在交互模式下，所需输入齐备后，先简要说明议程，并提出一个关于风格的开场问题。这是了解用户想采用默认风格还是特定参考风格的最佳时机。在非交互快速流程中，除非提供了 reference 或 style，否则选择默认风格，在文中注明这一假设，然后继续。

here's how this works:
1. **Read your brand + screenshots** — i absorb the brand voice, palette, type, and figure out what the app actually does
2. **Strategy** — i pitch a 5–6 screen narrative arc (hook → value → features → proof → close) with headlines for each, before any design
3. **Design + generate** — i design each layout, composite at 1290×2796
4. **Preview** — i deliver the PNGs + a contact sheet so you can see the whole campaign at once

quick question before i start — **do you want the default style, or something specific?**

- **Default** — clean, restrained, screens shown untouched. Full-frame device, headline + sub above, solid brand-color backgrounds, brand-voice copy. Codified in `references/default-layout.md`. This is what i deliver well.
- **Something specific** — share a clear reference: a screenshot of an App Store page you love (Notion, Calm, Things, Headspace, anything), a figma file, a moodboard image. I'll study it, extract the compositional rules (device size + position, headline treatment, background, any signature flourishes), pitch back what i read before designing, then build the campaign — **with your brand's palette, fonts, voice, and photography style swapped in**. So if the reference uses an over-the-shoulder photo, i'll generate one in your brand's photo style (`gpt-image-2` accepts the reference as a style input). The reference dictates the composition; your brand dictates the look.

if you don't tell me, i'll go with default.

为什么没有“更炫”的自动模式。 要做好丰富、多变、富有戏剧性的构图，需要进行视觉判断（透视、层次、排版层级、色彩平衡），这些都无法通过程序给出答案。用户想要丰富效果却没有提供参考时，我的近似方案往往显得不够专业。请用户提供具体参考，就能提取可复现的具体规则，而不是自由发挥；用户也可以据此确认我是否在朝正确的方向努力。

根据回答选择以下两种后续路径之一：

• 默认风格 → 从头到尾遵循 references/default-layout.md。每个屏幕都使用相同的构图骨架，通过颜色和内容呈现变化。这样能产出一致且遵循品牌规范的作品。
• 复现参考风格 → 研究参考，提取规则，再替换为用户的品牌元素。完整流程见下文的“参考驱动路径”。

如果用户无法或不愿提供参考，但仍想要超出默认风格的效果，请委婉说明：没有参考时，你会采用默认风格并加上用户的品牌色，这比通过反复猜测来迭代更好。不要临时编造一种“更炫”的风格。

步骤 1 — 了解品牌和产品

App Store 列表路径

如果用户提供 apps.apple.com URL、数字 App Store 应用 ID，或作为产品来源的应用名称搜索词，请先尝试使用 Pika MCP 的 fetch_appstore_screens，因为它速度更快、更稳定，并且会返回托管的截图/图标素材，可供后续渲染步骤使用：

fetch_appstore_screens(
  query: <app_store_url | numeric_app_id | search_term>,
  country: "us",
  max_screens: 10,
  include_icon: true
)

将返回的 metadata、icon 和 screenshots 用作产品来源。返回的截图 url 值已经是 Pika 托管的 HTTPS 素材，可直接用于后续 html_to_png 阶段。

如果用户提供了特定国家/地区的 App Store URL，调用工具时应尽可能保留该店面国家/地区。如果国家/地区不明确，除非用户要求其他店面，否则默认使用 "us"。

如果 MCP 工具不可用、未通过身份验证，或未返回截图，请说明情况，然后使用最稳妥的备用方案：其他读取/抓取工具、官方 App Store/iTunes 元数据端点，或用户提供的截图。备用方案应以真实的列表素材为依据；不要虚构产品 UI。

预期结果格式：

{
  "app_url": "https://apps.apple.com/...",
  "metadata": { "name": "...", "subtitle": "...", "description": "...", "category": "...", "icon_url": "https://..." },
  "icon": { "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/...", "filename": "appstore-icon.png", "mime_type": "image/png", "width": 1024, "height": 1024 },
  "screenshots": [
    { "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/.../1290x2796bb.png", "filename": "appstore-screen-01.png", "mime_type": "image/png", "width": 1290, "height": 2796 }
  ],
  "count": 1
}

源截图准备

在选择默认的手机布局之前，先对每张获取或由用户提供的源截图进行分类，并记录你将使用的 source_treatment：

• clean_ui_capture - 可用于设备模型的原始应用内 UI。
• composed_marketing - 已完成的 App Store 营销画面，不是干净的应用内截图。
• legacy_footer_cleanup - 干净的 UI，只需清理列表品牌页脚或水印即可嵌入设备。

组合式营销源图是预先排版好的营销画面。常见特征：手机上方已经有烘焙好的标题或副标题；手机与源图边缘相接或被裁切；背景已经是宣传素材；源图已经是完成的 1290x2796 App Store 画面，而非干净的产品 UI。2025 年的 Notion 列表采用了这种模式。

如果源图属于 composed_marketing，不要将其重新排版到另一个设备模型中，也不要在烘焙好的标题上方再添加、书写或生成第二个标题或副标题。优先使用 clean_ui_capture：如果产品网站、引导流程或 Web 应用存在可捕获的真实 UI 界面，请使用 capture_website；或者请求提供模拟器、Figma 或原始 UI 导出图。如果没有可用的干净 UI 界面，请使用 source_treatment=composed_passthrough：将组合好的源图原样作为屏幕或背景展示，只添加最少的交付框架、编号或联系表标签。不要依赖裁掉底部 6-8% 来修复组合式源图；这会裁掉错误区域，而且无法解决标题重复的问题。

在 HTML 阶段使用经过处理的截图包装器，并保持源图顶部位置固定。包装器必须定义自己的几何尺寸；除非从包装器到设备的每一层父级都设置了明确高度，否则不要依赖 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);   /* shows the top 92% while cropping the bottom 8% */
    object-fit:cover;
    object-position:top center;
    display:block;
  ">
</div>

如果裁掉 8% 会移除真实的产品 UI，请改为在底部页脚上叠加品牌色渐变，但仍须在截图进入最终设备模型之前去除水印残留。

处理 Mac 应用或混合应用截图

对于仅限 Mac 或 iOS/Mac 混合应用（例如 Things 3、Drafts、Numbers、Day One、OmniFocus 或 BBEdit），fetch_appstore_screens 可能返回横向 Mac 截图（例如 1290×806），而不是 iPhone 竖屏截图（1290×2796）。在选择默认的 iPhone 竖屏布局前，请先检测截图方向：

方向规则为 aspect_ratio_w > aspect_ratio_h；如果只有像素尺寸，则使用 width > height。

mac_shots = [s for s in screenshots if s.aspect_ratio_w > s.aspect_ratio_h]
# Equivalent when explicit aspect ratios are not present:
mac_shots = [s for s in screenshots if s.width > s.height]

如果 mac_shots 不为空，请使用 references/mac-app-layout.md 中的嵌入式卡片布局，而不是全画幅设备截图。对于仅限 Mac 或混合应用，请将每张横向截图作为圆角 UI 卡片嵌入 1290×2796 的竖屏画布，而不是将其裁切到 iPhone 边框内、添加上下黑边，或将其作为全画幅设备。Things 3 第 2 轮基准测试验证了这种方法：Mac 截图保持清晰易读，竖屏宣传素材也仍符合 App Store Connect 的要求。

源截图准备步骤同样适用于 Mac 卡片：嵌入前，请检查横向截图是否存在列表品牌页脚或页脚水印残留。不要对 Mac UI 使用手机竖屏裁切。使用专用卡片包装器（例如 source-screen-crop--mac）保持横向宽高比；如需清理，优先在卡片内使用窄幅底部遮罩或渐变，或进行保留横向比例的小幅底部裁切。

App Store 条目素材不足时的防护措施

运行 fetch_appstore_screens 后，统计展示真实产品界面的可用截图数量。如果条目返回的真实产品截图少于 3 张，则视为 App Store 条目素材不足。

• 不要通过臆造 UI 来制作 5-6 屏的宣传方案。设备画面默认必须使用真实产品 UI。
• 交互模式：在制定策略前暂停，并提供两个选项：
  1. 网站截取路径 — 使用 capture_website 或提供的网站／引导流程 URL，截取真实产品界面，然后将这些截图作为产品截图继续操作。
  2. 真实截图路径 — 请用户提供模拟器导出图、Figma 画面或其他产品 UI 截图，然后再继续。 不要为真实产品提供合成设备 UI。如果用户明确转为虚构产品发布／概念演示，则切换到虚构应用演示模式，并要求提供 demo_mode: true 和 demo_brief。
• 非交互快速通道：如果有 website_url 或明显的产品网站，优先采用网站截取路径。如果没有可截取的产品界面，则只暂停一次，并简要列出缺失字段；除非配置明确设定 demo_mode: true 并提供 demo_brief。

获取素材后，只能根据条目和视觉素材推断一份初步品牌印象：应用名称、类别、可见配色、可能的字体方向、从副标题／描述中体现的语气，以及值得注意的 UI 时刻。在交互模式下，将其复述为临时品牌规范，并请用户在提出 5-6 屏方案前进行修正。在非交互快速通道中，将其记录为临时品牌规范并继续。

参考驱动路径：如何将用户的品牌应用到参考样式中

参考描述的是布局/风格看起来是什么样。品牌描述的是要使用什么颜色、字体、语气和摄影风格。这项技能的任务是将两者结合起来：复现参考的视觉结构，但以用户的品牌来呈现。需要从参考中提取两项，从品牌中提取两项：

从参考中提取结构规则：

• 设备尺寸（占画布的百分比）和倾斜角度
• 标题样式（字号、位置、颜色逻辑——关键词是否使用强调色？是否使用着色背景胶囊？）
• 背景样式（纯色、照片、渐变、抽象元素）
• 主视觉图像模式（手持手机、越肩视角、从手机中跃出的真实人物、漂浮的 3D 物体等）
• 注释／引出样式（带箭头的对话气泡、浮动卡片、拍立得相框等）
• 重复规则：每个屏幕都使用相同布局，还是因位置而异？

将品牌细节应用到设计中：

• 配色（参考使用纯色块的地方，换成品牌颜色）
• 字体（所有使用字体的地方，都换成品牌的展示字体和正文字体）
• 语气（用品牌语气改写所有标题和副标题——不要照抄参考文案）
• 摄影方向（所有生成的图像都遵循品牌的摄影规则——对 DeltaStream 来说，即纪实风格的 35mm 摄影、黄金时段、真实公寓、每个画面都有奶油黄色点缀、真实多元的演员阵容）
• 氛围（温暖还是冷峻、活泼还是专业等）

**生成主视觉图像时：通过 generate_image_edit 将参考图作为 images 传给 gpt-image-2。**该工具最多支持 16 张参考图。当参考图使用了鲜明的照片构图时（手持手机、越肩视角、人物从屏幕中跃出、3D 角色浮现），请使用此方法。将品牌摄影规则与提示词结合：

Reference: [user's reference photo — e.g., insect app's hand-holding-phone with butterfly]

Prompt: "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."

这样就能获得参考的风格，而不是照搬其内容。手与手机的构图可以沿用；光线、演员阵容和场景则来自品牌。

**在交互模式下开始设计前，先向用户说明提取出的规则。**用简短的项目符号列表写出来（例如：“设备占画布 75%，倾斜 -8°；设备上方是黄色胶囊标题；越肩主视觉；墨色注释配弧形箭头”），并请用户确认你是否正确理解了参考。在非交互的快速模式下，将提取出的规则直接记录下来并继续。然后按照这些规则构建全部 6 个屏幕，始终保持一致。不要在活动中途偏离规则。

接下来实际阅读：

• brand.md——提取：品牌名称、标语、配色（含十六进制值）、展示字体和正文字体、语气形容词、语气示例、禁用词、摄影／插画方向和氛围词。如果文件采用其他格式（PDF、纯文本笔记），请解析其中内容，并在交互模式下询问缺失信息。在非交互的快速模式下，对非关键缺失项记录合理假设——不要凭空编造品牌信息。
• 产品截图——逐张打开，并建立真实的认知：*这个应用实际能做什么？*记下核心 UI 模式（信息流、聊天、画布、列表、地图等）、主要操作界面，以及任何令人惊艳的屏幕（生成结果、精美状态、独特交互）。
• 如果可以使用 analyze_media 检查截图，而无需将其作为图像加载，就这样做——快速浏览会更高效。

然后用 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.

交互模式：在制定策略前等待用户确认。这样可以低成本地纠正误读。在非交互的快速模式下，将品牌解读视为暂定结果，直接记录假设，然后继续制定策略。

步骤 2 — 确定 6 屏策略

开始设计之前，先用纯文本写出叙事脉络。每一屏都需要：

• 角色（钩子 / 价值 / 功能 / 证明 / 收尾）
• 标题（5–8 个词，符合品牌语调 — 参见下文“文案”）
• 可选副标题（一行简短文案）
• 布局类型（参见下文 — 先写出名称，暂不绘制）
• 展示的原始截图（文件名）— 或“无，全屏文字排版”
• 仅适用于证明屏的证明素材 — 至少包含一项可见的证明素材，例如星级评分行、“编辑精选”徽章、用户评价卡片、评价数量标签、奖项徽章或其他有来源的视觉证明。证明屏不能只有文字。

按以下格式呈现：

**Screen 1 — HOOK**
Headline: "Sleep like you mean it."
Sub: (none — let the headline carry)
Layout: full-bleed UI with bold typography overlay
Featured screenshot: home_screen.png

**Screen 2 — VALUE**
Headline: "One tap. Then quiet."
...

交互模式：在生成或合成任何内容之前，请用户确认叙事脉络。此时修改文案成本最低。非交互快速模式下，根据已配置或推断出的叙事脉络直接生成，无需等待确认。

**证明屏规则：**证明屏必须包含可见的证明素材，而不能只有口头宣称。不要发布只写着“深受数百万用户喜爱……”或其他纯文字社交证明文案的证明屏。如果 App Store 列表或品牌规范提供了真实证明，应以星级评分行、“编辑精选”徽章、用户评价卡片、评价数量标签、奖项徽章或有来源的引述卡片等形式直观呈现。如果没有真实证明，请使用产品截图支撑视觉差异化主题，而不要捏造评价、奖项、评分或用户数量。

步骤 3 — 生成品牌世界图像

对于需要醒目背景图或主视觉图的屏幕，使用 generate_image 生成图像（按照上文所述的参考图驱动流程传入参考图时，使用 generate_image_edit）。

适用于 App Store 全屏视觉的默认设置：

• provider: gpt-image-2
• quality: medium 用于成品截图；只有用户明确要求快速迭代时才使用 low
• aspect_ratio: 9:16 用于全屏背景（与 iPhone 画布比例一致）
• 默认使用 1K。如果屏幕确实需要更高分辨率（例如需要放大的超精细背景），则将 gpt-image-2 提升至 2K/4K 档位（9:16 背景均支持），或改用 seedream — 先说明取舍并征求同意

品牌世界图像的提示词结构：

1. 主体 + 构图（“一只陶瓷杯放在风化橡木上的宽幅电影感镜头……”）
2. 用名称标明品牌色板（“仅使用墨黑色 #0E0E10、燕麦色 #F5F0E6，以及一种铁锈红点缀色 #C84B2F”）
3. 光线 + 氛围（“柔和的阴天窗光、轻微的胶片颗粒感、纪实风格”）
4. 负面提示（“不要文字、不要徽标、不要人物（除非另有说明）、不要图库照片般的光鲜感”）
5. 9:16 背景的画幅要求：“纵向构图，上方三分之一留出负空间用于标题”

**为标题预留上方三分之一空间。**告诉图像模型文字将放置的位置，以便为其留出空间。

保留生成图像的 HTTPS/CDN URL，以便在服务端渲染。如果用户提供本地产品截图或背景图像，请先使用 upload_asset 上传，并使用返回的 public_url；html_to_png 无法读取本地 file:// 路径。当某个阶段需要重复使用较长的 CDN URL 时，请在 HTML/CSS 中使用 s://screen01 等短标记，并通过 short_link_map 传入完整 URL；包含空格或缺少 https:// 的无效素材 URL 会在渲染前被拒绝。

第 4 步 — 将每个屏幕合成为 1290×2796

每个屏幕编写一个 HTML 舞台，然后通过 Pika MCP html_to_png 渲染为 PNG。请参阅 references/render-pipeline.md，了解：

• html_to_png 请求的确切格式
• 服务端资源/字体规则
• 安全区域指南
• 常见问题（字体加载、视网膜屏幕文本锐度、曲线中段裁切）

每个 HTML 舞台的尺寸必须恰好为 1290×2796px。使用 @font-face，并指定直接指向 fonts.gstatic.com 的 WOFF2 字体文件 URL，或内联 data:font/... 源。不要在渲染器 HTML 中使用 GitHub raw Google Fonts 链接；它们可能解析为 text/html，导致字体 MIME 白名单校验失败。品牌套件中的本地字体文件必须通过公共 HTTPS URL 提供或内联；upload_asset 不接受字体 MIME 类型。可复制粘贴的 Google Fonts 代码片段请参阅 references/fonts.md。

对于 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 会对支持的拉丁字形使用品牌字体，并对缺失的文字系统逐字形回退，而不是渲染成豆腐块。

对于深色背景，设置深色模式副标题令牌，不要重复使用中灰色。使用 --subhead-on-dark: #B5B4B0，或使用品牌调色板中等效的浅色中性色，并保持完全不透明；切勿在近黑背景上使用 #787774 这一类灰色，也不要按照浅色背景的 opacity: 0.7-0.75 规则降低深色令牌的透明度。#787774 这一类灰色仅适用于浅色背景。标题可以切换为奶油色/白色，但副标题也必须切换为深色模式下清晰可读的颜色。

每次渲染后，在接受 PNG 之前，先进行交付前 QA 检查。对渲染后的图片使用 analyze_media，并在可用时检查已编写 HTML 中的位置。 如果任何屏幕的文本块边界框显示承载关键信息的标题、眉题、副标题、CTA 或产品 UI 位于 references/render-pipeline.md 说明的安全内容区域之外，则拒绝该屏幕并重新渲染。

第 5 步 — 构建联系表并交付

全部 6 张 PNG 均成功渲染后：

1. 使用 html_to_png 构建 _preview.png 联系表：在中性色背景上，以 3×2 网格排列 6 张约 25% 大小的缩略图，并标注角色。
2. 提供联系表 URL 和每张单独截图的 file_url。如果还保存了本地副本，请另外附上这些本地路径。
3. 询问：是否有需要修改的地方？常见修改包括文案微调（成本低）、布局调整（成本中等）或更换图片（成本最高）。

在 _preview.png 已生成并包含在交付内容中之前，不要声称截图已全部完成。如果联系表渲染失败，先修正联系表 HTML 或重新渲染缺失的 PNG；不要只交付单张 PNG 并宣称整个宣传活动已完成。

飞行后质量关卡

在宣布成功之前，先对 _preview.png 联系表调用 analyze_media，评估整个宣传活动的多样性，然后将带有证明文案、深色背景或预备源截图的画面作为全分辨率单张 PNG 检查。仅凭 25% 大小的联系表，无法验证页脚水印渗漏、深色背景副标题对比度、细微的证明素材瑕疵，或组合营销源素材中的双标题问题。

对以下内容运行全分辨率单张 PNG 检查：

• 证明画面
• 每张使用近黑色／深色背景的画面
• 每张嵌入了抓取或用户提供的源截图，且其中可能带有列表品牌页脚文字的画面
• 每张 source_treatment=composed_passthrough 的画面，或源素材被归类为 composed_marketing 的画面
• 每张使用了 mac_shots 的 Mac 横向卡片画面

对于联系表，请要求给出结构化判定：

Return JSON only: {
  "verdict": "clean" | "degraded" | "catastrophic",
  "observations": string[],
  "quality_warning": string | null,
  "re_roll_suggestion": string | null
}
Check that the contact sheet shows every requested screenshot, App Store safe zones are respected, product UI is readable, headlines are legible at thumbnail scale, and no generated text is garbled.

对于每张需要检查的已渲染单张 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
}
Check at readable resolution. The proof screen must include a visible proof artifact such as a star row, Editors' Choice badge, testimonial card, review-count chip, award badge, or sourced quote card. Dark-background subheads must use a light dark-mode token and remain readable. Source screenshots and Mac cards must not show footer watermark bleed or listing-brand footer clutter. For composed-marketing sources, verify there is no generated headline stacked above a baked headline and no extra device mockup wrapped around the source.

• 如果 verdict 为 clean，交付联系表和单张 PNG 的 URL。
• 如果 verdict 为 degraded，附上 quality_warning 一并交付 URL，让用户在发布前检查。
• 如果 verdict 为 catastrophic，不要宣布宣传活动已完成；应展示该判定和 re_roll_suggestion。
• 如果证明画面缺少可见的证明素材、深色背景副标题对比度过低、源截图页脚仍有可见的水印渗漏，或 composed_source_double_headline_visible 为 true，则至少应将判定视为 degraded，并在正常交付前重新渲染受影响的画面。如果组合源素材同时带有固有标题和生成标题，不要宣布宣传活动已完成。

5 种布局类型

每张画面使用一种。不要堆叠设备。 每张画面只突出一个大胆创意。

完整的 CSS 框架和视觉示例请参阅 references/layout-archetypes.md。快速参考：

1. 悬浮设备 — 倾斜的手机置于醒目背景上。最通用的布局，适合展示价值／功能的画面。
2. 全幅 UI — 手机画布铺满画面；文字叠加在顶部或底部。最适合吸引注意的开场画面。
3. 并排布局 — 设备置于一侧，另一侧为生成的生活方式图像。最适合呈现情感化功能。
4. 视差叠层 — 手机置于前景，品牌图形／图像浮于后方。最适合展示令人惊艳的功能画面。
5. 引言卡片 — 大号引述文字，角落放置一台小型设备。最适合证明画面。

文案 — 不容妥协

App Store 标题需要在极小的空间内接受检验，因此必须：

• 包含 5–8 个词。 更长的标题在搜索结果的 6.1" 手机上就会失效。
• 准确呼应品牌语气。 如果 brand.md 规定语气是“冷淡、面无表情、绝不用感叹句”，标题就绝不能以 ! 结尾。如果语气是“温暖而略带调侃”，标题就要有节奏感。
• 提出主张，而不是描述功能。 “像你认真的那样睡个好觉” > “追踪睡眠”。“每天专为一段安静时光而打造” > “效率应用”。
• 前两张画面单独作为缩略图也能成立。 字号更大，吸引力最明确。App Store 搜索结果会展开显示前 2–3 张，其余画面只有用户点进去后才会显示。

禁用文案（相当于 App Store 版的“倾注爱意打造”）：

• “保持井井有条。”
• “你的每日好帮手。”
• “一体化[类别]。”
• “专为帮助你[动词]而设计。”
• “追踪。规划。达成。”
• 任何包含“无缝”“毫不费力”“强大”“智能”“智慧”的文案。

如果某个标题放到其他 500 个应用上也毫无违和感，就重写。

视觉规范

• 设备是主角，文字是说明。 在 1290×2796 的画布上，设备宽度应为 1050–1150px（约占画布的 81–89%）。再小就显得畏缩。标题用于衬托屏幕内容，而不是与之争抢注意力。
• 字体层级。 每个画面只突出一项——通常是设备。标题使用 100–140px 的 Funnel-Display 级字体；副标题为 36–44px；字重和字号要有明显差异。（超过 150px 后，标题就会开始与设备争夺视觉焦点。）
• 避免使用 SVG 描边绘制 iPhone 边框——它们无法与截图圆角对齐。 基于描边的 SVG 边框会有一半位于路径内、一半位于路径外，而且圆角半径和灵动岛比例始终无法与真实 iPhone 完全匹配。优先使用从 Figma/模拟器导出的透明背景截图，或带透明挖空区域的真实 iPhone 模型 PNG。如果只有矩形源截图，请使用统一的 CSS border-radius + overflow:hidden 包裹，并对圆角进行目视检查。旧的本地 clean_phone_uniform() PIL 方案现在是有文档记录的 MCP 缺口，而非默认依赖项。
• 二选一：出血式或全框式。不要把底部曲线裁到一半。 默认采用全框式（设备顶部位于 y=580，宽度为 1000，这样圆角底部能完整显示在画布内，下方留出约 48px 间距）。出血式变体（设备顶部 ≥ 819）会让圆角底部完全超出 y=2796——适用于想营造戏剧感的吸引页。介于两者之间会导致可见的半截曲线：画布会从圆角弧线中间切过；这正是本规则要避免的失败情况。
• Apple 安全区域。 严格遵守安全区域规则：重要文字和产品 UI 必须位于 y=180..2616 范围内。顶部和底部各 100px 的区域绝不能放置关键信息；额外的 80px 缓冲可避免 App Store 界面元素、搜索结果裁切和文字上伸笔画挤到边缘。装饰元素可以放在此范围之外，但关键信息和可读的应用 UI 不行。
• 每个画面只放一个醒目的设备。 巨型文字、生成图像或引言——三者择一，而非兼有。醒目不等于杂乱。
• 只使用品牌调色板中的颜色。 不要为截图凭空创造新颜色。如果调色板限制太多，需要解决的是品牌本身的问题，而不是你的问题。

获取屏幕

原始屏幕可以来自任何地方——通过 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）。将其放大至 App Store 画布上默认的 1000px 设备宽度时，对于非像素级关键内容来说可以接受。如需更高保真度，请询问是否有更高分辨率的导出文件。

质量标准

交付前，请进行缩略检查：

1. 查看联系表。 能否一眼分辨出这 6 个屏幕？（标题不同、布局不同、视觉焦点权重不同。）如果看起来像同一个屏幕的 6 个版本，就重新设计。
2. 前 2 个屏幕的缩略图测试。 将屏幕 1 和 2 缩小到 25%。标题仍清晰可读吗？核心吸引点仍然明确吗？如果需要凑近才能看清，说明字体太小。
3. 品牌测试。 遮住每个屏幕上的设备。周围的设计是否仍然有品牌感？（标题中的色彩、字体、氛围和语气。）如果没有，这张截图就显得很普通。
4. 反平庸测试（与打造品牌测试相同）：这些屏幕是否可以属于这个品类中的任何其他应用？如果可以，就重写文案并调整视觉焦点层级。
5. 安全区审查。 检查每张渲染的 PNG；如果任何屏幕上的关键文字或产品 UI 超出安全内容区域，就拒收并重新渲染。

关键短语

这些锚点能让生成的营销素材清晰易懂，并符合品牌调性：

短语	位置	关键作用
vertical composition with negative space in upper third for headline	品牌场景图像提示词	为真正的 App Store 标题文字留出可用空间，避免文字被迫覆盖在繁杂图像上。
The device is the hero — type is the caption	视觉标准	避免文案喧宾夺主、压过产品 UI，让屏幕看起来像海报。
Apple safe zones	视觉标准 / 渲染 QA	确保关键信息不被状态栏和 App Store 覆盖区域遮挡。
no text, no logos	生成背景提示词	避免生成无法使用的文字；真实文案会通过 HTML 添加。
Pick one: bleed OR full-frame	设备布局规则	避免出现半截圆角裁切，让画面看起来像渲染错误。

引擎选择：优先使用 HTML 渲染，仅用 gpt-image-2 生成品牌场景图像

最终截图应通过 html_to_png 渲染为确定性的 HTML/CSS 合成图，因为 App Store 文案、设备蒙版、安全区和品牌字体都需要精确控制。仅在生成图像能增添视觉丰富度时，才使用 gpt-image-2 生成启动页、背景或品牌场景图像；真实产品 UI 则保留为截图。只有在特定生成背景确实需要高于 1K 的分辨率时，才将 gpt-image-2 升级到 2K/4K 档位（或改用 seedream）。

运行时间预期

典型运行时间为 10–25 分钟，具体取决于需要多少用户确认：

步骤	用时	备注
信息收集 + 风格选择	1–5 分钟	如需参考素材，耗时取决于用户
品牌 / 截图分析	2–5 分钟	包含视觉检查和功能映射
策略方案	2–5 分钟	最适合低成本迭代文案
图像生成	2–8 分钟	仅用于背景或基于参考素材生成的主视觉图像
HTML 合成 + 渲染	5–10 分钟	生成 6 张 1290x2796 PNG 和联系表
QA 修订	不定	文案调整成本低；新图像生成耗时较长

故障模式

症状	原因	修复方法
屏幕看起来像是同一布局的六种变体	重复使用默认骨架，内容缺乏足够的对比	重新分配布局原型，并轮换视觉焦点、色彩和截图选择
联系表中的标题难以辨认	字体对于 App Store 缩略图来说太小	增大标题字号，将文案缩短至 5-8 个词，然后重新渲染
生成的背景中包含文字或伪造的 UI	提示词对品牌／产品细节描述过多	使用禁止文字／Logo 的约束重新生成，并将真实 UI 留给截图
App Store 列表中可用截图少于 3 张	App Store 列表内容单薄，通常是配套应用或早期列表	使用网站截图路径，索取真实截图，或停止。仅对于虚构的发布演示概念，才使用虚构应用演示模式，并设置 demo_mode: true、demo_brief，同时注明仅用于演示
虚构应用没有真实产品截图	发布演示概念需要有代表性的 UI，但制作规则禁止虚构 UI	仅在设置 demo_mode: true、提供具体的 demo_brief、使用有代表性的 UI 模型并注明仅用于演示时，才使用虚构应用演示模式
关键文字离顶部或底部边缘太近	跳过了安全区 QA，或只检查了渲染后的外观，没有检查文字块的边界框	拒绝并重新渲染，确保文字块边界框位于严格的安全区边距内
设备圆角看起来不均匀	源截图的圆角区域已包含背景，或 CSS 圆角半径与源图不匹配	索取透明／高分辨率源文件导出图，使用真实的模型图裁切，或应用统一的 CSS 蒙版并进行视觉 QA。服务器端的统一圆角清理功能仍是工具缺口。
隐藏截图后，品牌显得很普通	周边设计忽略了 brand.md 中的品牌语调、配色或图像规则	根据品牌规范重建屏幕外壳，然后重新渲染
渲染结果模糊或缩放不正确	阶段尺寸或栅格选项有误	确认阶段尺寸为 1290x2796，且 html_to_png 使用 viewport_px:1290x2796、device_scale:1

何时应对用户提出异议

• 如果他们想要“更炫”的版本，却没有提供参考 → 提出异议。请他们提供喜欢的 App Store 页面截图、figma 文件或情绪板。说明没有参考时，你会提供默认方案加上他们的品牌色；这比猜测什么才算“令人兴奋”要好。（这条规则来自真实的宣传活动经验——自动美化每次都会产出业余水准的结果。）
• 如果他们想要 10 屏宣传活动 → 提出异议。5-6 屏最合适；更多会让人疲劳。
• 如果 brand.md 中的品牌语调很普通（“现代、友好、直观”）→ 指出这一点。你仍然可以制作屏幕，但要告诉他们，标题能有多鲜明，取决于语调规范有多鲜明。可以先提出优化语调（它位于 brand.md 的 Voice & Tone 部分）。
• 如果他们没有真实的产品截图，且没有明确要求使用虚构应用演示模式 → 不要编造 UI。请他们提供截图、网站／引导流程的截图目标，或明确设置 demo_mode: true 并提供具体的 demo_brief。
• 如果他们完全没有品牌 → 不要凭感觉继续。先引导他们使用 build-a-brand，或至少让他们写出：名称、调色板色值、展示字体、正文字体以及一句话的语调描述。

参考资料

• references/default-layout.md — 用户未提供参考图时，此技能生成的视觉系统。 每次运行时都先阅读此文件。它规定了标题置顶、设备为主、画面铺满的构图、配色轮换规则，以及眯眼检查清单。这是此技能擅长呈现的效果。
• references/mac-app-layout.md — 适用于 Mac 专属或混合应用商品页中横向 Mac 截图的竖版 App Store 布局。如果 fetch_appstore_screens 返回横向截图（例如 1290×806），请使用此文件。
• references/layout-archetypes.md — 真实 App Store 推广活动中常见布局模式的术语表。仅用于分析用户提供的参考图，不可作为自由选择菜单。
• references/render-pipeline.md — html_to_png 渲染请求、服务端资源／字体规则、安全区域叠加层、字体加载检查清单和交付前检查清单。