1. 项目概述当AI成为游戏设计师最近在GitHub上看到一个挺有意思的项目叫commjoen/generated-game-experiment。光看名字你可能会觉得这又是一个用AI生成些简单像素画或者随机地图的玩具项目。但当我真正点进去把代码拉下来跑了一遍之后我发现它的野心和实现深度远超我的预期。这本质上是一个关于“生成式AI如何从零开始系统性创造一款完整游戏”的深度实验。简单来说这个项目探索的核心问题是我们能否将游戏设计的全过程——从核心玩法、世界观设定到关卡布局、角色属性乃至美术风格和叙事碎片——都交给一个或多个AI模型来协同完成它不是一个简单的“输入提示词输出游戏”的黑箱魔法而是一个精心设计的、模块化的、可观测的“AI游戏设计流水线”。开发者commjoen搭建了一个框架让大型语言模型如GPT-4和图像生成模型如Stable Diffusion像一支专业的游戏开发团队一样各司其职通过多次迭代和反馈最终产出一个可玩的、具有一定一致性和趣味性的游戏原型。这个实验的价值对于独立开发者、游戏策划甚至是对未来内容生产模式感兴趣的人来说都极具启发性。它不仅仅展示了AI的“生成”能力更关键的是展示了如何用工程化的思维去“引导”和“约束”AI的创造力使其产出符合特定领域游戏设计逻辑的、结构化的、可执行的内容。接下来我就结合自己的理解和实验为你深度拆解这个项目的设计思路、技术实现以及那些在实操中才会遇到的“坑”。1.1 核心需求与目标拆解为什么我们要做这样一个“生成式游戏实验”直接让人类设计师来做不就好了吗这个项目背后其实回应了几个更深层次的需求和探索方向第一探索创意辅助的边界。对于独立开发者或小型团队最大的瓶颈往往是创意和内容的产能。AI能否承担“初级策划”或“灵感引擎”的角色快速生成大量游戏设计草案、关卡创意、角色设定供人类筛选和深化这个项目试图验证AI生成的方案是否能在“量”的基础上达到一定的“质”的标准甚至能提供人类未曾想到的巧妙组合。第二验证结构化生成的可能性。游戏是一个高度结构化的产品角色属性需要平衡关卡难度需要递进叙事需要自洽。让AI生成一段故事或一张图片相对容易但让AI生成一套相互关联、数据平衡的规则集则困难得多。本项目通过定义清晰的JSON Schema数据模式和迭代规则引导LLM产出结构化的游戏数据这是其技术核心。第三构建端到端的生成流水线。从文本到数据再从数据到可运行的游戏资产和逻辑。项目不满足于只生成设计文档它要真正生成一个可以启动、可以游玩的“东西”。这意味着需要打通从LLM到游戏引擎或渲染环境的管道涉及代码生成、资产路径管理、运行时逻辑注入等一系列工程问题。第四研究生成内容的可控性与一致性。这是所有AIGC应用的共同挑战。在游戏语境下问题具体表现为AI生成的世界观和角色设定能否贯穿始终不在中途出现矛盾基于文本描述生成的图像能否保持统一的艺术风格项目通过“种子”控制、上下文记忆和迭代式精炼等机制来尝试解决这些问题。基于这些目标generated-game-experiment没有选择做一个大而全的庞然大物而是明智地采用“实验”的形式针对一个具体的、范围可控的游戏类型比如一款2D俯视角的冒险解谜游戏或Roguelike游戏来构建它的流水线。这种聚焦使得每一个环节的验证和调试都变得可行。2. 项目架构与核心模块解析这个项目的代码结构清晰地反映了其“模块化流水线”的设计思想。它不是一团乱麻的脚本而是由多个职责分明的组件构成。理解这个架构是理解它如何工作的关键。2.1 总览流水线式工作流整个生成过程可以看作一个分阶段的管道Pipeline前一个阶段的输出是后一个阶段的输入。一个典型的工作流可能如下概念生成阶段用户输入一个非常简单的初始想法或种子词如“深海探险”、“蒸汽朋克塔防”。主控LLM根据这个种子生成游戏的核心概念文档包括游戏名称、一句话简介、核心玩法循环、目标受众、艺术风格参考等。数据生成阶段以上述概念文档为上下文LLM被要求按照预定义的、极其详细的JSON Schema生成具体的游戏数据。这通常包括世界与关卡生成多个关卡的名称、描述、地形特征、敌人分布、宝物位置等。实体与角色生成玩家角色、敌人、NPC、物品等的属性生命值、攻击力、速度、技能、行为描述以及对应的图像生成提示词Prompt。叙事与对话生成背景故事碎片、关卡内的叙事文本、以及NPC的对话树。资产生成阶段将上一步中为每个实体生成的图像提示词提交给Stable Diffusion等文生图模型批量生成角色精灵图Sprite、物品图标、背景元素等2D美术资产。这一步通常依赖本地部署的SD模型或调用相关API。游戏构建阶段将生成的结构化数据JSON和图像资产通过一个游戏模板或运行时解释器实例化为一个可运行的游戏。这个模板可能是一个简单的HTML5游戏框架如Phaser.js、一个2D游戏引擎的预制项目或者是一个自定义的、能够解析JSON数据并渲染对应资产的轻量级引擎。测试与迭代阶段运行生成出的游戏观察其可玩性、一致性和是否存在明显Bug。根据结果可以手动调整提示词或数据Schema也可以设计一个反馈循环让AI根据测试日志自动进行微调和重新生成。在commjoen/generated-game-experiment的具体实现中上述阶段被封装在不同的脚本和配置文件中。你会看到类似prompts/存放针对不同任务的LLM提示词模板、schemas/存放定义数据结构的JSON Schema、generators/执行生成任务的脚本、assets/存放生成的图片和JSON数据以及game/游戏运行时模板这样的目录结构。2.2 核心模块深度拆解接下来我们深入几个最关键的模块看看它们是如何工作的。2.2.1 提示词工程与上下文管理这是驱动整个流水线的“大脑”。项目中的提示词Prompt绝非简单的“请设计一个游戏”而是精心设计的、包含以下要素的复杂指令角色设定首先为LLM赋予一个角色例如“你是一位经验丰富的独立游戏设计师擅长创造新颖的机制和引人入胜的世界观。”这能更好地对齐后续输出的风格。任务背景与约束明确告知LLM当前的任务阶段如“基于已批准的核心概念现在需要设计具体的关卡”以及必须遵守的约束如“关卡数量为5个”、“必须包含一种新的环境机制”。结构化输出格式这是最关键的部分。提示词中会直接嵌入JSON Schema的片段或者严格要求LLM以指定格式输出。例如请严格按照以下JSON格式输出关卡数据 { “levels”: [ { “id”: “unique_string”, “name”: “关卡名称”, “description”: “一段生动的描述”, “enemies”: [“enemy_id_1”, “enemy_id_2”], “rewards”: [“item_id_1”], “win_condition”: “描述如何通关” } ] }上下文注入在生成关卡时提示词中会包含之前已生成的世界观和角色数据确保LLM在设计新内容时能参考并保持与已有设定的一致性。这模拟了人类设计师在设计时会翻阅前期文档的行为。实操心得编写这类提示词时最大的挑战是平衡“创造性”和“可控性”。约束太多AI产出会僵化死板约束太少输出会天马行空无法使用。我的经验是采用“渐进式细化”策略先让AI进行头脑风暴宽松约束产出几个核心创意选项然后人类选择一个方向再让AI在更严格的Schema下进行细化设计。项目中的提示词模板通常已经过多次调优直接使用效果不错但如果你想生成特定类型的游戏对其进行微调是必要的。2.2.2 数据Schema设计如果说提示词是“需求文档”那么JSON Schema就是“数据契约”。它定义了游戏数据必须长什么样。一个设计良好的Schema是项目成功的基石。类型与验证Schema会明确定义每个字段的数据类型字符串、数字、数组、布尔值、是否必需、可选值枚举例如“difficulty”: [“easy”, “medium”, “hard”]甚至数值范围例如“hp”: {“type”: “number”, “minimum”: 1, “maximum”: 1000}。这能在数据生成阶段就过滤掉大量不合理的内容。引用与关联高级的Schema会定义数据间的关联关系。例如关卡数据中的“enemies”字段其内容必须是实体数据中已定义的敌人ID数组。这保证了生成的数据在逻辑上是自洽的不会出现关卡引用了一个不存在的敌人这种情况。在实现上这可能需要多轮生成先生成所有实体的ID列表再在生成关卡时引用这些ID。可扩展性Schema应该易于扩展。当你想为角色增加一个“能量条”属性时只需在角色Schema中添加相应字段并更新提示词即可而无需重写整个数据生成逻辑。在项目中你可能会看到一个game_schema.json文件它像一棵树一样定义了从游戏根对象到角色、物品、关卡等子对象的所有结构。2.2.3 资产生成与风格一致性这是从“数据”到“体验”的关键一跃。项目通常使用Stable Diffusion来生成2D图像资产。提示词工程图像侧LLM不仅生成数据还为每个需要图像的实体生成一个详细的文生图提示词。例如对于一个“锈蚀的机械哨兵”敌人LLM可能会生成“top-down view sprite of a rusty mechanical sentinel, with glowing red eyes, metallic texture, steampunk style, video game asset, clean background, 32x32 pixels, pixel art”。这个提示词综合了视角、主题、风格、技术规格等多个要素。风格锚定为了保持所有生成资产风格一致需要在所有图像提示词中加入一个共同的“风格锚定词”。这可以是一个具体的艺术家风格如“in the style of Hayao Miyazaki”一种艺术运动如“synthwave”或者一个通用的描述如“cohesive muted color palette, detailed line art”。这个锚定词通常来自最初生成的核心概念文档中的“艺术风格”部分。批量生成与后处理脚本会遍历所有需要图像的实体调用SD的API或本地实例批量生成图片。生成后通常还需要进行简单的后处理如统一裁剪到标准尺寸如32x32, 64x64、调整色板以确保视觉协调或者为精灵图生成对应的动画帧可能需要额外的提示词或img2img操作。注意事项图像生成是流水线中最不稳定、最耗时的环节。不同的SD模型版本、不同的采样器、甚至相同的提示词在不同时间运行都可能产生风格迥异的输出。强烈建议在正式批量生成前用小样本进行大量测试确定一组稳定的生成参数模型、采样器、步数、CFG值等。另外为每个资产生成提示词时可以要求LLM同时生成一个“负面提示词”Negative Prompt如“blurry, messy, extra limbs, text, watermark”以提升出图质量。2.2.4 游戏运行时与数据驱动生成了一堆JSON和PNG文件后如何让它们变成一个游戏这里有两种主流思路模板化引擎项目提供一个基础的游戏引擎模板这个模板是“数据驱动”的。它预先写好了游戏的核心循环如渲染、输入、碰撞检测但具体的游戏内容有哪些角色、关卡布局、属性数值完全从生成的JSON文件中读取。例如引擎中有一个通用的Entity类其hp,attack,sprite等属性在游戏初始化时从JSON数据加载。这种方式灵活性强生成的数据可以无缝“注入”到游戏中。代码生成更激进的方式是让LLM直接生成游戏代码如JavaScript/Phaser代码。这难度极高因为生成的代码必须语法正确、逻辑自洽且能与其他部分协同工作。目前更可行的混合方案是引擎模板提供一系列“积木块”函数、组件LLM的任务是生成如何组装这些积木块的“配置”或“脚本”而非从头编写所有代码。在commjoen的项目中更可能采用的是第一种方式。你会看到一个game/目录里面是使用某个轻量级框架可能是Pixi.js或一个自定义Canvas渲染器编写的基础游戏项目。index.html和game.js会包含从assets/data.json加载数据并据此创建游戏对象、渲染精灵图的逻辑。3. 实操复现搭建你自己的生成式游戏实验看懂了原理手痒想自己实现一遍下面我就带你走一遍核心的搭建和操作流程。请注意由于原项目可能更新以下步骤是基于其核心思想提炼的通用流程你需要根据实际情况调整。3.1 环境准备与工具选型1. 开发环境Python 3.8这是大多数AI相关库和脚本语言的首选。建议使用虚拟环境如venv或conda管理依赖。Node.js如果你的游戏运行时是基于Web技术如Phaser则需要Node.js环境来运行一个本地开发服务器。代码编辑器VS Code等现代编辑器即可。2. 核心工具链LLM接口你需要访问一个强大的LLM API。首选是OpenAI GPT-4 API它在遵循复杂指令和生成结构化JSON方面表现最佳。备选可以是 Anthropic Claude 3 或开源的 DeepSeek-V2。你需要准备好相应的API Key。图像生成有两种选择本地部署Stable Diffusion使用Automatic1111 WebUI或ComfyUI。优点是免费、可控性强、无频次限制。缺点是对显卡要求高至少6GB显存部署和调试有一定门槛。调用云API如Replicate、Stability AI或DALL-E 3的API。优点是简单快捷无需关心硬件。缺点是会产生费用且可能对生成内容有政策限制。游戏运行时框架可选如果你想快速看到可玩的结果选择一个简单的2D游戏框架会事半功倍。Phaser.js是一个极好的选择它基于HTML5文档丰富社区活跃非常适合做原型。你也可以用PygamePython或GodotGDScript但集成生成流水线可能需要更多工作。3.2 分步实现流程步骤一克隆与探索原项目首先将原项目克隆到本地这是最好的学习材料。git clone https://github.com/commjoen/generated-game-experiment.git cd generated-game-experiment仔细阅读README.md查看项目结构。重点关注prompts/、schemas/、generators/和game/目录下的文件。理解main.py或类似的主脚本是如何组织整个流程的。步骤二构建你的提示词与Schema不要急于运行别人的代码。先根据你想生成的游戏类型设计自己的核心数据Schema。从一个简单的开始比如一个只有玩家、一种敌人和一种物品的迷你RPG。创建my_schema.json定义Player、Enemy、Item、Level的基本结构。创建prompts/目录为每个生成任务写提示词文件。例如prompt_core_concept.txt: 用于生成游戏核心创意。prompt_generate_entities.txt: 用于根据核心概念生成实体角色、物品的JSON数据。prompt_generate_levels.txt: 用于生成关卡数据并引用已生成的实体ID。prompt_image_for_entity.txt: 用于为每个实体生成图像提示词。步骤三编写数据生成脚本创建一个Python脚本如generate_data.py使用openai库调用GPT-4 API。读取提示词模板使用Python的文件操作读取你的提示词文件。构建对话将提示词内容作为user消息发送给ChatCompletion API。对于需要多轮交互的任务如先生成ID再生成详情需要维护好对话历史messages列表。解析与验证GPT-4的回复是文本你需要从中提取出JSON部分。可以使用json.loads()配合一些简单的文本处理如查找“json”和“”标记。强烈建议对解析出的JSON用jsonschema库进行验证确保其符合你定义的Schema。如果验证失败可以将错误信息反馈给GPT-4要求它修正。保存数据将验证通过的JSON数据保存到assets/data.json。步骤四实现资产生成脚本创建另一个脚本如generate_images.py。读取数据加载上一步生成的assets/data.json。提取提示词遍历JSON中所有需要图像的实体获取其image_prompt字段。调用图像生成API如果使用Replicate安装replicate库按照其文档调用SDXL等模型。如果使用本地SD你需要通过HTTP请求调用本地WebUI的API。Automatic1111提供了/sdapi/v1/txt2img接口。使用requests库发送包含prompt,negative_prompt,steps,cfg_scale,width,height等参数的POST请求。保存与命名将返回的图像二进制数据保存为文件如assets/images/enemy_sentinel.png并确保文件名与实体ID关联以便游戏运行时正确加载。步骤五集成游戏运行时这是将静态数据变为动态体验的一步。准备游戏模板在game/目录下用Phaser创建一个最基础的项目。一个index.html一个game.js。game.js里初始化Phaser创建一个基础场景。加载数据在Phaser的preload函数中使用this.load.json(‘gameData’ ‘assets/data.json’)加载你的游戏数据。同时根据数据中实体的图片路径动态加载所有精灵图this.load.image(‘enemy_sentinel’ ‘assets/images/enemy_sentinel.png’)。这里需要一个循环来遍历数据中的所有实体。创建游戏对象在create函数中解析加载的JSON数据。根据关卡数据在场景中创建精灵this.add.sprite(x, y, ‘enemy_sentinel’)并将对应的实体属性如hp附加到该游戏对象上。实现基础逻辑实现最简单的交互比如用键盘移动玩家精灵当玩家与敌人精灵重叠时触发一个简单的战斗计算玩家攻击力减敌人生命值并在控制台输出日志。步骤六运行与迭代运行你的数据生成脚本python generate_data.py。运行你的图像生成脚本python generate_images.py。启动一个本地HTTP服务器在game/目录下运行python -m http.server 8000或使用VS Code的Live Server插件。打开浏览器访问http://localhost:8000查看生成的游戏。观察游戏是否可运行美术风格是否统一数值是否平衡很可能不平衡。记录下问题。回到步骤二修改你的提示词或Schema增加更具体的约束例如“敌人的生命值应该是其攻击力的3到5倍”然后重新运行流程。这就是迭代。3.3 关键配置与参数详解在整个流程中有几个关键的配置点直接影响生成质量LLM API调用参数model: 首选gpt-4-turbo-preview或gpt-4它在复杂任务上远优于gpt-3.5-turbo。temperature: 创造性任务可以稍高0.7-0.9但生成需要严格遵守格式的结构化数据时建议调低0.1-0.3以减少随机性。response_format: OpenAI API支持指定{“type”: “json_object”}这能显著提高模型输出标准JSON的概率。务必使用此参数。max_tokens: 根据你期望输出的数据量大小设置对于复杂的游戏设计文档可能需要2048或更多。图像生成参数以Stable Diffusion为例模型 checkpoint: 选择适合游戏美术风格的模型如pixel-art类模型、RPG类模型或通用的SDXL。采样器Sampler:DPM 2M Karras或Euler a是速度和质量的较好平衡。步数Steps: 20-30步通常足够。CFG Scale: 控制提示词相关性7-9是常用范围。尺寸Size: 根据你的游戏分辨率设定如512x512然后缩放到精灵图所需尺寸如32x32。负面提示词Negative Prompt: 通用模板如“ugly, blurry, low resolution, bad anatomy, extra limbs, text, watermark”能有效过滤低质量图像。4. 常见问题、挑战与优化策略在实际操作中你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的一些排查思路和优化技巧。4.1 数据生成阶段的典型问题问题1LLM不按Schema输出JSON或格式错误。现象返回的是纯文本描述或者JSON缺少引号、括号不匹配导致json.loads()解析失败。排查与解决强化指令在提示词开头用大写或显眼方式强调“你必须输出纯JSON不要有任何额外的解释和标记”。使用API的response_format如前所述这是最有效的手段。后处理与重试编写健壮的解析函数。先尝试用json.loads()解析整个回复。如果失败尝试用正则表达式如r‘json\n(.*?)\n’提取被代码块包裹的JSON。如果还失败可以将错误信息和原始回复再次发送给LLM要求它修正。实现一个带有重试机制的生成函数是很有必要的。问题2生成的内容缺乏创意或过于天马行空。现象每次生成的都是类似“骑士打败恶龙”的俗套故事或者相反生成一个完全无法理解的怪异设定。排查与解决调整Temperature提高温度值如0.8可以增加随机性降低如0.2则更倾向于常见模式。提供更丰富的种子不要只给“奇幻游戏”四个字。尝试更具体的种子如“在一个由发光蘑菇提供照明的巨大地下洞穴网络中进行的邮政服务模拟游戏”。分阶段生成与人工筛选先让LLM生成5-10个核心概念人工挑选最有潜力的一个再基于它进行后续细化。将人类作为“创意总监”介入关键节点是保证质量的最有效方法。问题3数据关联性错误。现象关卡中引用了不存在的敌人ID或者物品的效果描述与属性数值不匹配。排查与解决改进Schema设计在生成关卡数据的提示词中明确列出所有已生成的实体ID和名称让LLM从中选择。例如“以下是所有可用的敌人类型[‘rusty_sentinel’ ‘crystal_slime’ …]。请从该列表中选择。”两阶段生成第一阶段生成所有实体的ID和基本信息列表。第二阶段在生成关卡、对话等内容时将这个列表作为上下文提供。生成后验证编写一个验证脚本在保存数据前检查所有引用关系是否有效。4.2 资产生成阶段的典型问题问题4图像风格不一致。现象生成的玩家角色是卡通风格敌人却是写实风格放在一起非常突兀。排查与解决统一风格锚定词确保所有图像提示词都包含完全相同的风格描述。这个描述应该来自最初生成的核心概念文档并在整个流程中作为常量传递。使用模型LoRA或Embedding如果你使用本地SD可以为特定风格训练一个LoRA模型或者在提示词中加入该风格的Textual Inversion embedding。这能极大地增强风格一致性。生成后统一处理使用图像处理工具如Photoshop脚本或Python的PIL库对所有生成图像进行统一的色彩调整、滤镜处理使其色调和对比度趋同。问题5生成图像的内容不符合预期。现象提示词是“正面的骑士肖像”但生成的是侧身或全身像或者“一把剑”生成成了“一把刀”。排查与解决精炼提示词在图像提示词中加入更明确的描述视角、构图、焦点。例如“front view, close-up portrait of a knight‘s face and helmet” “isometric view of a sword lying on a stone altar”。使用ControlNet这是解决构图问题的神器。你可以先画一个简单的草图例如一个表示精灵图边界的方框里面用色块标明大概的头部、身体位置然后使用ControlNet的Canny或Scribble模型让SD严格按照草图的轮廓和姿势生成图像。这对于生成统一视角的游戏精灵图至关重要。迭代生成img2img如果第一次生成结果尚可但细节不对可以将它作为初始图像用较低的去噪强度denoising strength 0.3-0.5和修改后的提示词进行重绘微调细节。4.3 游戏集成与可玩性问题问题6生成的数据导致游戏不平衡或无法游玩。现象敌人攻击力过高玩家被秒杀或者关卡目标无法达成。排查与解决在Schema中定义数值约束这是预防的第一道防线。明确设定属性的合理范围如玩家初始HP 100-150敌人攻击力10-30。设计平衡规则并写入提示词将简单的游戏平衡规则告诉LLM。例如“确保第一个关卡的敌人总强度生命值*数量不超过玩家初始攻击力的5倍。”实现模拟与自动调整编写一个简单的模拟器用生成的数据跑1000次虚拟战斗计算玩家通关概率。如果概率过低或过高可以自动按比例调整敌人属性或触发重新生成。这是一个更高级但非常有效的自动化平衡手段。问题7游戏运行时加载或逻辑错误。现象控制台报错图片加载失败精灵不显示或者交互无反应。排查与解决路径检查确保游戏运行时加载的JSON和图片路径与生成脚本输出的路径完全一致。这是最常见的错误来源。数据格式检查在游戏加载数据后立即在控制台打印出解析后的对象检查其结构是否与代码期望的完全一致。属性名的大小写、嵌套层级都可能是坑。逐步集成不要一次性集成所有生成内容。先用手工编写的、绝对正确的迷你数据集测试游戏逻辑。确认无误后再用AI生成的数据替换并观察哪里出了问题。4.4 流程优化与进阶思路当你解决了基本问题后可以考虑以下优化让整个系统更强大、更自动化并行化生成图像生成是瓶颈。可以使用异步IOPython的asyncioaiohttp并发调用SD API或者将任务分发到多个GPU上大幅缩短等待时间。引入评估与反馈循环构建一个简单的评估函数基于规则如“关卡多样性分数”、“数值平衡分数”、“艺术风格一致性分数”对每次生成的结果打分。如果分数低于阈值则自动调整提示词例如加入“请增加更多样的环境机制”的要求并重新生成该部分内容。利用LLM进行自我调试当游戏运行时出现逻辑错误如NPC说了不符合设定的话可以将错误上下文和游戏数据喂给LLM让它分析问题可能出在哪里是原始设定矛盾还是生成对话时忽略了上下文并提出修改建议甚至直接生成修复后的数据补丁。从2D迈向3D思路可以扩展。使用LLM生成3D模型的描述提示词然后利用如Shap-E、TripoSR等文生3D模型或者使用Blender脚本结合AI生成纹理来创建简单的3D游戏资产。这将是下一个前沿挑战。这个项目就像打开了一扇门它向我们展示了用AI协同创造复杂数字产品的可能性路径。它不是一个完美的、可以替代人类游戏设计师的成品而是一个强大的“创意加速器”和“原型生成器”。最大的收获不在于生成了多好玩的游戏而在于理解了如何将模糊的创意通过结构化的工程方法一步步转化为具体的、可交互的数字体验。这个过程本身对任何从事创造性或软件开发工作的人都具有深刻的启发意义。我个人的体会是最重要的不是追求全自动化而是找到人机协作的最佳结合点——让AI负责发散、量产和初步结构化让人负责收敛、评判和深度创意。