【Kiro开发集训营】我用 AWS Kiro 极限构建 Vue3 烹饪游戏的深度复盘

最新推荐文章于 2025-11-27 17:27:09 发布

原创最新推荐文章于 2025-11-27 17:27:09 发布 · 590 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#游戏 #aws

kiro 专栏收录该内容

1 篇文章

订阅专栏

我用 AWS Kiro 极限构建 Vue3 烹饪游戏的深度复盘

摘要：从模糊的想法到一个包含物理模拟、粒子特效、智能评分和完整容错机制的 Web 应用，通常需要几天？本文详细记录了我如何利用 AWS Kiro 在 75 分钟内完成这一挑战的全过程。这不是一篇简单的工具评测，而是一次关于 Spec-Driven Development（规格驱动开发）、架构解耦以及AI 辅助危机处理的深度技术复盘。

[项目开源地址：https://gitee.com/fox-kernel/cooking-game]
(注：本文基于真实开发记录复盘，文中技术细节均源自项目实战文档)

0. 引言：开发者的“周末悖论”

我们都经历过这种时刻：脑子里蹦出一个绝妙的 Side Project 想法，比如做一个“在线模拟做菜游戏”。但热情往往终结于繁琐的准备工作：

起步难：配置 Webpack/Vite，搭建脚手架。
逻辑绕：物理碰撞怎么算？评分算法怎么写？
视觉坑：Canvas 动画太难调，CSS 兼容性搞死人。

通常，这需要一个周末。但昨天，我利用 AWS Kiro，将这个过程压缩到了 75 分钟。

最终产出：

代码规模：约 3,500 行高质量代码
核心架构：Vue 3.5 + Pinia 3.0 + GSAP 3.13 + Vite 7.2
完成度：包含 8 个 JS 模块、6 个核心组件、完整的测试用例和文档。

下面是这次“极限开发”的完整复盘。

在这里插入图片描述

第一阶段：需求工程——拒绝“一句话 Prompt”

大多数人使用 AI 编程失败，是因为习惯用“帮我写个 XX 游戏”这种模糊指令。Kiro 的核心优势在于它强制引入了 Spec-Driven Development（规格驱动开发） 流程。

1.1 需求拆解：从模糊到精确

我最初的想法仅仅是：“做一个模拟做菜的网页，能选食材、调火候。”

Kiro 并没有直接生成代码，而是引导我进入了 Requirements Phase。

结构化转化：它将我的想法转化为了 8 个标准的用户故事（User Stories）。
验收标准（Acceptance Criteria）：利用 EARS 模式，为每个功能点编写了 40+ 条可测试的标准。遵循 INCOSE 质量规则，确保需求无歧义。

在这里插入图片描述

1.2 定义核心玩法的“数学模型”

这是最关键的一步。Kiro 追问了我关于“评分系统”的细节，我们共同定义了一个复杂的数学模型：

维度一：食材组合（权重 40%）
- 逻辑：识别兼容性（如番茄+蛋）与冲突（如海鲜+特定水果）。
维度二：烹饪参数（权重 35%）
- 逻辑：构建三维矩阵（火力 x 时间 x 翻炒频率），寻找最优解。
维度三：调料用量（权重 25%）
- 逻辑：每种调料设定“最优值”和“容差范围”。

💡 开发者洞察：这一步花了 10 分钟，但它消除了后续开发中 90% 的逻辑返工风险。

在这里插入图片描述

第二阶段：架构设计——像架构师一样思考

在写第一行代码前，Kiro 生成了一份 Design Spec。它没有把逻辑全部塞进 UI 组件，而是采用了一种高度解耦的分层架构。

2.1 分层架构全景图

在这里插入图片描述

[表现层 View] -> Vue Components (UI交互)
      ↓
[状态层 Store] -> Pinia (单一数据源)
      ↓
[业务层 Logic] -> Engine (物理模拟) + Calculator (评分算法)
      ↓
[数据层 Data]  -> Static JSON (食材/菜谱定义)

2.2 关键设计决策

状态管理：使用 Pinia 集中管理烹饪状态（锅内温度、当前食材、时间进度），确保组件间状态同步无延迟。
职责分离：
- cookingEngine.js 只管“做菜”（状态变化）。
- ratingCalculator.js 只管“打分”（纯函数计算）。
- animationController.js 独立管理 Canvas 粒子，不干扰 Vue 的响应式系统。

这种架构不仅清晰，更重要的是方便测试。

第三阶段：核心实现——复杂逻辑与算法构建

这是 AI 展现“全栈能力”的高光时刻。它在 30 分钟内生成了核心业务逻辑代码。

3.1 评分算法：引入“容差机制”

真实烹饪不是化学实验，多放 1 克盐不应该导致 0 分。
在 ratingCalculator.js 中，Kiro 实现了一个智能的容差算法（Tolerance Algorithm）：

配置：为每种调料定义 optimalAmount (最优量) 和 tolerance (容差)。

逻辑：

// 伪代码示例
if (Math.abs(current - optimal) <= tolerance) {
    score = 100; // 在容差范围内不扣分
} else {
    // 超出部分按线性衰减扣分
}

这种人性化的设计，让游戏体验瞬间提升了一个档次。

3.2 物理模拟与错误边界

为了模拟真实的烹饪过程，代码需要处理各种输入。Kiro 在 cookingEngine.js 中植入了大量的防御性编程：

输入验证：自动验证火力（1-10级）、时间（10-300秒）的合法性。
```
validated.heatLevel = Math.max(1, Math.min(10, validated.heatLevel))
```
异常捕获：在计算评分时包裹 try-catch，防止因浮点数计算错误导致页面崩溃，并提供默认返回值（50分）。

第四阶段：视觉工程——GSAP 与 Canvas 的华丽结合

一个好游戏必须“好看”。我希望有蒸汽、香气和火花。

在这里插入图片描述

4.1 混合渲染策略

Kiro 采用了 Vue DOM + Canvas 覆盖层的混合渲染方式：

UI 元素：使用 Vue 渲染锅具、食材图标。
粒子特效：使用 Canvas 渲染高频更新的粒子。

4.2 粒子系统的性能优化

在 animationController.js 中，Kiro 并没有暴力生成粒子，而是实施了严格的性能优化：

对象池思想：限制粒子总数（Max 100），复用已消亡的粒子对象，减少垃圾回收（GC）压力。
批量渲染：同类粒子（如灰色蒸汽、金色香气、橙色火花）批量绘制，减少 Canvas 的 context 切换开销。
动态帧率：使用 requestAnimationFrame 确保 60fps 流畅度，同时尊重用户的 prefers-reduced-motion 设置。

4.3 交互反馈

利用 GSAP 动画库，实现了锅具的动态翻炒：

联动逻辑：翻炒频率参数（Frequency）直接绑定动画的 duration。用户滑块拖得越快，锅铲动得越快。

第五阶段：危机处理——AI 的“自我修复”能力

这一阶段最能体现 Kiro 作为一个“智能伙伴”而非“代码生成器”的价值。

5.1 突发状况：Tailwind CSS v4 配置冲突

在这里插入图片描述

在开发中途，我们遇到了严重的构建错误。Tailwind CSS v4 的新特性与当前 Vite 环境中的 PostCSS 插件产生了严重冲突，导致页面完全无法加载。

通常，这需要开发者去 GitHub Issues 排查半天。

5.2 Kiro 的诊断与决策

我将报错日志丢给 Kiro，它的反应非常迅速：

识别（Identify）：精准定位错误源为 PostCSS 插件不兼容。
分析（Analyze）：评估修复成本。它指出，对于只有 6 个组件的中小型项目，强行配置复杂的 Tailwind 环境性价比极低。
决策（Decide）：建议移除 Tailwind，转而使用 Vue 原生的 Scoped CSS。

5.3 闪电执行

在获得许可后，Kiro：

自动运行命令卸载了 Tailwind 相关依赖。
重写代码：在 5 分钟内，将所有组件内的 Tailwind Utility Classes 转换为了语义化的标准 CSS，并使用了 CSS 变量管理主题色。
结果：项目恢复运行，且样式未受影响。

这种**“遇到死胡同能迅速掉头”**的工程决策能力，极其宝贵。

第六阶段：交付与打磨——被忽视的“最后一公里”

很多 Demo 死在细节上，但 Kiro 帮我守住了质量底线。

6.1 持久化存储的智能容错

在保存历史记录（LocalStorage）时，Kiro 考虑到了真实场景中的极端情况——存储空间不足（QuotaExceededError）。
它自动生成了如下逻辑：

try {
  localStorage.setItem('history', JSON.stringify(data));
} catch (error) {
  if (error.name === 'QuotaExceededError') {
    // 智能策略：删除最旧的 20 条记录，腾出空间后再试
    dishHistory.value = dishHistory.value.slice(0, 20);
    saveToStorage(); // 重试
  }
}