我如何使用 AI 构建浏览器游戏门户以及我自己必须修复的地方

发布: 5天前 (2026年1月15日 GMT+8 00:09)

9 min read

⚠️ Translation Warnings:

Body: Section 5 error: Error code: 401 - {‘error’: {‘message’: ‘401 Unauthorized: unauthorized’, ‘type’: ‘api_error’, ‘para

Source: Dev.to

为什么我选择基于浏览器的 Vibe‑Coding 工具和 React

我开始使用的 Vibe‑Coding 工具可以根据初始提示快速创建可运行的 Web 应用：

I want to build a puzzle games website where people 
can play different brain teasers and logic puzzles. 
Users should be able to create accounts, track their scores, 
and compete on leaderboards. 
Use react and vite.

我特意选择了自己已经稍有了解的技术栈，这样才能评估生成代码的质量——结果相当令人印象深刻！

第一次实验中让我印象深刻的地方

第一个版本已经相当不错，无论是视觉效果还是技术实现。
工具能够理解我的提示并很好地执行。
界面看起来像浏览器中的 VS Code，并且可以在源代码和运行中的应用之间切换。

首批成功

如前所述，游戏门户在 AI 编码工具中很快就启动并运行了。我可以使用模糊的、非技术性的提示来微调整体外观：

Use different colors. It should be bright and friendly.
Also, make sure it looks good on mobile screens.

AI 生成的颜色、游戏徽标和文字看起来很棒，下面的截图即是体现。

生成器在我没有特别要求的情况下首先添加的游戏之一是 记忆游戏 和扫雷。两者都立即可用，只需进行少量调整（颜色、按钮样式、响应式布局）——全部通过非技术性提示完成：

Add buttons for restarting the game and starting the 
game of the day. While all games are randomly initialized, 
the game of the day should be the same game for all users.

AI 发明了一个 “seed” 概念，并实现了基于当前日期的伪随机种子。效果非常好！

添加变体（不同的场地大小等）只需让 AI 去做即可。我真的被震撼到了。

这些早期的成功之所以可能，是因为游戏本身很简单。一旦我尝试构建更复杂的游戏，情况就发生了变化。

AI 在复杂游戏和视觉方面的挑战

AI 一直生成大致如下结构的 React 游戏组件：

import React, { useState, useEffect } from "react";
// … types and constants

export function Game({ seed, gridSize: initialSize }: GameProps) {
  // state hooks
  const [isRunning, setIsRunning] = useState(false);
  // …

  // set up grid
  const initializeGame = () => {
    // …
  };

  // side effects
  useEffect(() => {
    // …
  }, []);

  // handlers
  const onNewGame = () => {
    // …
  };

  // JSX
  return (
    
      {/* … */}
    
  );
}

当游戏变得更复杂时，这种模式会带来几个问题：

组件过长 – 难以阅读和理解。
职责混杂 – 游戏逻辑和呈现逻辑交织在一起。
逻辑难以测试 – 很难为核心机制编写独立的单元测试。
可复用性低 – 相同的逻辑无法在不同游戏或组件之间共享。

这些问题让门户网站更难维护，甚至小错误也会给我和 AI 带来修复上的痛苦。

我在创建 管道连接游戏（在网格中连接管道，使水能够从起点流向终点）时深刻体会到了这一点。

您可以在此尝试管道游戏：。

初始版本的问题

伪随机的初始解生成不正确。
胜利条件检测失败。
已连接的管道没有以不同颜色高亮显示。
管道的 SVG 边框缺失。

我是如何解决的

让 AI 重构组件 – 将逻辑拆分到单独的文件中。
创建合适的 TypeScript 类（或一组纯函数），封装所有游戏机制。
为新类编写单元测试，验证种子生成、胜利检测以及管道着色逻辑。
保持 React 组件简洁 – 现在它只负责渲染和用户交互，所有繁重的工作都交给提取出的逻辑模块。

这次重构显著提升了可读性、可测试性和可维护性，同时也让未来的扩展（新管道形状、难度等级等）变得更加容易实现。

Takeaways

Start simple – AI generators shine when the target is a small, self‑contained UI component.
Don’t let the AI own the whole architecture – extract core logic into reusable, testable modules.
Iterate with prompts – non‑technical, high‑level prompts work great for styling and minor tweaks, but for complex behavior you’ll need to guide the AI toward better separation of concerns.
Treat generated code as a draft – always review, refactor, and add tests before shipping.

In the next posts I’ll dive deeper into the refactoring process, share the final architecture of the portal, and discuss how I’m using AI to keep the codebase healthy as the project grows. Stay tuned!

Source: …

使用状态和方法

将解题生成器拆分到单独的文件中。
为游戏按钮创建可复用的组件，并在所有游戏中使用它。

学习过程

开始阅读并真正理解生成的代码。
从基于浏览器的代码生成器切换到通用的 LLM 聊天。
向聊天询问我需要解决的问题的典型数据结构和算法方法。

实现

编写了自己的游戏逻辑和解题生成器实现。
意识到无法回避对自己所做事情的实际理解。
使用 LLM 聊天快速学习所需的数据结构和算法——无需阅读论文或大学教材。
利用 LLM 按照我的需求创建实现，并讨论替代方案。

SVG 渲染

关于用于渲染管道的 SVG，我看不到除了与 LLM 聊天紧密且迭代地合作来实现我想要的方式之外的其他选择。

关键要点与结论

使用 AI 辅助的编码工具既有趣，又能快速产生初步成果。它生成了一个可供真实用户测试的原型。
AI 代码生成器仍然存在局限性。
在 AI 失效的地方，我必须介入，这一点至关重要；我们共同重构并简化了代码。
使用另一个 AI 工具，我找到了一个 正确、可靠且可维护 的实现。

即使在 AI 代码生成器的时代，良好的工程实践——清晰的代码、测试自动化以及深思熟虑的架构——仍然重要，甚至可能比以往更为关键。

AI 可以帮助我（也可能帮助你）更快地编写代码，但只有凭借我的工程判断，我才能构建可维护、稳定且安全的软件。

我接下来应该写什么？

对于本系列的下一篇文章，我正在考虑深入探讨以下其中一个领域：

浏览器游戏的安全考虑
- 作弊、攻击、失控的云成本
低成本端到端架构
- 从 AI 生成的 React 代码到可部署、可维护的生产环境设置
符合隐私合规的用户分析
- 我如何在不向第三方共享用户数据的情况下衡量玩家行为
获取
- 在有限预算下，人们实际上是如何找到并开始玩这些游戏的

告诉我你觉得哪一个最有用！