最近很多人问我一个问题：
用 AI 写 Bevy 项目，到底是效率神器，还是灾难制造机？
结论很简单：
AI 不是帮你写 Bevy，而是帮你当“实时架构协作者”。
如果你只是让它“写个 Bevy 游戏”，你会得到一坨能跑但不可维护的代码。
但如果你用工程流打法，它可以直接把 Bevy 开发效率提升一个数量级。
这篇文章讲讲我实践下来的一套 AI + Bevy 高效工作流最佳实践。
核心认知：不要让 AI 写游戏，让它写“模块”
Bevy 是 ECS 架构。
ECS 的核心不是“写逻辑”，而是：
而 AI 最擅长的是：
- 生成结构化代码
- 批量模式代码
- Trait / 泛型 / 资源封装
- 状态机框架
- 工具层代码
所以正确姿势是：
❌ 错误方式：
帮我写一个 Flappy Bird
✅ 正确方式：
帮我设计一个 Bevy 插件结构
帮我拆分 Player 组件和 Movement 系统
帮我写一个基于 State 的 UI 管理模块
最佳实践一：先让 AI 设计项目结构
不要上来就写代码。
第一步应该是：
帮我设计一个 Bevy 0.18 项目结构
要支持：
AI 会给你一个类似结构：
src/
├── main.rs
├── game/
│ ├── mod.rs
│ ├── plugin.rs
│ ├── state.rs
│ └── systems/
├── player/
├── ui/
├── audio/
└── common/
这一步非常关键。
因为：
AI 一旦知道结构，后续生成的代码不会乱。
如果你不提前定结构，它每次都会“重新发明架构”。
最佳实践二：让 AI 写 Plugin，而不是 System
Bevy 的模块化核心是 Plugin。
正确问法：
帮我写一个 PlayerPlugin，包含：
- Player 组件
- 移动系统
- 重力系统
- 在 InGame 状态下运行
这样 AI 生成的代码会天然模块化：
pub struct PlayerPlugin;
impl Plugin for PlayerPlugin {
fn build(&self, app: &mut App) {
app
.add_systems(
Update,
(movement_system, gravity_system)
.run_if(in_state(GameState::InGame)),
);
}
}
你会发现：
这是工程级写法。
最佳实践三：让 AI 解释调度模型
Bevy 最大的坑在于调度。
很多人会遇到：
- borrow 冲突
- 系统顺序错乱
- 状态切换问题
- 事件没触发
这时候不要问：
为什么不工作？
要问：
解释一下这个系统的执行顺序
Bevy 0.14 下 Update 和 FixedUpdate 的区别
run_if 在调度图中什么时候判断
AI 在“解释机制”上比写代码更有价值。
你可以把它当成：
Bevy 调度图可视化解释器
最佳实践四：用 AI 做 ECS 拆分优化
很多人写着写着会变成：
struct Player {
velocity: Vec2,
hp: u32,
mana: u32,
jump_count: u8,
...
}
这是典型 OOP 思维。
这时候可以问 AI：
这个结构如何改成更 ECS 风格？
它通常会建议：
- Velocity 作为独立组件
- Health 独立组件
- JumpAbility 独立组件
这一步对大型项目极其重要。
AI 在“结构重构建议”上非常强。
最佳实践五：生成工具层代码，而不是游戏逻辑
AI 最强的地方：
- Asset loader 封装
- 资源缓存
- 状态机封装
- 泛型事件总线
- 输入映射系统
- 自定义 schedule
例如：
写一个基于枚举的输入映射系统
支持键盘和手柄
可通过 Resource 修改
这种基础设施代码：
非常适合 AI。
而真正的游戏玩法逻辑，建议你自己写。
最佳实践六：用 AI 生成测试场景
Bevy 项目最大问题：
调试困难。
你可以让 AI：
写一个 minimal reproduction 示例
只保留 Player 和 Gravity
这样可以快速定位问题。
这是非常强大的能力。
最佳实践七：限制 AI 输出长度
Bevy 项目一旦超过 300 行，AI 就开始：
- 重复定义
- 忘记 trait
- 引入未导入模块
- 乱用版本 API
解决办法：
每次只生成一个模块。
比如：
只写 Player 组件和 Movement system
不要写 main
不要写 Cargo
控制输出范围 = 控制质量。
常见 AI 踩坑总结
❌ 版本错乱
AI 经常混用 0.11 / 0.12 / 0.14 API。
解决方式：
明确指定版本号
❌ 滥用 Commands
很多代码会：
commands.spawn(...)
但没有考虑生命周期。
要问：
是否可以改成 ChildBuilder 或者 SpawnBundle？
❌ 过度 Resource
AI 喜欢把所有东西塞进 Resource。
要主动提醒：
这是 Component 还是 Resource？
真正的价值：AI 是架构副驾驶
总结一句话：
AI 不适合“帮你做游戏”，适合“帮你做引擎级结构”。
尤其在 Bevy 这种高度架构化的 ECS 框架中：
- 结构设计 > 代码量
- 模块边界 > 逻辑复杂度
- 调度清晰度 > 功能多少
如果你本身是 Rust / 异步 / 系统型开发者，
你会发现：
Bevy + AI 非常适合做“高结构密度项目”。
进阶玩法（高阶用户）
如果你已经熟悉 Bevy，可以尝试：
- 让 AI 帮你生成自定义 Schedule
- 设计自己的 ECS DSL
- 写 Editor 工具
- 写 Debug 插件
- 写数据驱动系统（JSON → Component 自动注册）
这才是 AI 在 Bevy 领域真正强的地方。
最后一句
Bevy 是架构游戏引擎。
AI 是结构生成器。
当你把它们结合起来，
效率不是翻倍，是换维度。
