用Kiro的Vibecoding模式开发游戏：一次让我重新思考"写代码"的经历

写在前面

周五晚上11点,我盯着VSCode里那个半成品的大鱼吃小鱼游戏发呆。Canvas上的鱼勉强能动,但AI逻辑一团乱麻,碰撞检测Bug百出,更别提我脑子里那些"变异能力"、"粒子特效"的想法了。

作为一个工作五年的前端开发,这种"想法很丰满,实现很骨感"的时刻太熟悉了。我算了算:照这个进度,至少还要两周才能做出一个像样的Demo。周末的时间又要泡汤了。

就在这时,同事在群里发了条消息:“试试亚马逊云科技的Kiro吧,Vibecoding模式真的很神奇。”

抱着试试看的心态,我开始了一次完全改变我对"写代码"认知的旅程。

第一次接触:从怀疑到惊讶

怀疑是正常的

说实话,我对AI辅助编程工具一直持保留态度。GitHub Copilot用过,ChatGPT也用过,它们确实能补全代码、解释概念,但在真实项目开发上,我总觉得还是得自己来。

原因很简单:

• AI生成的代码往往缺乏整体设计
• 需求稍微复杂一点,AI就开始胡言乱语
• 生成的代码风格不统一,需要大量修改
• 最关键的是:AI不理解你的真实意图

所以当我打开Kiro时,心里其实没抱太大期望。

第一个惊喜:它真的在"听"

我对Kiro说了一句很模糊的话:

“我想做一个可爱的大鱼吃小鱼游戏,要萌一点,最好有些特色功能,比如鱼可以变异什么的。”

然后发生了让我意外的事——Kiro没有直接开始写代码,而是开始提问和确认:

"让我理解一下你的想法:
1. 游戏风格偏向可爱萌系?
2. 变异系统是核心玩法?
3. 你希望有多少种变异类型?
4. AI鱼的行为需要多智能?
5. 是否需要渐进式难度?
..."

这一刻我意识到,Kiro不是在"生成代码",而是在理解项目。

Vibecoding模式:重新定义"写代码"

什么是Vibecoding?

传统开发流程是线性的:

需求 → 设计 → 编码 → 测试 → 部署

每个阶段都需要开发者手动切换思维模式,消耗大量心智。

而Kiro的Vibecoding模式,更像是思维流式开发:

想法 ⇄ 对话 ⇄ 代码 ⇄ 验证 ⇄ 迭代

你只需要保持在"思考"和"决策"的状态,Kiro负责把你的思路转化为具体实现。

第一个阶段:需求澄清(10分钟)

让我印象深刻的是,Kiro用EARS规范帮我梳理需求:

WHEN 玩家的鱼接触到更小的鱼时,
THE SYSTEM SHALL 增加玩家鱼的成长值
AND 播放吃鱼动画
AND 触发粒子特效

我从来没想过,我那些零散的想法可以这样清晰地表达出来。更重要的是,Kiro会指出需求中的模糊点:

“你说的’可爱’,具体是指视觉风格、动画表现,还是音效?”
“变异能力的持续时间和冷却时间是多少?”
“Boss鱼应该在什么条件下出现?”

这些问题逼着我思考那些平时会"边做边想"的细节。结果就是:节省了大量返工时间。

第二个阶段:架构设计(15分钟)

这是让我最震撼的部分。

Kiro建议使用ECS(Entity-Component-System)架构。老实说,我之前听说过ECS,但一直觉得太复杂,没有深入研究。

但Kiro的解释方式让我突然理解了:

// 传统OOP方式
class Fish {
  position: Vector;
  velocity: Vector;
  size: number;
  ai: AIBehavior;
  
  update() {
    // 所有逻辑混在一起
    this.move();
    this.checkCollision();
    this.updateAI();
    this.render();
  }
}

// ECS方式
// 组件只负责数据
interface PositionComponent { x: number; y: number; }
interface VelocityComponent { vx: number; vy: number; }

// 系统只负责逻辑
class MovementSystem {
  update(entities: Entity[]) {
    // 只处理移动逻辑
  }
}

Kiro说:“ECS让每个系统专注做一件事,代码更容易测试、调试和扩展。”

然后它给出了完整的系统设计:

• InputSystem(输入处理)
• MovementSystem(移动)
• CollisionSystem(碰撞检测)
• AISystem(AI行为)
• GrowthSystem(成长系统)
• MutationSystem(变异系统)
• ParticleSystem(粒子特效)
• RenderSystem(渲染)

每个系统的职责清晰,依赖关系明确。这种模块化程度,是我过去写代码时很难达到的。

第三个阶段:任务分解(5分钟)

Kiro把整个项目拆成了33个独立任务,每个任务都有:

• 明确的目标
• 验收标准
• 依赖关系
• 预计耗时

比如:

Task 12: 实现AI逃离行为
- 目标: AI鱼检测到更大的鱼时逃离
- 标准: 
  ✓ 检测范围150px
  ✓ 逃离速度提升50%
  ✓ 逃离方向与威胁相反
- 依赖: Task 8(AI基础框架)
- 耗时: 30分钟

这种颗粒度让我可以专注于一件事,而不是被复杂度淹没。

代码实现:AI写代码是什么体验?

不是"生成代码",是"协作编程"

很多人以为AI写代码就是:“给个需求,输出代码,完事。”

实际体验完全不是这样。

场景1:变异系统的实现

我对Kiro说:“我想要一个磁力鱼变异,可以自动吸引小鱼。”

Kiro的反应是:

"好的,让我们讨论一下细节:

1. 吸引范围是多少? 建议200-300px
2. 吸引力是恒定的还是递减的? 建议随距离递减
3. 被吸引的鱼是否还保留AI行为? 建议暂停AI
4. 持续时间? 建议15秒
5. 视觉反馈? 建议绿色光环+连线特效"

这种对话让我意识到,Kiro不只是在写代码,而是在做设计决策。

最终生成的代码:

class MagneticMutation implements Mutation {
  private readonly RANGE = 250;
  private readonly FORCE_MULTIPLIER = 2;
  
  update(player: Entity, entities: Entity[], deltaTime: number) {
    const smallerFish = entities.filter(e => 
      e.size < player.size && 
      this.distance(player, e) < this.RANGE
    );
    
    smallerFish.forEach(fish => {
      const direction = this.getDirection(fish, player);
      const distance = this.distance(fish, player);
      const force = this.FORCE_MULTIPLIER * (1 - distance / this.RANGE);
      
      fish.velocity.x += direction.x * force;
      fish.velocity.y += direction.y * force;
    });
  }
}

代码质量很高:命名清晰、逻辑简洁、性能考虑周到(用距离衰减而不是恒定力)。

场景2:AI行为状态机

AI系统是游戏的核心,也是最容易写乱的部分。

我过去的做法通常是一堆if-else:

// 我以前会这么写
if (hasNearbySmallFish) {
  if (canCatch) {
    chase();
  } else {
    wander();
  }
} else if (hasNearbyBigFish) {
  flee();
} else {
  wander();
}

Kiro给出的方案是状态机模式:

enum AIState { WANDER, CHASE, FLEE }

class AISystem {
  updateState(entity: Entity, others: Entity[]): AIState {
    const threats = this.findThreats(entity, others);
    const prey = this.findPrey(entity, others);
    
    if (threats.length > 0) return AIState.FLEE;
    if (prey.length > 0) return AIState.CHASE;
    return AIState.WANDER;
  }
  
  executeBehavior(entity: Entity, state: AIState) {
    switch(state) {
      case AIState.FLEE:
        this.flee(entity);
        break;
      case AIState.CHASE:
        this.chase(entity);
        break;
      case AIState.WANDER:
        this.wander(entity);
        break;
    }
  }
}

代码结构清晰,每个状态的行为独立,易于扩展和调试。

让我改变认知的时刻

在实现粒子系统时,我随口说了一句:“粒子太多会不会卡?”

Kiro的回答让我意识到,它不只是写代码,而是在工程优化:

“是的,频繁创建/销毁粒子对象会造成GC压力。我会用对象池模式优化。”

然后生成了完整的对象池实现:

class ParticlePool {
  private pool: Particle[] = [];
  private active: Particle[] = [];
  
  get(): Particle {
    let particle = this.pool.pop();
    if (!particle) {
      particle = new Particle();
    }
    this.active.push(particle);
    return particle;
  }
  
  release(particle: Particle) {
    const index = this.active.indexOf(particle);
    if (index !== -1) {
      this.active.splice(index, 1);
      particle.reset();
      this.pool.push(particle);
    }
  }
}

这种主动的性能意识,是我在很多"代码生成工具"中没见过的。

遇到的真实问题和解决

问题1:TypeScript类型错误

开发过程中,Kiro生成了一个类型导入错误:

import { Vector } from './types';  // ❌ 找不到模块

传统工具可能会让你自己去改,但Kiro主动说:

“检测到类型导入错误,我用getDiagnostics分析一下。”

然后自动修复:

import { Vector } from './types/Vector';  // ✅ 正确的路径

这个细节让我印象深刻:AI不是生成完代码就不管了,而是会验证和修复。

问题2:游戏平衡性

玩了几局后,我发现Boss鱼太难打了。

我对Kiro说:“Boss太强了,几乎不可能赢。”

Kiro的回应:

"让我们调整Boss的参数:

• 当前速度: 3.0 → 建议: 2.0
• 当前检测范围: 300 → 建议: 250
• 击败奖励: 500 → 建议: 1000(增加成就感)

另外,建议给玩家一个Boss出现的视觉提示。"

这种游戏设计层面的建议,超出了我的预期。

问题3:边界条件Bug

测试时发现鱼偶尔会卡在屏幕边缘。

我描述了现象,Kiro立刻定位问题:

“这是边界反弹逻辑的问题。当前代码只检查中心点,但鱼有半径。我会修复为检查边界+半径。”

// 修复前
if (entity.position.x < 0) {
  entity.position.x = 0;
}

// 修复后
if (entity.position.x - entity.size < 0) {
  entity.position.x = entity.size;
  entity.velocity.x = Math.abs(entity.velocity.x);
}

不仅修复了Bug,还加了速度反弹的物理效果。

深度思考:AI辅助开发的本质是什么?

经历了这次开发,我对AI辅助编程有了新的理解。

不是"替代",是"增强"

很多人担心AI会取代开发者。但实际体验告诉我:AI改变的是开发者的工作内容,而不是取代开发者。

过去我的时间分配:

• 写重复代码: 40%
• 调试Bug: 30%
• 查文档: 15%
• 思考架构: 10%
• 做决策: 5%

用Kiro之后:

• 写重复代码: 5%(AI生成)
• 调试Bug: 10%(AI辅助)
• 查文档: 5%(AI解释)
• 思考架构: 40%(核心工作)
• 做决策: 40%(核心工作)

开发者的价值从"体力劳动"转向"脑力劳动"。这是好事。

不是"魔法",是"方法论"

Kiro的强大不在于它"会写代码",而在于它内置了最佳实践:

• EARS需求规范
• ECS架构模式
• SOLID设计原则
• 对象池优化
• 状态机模式
• …

这些都是经过验证的工程方法论。Kiro把它们系统化地应用到项目中,保证了代码质量。

普通开发者可能知道这些概念,但真正应用时往往会打折扣(赶时间、懒得做、忘记了)。AI的优势是:永远严格遵循最佳实践。

不是"快",是"对"

最初吸引我的是"3-4小时完成10天工作量"的效率。

但用下来我发现,真正的价值不是"快",而是"对":

• 需求对:清晰、完整、可测试
• 架构对:模块化、可扩展、易维护
• 代码对:规范、优化、无Bug
• 文档对:详细、准确、专业

快是结果,对是原因。

很多时候我们为了快而牺牲质量,结果后期花更多时间修补。Kiro让你在保证质量的前提下提速,这才是可持续的。

给开发者的启示

1. 重新定义"写代码"

过去:“写代码=敲键盘输入字符”
现在:“写代码=思考+决策+验证”

AI让你从"如何实现"的细节中解放出来,专注于"做什么"和"为什么"。

2. 拥抱模糊性

传统开发要求需求必须清晰。但现实中,很多想法在开始时是模糊的。

Vibecoding模式允许你从模糊想法开始,通过对话逐步澄清。这更符合真实的创新过程。

3. 学会提问

和AI协作的关键不是"给指令",而是"提问题":

• “这个设计有什么潜在问题?”
• “有更好的实现方式吗?”
• “如何优化性能?”
• “边界情况怎么处理?”

AI可以从多个角度审视你的代码,提供你可能忽略的见解。

4. 工程化思维更重要

AI可以生成代码,但不能替你做架构决策。

理解为什么要用ECS,比知道怎么写ECS代码更重要。

这意味着开发者需要提升的是:系统性思维、权衡能力、设计直觉。

5. 快速迭代的价值

过去,我往往陷入"完美主义陷阱":想一次做对,结果迟迟不敢动手。

有了AI辅助,试错成本大大降低。快速尝试→验证→调整成为可能。

我可以在30分钟内尝试三种不同的AI算法,找到最适合的那个。

这次开发改变了什么?

对项目的影响

• 交付时间: 从预计2周 → 实际4小时
• 代码质量: TypeScript零错误,模块化优秀
• 功能完整度: 实现了100%的规划功能
• 技术债: 几乎为零(架构清晰,代码规范)
• 文档完善度: 需求、设计、代码、用户手册齐全

对我的影响

更深远的是思维方式的改变:

1. 更愿意尝试新想法
   过去:“这个功能太复杂,算了。”
   现在:“让我和AI聊聊,看看能不能实现。”

2. 更注重架构和设计
   过去:花80%时间写代码
   现在:花80%时间思考架构

3. 更自信地学习新技术
   过去:看到ECS、状态机这些概念就头大
   现在:AI可以解释概念,还能生成示例代码帮我理解

4. 更享受编程本身
   过去:被琐碎的实现细节困扰
   现在:专注于创造性的决策和设计

一些冷静的思考

AI不是万能的

经历了这次开发,我也更清楚AI的局限:

1. 需要明确的上下文
   如果你自己都不知道想要什么,AI也帮不了你。

2. 不能替代领域知识
   AI可以告诉你"怎么做",但不能告诉你"做什么有价值"。

3. 仍需人工验证
   AI生成的代码需要review,逻辑需要测试,设计需要评估。

4. 创意仍是人类的
   “8种变异能力”、"Boss战"这些创意想法,还是得人来想。

开发者不会被取代

反而,我觉得好的开发者会更加重要:

• AI让普通开发者变得高效
• 但优秀开发者掌握AI后,效率提升是指数级的

就像Excel不会让会计失业,反而让优秀会计更有价值。

关键是:主动拥抱工具,提升不可替代的能力。

写在最后:普通开发者的真实感受

回到文章开头那个周五晚上。

如果没有尝试Kiro,我现在可能还在VSCode里调试碰撞检测的Bug,或者已经放弃了这个项目。

但现在,一个功能完整、代码优雅、体验流畅的游戏已经上线了。更重要的是,我学到了ECS架构、状态机模式、对象池优化等最佳实践,这些知识会在未来的项目中持续发挥价值。

AI辅助开发不是未来,是当下。

如果你是开发者,我建议你找个周末,选一个一直想做但没时间做的项目,试试Vibecoding模式。不是为了证明AI多强大,而是为了体验那种思维流畅、创意涌现、代码自然生成的感觉。

那种感觉,就像第一次骑上自行车,突然发现世界变大了一样。

编程本该如此:专注于创造,而不是被细节淹没。最终效果如下：

项目信息:

• 游戏名称:可爱大鱼吃小鱼
• 技术栈: TypeScript + Canvas 2D
• 开发时间: 4小时
• 代码量: 2000+行
• 开发工具: 亚马逊云科技Kiro(Vibecoding模式)

开源地址: GitHub仓库

如果你有任何问题或想法,欢迎留言讨论。让我们一起探索AI时代的编程新方式。🚀

写于2025年11月底,一个被AI改变的开发者