从 2025 年 7 月到 2026 年 6 月，我后面这批博客，慢慢写成了两条线。

一条是二合游戏客户端工程。

另一条是 Unity 开发里，哪些活适合让 AI 先帮你干 60 分版本。

前者偏运行时、性能、架构、存档、防作弊。

后者偏工具链、排查、回归、编辑器工具、工程流程。

如果你是第一次点进来，直接从归档一篇篇翻，效率其实不高。

所以这篇就当一个系列导航。

不讲新概念，纯粹帮你省时间。

一、如果你主要关心二合游戏客户端工程，先看这一条线

这条线更适合这些人：

• 正在做二合、合成、订单类手游
• 想补客户端性能、棋盘结构、弱联网存档这类问题
• 对“为什么这种项目看着不重，做起来一堆坑”有切身感受

1. 从性能入门看

建议先从这 4 篇开始：

• 二合游戏看着很休闲，为什么 UI 一复杂就开始掉帧？
• 二合棋盘一热闹就卡？问题往往不在棋子，在你太想“有反馈”了
• 二合游戏最容易让人上头的，不是装修剧情，是生成器和掉落表那点小心机
• 二合游戏的订单系统，千万别只把它当任务列表，它其实在偷偷控制玩家节奏

这几篇基本能把二合项目最常见的客户端压力点和系统节奏感先搭起来。

2. 如果你已经踩到存档和安全问题了

接着看这 2 篇：

• 弱联网二合游戏的存档，到底该信服务器，还是该信本地？
• 弱联网游戏最怕的，不是断网，是玩家比你更懂本地存档

这两篇更偏架构边界和工程取舍，不是银弹方案，但适合先把脑子里的边界划出来。

3. 如果你已经进入“内容越堆越重”的阶段

建议顺着看这 5 篇：

• 二合游戏越做越重时，真正救命的往往不是加班，是那套顺手的配置工具链
• 二合游戏活动越多越赚钱，也越容易把客户端做崩，活动工程化该早点上桌了
• 二合游戏的新手引导，别只会加手指动画了，真正难的是状态机和容错
• 二合棋盘为什么越玩越乱？问题不只是策划设定，很多时候是对象生命周期没管住
• 二合游戏上了低端机就掉链子？别只盯优化点，先把降级策略设计成系统

这几篇连起来看，会比较像“项目中后期开始收债”时该先看哪些面。

4. 如果你已经开始盯线上稳定性和工程回路

可以继续看：

• 二合游戏优化别只看体感，埋点和性能回归没跟上，很多“优化”其实只是心理安慰

这篇更像是前面那些运行时问题的收口文。

它不再讲单个优化点，而是讲你怎么证明自己真的优化了，而不是自我感觉不错。

二、如果你主要关心 Unity + AI 工程工作流，走另一条线

这条线更适合这些人：

• 已经在用 Copilot、ChatGPT、Claude 之类的工具，但总觉得“能用，没用透”
• 想知道 Unity 开发里，到底哪些活适合先交给 AI
• 不想看空泛 AI 观点，只想看具体苦活怎么省时间

这条线我刻意没写成“AI 很厉害”的宣传稿。

核心就一句话：

别让 AI 替你拍板。

让它先把那些机械、重复、容易拖着不做的活推到 60 分。

1. 先从最容易落地的工具类开始

建议先看这 3 篇：

• 用 AI 帮 Unity 写编辑器工具挺香，但前提是你别只会说“帮我写个工具”
• 用 AI 帮 Unity 查配置表错误，比让它直接写玩法靠谱多了
• 编辑器批处理脚本总是又长又烦？这类活真的很适合先让 AI 打个底

这三篇比较像一组。

核心都是编辑器工具、规则检查、批处理脚本这类特别适合 AI 起草的活。

2. 如果你更关心排查和诊断

建议看这 3 篇：

• AI 能不能帮你查 Unity 卡顿？能，但你得先把现场证据喂明白
• Unity 日志一多就像看天书？AI 很适合帮你做第一轮异常归因
• 让 AI 先帮你列 Code Review 清单，比每次拍脑袋看提交靠谱多了

这组更偏“人已经在工程现场里了，怎么让 AI 帮你先收集、归类、整理判断面”。

3. 如果你更关心测试、回归和流程化

建议看这 4 篇：

• AI 能不能帮 Unity 写回归脚本？能，尤其适合那些重复到让人犯困的检查项
• 让 AI 先帮你列回归清单，比等版本提测后大家一起脑补靠谱多了
• 老 Unity 模块最怕没人敢动，AI 倒是很适合先帮你补那层测试和替身
• 埋点设计最怕事后补锅，AI 倒是很适合先帮你把埋点草图铺出来

这组更像项目中后期的日常工程维护线。

4. 如果你做的是资源、热更新、发布链路

建议顺着看这 4 篇：

• 热更新最怕资源依赖一团乱，AI 倒是挺适合先帮你查这笔账
• 资源规范最怕靠口头约定，AI 倒是很适合先帮你当那个不嫌烦的检查员
• CSV 导表这类脏活很适合先交给 AI，但别让它偷偷把配置协议写歪了
• 打包前总怕漏资源？AI 很适合先帮你做那层资源发布前检查

这几篇更像工具链和发布链的苦活合集。

三、如果你时间不多，我建议就按这条最短路径读

如果你是 Unity 客户端，时间又不多，我建议先看这 6 篇：

1. 二合游戏看着很休闲，为什么 UI 一复杂就开始掉帧？
2. 弱联网二合游戏的存档，到底该信服务器，还是该信本地？
3. 二合游戏活动越多越赚钱，也越容易把客户端做崩，活动工程化该早点上桌了
4. 用 AI 帮 Unity 写编辑器工具挺香，但前提是你别只会说“帮我写个工具”
5. AI 能不能帮你查 Unity 卡顿？能，但你得先把现场证据喂明白
6. AI 能不能帮 Unity 写回归脚本？能，尤其适合那些重复到让人犯困的检查项

这 6 篇差不多能把我这一轮最想说的东西看个大概：

• 二合项目哪里最容易出工程问题
• Unity 客户端后期为什么总在收债
• AI 到底该进哪些开发环节，才是真的省时间

四、这批文章的共同态度，其实就一句话

无论是二合客户端工程，还是 Unity + AI 工作流，我后面写这些文章时，其实都在强调同一件事：

别迷信一个“神奇功能”会替你把问题自动搞定。

二合游戏不是因为玩法轻，就没有技术债。

AI 也不是因为现在好用，就能替你做工程判断。

真正值钱的，往往还是这些东西：

• 结构先搭对
• 边界先划清
• 苦活尽量工具化
• 重复活尽量流程化
• 让系统越来越容易验证，而不是越来越靠感觉

如果这份导航能让你少翻半天归档，直接跳到自己真正关心的那几篇，那它就算有用了。

后面我应该还会继续沿着这两条线写。

毕竟项目里的坑，不会因为我写过博客就自动消失。

它们只会换个方式再来一遍。

很多团队做 Code Review 时，最大的问题不是没人看。

而是看得不稳定。

有时候盯性能，有时候盯架构，有时候盯命名，有时候纯看心情。

这就会导致一个问题：

同样类型的风险，这次被看见，下次可能就漏过去了。

这类流程问题，AI 其实能帮一个挺实用的忙。

不是替你做最终 review 判断。

而是先帮你把“针对某类改动，该重点看什么”的检查清单列出来。

一、AI 最适合帮忙的，不是下结论，而是先把检查面铺平

比如这次改的是：

• UGUI 面板
• 对象池
• 活动入口逻辑
• 存档同步

那每一类改动，本来就应该有一些固定高风险点。

AI 很适合先帮你把这些点整理成 review 提示清单。

二、一个实用提示词例子

1
2
3
4
5
6
7
8
9
10
11
12

你是资深 Unity 客户端工程师。
请帮我生成一份针对这次改动的 Code Review 检查清单。

改动类型：
1. UGUI 面板重构。
2. 奖励飞行动画对象池调整。
3. 活动入口显示逻辑改动。

要求：
1. 按模块分类输出 review 点。
2. 标出性能风险、状态风险、空引用风险、兼容风险。
3. 如果是二合游戏主棋盘相关逻辑，优先关注高频操作链路。

三、它最值钱的地方，是减少“纯靠经验临场想”的波动

经验当然很重要。

但经验如果每次都只存在于某个人脑子里，review 质量就会不稳定。

而 AI 很适合先把这套“半结构化经验”整理成一版清单。

这样至少不会每次都从空白开始。

四、最后一句

AI 在 Code Review 流程里，最有价值的通常不是替你判代码好坏。

而是让你别每次都靠拍脑袋决定这次重点看什么。

它先把检查面摊平，人再做最终判断，这个配合方式往往更靠谱。

Unity 编辑器里有一类脚本，技术含量未必最高，但特别容易又长又碎。

比如批量做这些事：

• 改一批资源导入设置
• 批量替换组件字段
• 统一 prefab 某个默认值
• 扫一遍场景把老组件换成新组件

这类脚本最典型的特点就是：

你不难想到思路。

但真要手写，特别容易拖。

AI 在这里很合适。

一、为什么批处理脚本适合 AI 起稿

因为它通常具备：

• 输入清楚
• 操作步骤明确
• 样板代码多
• 容易人工复核

你要做的，本来就不是让 AI 发挥创意。

而是让它先把 AssetDatabase、Selection、Undo、批量遍历这些机械部分搭起来。

二、一个实用提示词例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14

你是资深 Unity 编辑器工具工程师。
请帮我写一个批处理脚本。

目标：
1. 扫描当前选中的 prefab。
2. 找到其中所有 Text 组件。
3. 把 raycastTarget 统一设为 false。
4. 支持 Undo。
5. 修改后标记资源 dirty。

要求：
1. 提供菜单入口。
2. 代码拆成扫描、修改两个方法。
3. 先给完整代码，再说明边界风险。

三、一个适合起步的代码壳子

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

using UnityEditor;
using UnityEngine;
using UnityEngine.UI;

public static class BatchDisableTextRaycast
{
	[MenuItem("Tools/UI/Batch Disable Text Raycast")]
	public static void Execute()
	{
		foreach (var obj in Selection.objects)
		{
			var path = AssetDatabase.GetAssetPath(obj);
			var prefab = AssetDatabase.LoadAssetAtPath<GameObject>(path);
			if (prefab == null)
			{
				continue;
			}

			var texts = prefab.GetComponentsInChildren<Text>(true);
			foreach (var text in texts)
			{
				Undo.RecordObject(text, "Disable Text Raycast");
				text.raycastTarget = false;
				EditorUtility.SetDirty(text);
			}
		}
	}
}

四、最后一句

编辑器批处理脚本这种活，很典型地属于“人人都知道该做，但很容易被拖着不做”。

让 AI 先把 60 分版本起出来，再由人收边界，通常性价比很高。

很多项目的埋点都是这样长出来的。

先做功能。

等上线前或出问题后，再开始问：

• 这里要不要打点
• 这个字段够不够
• 为什么这条链路看不清

最后埋点就容易越补越乱。

这类工作其实很适合让 AI 先帮你打草稿。

不是让它决定你该看什么数据。

而是让它先把“某条玩法链路需要哪些观察点”整理出来。

一、AI 最适合做埋点设计的哪一部分

最适合做结构化草图。

比如你已经知道一条链路是：

• 进入主棋盘
• 点击生成器
• 合成
• 提交订单
• 领奖励

那 AI 很适合先帮你拆：

• 关键事件点
• 事件字段
• 可能的状态字段
• 哪些字段更偏性能、哪些更偏行为

二、一个实用提示词例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14

你是资深 Unity 数据与埋点设计工程师。
请帮我为二合游戏的订单完成链路设计一版客户端埋点草图。

链路：
1. 玩家打开订单面板。
2. 提交订单。
3. 触发奖励飞行动画。
4. 关闭面板返回主棋盘。

要求：
1. 输出事件名建议。
2. 输出每个事件建议字段。
3. 区分行为字段和性能字段。
4. 标注哪些字段是高优先级必留。

三、代码层面也可以让 AI 先补骨架

1
2
3
4
5
6
7

public static class AnalyticsEventNames
{
		public const string OrderPanelOpen = "order_panel_open";
		public const string OrderSubmit = "order_submit";
		public const string RewardFlyStart = "reward_fly_start";
		public const string RewardFlyEnd = "reward_fly_end";
}

它不复杂，但这种壳子越早整理，后面越不容易一堆字符串到处飞。

四、最后一句

埋点设计最怕的，不是字段不够多，而是链路边界没先想清楚。

AI 很适合帮你先把这张草图铺开，让你少从空白页开始发呆。

Unity 项目每次打包前，大家心里通常都会有几个老朋友：

• 有没有漏打资源
• 有没有资源命名还没改干净
• 有没有测试图、废资源、临时 prefab 混进去
• 某个活动资源是不是还挂着开发路径

这些问题很多时候不是技术难题。

而是发布前检查特别碎、特别烦、特别容易靠人脑漏掉。

这种场景很适合让 AI 先帮你搭一层“发布前检查壳”。

一、AI 最适合帮忙的不是“决定该发什么”，而是“把检查规则翻成工具”

你真正有价值的，是项目经验。

比如你知道哪些问题最容易出现在发版前：

• 开发测试资源没删
• 资源路径不规范
• 某些图没进正确图集
• bundle 命名不符合规则

AI 擅长的，则是把这些规则快速装配成可跑代码。

二、一个实用提示词例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

你是资深 Unity 工具链工程师。
请帮我写一个发布前资源检查工具。

项目背景：
1. Unity 2021 LTS。
2. 我们使用 AssetBundle 打包资源。
3. 发布前想扫描以下问题：
   - 文件名含 test/debug/temp 的资源
   - 没设置 AssetBundle 名称但在发布目录下的资源
   - 过大的 UI 纹理
   - 重复命名的 prefab

要求：
1. 提供菜单入口。
2. 输出汇总日志。
3. 每类问题拆成独立检查函数。
4. 先给代码，再说明如何扩展更多检查项。

三、一个适合起步的扫描骨架

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

using System.Collections.Generic;
using UnityEditor;
using UnityEngine;

public static class ReleaseAssetChecker
{
	[MenuItem("Tools/Build/Run Release Asset Checks")]
	public static void RunChecks()
	{
		var results = new List<string>();
		CheckSuspiciousNames(results);
		Debug.Log(string.Join("\n", results));
	}

	private static void CheckSuspiciousNames(List<string> results)
	{
		var guids = AssetDatabase.FindAssets(string.Empty, new[] { "Assets" });
		foreach (var guid in guids)
		{
			var path = AssetDatabase.GUIDToAssetPath(guid);
			var lowerPath = path.ToLowerInvariant();
			if (lowerPath.Contains("test") || lowerPath.Contains("debug") || lowerPath.Contains("temp"))
			{
				results.Add($"[SuspiciousName] {path}");
			}
		}
	}
}

四、这类工具很适合 AI 继续往下补

比如继续追问：

1
2
3
4
5
6

请继续扩展这个发布前检查工具。
1. 增加对 AssetBundle 名称为空的检查。
2. 增加 Texture2D 宽高过大检查。
3. 增加 prefab 重名检查。
4. 输出结果按问题类型分组。
5. 只输出新增和替换的方法。

五、最后一句

发版前资源检查这种活，最难的不是写出原理，而是把团队脑子里那套“老经验”稳定执行下去。

AI 很适合在这里当装配工，把这些经验先翻成能跑的检查器。

很多 Unity 老项目里都有这种模块。

你知道它该整理了。

也知道它写法不太现代，耦合偏重，测起来也麻烦。

但大家又都不太想先动。

原因很现实：

• 一动怕崩
• 没测试托底
• 边界不清楚
• 改完还要顺手救火

这种情况下，AI 一个挺实用的切入点，不是直接帮你大重构。

而是先帮你补那层最容易拖着不做的东西：测试壳子、依赖替身、接口草稿。

一、为什么老模块补测试这件事，特别适合 AI 先起版

因为它最烦的部分，经常不是测试思路本身。

而是这些机械工作：

• 把依赖抽成接口
• 写假对象或 stub
• 搭测试类结构
• 把 Arrange/Act/Assert 基本壳子补起来

这些东西人工当然能做。

但真的很容易拖。

AI 在这里最大的价值，就是先把这些“启动成本”压下去。

二、最不该做的事：把整个烂模块丢给 AI 说“帮我重构”

这通常不太靠谱。

因为老模块的问题往往不只是代码丑。

还包括：

• 业务约束多
• 历史兼容逻辑多
• 外部依赖复杂
• 生命周期和场景强耦合

这类东西一股脑丢给 AI，很容易产出一份看着整洁、实际上没法直接接项目的重构建议。

更好的切法，是先只让它做一小步。

三、我更推荐的提示词：先帮我把这个类变得“能测一点”

1
2
3
4
5
6
7
8
9
10

你是资深 Unity 客户端重构工程师。
下面是一个老的 MonoBehaviour 类，它直接依赖单例、静态方法和 UI 组件，导致很难写测试。

请先不要重构整个类。
先做这几件事：
1. 找出最适合先抽象成接口的外部依赖。
2. 给出一个最小可行的接口拆分方案。
3. 生成一个对应的测试类骨架。
4. 如果需要 fake 或 stub，请给出最简单版本。
5. 不要改业务逻辑，只做“让它更容易测试”的第一步。

这种问法会比“帮我优化一下”靠谱很多。

因为它限制了 AI 的发挥范围。

四、一个很典型的最小替身例子

比如原来某个模块直接这样拿资源和存档：

1
2
3
4
5
6
7
8

public class RewardService
{
	public void GrantDailyReward()
	{
		var amount = ConfigManager.Instance.GetDailyRewardAmount();
		PlayerData.Instance.AddGold(amount);
	}
}

这类代码很常见。

问题是几乎没法单测。

更适合的第一小步，通常不是大改，而是先拆依赖：

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

public interface IRewardConfigProvider
{
	int GetDailyRewardAmount();
}

public interface IPlayerWallet
{
	void AddGold(int amount);
}

public class RewardService
{
	private readonly IRewardConfigProvider _configProvider;
	private readonly IPlayerWallet _playerWallet;

	public RewardService(IRewardConfigProvider configProvider, IPlayerWallet playerWallet)
	{
		_configProvider = configProvider;
		_playerWallet = playerWallet;
	}

	public void GrantDailyReward()
	{
		var amount = _configProvider.GetDailyRewardAmount();
		_playerWallet.AddGold(amount);
	}
}

然后让 AI 再补一个最小测试壳子，通常就很快了。

五、第二轮提示词，适合让 AI 补测试替身和边界用例

1
2
3
4
5

请继续基于刚才的接口拆分，补这些内容：
1. 给出最简单的 fake config provider 和 fake wallet。
2. 生成 NUnit 测试骨架。
3. 至少覆盖正常奖励发放和奖励为 0 的边界情况。
4. 不要引入过重的 mocking 框架。

这类追问很有价值。

因为老模块最需要的，往往不是立刻重构得多漂亮。

而是先建立一点点“动它也不至于全靠心跳”的安全感。

六、最后一句

AI 在老 Unity 模块上的最佳用法，通常不是替你拍板重构方案。

而是先帮你把那层最容易拖着不做的测试准备工作铺出来：接口草稿、替身对象、测试壳子、边界样例。

这些东西一旦有了，后面人再动模块，心理负担会小很多。

项目里很多技术债，不是完全不会还。

只是一直缺一个足够低成本的第一步。

Unity 项目做到中后期，几乎都会长出一堆调试需求。

比如：

• 跳关
• 加资源
• 强制弹活动
• 重置本地存档
• 模拟弱联网
• 手动触发某条奖励链

这些能力最后通常会落到一个开发调试面板里。

问题是，这类面板很重要，但又特别容易被写得很随手。

毕竟大家心态通常都是：

“先能用，后面再说。”

结果后面它越长越大，越来越像工具坟场。

这类场景其实很适合让 AI 先搭一个像样的壳子。

一、为什么调试面板适合 AI 先起版

因为这类工具通常：

• UI 结构重复
• 输入输出清楚
• 菜单和按钮样板多
• 最终一定会人工 review

也就是说，它很少考验核心业务创造力，更多是在堆“可操作入口”。

这种活 AI 通常挺能干。

二、最常见的低效写法：帮我写个 Debug 面板

这类提示词太泛了。

AI 很容易给你一个功能不少、但和项目根本不贴的模板。

比如：

• 菜单分组不对
• 功能入口太散
• 没有权限开关
• 运行时和编辑器模式混着写

最后你还是得大改。

三、更靠谱的提示词，是把你真正要暴露的调试动作讲清楚

1
2
3
4
5
6
7
8
9

你是资深 Unity 客户端工具工程师。
请帮我写一个运行时 Debug 面板，用于二合游戏开发环境调试。

要求：
1. 支持按钮：加金币、清空棋盘、完成当前订单、模拟断网、重置本地存档。
2. 支持输入框：输入活动 ID 并打开活动。
3. UI 用 uGUI，结构尽量简单。
4. 面板代码拆成：视图层、命令分发层。
5. 先给代码骨架，再说明如何继续扩展新命令。

这类提示词的关键，是你给的不是“做个工具”，而是“给这些调试动作做入口”。

四、一个适合 AI 先搭骨架的调试命令结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

using System;
using System.Collections.Generic;

public class DebugCommandRegistry
{
	private readonly Dictionary<string, Action> _commands = new Dictionary<string, Action>();

	public void Register(string key, Action action)
	{
		_commands[key] = action;
	}

	public bool Execute(string key)
	{
		if (!_commands.TryGetValue(key, out var action))
		{
			return false;
		}

		action?.Invoke();
		return true;
	}
}

这个结构很朴素。

但它比“所有按钮 onClick 都直接怼业务单例”要健康得多。

AI 很适合先帮你把这种基础骨架整理出来。

五、第二轮提示词，适合让 AI 帮你补工程边界

比如继续追问：

1
2
3
4
5

请继续扩展刚才的 Debug 面板方案。
1. 增加开发环境开关，避免正式包启用。
2. 增加命令分组：经济、棋盘、活动、网络。
3. 为每个命令保留日志输出。
4. 请只输出新增类和需要替换的方法。

这一步很有价值。

因为调试面板最容易从“方便”走向“混乱”。

而 AI 在帮你补分组、壳层、日志这类机械结构时，确实挺省时间。

六、最后一句

开发调试面板这种东西，大家都知道重要，但又经常懒得好好搭。

所以特别适合让 AI 先把 60 分版本迅速堆起来，再由你决定哪些命令该进、哪些边界该收、哪些功能不能乱放。

它最值钱的地方，不是设计调试体系。

而是把那些本来会拖很久的工具壳子，先搭出来。

Unity 项目里有一类活，程序通常都不太爱手写。

就是导表工具。

比如：

• 读 CSV
• 转配置类
• 做字段映射
• 生成代码或 JSON

这类活说复杂也不至于高深。

但特别容易又长又碎，还充满重复劳动。

所以它天生就很适合让 AI 先起一版。

一、为什么导表工具特别适合 AI 起草

因为它有几个典型特征：

• 结构明确
• 输入输出清楚
• 模板代码多
• 规则可以写死

比如你很清楚要做的是：

1. 读取某个 CSV。
2. 第一行是字段名。
3. 第二行是类型。
4. 生成对应的 C# 配置类。

这种任务对 AI 很友好。

因为你不是让它猜业务，而是在让它补“机械代码”。

二、但导表问题最怕的，不是代码写不出来，而是协议被偷偷写歪

这是重点。

AI 特别容易在这些地方“看上去合理，实际上不对”：

• 字段类型映射错了
• 空值规则默认错了
• 枚举解析策略和项目约定不一致
• 主键处理方式和现有配置管线不一致

所以导表工具适合让 AI 起草，但不适合闭眼接收。

三、一个更靠谱的提示词例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

你是资深 Unity 工具链工程师。
请帮我写一个 C# 工具，用于把 CSV 配置表转换为 Unity 项目里的配置类代码。

约定：
1. 第一行字段名。
2. 第二行字段类型，例如 int/string/float/bool。
3. 第三行开始是数据。
4. 第一列 id 作为主键。

输出要求：
1. 生成一个对应的 C# 配置类。
2. 每个字段保留原字段名。
3. 类型映射写成独立方法。
4. 如果遇到未知类型，要明确报错。
5. 先给完整代码，再解释风险点。

这类提示词最重要的点，就是把“你们项目的表协议”说清楚。

别让 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

using System;
using System.IO;
using System.Text;

public static class CsvConfigClassGenerator
{
	public static string GenerateClass(string className, string[] fieldNames, string[] fieldTypes)
	{
		if (fieldNames.Length != fieldTypes.Length)
		{
			throw new InvalidOperationException("Field name count does not match field type count.");
		}

		var builder = new StringBuilder();
		builder.AppendLine("[System.Serializable]");
		builder.AppendLine($"public class {className}");
		builder.AppendLine("{");

		for (int i = 0; i < fieldNames.Length; i++)
		{
			var csType = MapType(fieldTypes[i]);
			builder.AppendLine($"    public {csType} {fieldNames[i]};");
		}

		builder.AppendLine("}");
		return builder.ToString();
	}

	private static string MapType(string csvType)
	{
		switch (csvType)
		{
			case "int": return "int";
			case "float": return "float";
			case "string": return "string";
			case "bool": return "bool";
			default:
				throw new NotSupportedException($"Unsupported csv type: {csvType}");
		}
	}
}

这段代码不长。

但它正好展示了这类任务最适合 AI 的地方：先把重复样板铺起来，再由你把项目特定协议收紧。

五、第二轮提示词，最适合让 AI 帮你补“项目约束”

我通常会继续问：

1
2
3
4
5
6
7

请继续扩展刚才的导表代码。
补这些项目约束：
1. 支持数组字段，如 int[]。
2. 支持枚举字段。
3. 生成时校验字段名是否重复。
4. 输出错误时带上列名。
5. 只输出新增方法和需要替换的方法。

这样 AI 会更像在给你补协议实现，而不是重新发明一套新工具。

六、最后一句

CSV 导表这类活，真的很适合先交给 AI 起版。

因为它机械、重复、容易拖。

但你一定要守住一件事：

项目协议不能模糊。

不然 AI 写出来的不是工具，是另一套偷偷长歪的配置标准。

很多版本回归会有一种很熟悉的场面。

提测前，大家都觉得应该测的东西心里有数。

真到要列清单时，又开始现场回忆：

• 这个活动入口要不要测
• 上周那个修过的订单问题还要不要回归
• 新手引导会不会又被弹窗打断

这种方式当然也能做事。

但它特别依赖人脑在线，而且很容易漏。

所以我越来越觉得，AI 在这里最值钱的一种用法，不是直接替代测试，而是先帮你把“回归候选清单”快速摊出来。

一、为什么 AI 适合先帮忙列测试清单

因为很多回归项本质上是“基于已知变更做展开”。

比如这次改了：

• 订单系统
• 活动面板
• 奖励飞行动画

那合理的回归清单本来就应该往这些周边展开。

这件事不需要 AI 懂所有业务细节。

它只需要基于变更说明、模块边界和历史坑，先把一份 60 分版本的清单列出来。

这个起点已经很有用了。

二、最差的问法：帮我列测试点

这种问法会得到什么，你大概能猜到：

• 功能是否正常
• 界面是否正确
• 网络是否稳定
• 性能是否良好

都对。

但也都太空。

真正有用的测试清单，必须带上下文。

三、更好的提示词，是把“本次改动”讲清楚

比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

你是资深 Unity 游戏测试分析工程师。
请帮我基于本次改动生成一份二合游戏版本回归清单。

本次改动：
1. 改了订单提交流程。
2. 增加了活动面板入口。
3. 调整了奖励飞行动画对象池。
4. 修复了新手引导被弹窗打断的问题。

请按以下格式输出：
1. 核心必测项。
2. 关联回归项。
3. 高风险边界项。
4. 如果时间不够，最小回归集合是什么。

这类提示词的好处是，AI 输出的清单会更像“围绕改动展开”，而不是泛泛而谈测试常识。

四、AI 列清单最适合和结构化模板一起用

如果团队已经有固定模板，效果会更好。

比如你可以要求它输出：

• 模块
• 测试点
• 风险等级
• 触发条件
• 预期结果

这会比纯自然语言清单更容易落进实际测试流程。

甚至后面还能继续转成表格或测试 case。

五、一个简单的清单数据结构，也很适合让 AI 先起草

这类代码也不难，但很适合让 AI 先搭框架。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

using System;
using System.Collections.Generic;

[Serializable]
public class RegressionChecklistItem
{
		public string module;
		public string title;
		public string riskLevel;
		public string triggerCondition;
		public string expectedResult;
}

[Serializable]
public class RegressionChecklist
{
		public List<RegressionChecklistItem> items = new List<RegressionChecklistItem>();
}

这种结构非常朴素。

但它的意义在于，你后面不管是人工补、AI 继续生成，还是导出到别的系统，至少格式先立住了。

六、第二轮提示词，最适合让 AI 帮你补“边界项”

我很喜欢继续这样追问：

1
2
3
4
5

基于刚才生成的回归清单，请继续补这些内容：
1. 最容易遗漏的边界项。
2. 哪些测试点适合自动化冒烟。
3. 哪些测试点必须人工体验验证。
4. 哪些项和低端机/弱联网环境强相关。

这类追问很有价值。

因为真正让版本出事的，往往不是主路径没人测，而是边界情况被默认“应该没事”。

七、最后一句

AI 在测试清单这件事上的价值，不是把测试工作一键做完。

而是让团队别每次都从空白页开始回忆：这次到底该测什么。

尤其版本节奏快、改动多的时候，先有一份像样的候选清单，本身就能减少很多低级遗漏。

很多 Unity 项目里，资源规范一开始都写过。

比如：

• UI 图不要开 Read/Write
• Texture 格式按平台走
• 非必要别开 mipmap
• 命名要统一
• 大图别乱进公用图集

文档通常不缺。

真正缺的是，谁来持续检查。

因为这类活又碎、又重复、又容易让人烦。

而越是这种活，AI 越适合先帮你把工具骨架铺起来。

一、资源规范问题为什么总是反复出现

不是因为大家不懂。

更多时候是因为：

• 资源量大
• 人员流动
• 赶版本时容易手滑
• 靠人眼审核很难持续

最后的结果往往就是，规范存在于文档里，问题存在于项目里。

这时候最务实的办法，不是再开一次规范宣讲会。

而是把高频规则尽量工具化。

二、AI 在资源规范场景里最适合的角色：规则翻译器

也就是把你脑子里那一套规则，翻成能跑的检查逻辑。

比如你已经很清楚项目想要的规则是：

1. UI 目录下的贴图默认关闭 mipmap。
2. 图标类资源宽高不能超过某个上限。
3. 非透明贴图不要保留 alpha。
4. 命名必须符合某个前缀规范。

这种时候让 AI 去补检查器，命中率通常不低。

前提是你把规则说清楚。

三、一个更靠谱的提示词例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14

你是资深 Unity 资源工具链工程师。
请帮我写一个 Unity Editor 检查工具，用来扫描 UI 贴图资源是否符合导入规范。

项目规则：
1. 路径在 Assets/UI/ 下的 Texture2D 默认不能开启 mipmap。
2. UI 图默认不能开启 Read/Write。
3. 宽高超过 2048 的资源要报警。
4. 名字必须以 ui_ 开头。

要求：
1. 提供一个菜单入口。
2. 扫描结果输出到 Console。
3. 代码拆成扫描、规则判断、日志输出几个方法。
4. 先给代码，再说明如何扩展更多规则。

这种问法的关键是，你是在给 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

using UnityEditor;
using UnityEngine;

public static class UiTextureRuleScanner
{
	[MenuItem("Tools/Assets/Scan UI Texture Rules")]
	public static void Scan()
	{
		var guids = AssetDatabase.FindAssets("t:Texture2D", new[] { "Assets/UI" });

		foreach (var guid in guids)
		{
			var path = AssetDatabase.GUIDToAssetPath(guid);
			var importer = AssetImporter.GetAtPath(path) as TextureImporter;

			if (importer == null)
			{
				continue;
			}

			ValidateName(path);
			ValidateImporter(path, importer);
		}
	}

	private static void ValidateName(string path)
	{
		var fileName = System.IO.Path.GetFileNameWithoutExtension(path);
		if (!fileName.StartsWith("ui_"))
		{
			Debug.LogWarning($"[UI Rule] Invalid name: {path}");
		}
	}

	private static void ValidateImporter(string path, TextureImporter importer)
	{
		if (importer.mipmapEnabled)
		{
			Debug.LogWarning($"[UI Rule] Mipmap should be disabled: {path}");
		}

		if (importer.isReadable)
		{
			Debug.LogWarning($"[UI Rule] Read/Write should be disabled: {path}");
		}

		var texture = AssetDatabase.LoadAssetAtPath<Texture2D>(path);
		if (texture != null && (texture.width > 2048 || texture.height > 2048))
		{
			Debug.LogWarning($"[UI Rule] Texture too large: {path} ({texture.width}x{texture.height})");
		}
	}
}

这类工具不是什么黑科技。

但很容易从“大家都知道要检查”变成“没人真想手工查”。

所以让 AI 先把骨架搭出来，性价比很高。

五、第二轮提示词，适合让 AI 补“项目特有规则”

我会继续这样问：

1
2
3
4
5
6

请继续扩展刚才的 Unity 资源规范检查工具。
再补这些规则：
1. 某些目录必须使用指定平台压缩格式。
2. SpriteAtlas 依赖要额外报警。
3. 结果不要只打 Console，请输出一个可复制的汇总文本。
4. 只输出新增函数和需要替换的函数。

这种追问很有用。

因为项目里的资源规范，真正值钱的部分往往不是通用规则，而是你们团队自己的历史坑。

六、最后一句

资源规范最难的从来不是写出来，而是持续执行。

而这种重复、机械、容易拖延的检查工作，正好是 AI 很适合先帮你推一把的地方。

它当然不能代替最终判断。

但用来把规范翻成可执行检查器，已经很值了。