最近好几拨做Unity的朋友都在问同一件事怎么把自定义Skill接进TraeAI让AI写C#脚本的时候真正懂Unity的API、工程结构和团队的编码习惯。我也折腾了几个月从最开始AI瞎写被项目编译打脸到后来把SKILL.md整理得服服帖帖中间踩过的坑说多不多、说少不少。这篇文章我就以 unity-csharp 这个Skill为例把完整的接入步骤、目录规范、规则写法、调优方法一起讲透。适合谁看已经在用TraeAI写代码、但觉得它不够懂Unity的人想给AI设定一套本地规范的人以及准备在团队里推广AI编程规范的人。1. 先搞清楚Unity项目里的AI缺的到底是什么1.1 从“AI会写代码”到“AI懂项目”TraeAI直接拿通用能力去写Unity脚本和让一个完全没做过项目的新人直接上手是同一个效果。他能写出语法正确的C#但不知道你这个项目用的是URP还是Built-in管线不知道目标平台是Android、iOS还是微信小游戏更不知道团队里模型是走Addressables还是Resources文件夹。这些信息不补进去AI每写一段代码都像是在凭感觉答题。我见过最典型的场景让AI生成一个“点击地面角色移动”的脚本它给你用Camera.main每帧查找相机用transform.Translate直接移动物体完全不考虑角色有没有Rigidbody也不管是不是应该走CharacterController。代码能编译逻辑也像那么回事但放进正式项目里全是性能隐患和物理表现问题。所以接入Skill的核心目的不是“让AI多会几个API”而是把项目的隐性知识显性化。Unity版本、渲染管线、输入系统、UI框架、性能红线、打包约束这些一旦写进SkillAI每次生成代码都会自动带着这套规则去思考效果完全不一样。1.2 Skill 和普通提示词的区别很多人觉得Skill不就是一段“高级提示词”吗一开始我也这么想实际用下来发现差别挺大。普通提示词是一次性的。你在这条对话里说“请遵守Unity编码规范”AI记住了但下一条新对话它又忘干净了。Skill是持久化的上下文它放在项目目录里每次TraeAI在这个工作区启动新对话时都会自动加载相当于一个常驻的“岗位说明书”。更重要的是Skill是结构化的。它不是一段堆在聊天框里的话而是一个有名字、有描述、有正文、有参考文件的完整单元。你可以给不同场景分别建Skill比如unity-csharp负责常规脚本unity-performance负责性能评审unity-wxgame负责微信小游戏打包检查。AI会根据任务描述判断该调用哪个而不是靠你每次手动叮嘱。我常用一个类比普通提示词是“口头交代”Skill是“入职手册”。口头交代容易遗漏手册翻到哪一页都有章可循。1.3 我踩过的第一个坑通用AI的“正确废话”没接入Skill的时候AI给我最崩溃的反馈不是报错而是“正确废话”。比如我让AI查粒子特效内存泄漏的原因它能从GC Alloc、Mesh合并、Texture压缩讲到Draw Call每一条都正确但没有一条能帮我定位到自己项目里的问题。原因很简单它不知道我的粒子系统是放在预制体里频繁Instantiate的也不知道场景里有几十个特效同时播放。这种具体信息不在聊天上下文里AI就只能给通用结论。把Skill接上之后我把项目实际情况写进去粒子系统一律走对象池不直接Instantiate和Destroy特效结束后必须ParticleSystem.Clear()避免残留数据一直占内存个别高频特效要主动控制MaxParticles。再让AI分析问题它说的是“你这里每次点击都new一个特效预制体和Skill里的对象池规则冲突了要么改成池子复用要么把特效挂到固定节点下提前激活”。这才是有用的回答。2. 接入前的准备工作2.1 TraeAI 的 Skill 入口与版本差异先别急着写文件第一步是确认你的TraeAI版本支持项目级自定义Skill。我手上这个版本入口在对话输入框左侧的技能图标里点开后能看到已安装的Skill列表分为“全局技能”和“项目技能”两个分组。不同版本入口位置会有差别有的在符号弹层里有的在设置面板里但核心逻辑都是同一个识别项目目录下的Skill文件夹并加载。这里有个小常识Skill分“用户级”和“项目级”。用户级放在系统目录所有项目都能用项目级放在Unity工程根目录下只对当前工程生效。做Unity开发我强烈建议用项目级因为不同Unity项目的规则差异太大了。A项目是3D动作游戏B项目是数字孪生大屏规则写在一起只会互相干扰。如果你打开TraeAI后找不到技能入口先升级到较新版本再看。版本太老的话很多特性是缺失的。我当年就是旧版本折腾半天没入口升级后五分钟就解决了。2.2 项目目录规划尽量放在 .trae 下Unity项目接入Skill目录位置是第一个分水岭。我看到有人图省事直接把Skill建在Assets/TraeSkills/下面后果是Unity会把整个目录当成资源导入生成一堆.meta文件团队协作时Git冲突不断。我的建议是放在工作区根目录/.trae/skills/下这个目录不参与Unity的AssetDatabase导入干净又安全。一个典型的目录结构是这样的UnityProject/ ├── Assets/ │ ├── Scripts/ │ ├── Scenes/ │ └── Resources/ ├── Packages/ ├── ProjectSettings/ └── .trae/ └── skills/ └── unity-csharp/ ├── SKILL.md └── references/ ├── input-system.md ├── ui-ugui.md ├── performance.md └── build-wxgame.mdSKILL.md是技能主文件AI每次都会读它references目录放详细规则按需加载避免主文件太长。这样设计有两个好处主文件保持精简AI不容易被长文本干扰详细规则分类清晰不会在一个文件里堆积几百条互相冲突的约束。2.3 一份能跑的 SKILL.md 模板不管你的项目是手游、VR还是数字孪生SKILL.md的骨架是通用的。我用的最小可用模板长这样--- name: unity-csharp description: 用于Unity C#脚本生成、代码审查与工程规范增强。当用户要求编写或修改Unity脚本时自动生效。 --- # Unity C# Skill ## 项目基本情况 - Unity版本: 2022.3 LTS - 渲染管线: URP - 目标平台: Android / iOS / 微信小游戏 - UI框架: UGUI ## 编码规范 - 类名PascalCase私有字段_camelCase公共属性PascalCase - 不允许在Update中频繁使用Camera.main缓存引用 - 物理对象移动使用Rigidbody.velocity或CharacterController.Move ## 常用判断 - 获取物体速度优先读取Rigidbody.velocity而不是手动计算位移除以时间 - 暂停逻辑谨慎修改Time.timeScale对UI动画和协程都有影响模板不需要很复杂先把最关键的项目基本信息和几条铁律写清楚。后面随着项目迭代哪里被AI坑了就往里补一条。3. 手把手把 unity-csharp 接进 TraeAI3.1 第一步创建 Skill 目录和元信息先在Unity工程根目录创建skills目录名字用unity-csharp全小写加中划线别用中文和驼峰。命令行操作cd /path/to/UnityProject mkdir -p .trae/skills/unity-csharp/references然后在unity-csharp文件夹下新建SKILL.md最顶部写name和description两个字段。description尤其重要它决定了AI在什么情况下主动调用这个技能。我见过有人把description写成“Unity C#技能”结果该触发的时候不触发。正确的是把触发条件写清楚比如“当用户要求编写、修改或审查Unity C#脚本时使用”这样AI才能精准匹配。3.2 第二步用“决策规则”填充 SKILL.md填充规则时记住一句话给AI写“遇事怎么处理”而不是写“这样做不行”。我第一版Skill里全是“不要用XX”“禁止YYY”实测效果很差AI经常选择性忽略否定式指令。改成“遇到XX时应该用YYY原因是ZZZ”之后遵守率明显提升。举个例子。处理“Unity物体速度怎么获取”这个高频问题第一版我写的是“不要用Transform位置差除以deltaTime”AI照样生成那种代码。第二版我改成“获取物体速度时优先读取Rigidbody.velocity或CharacterController.velocity只有在纯逻辑对象上才考虑自算位移差因为物理插值会导致帧间抖动”AI就老实多了。所以SKILL.md里的每一条规则尽量都带上“场景-动作-理由”结构。理由不一定长但要让AI明白为什么选这条它才能在做权衡时做出正确判断。3.3 第三步让 TraeAI 加载并激活这个 Skill目录和文件都就位后重启TraeAI再点开对话输入框的技能图标。正常情况下刚才创建的unity-csharp会出现在“项目技能”分组里。如果列表里没有先检查TraeAI打开的工作区是不是这个Unity工程根目录很多人会不小心打开到上一级文件夹导致Skill识别不到。确认出现在列表后把开关打开。注意一点不是所有对话都会自动使用这个Skill。TraeAI根据description里的触发条件判断也可以手动在输入框里输入选择技能。如果想要强制生效就在新对话开头说一句“请使用unity-csharp技能来编写以下脚本”先把链路跑通。3.4 第四步用一个真实需求验证接入效果要验证Skill有没有真正生效别拿“写个移动脚本”这种太泛的需求试AI很容易蒙混过关。最好拿一个你之前翻过车的具体需求这样前后对比非常直观。我当时的测试需求是“给玩家角色写一个点击屏幕位置移动的脚本使用CharacterController目标平台为Android和微信小游戏。”接Skill之前AI给出的方案是transform.Translate加上Camera.main理由还振振有词。接入Skill之后AI先生成了CharacterController.Move的移动逻辑用SmoothDamp做减速重力也单独处理了还主动提示微信小游戏下要用UnityWebRequest处理资源加载。两者一比差距立竿见影。这里有个验证技巧每次改完Skill一定要开新对话测试。正在进行的对话通常用的是旧上下文你感觉“Skill没生效”其实只是改了文件但会话没有重新加载我因为这个误判过好几次。4. 让 Skill 真正“懂 Unity”的关键规则配置4.1 版本与 API 约定哪一年份的Unity就写哪一年的规矩Unity的API变更剧烈同一个写法在不同版本里可能是推荐、废弃、已移除三种完全不同的状态。Skill里如果不写版本约束AI的通用知识库会默认用较新的API放到老项目里直接编译失败。我踩过的具体例子是项目用的Unity 2020 LTSAI生成代码时套用了文件作用域命名空间C# 9编译报CS8958。后来我在Skill里明确写下“本工程C#版本为8.0禁止使用文件作用域命名空间命名空间必须显式包裹大括号”再也没出过同类问题。版本约定还涉及渲染管线和输入系统。Unity 6引入GPU Skins这种新特性老项目里根本不存在新项目还在用旧的Input.GetKeyDown也会被Skill里的规则纠正。所以开头那几行“项目基本情况”不是摆设每个版本相关的边界条件都要写清楚。4.2 高频需求速查规则速度、朝向、三角形按钮、热力图接入一段时间后你会发现团队里反复被问到的Unity知识点就那么多。把这些整理成速查规则AI的生成质量会稳定很多。我摘几条自己项目里常用的需求Skill中建议写入的规则获取物体速度物理对象用Rigidbody.velocity角色控制器用CharacterController.velocity不要用位置差分除以deltaTime物体朝向目标优先Quaternion.LookRotation使用Slerp做平滑插值注意相机空间下up向量要传世界up而不是本地up三角形/异形按钮UGUI的Image默认只有矩形点击区异形按钮设置alphaHitTestMinimumThreshold配合精灵图alpha通道判断点击热力图显示用Texture2D逐像素SetPixel生成颜色渐变避免在Update里反复setPixel改为缓冲区对象只更新脏区地图坐标GIS地图和数字孪生场景先统一坐标系经纬度转平面坐标用EPSG规则Unity单位与米的比例单独配置这些规则不是一次性想出来的是我从实际项目里一点点回填的。比如三角形按钮那个AI第一次给我建议PolygonCollider2D配UGUI方向完全错了。我在Skill里写清楚“UI层异形点击用Image的alphaHitTestMinimumThreshold不是3D碰撞器”后面再问相关需求AI直接就给正解。4.3 性能和包体规则让AI生成能“上线”的代码写Demo怎么都行做上线项目就不一样了。Skill里性能规则的作用是让AI在一开始就避开那些“能跑但跑不久”的写法。粒子特效内存泄漏是我处理过最多的问题类型规则原文供参考粒子系统建议配合对象池使用避免反复Instantiate和Destroy特效预制体特效播放结束时调用ParticleSystem.Clear()防止残留粒子数据占用内存控制MaxParticles上限超出上限时自动回收最旧粒子高频且长期存在的特效使用Loop Stop动作不要用Play后反复重启包体规则同样重要。Unity包体优化是一个系统工程AI能帮忙的更多是编码侧约束不要用Resources文件夹塞大量资源、纹理放在StreamingAssets走按需加载、Addressables替代直接AssetBundle打包、IL2CPP保留裁剪开关、微信小游戏首包关注4MB限制和分包策略。这些规则写进去之后AI写代码时会主动问一句“这个设置需要ScriptableObject序列化还是直接静态配置”因为它知道Resource目录不能乱用、Addressables是当前项目的资源管理方案。4.4 特殊场景地图、数字孪生、XR设备开发如果你的项目不只是一般的游戏Special场景的规则也要提前写。我做过数字孪生项目也在PICO 4上折腾过一阵体会很深。数字孪生领域AI最容易在坐标转换上翻车。GIS空间分析里常用经纬度Unity场景里用世界坐标两者不能直接画点。Skill规则就是所有GIS数据先做投影转换区域范围对应到Unity单位比例楼层高度统一米制避免直接用经纬度数值铺平面。PICO 4这类XR项目规则重点在输入和渲染上使用XR Interaction Toolkit管理手柄射线和抓取不要用旧版OVRInput直接耦合特定硬件头显设备的透视背景要开Passthrough而不是黑底每帧处理XR Origin位移要注意刚体同步。这些不是AI通识但写进Skill后它就不会给你生成“桌面端的鼠标操控方案”这种牛头不对马嘴的代码。5. 接入后我反复踩的坑与排查记录5.1 Skill 文件放好了却完全不生效这是发生率最高的问题一半以上都出在工作区路径不对。TraeAI里打开的是Unity工程目录而不是Assets目录。如果你把工作区定位到Assets/Scripts这种子目录项目技能根本扫描不到。排查顺序建议是先看技能列表里有没有unity-csharp。没有检查目录结构是否是工作区/.trae/skills/技能名/SKILL.md文件名大小写是否一致。特别注意Windows系统下目录路径末尾不要多空格。确认无误后重启TraeAI一次很多加载问题是启动时才扫描一次导致的。5.2 规则被“跳过”不是AI叛逆是写法不对技能列表里明明有AI也识别到了但生成结果还是不遵守。我复盘后发现大部分是规则写法问题。一个典型错误是写“不要使用WWW类加载资源”AI看到否定指令后会倾向找“正确”的替代方案但替代方案可能还是老API。更稳妥的写法是“加载远程资源使用UnityWebRequest旧版WWW已废弃继续使用会导致移动端兼容问题”。还有一个细节是SKILL.md的主体内容不要太长。AI不是逐字遵守所有规则它先提取关键规则再生成代码。如果规则堆到两百行优先级就不清晰了。我会把最重要的规则放在文件最开始次要规则放在references子文件里按需引用。5.3 Skill 写太长上下文被截断Skill本质上是消耗上下文窗口的。写得越长留给对话和代码的空间就越少。我有一次贪心把几十条性能规范全塞进SKILL.md结果AI开始丢三落四前面说生成URP兼容的shader后面就忘了。解决办法是拆分。SKILL.md只保留核心20至30条规则剩下的按主题拆到references目录。比如粒子特效规则放performance.md微信小游戏打包放build-wxgame.md每个reference文件都有明确标题SKILL.md里写一句“涉及粒子性能时查看references/performance.md”AI会按需读取。这也让每次对话的token消耗更可控。问题排查路径建议完全不生效工作区路径是否正确、文件大小写、重启从技能列表反向查加载结果规则被跳过是否用了否定式写法、规则是否堆叠过长改正向规则缩短主文件上下文截断SKILL.md是否超过150行拆references子文件按需引用编译报错API不存在版本约定缺失在Skill里写明Unity和C#版本边界5.4 生成代码与 Unity 编译器版本冲突最后一个高频问题是编译版本冲突。AI的通用训练数据覆盖了大量Unity版本它很容易默认用最新API。Skill里如果没有写死版本边界就会出现2020工程被塞进2023才有的接口、老项目被要求用URP专属Shader这类情况。我在Skill里明确写了四行Unity版本号、C#语言版本、可用的输入系统、渲染管线。这样即使AI内部记忆模糊也会参照文件里的硬约束。另外一个容易忽略的点TraeAI不是万能的它无法替代Unity编辑器里的编译过程。我每次让它写完整脚本都会复制到工程里实际编译一遍编译报错再喂回去让它改。等这套“生成-编译-反馈”的循环跑起来AI对Unity工程的理解会越来越准。6. 让 Skill 长期可用拆分、迭代和协作6.1 按模块拆 Skill按需加载接好一个Skill只是起点长期用下去一定会需要拆。项目变大后业务技能、性能规则、打包规范混在一起不光AI容易错乱维护也是灾难。我现在的做法是按生命周期拆unity-csharp管日常脚本unity-code-review管编码评审unity-build管打包前检查。每个Skill自带触发条件和参考文件AI根据任务主题自动选。这比“一个超级Skill包含所有规则”可靠得多也方便每个技能独立迭代。要注意的是Skill之间的描述必须清晰区分避免两个技能同时触发然后规则打架。6.2 用“踩坑回填法”持续迭代SkillSkill不是一个写完就能用一辈子的静态文件它是跟着项目一起生长的。我的习惯是每次被AI生成的代码坑一次就把这次的教训写进Skill。比如那次粒子特效反复实例化导致内存上涨回填了对象池规则那次在PICO 4上用了鼠标点击方案回填了XR输入专用规则。迭代节奏也重要。不要边写功能边改Skill容易把规则改乱。我一般每周抽一天统一整理把这一周AI踩过的坑、编译报错、性能问题翻一遍把新规则补充进SKILL.md或references。用Git管理Skill文件每次改动都能看到来龙去脉回滚也方便。6.3 团队要不要把 Skill 放进 Git强烈建议把.trae/skills放进Git仓库和Unity工程一起管理。这样新同事拉到代码后Skill自动就在不用每个人手动配置。放在.trae目录下还有个好处它不会被Unity当成资源导入不会生成.meta文件Git冲突少很多。需要提醒的是别把整个.trae目录一股脑提交。TraeAI自己可能会在.trae下生成其他缓存文件仓库里只要保留skills目录就好。.gitignore里写.trae/* !.trae/skills/团队协作时Skill规则很容易起争议比如“到底能不能用Camera.main”。我的做法是争议问题放到周会上讨论确认后写进Skill以文件为准。一旦理由写清楚团队成员执行起来反而比口头约定更统一。Skill本质上就是团队开发规范的自动化执行器它的价值也正在这里。个人在实际操作里的体感是别想着一次把Skill写到完美先花二十分钟把项目的基本信息和最容易被AI坑的三类问题写进去跑起来再说。后面每踩一个坑就回填一条规则过一个月回看这个文件你会惊讶它已经变成了项目里最值钱的文档之一。最后再分享一个细节更新Skill文件后尽量开新对话测试别在旧会话里反复试否则你很容易得出“Skill没生效”的错误结论这也是我调试得最多的地方。