如何在 TapTap 小游戏中接入 AI 游戏助手：从零开始的完整分享

精华修改于04/17763 浏览开发交流

大家好，我是「深渊炼狱：堕落之塔2」的开发者，游戏还在开发中。最近给游戏加了一个 AI 游戏助手功能——玩家可以在游戏内直接跟 AI 对话，问攻略、问合成配方、问兑换码，甚至聊聊天吹吹水。

测试后玩家反馈出乎意料地好，很多玩家说"比查攻略方便多了"。这里把完整的开发过程、踩过的坑、以及一些心得分享给大家，希望对想做类似功能的开发者有帮助。

一、为什么要在游戏里加 AI？

我的游戏有 42 个仆从、67 个遗物、暗品合成配方、天赋加点、装备套装……系统比较多。玩家经常在群里问：

"XX暗品怎么合成？需要哪两个金品？"

"天赋点怎么加最优？"

"有没有兑换码？"

"新手刚开始怎么玩？"

我一个人根本回答不过来。于是想到：能不能让 AI 来当 24 小时在线的客服？

而且 AI 不只能答游戏问题，玩家问个数学题、聊个天也行，增加游戏的粘性和趣味性。

二、整体架构：服务端代理模式

为什么不在客户端直接调 API？

一开始我想在客户端直接请求大模型 API，但很快发现几个致命问题：

1. API Key 暴露：客户端代码容易被反编译，Key 泄露 = 钱包遭殃

2. 安全风控：没法做频率限制、敏感词过滤

3. 灵活性差：换模型、改提示词都要发版更新

所以最终采用了服务端代理架构：

玩家输入问题

↓

客户端 → [RemoteEvent] → 服务端 AIProxyServer

↓

服务端 → [HTTP POST] → 大模型 API（豆包）

↓

服务端 ← [JSON Response] ← 大模型返回

↓

客户端 ← [RemoteEvent] ← 服务端转发回复

↓

玩家看到 AI 回复

核心代码结构

scripts/

├── network/

│ ├── AIProxyServer.lua -- 服务端：转发请求、管理对话历史

│ ├── AIProxyShared.lua -- 共享：事件名定义

│ └── AIProxyClient.lua -- 客户端：发送问题、显示回复

└── AIChatPanel.lua -- UI：聊天界面

服务端核心逻辑其实非常简单，就三步：

```lua

-- 1. 收到客户端消息

SubscribeToEvent("C2SAICHATREQ", function(, eventData)

local userMessage = eventData["Message"]:GetString()

-- 2. 构造请求，发给大模型

local messages = {

{ role = "system", content = systemPrompt },

-- ... 历史对话 ...

{ role = "user", content = userMessage },

}

http:Create()

:SetUrl(API_URL)

:SetMethod(HTTP_POST)

:AddHeader("Authorization", "Bearer " .. API_KEY)

:SetBody(cjson.encode({ model = MODEL_ID, messages = messages }))

:OnSuccess(function(_, response)

-- 3. 解析回复，转发给客户端

local data = cjson.decode(response.dataAsString)

local reply = data.choices[1].message.content

SendToClient(conn, "S2C_AI_CHAT_RESP", { Reply = reply })

end)

:Send()

end)

```

三、系统提示词：AI 好不好用，80% 取决于这个

这是我花时间最多、也是效果最明显的部分。系统提示词的质量直接决定了 AI 回答的准确度。

血泪教训：别偷懒写模糊描述

我最初的提示词是这样的：

你是一个塔防游戏的助手，游戏有多种仆从和遗物，请帮助玩家回答问题。

结果 AI 的回答全是瞎编的——编造不存在的仆从名字、虚构合成配方、胡说游戏机制。大模型不了解你的游戏，它只会"合理地编造"。

正确做法：把真实游戏数据全部喂给它

我最终写了一份 200 多行的系统提示词，涵盖了游戏的所有核心数据：

```lua

local SYSTEM_PROMPT = [[你是「深渊炼狱：堕落之塔2」的AI游戏助手。

仆从系统（共42个）

普通仆从名录

召唤概率

灰50%、血30%、蓝15%、紫4%、金0.9%、暗0.1%

50抽保底金品

遗物系统（共67个）

...

天赋系统

6个天赋，共8点，分3层投点：

基础层：魔力亲和(max3)、战斗本能(max3)、灵魂共鸣(max3)

进阶层(需3基础点)：深渊意志(max3)、堕落赐福(max3)

精通层(需6点)：末日审判(max1)

...]]

```

数据怎么来？直接从代码里扫

别让嗒啦啦手动抄，容易出错。我的做法是直接扫描游戏源码，提取真实的配置数据：

仆从名称和属性 → 扫 Config.SPIRITS

配置表

暗品合成配方 → 扫 Config.DARK_RECIPES

遗物数量和效果 → 扫 Config.RELICS

天赋/技能数据 → 扫 Config.LORD_TALENTS

、Config.LORD_SKILLS

召唤概率 → 扫 Config.SUMMON_RATES

代码是唯一的真相来源，文档会过时，代码不会。

关键技巧：限制回复长度

大模型默认回复很长，但游戏聊天窗口空间有限，太长体验很差。两层限制：

```lua

-- 1. 提示词里明确告诉它

⚠️ 重要：所有回复必须控制在300字以内。

-- 2. API 参数里硬限制

{ model = MODELID, messages = msgs, maxtokens = 512 }

```

四、动态数据注入：让 AI "实时更新"

静态提示词解决了大部分问题，但有些数据是运行时动态变化的，比如：

1.兑换码：GM 随时可能发布新兑换码

2.版本更新日志：每次发版内容不同

3.活动状态：联动活动是否开启

兑换码的动态读取

我的游戏有 GM 广播系统，GM 创建的兑换码会通过排行榜附加数据广播给所有玩家。AI 助手服务端也可以读取这份数据：

```lua

-- 服务端定期从排行榜读取 GM 广播数据

local function refreshCDKList()

serverCloud:GetRankList("gmbroadcastver", 1, 1, {

ok = function(rankList)

local broadcastData = rankList[1].score.gmbroadcastdata

local cdkList = broadcastData.gmConfig.cdkList

-- 提取通用码（type=1），格式化奖励

for _, cdk in ipairs(cdkList) do

if cdk.type == 1 then

-- 缓存到内存，拼入系统提示词

end

})

end

```

然后在构建系统提示词时动态拼接：

lua

local function buildSystemPrompt()

-- 每 5 分钟刷新一次 CDK 缓存

if os.time() - lastRefresh >= 300 then

refreshCDKList()

end

return SYSTEM_PROMPT_BASE .. buildCDKSection() .. "\n" .. CHANGELOG

end

这样 GM 发布了新兑换码后，AI 最迟 5 分钟内就能告诉玩家。玩家问"有没有兑换码"时，AI 会直接列出当前可用的兑换码和对应奖励。

五、对话历史管理

只有单轮对话的 AI 体验很差——玩家问"那它怎么合成？"，AI 不知道"它"是什么。

方案：每连接独立的对话历史

```lua

local chatHistories = {} -- connKey -> messages[]

-- 每次对话，把完整历史发给大模型

local messages = {

{ role = "system", content = systemPrompt },

}

for _, msg in ipairs(history) do

table.insert(messages, msg)

end

-- 限制历史轮数，避免 token 爆炸

local MAXROUNDS = 10 -- 保留最近 10 轮

while #history > MAXROUNDS * 2 do

table.remove(history, 1)

end

```

注意：玩家断开连接时要清理历史，避免内存泄漏。

lua

CM.OnDisconnect("AIProxy", function(conn, connKey)

chatHistories[connKey] = nil

end)

六、踩过的坑

坑 1：提示词里的数据和游戏实际不一致

这是最严重的问题。我最初写提示词时凭记忆写的，结果：

1.写了"30章x10关"→ 实际是 100 章

2.写了"遗物共 63 个"→ 实际是 67 个

3.写了"暗品合成需要 3 个金品"→ 实际是禁法书 + 2 个金品

4.写了"天赋 3 选 1"→ 实际是投点系统

解决方案：从代码中全量提取数据，逐字段校对。这个过程很枯燥但非常值得。

坑 2：AI 回复太长导致 JSON 解析失败

大模型有时回复特别长，超过网络传输限制或解析 buffer，导致 JSON 截断。

```lua

-- 设置 maxtokens 限制

{ maxtokens = 512 }

-- 同时在错误处理中给友好提示

:OnSuccess(function(_, response)

local ok, data = pcall(cjson.decode, response.dataAsString)

if not ok then

reply = "AI回复内容过长导致解析失败，请换个简短的问题试试~"

end

end)

```

坑 3：不要忘记错误处理

网络请求随时可能失败——超时、API 限流、余额不足。每种情况都要有友好的提示：

lua

:OnError(function(_, statusCode, error)

if statusCode == 0 then

hint = "请求超时了，试试问简短一点的问题~"

elseif statusCode == 429 then

hint = "AI 太忙了，请稍后再试~"

else

hint = "网络繁忙，请稍后再试~"

end

end)

坑 4：提示词中加上"不要编造"

即使喂了完整数据，大模型有时还是会"发挥创意"。明确告诉它：

请基于上述真实游戏数据作答，不要编造不存在的功能或道具。

七、大模型选择

我用的是火山引擎的豆包大模型（doubao-seed-2-0-pro），原因：

中文能力强，游戏场景本地化好

API 兼容 OpenAI 格式，接入成本低

价格相对便宜，适合独立游戏开发者

其实换任何兼容 OpenAI Chat Completions 格式的大模型都可以（DeepSeek、通义千问等），代码几乎不用改，只需要换 URL、Key 和模型名。

八、成本控制

AI API 是按 token 计费的，要注意控制成本：

| 措施 | 效果 |

|------|------|

| max_tokens = 512

| 限制每次回复长度 |

| 历史轮数上限 10 轮 | 控制上下文 token 数 |

| 系统提示词精简 | 减少每次请求的固定开销 |

| 提示词里要求"300字以内" | 从源头减少输出 |

假如游戏日活几百人，AI 助手的 API 费用每天大概几块钱，大部分人完全可以接受，并且新人每天还有免费的token使用。

九、效果展示

真实使用场景：

问攻略："暗品怎么合？推荐先合哪个？" → AI 准确列出所有 11 个暗品的合成公式并给建议

问兑换码："有福利码吗？" → AI 实时列出当前可用的兑换码和奖励

问天赋加点："天赋怎么加最强？" → AI 根据真实数据推荐加点方案

闲聊："给我讲个笑话" → AI 变身聊天陪伴

十、总结

给小游戏加 AI 助手其实不难，核心步骤就四个：

1. 服务端代理架构：保护 API Key，方便迭代

2. 高质量系统提示词：从代码中提取真实数据，这是效果好坏的关键

3. 动态数据注入：兑换码、活动等运行时数据实时同步

4. 对话历史管理：支持多轮对话，记得清理内存

整个功能我从开始到上线测试大概花了一个多小时，其中大部分时间花在了校对系统提示词的准确性上。代码本身不复杂，让 AI 说对才是最难的。

希望这篇分享对大家有帮助，有问题欢迎在评论区交流！

#TapTap制造 #嗒啦啦

猜你想搜

taptap 制造ai游戏助手接入

TapTap 制造应用

9.8

前往论坛