老 Unity 模块最怕没人敢动，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 模块上的最佳用法，通常不是替你拍板重构方案。

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

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

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

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