Vibe Coding实战：用AI打造624台掌机数据检索工具

这次我们来看一个很典型的 Vibe Coding 实践项目：作者整理了 624 台掌机的数据，借助 AI 辅助编码，最终做成了一个可以搜索、筛选、详情查看的掌机数据工具。这正好也是 B 站 AI 创造公开赛的一个参赛作品。

这个项目本身并不复杂，但它把 Vibe Coding 的一条完整链路跑通了：数据收集 → 结构化整理 → 用自然语言让 AI 生成代码 → 反复测试和迭代 → 得到一个能用的工具。对于想尝试 Vibe Coding、但又不知道拿什么练手的人来说，这种“数据查询类工具”几乎是性价比最高的起点。

下面我会从数据字段设计、提示词怎么写、页面怎么迭代、测试怎么验证、后边还能怎么扩展这几个角度，把这个项目拆开讲一遍。如果你也想复刻一个类似的掌机数据库、游戏库或者任何“搜索型工具”，这套流程可以直接套用。

1. 核心能力速览

先把这个工具的大致面貌说清楚。

从材料看，这个项目更偏前端工具向，重点是把数据结构化并展示出来。对于读者来说，最值得关注的是两点：一是 624 条数据是怎么整理成一个可用产品的，二是 Vibe Coding 的提示词迭代过程到底是怎么发生的。

2. Vibe Coding 为什么会适合这类项目

Vibe Coding 并不是一个严格的编程框架，而是一种工作方式：你负责描述需求和设计数据结构，AI 负责生成、修改、调试代码。它的核心是人与模型的持续对话，而不是一次性让 AI 写出所有东西。

掌机数据工具恰好非常适合这种开发方式，原因有三点。

第一，需求边界清晰。这个工具要解决的问题就是“从 624 台掌机里快速找到我想要的机器，并且能看参数、做对比”。搜索、筛选、详情展示，这些功能逻辑简单，AI 生成的代码通常不会因为业务规则复杂而失控。

第二，数据是结构化资产。掌机参数（品牌、年份、CPU、内存、屏幕分辨率、重量、售价、电池等）天然适合用 CSV 或 JSON 表达。数据本身不依赖模型推理，AI 只需要处理展示逻辑，不需要处理复杂的业务状态。

第三，迭代成本极低。如果工具的每个功能都从零手写，至少需要半天。但用 Vibe Coding，大多数情况下的流程是：写一句“帮我在页面右侧加一个详情面板，点击列表项时展示对应掌机的完整参数”，等几秒，刷新页面，发现问题，再补一句“详情面板里的图片链接如果为空，就显示一个占位图”。这个过程可以持续循环，直到满意。

当然，Vibe Coding 也有适用边界。如果项目涉及复杂状态管理、高并发后端、大量权限控制，AI 生成的代码很可能需要人工大面积重写。但掌机数据工具这种查询展示类项目，AI 的完成度可以做到很高。

3. 数据准备：624 台掌机的结构化过程

动手让 AI 写代码之前，必须先把数据整理好。数据是 Vibe Coding 项目的燃料，数据结构越干净，AI 生成的页面逻辑就越省心。

3.1 数据来源与清洗

掌机数据的收集通常来自公开资料、产品规格页、游戏机评测文章、玩家社区整理帖等。624 台这个规模，意味着不只有主流掌机，还包含了大量的改款、限定版、第三方兼容机型，以及不同地区的型号变体。

收集到的原始数据往往很乱：同一款机器在 A 网站叫“Game Boy”，在 B 网站叫“GB”；重量有的写克，有的写千克；屏幕尺寸有的是英寸，有的只有分辨率。面对这种情况，第一件事是统一字段规范，而不是直接扔给 AI。

常见的字段至少应该包括：

清洗时要处理的主要问题包括：

• 统一单位。重量统一为克，屏幕统一为英寸，价格统一为首发当地货币。
• 处理缺失值。早期掌机的很多硬件参数至今没有官方确认，缺失就留空，不要在页面里硬填 0。
• 不同地区版本去重或保留。如果日版和美版硬件不同，建议保留为多条记录，方便对比；如果只是包装不同，可以在 tags 里标注。
• 图片链接的版权。如果图片来自公开网络，要注意引用来源或使用占位图，避免版权风险。

3.2 JSON 数据示例

工具层面对 624 条数据最友好的格式是 JSON。下面是一段简化的数据结构示例，实际使用时字段可以按需补充：

[ { "id": "nintendo-ds-2004", "brand": "Nintendo", "model": "Nintendo DS", "release_year": 2004, "cpu": "ARM946E-S + ARM7TDMI", "memory": "4MB RAM", "screen_type": "双屏 TFT", "resolution": "256×192（单屏）", "weight": "275g", "media_type": "NDS 卡带 / GBA 卡带", "price": "149.99 美元", "battery": "约 6-10 小时", "image": "", "tags": ["双屏", "触控笔", "经典"] }, { "id": "sony-psp-1000-2004", "brand": "Sony", "model": "PSP-1000", "release_year": 2004, "cpu": "MIPS R4000", "memory": "32MB RAM", "screen_type": "4.3 英寸 TFT", "resolution": "480×272", "weight": "280g", "media_type": "UMD", "price": "249.99 美元", "battery": "约 4-6 小时", "image": "", "tags": ["UMD", "多媒体"] } ]

这份 JSON 建议直接放在项目目录下的data.json，前端通过 fetch 加载。如果担心本地直接把 HTML 文件拖到浏览器会跨域加载失败，就配合一个静态服务使用，后面会讲。

3.3 数据量评估

624 条记录，如果每条 JSON 平均 400 到 800 字节，整个文件大概在 0.5MB 到 1.5MB，完全可以直接放进浏览器加载。不需要引入数据库，也不需要后端。这是这个项目“门槛低”的另一个体现。

4. 用 Vibe Coding 搭建工具：环境与提示词

数据准备好之后，就进入 Vibe Coding 的核心环节：用自然语言让 AI 生成代码。

4.1 环境准备

工具本身的运行环境可以非常轻量。如果你选择纯 HTML + JavaScript 单页方案，只需要以下条件：

• 一个现代浏览器（Chrome/Edge/Firefox 均可）
• 一个文本编辑器
• 一个本地静态服务器（推荐，避免 fetch 本地 JSON 的跨域问题）
• 如果使用 Node.js，可以用npx serve或简单的 Python HTTP 服务

# 方法一：Python 静态服务 cd your-project-directory python -m http.server 8080

# 方法二：Node 静态服务 npx serve -l 8080 .

如果你想让 AI 生成一个 React 版本，那还需要 Node.js 环境和包管理器。但对于 624 条数据的展示，纯原生 JavaScript 完全够用，也更适合让 AI 去生成。

4.2 初始提示词：生成基础页面

用 Vibe Coding 时，第一轮提示词不要一次提太多需求。先把骨架搭出来，之后逐步补功能。一个合理的初始提示词是：

请帮我写一个掌机数据检索工具的单页 HTML 文件。 数据从 data.json 文件加载。 页面左侧是掌机列表，显示型号名称和发布年份； 页面顶部有一个搜索框，可以按关键词过滤列表； 点击列表中的某一项后，右侧显示该掌机的完整参数详情。 请使用简洁的现代 CSS 样式，支持中文界面。

这个过程不需要你亲自写代码，但你要能看懂 AI 生成的代码结构。第一版生成后，直接在浏览器打开，确认以下基本功能：

• 页面能正常加载数据
• 列表能显示出来
• 搜索框输入文字时可以过滤
• 点击列表项时详情面板有内容

如果某一项没生效，直接把现象扔给 AI，让它修复。例如：

点击列表项时详情面板没有更新，控制台没有报错。请检查事件绑定和数据传递逻辑。

4.3 迭代提示词：增加字段筛选

基础页面跑通后，再逐步增加筛选能力。常见做法是在顶部加一排下拉框，让用户按品牌、发布年代、有无某项硬件规格来筛选。

在搜索框下方增加筛选条件区域： 1. 品牌下拉框，选项从数据中自动提取，不要写死。 2. 发布年代范围输入，可以填起始年和结束年。 3. 筛选条件要和搜索关键词叠加生效。 4. 当筛选结果为空时，页面显示“没有符合条件的掌机”。

这一轮的关键是“选项从数据中自动提取”。这样可以避免以后数据更新时，下拉框里出现过期品牌。

4.4 迭代提示词：对比模式

单台掌机的详情看多了，用户自然想对比两台机器。这个功能和 624 条数据结合后，价值会明显提升。

增加对比功能： 1. 列表项上有复选框，用户可以勾选 2 到 3 台掌机。 2. 页面底部显示一个对比区，用表格横向对比参数。 3. 参数缺失时显示“—”。 4. 如果勾选超过 3 台，提示用户最多只能对比 3 台。

对比模式是比较容易暴露 AI 逻辑缺陷的地方，例如：多选时重复点击同一台机器、数据结构字段不一致导致表格错位、数量上限判断放错位置等。每一轮出现问题，就补一条修复提示。

4.5 AI 生成代码的使用方式

这里要特别提醒一点：Vibe Coding 不是“AI 写完就能跑”。实际迭代过程中，很多问题出在数据格式和页面逻辑的匹配上。

例如 AI 生成的代码可能默认data.json里没有tags字段，而你实际数据里有；或者它假设所有机型都有price，但某些古董掌机的首发价格已经无处考证。这些情况下，最好的做法是让 AI 也读一遍数据文件和当前代码：

请先查看 data.json 中的字段结构，再对照当前 index.html 的实现， 找出哪些地方依赖了可能缺失的字段，统一改成安全判断。

这个提示词能大幅提升 AI 生成代码的健壮性。

5. 功能测试与效果验证

工具做完后，不能只点几下就认为没问题。测试的核心目的，是验证搜索、筛选、详情、对比四条链路在 624 条数据上都能稳定工作。

5.1 功能测试用例

这些测试用例可以手动执行，也可以让 AI 帮你生成一个测试清单。但不要依赖 AI 自动测试全部功能，因为这一类工具的运行结果需要真实数据验证。

5.2 AI 生成代码的常见失败模式

测试时你会遇到一些重复出现的问题，这里列几个高频项：

• 事件绑定丢失。列表重新渲染后，点击事件没有重新挂载，导致点击无效。修复方式：优先建议 AI 使用事件委托。
• 筛选逻辑取反。多项筛选叠加时，条件判断写成了“或”关系，导致筛选结果过多。
• 数据字段大小写不一致。数据里是release_year，代码里写成releaseYear，搜索和展示会一起错乱。
• 中文输入法兼容问题。搜索框在输入拼音时频繁触发过滤，导致中文搜索体验差。修复方式：设置输入防抖，或者等待compositionend事件后再过滤。

如果说 Vibe Coding 解决了“从无到有”的问题，那测试环节解决的就是“从有到稳”的问题。这一步不能省。

6. 接口 API 与批量扩展

虽然纯前端版本已经可以用，但如果你希望把 624 台掌机的数据开放给其他应用，或者以后接入语音助手、聊天机器人，那就需要把数据层抽出来，做成一个小接口服务。

6.1 轻量 API 服务设计

推荐使用 Node.js + Express 或 Python + FastAPI，数据文件仍然沿用一个 JSON。服务启动后暴露几个基础接口：

• GET /api/consoles：返回全部掌机列表，支持search、brand参数。
• GET /api/consoles/:id：返回单台掌机详情。
• GET /api/brands：返回品牌列表。

6.2 Python 接口示例

用 FastAPI 写一个最小接口非常快。下面是一个通用模板，实际使用时需要把data.json的路径替换成你本机的位置：

import json from fastapi import FastAPI, Query from fastapi.middleware.cors import CORSMiddleware app = FastAPI() app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"], ) with open("./data.json", encoding="utf-8") as f: consoles = json.load(f) @app.get("/api/consoles") def get_consoles( search: str = "", brand: str = "", ): result = consoles if search: result = [ item for item in result if search.lower() in json.dumps(item, ensure_ascii=False).lower() ] if brand: result = [item for item in result if item.get("brand") == brand] return {"total": len(result), "items": result} @app.get("/api/consoles/{console_id}") def get_console(console_id: str): for item in consoles: if item.get("id") == console_id: return item return {"error": "not found"}

启动命令：

pip install fastapi uvicorn uvicorn main:app --host 127.0.0.1 --port 8000

启动后访问http://127.0.0.1:8000/api/consoles?search=PSP就可以验证接口效果。

6.3 批量导入与数据更新

624 条数据不会只维护一次。后续你会不断补充新机型、修正参数，所以最好保留一份 CSV 作为“源数据”，每次通过脚本转成 JSON，再让页面或接口读取。

现代 CSV 转 JSON 的脚本同样可以让 AI 生成：

帮我写一个 Python 脚本，读取 consoles.csv，字段包含 id,brand,model,release_year,cpu,memory,screen_size,resolution,weight,media_type,price,battery,tags, 输出为 data.json。要求： - 空值保留为 null 或空字符串，不要删除整行。 - release_year 转成数字，无法转换的保持为空。 - tags 列如果有多个值，用竖线 | 分隔，输出时转成数组。

这样可以保证“更新数据”这个重复动作成本非常低。以后新增一台掌机，只需要在 CSV 里加一行，再运行一次脚本。

7. 资源占用与性能观察

这个项目不涉及 GPU、显存等重度资源，但作为前端工具，仍然要关注加载性能、内存占用和交互流畅度。

7.1 加载时间观察

在浏览器 DevTools 的 Network 面板中，重点看两个时间：数据文件的下载时间和页面的解析渲染时间。

624 条 JSON 数据通常只有几百 KB，理论上在本地网络环境是瞬时加载。如果你发现加载变慢，优先检查是不是页面里存在没有压缩的高清掌机图片。图片建议统一走外链，并且加上尺寸压缩，避免一次性加载几十张大图。

7.2 列表渲染性能

如果一次性把 624 条数据全部渲染成 DOM，浏览器虽然不会卡死，但在低性能设备上滚动时可能出现明显掉帧。解决方案有两种：

一是分页。每页显示 20 条或 50 条，底部用“加载更多”。

二是虚拟滚动。只渲染窗口里可见的十几条数据，滚动时动态替换。这个方案更适合掌机列表这种高度一致的长列表。

当你在提示词里要求 AI 优化性能时，可以这样写：

当前列表一次性渲染 600 多条数据，滚动卡顿。 请改成只渲染可见区域的数据，其他项在滚动时动态创建。 不要引入大型框架，保持原生 JavaScript 或者轻量实现。

这类优化提示词对 AI 来说并不难，但因为涉及滚动高度计算，容易出现边界问题，需要重点回归测试列表底部和详情点击。

7.3 显存与内存：不需要担心

和 AI 图像生成、本地大模型部署不同，这个掌机工具没有模型推理环节，也没有显存占用需求。你只需要关心浏览器内存。打开任务管理器，观察浏览器进程的占用，正常情况下一个纯数据页面不会超过几百 MB。如果你发现内存异常上涨，大概率是某个循环在重复构造大对象，而不是数据本身的问题。

8. 常见问题与排查方法

这类 Vibe Coding 项目会碰到很多琐碎问题。这里按实际开发中常见的现象整理了一份排查表。

这些排查步骤大多数不需要特别深厚的编程经验，关键是“让 AI 先看数据文件，再看控制台报错，再改代码”这个循环要做熟练。

9. 最佳实践与使用建议

从这次掌机数据工具中，可以提炼出几个适合后续项目复用的经验。

9.1 提示词拆解比一次完成更重要

不要在第一轮就把所有功能都塞给 AI。更好的方式是：先让 AI 生成一个能运行的骨架，再逐步增加搜索、筛选、详情、对比、优化。每一轮只解决一个主要问题，你会更容易定位哪一次改动引入了 bug。

9.2 数据、样式、逻辑分层管理

即使是一个纯前端工具，也建议把数据文件data.json、样式文件style.css、逻辑文件app.js分开。这样 AI 在修改样式时不会不小心破坏数据逻辑，修改逻辑时也不会影响布局。文件分离是低成本、高收益的做法。

9.3 一定要用 Git 维护版本

Vibe Coding 的迭代速度快，但 AI 可能在某次修改后把原本正常的代码改坏。如果每一步都提交到 Git，你在测试时发现回归，可以直接回滚，然后精确告诉 AI“从 2 小时前那个版本开始，新增对比功能，但不要改动搜索逻辑”。这个工作流能省下大量时间。

9.4 数据版权与合规

掌机的型号名称、logo、官方图片、参数数据，都可能涉及商标权、著作权或第三方网站的使用条款。个人学习研究用途问题不大，但如果你的工具要公开发布、参与比赛或商业化，最好：

• 照片统一使用自己拍摄的实机图，或者使用无版权占位图。
• 参数数据标注来源。
• 不使用掌机品牌 logo 作为页面装饰性主体元素。
• 如果涉及用户上传图片，必须增加审核和举报机制。

在 B 站 AI 创造公开赛这类场景下，除了工具的可玩性，评委通常也会关注素材来源的合规性，这一点不能回避。

9.5 第一次先小范围测试

624 台掌机的数据量虽然不大，但你在让 AI 开发对比功能前，可以先只保留 20 台数据，跑通代码逻辑后再恢复完整数据。这样调试速度快，页面报错也更直观。

10. 总结与下一步

这个项目的价值不在代码量，而在于它用 Vibe Coding 完成了一个真实可用的数据工具，并且整个开发链路清晰、可复制。如果你想尝试 Vibe Coding，拿这种“搜索 + 筛选 + 详情”的工具练手是很好的起点。

最先要验证的功能是搜索和详情面板，因为这两步决定了数据能不能被正常消费。最容易踩的坑是 JSON 加载跨域、字段大小写不一致、事件绑定失效，这三类问题会占用你大量调试时间。但只要你有足够耐心，让 AI 反复看数据、看报错、改逻辑，最终都能跑通。

后续可以扩展的方向也有不少：可以继续补充更详细的掌机图片，可以加入用户收藏和评分，可以做一个型号对比的分享链接，也可以把接口接进聊天机器人，让用户用自然语言问“帮我找一台 2005 年左右的索尼掌机”。无论往哪个方向走，底层那 624 台掌机的结构化数据，都是这个工具最有价值的部分。