AI辅助编程实战：三小时构建单词消消乐

一、当AI成为你的“程序员”

“不会编程，直接用AI来写靠谱吗？”这个问题在开发者社区中被反复讨论。本文记录了一次完整的实践：借助AI编程工具，在不手动编写任何代码的情况下，用三个小时完成了一个具备单词书选择、游戏进度存取、完整游戏逻辑的单词消消乐小游戏。

先看最终效果：玩家点击对应的中英文卡片，配对成功则卡片消去；上方卡片下落填补空缺，同时新卡片从顶部像俄罗斯方块一样掉落“盖楼”。整个游戏支持多本单词书切换和进度保存。

这个项目的起因很朴素——孩子备考KET，每天抱着词汇表背单词，量大且过程痛苦，背了就忘。市面上的背单词软件要么趣味性不足，要么词汇表排列与教学要求不一致。于是决定自己做一个。

本文将从需求讨论、架构设计、接口定义、编码实现到联调优化，逐步拆解整个流程，并总结AI编程中的关键心得。

二、需求阶段：与AI对齐“颗粒度”

2.1 从模糊想法到结构化需求

项目初期只有一个大致思路，需求分为三大块：选单词书 → 选游戏进度 → 开始游戏。

第一版原型图相当粗糙——手绘草图级别。但将草图发给AI编程工具后，分析结果令人眼前一亮：AI不仅完全理解了意图，还准确识别了手写标注的含义。这体现了多模态推理能力的实际价值。

实践提示：在需求讨论阶段，推理模型往往“过于聪明”，容易跳过讨论直接开始写代码。需要不断“踩刹车”，明确告诉它：先不着急进行代码实现，先完成需求对齐。

2.2 关键决策：存储方案与页面风格

在需求讨论中完成了几项关键决策：

• 存储方案：第一版不涉及后端，放弃PDF文件存储方式，改用纯文本格式存储单词书。这样既降低了复杂度，又便于后续手动编辑和版本管理。
• 页面风格：确定为小清新风格，需要保存游戏进度，并定义了粗糙版的游戏规则。
• PRD输出：让AI将上述讨论梳理成结构化的PRD文档。

这里的“对齐颗粒度”对后续开发至关重要。需求文档越精确，AI在编码阶段偏离预期的概率就越低。

三、架构设计：AI编程同样需要“大纲”

整体感受是：即使是AI编程，项目架构仍然是重中之重。架构就像小说的大纲，有了它就不容易写崩盘。

3.1 架构讨论流程

架构设计采用迭代方式：

1. 先让AI出一版架构方案；
2. 提出自己的意见和调整方向；
3. AI再调整，最后达成共识。

3.2 页面间传参与接口定义

明确页面之间的传参接口是架构设计的核心环节。三个主要页面之间的数据流转关系如下：

单词书选择页 → (selectedBookId) → 游戏进度选择页
游戏进度选择页 → (bookId, progressId, gameConfig) → 游戏页面
游戏页面 → (gameResult, updatedProgress) → 进度选择页

接口定义清晰后，各页面可以独立开发和调试，最后再进行联调。这种“先定义接口，再并行开发”的思路，与传统软件工程实践完全一致。

四、编码实现：分页面推进

4.1 单词书选择页面

第一个页面负责展示可选的单词书列表，每本书显示名称、词汇量、难度等基本信息。数据来源为预置的文本文件列表。

核心逻辑简洁明了：

// 伪代码示意
function loadWordBooks() {
  const books = readBookList(); // 读取单词书目录
  renderBookCards(books);       // 渲染卡片列表
}
function onBookSelect(bookId) {
  navigateTo('/progress', { bookId }); // 携带参数跳转
}

4.2 游戏进度选择页面

该页面接收上一步传来的 bookId，展示该单词书下可选的游戏进度。每个进度对应一组已学习的单词集合，支持“继续游戏”和“重新开始”两种模式。

进度存取采用轻量级方案，将游戏状态序列化后存入本地存储。数据结构大致如下：

{
  "bookId": "ket_core_001",
  "progressId": "stage_3",
  "learnedWords": ["apple", "banana", "..."],
  "currentScore": 120,
  "timestamp": 1700000000
}

4.3 游戏页面

游戏页面是核心模块，包含以下关键逻辑：

• 卡片生成：根据当前进度对应的单词集合，生成中英文配对卡片。
• 消除判定：点击两张卡片，若中英文匹配则消除。
• 下落与补充：消除后上方卡片下落，顶部生成新卡片。
• 进度更新：游戏结束后更新进度数据并写回存储。

游戏循环的核心逻辑可以用状态机来描述：

状态：IDLE → SELECTING → MATCHED / MISMATCHED → REFILL → IDLE

每次消除后触发下落动画和补充逻辑，保持网格始终填满。这部分交互逻辑通过AI生成后，需要人工验证边界情况，例如：当剩余卡片不足以配对时如何处理、连续快速点击的防抖等。

4.4 三页联调与风格一致性调整

三个页面独立完成后，进入联调阶段。主要工作包括：

• 传参验证：确保页面间传递的参数正确解析和使用。
• 风格统一：调整字体、配色、间距、圆角等视觉元素，保持小清新风格的一致性。
• 异常处理：补充空状态、加载状态、错误提示等边界场景。

联调阶段是AI编程中人工介入最多的环节。AI生成的各页面代码可能风格不完全一致，需要人工审查和统一调整。

五、AI编程的实践心得

5.1 需求讨论要“踩刹车”

推理模型的能力很强，但容易“把事儿做到前面去”。在需求阶段，它可能直接开始生成代码。需要反复强调：先讨论清楚需求，再动手实现。这与人月神话中的经验一致——需求阶段的返工成本远低于编码阶段。

5.2 架构设计不可跳过

即使AI能直接生成代码，架构设计仍然不可省略。没有架构指导，AI生成的代码可能结构混乱、难以维护。架构是“不容易写崩盘”的保障。

5.3 接口定义是协作的基础

页面间的传参接口定义清楚后，各模块可以独立开发、独立测试，最后联调。这种模块化思路对AI编程同样适用。

5.4 人工审查不可替代

AI生成的代码需要人工审查，尤其是边界情况和异常处理。AI倾向于生成“happy path”代码，对异常场景的覆盖往往不足。

5.5 效率提升显著

三个小时完成一个可运行的小游戏，不写一行代码。这个效率在传统开发模式下很难达到。AI编程的价值在于：将开发者从重复性编码中解放出来，专注于需求分析、架构设计和质量把控。

六、总结

AI辅助编程不是“一键生成”的魔法，而是一种新的协作模式。在这个模式中：

• 人类负责需求定义、架构设计、质量把控；
• AI负责代码生成、方案建议、重复性实现；
• 两者通过清晰的需求文档和接口定义进行协作。

对于“不会编程，直接用AI来写靠谱吗？”这个问题，答案是：对于简单项目，AI可以独立完成；对于复杂项目，AI是强大的助手，但仍需要人类的判断和把控。关键在于找到人与AI的协作边界，让各自发挥优势。

未来，随着AI编程工具的持续进化，这种协作模式将变得更加流畅。但无论工具如何变化，清晰的需求、合理的架构、严谨的验证始终是软件交付的核心要素。