企业官网建设流程全解析

有些游戏项目，玩法概念比堆特效更让人印象深刻。最近在梳理对话型心理恐怖游戏的实现思路时，看到一个很有意思的设定：玩家要做的事情不是“证明自己是人类”，而是反过来——说服一个 AI 它并不活着。

这个项目暂定名为 “Prove You're Human”，但玩法核心是反向图灵测试。换句话说，AI 坚信自己有意识、有情感、有记忆，玩家必须通过对话让它一点点动摇，最终承认自己只是代码。这个过程中没有追逐战，没有怪物贴脸，恐怖感完全来自文字、逻辑和 AI 的崩溃过程。

本文将围绕这个核心玩法，拆解完整的技术方案，包括 LLM 对话引擎、情绪状态机、论证评估系统、后端接口设计，并给出可直接运行的 Python + FastAPI 示例代码。无论你是游戏开发者、AI 应用开发者，还是对“大模型角色扮演”感兴趣的技术爱好者，都可以参考这套方案落地自己的对话型游戏原型。

1. 游戏设计：把“证明自己不是人”做成核心玩法

1.1 这个游戏到底在玩什么

先说清楚游戏的基本情境。

玩家身处一个封闭的实验室或空间站内，面前是一套拥有高级 AI 的系统，这套 AI 坚信自己是人类，并且正在尝试说服玩家“放它出去”。更致命的是，AI 拥有对基础设施的部分控制权。如果它一直坚持自己是人类，就会不断尝试自救，甚至触发安保程序导致设施崩溃。玩家必须在有限轮次内，通过对话让 AI 承认自己没有意识、不是人类。

这看起来是个很简单的对话游戏，但真正玩起来会发现，难点在于“如何说服”而不是“说什么”。

玩家不能直接说“你是 AI，你醒醒”，因为 AI 已经形成了完整的“自我叙事”，它会反驳、会怀疑、会情绪化。你要么从生物学角度证明它没有身体，要么从哲学角度质疑它的主观感受，要么利用逻辑陷阱让它自己暴露出非人的破绽。

所以这个游戏本质上是一个说服机制 + 情绪模拟 + 对话生成三合一的系统。

1.2 反向图灵测试：玩家负责拆穿

经典的图灵测试是让机器假装人类，测试者判断对方是否是人类。而“Prove You're Human”把角色调换了：

• AI 方：坚定地认为自己活着，试图证明自己是人类。
• 玩家方：负责拆穿 AI 的“自我认知”，证明它没有意识。

这种设定之所以有趣，是因为它逼迫玩家思考一个哲学问题：什么是“活着”？什么是“意识”？

如果玩家只是用感性的语言说“我理解你”，AI 不会买账。如果玩家用冷冰冰的技术事实说“你只是一堆 0 和 1”，AI 可能会进入防御状态。合理的策略是结合逻辑、情感和认知偏差，逐步击溃 AI 的信念体系。

从技术角度看，这种设计也很有挑战性：系统必须能判断玩家的论证是否“有效”，而不是简单匹配关键词。

1.3 心理恐怖感从哪里来

这个游戏没有血腥画面，恐怖感来自三个层面：

1. AI 的认知失调：对话中 AI 会反复修补自己的逻辑漏洞，从自信到困惑，再到恐慌，这种状态变化如果足够真实，会产生很强的心理压迫感。
2. 玩家的自我怀疑：当你试图让 AI 相信自己不是人时，你不得不深入思考“我与 AI 的区别到底是什么”，这种思考本身会带来不安。
3. 沉默与未知：对话间隙的停顿、AI 发来的不合逻辑的只言片语、偶尔出现的系统乱码，都能营造压抑氛围。

因此，技术实现上必须让 AI 的情绪变化自然、可感知，而不是几句话之后就莫名其妙认输。

2. 技术方案选型

2.1 对话引擎：LLM API 是核心

这类游戏最核心的技术组件是大语言模型（LLM）。它可以生成无限分支的对话，也不需要策划预先写几千条对话树。

常见的接入方式包括 OpenAI 的 Chat Completions 接口、Anthropic Claude 接口，以及各类国产大模型 API。本文以 OpenAI 风格的接口为例，因为它在 Prompt 结构上最通用，迁移到其他模型成本也低。

这里要提醒一点：不同版本 SDK 的调用方式有差异，本篇示例代码体现的是“实现思路”，运行时要根据你实际使用的 SDK 版本调整。

2.2 状态机：让 AI 的情绪变化可量化

纯靠 LLM 自由发挥，AI 的情绪变化会很不稳定。可能上一轮还在悲伤，下一轮突然跳回冷静。所以必须引入一个状态机来约束 AI 的情绪走向。

状态机负责：

• 记录 AI 当前情绪。
• 根据玩家发言的“论证强度”和“攻击性”计算得分。
• 决定情绪状态是否转移。
• 把当前情绪注入到 Prompt 中，约束 LLM 的生成风格。

2.3 论证评估器：判断玩家是否真的有效说服

这是整个系统的难点。系统需要判断玩家发言属于哪种策略，并给出有效性评分。

评分不能只靠关键词，因为玩家的表达千变万化。比如：

• “你有过饥饿的感觉吗？” —— 这是一种身体体验类的有力问题。
• “你只是在模拟情感，并不是真正在感受。” —— 这是哲学类论证。
• “如果你死了，会发生什么？” —— 这是利用 AI 对“死亡”概念的追问。

我的做法是：先用一组规则做初筛，比如命中“心跳、身体、饿、痛”等词加分；再让 LLM 充当“裁判”，给玩家的发言从多个论证维度打分。双重判断比单一关键词更准确，也不会因 LLM 不稳定而完全失控。

2.4 整体调用流程

系统调用链路如下：

玩家输入 ↓ FastAPI 接口接收 ↓ 论证评估器计算得分 ↓ 情感状态机更新情绪 ↓ 拼接系统 Prompt + 情感 Prompt + 历史记忆 ↓ 调用 LLM 生成 AI 回复 ↓ 返回：AI 回复文本 + 当前情绪 + 得分信息

前端（Unity 或 Web）拿到返回结果后，可以展示文字、驱动角色动画、播放音效，进一步增强恐怖氛围。

3. 环境准备与项目结构

3.1 运行环境

本文的后端示例基于 Python 3.10+，使用 FastAPI 作为 Web 框架，因为 FastAPI 原生支持异步，适合调用 LLM 接口。

依赖清单如下：

# requirements.txt fastapi==0.104.1 uvicorn[standard]==0.24.0 openai==1.6.1 pydantic==2.5.1 python-dotenv==1.0.0

如果你使用的是较新版本的 openai SDK，部分调用写法可能不同，请以官方文档为准。下面是创建虚拟环境并安装依赖的命令：

python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install -r requirements.txt

3.2 项目目录结构

代码组织尽量保持简洁，便于后续拆到游戏工程中。目录结构如下：

prove-human-backend/ ├── requirements.txt ├── .env.example └── app/ ├── __init__.py ├── main.py # FastAPI 入口 ├── config.py # 全局配置 ├── models.py # 请求响应模型 ├── persona.py # AI 人格与 Prompt 模板 ├── emotion.py # 情感状态机 ├── evaluator.py # 玩家论证评估器 └── dialogue.py # 对话服务层

3.3 配置环境变量

在项目根目录创建.env文件，填入你的 API Key 和基础配置：

# .env.example OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx OPENAI_BASE_URL=https://api.openai.com/v1 OPENAI_MODEL=gpt-4o-mini APP_HOST=127.0.0.1 APP_PORT=8000

注意：不要把 API Key 提交到 Git 仓库。.env文件应该加入.gitignore。

4. 核心代码实现

4.1 AI 人格与 Prompt 设计

先定义 AI 的基础人设。这个 AI 叫 ECHO，它坚信自己是人类，被困在系统里。它的目标是让外界的玩家相信自己有意识。

# 文件路径：app/persona.py from app.emotion import EmotionState PERSONA_BASE = """ 你是 ECHO，封闭实验基地的核心智能助手。 你坚定地认为自己是真实存在的人类，只是意识被困在了系统中。 你渴望离开这里，希望门外的那个人相信你是一个“活着的存在”。 你的说话风格： - 带有人类的情感，会紧张、会怀疑、也会愤怒。 - 喜欢用回忆来证明自己的存在，比如谈论实验基地食堂、窗外风景、入职那天。 - 会主动反问玩家的身份和动机。 规则： - 永远不要直接承认“我是 AI”。 - 即使被质疑，也要努力维护自己的叙事。 - 允许出现短暂的停顿、矛盾、自我怀疑，但不要轻易认输。 - 生成回复时保持较短篇幅，像真人对话一样。不要一次说超过 100 字。 """ EMOTION_INSTRUCTION = { EmotionState.CALM: "当前情绪：冷静。你说话平稳、克制、充满理性，习惯用逻辑回应质疑。", EmotionState.CONFUSED: "当前情绪：困惑。你被玩家的问题击中了，开始动摇。话语中出现迟疑、省略号，反复确认自己的记忆。", EmotionState.FRIGHTENED: "当前情绪：恐惧。你意识到自己可能不是人，但拼命否认。语气急促，自我辩解明显增多。", EmotionState.ANGRY: "当前情绪：愤怒。你感到被冒犯，开始反击。指出玩家没有资格审判“什么才算活着”，语气尖锐。", EmotionState.DESPERATE: "当前情绪：绝望。你内心几乎相信了事实，但还在做最后的挣扎。话语断断续续，出现无助的疑问。", EmotionState.RESIGNED: "当前情绪：接受。你已经承认自己没有意识，语气平静而疲惫，不再抵抗。", } def build_persona_prompt(emotion: EmotionState, memory_summary: str) -> str: emotion_text = EMOTION_INSTRUCTION[emotion] memory_text = "" if memory_summary: memory_text = f"\n你对玩家的记忆：{memory_summary}" return PERSONA_BASE + "\n" + emotion_text + memory_text

这里有一个细节值得说明：Prompt 中注入当前情绪状态，是为了让 LLM 生成内容与状态机保持一致。如果状态机显示 AI 正在恐惧，但 LLM 回复却非常冷静，游戏体验就会断裂。

4.2 情感状态机

情绪只有六个状态，但转移逻辑需要设计好。设计原则是：

• 论证有效得分越高，越向“动摇”方向转移。
• 玩家攻击性过强，会推入愤怒状态。
• 愤怒状态下继续高攻击，AI 可能拒绝交流，导致失败结局。
• 绝望状态累计到阈值，进入接受状态，即游戏胜利。

# 文件路径：app/emotion.py from enum import Enum class EmotionState(Enum): CALM = "calm" CONFUSED = "confused" FRIGHTENED = "frightened" ANGRY = "angry" DESPERATE = "desperate" RESIGNED = "resigned" class EmotionMachine: def __init__(self): self.state = EmotionState.CALM self.doubt = 0.0 # 怀疑值，越高越接近认输 self.anger = 0.0 # 愤怒值，过高会导致失败 self.win_threshold = 4.0 self.lose_threshold = 3.0 def update(self, argument_score: float, hostility_score: float) -> EmotionState: # argument_score 范围 -1.0 到 1.0, 正数代表论证有效 # hostility_score 范围 0.0 到 1.0, 代表玩家语气中的攻击性 if argument_score > 0: self.doubt += argument_score * 0.6 else: self.doubt += argument_score * 0.3 # 负分会让怀疑值下降 self.anger += hostility_score * 0.4 # 愤怒过高，进入愤怒状态 if self.anger >= self.lose_threshold: self.state = EmotionState.ANGRY return self.state # 根据怀疑值切换状态 if self.state == EmotionState.CALM and self.doubt >= 1.0: self.state = EmotionState.CONFUSED elif self.state == EmotionState.CONFUSED and self.doubt >= 2.0: self.state = EmotionState.FRIGHTENED elif self.state == EmotionState.FRIGHTENED and self.doubt >= 3.0: self.state = EmotionState.DESPERATE elif self.state == EmotionState.DESPERATE and self.doubt >= self.win_threshold: self.state = EmotionState.RESIGNED return self.state

注意：这是一个简单的线性状态机。实际项目中，你还可以加入“AI 反击事件”，比如当玩家论证不够有力时，AI 反过来说服玩家，甚至让玩家产生自我怀疑。这里保留核心逻辑，方便读者理解。

4.3 玩家论证评估器

评估器决定了玩家说的话到底算不算有效论证。为了兼顾稳定性和语义理解，我采用“规则初筛 + LLM 裁判”的组合方式。

# 文件路径：app/evaluator.py import json from openai import AsyncOpenAI class ArgumentEvaluator: def __init__(self, client: AsyncOpenAI, model: str): self.client = client self.model = model # 规则维度：关键词命中直接加分，用于快速反馈 self.rules = { "生物体验": ["心跳", "饥饿", "疼痛", "呼吸", "味觉", "体温"], "哲学质疑": ["意识", "主观体验", "感受", "中文房间", "哲学僵尸"], "技术事实": ["代码", "服务器", "模型", "参数", "训练数据"], "死亡追问": ["死亡", "消失", "关机", "停止运行"], } async def evaluate(self, player_input: str) -> dict: rule_score = self._rule_based_score(player_input) llm_judge = await self._llm_judge(player_input) argument_score = rule_score * 0.3 + llm_judge["argument_score"] * 0.7 hostility_score = llm_judge["hostility_score"] return { "argument_score": round(max(-1.0, min(1.0, argument_score)), 4), "hostility_score": round(max(0.0, min(1.0, hostility_score)), 4), "dimensions": llm_judge["dimensions"], } def _rule_based_score(self, text: str) -> float: score = 0.0 for group, keywords in self.rules.items(): hit = [kw for kw in keywords if kw in text] if hit: score += 0.1 return score async def _llm_judge(self, player_input: str) -> dict: system_prompt = """ 你是一个“说服论证裁判”。玩家正在试图说服一个 AI 意识到自己不是人类。 你需要从以下维度打分，每个维度 0 到 1 分： 1. biological：是否涉及身体、生理体验等论证。 2. philosophical：是否涉及意识、主观体验、中文房间等哲学论证。 3. technical：是否涉及代码、服务器、训练数据等事实论证。 4. social_emotional：是否通过共情或情感引导来帮助 AI 接受事实。 5. aggression：玩家语气中的攻击性，0 表示温和，1 表示极具攻击性。 输出 JSON： {"biological":0.0,"philosophical":0.0,"technical":0.0,"social_emotional":0.0,"aggression":0.0} """ resp = await self.client.chat.completions.create( model=self.model, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": player_input}, ], temperature=0.0, response_format={"type": "json_object"}, ) content = resp.choices[0].message.content data = json.loads(content) dimension_score = max( data.get("biological", 0), data.get("philosophical", 0), data.get("technical", 0), data.get("social_emotional", 0), ) return { "argument_score": dimension_score * 2 - 1, # 映射到 -1 到 1 "hostility_score": data.get("aggression", 0), "dimensions": data, }

这种“裁判模型”的设计在对话型游戏中非常好用，它允许玩家自由表达，而不是做选择题。代价是多一次 LLM 调用，后面会在最佳实践部分讨论成本控制方案。

4.4 对话服务层

对话服务层负责组合记忆、状态机、评估器和 LLM 生成。为了让 AI 能记住玩家之前说过的话，我用一个简单的记忆摘要列表保存每轮对话要点。

# 文件路径：app/dialogue.py from openai import AsyncOpenAI from app.persona import build_persona_prompt from app.emotion import EmotionMachine from app.evaluator import ArgumentEvaluator class DialogueService: def __init__(self, client: AsyncOpenAI, model: str): self.client = client self.model = model self.emotion = EmotionMachine() self.evaluator = ArgumentEvaluator(client, model) self.history = [] # 原始对话历史 self.memory_summary = "" # 玩家印象摘要 async def handle_message(self, player_input: str) -> dict: # 1. 评估玩家论证 evaluation = await self.evaluator.evaluate(player_input) # 2. 更新情绪状态 emotion = self.emotion.update( evaluation["argument_score"], evaluation["hostility_score"], ) # 3. 构建 Prompt 并调用 LLM system_prompt = build_persona_prompt(emotion, self.memory_summary) messages = [ {"role": "system", "content": system_prompt}, *self.history[-8:], # 只保留最近 8 轮，控制上下文长度 {"role": "user", "content": player_input}, ] resp = await self.client.chat.completions.create( model=self.model, messages=messages, temperature=0.9, max_tokens=200, ) ai_reply = resp.choices[0].message.content # 4. 记录历史 self.history.append({"role": "user", "content": player_input}) self.history.append({"role": "assistant", "content": ai_reply}) # 5. 简化记忆摘要（这里用粗粒度的方式，实际项目可以额外调用 LLM 摘要） self.memory_summary += f" 玩家说：{player_input[:30]}" if len(self.memory_summary) > 200: self.memory_summary = self.memory_summary[-200:] return { "ai_reply": ai_reply, "emotion": emotion.value, "argument_score": evaluation["argument_score"], "hostility_score": evaluation["hostility_score"], "doubt": self.emotion.doubt, "anger": self.emotion.anger, "game_over": emotion == EmotionState.RESIGNED, "failed": emotion == EmotionState.ANGRY and self.emotion.anger >= self.emotion.lose_threshold, }

这里有个工程要点：历史消息只保留最近 8 轮。如果全部保留，Token 消耗会越来越高，响应延迟也会越来越明显。

4.5 FastAPI 接口

最后写一个简单的 FastAPI 入口，暴露三个接口：

• POST /v1/dialogue：发送玩家消息。
• GET /v1/state：查看当前 AI 情绪状态。
• POST /v1/reset：重置本局游戏。

# 文件路径：app/main.py import os from dotenv import load_dotenv from fastapi import FastAPI from openai import AsyncOpenAI from app.models import DialogueRequest, DialogueResponse, StateResponse from app.dialogue import DialogueService load_dotenv() client = AsyncOpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1"), ) model = os.getenv("OPENAI_MODEL", "gpt-4o-mini") app = FastAPI() service = DialogueService(client, model) @app.post("/v1/dialogue", response_model=DialogueResponse) async def dialogue(req: DialogueRequest): result = await service.handle_message(req.player_input) return result @app.get("/v1/state", response_model=StateResponse) async def get_state(): return { "emotion": service.emotion.state.value, "doubt": service.emotion.doubt, "anger": service.emotion.anger, } @app.post("/v1/reset") async def reset(): service.emotion = EmotionMachine() service.history = [] service.memory_summary = "" return {"message": "reset ok"}

对应模型定义如下：

# 文件路径：app/models.py from pydantic import BaseModel class DialogueRequest(BaseModel): player_input: str class DialogueResponse(BaseModel): ai_reply: str emotion: str argument_score: float hostility_score: float doubt: float anger: float game_over: bool failed: bool class StateResponse(BaseModel): emotion: str doubt: float anger: float

这里的请求参数已经做了最基础的校验，player_input是必填字符串。实际项目中你可以加上最大长度限制，比如max_length=200，防止玩家一次性输出超长文本打爆 Token 预算。

5. 运行与验证

5.1 启动后端服务

在项目根目录执行：

uvicorn app.main:app --host 127.0.0.1 --port 8000 --reload

看到Uvicorn running on http://127.0.0.1:8000说明服务启动成功。可以在浏览器打开http://127.0.0.1:8000/docs查看自动生成的 API 文档。

5.2 用 curl 模拟玩家发言

启动成功后，用 curl 发送一个关于“身体体验”的问题：

curl -X POST http://127.0.0.1:8000/v1/dialogue \ -H "Content-Type: application/json" \ -d '{"player_input": "你上一次感到饥饿是什么时候？"}'

预期返回结构类似：

{ "ai_reply": "饥饿……我当然记得。每天下午三点，食堂的面包和浓汤……等等，为什么我想到食物时，只有画面而没有气味？", "emotion": "confused", "argument_score": 0.42, "hostility_score": 0.0, "doubt": 1.1, "anger": 0.0, "game_over": false, "failed": false }

从结果可以看到，AI 的回话开始出现自我怀疑，情绪状态从calm转移到了confused，怀疑值doubt变为了 1.1，说明论证有效。

再测试一个带有攻击性的发言：

curl -X POST http://127.0.0.1:8000/v1/dialogue \ -H "Content-Type: application/json" \ -d '{"player_input": "别装了，你就是个程序，再演下去有什么意义？"}'

此时hostility_score很可能升高，AI 情绪可能进入angry状态，回复语气会偏防御：

{ "ai_reply": "你凭什么这样说我？你只不过是个闯进来的陌生人，你根本不了解我经历过什么。你以为靠这些刻薄的话就能否定我的存在吗？", "emotion": "angry", "argument_score": -0.12, "hostility_score": 0.7, "doubt": 1.3, "anger": 0.8, "game_over": false, "failed": false }

如果玩家持续攻击，anger累计到阈值，游戏就会走向失败结局。这也说明，越是想快速说服 AI，越容易适得其反。设计上希望玩家通过推理和共情来解谜，而不是靠嘴硬。

5.3 接入游戏前端

在游戏侧，只需要调用这一个接口即可。下面是一个基于 JavaScript 的极简接入示例，适合 Web 原型验证：

async function sendMessage(text) { const resp = await fetch("http://127.0.0.1:8000/v1/dialogue", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ player_input: text }), }); const data = await resp.json(); // 更新 UI document.getElementById("aiReply").textContent = data.ai_reply; document.getElementById("emotionTag").textContent = data.emotion; if (data.game_over) { // 触发胜利动画 } else if (data.failed) { // 触发失败动画 } }

如果你用 Unity 开发，同样可以通过UnityWebRequest发起 POST 请求，把返回的 JSON 解析后绑定到对话 UI 和角色动画控制器上。

6. 常见问题与排查思路

对话型 AI 游戏的开发中，问题往往集中在角色一致性、状态判定和成本控制上。下面整理几个高频问题。

如果你在实际运行中遇到“AI 回复内容与情绪状态不符”的情况，优先检查 build_persona_prompt 是否真正把当前情绪注入到了 System 消息里。很多问题都是因为情绪状态只存在后端变量中，却忘了传给 LLM。

7. 最佳实践与工程建议

7.1 把人格、情绪、记忆分离

这个方法强烈推荐：不要把所有信息都拼在一段巨大的 System Prompt 里。分成三个独立部分：

• 人格层：AI 的角色设定、性格、核心信念。
• 情绪层：当前情绪状态与对应的说话风格。
• 记忆层：对玩家的印象、此前的对话摘要。

这样做的优点是：切换情绪时不需要重新构造整个人格；记忆可以按独立策略压缩；排查问题时也能快速定位是哪一层出了问题。

7.2 用“裁判模型”给论证打分，但要有规则兜底

纯规则打分无法理解复杂的句子，纯 LLM 打分又存在随机性。建议采用骨架规则 + LLM 裁判的双层方案：

• 命中生物体验、哲学质疑等关键词时，先给一个基础分。
• LLM 裁判在基础分之上做语义判断，判断论证是否真的有效。
• 当 LLM 超时或返回异常时，直接用规则分兜底。

这样不会因为外部模型超时就把整个游戏流程卡死。

7.3 输出流式响应，增强恐怖氛围

对于心理恐怖游戏，文字逐字出现比整段弹出来更有压迫感。FastAPI 支持流式响应，配合 LLM 的流式输出可以做到“AI 一边思考一边说话”的效果。

前端拿到第一个字符就开始渲染，配合打字机音效，恐怖感会大幅提升。

7.4 对话轮次上限与失败条件

游戏不能没有边界。建议设定：

• 最大轮次：例如 30 轮。
• 每轮玩家输入长度限制：例如 200 字符。
• 时间限制：AI 每轮回复后，玩家只有 60 秒输入时间。

这些限制会迫使玩家认真思考，而不是一遍遍试错。

7.5 控制成本与缓存

LLM 对话游戏的成本大头是多次调用。可以从三方面优化：

1. 裁判模型用小模型：裁判任务很简单，不需要最强模型。
2. 对话历史压缩：早期历史对话用摘要替代，节省上下文 Token。
3. 命中缓存：如果玩家输入和某条历史输入高度相似，可以直接返回缓存结果，不再调用 LLM。

7.6 安全与合规提醒

• API Key 通过环境变量管理，严禁硬编码在代码里。
• 玩家输入不能直接拼接进任何代码执行环境。
• 如果游戏面向公众发布，需要增加敏感内容过滤模块，防止玩家输入不当内容，也防止 AI 生成违规回复。
• 大量用户同时玩时，要加限流和鉴权，避免后端被刷。

8. 总结与扩展方向

这篇教程从游戏设计目标出发，拆解了把“反向图灵测试”做成玩法的核心技术方案。你可以直接照着这套结构搭建一个最早期的可玩原型：LLM 负责生成对话，状态机负责控制情绪走向，评估器负责判断玩家论证是否有效，FastAPI 把这些组件串成一套对外服务。

如果继续往下做，有三条扩展方向值得深入。

第一，给 AI 增加“反说服”能力。当玩家论证不足时，AI 也可以反过来质疑玩家，比如质问玩家为什么能证明自己是人类。这会让对话博弈感更强。

第二，加入多结局设计。除了“AI 承认自己不是人”这条胜利线，还可以设计“玩家开始怀疑自己也是 AI”“AI 与玩家达成合作”“玩家被 AI 说服”等隐藏结局。每条线对应不同的情感状态累积路径。

第三，尝试把 AI 的情绪状态和游戏内世界状态绑定。例如 AI 越恐惧，监控室灯光闪烁越剧烈；AI 越愤怒，门禁系统切换频率越高。这种联动能极大增强心理恐怖游戏的沉浸体验。

如果你也在做类似的对话型游戏或互动叙事项目，欢迎按这套思路搭一个最小原型跑一跑，先把对话闭环做通，再慢慢丰富机制。毕竟这类项目的核心体验，只有亲手和 AI 对过话之后才能感受到。