企业官网建设流程全解析

很多人让AI写Unity代码，报错报得怀疑人生。其实问题多半不在AI笨，而在于喂给它的“默认知识库”里，全是被搜索引擎顶到前排的十年前老教程。那里面充斥着Resources.Load、Input.GetAxis、Text这些在新版本里早就该进博物馆的写法。最近在社区里看到一套开源方案，整理成31个技能项，专门用来纠正这类问题。花了一周时间接进自己的开发流，实测下来确实省心不少。这篇就把这套方案怎么用、解决哪些死穴、有哪些坑，一条条讲清楚。

1. 为什么AI写Unity代码总带“古董味”

1.1 Unity的版本断层比想象中更严重

Unity这些年经历了三轮比较大的API变革：第一轮是5.x时代引入物理和动画系统的重构；第二轮是2018到2020年，Input System、TextMeshPro、Addressables、ECS这波新框架轮番上线；第三轮是Unity 6以后，GameObject的管理方式、序列化方式又有了新的推荐姿势。

问题在于，Unity很少主动删除旧接口。Input.GetAxis现在还能跑，Resources.Load现在也还能工作，UnityEngine.UI.Text依旧存在。这种“旧代码永远能用”的设计，让AI训练语料里的老代码权重非常高——不是AI故意写错，而是它的训练数据里根本没有足够多的新API范例。

很多开发者的真实情况是：AI写出的代码能编译、能运行、功能也正常，但打包后的包体大了一圈，帧率掉个五分之一，改个需求要连带重构。这些都不是“立刻报错”的硬伤，而是“看起来没错，实际是坑”的软伤。

1.2 搜索引擎时代的信息污染

十年前的Unity博客如今依然霸占搜索首页。老博客里的写法在当时是最佳实践，现在却成了新人的绊脚石。AI编码助手训练时抓取了海量这类内容，自然把“老代码”当成了正确答案。

举几个真实场景：

• 让AI写个角色移动脚本，它给你用CharacterController.Move加老式键盘输入，而不是新版Input System的事件驱动写法。
• 让AI写敌人血条UI，它默认生成UnityEngine.UI.Text，完全不理会项目里装好的TextMeshPro。
• 让AI写资源加载逻辑，它给你Resources.Load，导致所有Bundle资源都被塞进首包。
• 让AI处理时序逻辑，它写一堆yield return new WaitForSeconds而不是UniTask或原生async/await。

这套开源方案的思路，就是在AI生成代码之前，把这31条“反古董规则”塞进AI的上下文里，让它明确知道当前项目应该使用哪套API、遵循哪套工程规范。

2. 31个技能项到底“管”了哪些事

这31个技能不是泛泛的“写更好的代码”prompt，而是把Unity开发中最容易踩坑的31个点，拆成了几条清晰的规则线。我按类型归类整理了一下，大致是这几个方向。

2.1 API版本映射类：让AI换掉旧接口

这一系列技能专注处理“同一个功能，新旧API的写法差异”。典型条目包括：

这里有个值得注意的细节：这组技能不只是告诉AI“用新的”，还提供了新API的最小可运行示例。因为AI模型本身知道新API，但缺乏具体项目的上下文时不会主动选择它。给它看一段示例代码，触发准确率会直线上升。

2.2 性能纪律类：治的是“能跑但很烂”

第二大类是性能约束。AI生成的代码往往功能正确，但性能不佳。这组技能专门禁止AI写出“每帧都分配内存”的写法。

典型规则：

• 组件引用必须在Awake或Start中缓存，禁止在Update里重复GetComponent。
• 每帧调用的函数内禁止new结构体、类或数组，避免产生GC Alloc。
• 大量生成和销毁的对象必须使用对象池，而不是直接在场景里Instantiate/Destroy。
• Camera.main每次调用都有内部查找开销，如果使用频率高，要手动缓存。
• LINQ在Update中要慎用，Where、OrderBy这类操作会瞬间产生大量临时内存。

// 错误示范：AI默认写法 void Update() { var rb = GetComponent<Rigidbody>(); var cam = Camera.main; rb.AddForce(cam.transform.forward * 10f); } // 正确写法：技能要求缓存 private Rigidbody rb; private Transform camTrans; void Awake() { rb = GetComponent<Rigidbody>(); camTrans = Camera.main.transform; } void Update() { rb.AddForce(camTrans.forward * 10f); }

这种规则的好处是直接改变了AI的“生成习惯”。你不需要每次手动审查代码，AI看到Update开头就会先判断是否有需要缓存的引用，从源头上把GC峰值降下来。

2.3 架构与工程结构类：不让代码变成屎山

第三大类是关于代码组织方式的。写过Unity项目的人都知道，脚本全堆在Assets根目录下、没有程序集定义、没有命名空间的项目，时间一长就是灾难。

技能中有一条强制要求：生成代码时必须带上命名空间，并按功能模块拆分目录；如果项目结构复杂，必须使用asmdef程序集定义来划分编译边界。

另外一个关键点，是关于事件通信的写法。AI默认倾向于使用UnityEvent或SendMessage来解耦，但SendMessage本身有严重性能开销，而且无法通过静态检查发现错误。技能会引导AI改用C#事件、委托或者信号库，明确函数调用关系。

比如：

// 错误示范：AI默认写法 SendMessage("OnDamage", 10); // 正确写法：技能要求事件订阅 public event Action<int> OnDamaged;

2.4 平台差异类：移动端、WebGL、小游戏全照顾

AI因为训练语料多来自PC环境，经常无视移动端的性能预算和WebGL的API限制。这组技能就是给AI加“平台意识”。

移动端上，规则要求避免大尺寸纹理实时处理，避免Graphics.Blit之外的像素级操作，要求用纹理压缩格式而非RAW RGBA。

WebGL上，规则会强制要求：不同类型的持久化存储不能直接用System.IO.File，因为浏览器环境根本没有文件系统；网络请求必须走UnityWebRequest，而非HttpWebRequest。

在小游戏平台则是更严格的限制：不能直接引用UnityEngine.Networking.PlayerConnection等仅编辑器可用的API，加载资源必须走平台热更新框架，不能直接向Resources目录写文件。

这套平台分类规则，极大减少了“能跑但一上真机就崩”的尴尬。

2.5 每个技能项的“配方”结构

每一条技能的格式基本是固定的，这也是这套开源方案最大的亮点。它不是单纯的“禁止XX”，而是一个完整的配方：

• 触发场景：AI在什么情况下应该参考这条规则。
• 禁止行为：明确写出AI不得使用哪些API或写法。
• 推荐行为：给出当前推荐做法，包括最小代码示例。
• 原因说明：为什么必须这样做，有什么性能和工程上的收益。

AI其实是靠上下文和模式匹配来生成代码的。给它一段“禁止XX，必须YY”的明确指令，比让它“理解”你的项目意图要靠谱得多。这也是为什么这套方案比你自己写prompt有效——它把规则结构化了，AI不需要去推断，直接照着配方执行就行。

3. 接入工作流：从规则文件到编码助手

3.1 规则文件放在项目哪个位置

我目前的工作方式是把这套规则包下载后，按编号拆成独立Markdown文件，放在项目根目录的Rules/文件夹下。主流AI编码助手都支持项目级规则目录，识别到之后每次生成代码都会自动读取。

目录结构类似这样：

UnityProject/ Assets/ Packages/ ProjectSettings/ Rules/ 01-InputSystem.md 02-TextMeshPro.md 03-Addressables.md 04-ObjectPool.md 05-Asmdef.md 06-UniTask.md ...

命名时我一定会在文件开头写下适用范围，比如# 涉及角色控制、视角移动、交互输入的脚本必须使用 Input System，这样AI解析时能快速定位到对应规则。

3.2 在提问层面做二次约束

部分编码助手对项目级规则的响应并不可靠，所以我在提问时会加一个固定的指令前缀。经过反复测试，三种说法的效果差别很大：

• “帮我写一个玩家移动脚本”——AI十次有八次用旧API。
• “用最新版本Unity API写玩家移动”——AI改用新Input System的概率提升到一半左右。
• “遵循项目Rules目录下的InputSystem规则和C#事件规则，写一个支持键盘、手柄、触屏三种输入的玩家移动脚本”——基本每次都能生成可用且规范的代码。

原因在于，AI对“最新版本”这个概念缺乏时间锚点，但“遵循Rules目录下的具体规则”是明确的文件系统指令，模型会真正去查阅。

3.3 真实对比：同一个需求，规则介入前后

我在测试项目中让AI写一个“拾取道具”功能。第一次用的是空白Prompt，AI生成了以下结构：

void Update() { if (Input.GetMouseButtonDown(0)) { Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition); RaycastHit hit; if (Physics.Raycast(ray, out hit)) { if (hit.collider.CompareTag("Item")) { Destroy(hit.collider.gameObject); GameManager.instance.AddScore(10); } } } }

代码能跑，但问题一堆：Input.GetMouseButtonDown在移动设备上不适用，Camera.main每帧查找，GameManager.instance用了单例但没做空判断，道具直接销毁而不是禁用入池。

加入31条规则后，AI生成的脚本变成：

public class ItemPicker : MonoBehaviour { [SerializeField] private LayerMask itemLayer; private Camera mainCam; private PlayerInputActions inputActions; private void Awake() { mainCam = Camera.main; inputActions = new PlayerInputActions(); } private void OnEnable() => inputActions.Enable(); private void OnDisable() => inputActions.Disable(); private void Update() { Vector2 pointerPos = inputActions.UI.Point.ReadValue<Vector2>(); Ray ray = mainCam.ScreenPointToRay(pointerPos); ... // 命中后调用对象池回收而非直接Destroy } }

虽然结构比之前重了一些，但移动端可用、接口清晰、内存回收安全。这样的差距，就是规则介入前后的效果差距。

3.4 怎么把它和Unity的官方包管理器结合起来

31个技能里有一部分是要求AI使用特定的包和工具链，比如UniTask、TextMeshPro、Input System。但AI生成代码时不会替你在manifest.json里加包依赖。

所以，我会先把项目基础设施准备好：在Unity Package Manager中安装Input System、TextMeshPro、Addressables，并在Player Settings里把Active Input Handling 切换为“Input System Package (New)”。规则里的命令才会生效。

如果没有提前设置，AI就算生成正确的新API代码，导入Unity后依然会报“输入管理类型冲突”或“命名空间未找到”的错。这一步是前置条件，千万别漏。

4. 调试与实测：哪些技能真有用，哪些是纸面功夫

4.1 长期使用后我发现的高频生效项

这31个技能在我实际用下来，生效频率真的存在偏差。优先级最高的几项：

高频生效：

• TextMeshPro替换：只要出现UnityEngine.UI.Text，AI基本100%会被纠正。
• Input System替换：Prompt中如果说明需要支持触屏/手柄，AI就会使用新输入系统。
• Update内禁止GetComponent：只要规则里写明“缓存组件引用”，AI几乎不会越线。

中频生效：

• Addressables替换Resources：如果明确提到“性能优化”或“热更新”，AI会正确使用Addressables，否则偶尔会跳回Resources。
• UniTask替换协程：需要专门的规则条目提醒，否则AI还是会写StartCoroutine。

低频生效：

• 复杂架构约束（如模块边界划分、按接口编程）：AI在较长代码生成任务中经常会“忘记”这些规则，需要分步骤、分Prompt让它输出类结构。

4.2 常见问题速查表

4.3 规则冲突怎么处理

当项目本身比较复杂，31条规则里偶尔会出现两条同时触发的情况。比如：既要求“使用Addressables异步加载”，又要求“不要在Update中异步等待”。AI在处理类似冲突时大概率会直接卡住或输出冗余的try-catch。

我的处理办法是给规则标注优先级。在文件头部加入一行> Priority: 10（数值越大优先级越高），同时确保类规则在规则文件的前半部分出现。AI在解析时会对高优先级规则投入更高注意力权重，冲突率会明显下降。

4.4 这个方案没法解决什么

必须承认，31个技能不是银弹。它侧重纠正“API使用”和“基础性能习惯”，但无法解决三个长期问题：

第一，AI对大型架构设计依然缺乏建模能力，让它生成一个跨多个类的完整模块时，代码依赖关系经常是混乱的。

第二，AI无法读懂美术资源、动画状态机和配置数据，涉及到与Prefab、Animator Controller联动时，只能生成配套组件代码，具体数据还是要自己在编辑器里拖拽绑定。

第三，代码可读性上有个副作用：过度遵循规则会让代码风格趋于稳妥，但不会留下精妙的算法设计。遇到优化瓶颈，AI能给出常规方案，但剑走偏锋的优化策略还是得人来。

5. 拿来即用：怎么把31个技能改造成自己的项目专属版

这套开源方案最大价值不只在31个技能本身，更在于它的“包装方式”。我把它落地到自己项目时，做了一次彻底的二次改造。

5.1 删：去掉不匹配业务场景的规则

我的项目是做手机端的休闲游戏，平台差异相关的WebGL和物理渲染规则基本用不上，直接删掉或注释掉，避免增加上下文长度干扰AI判断。

5.2 改：把示例代码改成项目内部的API风格

比如规则里提供的是PlayerInputActions示例，我改成了自己封装的InputDelegate静态类，并更新了全部示例代码。这样AI生成出来的东西，直接符合项目的内部规范，不用二次重构。

改写规则的时候一定注意保留“为什么”部分。AI其实理解具体规则的原因描述并不好，但包含原因说明的规则文本，在检索时的相关性匹配会更强。

5.3 增：把我自己的踩坑经验补进去

我加了几条不在31项里的规则，比如：

• 不要在FixedUpdate中做插值运算，除非处理物理帧相关逻辑。
• 在移动端禁止使用OnGUI绘制调试工具。
• 所有对外公开的API必须加XML文档注释，方便AI在后续生成调用代码时能准确理解参数含义。

这类规则来自日常踩坑的经验积累，可以说是这个方案带给我最大的启发——它提供了一个规则框架，剩下的内容完全可以按项目特性无限延展。

5.4 迭代节奏：别一上来就全量启用

刚接入时我全量启用了31条规则，结果AI的响应速度明显变慢，生成的代码“小心翼翼”得有点过头。后来改成按开发阶段分组：原型阶段只用API映射类规则，性能调优阶段再启用性能纪律类规则，做平台适配时把平台差异类规则加进来。这样效果最均衡。

写在后面

AI写Unity代码这件事，大部分人卡在“让AI不报错”这层，但代码的“健康度”才是真正决定后续项目维护体验的分水岭。这套31技能的开源方案，本质上是给AI铺了一层“当前版本的常识底子”。我自己用下来的最大体会是：规则不在于多，而在于准确、具体、可判断。与其指望AI自动跟上Unity的版本步伐，不如用规则主动告诉它答案。这比反复修改Prompt靠谱得多。如果你也在被AI的“过时代码”折磨，建议找一套类似的规则集跑一跑，再按自己项目的脾性改成一版专属的，效果一定比现在好。