自然语言配表 2.0：从通用工具到领域配置专家

turboyuan

529人浏览 · 2026-03-26 11:30:40

turboyuan · 2026-03-26 11:30:40 发布

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.0	2.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+  ▼]     │  ← 预设类型+ID段提示
│  任务数量  [3]                                    │
│                                                   │
│  ☑ 任务链                                         │  ← 开关控制
│    ● 多任务串联（N 条任务，NextMission 链接）       │
│    ○ 多步骤模式（1 条任务 + N 条步骤）             │
│                                                   │
│  ☑ NPC 对话接取                                    │  ← 开关控制
│    NPC 实例 ID: [_________]                        │
│    对白写入目标: [对白配置表  ▼]                    │
│    → 自动联动生成对白数据                          │
│                                                   │
│  奖励配置  ● 标准模板  ○ 自定义物品                │
│                                                   │
│  [用自然语言描述任务故事、目标、步骤……]              │
│                                                   │
│             [ 🚀 生成数据 ]                        │
└─────────────────────────────────────────────────┘

面板选项（类型、NPC ID、奖励模板）由代码直接消费，不经过正则解析。同时所有选项保留回退逻辑——不选也能从自然语言中尝试提取，兼容不用面板直接打字的场景。

3.2 四表联动生成

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

策划输入："猎人委托冒险者寻找失踪旅人，途中需要击败怪物并搜集线索"
                              ↓
                    ┌─────────────────────┐
                    │  ① 任务表 × 3       │  3 环任务链
                    │  名称、描述、流程路径 │  ID 按类型自动分配到对应段
                    │  Next 链自动串联     │  资源路径按类型选模板
                    └────────┬────────────┘
                             │
            ┌────────────────┼────────────────┐
            ↓                ↓                ↓
  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐
  │ ② 奖励表 ×3  │  │ ③ 对白表 ×N  │  │ ④ 步骤表 ×N      │
  │ 标准模板3顺位 │  │ NPC接取对白   │  │ 追踪面板+详细描述 │
  │ 经验+货币+积分│  │ LLM写台词    │  │ LLM写步骤文本    │
  └──────────────┘  └──────────────┘  └──────────────────┘

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

ID 类型	派生规则	说明
任务 ID	按任务类型分配到对应 ID 段	不同类型有约定的 ID 范围
奖励 ID	独立分配，写入任务表引用字段	最后一环才配奖励
对白 ID	从任务 ID 派生	写入接取配置字段
步骤 ID	`任务ID × 100 + 序号`	保证层级关系可读

3.3 任务链的两种实现方式

策划在面板上选择任务链后，可以选择两种实现方式：

方式一——多任务串联（传统方式）：生成 N 条任务数据，通过 NextMissionList 首尾相连。第 1 条配 NPC 接取，后续任务自动隐藏。只有最后一环配奖励。

方式二——多步骤模式（新增）：只生成 1 条任务数据 + N 条步骤数据。每个步骤包含追踪面板的简短提示（“前往码头”）和详细描述。适合一个复杂任务内部有多个阶段的场景。

四、关键技术点

4.1 本地化双字段模式

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

方案：建立通用双字段规则——LLM 只生成 _LN 字段的中文文本，Key 字段全部由系统代码回填。

LLM 的职责（只管中文文本）            系统自动回填（Key）
─────────────────────               ────────────────────
Name_LN:    "寻找失踪的旅人"    →    Name:    task_Name_10001
Desc_LN:    "猎人委托你..."     →    Desc:    task_Desc_10001
Detail_LN:  "你来得正好！"      →    Detail:  dialog_Detail_100011_1
Content_LN: "前往码头调查"      →    Content: step_Content_1000101

这个模式覆盖了 4 张表的 6 对字段。固化为全局通用规则后，新表接入时只要发现 _LN 列就能自动适配。

4.2 真实数据逆向分析

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

方案：对策划提供的完整生产数据进行统计分析，提取隐含的业务规则：

发现	分析方法	应用
不同任务类型使用不同 ID 段	统计 300+ 条任务的 ID 分布	自动按类型分配 ID 到对应范围
资源路径有多种模板	分析路径命名规律	根据类型自动选择路径模板
布尔字段新老数据写法不同	全表扫描对比	统一新生成的写法
接取模式只有两种合法值	全表扫描去重	约束 LLM 不生成非法值
某些字段是 Dict 列分组	分析 txt 列头声明	正确处理嵌套子字段

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

4.3 三层规则注入体系

为了让 LLM 在不同场景下都能生成准确数据，设计了三层可编辑的规则体系：

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

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

4.4 数据先行原则

这是贯穿 2.0 开发的核心工作原则：

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

实践中的做法：

Schema 中只有 5 条采样？主动向策划要完整数据，而不是基于 5 条数据猜规则
某个字段只知道部分枚举值？主动确认完整映射（实际从 5 种扩展到了 13 种）
不确定两个字段的关系？主动看引擎代码分析字段用途，再写入规则文件
策划说的和现有规则矛盾？以策划提供的为准，立即更新规则

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

4.5 采样参数调优

问题：1.0 的蓄水池采样 k=5，LLM prompt 只展示 3 条参考。对 30+ 字段的表来说，3 条参考远远不够，LLM 容易遗漏字段或误解格式。

方案：量化分析后找到最优平衡点——蓄水池 k 从 5 调到 15，prompt few-shot 从 3 调到 8。磁盘仅增 1 MB，构建索引多 83 秒，LLM 上下文增量不到 1%，但参考数据量提升了 167%。

结论：few-shot 质量对 LLM 生成质量的影响远大于 prompt 措辞的精心雕琢。投入少量存储和构建时间换大幅质量提升，性价比极高。

4.6 写入目标灵活配置

问题：某些表的 Schema 中记录的源文件不是最合适的写入目标——因为多个 Excel Sheet 可以导出到同一个 Lua 文件，Schema 只记录了其中一个 Sheet 对应的 txt。

方案：三级优先级覆盖机制——前端下拉选择 > config 全局配置 > Schema 原值。策划可以在界面上直接选写入目标，也可以在配置文件里设默认覆盖，两层都不配就用 Schema 回退。

五、踩坑与经验总结

问题	根因	解决方案	收获
LLM 生成 Key 而非中文文本	prompt 没区分 Key 和 _LN 的职责	双字段模式：LLM 只管 _LN	职责分离比"教 LLM 理解复杂规则"更有效
Schema 采样不足	蓄水池 k 太小	k 调到 15，few-shot 展 8 条	少量存储换大幅质量提升
校验器对原生格式报错	把 txt 原生列表格式当 JSON 校验	识别原生格式并豁免	校验器要理解数据的"方言"
数据写入了错误的 txt	Schema 元信息不准确	三级优先级覆盖	元数据不可靠时要提供覆盖手段
UI 开关点击无反应	`<div>` 包裹 checkbox，absolute 定位的滑块遮挡	改用 `<label>` 包裹	CSS 定位覆盖会截断事件冒泡
枚举映射不完整	Schema 采样只覆盖部分值	向策划要了完整映射表	宁可多问，不猜规则
新增的生成方法不工作	调用了不存在的内部方法名	参照已有的同类方法保持一致	新方法要和已有方法保持同构

三条核心感悟

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

Schema 不够就分析真实数据，真实数据不够就向策划要。这不是"偷懒"，这是提示词工程的正确方法论。

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

ID 分配、Key 生成、格式校验——全部走代码，100% 确定性。任务名称、对白台词、步骤描述——才交给 LLM 发挥创造力。混在一起只会两头出错。

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

通用模式是"什么都能做，但什么都做不深"。当一个场景有足够密集的业务规则时（任务配置就是），定制一条专用工作流的 ROI 远高于不断修补通用逻辑。

六、工程数据

代码规模变化

模块	1.0	2.0	变化
数据生成核心	~1,260 行	~3,490 行	+2,230
Web UI（后端+前端）	~880 行	~2,830 行	+1,950
解析/采样/检索/写入	~1,940 行	~2,060 行	+120
配置+入口	~210 行	~240 行	+30
核心代码合计	~4,290 行	~8,620 行	+4,330
规则文件（Markdown）	0	~790 行（11 文件）	+790
总计	~4,560 行	~9,400 行	+4,840

增量集中在两个模块：

数据生成核心（+2,230 行）：新增任务配置生成器类，含 4 表联动逻辑、对白生成、步骤生成
Web UI（+1,950 行）：配置面板交互、条件展开、动态标签切换、预览序列化

规则文件体系

层级	文件数	行数	作用
全局规则	1 个	~140 行	本地化模式、ID 范围、通用约定
流程规则	1 个	~230 行	4 表依赖关系、任务链规则、奖励模板
表级规则	9 个	~420 行	每张表的字段填写规范和数据示例
合计	11 个	~790 行	策划可直接编辑的"LLM 行为配置文件"

验证测试

测试阶段	测试数	通过	覆盖内容
配置面板集成	7	✅	导入、方法签名、HTML 元素
字段规则修正	35	✅	字段废弃/引用/格式纠正
真实数据应用	16	✅	ID 分配、路径模板、配置
对白表集成	50	✅	全流程+规则文件+Schema
采样调优	5	✅	参数+文档同步
本地化规则固化	25	✅	规则+代码+功能
写入选择器	16	✅	前端+后端+优先级
多步骤模式	47	✅	前端+后端+分支+规则
累计	201	✅ 100%

七、思考：AI 工具的"通用"与"专用"

做完 1.0 和 2.0 之后，我对"AI 工具怎么在游戏开发中落地"有了一些思考：

通用能力是基座，专用模式是价值

1.0 的通用配表能力很酷——输入一句话就能往任意表里加数据。但实际使用时，策划最常用的场景是任务配置，而这恰恰是规则最复杂、通用模式最吃力的场景。

2.0 的做法是：保留通用能力作为基座，在高频高复杂度的场景上叠加专用模式。专用模式的开发成本更高（+4,800 行代码、+790 行规则），但效果提升是质变级的——从"能用但经常出错"到"一次成功率极高"。

提示词工程 ≠ 写 prompt

很多人理解的提示词工程是"怎么把 prompt 写得更好"。实际做下来发现，80% 的提示词工程工作量不在写 prompt，而在准备数据：

分析真实生产数据，提取隐含规则
与业务方反复确认字段含义和填写约定
把业务规则结构化为可注入的 Markdown 文件
调优 few-shot 采样数量和质量
建立"数据不足时主动要数据"的工作习惯

prompt 本身只是最后的"组装"环节。

确定性逻辑 vs 概率推理的边界

1.0 踩过的最大坑是让 LLM 分配 ID。2.0 把这个原则推到了极致：

代码负责：ID 分配、ID 派生、Key 生成、格式校验、字段回填
LLM 负责：任务名称、对白台词、步骤描述、奖励搭配建议

边界很清晰：有确定性答案的事情不交给概率模型，需要创造力的事情才交给 LLM。

八、下一步方向

维度	当前状态	提升方向
场景覆盖	仅任务配置	扩展对白独立配置、NPC 配置等流程
对白质量	LLM 自由生成	支持风格模板（正式/幽默/紧急）
步骤详情	只生成文本描述	联动地图坐标、击杀条件等字段
规则维护	手动编辑 Markdown	规则冲突检测 + 覆盖率统计
批量模式	每次配一组任务	批量导入任务列表一键配置
NPC 联动	手动输入 ID	自动关联 NPC 表获取名称