mcpField
N
nano-banana-app-store-campaign

nano-banana-app-store-campaign

github.com/chawlaaditya营销与增长6147 次安装30 周前更新
代码仓库

关于 nano-banana-app-store-campaign

用于将应用真实界面制作成 App Store 广告截图的工作流指南,面向需要成套营销图片的应用团队。它要求先检查应用与文案,再规划版式,并指定使用 Nano Banana,不在缺少凭据时切换模型。

主要功能

  1. 01从应用代码和素材提取设计依据
  2. 02规划连续的截图叙事与版式
  3. 03每张幻灯片撰写多个标题选项
  4. 04按故事规划截图采集清单
  5. 05生成前确认 Nano Banana 凭据
  6. 06避免虚构产品主张或切换图像模型

适用场景

  1. 01为应用商店制作统一截图广告
  2. 02将产品差异点编排成视觉故事
  3. 03根据既有应用界面准备宣传图

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/chawlaaditya/nanobananaaso --skill nano-banana-app-store-campaign

安装后在 Claude Code 中输入/nano-banana-app-store-campaign确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
.gitignore
agents/
openai.yaml
references/
prompt-patterns.md
quality-gates.md
visual-recipe.md
export-pattern.md
layout-plan-template.md
gemini-image-api.md
scripts/
build_contact_sheet.py
normalize_app_store_exports.py

详细介绍

Nano Banana App Store 营销活动

将 App Store 截图设计成广告,而不是教程。

文案先于布局。叙事先于装饰。 首先应通过视觉让幻灯片自我说明。 文字应强化信息,而不是包办一切。

当用户想制作一组截图营销素材,并且需要:

  • 从实际应用代码库和真实截图出发
  • 在所有幻灯片中保持统一的视觉系统
  • 使用 Nano Banana 进行广告化处理
  • 以确定性方式调整尺寸并打包联系表

请使用此技能。

仅在此技能中使用 Nano Banana。 不要切换到其他图像模型。 不要悄悄回退到 Flash 或任何质量较低的图像生成方案。

工作流

0. 确认 Nano Banana 凭据

在规划提示词或生成任何幻灯片之前,先确认 Nano Banana 能否在当前环境中实际运行。

默认行为:

  • 使用 Nano Banana
  • 首先检查是否已设置 GEMINI_API_KEY
  • 如果没有,再检查是否已设置 GOOGLE_API_KEY
  • 如果两个密钥都不可用,请停止并在生成前向用户索取 Gemini API 密钥

不要将缺少密钥视为可以使用其他图像模型的许可。

在计划、备注和提示词日志中,明确说明选用的方案:

  • Nano Banana

需要记录凭据来源时,请按以下格式记录:

  • Nano Banana credential source: GEMINI_API_KEY
  • 或 Nano Banana credential source: GOOGLE_API_KEY

不要让工具或凭据来源含糊不清。

1. 设计前先检查应用

先阅读代码库和资源,再推导出:

  • 字体和排版风格线索
  • 调色板和整体氛围
  • 有实际依据支持的产品主张
  • 值得宣传的差异化优势
  • 对用户最有力的益处
  • 应用解决的最明确的用户痛点
  • 用户应感受到的使用前后变化

不要编造主张。内容必须以代码、文案、设置、引导流程、定价界面或平台集成为依据。

检查以下内容:

  • 资源或字体目录中的字体
  • UI 代码中的颜色标记
  • 引导流程/营销文案
  • 定价/购买文案
  • 离线、隐私、本地 AI、可穿戴设备或平台集成相关主张

如果应用以 iOS 为主,请检查真实的 iOS 视图或资源,不要靠猜测。

2. 确定营销活动的故事线

根据用户要求的幻灯片数量,将应用转化为广告叙事。

如果用户要求的数量更少或更多,不要强行套用固定的 5 到 7 张幻灯片故事线。只使用有帮助的部分。

默认叙事弧线可参考以下截图框架:

位置目的备注
#1主视觉/核心益处尽可能展示应用图标、标语和主屏幕。这是许多人唯一会看到的一张幻灯片。
#2差异化优势展示应用与竞争产品相比有何实质性不同。
#3生态系统小组件、扩展、手表、桌面或其他核心功能之外的场景。若并非真实存在则跳过。
#4+核心功能每张幻灯片展示一项功能,并按重要性排序。
倒数第二张信任信号身份、工艺或可信度。例如:“为 [X] 群体打造。”
最后一张更多功能用标签或简短模块介绍额外功能和即将推出的内容。如果应用没有足够且真实的内容,则跳过。

规划幻灯片顺序时,还应采用以下高转化率的顺序逻辑:

  • 截图 1 点出痛点、愿望或矛盾
  • 截图 2 展示转变或结果
  • 截图 3 在条件允许时,用具体内容提供证明
  • 从截图 4 开始,展示一两个让承诺更可信的功能

将这一逻辑与位置框架结合使用,而不是将二者视为相互竞争的方案。例如:

  • 主视觉可以点出痛点或承诺结果
  • 差异化优势可以体现转变
  • 较早出现的核心功能页或信任页可以作为证明
  • 后续功能页可以说明如何实现承诺 核心叙事规则:
  • 每张幻灯片只传达一个理念
  • 一张幻灯片上绝不展示两个功能
  • 第一张幻灯片要突出对用户最有吸引力的益处,而不是最全面的概览
  • 幻灯片之间的顺序应经过精心安排,不能随意互换
  • 规划整组幻灯片时,应混合使用不同的幻灯片类型,而不是反复套用同一模板
  • 根据要求的幻灯片数量,选择最合适的内容安排,而不是盲目填满每个位置
  • 采用不同的版式,不要重复相同的模板结构
  • 相邻幻灯片不能使用相同的手机摆放位置
  • 加入 1 到 2 张反差幻灯片,使用反转色调或明显更深/更浅的背景,营造视觉节奏
  • 文案在缩略图尺寸下也必须清晰易读
  • 装饰元素必须烘托信息,绝不能遮挡 UI
  • 以截图为主的幻灯片应让截图保持视觉焦点
  • 优先通过视觉而非文字来解释
  • 力求文字与视觉内容干净均衡;但如果必须取舍,应先加强视觉表现,而不是增加更多文案
  • 避免只像把文字贴在截图上的广告牌式构图
  • 可安排 1 到 2 张刻意偏广告风格的幻灯片,让字体或情境图像比截图更具分量
  • 融入与应用类别相符的相关辅助图像,例如人物、地点、物品、表面或情境场景
  • 让整组幻灯片醒目鲜活,但不要显得杂乱或千篇一律

有意识地使用以下幻灯片类型。大多数优秀的整组幻灯片至少会混合使用其中 3 种:

类型用途典型场景
Typography-led hero使用醒目的大号粗体字,尽量减少产品展示第 1 张、信任类幻灯片或价值主张幻灯片
Hybrid ad截图搭配鲜明的情境图像、贴纸、徽章、路径或物品差异化优势和成果展示幻灯片
Product proof以截图为主,搭配克制的辅助元素核心功能和证明类幻灯片
Contextual/lifestyle通过真实场景、人物、吉祥物、地点或物品,让益处更鲜活情感化差异优势或契合产品类别的展示
Brand/value不使用伪造截图;仅使用字体、图标、物品或价值主张面板所有权、隐私、奖励、定价、信任

类型规则:

  • 不要让每张幻灯片都成为产品证明类幻灯片
  • 也不要让每张幻灯片都成为文字广告牌
  • 至少有一张幻灯片应首先给人大胆广告的感觉,而不只是装饰过的截图
  • 如果应用类别适合,应至少加入一张使用情境图像来展现应用周边生活方式或环境的幻灯片
  • 使用情境图像时,要让它与信息直接相关:旅行地点、路线、食物、训练鞋、硬币、证书、角色、房间、书桌或用户一眼就能理解的物品
  • 如果纯粹的价值广告更有力,可以让一张幻灯片尽量少展示手机,甚至完全不展示手机

压缩叙事、减少幻灯片数量时:

  • 保留 #1 主打幻灯片
  • 优先保留一个差异化优势,再考虑增加功能幻灯片
  • 先删去生态系统或“更多功能”内容,不要删去主要差异化优势

扩展叙事、增加幻灯片数量时:

  • 先增加更多核心功能幻灯片,再添加填充内容
  • 将信任信号幻灯片放在接近结尾的位置
  • 只有在“更多功能”幻灯片能如实展现更多内容且不会削弱整组幻灯片时,才将其用作最后一张
2.5. 先写文案

标题足够有力之前,不要开始设计版式。

在最终生成版式前,先获得标题认可。糟糕的文案会毁掉出色的设计。

把文案当作精确的工具,而不是整张幻灯片的全部内容。 视觉内容应首先传达功能、氛围或效果。 文字应让含义传达得更快、更清楚,而不是取代视觉说明。

对于每张计划中的幻灯片:

  • 开始设计版式前,先写 3 个标题选项
  • 每种思路各用一个选项:
    • 描绘一个瞬间
    • 陈述一种效果
    • 消除一种痛点
  • 如果工作流包含审批环节,就向用户展示这些选项,并为每个选项附上一条简短理由
  • 如果无法与用户互动,就在内部选择最有力的选项,并在计划或备注中说明原因

截图文案的铁律:

  • 每个标题只表达一个想法
  • 绝不要用“和”连接两个主张
  • 尽可能使用简短、常见的词
  • 确保文案在缩略图大小下仍清晰可读
  • 如果无法用 8 个词或更少的词说明核心变化,就继续精简
  • 每行尽量控制在 3 到 5 个词
  • 使用有意安排的换行,并用 <br /> 标记
  • 除非领域确实需要,否则避免使用行话
  • 避免使用功能列表式标题
  • 避免使用复合从句
  • 避免使用空泛、缺乏实质内容的愿景式文案
  • 除非主张具体且真实,否则避免使用营销流行语

确保文案可安全渲染的规则:

  • 仅在规划文档、版式计划和审核备注中使用 <br />
  • 编写实际的图像生成提示词时,将计划中的换行转换为明确的多行文案区块,例如:
    • Headline (2 lines):
    • Line 1
    • Line 2
  • 明确告知图像模型不要在最终图片中渲染字面上的 <br /> 字符
  • 不要假设 Nano Banana 能正确识别 HTML 风格的换行标记

使用以下标题模式:

类型作用示例
描绘一个瞬间帮助观看者想象自己使用应用Check your coffee<br />without opening the app.
陈述一种效果推销最终效果A home for every<br />coffee you buy.
消除一种痛点点明并解决问题Never waste<br />a great bag.

在生成版式前,先改写薄弱的文案。优先强调用户的获益,而不是罗列界面内容。 不要先描述功能。先讲生活上的改变,再让功能为其提供支持。 如果一张幻灯片需要太多文字才能说明白,就先修正视觉概念,而不是继续增加文案。

由差变好的改写模式:

薄弱更好胜出原因
Track habits and stay motivatedKeep your streak alive只表达一个想法,更容易快速理解
Organize tasks with AI summaries and smart sortingTurn notes into next steps先讲效果,减少行话
Save recipes with tags, filters, and favoritesFind dinner fast推销获益,而不是罗列功能
Manage budgets and never miss paymentsSee where money goes承诺更清晰,不包含两个主张
AI-powered wellness supportFeel calmer tonight带来具体的情绪效果

文案流程:

  1. 每张幻灯片写 3 个选项。
  2. 手臂伸直拿着幻灯片阅读。如果无法在约 1 秒内读懂,就重写。
  3. 检查每行的长度。如果某行太密,就添加或调整 <br />。
  4. 用手遮住 UI,只读文字。如果读起来像功能目录,而不是一个故事,就重写。
  5. 确认每张幻灯片仍然只推销一个想法。
  6. 将获批的、带 <br /> 的规划文案转换为可安全渲染的提示词文案,并使用明确的分行区块。
  7. 开始制作最终版式前,锁定获批的标题集。
3. 明确告知用户需要截取哪些屏幕截图

如果用户尚未提供屏幕截图,请根据已批准的故事槽位和标题,列出具体的截图清单。

编写一个简短的有序列表,包含:

  • 文件名
  • 要截取的确切屏幕
  • 屏幕上应显示的内容
  • 对应支持的幻灯片创意

每张基于截图的幻灯片只使用一张原始屏幕截图。

不要为应以文字排版为主的价值展示幻灯片索要截图。

截图清单示例:

  • 01-main-value-screen.png:最能体现应用主要优势的屏幕,包含一个明确的主视觉区域
  • 02-structure-screen.png:清晰展示组织结构、工作流或下一步的屏幕
  • 03-action-screen.png:展示用户即将执行核心操作的屏幕,并显示主要行动号召
4. 在生成前敲定布局计划

生成任何最终幻灯片之前,先在项目目录或输出目录中编写一个布局计划 Markdown 文件。

以 references/layout-plan-template.md 为起始结构。 如果用户需要一个扎实的默认起点,也请阅读 references/visual-recipe.md。

布局计划是以下内容的事实依据:

  • 生成路径
  • 宣传定位
  • 故事主线
  • 使用了哪些故事槽位,以及有意跳过了哪些槽位
  • 整个序列采用的痛点 -> 转变 -> 证明 -> 交付逻辑
  • 一致性主线
  • 裁切安全的构图规则
  • 幻灯片顺序
  • 已批准的标题/辅助文案
  • 适用时为每张幻灯片考虑的三个标题选项
  • 整套幻灯片的类型规划
  • 手机的摆放变化
  • 布局变化策略
  • 对比幻灯片规划
  • 背景处理
  • 差异化处理
  • 导出目标

不要跳过这一步。计划可以防止风格偏移。

生成前,还要敲定视觉节奏计划:

  • 哪些幻灯片以文字排版为主,哪些以屏幕截图为主
  • 哪张幻灯片采用最醒目的标题处理
  • 哪张幻灯片使用最丰富的辅助图像
  • 哪张幻灯片作为最简洁的证明页
  • 整套作品在哪些位置有意从浅色转为深色、从平面转为立体,或从沉静转为活跃
5. 先生成风格锚点

不要一开始就批量生成整组内容。

先生成第 1 张幻灯片,将其作为风格锚点:

  • 忠实使用真实截图
  • 使用已锁定的布局方案
  • 围绕截图设计高端广告风格
  • 保持应用 UI 清晰可辨
  • 让主视觉幻灯片突出一个明确的核心优势
  • 让文字负责推销,让 UI 负责证明
  • 定义整套作品的字体排印、面板效果、设备光效、强调元素的运用方式和留白理念
  • 定义整套作品的辅助图像风格:与应用相匹配的人物、地点、物品或场景
  • 让截图保持主角地位,同时用辅助图像让幻灯片更丰富、更生动
  • 如果以排版为主或混合广告风格的幻灯片更适合作为宣传活动的开篇,就让锚点确立这一更大胆的方向,而不是默认使用居中的手机
  • 将第 1 张幻灯片视为一场有意设计的系统测试,而不只是漂亮的初稿
  • 将锚点视为以下要素的正式定义:
    • 字体排印
    • 背景风格
    • 面板效果
    • 设备效果
    • 强调元素的运用方式
    • 整体视觉风格

利用第 1 张幻灯片尽早测试容易出问题的细节:

  • 归一化后的裁切安全性
  • 标题字体、字重和换行
  • 辅助文案的字号和密度
  • 标签或徽章的大小
  • 使用时的 CTA 提示、箭头、切换开关或按钮
  • 手机的尺寸和视觉主导性
  • 辅助图像的适量程度
  • 幻灯片在缩略图尺寸下是否仍能一眼看清

不要只满足于“还不错”。 反复完善锚点,直到它能为宣传活动的其余内容提供可靠的系统。

如果没有更适合该应用的方向,就默认使用 references/visual-recipe.md 中经过验证的竖版方案作为构图系统。

在满足以下任一条件前,不要继续制作第 2 张到第 N 张幻灯片:

  • 用户明确批准;或
  • 内部评审确认其足够出色,可作为整套宣传内容的风格参考

之后,以获批的第 1 张幻灯片作为整套宣传内容的主要风格参考。

这是确保一致性的关键技巧:

  • 使用图像模型搭建初始框架
  • 然后将搭建好的幻灯片用作其余幻灯片的风格参考
  • 将第 1 张幻灯片归一化后的导出版本用作后续风格参考,而不是随意使用未经处理的输出

修改第 1 张幻灯片后,明确记录从修改中总结出的经验:

  • 实际有效的裁切安全间距
  • 归一化后效果最佳的字体处理方式
  • 保持清晰易读的标签、CTA 或面板尺寸
  • 过于繁杂并已移除的视觉元素
  • 可接受的文字密度
  • 后续每张幻灯片都应遵守的构图规则

将这些锚点经验写入布局方案或提示词日志。 将其作为第 2 张到第 N 张幻灯片的规则,让后续内容沿用已经验证过的系统,而不是重复摸索。

在布局方案和提示词日志中明确写出 Nano Banana。 如果可以,还要记录凭证来自 GEMINI_API_KEY 还是 GOOGLE_API_KEY。

6. 生成其余广告系列幻灯片

使用风格锚点和每张目标截图,生成第 2 张至第 N 张幻灯片。

遵循以下规则:

  • 保留真实的应用 UI
  • 不要重新设计产品
  • 放大 UI 局部时,只能使用同一张截图中的内容
  • 让整个广告系列保持统一风格
  • 根据叙事需要,在简洁的证明型幻灯片和内容更丰富的广告型幻灯片之间交替
  • 让相邻幻灯片上的手机摆放位置有所变化
  • 让整组幻灯片的整体构图节奏有所变化
  • 让截图在整组幻灯片中的主导程度有所变化
  • 字体要大且醒目
  • 文案要简短、具体
  • 每张幻灯片只聚焦一个已获批准的想法
  • 用视觉呈现说明,让文字强化主张
  • 让每张幻灯片的背景或装饰图案都能支撑其传达的信息
  • 让截图或核心产品视觉成为焦点
  • 只有在能强化信息和应用类别时,才添加辅助图像
  • 避免空洞的背景,也避免只有文字的广告牌式构图
  • 在后续幻灯片中明确锁定与锚点一致的标题字体系列或字体风格
  • 除非锚点本身就采用衬线标题或其他字体风格,否则后续幻灯片不得偏离锚点的字体风格
  • 除非锚点的设计语言中已有超大的白色文字卡片或巨型文案面板,否则应避免使用

借鉴优秀 App Store 广告系列,进行适度变化:

  • 使用大胆的色块,并搭配超大标题
  • 在能强化主张时,少量使用贴纸、徽章、路径、轨道、缎带或光晕图案
  • 在能增加结构感时,使用简洁的页脚色带或紧凑的价值点栏
  • 偶尔加入抠图摄影、吉祥物、物件或场景片段,让应用更显真实、贴近生活
  • 在较为抢眼的广告型幻灯片后,安排一张克制的证明型幻灯片,让整组内容有所喘息

不要把风格统一误解为千篇一律。整组内容应经过艺术指导,而非套用模板。

对于每个后续提示词,都要明确重申锚点的风格 DNA:

  • 字体大小
  • 背景风格
  • 面板处理方式
  • 设备呈现方式
  • 强调色的使用方式
  • 从锚点修订中总结出的安全裁切要点
  • 经标准化验证有效的字体、CTA、标签和间距选择

严格遵循以下输出流程:

  • 将模型原始输出保存到 native/
  • 将每张幻灯片标准化后保存到 export-<width>x<height>/
  • 保留 prompt-log.md
  • 根据标准化后的导出文件生成 contact-sheet.png

这是成功的 campaign-v3 运行所采用的参考工作流程。请沿用,不要另行设计宽松的导出流程。

使用 references/prompt-patterns.md 了解提示词结构。

6.5. 针对最终裁剪进行设计,而不是针对原始输出

生成的源图必须预先考虑最终的 App Store 裁剪效果。

不要把关键内容紧贴边缘,然后指望标准化处理能让它们保持在安全范围内。

把标准化视为最后的打包步骤,而不是布局步骤。

将所有关键元素放在裁剪安全区内:

  • 标题和辅助文案
  • 标签和价值面板
  • 手机或主要视觉焦点
  • 任何必须看清的图标或标注

纵向幻灯片采用以下默认裁剪安全规则:

  • 左右安全边距:至少为画布宽度的 8%
  • 顶部安全边距:至少为画布高度的 6%
  • 底部安全边距:至少为画布高度的 8%
  • 关键文案或视觉焦点绝不能接触外框

使用实际的标准化计算方式,不要凭直觉判断:

  • 最终 iPhone 纵向目标比例为 1320 / 2868 = 0.4603
  • 标准化程序会先居中裁剪,然后调整尺寸
  • 如果生成的源图宽于 0.4603,则保留的宽度为 src_h * 0.4603
  • 两侧各自裁掉的宽度为 (src_w - src_h * 0.4603) / 2
  • 如果生成的源图窄于 0.4603,则保留的高度为 src_w / 0.4603
  • 顶部和底部各自裁掉的高度为 (src_h - src_w / 0.4603) / 2

在编写提示词前,先据此确定一个初步安全框:

  • 对于较宽的纵向源图,安全区左边缘为 horizontal_trim + 0.08 * surviving_width
  • 对于较宽的纵向源图,安全区右边缘为 src_w - safe_left_edge
  • 对于较宽的纵向源图,安全区上边缘为 0.06 * src_h
  • 对于较宽的纵向源图,安全区下边缘为 0.92 * src_h
  • 对于较窄的纵向源图,沿垂直方向采用同样的逻辑,并将上下裁切部分考虑在内

常见的初步估算示例:

  • 对于 1024x1536 的源图,宽度仅约 707px 会保留下来;每侧约有 158px 会被裁掉;较安全的内容区域约为 x=216..808、y=92..1413
  • 对于 1242x2208 的源图,宽度仅约 1017px 会保留下来;每侧约有 113px 会被裁掉;较安全的内容区域约为 x=194..1048、y=132..2031

如果暂时还不知道确切的初始源图尺寸:

  • 假设使用常见的纵向源图,其宽度大于最终比例
  • 按每侧约有源图宽度的 10 to 16 percent 可能会被裁掉来处理
  • 初次生成时,将所有必须看清的文案、手机、面孔、标签、箭头和证明面板放在源图宽度中央 58 to 70 percent 的区域内
  • 这种保守的初步规则,比要求模型“留出一点边距”更可靠

对于文字或证明内容较多的幻灯片,采用更严格的默认规则:

  • 标题和辅助文案应位于画布中间约 70% 的区域内
  • 不要将重要文案紧贴最左侧或最右侧
  • 标签和侧边声明都应完整地位于同一安全区内
  • 与其让文字更靠近裁剪边界,不如先缩短文案

编写提示词时,明确告诉 Nano Banana:

  • 构图时要考虑之后会居中裁剪到最终的 App Store 尺寸
  • 所有关键文字和主要视觉元素都要远离边缘,留出充足的安全边距
  • 在边缘附近留出可供标准化裁掉的背景空间
  • 假设初次生成的纵向源图在居中裁剪时,每侧可能会损失约 10 to 16 percent 的宽度
  • 将所有必须看清的内容放在中央安全框内,而非铺满整个源画布
  • 标题、标签、CTA 提示或手机轮廓不要靠近原图的左右边缘

如果幻灯片只有在裁剪前看起来不错,那就还没做好。

6.6. 最终确认前,先进行裁切验证

生成主图后以及生成完整套图后:

  • 规范化当前输出
  • 目视检查规范化后的导出图,而不只是原生渲染图
  • 逐张实际查看图片
  • 检查标题、补充说明、截图边缘、标签或视觉面板是否有不自然的裁切
  • 检查裁切后手机画面是否依然显得恰到好处
  • 检查标题或视觉焦点周围是否仍留有充足空间
  • 使用联系表快速纵览,然后仍需全尺寸检查每张规范化后的幻灯片

如果规范化后的导出图存在裁切问题:

  • 修改源提示词
  • 增加边缘留白
  • 重新生成该幻灯片
  • 再次规范化
  • 再次检查新的规范化图片
  • 重复以上步骤,直到裁切效果明确可用

不要仅仅因为原始渲染效果不错,就将幻灯片标记为完成。 必须进行这套视觉验证循环,不能将其视为可选的润色步骤。

7. 单独处理品牌价值幻灯片

如果套图需要包含定价、离线使用、隐私、设备端 AI 或所有权相关的幻灯片:

  • 不要伪造应用界面
  • 不要使用与信息毫无关联的随机抽象图像
  • 构建以排版为主的价值主张幻灯片
  • 使用 2 到 3 个有意义且有质感的面板或视觉元素来传达主张
  • 考虑使用应用图标、吉祥物、类别物品、证书、奖励、路线、硬币或其他具体符号,而不是再放一部手机
  • 如果能改善宣传节奏,可让其中一张幻灯片成为真正的品牌广告,采用大字排版和极简 UI

优秀示例:

  • 用所有权卡片或购买隐喻表达一次性付款
  • 用无信号或本地模式视觉元素表达离线使用
  • 用私有设备 / 本地模型视觉元素表达设备端 AI
  • 使用清晰的视觉 CTA 提示,例如有意义的按钮、徽章、标签、箭头、开关或面板,让幻灯片更易快速理解,而不是变成大段文字

避免使用:

  • 机器人
  • 发光的大脑
  • 云朵陈词滥调
  • 密集的规格说明文案
  • 明明用更清晰的视觉元素就能表达,却仍添加额外解释文字
8. 规范化导出图

生成后,始终将最终导出图规范化为目标 App Store 尺寸。

默认的 iPhone 竖屏目标尺寸:

  • 1320x2868

如果用户指定了其他 Apple 槽位,则使用该确切目标尺寸。

使用随附脚本:

  • scripts/normalize_app_store_exports.py
  • scripts/build_contact_sheet.py

将每张幻灯片规范化为相同的目标尺寸。不要拉伸图像。先裁切至目标宽高比,再调整尺寸。 绝不要依赖图像模型直接返回最终 App Store 尺寸。

但同时:

  • 不要让规范化过程移除重要内容
  • 批量确认前,检查规范化后的图片本身
  • 如果裁切损害可读性或版式,则修改源生成提示词并重新生成
  • 每次重新生成后,都要再次规范化并检查新的规范化图片
  • 持续迭代,直到规范化后的导出图达到预期,而不只是源渲染图
  • 将完整规范化套图再次进行裁切验证,然后再标记为最终版

推荐的文件夹结构:

output/
  nano-banana-layout-plan.md
  prompt-log.md
  native/
    slide-01-...
    slide-02-...
  export-1320x2868/
    slide-01-...
    slide-02-...
  contact-sheet.png
9. 打包审核材料

最后,提供:

  • 版式规划文件
  • 最终导出文件夹
  • 如果使用了提示词日志,也一并提供
  • 供审核使用的联系表
10. 执行一致性 QA 检查

在宣布整套内容完成之前,请对照 references/quality-gates.md 进行检查。

如果发现以下任何问题,请先修改,再将作品作为完成版本提交:

  • 随机背景无法强化信息
  • 只是把截图放进样机中的平淡构图
  • 文案过小或过于冗长
  • 相邻幻灯片的排版节奏相同
  • 价值主张页看起来像泛泛的 AI 艺术图,而不是产品主张
  • 各张幻灯片看起来不像同一场连贯的营销活动
  • 截图中的文字读起来像补丁说明或功能标签
  • 整组内容无论按什么顺序排列都成立,因为没有讲述真实的故事
  • 任何幻灯片在第一轮处理后,规范化导出效果仍有哪怕一点裁切异常

提示词编写指南

使用祈使语气编写提示词,并明确设定硬性规则。

对于此技能:

  • 在计划或提示词日志中明确写出 Nano Banana
  • 将第 1 张幻灯片描述为 Nano Banana 风格锚点
  • 将后续幻灯片描述为基于该锚点衍生的一致变体
  • 生成前先检查 GEMINI_API_KEY,再检查 GOOGLE_API_KEY
  • 如果两个密钥都不存在,请向用户索要 Gemini API 密钥,并暂停生成,直到密钥可用
  • 不要因为缺少凭据而改用其他图像模型

始终包括:

  • 忠实保留截图
  • 不要重新设计应用 UI
  • 确保缩略图尺寸下的排版清晰可读
  • 必要时使用 <br /> 保持标题换行合理
  • 让幻灯片以广告为先
  • 每张幻灯片只聚焦一个想法
  • 先让视觉传达信息,再用文案帮助读者更快理解
  • 让幻灯片与风格锚点保持同一风格系列
  • 让视觉语言强化幻灯片要传达的信息
  • 使用规划好的 <br /> 文案时,将其转换为明确的提示词分行,不要直接粘贴该标记
  • 明确写出 do not render literal <br /> characters
  • 明确写出 use the same headline font family / type style as the anchor

生成没有截图的价值主张页时,请明确说明这一点。

失败模式

主动避免以下常见问题:

  • 用户要求使用 Nano Banana 时,未明确指定图像生成工具
  • 尝试使用 Nano Banana 生成前,跳过 Gemini 凭据检查
  • 在没有 GEMINI_API_KEY 或 GOOGLE_API_KEY 的情况下继续操作,并假装生成过程已解除阻碍
  • 因缺少 Gemini 密钥而改用其他图像模型
  • 跳过先撰写文案的阶段,或在标题定稿前就开始生成版式
  • 将截图文字写成产品功能文档,而不是广告论点
  • 直接将 <br /> 粘贴到图像生成提示词中,导致输出里渲染出该文本
  • 只保存一组输出,跳过原生文件和导出文件的拆分
  • 后续将未经处理或尺寸不同的锚点图像用作系列参考
  • 盲信模型返回的尺寸,而不进行标准化处理
  • 将文字或焦点视觉内容放得太靠近边缘,导致标准化裁切时被裁掉
  • 只检查原始渲染图,不检查标准化后的图像
  • 只进行一轮裁切,发现问题后却不反复调整直到解决
  • 将幻灯片做成文字广告牌,而不是内容丰富的产品广告
  • 主要用文字解释功能,而不是用视觉更清晰地呈现
  • 添加与应用类别或宣传信息毫无明确关联的随机图像
  • 多张幻灯片使用相同的模糊背景效果
  • 几乎每张幻灯片都采用相同的截图加标题版式
  • 每张幻灯片都塞满截图,导致整个宣传系列缺乏节奏
  • 即使大胆的文字主导或价值主张主导的广告幻灯片更能传达信息,也拒绝采用
  • 尚未确定风格锚点就生成所有幻灯片
  • 将版式计划视为可有可无
  • 在整套幻灯片中重复使用相同的模板结构
  • 相邻幻灯片上的手机摆放位置相同
  • 塞入过多功能文案,而不是聚焦于一条信息
  • 标题用“和”连接两个想法
  • 将功能列表用作标题
  • 使用模糊或充斥流行术语的标题,无法传达具体的用户收益
  • 构建一套截图可以随意调换顺序而不影响含义的幻灯片
  • 因原始渲染图看起来安全,就让文字密集的幻灯片过于靠近裁切边界
  • 让后续幻灯片偏离锚点的字体系列,或改用巨型文字卡片效果
  • 让装饰面板重复呈现相同文字,却没有增加任何含义
  • 将“AI”幻灯片做成陈词滥调的意象,而不是以产品为基础的价值面板

资源

references/

仅在需要时阅读:

scripts/

生成完成后使用这些确定性辅助脚本:

  • scripts/normalize_app_store_exports.py:将生成的幻灯片裁切并调整大小,使其符合统一的 App Store 尺寸
  • scripts/build_contact_sheet.py:根据标准化后的导出图生成审阅图

输出检查清单

完成前,请确认:

  • 该宣传活动以广告为先,而非以教程为先
  • 每张幻灯片只传达一个理念
  • 标题已在最终排版前撰写并锁定
  • 遮住 UI 后,单看文字也能讲述一个连贯的故事
  • 相邻幻灯片的版式各不相同
  • 这组幻灯片兼有简洁的证明型幻灯片,以及至少一张更具表现力、以广告为主导的幻灯片(视情况而定)
  • 这组幻灯片具有视觉节奏,而非重复使用同一种模板
  • 所有主张都有应用内内容作为依据
  • 这组幻灯片在视觉上保持一致
  • 所有导出内容都统一为同一种 App Store 尺寸

评论

支持 Markdown