开发调试面板别总是手糊按钮了，AI 很适合先帮你把壳子搭起来

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 分版本迅速堆起来，再由你决定哪些命令该进、哪些边界该收、哪些功能不能乱放。

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

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