企业官网建设流程全解析

先交代一下这次实验的起因。之前一直想做一个氛围向的恐怖游戏，但美术资产、程序脚本、叙事文案三座大山堆在一起，进度始终卡在“空房间打转”的阶段。后来决定换一条路：让AI来写核心玩法、生成剧情台词、甚至输出可用的语音素材。结果流程跑通之后，最意外的不是Demo能跑，而是AI生成的剧情和音频在深夜测试时真的把自己吓到了。这篇文章会把整套流程完整拆开，包括工具选型、Prompt设计、Godot 4 代码实现、中英双语叙事生成、音效合成以及AI辅助开发中的避坑经验，适合想用AI加速独立游戏原型开发、又怕被“幻觉代码”带偏的开发者参考。

1. 为什么恐怖游戏是最适合AI辅助的实验场

1.1 恐怖游戏开发的核心难点

恐怖游戏和普通休闲游戏最大的区别，在于它的核心体验是“情绪”。玩家需要的不是爽快的反馈，而是持续的紧张感、未知感和压迫感。这种体验对资产质量、节奏控制、叙事氛围要求非常高，直接导致恐怖游戏是独立开发者最难完成的一种类型。

具体来说，难点集中在几块：

• 场景氛围：黑暗走廊不是简单地把灯光调暗，而是要控制明暗对比、镜头晃动、音效层次。
• 剧情文本：恐怖游戏需要有日记、纸条、录音、怪物低语等碎片化叙事，文本量大且需要风格统一。
• 玩法脚本：保险丝、密码锁、钥匙、追逐战、隐藏区域，交互逻辑又多又碎。
• 音频资产：脚步声、心跳、低频嗡鸣、贴脸jump scare，普通开发者很难独立制作。

这些环节恰恰是AI大语言模型、AI绘画、AI音频工具目前最擅长的领域。AI不一定能直接给你一个完整上架的恐怖游戏，但能把一个Demo的产出效率提升好几倍。

1.2 AI能在哪些环节介入游戏开发

很多人对AI辅助游戏开发的认知还停留在“让AI写一段代码”。但从这次实验来看，AI在恐怖游戏开发中的参与度可以覆盖整个production pipeline：

所以这次的实验选了恐怖游戏，不是因为它最简单，而是因为它最能展示AI辅助开发的价值——一个内容量极大的品类，正好需要AI来“填内容”。

1.3 本次实验的目标

文章里的实战部分，目标是制作一个可运行的3D第一人称恐怖游戏Demo，名字叫 The Corridor。玩家在一条废弃研究走廊里醒来，需要找到三份日记碎片，每找到一份，就会解锁一段AI生成的恐怖文本。与此同时，走廊深处有一个会主动追踪玩家的怪物，玩家被追上就会触发游戏结束。

为了让“中英双语”这个特性不只是一个标题噱头，整个项目的叙事文本会刻意做成英文原始文本 + 中文翻译对照的形式，最后还会用TTS把关键台词合成为音频直接放进游戏里。这样就能完整验证 AI从文本、到代码、再到音频的全链路能力。

2. 环境准备与工具选型

2.1 为什么选择Godot 4

AI辅助开发游戏，引擎选型非常重要。Unity和Unreal是行业主流，但如果在AI生成代码的场景下比较，Godot 4 有很明显的优势：

对AI辅助开发来说，最关键的是“AI生成代码的准确率”。Godot 4的GDScript语法简洁，节点树组织清晰，大语言模型训练数据中包含大量Godot代码示例，因此生成的脚本通常能接近可运行状态。如果选择Unity，AI生成的C#脚本经常因为Render Pipeline、Input System新老版本差异而报错。

版本说明：本文的实战案例使用 Godot 4.x。不同小版本的API略有差异，但本文使用的 PlayerController、CharacterBody3D、Area3D、RayCast3D 都是4.x通用API，没有绑定某个特定的次级版本。如果你使用的是 Godot 3.x，请注意对应API会有明显不同。

2.2 AI工具链组合

这次实验用到的AI工具并不多，关键是搭配合理：

• 对话式大模型：用于生成代码、剧情、设计文档，例如 ChatGPT、Claude、通义千问、文心一言等，只要支持长上下文都可以。
• AI绘画工具：用于生成参考概念图，例如 Midjourney、Stable Diffusion WebUI，用来为场景氛围和怪物外观定调。
• TTS工具：使用 edge-tts 或云端TTS把AI文本转成音频，这是低成本生成恐怖语音的最佳方式。
• 代码编辑器：VS Code 或 Godot 内置编辑器，配置好 GDScript 语法高亮即可。

在实际项目中，也可以接入“AI编程助手”插件，比如在VS Code中安装Continue、通义灵码、CodeGeeX等，让代码补全直接在编辑器里完成。

2.3 安装Godot并创建项目

首先到 Godot 官网下载对应系统的标准版，解压后直接运行。不需要额外安装依赖。

打开后新建项目，选择3D场景模板，项目名字可以写成TheCorridor。项目创建完成后，整个项目文件夹结构如下：

TheCorridor/ ├── project.godot ├── assets/ │ ├── audio/ │ ├── models/ │ └── textures/ ├── scenes/ │ ├── main.tscn │ └── player.tscn └── scripts/ ├── player.gd ├── enemy.gd ├── interactable.gd └── game_manager.gd

后续所有代码和资产都会按这个结构组织。

3. 用AI做需求设计与Prompt工程

3.1 先拆需求，再让AI写代码

很多开发者让AI写游戏脚本，得到一堆跑不起来的代码，核心原因不是AI能力不行，而是没有把需求拆到位。恐怖游戏这类复杂项目，需求描述越模糊，AI输出的代码越容易偏离目标。

正确的做法是先把整个项目拆成最小可玩单元。对 The Corridor 来说，我把它拆成了五个部分：

1. 玩家控制：第一人称视角、WASD移动、鼠标视角、与物体交互。
2. 地图场景：一条封闭走廊，有若干房间门、灯光、可拾取物品。
3. 敌人AI：怪物在走廊里巡逻，发现玩家后追向玩家，碰到玩家造成游戏结束。
4. 拾取与日记系统：玩家靠近日记，按E键拾取，屏幕显示日记内容。
5. 音频与氛围：背景低频音、脚步声、怪物低语、拾取日记时播放语音。

每个部分再继续拆分，直到可以形成一条清晰的Prompt指令。

3.2 让AI生成设计文档

需求拆解后，可以让AI输出一份结构化的游戏设计文档。下面是一段实际使用的Prompt示例：

你是一名资深恐怖游戏策划。请为以下需求撰写一份游戏设计文档（GDD）， 要求结构清晰、可直接用于开发： 游戏名：The Corridor 类型：第一人称心理恐怖 平台：PC 核心玩法：玩家在废弃研究走廊中寻找3份日记碎片，每次拾取会触发 一段恐怖叙事文本，同时怪物会逐渐逼近玩家。 怪物机制：怪物初始在地图远端待机，当玩家拾取日记后，怪物会向玩家 当前位置移动，玩家可以通过跑动拉开距离。 胜利条件：收集全部3份日记并到达出口。 失败条件：怪物接触玩家。 胜利/失败都要播放结局画面。 请输出：核心循环、场景结构、怪物行为列表、玩家能力列表、UI界面列表。

AI输出的GDD不需要完全照做，但可以作为项目开发的需求列表，后续所有Prompt都可以引用这份文档，避免会话上下文丢失。这种方式比每次从零描述要高效得多。

3.3 Prompt技巧：给AI设定角色与输出约束

在让AI生成代码时，最常见的失败原因是输出格式混乱、没有上下文、代码与引擎版本不匹配。有效的Prompt应该包含四个要素：

1. 角色设定：让AI以“资深Godot开发者”的身份回答。
2. 技术栈：明确引擎版本和语言。
3. 输出约束：要求给出完整代码、注释和挂载位置。
4. 上下文：贴入项目结构和已有代码片段。

例如：

你是一名资深Godot 4开发者，请用GDScript编写一个第一人称玩家控制器脚本。 要求： 1. 使用CharacterBody3D作为根节点。 2. 相机挂在玩家节点下，负责鼠标视角旋转。 3. 支持WASD移动、空格跳跃、Shift加速跑。 4. 实现射线交互，按E键与Interactable对象交互。 5. 每个关键步骤都要有中文注释。 6. 输出完整脚本，并说明节点树应该如何搭建。

用这种方式生成的脚本，质量明显高于“帮我写一个玩家控制器”这种模糊请求。

4. 实战：用AI搭建可运行的恐怖游戏Demo

4.1 搭建Player场景

在Godot中新建一个场景，根节点类型选择CharacterBody3D，命名为Player，然后保存为scenes/player.tscn。

节点树结构如下：

Player (CharacterBody3D) ├── Camera3D ├── RayCast3D ├── CollisionShape3D └── AudioStreamPlayer3D

其中Camera3D是玩家的眼睛，RayCast3D用于交互检测，CollisionShape3D负责碰撞体积，AudioStreamPlayer3D用于播放脚步等3D音效。

4.2 AI生成玩家控制脚本

玩家控制脚本是整个项目最基础、也最重要的代码。把上面那条Prompt交给AI生成后，再人工调整完善，得到的核心代码类似下面这样：

# 文件路径：scripts/player.gd extends CharacterBody3D ## 基础移动参数 @export var move_speed: float = 4.0 @export var sprint_speed: float = 6.5 @export var jump_velocity: float = 4.5 @export var mouse_sensitivity: float = 0.002 @export var interact_distance: float = 3.0 ## 重力与加速度参数 var gravity: float = 9.8 var current_speed: float = 0.0 ## 节点引用 @onready var camera: Camera3D = $Camera3D @onready var raycast: RayCast3D = $RayCast3D @onready var audio_player: AudioStreamPlayer3D = $AudioStreamPlayer3D func _ready() -> void: # 隐藏鼠标指针，进入第一人称视角 Input.set_mouse_mode(Input.MOUSE_MODE_CAPTURED) # 设置交互射线检测距离 raycast.target_position = Vector3(0, 0, -interact_distance) func _unhandled_input(event: InputEvent) -> void: # 鼠标控制视角旋转 if event is InputEventMouseMotion and Input.get_mouse_mode() == Input.MOUSE_MODE_CAPTURED: rotate_y(-event.relative.x * mouse_sensitivity) camera.rotate_x(-event.relative.y * mouse_sensitivity) # 限制相机俯仰角，防止视角翻转 camera.rotation.x = clamp(camera.rotation.x, -1.4, 1.4) # 按ESC释放鼠标，便于调试 if event.is_action_pressed("ui_cancel"): Input.set_mouse_mode(Input.MOUSE_MODE_VISIBLE) func _physics_process(delta: float) -> void: # 处理重力 if not is_on_floor(): velocity.y -= gravity * delta # 跳跃 if Input.is_action_just_pressed("ui_accept") and is_on_floor(): velocity.y = jump_velocity # 根据Shift状态选择移动速度 current_speed = sprint_speed if Input.is_action_pressed("sprint") else move_speed # 获取WASD输入并转换到世界空间方向 var input_dir := Input.get_vector("move_left", "move_right", "move_forward", "move_back") var direction := (transform.basis * Vector3(input_dir.x, 0, input_dir.y)).normalized() if direction: velocity.x = direction.x * current_speed velocity.z = direction.z * current_speed else: # 没有输入时水平减速，让移动手感更顺滑 velocity.x = move_toward(velocity.x, 0, current_speed * 4.0 * delta) velocity.z = move_toward(velocity.z, 0, current_speed * 4.0 * delta) move_and_slide() # 每帧执行一次交互检测 _check_interaction() func _check_interaction() -> void: if Input.is_action_just_pressed("interact"): if raycast.is_colliding(): var hit_obj = raycast.get_collider() if hit_obj and hit_obj.has_method("on_interact"): hit_obj.on_interact()

这段脚本的关键点在于：

• Input.get_vector把 WASD 输入转换为一个二维向量，避免手写多个if判断。
• transform.basis * Vector3(...)把输入方向从本地坐标转换到世界坐标，确保方向跟随相机朝向。
• mouse_sensitivity使用@export暴露到编辑器，方便后续调参。
• 交互检测使用RayCast3D，比Area3D更精准，适合玩家正前方交互的场景。

4.3 设置输入映射

在项目设置 -> 输入映射中添加以下动作：

这些动作名称必须和 player.gd 中的Input.get_vector参数保持一致，否则输入无效。

4.4 AI生成敌人追逐AI

敌人AI的核心要求是：初始待机，玩家拾取日记后开始向玩家移动，接触玩家触发游戏结束。用AI生成时，Prompt可以这样写：

使用GDScript编写一个3D敌人脚本： 1. 敌人使用CharacterBody3D。 2. 初始状态为 idle，不移动。 3. 当游戏全局变量 diary_count 大于0时进入 chase 状态。 4. chase状态下向玩家方向移动，速度比玩家慢一点。 5. 与玩家距离小于0.8米时，调用game_over()函数。 6. 需要给移动留一点延迟和随机扰动，让怪物看起来不是精准锁定。

生成的脚本经过整理后如下：

# 文件路径：scripts/enemy.gd extends CharacterBody3D @export var move_speed: float = 3.2 @export var player_path: NodePath var player: Node3D var state: String = "idle" var rng = RandomNumberGenerator.new() @onready var detection_area: Area3D = $DetectionArea func _ready() -> void: rng.randomize() if player_path: player = get_node(player_path) func _physics_process(delta: float) -> void: # 状态切换：根据游戏进度逐渐唤醒怪物 if GameManager.diary_count > 0: state = "chase" if state == "idle": # 待机时轻微飘动，增加恐怖感 velocity = Vector3.ZERO position.y = 0.5 + sin(Time.get_ticks_msec() * 0.003) * 0.02 elif state == "chase" and player: # 朝玩家移动，加入随机扰动，避免AI行为太机械 var to_player: Vector3 = (player.global_position - global_position).normalized() var noise: Vector3 = Vector3(rng.randf_range(-0.2, 0.2), 0, rng.randf_range(-0.2, 0.2)) velocity = (to_player + noise) * move_speed # 面向玩家 look_at(Vector3(player.global_position.x, global_position.y, player.global_position.z)) # 接触检测 if global_position.distance_to(player.global_position) < 0.8: GameManager.game_over() move_and_slide()

这里特别说明一下look_at那一行。为了避免怪物在下蹲或高低差情况下出现奇怪倾斜，这里强制让怪物的y坐标与自身保持一致，只旋转水平朝向。

4.5 创建全局游戏管理脚本

追逐AI脚本里调用了GameManager.game_over()和GameManager.diary_count，因此需要创建一个全局单例脚本来管理游戏状态。

# 文件路径：scripts/game_manager.gd extends Node signal game_over_signal signal diary_collected(new_count: int) var diary_count: int = 0 var total_diaries: int = 3 var is_game_over: bool = false func collect_diary() -> void: if is_game_over: return diary_count += 1 diary_collected.emit(diary_count) if diary_count >= total_diaries: # 全部收集完成，进入胜利状态（可以扩展为切换场景） _win_game() func game_over() -> void: if is_game_over: return is_game_over = true game_over_signal.emit() print("Game Over") func _win_game() -> void: print("You escaped the corridor.") # 这里可以显示胜利UI或切换场景

在项目设置中，把game_manager.gd注册为全局单例，名字叫GameManager。这样enemy.gd和interactable.gd才能直接使用GameManager.diary_count。

4.6 AI生成拾取与日记系统

日记系统的核心是：当玩家靠近日记模型并按E键时，显示日记文本并增加diary_count。为了让这类交互对象可以大量复用，我让AI生成一个通用的interactable.gd脚本：

# 文件路径：scripts/interactable.gd extends Area3D @export var diary_id: int = 1 @export var title: String = "日记碎片" @export_multiline var content_en: String = "" @export_multiline var content_zh: String = "" func on_interact() -> void: # 防止重复拾取 if not visible: return # 把日记内容发送到UI层显示 var diary_ui = get_tree().get_first_node_in_group("diary_ui") if diary_ui: diary_ui.show_diary(title, content_en, content_zh) # 更新全局日记计数 GameManager.collect_diary() # 隐藏日记模型，表示已被拾取 visible = false

在场景中，为每个日记模型创建Area3D节点，挂载这个脚本，并把日记内容填到content_en和content_zh属性中。这里需要提醒的是，不要用queue_free()隐藏日记，因为后续可能还想做“已拾取日记清单”功能，隐藏加标记的方式更适合扩展。

4.7 组装场景并测试

在主场景中创建地面、走廊墙壁、灯光、敌人、日记模型。玩家节点添加方式有两种：

• 菜单选择“当前场景”运行，把player.tscn实例拖入主场景。
• 或者设置主场景为main.tscn后直接运行。

在main.tscn中，把敌人节点的player_path指向玩家节点。此时运行项目，应该可以完成：

1. WASD移动，鼠标视角观察。
2. 按E拾取日记。
3. 拾取后屏幕显示日记内容。
4. 怪物开始追逐。

到这里，一个不包含任何AI的“普通恐怖游戏”已经能跑了，但内容还比较空。接下来的关键一步，是用AI产出真正吓人的叙事文本和音频。

5. AI驱动的中英双语恐怖叙事实验

5.1 用AI生成带有“递进恐怖感”的日记文本

恐怖叙事最忌讳的是“一次性把恐怖全说出来”。好的恐怖文本应该层层递进，第一份日记是困惑，第二份是恐惧，第三份是绝望。这个结构可以用Prompt来约束AI。

你是恐怖小说作家。请创作三份日记碎片，主题是“废弃研究走廊里的实验体苏醒”。 要求： 1. 第一份日记表达困惑与不安，篇幅100词以内。 2. 第二份日记表达恐惧与身体异常，篇幅120词以内。 3. 第三份日记表达绝望与自我认知崩塌，篇幅150词以内。 4. 每份日记都输出英文原文和中文翻译。 5. 不要直接写“怪物”，用暗示和细节让读者自己感受到异常。

AI输出的结果经过筛选后，我使用了下面这份英文版作为游戏内文案：

Diary #1 They told me the corridor was sealed for safety. But tonight I heard footsteps on the other side of the wall. Slow. Heavy. Almost like it was learning how to walk again. 翻译： 他们告诉我这条走廊因为安全原因被封锁了。但今晚，我听到墙的另一边有脚步声。很慢、很重，像是它正在重新学习如何走路。

Diary #2 It knows my name now. It whispered it through the door when I was trying to sleep. I checked the security camera and saw nothing in the hallway. But the door handle moved. Just a little. Just enough to let me know it can open the door anytime. 翻译： 它现在知道我的名字了。我准备睡觉时，它隔着门低语了我的名字。我查看监控摄像头，走廊里什么都没有。但门把手动了，只是动了一点点。刚好足够让我知道，它随时都能打开这扇门。

这种文本风格很适合AI生成，因为它的判定标准不在于“对不对”，而在于“氛围足不足”。AI在氛围描写上的平均水平和合格写手差距已经不大。

5.2 用AI绘画生成场景概念参考

恐怖游戏的美术资产门槛很高，但Demo阶段不需要实际模型，可以先让AI绘画生成场景概念图，用来贴在CanvasLayer里作为加载画面或过场CG。

可以使用类似下面的Prompt：

A dark abandoned research corridor, flickering fluorescent lights, wet concrete walls, a distant silhouette at the end of the hall, first-person horror game concept art, cinematic lighting, highly detailed, Unreal Engine style, wide angle, misty atmosphere.

得到的图不需要精确到像素，可以作为灯光设计和氛围调色的参考。在Godot中，可以把概念图直接作为TextureRect显示在CanvasLayer上，也能当作用户界面背景。

5.3 用TTS把恐怖台词变成音频

纯文字展示只是“阅读恐怖”，如果日记内容能在拾取瞬间以低语形式播放出来，恐怖指数会明显提升。这里使用了 edge-tts，它可以通过命令行直接把文本转为MP3，支持多种中文和英文语音。

安装命令：

pip install edge-tts

生成中文低语语音（使用 zh-CN-XiaoxiaoNeural 女声，适合走廊环境的柔和低语感）：

edge-tts --voice zh-CN-XiaoxiaoNeural --rate=-20% --pitch=-5Hz --text "它知道我的名字了。它隔着门，低语了我的名字。" --write-media "diary02_zh.mp3"

生成英文语音：

edge-tts --voice en-US-AriaNeural --rate=-10% --pitch=-3Hz --text "It knows my name now. It whispered it through the door." --write-media "diary02_en.mp3"

生成后把MP3文件放入assets/audio/目录，然后在日记拾取脚本中播放：

# 在 interactable.gd 中增加音频播放 @export var diary_audio_en: AudioStream @export var diary_audio_zh: AudioStream var audio_player: AudioStreamPlayer func _ready() -> void: audio_player = AudioStreamPlayer.new() add_child(audio_player) # 如果游戏语言为中文，播放中文语音；否则播放英文语音 if GameManager.language == "zh": audio_player.stream = diary_audio_zh else: audio_player.stream = diary_audio_en func on_interact() -> void: # ... 原有拾取逻辑 ... audio_player.play()

这里有一个实用技巧：把TTS参数中的--rate=-20%和--pitch=-5Hz结合，可以让合成语音的语速变慢、音调降低，比默认TTS发音更有“低语感”。如果你想要更明显的恐怖效果，还可以在音频播放时再加一个AudioEffectReverb混响效果，模拟走廊环境。

5.4 在Godot中实现日记显示UI

为了让日记显示不打断游戏节奏，我在main.tscn中新建了一个CanvasLayer，并添加一个Panel，内部放两个标签：TitleLabel和ContentLabel。脚本如下：

# 文件路径：scripts/diary_ui.gd extends Panel @onready var title_label: Label = $MarginContainer/VBoxContainer/TitleLabel @onready var content_label: Label = $MarginContainer/VBoxContainer/ContentLabel var is_visible: bool = false func _ready() -> void: hide() add_to_group("diary_ui") func show_diary(title_text: String, content_en: String, content_zh: String) -> void: title_label.text = title_text # 根据全局语言设置选择显示语言 if GameManager.language == "zh": content_label.text = content_zh else: content_label.text = content_en show() is_visible = true # 自动隐藏，也可以改为按任意键关闭 get_tree().create_timer(6.0).timeout.connect(hide)

这里add_to_group("diary_ui")对应interactable.gd中的get_tree().get_first_node_in_group("diary_ui")，这是Godot中一种轻量级的跨脚本通信方式，适合Demo阶段使用。

5.5 一个不算意外的“惊吓瞬间”

这部分的体验是整个项目最有趣的地方。在测试第三份日记时，AI生成的英文文本是：“The facility was never sealed to keep me out. It was sealed to keep itself from remembering.” 配合减速后的TTS女低音在空旷走廊里播放，再加上敌人刚好在背后出现，那一瞬间确实被吓到了。这提醒我一件事：当AI生成的内容足够贴合场景氛围时，恐怖游戏的“吓人效果”是会上涨的，这也意味着开发者在测试时最好避免在深夜反复调试。

6. 常见问题排查与AI翻车场景

AI生成内容不是次次都好用，这个项目里也踩了不少坑。下面把高频问题整理成一张速查表，方便之后项目复用。

6.1 典型AI“幻觉代码”案例分析

在一次测试中，AI给出一段看起来合理的Node初始化代码，使用了get_tree().get_root().get_node("Player")来获取玩家节点。问题在于，实际运行的场景中玩家节点在main.tscn下的路径层次不同，最终导致空引用错误。

正确的做法是根据实际场景树路径配置节点引用，或者在@export中拖拽赋值。这个案例说明，AI生成的代码如果涉及场景树路径，必须人工核对，不能直接信任。

6.2 排查流程建议

遇到AI生成代码报错，我的排查顺序固定为：

1. 先复制完整报错信息，送给同一个AI会话，让它解释错误原因。
2. 如果AI给出的修正方案涉及多个文件，要求它明确说明每个文件路径。
3. 在Godot中逐步验证：先确认单例注册，再确认场景树节点，再确认输入映射。
4. 运行时不直接看画面，先看Output面板的print日志，确认状态机切换是否符合预期。

这套流程帮助我缩短了至少一半的调试时间。

7. 把AI融入游戏开发的工程建议

7.1 AI生成代码，但要建立“代码审查”清单

AI生成的代码可以当初稿，但不能直接当最终代码。建议为团队或个人建立一份审查清单：

• 是否包含与引擎版本不兼容的API？
• 是否有未定义的单例、节点路径或信号？
• @export的路径引用是否在编辑器里正确赋值？
• 是否处理了空引用和边界条件？
• 性能是否合理？在循环中是否每帧创建了对象？

这条清单在AI辅助开发中尤为重要，因为AI生成代码时的“自信”并不等于“正确”。

7.2 用“AI会话存档”维护项目上下文

游戏项目是长周期的，AI会话很容易丢失上下文。我的做法是：为每个子系统单独建立一个文档，比如docs/prompts/player_prompt.md、docs/prompts/enemy_prompt.md，记录每次对话中效果好的Prompt版本。下次继续开发时，直接复制存档中的Prompt再补充新需求。这比每次从零描述需求高效得多。

7.3 资产版权与合规

AI生成内容在商业项目中的版权问题还在不断演变，所以这篇文章的重点是个人学习和原型验证。如果项目准备发布或商用，需要做到：

• 美术模型和贴图必须确认授权状态，AI绘画生成物并不能天然保证商用无忧。
• TTS合成语音确认服务条款是否允许商用发布。
• 字体、音效、背景音乐建议全部使用明确可商用的资源。

7.4 适合AI辅助的游戏类型

从实验来看，AI辅助开发最适合的是“内容量大于系统复杂度”的游戏类型，比如视觉小说、恐怖探索、解谜叙事。这类游戏的核心代码逻辑相对固定，AI能高效生成，而内容生成正是AI最擅长的长文本、多分支剧情。反过来，如果游戏核心是复杂的物理模拟、多人网络同步、策略平衡，AI可以帮忙写脚手架，但核心系统仍然需要人工深度参与。

7.5 用AI做“体验测试员”

这个项目里，我还让AI扮演“第一次玩恐怖游戏的新手玩家”，请它列出游戏中最容易被卡住的时刻，以及可以加jump scare的节奏点。AI给出的建议虽然不能替代真实玩家测试，但能提前发现很多设计层面的盲区，比如“日记拾取时没有强制暂停，玩家可能没来得及看文本就被怪物追上”这条建议，直接促成了自动隐藏UI前短暂暂停游戏时间的改动。

8. 下一步可以怎么继续

这次实验验证了一件事：AI参与开发，可以把一个“至少需要两三周”的恐怖游戏原型压缩到几天内跑通。The Corridor 目前还只是一个最简Demo，距离完整的游戏还差不少环节，但核心机制已经成立。

如果打算在这个项目基础上继续做，可以考虑的方向大致有三条：

一是完善怪物行为。现在的敌人AI只是直线追踪，可以扩展为巡逻状态、攻击状态、消失重现机制，让玩家需要研究怪物行为规律才能通过，这会明显提升恐怖感和玩法深度。

二是加入更完整的叙事线。AI生成的日记已经能给玩家带来情绪压力，后续可以扩展成录音机、电话、监控录像回放等更多叙事载体，让玩家通过非线性的方式拼凑出研究机构的事件全貌。

三是优化美术和音频的配合。当前只是用一个简单位移的胶囊体代表怪物，如果后续把AI绘画生成的怪物形象骨骼化，并配合动态音量、心跳声、低频氛围音，恐怖体验还能再上一个台阶。

如果你想用AI做自己的恐怖游戏，建议不要一上来就做大而全的复杂项目，而是先选择一个“单一吓人时刻”做原型——比如一条没有出口的走廊、一只无法击败的怪物、一份逐渐疯癫的日记。把单个情绪点做透，比堆一堆没做完的系统更有价值。好在这一轮实验里，AI连“吓人”这件事都愿意帮忙，剩下的就看你怎么把它缝进自己的世界里了。