Reddit 上的 Nano Banana 提示词：别照抄，先提炼结构再测试

Reddit 上的 Nano Banana 提示词值得看，因为它们暴露了真实用户怎样描述产品图、角色、风格、镜头、编辑任务和失败经验。但一条在别人截图里好看的提示词，不会自动适合你的商品、角色设定、参考图、广告版式、可读文字或 API 批量任务。正确动作不是收藏更多整段文本，而是先把它拆成结构，再换成自己的任务条件。

把一条社区提示词放进工作流前，先做四个判断：

截至 2026 年 5 月 18 日，涉及路线和模型 ID 的事实要看 Google 官方文档：开发者语境里 Nano Banana 2 对应 gemini-3.1-flash-image-preview，Nano Banana Pro 对应 gemini-3-pro-image-preview，原始 Nano Banana 对应 gemini-2.5-flash-image。Reddit 能提供表达方式和真实失败样本；官方文档才定义模型名、访问方式、计费边界和安全行为。

停止规则很简单：同一结构在你的任务里连续两次失败，就不要继续堆形容词；如果问题来自文字排版、身份一致性、参考图继承、批量调用或安全拦截，就先换路线或改任务，而不是继续复制更多提示词。

先判断这条提示词解决了什么任务

一条提示词是否值得保存，第一标准不是语言华丽，而是任务清楚。它到底是做商品主图、角色设定、海报创意、室内空间、食物摄影、信息图、局部编辑，还是参考图一致性？如果任务都说不清，后面再多“电影感”“超真实”“高细节”也救不了。

很多社区范例看起来很强，是因为主体、场景和镜头已经被写清楚了。比如“磨砂黑台灯放在胡桃木书桌上，左侧柔光，右侧留标题空间”比“高级感产品图”可靠得多。前者能控制材质、位置、光线和用途；后者只表达审美愿望。

保存前可以给提示词贴三个标签：

如果只能给出“看起来更好”“更爆款”这样的标签，就不要把它当作工作提示词。它最多是灵感，不是流程资产。

先选 Nano Banana 路线，再改提示词

提示词失败时，很多人第一反应是把句子写得更长。实际更常见的原因是路线错了。快速灵感、参考图编辑、文字版式、API 批量和多图一致性不是同一个问题。

Gemini 应用适合快速试方向。你可以用它探索构图、风格、氛围和初步视觉语言，但它不是生产日志、批量重试和模型 ID 管理的最佳位置。

参考图编辑适合保护已有主体。只要任务里出现真实产品、固定角色、房间布局、服装、脸型、道具或品牌物料，就要把“保持不变”的内容写在前面，而不是把风格形容词塞满。

Nano Banana Pro 更适合文字、版式、图表、信息板、流程图和需要组织能力的视觉任务。它不是每张图都必须使用的默认答案。简单探索可能用更短、更干净的提示词更快；复杂信息图才需要 Pro 的结构化要求。

AI Studio 或 API 适合开发者任务：模型 ID、请求体、批量、日志、失败重试、成本估算和输出归档都要可控。社区里“这段能用”的说法不能替代你自己的请求记录。

把整段提示词拆成可复用字段

可复用提示词不是一袋形容词，而是一组可替换字段。看到一段很长的社区提示词时，不要先复制；先把它拆成“任务、主体、场景、风格、构图、光线、约束、参数、验收”。

推荐保存成这种结构：

hljs text复制
图像任务：
主体与上下文：
构图与镜头：
光线与色调：
风格或输出格式：
必须保持的细节：
必须避免的错误：
路线或参数：
验收标准：

这套字段的价值在于它能迁移。别人的“赛博战士雨夜肖像”不一定有用，但它背后的结构有用：清晰主体、可感知环境、明确镜头、固定光线、风格边界、禁止项和验收标准。把主体换成你的产品、角色或空间后，提示词才真正进入你的流程。

字段也能帮助团队协作。设计、运营和开发看到同一条提示词时，可以讨论“主体锚点不够”“文字要求太多”“参考图保护缺失”“验收标准不可测”，而不是争论这句话是不是够有感觉。

适合保留的几类 Reddit 提示词模式

不是每类提示词都值得进库。下面这些模式更容易转成工作资产，因为它们有明确任务、可替换字段和可测试结果。

商品主图

商品提示词的重点是材质、场景、光线和商业用途。不要只写“高级感”，要写出高级感来自什么。

hljs text复制
为 [产品] 创建一张商业主图，放在 [表面/环境] 中。
使用 [光线]、[阴影] 和 [背景处理]。
镜头为 [角度/焦段感]，主体必须保持清晰。
不要添加额外 logo、手、变形文字或改变产品形状。
验收：三次输出里产品形状、材质和关键卖点都能识别。

这类提示词适合电商首图、广告提案、包装概念和产品视觉探索。真正要改的是产品、材质、品牌色和使用场景，而不是把“viral”“luxury”这类词原样留下。

角色和身份一致性

角色提示词最容易被成片误导。单张图漂亮不等于角色能保持一致。要保存的是身份锚点和失败条件。

hljs text复制
生成 [角色描述] 在 [场景] 中的肖像。
保持 [脸型、发型、服装、标志物、年龄感] 一致。
使用 [风格] 和 [镜头距离]，表情为 [具体情绪]。
不要改变年龄、面部结构、服装颜色或标志物。
验收：三次输出里身份锚点稳定，否则改用参考图路线。

如果角色要用于连载、短剧、品牌 mascot 或故事板，文本提示词只是起点。只靠文字很难保证连续性，参考图和多参考图路线更重要。

信息板和文字版式

信息图、菜单、流程图、对比表、教学板不是“请做一个 infographic”就能稳定完成的任务。提示词必须定义内容层级。

hljs text复制
创建一张面向 [读者] 的信息板，解释 [主题]。
必须包含这些板块：[板块 1]、[板块 2]、[板块 3]、[板块 4]。
每个板块使用短标签、充足留白和清晰层级。
必须准确出现的文字：[文字]。
避免虚构数字、额外标签和装饰噪音。
验收：所有指定文字可读，且没有新增事实声明。

这类任务通常更适合 Pro 路线。尤其当画面里有标题、表格、步骤、标注和品牌措辞时，成功标准应该放在提示词里，而不是生成后再凭感觉判断。

局部编辑和前后对比

编辑提示词的核心是“改什么”和“保留什么”。很多失败来自只写了目标效果，没有写保护边界。

hljs text复制
编辑输入图，让 [具体变化] 发生。
保持 [人物/产品/姿势/背景/透视/文字] 不变。
匹配原图的镜头角度、光线方向和透视。
不要新增物体、改变身份、改写背景布局或修改可见文字。
验收：变化明显，但受保护细节仍与原图一致。

只要任务涉及真实产品、人物、房间、包装或已有素材，就把保护规则放在风格词前面。否则模型可能做出好看的图，但破坏了真正要保留的部分。

同一提示词先做小样测试

提示词库不能只保存“看过不错”的句子。至少要保存一次小样测试，才知道它能不能被复用。

小样测试用一版基准和两版变量：

1. 基准版：把 Reddit 模式改成自己的干净提示词。
2. 变量 A：只改一个视觉变量，比如镜头或光线。
3. 变量 B：只改一个路线变量，比如需要文字、参考图保持或版式复杂度。

评分不要写成“喜欢/不喜欢”。用可观察标准：

平均分达到 4，且没有关键项低于 3，才值得保存。某次偶然生成惊艳但不可复现的提示词，只能当灵感。能解释为什么通过、为什么失败、什么时候换路线的提示词，才是团队资产。

什么时候不要继续改提示词

提示词工程不是绕过系统，也不是把失败句子改到无限长。遇到以下情况应停止。

第一，任务本身不合规。欺骗、冒充、私人信息、未经同意的相似形象、绕过拦截或规避限制的写法，不应该进入提示词库。需要的是改成合规创意任务，或直接丢弃。

第二，承诺不可验证。任何“百试百灵”“永久最佳”“一定出大片”的说法都不是证据。证据是结构、路线和你自己的小样结果。

第三，把消费端和 API 混在一起。Gemini 应用中能用，不代表同一句在某个 API 模型 ID、请求体、速率限制和计费环境下也能用。开发者路线要记录模型、请求、时间、输出和错误。

第四，提示词库越来越像素材坟场。只保存成片和整段文字，会让以后的人无法判断该怎么改。库里应该有结构、路线、输入要求、停止条件和测试记录。

建一个小而可靠的提示词库

提示词库应该按任务组织，而不是按来源组织。一个能解释清楚的 20 条模式，比一千条看不完的复制文本有用。

库越小，维护越容易。每次加入新提示词，都要能回答三个问题：它解决什么任务？它依赖什么路线？它通过什么测试？回答不上来就不要入库。

从社区范例改成自己的提示词

改写时不要只替换名词。真正要换的是任务语境、素材约束和验收标准。可以按“保留骨架、换业务、加检查”的顺序走。

假设看到的范例是一个“电影感咖啡杯海报”。直接把咖啡杯换成你的耳机，通常会失败，因为原提示词里的杯子、蒸汽、木桌和暖光承担了画面结构。更好的改写是先提炼骨架：单一主体、桌面近景、左侧柔光、后景虚化、右侧留标题、无多余文字。然后把业务条件写进去：耳机外壳材质、耳罩角度、品牌色、包装是否出现、标题区域的留白位置、需要避免的手和伪 logo。

可以这样拆：

角色提示词也一样。看到一个漂亮人物范例时，不要保存“超真实、电影级、8K、情绪化肖像”这类壳。要保存的是身份锚点：脸型、发型、服装颜色、年龄感、关键道具、表情和场景关系。下一次换角色时，先替换这些锚点，再决定是否需要参考图。只靠文本写“保持同一个人”往往不够，尤其是多张图要连续使用时。

信息板提示词更需要改写。社区范例里的板块数量、图标、标题和配色可能看起来好，但你的内容如果有事实、数字、流程或合规要求，就不能把模板直接搬过来。先写清楚必须出现的标签，再写哪些词不能被模型自由发挥。比如“价格”“上限”“免费”“官方”这些字眼，只要不是当前证据能支撑，就不要交给图像模型自由编。

让团队按同一套验收语言沟通

提示词库如果只给创作者看，可以很松；如果要给团队反复用，就需要统一验收语言。否则运营说“更高级”，设计说“更干净”，开发说“模型不稳定”，三个人其实在谈三种问题。

建议把每条提示词的验收写成可勾选项：

这样的表格能减少“我觉得还不错”的争论。每次小样测试后，只记录失败项和下一步动作。比如“主体准确 5，文字可信 2，所以减少文字并改 Pro 路线”；或者“构图可用 2，所以保留提示词结构但换镜头描述”。记录动作比记录情绪有用。

当提示词被多人复用时，还要给它加版本。不要覆盖旧提示词。保留通过版本、失败版本、改变原因和适用场景。这样后面看到某条社区范例时，不会因为它像旧版本就盲目加入，而是能看出它补的是哪个缺口。

不要把热门清单当成排名

社区里常见“100 条”“500 条”“1000 条”“按赞数排序”的合集，这些东西适合快速浏览，不适合作为可靠性排名。点赞和收藏只能说明那张示例在某个圈层里有吸引力，不能说明它在你的路线、尺寸、参考图、语言和业务约束里稳定。

热门清单最适合做两件事。第一，看大家经常怎样命名任务：产品照、头像、3D 角色、信息图、室内、食物、海报、前后对比。第二，看失败讨论集中在哪里：提示词太短、参考图不稳、Nano Banana 2 和 Pro 表现不同、文字被拦、角色漂移、生成路线和编辑路线混用。

把清单读成“任务地图”，不要读成“标准答案”。当你发现很多人都在问同一个问题，例如“为什么同样提示词在 Pro 和 2 里表现不同”，那说明你的提示词库需要一条路线判断，而不是再复制十条相似提示词。当你发现很多合集都在展示产品图，那说明商品主图是高频任务，但仍然需要你自己的材质、场景和验收标准。

真正值得保存的不是“第 37 条提示词”，而是“这类提示词为什么能工作、什么时候会失败、失败后换哪条路线”。这三件事讲清楚，社区清单才会变成你的生产资料。

把失败也写进提示词库

很多提示词库只保存成功图，结果下次复用时仍然踩同样的坑。失败记录不是负担，它会告诉你这条结构的边界在哪里。至少记录三类失败：主体漂移、路线不匹配、验收不可测。

主体漂移要写清楚“漂移了什么”。是脸型变了，服装颜色变了，产品比例变了，还是背景里多了无关物体？如果只是风格偏了一点，可以改镜头、光线和色调；如果身份、产品形状或空间结构变了，通常要换参考图路线。不要把这两类失败都写成“效果不好”。

路线不匹配要写清楚“原来想用什么路线，后来应该换什么路线”。比如信息板文字错，不一定是提示词不够细，可能是文字量超过了当前路线适合处理的范围；角色连续图不稳，不一定是描述不够长，可能是缺少参考锚点；批量生成时结果波动大，不一定是社区范例差，可能是你没有记录模型 ID、请求体和重试条件。

验收不可测要写清楚“下次怎样测”。如果提示词只写“更自然”“更高级”“更像广告”，团队很难判断是否通过。把它改成“主体占画面 60% 左右”“右侧保留标题区域”“指定文字不超过 12 个字”“三次输出里产品颜色一致”。可测的提示词不一定更长，但一定更容易复用。

失败记录还可以保护团队不被热门范例反复带偏。某个风格可能在一张图里好看，但每次做产品图都会把材质弄错；某个角色模板可能适合头像，却不适合多镜头故事板；某个信息图模板可能视觉密度强，却容易虚构标签。把这些边界写清楚，比继续收藏更多相似提示词更有价值。

最后给每条失败记录留一个“下次动作”。动作可以是改字段、换路线、减少文字、加入参考图、拆成两张图、或直接删除。只要动作清楚，失败就不会变成噪音；它会让提示词库越来越小，也越来越可靠。团队复盘时也能快速看出哪些模式值得继续投入，哪些模式只是热闹但不稳定，避免下一次又从同一个坑开始，也避免把偶然好图误当成稳定方法和团队长期标准。

常见问题

Reddit 上的 Nano Banana 提示词真的更好吗？

它们更适合发现表达模式，不一定更适合直接使用。真正有价值的是结果背后的结构：主体、场景、风格、构图、约束和验收标准。没有路线和复现记录的“最佳提示词”，只能算灵感。

能不能直接复制整段提示词？

可以用于一次快速试验，但不适合进入工作流。只要主体、品牌、尺寸、参考图、文字要求或成功标准不同，整段复制就会带入别人的条件。长期保存时应该保存字段结构，而不是保存原句。

Nano Banana Pro 应该用什么提示词格式？

Pro 更适合结构化提示词，尤其是文字、版式、图表和信息板。写清输出类型、层级、精确文字、保护约束和验收标准。简单图像探索可以短一些，不必为了显得专业而堆长句。

JSON 提示词会更稳定吗？

JSON 能帮助团队或 API 工作流保持字段一致，但它不会自动让弱提示词变强。只有当 JSON 清楚表达主体、场景、风格、构图、约束、参考、输出格式和测试条件时，才值得使用。

先用 Gemini 应用还是 API？

想快速探索视觉方向，先用 Gemini 应用。要保护参考图或身份一致性，走参考图路线。要做文字、版式或信息板，考虑 Pro。需要批量、日志、模型 ID 和集成控制，再进 AI Studio 或 API。

提示词生成器值得用吗？

可以用来补字段，不要让它替你决定任务。生成器给出的句子仍然要经过任务、路线和测试三关。如果它加入未验证承诺、绕过措辞或无关装饰，就删掉。

一条提示词反复失败怎么办？

先分类失败。结构模糊就重写结构；参考漂移就换参考图路线；文字失败就减少文字或使用 Pro；路线报错就排查路线；安全拦截就改成合规任务或停止。不要把所有失败都当成“形容词不够多”。