vibe coding 实战：让 Gemini 3 半天搭出一个连连看原型
这篇文章写给两类读者：
- 想快速做出“能玩的”小游戏原型的独立开发者；
- 想理解 AI 协作开发节奏、避免反复返工的团队。
我们这次的目标很明确：半天内做出可玩的连连看 MVP，要求包含基础消除规则、计时、重排、提示和移动端可用布局。
一、先定“验收清单”，再写提示词
很多 vibe coding 翻车，核心不是模型能力，而是目标不清。我们先固定 5 条验收：
- 同图案可连线且最多 2 次转折；
- 无解时支持洗牌；
- 提示按钮能找到一对可消除块；
- 计时与关卡完成判定正确；
- 手机端点击区域可用。
这个清单先写出来，再让模型做实现，返工会明显减少。
二、提示词拆成 3 轮，别一口气让它“做完全部”
第 1 轮：只做数据结构和判定函数
要求 Gemini 3 先输出：
- 棋盘数据结构；
- 路径可连通判定函数；
- 可消除对搜索函数。
这一步不要 UI，先把“可玩性核心逻辑”锁死。
第 2 轮：补交互和状态流
让模型把点击状态机接上：
- 首次选中；
- 二次选中判定；
- 消除动画触发；
- 胜负状态更新。
第 3 轮：补体验项
最后再让它加提示、洗牌、计时、移动端响应式。这样每一轮都能独立验收，不会出现“改一个按钮把判定搞坏”的连锁问题。
三、半天节奏的关键：每 30~40 分钟做一次小验收
我在这次实践里用的是“短回路”：
- 模型给一版；
- 人工只测 3 个关键路径；
- 记录一个最小问题列表；
- 带着问题再喂回去。
这个节奏比“攒一堆问题一次性返工”更高效，也更不容易丢上下文。
四、最容易返工的 3 个坑
- 路径判定边界：外层虚拟边界没处理好，会导致可连线判断错漏；
- 状态重置时机：消除后未清理选中状态，下一次点击会错乱；
- 移动端点击面积：格子太小导致误触，体验直接崩。
这 3 项建议单独写测试用例，哪怕是最轻量的手测脚本也值得。
五、为什么这套方式适合小游戏开发
小游戏通常是“规则明确 + UI 轻量 + 反馈快”的场景，非常适合用 vibe coding 走 MVP。重点不是让模型一次写完，而是把它当作高频协作者：
- 你定义验收标准；
- 模型批量产出实现；
- 你在关键路径上做决策。
这样你既能保住代码质量，又能显著提高原型速度。
下一篇预告
下一篇会把这次连连看原型拆成更工程化的版本：目录结构、状态管理、资源加载和 SEO 页面包装，方便直接接入到小游戏站点。