Vibe Coding实战：从数据清洗到掌机查询工具的开发复盘

把624台掌机的资料整理成可检索的数据工具再用Vibe Coding的方式把它做出来这个过程最让我意外的地方是写代码本身只占了一小部分时间真正决定项目能不能走下去的反而在数据清洗和需求描述这两个环节。这篇笔记会从数据来源、字段设计、Vibe Coding 的使用方式、工具迭代过程一直拆到参赛复盘最后再讲一遍我踩过的坑。先说结论这种“个人数据工具”非常适合用 Vibe Coding 做因为功能边界清楚、数据量可控、反复修改成本低。但它并不是“输入一句话就自动出成品”的魔法你需要对数据有判断力也需要能说清楚到底要 AI 帮你做什么。1. 先搞清楚这个工具到底解决什么问题1.1 掌机数据查询是一个绕不开的麻烦场景掌机圈子里的型号非常杂。任天堂的 GB、GBA、NDS、3DS、Switch索尼的 PSP、PSVSteam Deck再加上各种国产开源掌机、寨机、怀旧掌机光是罗列出来就已经很乱更别提每个机型还有不同版本、不同内存组合、不同屏幕规格。如果你想在买掌机之前横向对比几款机器通常的做法是打开搜索页一个型号一个型号地查再在标签页里来回切。遇到评测文章里没有给参数你还要去官网翻规格表。做这件事一两次可以但要对比十几台甚至几十台效率就会变得非常低。把 624 台掌机的数据整理成一份可筛选、可搜索、可对比的工具之后这个问题就变成了一次操作选品牌、选价格区间、选内存结果列表马上出来。整个项目的核心价值不是“我有 624 台机器”而是“你能用极短的时间从 624 台机器里找到符合条件的那几台”。1.2 做工具的收益不只是省时间有人可能会问为什么不用 Excel 或者在线表格这个问题的答案是Excel 确实可以承载数据但体验不完整。表格需要自己处理筛选条件、需要考虑条件组合、对比两台机器时还要来回切换行。做成网页工具后交互更直观还能加入标签、卡片展示、多选对比这些表格里很难实现的功能也更容易分享给别人。另外这个项目对 Vibe Coding 的实践也有独立价值。它不是随手写一个 hello world而是真的用了一万多条整理后的字段数据在自然语言驱动下逐步迭代出一个能用的界面。你可以在里面看到一次真实的 AI 协作过程哪些需求 AI 一次能理解哪些需求需要拆成多轮对话哪些地方 AI 生成的代码明显需要人来判断。2. 624 台掌机的数据是怎么整理出来的2.1 数据来源和采集原则这个项目的数据来源主要是厂商公开规格页、电商详情页、评测文章、玩家社区的参数整理帖。没有使用任何私有数据也不需要账号登录。采集时我给自己定了几条原则参数以厂商页面为准评测和社区数据用于交叉验证。一台机器只保留一条记录存在不同版本时优先记录国内常见的版本。采集到的原始信息先存一份原档不做任何修改方便后面回溯。拿不准的字段宁可留空也不要随意填一个推测值。这里特别说下第二条。掌机圈子里经常有命名冲突。同一台机器可能叫“RG353M”“Retroid Pocket 3”“Anbernic RG353M”不同论坛的简称也不一样。如果不先在数据层做名字统一后面工具做得再漂亮搜索结果都是乱的。2.2 字段设计比想象中重要我最初想得比较简单以为只要记录“型号、品牌、价格”就够用了。结果在整理过程中发现不行。如果你的目标是“帮人选掌机”那至少需要这些字段字段含义示例说明品牌掌机品牌Nintendo / Sony / Anbernic建议用统一名称不要中文英文混用型号具体机型Steam Deck LCD这一列是搜索的主键发售年份首次发布年份2022用于按时间筛选处理器SoC 型号Intel Core i5-1240P不一定每台都能查到完整信息内存运行内存16GB LPDDR5注意统一单位存储机身存储512GB NVMe SSD有些机型还支持 TF 卡扩展屏幕尺寸对角线长度7.0 英寸保留 0.1 精度分辨率屏幕分辨率1280x800用于横向对比画质重量机身重量669g单位统一为克电池容量电池规格40Wh不是所有机器都有公开值参考价格当时常见价格区间2499-2999 元注意注明时间点系统平台运行系统SteamOS / Android / 定制 Linux影响软件生态备注其他信息支持底座、按键布局特殊给用户补充参考一开始我没设计“参考价格”这个字段后来发现少它完全不行。没有价格玩家根本没法在几十台机器里做初步筛选。价格有很强的时效性所以我记录时会同时标注一个采集时间范围避免误导。2.3 用 Python 脚本做一轮基础清洗数据采集阶段可以用表格工具手动维护但当数据条数变多之后我建议至少用脚本做一次清洗。下面是一个简化版的示例实际处理时字段会更多。import pandas as pd df pd.read_excel(handhelds_raw.xlsx) # 1. 去掉完全重复的行 df df.drop_duplicates(subset[brand, model]) # 2. 统一品牌名 brand_map { 任天堂: Nintendo, 索尼: Sony, NINTENDO: Nintendo, } df[brand] df[brand].replace(brand_map) # 3. 把价格列统一成字符串区间避免格式混乱 df[price_range] df[price_range].astype(str).str.strip() # 4. 内存单位统一为 GB def normalize_memory(val): if isinstance(val, str) and MB in val.upper(): return str(round(int(val.lower().replace(mb, )) / 1024, 1)) GB return val df[memory] df[memory].apply(normalize_memory) # 5. 删除关键字段全部缺失的行 df df.dropna(subset[model, brand, release_year]) df.to_excel(handhelds_clean.xlsx, indexFalse)这段代码不是重点。重点是你要形成一套“发现问题 - 写规则 - 修改数据”的小循环。比如第一遍清洗后我发现有些目录把 PSP 2000 和 PSP 3000 记成同一台所以要拿“型号”列逐条检查。这种工作没有任何捷径。2.4 清洗时的几个判断标准数据洗干净到什么程度才算合格我的标准是同一个品牌只有一种写法。同型号不会出现两条记录。价格字段能直接按“最低价-最高价”解析而不是夹着“大概”“左右”这些词。缺失字段不能影响核心筛选例如“屏幕尺寸”缺失没关系但“型号”不能有歧义。如果某些机器确实查不到官方存储组合比如多年前的二手掌机我会在备注里写明“资料缺失”而不是硬填一个“兼容值”。3. Vibe Coding 用在这个项目里到底是怎么一回事3.1 不要把 Vibe Coding 理解成“不用看代码”很多人第一次听到 Vibe Coding会以为是用 AI 生成代码然后自己什么都不用管直接拿成品。这个理解偏差比较大。Vibe Coding 的典型工作方式是用自然语言描述需求让 AI 生成代码然后由人来运行、检查、纠错。整个过程很像带一个执行力很强但不带业务理解的实习生你描述得越清楚它做得越准你一旦含糊它就开始自由发挥。在这个项目里我承担的并不是“编码员”角色而是“需求提出者 验收者”。我要时刻判断 AI 生成的代码是否满足需求数据量变大时会不会卡顿筛选逻辑是否覆盖了所有条件。AI 负责把手写代码的时间压缩掉但判断责任始终在你这边。3.2 适合 Vibe Coding 的任务特征不是所有项目都适合用 Vibe Coding 做。经过这次实践我总结出几个特征数据量在几万条以内纯前端可以处理不需要高并发后端。功能边界清楚核心是“搜索、筛选、查看详情、对比”不需要复杂权限系统。界面以信息展示为主不太涉及复杂动画和高度定制化交互。你可以接受一定程度的返工和调整因为 AI 的第一次输出大概率不完美。与之相对如果你要做的是支付系统、多租户平台、实时协作编辑器那 Vibe Coding 只能承担其中一小部分核心架构仍然需要人工设计。它是个人工具、原型验证、学习实验的好帮手不是所有项目的万能解。3.3 我使用的开发节奏这个项目的开发节奏可以总结为四步准备好清洗后的数据转成 JSON 文件。从最小的页面开始让 AI 生成一个能打开、能读取数据的页面。每提出一个新需求只改一个功能点跑通后再增加下一个。每轮都检查浏览器控制台和搜索结果不把多个问题混在一起修复。用这种节奏我在整个工具里一共迭代了六七个版本但每次改动都控制得很小。反而到了后期AI 生成的方向开始稳定需要的修改次数明显减少。4. 从零跑通这个工具每一步做了什么4.1 准备环境和数据我选择做一个纯前端工具。原因很简单数据量不大不需要服务端计算部署也省事。整份数据导出成 JSON 后大约不到一百 KB浏览器打开没有任何压力。环境只需要一个代码编辑器和一个浏览器。本地开发时我用一个简单的 HTTP 服务打开页面避免本地文件读取 JSON 时出现跨域问题。如果你不想配置本地服务也可以直接把 JSON 内嵌到 HTML 里。[ { brand: Steam, model: Steam Deck LCD, release_year: 2022, processor: AMD Van Gogh, memory: 16GB LPDDR5, storage: 64GB eMMC / 256GB NVMe / 512GB NVMe, screen_size: 7.0 英寸, resolution: 1280x800, weight: 669, battery: 40Wh, price_range: 2499-2999 元, system: SteamOS, note: LCD 版支持底座模式 } ]这里要注意JSON 字段名最好和清洗后的表格保持一致这样后续让 AI 写筛选逻辑时不容易出现“字段不存在”的报错。4.2 首版让 AI 先生成一个可浏览的页面框架我的第一条提示词没有提任何复杂功能只要求做一个单页面 HTML 工具使用上面的 JSON 数据文件数据展示所有掌机的基本信息包括品牌、型号、发售年份、屏幕尺寸、参考价格。页面风格偏简洁顶部留一个搜索框。这个需求足够让 AI 生成一个可以运行的页面框架。写完以后我先用浏览器打开确认数据有没有加载、列表显示是否正常。这里有一个很重要的经验首版不要加太多交互功能尤其不要一步到位加组合筛选。先把“数据能不能读出来”这个问题解决后面再逐步加搜索、加筛选、加对比每一步都有明确的验收方式。4.3 第二版加入搜索和基础筛选页面能展示之后我开始让 AI 加入筛选功能。这一版的需求是在搜索框输入关键词时可以匹配品牌、型号、处理器、系统几个字段页面增加品牌下拉框、发售年份区间选择器筛选条件可以叠加。这个阶段最容易出现的问题是筛选逻辑只写了“单条件生效”而不是“多条件同时生效”。我在实测时发现选了一台 Switch 之后再选年份列表没有同步收缩。原因是 AI 生成的代码里一个个筛选条件是互斥的没有做条件叠加。处理方式不是让 AI 从头重写而是明确告诉它现在筛选逻辑没有叠加例如选好品牌之后再选年份应该只在品牌结果里继续过滤。请改成所有条件都参与过滤。改完之后我先手动构造几个组合条件测试确认结果符合预期才开始下一版。4.4 第三版加入卡片布局和标签纯列表虽然能用但可读性很差。大批量数据往下滚动时眼睛很难快速寻找差异。这版我让 AI 改成卡片展示每张卡片包含型号、品牌、发布时间、参考价格和一个“查看详情”按钮。给 AI 的提示词是把列表改成卡片网格布局。每张卡片显示型号、品牌、发售年份、价格。如果屏幕尺寸或系统平台有值也在卡片上显示。卡片可以点击展开更多参数。这里 AI 通常会出现一个常见问题卡片信息不完整只显示了它觉得好看的信息而不是数据里全部字段。我后来要求它在详情区域把 CPU、内存、存储、屏幕、分辨率、重量、电池、系统、备注全部列出字段缺失时显示“暂无数据”。4.5 第四版加入多选对比掌机数据工具最有价值的地方不是看单台参数而是同时对比两台或者三台机器。所以我加了一个对比功能。需求是说在每张卡片上增加一个复选框最多选择 3 台掌机进行对比。页面底部固定一个“对比”按钮点击后在新区域展示选中机器的主要参数不同点用颜色标记。AI 在实现这个功能时出现过两次问题第一没有限制最多选择 3 台导致用户可以无限勾选第二对比区域的数据没有实时同步选择变化后旧对比仍然存在。这些其实不是硬伤通过简单修改就能修好。你只需要有耐心把需求描述完整并在验收时把边界条件都测一遍。4.6 每个版本的验收标准版本核心功能验收标准第一版页面框架 数据展示页面可打开JSON 能正常加载第二版搜索 品牌筛选 年份筛选多条件叠加过滤正确第三版卡片布局 详情展示字段完整缺失值有提示第四版多选对比最多选 3 台对比区域实时更新第五版排序 标签按年份/价格排序正确第六版部署上线静态资源可在服务器访问每一个版本都按照“先单条验证再批量验证”的方式检查。宁可每轮多做一遍整体测试也不要攒一堆功能最后一次性调试否则你根本不知道哪里开始坏的。5. 实测中的性能、资源和坑点5.1 624 条数据在前端毫无压力这个数据规模对于浏览器来说非常小。页面加载时 JSON 只有几十 KB不需要懒加载不需要分页。搜索操作是在内存中直接过滤的输入关键词后结果基本是即时返回没有任何可感知的卡顿。如果你要把同样的工具扩展到几万条数据那就要考虑引入搜索索引或者服务端查询。不过我这次的项目场景624 台掌机的体量下纯前端方案是最省事的选择。5.2 常见卡点整个迭代过程中我遇到的主要问题有几类编码问题JSON 文件没有保存为 UTF-8 时中文显示乱码。字段名不一致AI 生成代码时用了cpu去取processor字段结果很多卡片显示“暂无数据”。筛选逻辑不叠加多个筛选条件之间是互相覆盖的不是同时生效。排序类型错误价格字段被当成字符串排序导致按从低到高排序时出现“1000元”排在“2000元”后面。AI 自由发挥我要求保留原始厂商名结果 AI 自己映射成了缩写比如把 Nintendo 改写成 Nint。这些问题没有一个是难到无法解决的但它们都指向同一个核心点必须自己看数据、看输出、看控制台不能盲目相信 AI 给的结果。5.3 排查顺序如果页面出现异常我一般按这个顺序排查打开浏览器控制台先看有没有红色报错。确认 JSON 是否加载成功可以在控制台执行 fetch 或者查看 Network 面板。检查字段名是否和 JSON 里的 key 完全一致注意大小写和拼写。检查筛选逻辑是不是用了“重新过滤”而不是在当前结果里继续过滤。检查是否有多个筛选条件互相覆盖打印出临时结果帮助判断。最后再看 UI 层是不是样式遮挡、布局溢出、事件绑定没生效。这个顺序可以覆盖大多数个人数据工具的问题。不要一上来就怀疑 AI 能力不行多数情况下是输入数据或者需求描述不完整。6. 一次公开赛级复盘的几个启示6.1 比赛看的不是功能列表参加过公开赛之后我对“作品价值”的理解有了变化。比赛评审不会只盯着你做了多少功能而是看你有没有解决一个真实问题、数据是否可靠、演示是否顺畅。这个掌机数据工具在功能上并不复杂但它有一个明显优势数据量大、来源真实、覆盖型号多。当我在演示中筛选“预算 3000 元以内、屏幕 6 英寸以上、可以玩掌机游戏”列表瞬间缩小到少数几台机器时观众能直观感受到数据整理的价值。这就引出一个很重要的经验Vibe Coding 能帮你快速写出页面代码但“数据本身是否值得展示”这件事仍然需要人为投入。我在清洗数据上花的时间远远多于和 AI 对话的时间但正是这部分时间让工具变得可信。6.2 Vibe Coding 的边界通过这个项目我意识到 Vibe Coding 适合做“个人工具”和“原型验证”但它不解决业务设计的复杂度。举例来说AI 可以很快生成品牌筛选下拉框但它不会主动告诉你某些品牌在掌机圈子里有交叉定位比如“开源掌机”品牌下有很多小厂机型只按品牌筛选会让用户陷入选择困难。这些产品理解需要你自己补充。所以我更愿意把 Vibe Coding 理解成“能快速把想法变成代码的协作方式”而不是“自动完成产品设计的黑盒”。在这个项目里AI 帮我节省了大量编码时间但掌机数据的字段设计、用户场景、展示优先级都是我在清洗数据时一点点想清楚的。6.3 后续可以继续加什么工具做出第一版之后我的计划是继续扩展把筛选结果做成可视化图表比如品牌占比、发售年份分布。加入一个“推荐位”区根据价格和内存做简单匹配。支持导出对比图方便分享到社区。把数据表格增加到掌机之外比如家用机、掌机配件。这些功能的本质都是把数据工具推向更完整的决策场景。Vibe Coding 可以帮助快速实现这些扩展但前提是底层数据仍然保持干净。7. 如果你也想做类似工具我的建议7.1 先做数据再想功能很多人拿到一个想法之后第一反应是让 AI 写页面数据后面再补。这个顺序很容易出问题。没有数据可用的页面你没法验证真实筛选效果AI 也只能拿假数据演示给你看。我建议先把数据表整理到“能查、不矛盾、没有明显缺失”的程度再开始做界面。这个工作可能不有趣但它决定了工具上线后用户第一眼看到什么。7.2 第一次对话尽量具体给 AI 的需求越具体出来的结果越接近你想要的样子。比如不要只说“做一个掌机查询页面”而是说页面顶部是搜索框和筛选区下面是卡片网格。每张卡片显示品牌、型号、参考价格和发布年份。点击卡片可以展开完整参数。数据从 handhelds.json 中读取。少让 AI 猜它就少出错。即使你的描述看起来像流水账也比让它自由发挥更高效。7.3 不要一开始就上框架我见过一些人做个人工具时第一反应就是引入 Vue 或者 React。这个项目里我使用原生 HTML JS 就能完成所有功能不需要打包工具、不需要构建步骤本地打开就能调试。等你觉得维护成本变高了再考虑换框架不要为了“技术含量”提前增加复杂度。7.4 留好原始数据清洗后的数据可以直接用于工具但原始采集数据也要单独保留。当你发现清洗规则有误或者想增加一个字段时原始数据就是你的备份。没有备份你可能要从零开始重新采集几小时。我一般会在项目目录下建三个文件夹raw放原始采集文件、clean放清洗后的数据、output放最终导出的 JSON。每次清洗脚本都保留方便追查数据是怎么变成现在这个样子的。7.5 用小样例验证每一步在让 AI 生成完整功能之前可以先喂给它三条数据让它把逻辑跑通。你确认三条数据没问题后再把 624 条真实数据放进去。这样可以避免被一堆数据里的个别脏值干扰也能更快看到问题。如果你也想做类似工具我最大的建议是先花时间把数据整理到能看、能查、不矛盾的程度再坐下来打开 AI 对话窗口。功能可以慢慢加但数据基础不牢固后面所有功能都会摇摇晃晃。Vibe Coding 确实让个人开发的效率上升了不少但前提仍然是你愿意当那个判断对错的人。