龙虎斗游戏开发：AI生成代码以后，为什么开发者仍然必须检查场景、依赖和现有脚本？
事故是这样发生的。开发者让AI“给角色增加冲刺”，AI生成了一段干净的代码：按下Shift，速度乘以二，持续0.3秒，冷却两秒。编译通过，运行正常，冲刺手感不错。两周后测试反馈：冲刺不消耗体力。查下去才发现，项目里的体力系统在Stamina.cs里，跳跃和攀爬都会调用它扣体力，但AI写的Dash.cs根本不知道这个脚本存在。冲刺变成了无限使用的免费技能，而设计文档里写得很清楚：冲刺消耗20点体力。AI没有错，它没看见Stamina.cs；开发者也没有错，他以为AI看见了。问题出在“看见”这件事从来没有被确认过。
“增加冲刺”背后至少要碰七样东西
把这个需求拆开：Input，冲刺绑定哪个键，是否与已有的按键冲突，用的是旧输入系统还是Input Action；Movement，冲刺是改速度还是施加力，与现有移动脚本的关系是覆盖还是叠加；Animation，Animator里有没有冲刺状态，没有就要加，加了要处理过渡；Stamina，消耗多少，不够时怎么反馈；Cooldown，冷却怎么计时，UI要不要显示；UI，冷却图标、体力条变化；Network，联机时冲刺要不要同步，同步速度还是同步事件。七样东西里，AI在没有上下文的情况下通常只做前两样，因为只有这两样是“冲刺”这个词本身包含的。其他五样都存在于项目里，不在需求里。
Coding Model和Project-aware Agent的分界
Coding Model理解代码上下文：它能读当前文件，能读你贴给它的其他文件，能推断函数之间的调用关系。这在普通软件项目里够用，因为软件项目的大部分关系都在代码里。游戏项目不一样，大量关系在代码之外：哪个GameObject挂了哪个脚本是编辑器里拖出来的；字段的实际值是Inspector里填的，不是代码里的默认值；Animator的状态和过渡存在资源文件里；Prefab之间的引用是序列化数据。Project-aware Agent的意思就是把这些代码之外的东西也读进来：Scene、Object、Asset、Package、Log、Editor State。2026年Unity的编辑器内AI助手明确以此为定位，能读取场景层级、项目设置、包、代码和Inspector序列化数据，Unity MCP Server把这些暴露给外部编码Agent。Roblox的Studio Assistant在生成计划前会先分析现有代码和数据模型。这些都还是Beta，但方向一致：先读项目，再动手。
| 维度 | 普通Coding Chatbot | Project-aware Agent |
|---|---|---|
| 看到的输入 | 一句需求，可能加几个贴进来的文件 | 需求 + 场景层级 + 相关脚本 + Prefab引用 + Animator + 输入方案 + 日志 |
| “增加冲刺”的输出 | 新建Dash.cs，速度乘二 | 修改现有Movement脚本，调用Stamina，添加Animator状态，标注网络同步待确认 |
| 典型失败 | 与现有系统脱节，编译通过但行为不符设计 | 上下文不完整时仍可能漏项，但会在计划里列出它读了什么 |
| 开发者要做的 | 自己补齐五样东西 | 审查计划和Diff |
动手前的核对清单
- 项目里有没有已经实现类似功能的脚本？让AI先搜索并列出。
- 这个功能会调用或被调用的系统有哪些？体力、冷却、动画、网络逐个确认。
- 相关字段的实际值在哪里？代码默认值、Inspector、配置表，哪个生效？
- 目标平台是什么？移动端的输入和性能约束与桌面端不同。
- 要求AI在修改前复述它理解的现状，复述错了就先纠正，不要让它带着错误理解动手。
编译失败与编译成功但行为不对
AI生成代码编译失败，原因通常很直白：引用了项目里不存在的类、用了过时的API、命名空间不对。这类问题反而好处理，编译器会指出来。真正麻烦的是编译成功但行为不对：字段被Inspector覆盖导致代码改动无效；项目里存在平行实现，新旧两套同时生效；改动了一个被Prefab引用的组件导致引用丢失。这些问题编译器不报，运行时也未必立刻报，往往要到玩到某个特定情况才暴露。检查场景、依赖和现有脚本的意义就在这里：把这类问题在合并前找出来，而不是两周后从测试反馈里找。
当前限制
截至2026年9月，项目感知工具索引大型工程时仍有明显的上下文缺口：自定义序列化格式、第三方插件、大量Prefab变体，这些常常读不全。龙虎斗游戏开发的建议是，把项目感知Agent用在边界清晰的局部修改上，并且始终让开发者做最后一道检查。工具会进步，但“确认AI看见了什么”这个习惯不会过时。