用 AI 帮 Unity 查配置表错误，比让它直接写玩法靠谱多了

如果让我排一个“AI 在 Unity 项目里最容易稳定产出价值的活”，配置校验我会给很高的排名。

原因非常现实。

玩法代码复杂、状态多、边界长，AI 很容易一本正经地漏关键条件。

但配置校验这种事，反而和它很搭。

因为这类任务通常具备几个特点：

  • 规则明确
  • 输入结构清楚
  • 错误模式重复
  • 很适合先出一个骨架再人工补细节

说白了，这种活很像“有边界的脏活累活”。

AI 在这里经常比写主玩法更靠谱。

一、为什么 Unity 项目特别需要配置校验工具

项目越往后，配置越多，越容易出现这种问题：

  • 引用了不存在的资源 ID
  • 掉落表权重和不对
  • 合成链断了
  • 订单奖励填错档位
  • 活动时间区间互相重叠

这些错误很多不是算法错，而是“人总会手滑”。

如果等到运行时才发现，成本通常比较高。

所以配置校验工具最值钱的地方，不是炫技，而是让错误更早暴露。

二、最适合托管给 AI 的，不是“帮我设计规则”，而是“按规则生成校验器”

这两者差很多。

让 AI 设计规则，它可能会开始发挥。

让 AI 按你给定的规则生成校验逻辑，它通常更老实。

比如你可以先自己定清楚：

  1. 哪些字段不能为空。
  2. 哪些 ID 必须能在别的表里找到。
  3. 哪些数值范围有上下界。
  4. 哪些组合关系必须满足。

然后再让 AI 帮你把这些规则翻译成编辑器校验代码。

这样它输出的东西会稳很多。

三、一个更实用的提示词例子

下面这种提示词，就比“帮我写个配置检查工具”强不少：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
你是资深 Unity 工具链工程师。
请帮我写一个 Unity Editor 校验器，用来检查二合游戏订单配置。

项目背景：
1. Unity 2021 LTS。
2. 订单配置使用 ScriptableObject 持有一个 OrderConfig 列表。
3. 每个 OrderConfig 包含：orderId、targetItemId、targetCount、rewardGold、rewardExp。

校验规则：
1. orderId 不能为空且不能重复。
2. targetItemId 必须存在于 ItemConfig 表中。
3. targetCount 必须 > 0。
4. rewardGold 和 rewardExp 不能为负数。
5. 请输出错误列表，格式包含 orderId 和具体错误原因。

要求：
1. 使用 UnityEditor 实现。
2. 提供 ValidateAll 方法。
3. 代码尽量拆分成清晰的小函数。
4. 先输出完整代码，再解释如何扩展更多规则。

这种输入很关键。

因为你不是让 AI 猜项目，而是在让它补执行层。

四、一个简化版配置校验器例子

下面这段代码就属于很适合 AI 先帮你搭骨架，再自己往里加规则的类型。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

[CreateAssetMenu(menuName = "Configs/Order Table")]
public class OrderTable : ScriptableObject
{
	public List<OrderConfig> orders = new List<OrderConfig>();
}

[System.Serializable]
public class OrderConfig
{
	public string orderId;
	public string targetItemId;
	public int targetCount;
	public int rewardGold;
	public int rewardExp;
}

public static class OrderConfigValidator
{
	public static List<string> ValidateAll(OrderTable orderTable, HashSet<string> validItemIds)
	{
		var errors = new List<string>();

		if (orderTable == null)
		{
			errors.Add("OrderTable is null.");
			return errors;
		}

		ValidateDuplicateIds(orderTable.orders, errors);

		foreach (var order in orderTable.orders)
		{
			ValidateSingleOrder(order, validItemIds, errors);
		}

		return errors;
	}

	private static void ValidateDuplicateIds(List<OrderConfig> orders, List<string> errors)
	{
		var duplicateIds = orders
			.Where(order => !string.IsNullOrEmpty(order.orderId))
			.GroupBy(order => order.orderId)
			.Where(group => group.Count() > 1)
			.Select(group => group.Key);

		foreach (var duplicateId in duplicateIds)
		{
			errors.Add($"Duplicate orderId: {duplicateId}");
		}
	}

	private static void ValidateSingleOrder(OrderConfig order, HashSet<string> validItemIds, List<string> errors)
	{
		var orderKey = string.IsNullOrEmpty(order.orderId) ? "<empty orderId>" : order.orderId;

		if (string.IsNullOrEmpty(order.orderId))
		{
			errors.Add($"{orderKey}: orderId is empty.");
		}

		if (string.IsNullOrEmpty(order.targetItemId) || !validItemIds.Contains(order.targetItemId))
		{
			errors.Add($"{orderKey}: targetItemId is invalid -> {order.targetItemId}");
		}

		if (order.targetCount <= 0)
		{
			errors.Add($"{orderKey}: targetCount must be > 0.");
		}

		if (order.rewardGold < 0 || order.rewardExp < 0)
		{
			errors.Add($"{orderKey}: reward values cannot be negative.");
		}
	}
}

这类代码的好处是，不难，但烦。

而“烦”这件事，正是 AI 比较适合帮你省时间的地方。

五、第二轮提示词，更适合让 AI 补“漏网规则”

我自己常用这种追问方式：

1
2
3
4
5
6
请继续审查刚才的配置校验代码。
从二合游戏订单系统角度，再补 5 条高价值校验规则。
要求：
1. 优先考虑容易导致线上事故的规则。
2. 每条规则说明为什么值得校验。
3. 只输出新增规则和对应的函数，不要重写全部代码。

这种追问特别适合把 AI 从“代码生成器”推进到“规则补全助手”。

六、配置校验最该防的，不是语法错，而是业务上看着像对、实际有坑

比如这些情况：

  • 奖励没填错，但填得极不合理
  • 时间区间没重叠，但顺序设计有问题
  • 链路没断，但某阶段需求异常集中

这些问题纯靠基础字段检查未必能抓出来。

所以 AI 的第二层价值，是帮你把“经验规则”整理成工具规则。

前提当然还是一样：

你得先知道自己项目里哪些坑最常见。

七、最后一句

AI 在 Unity 里最实用的地方，往往不是替你写最核心的玩法系统。

而是把这些本来就该做、但经常因为嫌麻烦而拖着不做的工具链活，先推一把。

配置校验就是很典型的一类。

你把规则说清楚，它就很适合当一个还算勤快的代码装配工。