Unity Claude Code AI 游戏开发实战MCP、潜行机制与 AI 智能代理工作流如果你写过潜行类游戏哪怕只是一个 Demo一定遇到过这种时刻敌人 AI 需要视野检测、巡逻点巡回、发现玩家后立刻追击、丢失目标后再回去搜索。逻辑不复杂但代码量不小而且绝大多数都是“胶水逻辑”——写起来麻烦改起来更麻烦。过去我在 Unity 里做这类系统流程基本是写脚本、等编译、跑场景、调参数、再编译。一个功能下来半天时间就没了。真正耗时间的不是“逻辑有多难”而是“从想法到可运行结果”的反馈周期太长。Claude Code 这一类的 AI 编程代理工具配合 MCP 协议正在把这段周期明显压缩。你可以在终端里把任务拆给 AI 代理让它先读现有脚本了解风格再按需求生成 C# 代码接着做编译检查最后通过 git diff 审查改动。整个过程里开发者负责定义边界和做决策AI 负责大量重复代码的生成与修改。这篇文章不会只说新工具多好用而是结合一个典型的 Unity 潜行游戏场景完整走通“Unity 工程接入 MCP - AI 生成潜行视野检测脚本 - 实现敌人状态机 - 用 git 与 Unity 批量编译验证成果”的全流程。读完你会得到一个可以直接照做的 AI 游戏开发工作流也能搞清楚哪些环节一定要人来把控。1. Unity 开发者为什么要关注 Claude Code 与 MCP先说一个容易被忽略的判断Claude Code 这类工具带来的不是“自动写代码”而是项目理解能力的突飞猛进。以前大家用 AI 写 Unity 脚本无非是把一段需求描述贴到对话框里再把生成的代码复制进 Visual Studio然后自己手动解决命名冲突和编译错误。对于单脚本、单功能的小任务这种方式确实能省点时间。可一旦遇到跨文件、依赖现有系统的需求对话式 AI 就抓瞎了原因很简单它看不到你的项目结构也不了解你团队里已经写好的工具类。Claude Code 的最大差异在于它运行在终端里天然能访问文件系统和命令行。你可以让它直接查看 Assets/Scripts 目录下的文件列表搜索某个类的使用位置读取指定脚本的完整内容甚至让它执行命令来获取编译日志。这种能力不是“AI 聊天助手”而是“AI 编程代理”。用代理这个词意味着它具备一个闭环理解任务、读取相关代码、生成修改、运行验证、汇报结果而人类在关键节点把关。MCP 又解决了另一个问题AI 工具怎么和外部系统接通。MCP 是一套标准化协议可以让 Claude Code 获得一套可动态调用的工具集合。放到 Unity 场景里就是可以做一个中间层服务向 AI 暴露“列出 C# 脚本”“读取文件内容”“搜索符号”“执行 Unity 批量编译并返回日志”等工具。有了这套工具AI 相当于真正“读”到了 Unity 工程而不是靠你把代码复制进对话里。所以Unity 开发者真正值得关注的不是某个具体 AI 产品而是“AI 智能代理工作流”这个工程实践。我自己更愿意把它理解成让 AI 承担阅读、检索和重复编码的部分而人类负责定义任务边界、审查代码和验证最终游戏体验。1.1 哪些项目收益最大收益最明显的项目有三个特征规则清晰、逻辑重复、代码量较大。比如任务系统、背包系统、NPC 行为状态机、潜行检测、对话剧情、UI 交互逻辑等。这些系统本身不难但字段多、分支多、样板代码多完全符合 AI 代理擅长处理的任务画像。第二类收益大的项目是团队规范已经建立的项目。目录结构稳定、命名风格统一、代码审查套路明确AI 生成结果的可预测性就会高很多。反过来说如果项目本身没有 git、没有目录规范、代码风格混乱那 AI 生成的代码只会加剧混乱。不建议先用的场景也有几个渲染优化、Shader 调试、性能分析与引擎底层扩展。这些任务需要大量的实测数据、Profiler 观察和经验判断AI 代理只能做辅助很难直接交付出可用的结果。另外如果需求本身还没想清楚也不要急着让 AI 写代码否则它会把你的“模糊”用一种看起来很有道理的方式固化下来后面改起来更痛苦。2. 基础概念Claude Code、MCP 与 AI 智能代理工作流先把几个名词放在一起说清楚因为它们经常被混在一起讨论但实际上解决的是不同层面的问题。Claude Code 是一款命令行 AI 编程工具核心特点是能在终端里以代理模式工作可以自动读取项目文件、修改代码、执行命令。对于开发者来说它更像一个能干活的同事而不是一个只会聊天的窗口。MCP 是“模型上下文协议”的缩写。它的目标不是取代现有 API而是定义一套标准方式让模型应用可以通过“工具”获取外部数据、触发外部动作。举个例子没有 MCP 的时候消息对话界面就是一个文本框AI 只能用你贴进来的内容去理解项目有了 MCPAI 可以调用本地函数去搜索关键字、读取文件、运行命令。MCP 的工具调用流程有点像一个插件市场每个服务器可以注册若干工具当前主程序按需加载。AI 智能代理工作流则是一个更大范围的概念它描述的不是某个工具而是从任务下发到最终提交的完整协作方式。典型闭环包括读取项目上下文、拆解任务、生成或修改代码、执行编译或测试、汇报差异、人工审查、提交或回滚。这个闭环能够成立依赖的不仅是模型能力还包括工程规范、版本控制、权限边界和审查机制。概念关注的问题在 Unity 场景中的位置Claude CodeAI 如何以代理方式操作项目作为编码执行的“代理入口”MCPAI 如何标准化连接外部工具作为 Unity 工程工具链的“连接协议”AI 智能代理工作流如何闭环管理 AI 的代码变更作为流程规范用 git 和编译验证控制结果特别要提醒一个容易混淆的点MCP 并不等于“云服务”也不一定需要部署在远程服务器。在 Unity 开发场景里最常见的接入方式是本地进程通信AI 工具通过标准输入输出和 MCP 服务器对话。所以它不会把你的 Unity 工程上传到什么云平台核心数据仍然保留在本地工程目录里。当然使用 Claude Code 时仍然要注意项目内是否有敏感配置、密钥或第三方账号 token这类内容无论如何都不应该出现在代码库里。3. 环境准备与最小配置在开始之前你需要准备的东西并不多。操作系统不限Windows、macOS、Linux 都可以但具体安装命令和路径会有一点差异下面给出的是通用思路细节以官方文档为准。你至少需要具备以下基础条件Unity 编辑器支持 C# 脚本开发。本文不绑定具体 Unity 版本演示代码使用的都是基础 API。Node.js 环境因为 Claude Code 通常通过 npm 安装。一个终端工具Windows 上可以用 PowerShellmacOS 上可以用 Terminal。一个带 git 的 Unity 工程。没有 git 的话建议先初始化版本管理再考虑引入 AI 代理。Claude Code 的安装方式一般是通过 npm 全局安装安装命令大致如下npm install -g anthropic-ai/claude-code安装完成后在项目目录下直接执行启动命令claude如果首次启动会要求登录授权或配置模型按终端里的指引操作即可。这里有一个容易出现分歧的点网上很多教程会建议使用第三方工具切换后端模型比如接入 Qwen、GLM 等模型但从工程稳定性来说非官方适配链路可能会遇到工具调用格式不匹配、上下文遵守度下降等问题。原型阶段可以尝试正式项目建议先以官方支持模型为主。接下来建议先创建一个最小工程来验证闭环而不是直接把 AI 挂到已经做了很久的大项目里。最小工程可以非常简单新建一个 Unity 3D 场景放一个 Plane 作为地面再放一个 Capsule 代表玩家一个 Cube 代表敌人保持默认材质即可。我们要验证的是 AI 能不能在这个工程里创建脚本、读取脚本、按指令修改脚本以及最终生成代码能否被 Unity 正常编译。为了让 AI 第一次就能遵循你的工程规范建议在项目根目录下创建一个说明文件很多工具会把这一类文件作为项目上下文优先加载。文件名一般叫 CLAUDE.md具体名称以你使用的工具文档为准。下面是一个适合 Unity 小项目的最小示例# StealthDemo 项目说明 当前项目是一个 Unity 潜行游戏 Demo包含玩家移动与敌人 AI。 ## 目录与命名 - C# 脚本统一放在 Assets/Scripts 下 - 类名使用 PascalCase私有字段使用 camelCase - 公共字段在 Inspector 中配置不硬编码数值 ## AI 任务边界 - 只能修改 Assets/Scripts 目录 - 禁止修改 Packages 目录和 ProjectSettings 目录 - 禁止删除现有脚本除非任务中明确说明 ## 完成标准 - 每次改动后必须输出 git diff --stat 摘要 - 新增脚本后给出简单的使用说明和测试方式这个文件的价值是把“行为规范”提前立好。没有它AI 默认会按照自己的理解去改文件结果往往是多改了你不想动的配置或者生成的代码风格和项目完全脱节。4. Unity 侧接入 MCP把游戏工程暴露给 AI 代理要让 Claude Code 实际“看见” Unity 工程最常见的方式是配置一个本地 MCP 服务器。MCP 服务器本质上是一个本地进程Claude Code 通过协议调用它注册的工具。在 Unity 开发场景中建议暴露的工具至少包括列出 C# 脚本、读取文件内容、搜索符号、执行 Unity 批量编译并返回日志、读取 git diff 摘要。这几个工具已经能把“读懂项目、修改代码、验证编译、汇报改动”的闭环覆盖到。下面是一个典型的本地 MCP 配置示例使用 stdio 方式启动注意里面的路径要替换成你自己的实际路径{ mcpServers: { unity-stealth: { command: python, args: [D:/tools/mcp_unity_server.py], cwd: D:/UnityProjects/StealthDemo, env: { UNITY_PROJECT_ROOT: D:/UnityProjects/StealthDemo, UNITY_EDITOR_PATH: C:/Program Files/Unity/Hub/Editor/2022.3.20f1/Editor/Unity.exe } } } }配置里的command和args决定了 Claude Code 如何启动这个本地服务。你不需要自己从零实现一整套 MCP 协议可以搜索社区里现成的 Unity MCP 服务器实现或者干脆只写一个能满足你项目的轻量脚本。下面是一个工具暴露思路的示意代码用来帮助你理解“MCP 工具”到底暴露了什么# mcp_unity_server.py 设计思路 # 这里只展示工具函数的核心逻辑并非完整可运行代码 from pathlib import Path def list_cs_scripts(project_root: str): 列出项目内所有 .cs 脚本排除 Library 目录 root Path(project_root) scripts [str(p) for p in root.rglob(*.cs) if Library not in str(p)] return scripts def search_symbol(project_root: str, keyword: str): 在指定目录搜索包含关键字的脚本行 root Path(project_root) results [] for p in root.rglob(*.cs): if Library in str(p): continue try: lines p.read_text(encodingutf-8).splitlines() except UnicodeDecodeError: continue for i, line in enumerate(lines, start1): if keyword in line: results.append(f{p}:{i}:{line.strip()}) return results这里要特别强调权限边界的问题。很多 MCP 配置示例为了省事会给 AI 暴露一个通用的 shell 执行工具这样 AI 确实“什么都能做”但它也就拥有了你本地账户的全部权限。一旦提示词写得不清不楚或者模型误判了命令的副作用后果可能是在错误目录里执行了删除或覆盖操作。更稳妥的做法是只暴露白名单工具文件读取、受限的脚本写入、git diff 查看、Unity 批量编译。坚决不提供无限制的终端命令通道。如果你把 MCP 服务器看成“给 AI 的门禁系统”那原则就一句话它能访问的数据越少误操作的影响面就越小。让 AI 在 Assets/Scripts 下工作就不要给它整个磁盘的读写权限。5. 实战一用 AI 智能代理实现潜行机制的核心视野检测下面进入具体游戏开发实战。潜行机制最基础、也最核心的部分是敌人视野检测敌人有一个扇形视野区域只有当玩家处于这个区域内、并且没有被墙体等障碍物遮挡时才能算被发现。代码量不大但涉及多个判断条件很多新手会在“角度判断”和“遮挡判断”的顺序上出错。先拆解一下需求检测半径敌人能看到多远的玩家。检测角度敌人视野张角比如 90 度表示正前方左右各 45 度。目标层级玩家所在的 Layer用来过滤检测对象。遮挡层级墙体、掩体所在的 Layer用于做射线遮挡判断。调试可视化在 Scene 视图里画出视野范围和朝向线方便调整参数。下面是一份可以直接放进 Unity 工程使用的完整脚本文件路径是Assets/Scripts/AI/EnemyVisionController.csusing UnityEngine; public class EnemyVisionController : MonoBehaviour { [Header(视野参数)] public float viewRadius 8f; [Range(0, 360)] public float viewAngle 90f; public LayerMask targetMask; public LayerMask obstacleMask; void Start() { // 没有强制要求必须在 Start 里获取玩家 // 方便后续把 DetectionTarget 设计得更通用 } public bool CanSeePlayer() { Transform nearestTarget FindNearestVisibleTarget(); return nearestTarget ! null; } private Transform FindNearestVisibleTarget() { Collider[] targets Physics.OverlapSphere(transform.position, viewRadius, targetMask); if (targets.Length 0) { return null; } Transform nearest null; float nearestDistance float.MaxValue; foreach (Collider col in targets) { Transform candidate col.transform; Vector3 dirToTarget (candidate.position - transform.position).normalized; float distance Vector3.Distance(transform.position, candidate.position); if (distance viewRadius) { continue; } // 角度判断视野角度的正中是 transform.forward float angle Vector3.Angle(transform.forward, dirToTarget); if (angle viewAngle * 0.5f) { continue; } // 遮挡判断如果射线碰到障碍物说明玩家被掩体挡住 if (Physics.Raycast(transform.position, dirToTarget, out RaycastHit hit, distance, obstacleMask)) { if (hit.collider.transform ! candidate) { continue; } } if (distance nearestDistance) { nearestDistance distance; nearest candidate; } } return nearest; } void OnDrawGizmosSelected() { Gizmos.color Color.yellow; Gizmos.DrawWireSphere(transform.position, viewRadius); Vector3 forward transform.forward * viewRadius; Vector3 leftBoundary Quaternion.Euler(0, -viewAngle * 0.5f, 0) * forward; Vector3 rightBoundary Quaternion.Euler(0, viewAngle * 0.5f, 0) * forward; Gizmos.DrawLine(transform.position, transform.position leftBoundary); Gizmos.DrawLine(transform.position, transform.position rightBoundary); Gizmos.DrawLine(transform.position, transform.position forward); } }这段代码的关键逻辑有三个。第一用Physics.OverlapSphere先做球形范围查询而不是直接对每个玩家发射射线。这样可以先在物理层面过滤掉距离过远的目标省去无意义的 Raycast。第二用Vector3.Angle计算敌人正前方与目标方向之间的夹角再和viewAngle * 0.5f比较。这里容易踩坑的点是忘记除以 2导致实际视野张角是配置值的两倍。第三Raycast 的判断目标是障碍物层级。只要敌人与玩家之间存在障碍物就认为玩家处于隐蔽状态。如果想让多个障碍物共同判断可以改用Physics.RaycastAll并遍历所有碰撞点。把这份需求交给 AI 代理提示词可以这样写请阅读 Assets/Scripts/AI 目录下已有脚本保持现有命名风格。 新增 EnemyVisionController.cs实现以下功能 1. 敌人视野检测扇形角度、半径、目标层和遮挡层可配置 2. 玩家进入扇形且未被遮挡时CanSeePlayer 返回 true 3. 在 Scene 视图显示视野范围 Gizmos 4. 不要改动其他文件完成后给出 git diff 摘要。这里的关键是“保持现有风格”和“给出 git diff 摘要”这两条约束。AI 生成代码时如果你不要求它先读既有代码它大概率会生成一套全新风格的写法后续维护会很别扭。而要求输出 diff 摘要是为了逼它把改动范围摊开给你看。6. 实战二敌人行为系统——状态机还是行为树敌人行为系统是另一个很适合 AI 代理处理的场景。市面上有两种常见方案状态机与行为树。我的建议是小项目、原型阶段优先使用原生 C# 状态机不要一上来就引入行为树框架。原因很简单状态机的控制流直观所有状态变化都写在一个文件里容易审查也容易修改。行为树的优势在于节点化、可视化和策划可调整性但如果团队里没有专门的 AI 程序员或技术策划学习与维护成本会压过收益。等状态机的分支数量增加到难以维护时再迁移到行为树也不迟。下面是一个敌人状态机脚本完整覆盖“巡逻 - 追击 - 搜索 - 回到巡逻”这条经典循环文件路径是Assets/Scripts/AI/EnemyStateMachine.csusing UnityEngine; public enum EnemyBehaviorState { Patrol, Investigate, Chase } public class EnemyStateMachine : MonoBehaviour { public EnemyBehaviorState currentState EnemyBehaviorState.Patrol; public Transform[] patrolPoints; public float patrolSpeed 2f; public float chaseSpeed 4f; public float investigateSpeed 3f; private EnemyVisionController vision; private Transform player; private int patrolIndex 0; private Vector3 lastKnownPosition; void Start() { vision GetComponentEnemyVisionController(); GameObject playerObject GameObject.FindGameObjectWithTag(Player); if (playerObject ! null) { player playerObject.transform; } } void Update() { if (vision ! null vision.CanSeePlayer() player ! null) { lastKnownPosition player.position; currentState EnemyBehaviorState.Chase; } switch (currentState) { case EnemyBehaviorState.Patrol: UpdatePatrol(); break; case EnemyBehaviorState.Investigate: UpdateInvestigate(); break; case EnemyBehaviorState.Chase: UpdateChase(); break; } } void UpdatePatrol() { if (patrolPoints null || patrolPoints.Length 0) { return; } Transform targetPoint patrolPoints[patrolIndex]; if (targetPoint null) { return; } transform.position Vector3.MoveTowards( transform.position, targetPoint.position, patrolSpeed * Time.deltaTime ); if (Vector3.Distance(transform.position, targetPoint.position) 0.3f) { patrolIndex (patrolIndex 1) % patrolPoints.Length; } } void UpdateChase() { if (player null) { return; } transform.position Vector3.MoveTowards( transform.position, player.position, chaseSpeed * Time.deltaTime ); transform.LookAt( new Vector3(player.position.x, transform.position.y, player.position.z) ); // 追击过程中丢失视野进入搜索状态 if (vision ! null !vision.CanSeePlayer()) { currentState EnemyBehaviorState.Investigate; } } void UpdateInvestigate() { // 到达最后看到玩家的位置后恢复巡逻 if (Vector3.Distance(transform.position, lastKnownPosition) 0.5f) { currentState EnemyBehaviorState.Patrol; return; } transform.position Vector3.MoveTowards( transform.position, lastKnownPosition, investigateSpeed * Time.deltaTime ); } }这套状态机里的一个关键设计是“丢失视野后不直接回到巡逻而是先去最后一次看到玩家的位置搜索”。这个细节能明显提升潜行游戏的真实感。玩家被敌人发现后如果只是躲到转角敌人不会立刻放弃而是会跑到你最后出现的位置附近找一圈游戏张力会大很多。如果把这段逻辑交给 AI 编写提示词里应该明确说明状态之间的转换条件。没有这些条件AI 生成的状态机最多只是“看到玩家就追看不到就发呆”游戏体验会非常机械。这里还要给一个工程层面的建议AI 生成的代码第一次很可能不会完全符合你的手感预期。你需要把“参数不调好”当成常态处理。比如patrolSpeed、chaseSpeed、viewAngle这些变量做成 Inspector 可调字段不要硬编码。AI 可能不会主动把每个数值都提成公共字段你在提示词中要显式要求“可配置参数使用公共字段”。7. 把 AI 智能代理工作流固化到团队协作里到这里我们已经有了能够工作的潜行检测脚本和敌人状态机但真正让 AI 智能代理发挥价值的是协作流程。很多团队尝试 AI 编程之后发现效果不稳定不是因为模型不够强而是因为没有把“规范、审查、回滚”这套工程机制前置。7.1 全局说明文件是团队的 AI 准入规范在上一节我们创建了 CLAUDE.md它应该成为团队与 AI 协作的唯一可信入口。当新同事或新的 AI 工具接入项目时先读这份文件再开始干活。文件里不要写虚的废话只写“能做什么、不能做什么、完成标准是什么”。如果项目越来越大可以按目录拆分成多个说明文件但根目录必须有一份总纲。7.2 每次改动都要先看 git diffClaude Code 有能力修改多个文件但“有能力”不代表“每次都正确”。AI 生成代码后第一步不是进 Unity 运行而是先看它改了什么。下面的命令可以帮助你快速评估改动范围git diff --stat git diff Assets/Scripts/AI/如果 AI 改的文件数量和你的预期不符优先怀疑任务边界没有描述清楚。比如你只让它新增一个脚本但它顺手改动了你的 PlayerController这时候不要急着接受改动先要求它解释原因或者直接回滚无关文件。# 确认该文件的改动确实不需要保留后再执行回滚 git checkout -- Assets/Scripts/AI/EnemyStateMachine.cs回滚操作是不可恢复的所以只应该用在“确认改动完全错误”的情况下。如果只是部分不满意更推荐进入 Unity 手动微调而不是整体回滚重来。7.3 让编译验证成为闭环的第三环节AI 写出 C# 脚本后最怕的问题是“看起来合理但编译不过”。几乎每个 Unity 开发者都遇到过引用错误、命名空间冲突、缺少 using 语句、方法签名不一致等。这些问题如果交给 AI 自己发现效率反而更高。你可以通过 Unity 的 batch mode 在命令行里执行编译验证把日志喂回给 Claude Code 做二次修正。Windows 下的命令大致如下# 路径按你本机实际的 Unity 安装目录替换 $unity C:/Program Files/Unity/Hub/Editor/2022.3.20f1/Editor/Unity.exe $unity -batchmode -quit -projectPath D:/UnityProjects/StealthDemo -logFile build.log如果编译失败build.log 里会包含详细的错误信息。这时候把日志内容和上下文一起发给 Claude Code让它基于错误提示修改。这套“生成 - 编译 - 根据错误修正”的循环才是 AI 智能代理工作流中最有价值的部分。它让 AI 不只停留在文本生成层而是能真正接近一个开发者的工作方式。8. 常见问题与排查思路在实际使用时你会遇到一些重复出现的问题。下面按“现象 - 可能原因 - 排查方式 - 解决方案”整理成一张排查表方便收藏后逐步对照。问题现象可能原因排查方式解决方案Claude Code 找不到 MCP 服务器配置文件的路径或命令拼写错误检查 mcpServers 配置里的 command 与 args 是否为有效路径修正路径后重启 Claude CodeMCP 服务器已启动但工具调用超时工具内部执行了耗时过长的命令单独运行 MCP 脚本确认函数能否正常返回给工具调用增加超时控制必要时简化搜索范围Unity 编译报错AI 生成的代码逻辑却没问题缺少 using 语句或引用类型不一致查看 build.log 中的错误行号让 AI 读取错误日志并修正不要盲目重写AI 生成了多个无关文件任务边界不清晰CLAUDE.md 约束没生效查看 git diff --stat 的文件列表细化 CLAUDE.md增加“禁止新增目录”等强约束MCP 暴露了无限制 shell 命令配置时使用了过于宽泛的工具接口审查已注册工具列表只保留白名单工具删除无关的全权限 shellAI 修改了 Packages 或 ProjectSettings根目录缺少正确的权限说明查看 git status 确认改动路径在 CLAUDE.md 中明确禁止修改这些目录第三方模型接入后工具调用不稳定模型对工具调用格式的理解不一致对比官方模型的行为日志关键任务使用官方支持模型第三方方案只能轻量验证这里想多说一句关于第三方模型接入的问题。社区里经常讨论把 Claude Code 接到 Qwen、GLM 等模型上也确实有一些辅助工具在做这件事。但需要清楚的是这类适配绕过了官方链路可能出现工具调用格式不匹配、上下文截断、突发不可用等问题。原型阶段用来体验没有问题正式项目建议把“验证工具链路稳定”和“使用正式模型”分开避免在调试 AI 工具上消耗掉本来想省下来的时间。9. 最佳实践与工程建议如果你决定在 Unity 项目里正式启用 Claude Code 与 MCP下面几条建议值得在团队内部固定成规范。第一工作流先于工具。先把“需求描述 - 代码生成 - 编译验证 - diff 审查”四步流程跑通再追求生成效率。不要一上来就让 AI 同时修改一个大型战斗系统的十个文件那只会让错误被淹没在大批量改动里。第二权限最小化。AI 能只看 Assets/Scripts 目录就不要给它整个仓库的读写权限。MCP 工具暴露得越少出问题时的排查面就越小。第三每个任务都要给边界。明确的修改文件列表、禁止触碰的目录、完成标准这些比“请帮我优化代码”这种模糊指令可靠得多。第四强制使用 git。没有版本管理之前不要让任何人或 AI 直接改项目。AI 一旦生成了你不满意的代码git 回滚是最稳的退路。第五用日志驱动修正。AI 做错时不要用“这样不对再试一次”这种抽象反馈。把编译错误信息、运行日志、性能报告具体贴给它让它基于事实修正效率会高很多。第六不要期待 AI 解决体验问题。潜行手感、难度曲线、敌人 AI 的“笨拙感”和“压迫感”都需要你反复进游戏试玩才能调好。AI 可以把状态机的代码写得完整但它不知道你的玩家会在什么时候觉得“这敌人太迟钝了”或者“这敌人开挂了吧”。第七单文件生成优于跨文件重构。AI 新手期尽量让它“新增一个独立脚本”而不是“重构现有架构”。独立脚本带来的风险是局部可控的跨文件重构则可能破坏隐藏依赖。写在最后的建议如果只给一条建议那就是把 AI 智能代理当成一位“执行力很强的实习工程师”而不是“全知全能的主程”。你给它清晰任务、清晰边界、清晰验收方式它就能帮你在 Unity 里快速落地大量重复代码但最终的游戏手感、玩法判断仍然在你自己手里。下一次你准备动手写几百行状态机之前可以先停下来想一想这部分的边界是否足够清楚如果清楚它很适合交给 Claude Code 配合 MCP 去完成如果连你自己都没想明白就不要急着让 AI 动手。真正改变游戏开发流程的不是某个具体的 AI 工具而是你建立起来的那套“人类定边界、AI 做执行、git 管结果”的协作方式。