零基础用AI编程做单词游戏：一次完整实践记录

一、背景与目标

这次实践的起点是一个很具体的家庭需求：孩子正在备考，需要反复记忆大量单词。传统背词方式枯燥，容易遗忘，而现成的背词软件要么趣味性不足，要么单词表结构不符合老师要求。于是决定自己做一个轻量的单词小游戏。

目标并不复杂，但比普通 Demo 更接近真实项目：

1. 可以选择不同的单词书；
2. 可以读取或选择游戏进度；
3. 核心玩法是“点击匹配中英文词对”，匹配成功后卡片消除；
4. 上方卡片会下沉补位，同时下方像方块一样继续掉落新卡片；
5. 页面风格统一，偏清新简洁；
6. 第一版不涉及后端，数据用文本文件保存。

最关键的约束是：不手写一行代码，全部通过智能编程工具辅助完成。

这个约束不是为了炫技，而是想验证一个非常实际的问题：如果需求足够清楚、拆解足够细，一个没有编程背景的人是否也能借助 AI 编程工具完成小型应用。

二、先把需求讲清楚，比急着写代码更重要

很多人在使用 AI 编程时，第一反应是直接说：“帮我写一个背单词游戏。”但这样得到的通常是一个通用 Demo，后续几乎无法扩展。

这次实践的第一阶段没有写任何代码，而是先和工具讨论需求。

1. 用草图表达页面想法

最初的页面原型其实画得非常粗糙，几乎就是几个方框加箭头，分别表示：

• 单词书选择页；
• 游戏进度选择页；
• 游戏主页面。

令人意外的是，工具的“多模态理解能力”在面对这种草图时，依然能够准确识别页面结构和跳转关系。这说明在需求阶段，不必等到原型非常完整，只要能表达清楚页面边界和主要交互即可。

2. 控制工具不要“过度发挥”

推理能力较强的模型有一个常见问题：在需求尚未完全明确时，就倾向于直接生成代码。例如，刚说完“我想做单词游戏”，它可能已经开始设计数据结构或页面组件了。

这时需要不断“踩刹车”，明确告诉它：

• 先不要写代码；
• 先帮我梳理需求；
• 先确认页面关系；
• 先讨论技术方案。

这一步非常关键。需求阶段的目标是“达成共识”，而不是“尽快看到界面”。

3. 对齐关键业务规则

在讨论中，逐渐明确了几个关键点：

• 单词书第一版用 TXT 文本存储，避免引入后端与文件系统复杂度；
• 每本单词书可以有多条进度，用户可以继续历史进度，也可以新开一局；
• 游戏规则需要明确：点击英文单词，再点击对应中文释义，匹配成功则消除；如果点错，可以设计为无惩罚或轻微提示；
• 新卡片会从上方或下方补位，形成类似“消消乐 + 俄罗斯方块”的效果。

这些规则看似简单，但如果不提前写清楚，AI 在生成代码时会自我发挥，导致页面逻辑五花八门。

最终，工具根据讨论结果整理出了一份简版需求文档，包括页面清单、交互流程、数据字段和规则说明。这份文档成为后续所有开发工作的基线。

三、先定架构，再谈页面

即使是 AI 编程，也不能跳过架构设计。架构在小型项目中同样重要，它决定了：

• 页面如何组织；
• 数据如何在页面之间传递；
• 后续增加功能时是否还需要推倒重来。

1. 页面结构设计

这个应用一共三个页面：

• 单词书选择页；
• 进度选择页；
• 游戏页。

页面结构并不复杂，但需要提前定义清楚“谁可以跳转到谁”。例如：

单词书选择页 → 进度选择页 → 游戏页
游戏页 → 返回进度选择页
游戏页 → 返回单词书选择页

这种导航关系确定后，后面写页面跳转逻辑时就不会混乱。

2. 页面之间的传参设计

这是整个项目最容易出错的地方。很多 AI 生成的代码在单页演示时看起来很好，一旦涉及多页跳转和状态共享，就开始出现数据丢失、重复初始化、参数名不一致等问题。

因此，在写代码前，先和工具一起定义清楚页面间需要传递的内容。例如：

单词书选择页 → 进度选择页
传递内容：单词书 ID、单词书名称
进度选择页 → 游戏页
传递内容：单词书 ID、进度 ID、是否需要恢复历史状态

同时约定这些参数在跳转时的命名方式，例如统一使用 bookId、progressId，避免一个页面叫 id，另一个页面叫 book_id。

3. 数据结构约定

第一版使用 TXT 存储单词书，因此需要提前约定文本格式。例如：

# 单词书名称
apple|苹果
banana|香蕉
cat|猫

每行一组中英文，中间用固定分隔符隔开。这样后续解析逻辑简单，也方便用户自行编辑单词书。

进度数据则可以用 JSON 结构保存，字段包括：

{
  "bookId": "ket-core-01",
  "progressId": "20250101-001",
  "matchedPairs": 12,
  "totalPairs": 100,
  "remainingWords": ["apple|苹果", "cat|猫"],
  "updatedAt": "2025-01-01T10:00:00Z"
}

这些结构虽然简单，但提前定义后，后续生成解析代码、保存代码时，错误率会明显下降。

四、逐页生成与联调

架构和接口确定后，才开始进入代码生成阶段。即使如此，仍然不建议一次性让 AI 生成整个应用，而是按页面拆分。

1. 单词书选择页面

这一页的核心逻辑是：

• 读取可用单词书列表；
• 展示单词书名称和单词数量；
• 用户点击后进入进度选择页。

生成时，需要明确告诉工具：

• 单词书文件放在哪个目录；
• 如何扫描目录；
• 如何读取每个文件的第一行作为书名；
• 点击时传递哪些参数。

示例逻辑可以描述为：

读取指定目录下所有 txt 文件，每个文件代表一本单词书。
文件第一行为书名，其余行为单词对。
页面以卡片列表形式展示书名与词条数量。
点击卡片后，携带 bookId 和书名跳转到进度选择页。

这种描述足够具体，AI 生成的代码基本不需要返工。

2. 游戏进度选择页面

该页面根据传入的单词书 ID，读取该单词书对应的历史进度。

需要处理的逻辑包括：

• 展示已有进度，如“已掌握 12/100”；
• 允许用户继续某个进度；
• 允许用户新建进度；
• 删除旧进度。

该页面涉及的本地存储逻辑比第一页复杂。为了方便，第一版允许将进度直接保存在本地文本或 JSON 文件中，不引入数据库。

这一阶段最容易出现的问题是 AI 把进度存储逻辑写得太复杂，比如直接引入一套完整的数据层。因此在提示中需要明确范围：

第一版不使用数据库，进度以 JSON 文件形式保存在本地。
每个进度文件包含所属单词书 ID、已匹配词对和剩余词对。
页面需要支持读取、新建和删除操作。

3. 游戏页面

游戏页面是核心，也最能体现 AI 编程的“视觉生成能力”。

核心交互如下：

• 页面加载时，根据进度信息渲染当前单词卡片；
• 用户先点击一个英文单词，再点击一个中文释义；
• 如果匹配，则两张卡片消除；
• 消除后，上方卡片下沉补位；
• 同时从底部或顶部生成新的单词卡片；
• 当所有单词匹配完成时，提示通关并保存进度。

在生成游戏页面时，可以把重点放在“动画效果”和“状态更新”上。例如：

卡片消除后，剩余卡片需要平滑下移；
新卡片从底部加入，并带有轻微弹入效果；
卡片布局使用网格，每行固定列数。

实践证明，只要把交互描述清楚，工具可以生成非常接近预期的页面效果，包括基础动画和响应式布局。

4. 页面风格统一与联调

三个页面分别生成后，可能出现风格不一致、字号不统一、颜色偏差等问题。

此时需要做一次全局样式整理。可以让工具根据一个统一的视觉风格，重新整理所有页面的样式，例如：

• 背景色统一；
• 卡片圆角统一；
• 按钮颜色和悬停效果统一；
• 字体大小按页面层级设定。

同时，在联调阶段逐个验证：

• 从单词书选择页跳转到进度页时，参数是否正确；
• 从进度页进入游戏页时，是否能正确恢复已匹配的词对；
• 游戏过程中退出再进入，进度是否保存；
• 新建进度后，旧进度是否仍然存在。

这些问题中，参数传递和进度恢复是最容易出错的环节。由于前面已经定义了明确的传参结构，联调时基本没有出现大规模返工。

五、实践心得

这次实践最明显的感受是：AI 编程的效率高度依赖需求表达质量。

如果只是模糊地说“帮我做个小游戏”，得到的通常是一个能看但不能用的页面。而一旦把页面结构、跳转关系、数据结构和规则边界说清楚，AI 生成的代码质量会显著提高。

另一个值得注意的点是，不要把 AI 当成一次性交付工具，而要把开发过程拆成“讨论—确认—生成—验证”的循环。在这个循环中，人的角色不是写代码，而是做决策和验证。

最后，对于没有编程经验的人来说，用 AI 编程完成小型应用已经具备可行性。但前提是：愿意花时间把需求和规则想清楚，并且能够用结构化语言表达出来。代码可以交给工具，但产品逻辑和边界仍然需要人来定义。