AI 辅助游戏开发 · 工具能力迭代分享

上个月分享了 1.0 版本——用一句自然语言往任意配置表里加数据，RAG 检索准确率 100%，解决了"策划不用理解表结构也能配表"的基本问题。

但实际用起来发现，通用能力在高复杂度场景下不够用。拿任务配置来说：一个任务要同时往 4 张表里写数据，表之间有严格的 ID 引用链，还有十几条只有老策划才知道的隐含规则——通用模式能生成，但经常出错。

所以 2.0 的核心思路是：保留通用能力作为基座，在最高频、最复杂的场景上做领域专用模式。代码量翻了一倍（4,500 → 9,400 行），但换来的是一次操作完成原本需要手动配 4 张表的工作，而且一次成功率大幅提升。

一、背景回顾

1.0 做了什么

开发了一个 AI 驱动的配表数据生成工具——策划输入一句自然语言（如"给角色表加一个火属性英雄"），系统自动完成：表定位（RAG 检索）→ 数据生成（LLM + 结构化 Prompt）→ 四重校验（类型/枚举/主键/必填）→ 安全写入 .txt 文件。

核心技术点：三路混合 RAG 检索（准确率 100%）、代码驱动 ID 分配、跨表拓扑排序联动、原子写入防损坏。

2.0 做了什么

在 1.0 通用配表能力的基础上，开发了任务配置专用模式——策划通过可视化面板选择任务类型、NPC 接取方式、任务链模式等参数，系统自动联动生成任务表 + 奖励表 + NPC 对白表 + 任务步骤表四张表的完整配置数据，一次操作完成原本需要分别手动配 4 张表的工作。

1.0 → 2.0 的核心变化

维度1.02.0
覆盖范围通用单表/跨表生成新增任务配置专用模式（4 表联动）
输入方式纯自然语言结构化面板 + 自然语言混合
表间联动基于引用关系自动拓扑业务领域深度定制（ID 派生、对白自动生成）
规则体系全局规则 1 份全局规则 + 9 份表级规则 + 1 份流程规则
代码规模~4,500 行 / 10 文件~9,200 行 / 20 文件（翻倍）

二、为什么要做专用模式

1.0 的通用模式面对任务配置时，暴露了三个核心问题：

问题一：表间关系太深。 一个任务涉及 4 张表，表间有严格的 ID 引用链。通用的"自动发现引用→拓扑排序"机制无法处理"任务 ID 派生出对白 ID 和步骤 ID"这种业务特有的派生关系。

问题二：自然语言太模糊。 从"创建一个 NPC 接取的 3 环奇遇任务"中用正则提取任务类型 ID、NPC 实例 ID、链式模式……鲁棒性不够，稍微换个说法就解析失败。

问题三：领域规则太密集。 仅任务表一张表就有 ID 范围约定、资源路径模板、Dict 列分组、布尔值特殊写法等十几条规则，全塞进通用 prompt 既放不下也不精准。

结论：通用模式适合弱关联的跨表场景（角色 + 天赋 + 装备），但强业务规则场景需要领域专用工作流。

三、方案设计

3.1 面板化输入：结构化参数 + 自然语言

核心设计哲学：确定性参数用面板选，创意性内容用自然语言写。

┌─────────────────────────────────────────────────┐
│  任务类型  [奇遇 (ID:4) — ID段: 600000+  ▼]     │
│  任务数量  [3]                                    │
│                                                   │
│  ☑ 任务链                                         │
│    ● 多任务串联（N 条任务，NextMission 链接）       │
│    ○ 多步骤模式（1 条任务 + N 条步骤）             │
│                                                   │
│  ☑ NPC 对话接取                                    │
│    NPC 实例 ID: [_________]                        │
│    对白写入目标: [对白配置表  ▼]                    │
│                                                   │
│  [用自然语言描述任务故事、目标、步骤……]              │
│             [ 🚀 生成数据 ]                        │
└─────────────────────────────────────────────────┘

面板选项（类型、NPC ID、奖励模板）由代码直接消费，不经过正则解析。

3.2 四表联动生成

一次任务配置最多联动 4 张表，系统自动处理所有 ID 引用关系：

ID 类型派生规则
任务 ID按任务类型分配到对应 ID 段
奖励 ID独立分配，写入任务表引用字段
对白 ID从任务 ID 派生
步骤 ID任务ID × 100 + 序号

关键原则——ID 全部由代码处理，不交给 LLM。

四、关键技术点

4.1 本地化双字段模式

问题：游戏配置表的文本字段不直接存中文。Name 列存的是本地化 Key（如 task_Name_10001），真正的中文在旁边的 Name_LN 列。早期让 LLM 同时理解 Key 和文本的关系，经常混淆。

方案：建立通用双字段规则——LLM 只生成 _LN 字段的中文文本，Key 字段全部由系统代码回填。这个模式覆盖了 4 张表的 6 对字段，固化为全局通用规则后，新表接入时只要发现 _LN 列就能自动适配。

4.2 真实数据逆向分析

问题：Schema 定义只告诉你"字段是什么类型"，不告诉你"实际怎么用"。

方案：对策划提供的完整生产数据进行统计分析，提取隐含的业务规则：不同任务类型使用不同 ID 段、资源路径有多种模板、布尔字段新老数据写法不同……

感悟：Schema 是"字段类型说明书"，真实数据才是"字段使用说明书"。后者对提示词工程更关键。

4.3 三层规则注入体系

┌────────────────────────────┐
│ 全局规则  generator_rules  │  所有表通用（本地化模式、ID 约定...）
├────────────────────────────┤
│ 表级规则  table_rules/*    │  每张表专属（9 张表各一份）
├────────────────────────────┤
│ 流程规则  flow_rules/*     │  跨表联动工作流（表间依赖、生成顺序）
└────────────────────────────┘

所有规则文件都是 Markdown——策划或开发者可以直接编辑来调整 LLM 行为，无需改代码。这是整个 2.0 最重要的工程决策之一。

4.4 数据先行原则

提示词工程的上限取决于学习数据的充分性。 数据不足时，提示词再精妙也无法让 LLM 生成正确结果。

宁可多问一个"蠢问题"，也不要写一条错误的规则。

4.5 采样参数调优

蓄水池 k 从 5 调到 15，prompt few-shot 从 3 调到 8。磁盘仅增 1 MB，但参考数据量提升了 167%。

结论：few-shot 质量对 LLM 生成质量的影响远大于 prompt 措辞的精心雕琢。

五、踩坑与经验总结

问题根因解决方案收获
LLM 生成 Key 而非中文文本prompt 没区分 Key 和 _LN 的职责双字段模式：LLM 只管 _LN职责分离比"教 LLM 理解复杂规则"更有效
Schema 采样不足蓄水池 k 太小k 调到 15，few-shot 展 8 条少量存储换大幅质量提升
枚举映射不完整Schema 采样只覆盖部分值向策划要了完整映射表宁可多问，不猜规则

三条核心感悟

1. 提示词工程的上限取决于学习数据的充分性。

Schema 不够就分析真实数据，真实数据不够就向策划要。

2. 确定性逻辑和创意内容要严格分离。

ID 分配、Key 生成、格式校验——全部走代码。任务名称、对白台词、步骤描述——才交给 LLM。

3. 领域专用模式比通用模式强得多。

当一个场景有足够密集的业务规则时，定制一条专用工作流的 ROI 远高于不断修补通用逻辑。

六、工程数据

模块1.02.0变化
数据生成核心~1,260 行~3,490 行+2,230
Web UI（后端+前端）~880 行~2,830 行+1,950
规则文件（Markdown）0~790 行（11 文件）+790
总计~4,560 行~9,400 行+4,840

201 个验证测试全部通过（100%），整个系统已在真实项目数据上跑通端到端流程。