【生活娱乐】闲卡宝 — 让闲置会员卡流动起来
赛道： 生活娱乐
作品形态： Web 应用（已部署上线）
开发工具： TRAE Work
一、自己介绍
大家好，我是技术出身，但常年没有亲身写代码了。
今年暑假带小孩去游泳，发现团购价格也不低，去一次肉疼一次。后来偶然加入了一个微信游泳爱好者群，群里有人转让闲置的次卡，买来一用——性价比超高，同样的泳池，花不了几个钱就能游一次。
那一刻我就在想：这件事不该只发生在一个微信群里。
正好这段时间在用 TRAE，发现它把开发和部署的门槛拉得很低——不用搭环境、不用翻文档，跟 AI 聊着聊着，代码就出来了。我就试着把"让闲置卡流动起来"这个想法，用对话的方式一点点做成了产品。
全程基本是聊天完成的，从产品方案到前后端代码，再到部署上线，没写几行手敲代码。说实话，不得不佩服现在的 AI——一个多年没碰代码的人，靠一轮轮对话，硬是把一个完整的产品从零做到了上线。
性格标签：技术出身但多年未实操的产品人，被 TRAE 重新拉回开发的"Vibe Coding 选手"。
二、产品简介（复赛版）
是什么
闲卡宝是一款闲置会员卡共享平台，连接"有闲置次数的卡主"和"有单次需求的消费者"，让会员卡像共享单车一样随取随用。平台只做信息撮合，不抽佣、不碰钱。
面向谁
- 卡主侧： 办了游泳卡、健身卡、美食卡、儿童乐园卡、美容卡但用不完的年轻白领、学生、家庭主妇
- 消费者侧： 有偶尔性需求、不想被长期卡绑定的都市人群
- 典型场景： 夏天想游一次泳但不想办年卡；搬家后美容卡用不了想低价转出；孩子长大了儿童乐园卡闲置
完整功能与用户使用路径
用户端核心功能：
| 功能模块 | 说明 |
|---|---|
| 首页（场馆列表 + 筛选） | 按品类筛选（游泳/健身/美食/儿童乐园/美容），支持搜索、发布时间排序、价格排序，场馆聚合展示 |
| 场馆详情页 | 查看该场馆下所有闲置卡券，支持品类筛选 |
| 卡券详情页 | 展示卡券完整信息（剩余次数、到期时间、可用分馆、使用规则、核销方式、交易保障），一键查看卡主联系方式 |
| 发布闲置卡 | 选场馆 → 填次数/价格 → 选核销方式 → 填补充说明 → 留联系方式，30秒完成 |
| 个人中心 | 我的发布、我的收藏、浏览历史、投诉建议、登录/注册 |
| 智能场馆匹配 | 输入场馆名自动补全，自动识别连锁分馆，避免同名不同写法导致聚合失效 |
| 过期自动清理 | 到期卡券自动标记过期，列表中不再展示，保持信息有效性 |
管理后台核心功能：
| 功能模块 | 说明 |
|---|---|
| 控制台概览 | 用户数、卡券数、待处理投诉、今日新增、各品类分布统计 |
| 投诉管理 | 投诉列表查看、处理状态流转（待处理→处理中→已解决/已驳回）、回复投诉人 |
| 发布管理 | 卡券列表查看、违规卡券下架 |
| 场馆管理 | 合并重复场馆、编辑场馆信息、下架无效场馆 |
| 用户管理 | 查看用户列表、封禁/解封、删除违规用户（软删除） |
| 管理员管理 | 超级管理员可添加普通管理员，支持按地区分配权限 |
| 城市管理 | 维护城市列表，支撑地区筛选 |
用户使用路径：
卡主路径：注册登录 → 点击发布 → 选择场馆（自动补全）→ 填写次数/价格/到期日期 →
选择核销方式 → 填写补充说明 → 留联系方式 → 发布成功
消费者路径：打开首页 → 按品类/搜索筛选 → 点击场馆查看闲置卡 →
点击卡片查看详情 → 查看联系方式 → 联系卡主 → 到店核销使用
管理员路径：登录后台 → 查看控制台概览 → 处理投诉/管理场馆/管理用户/管理卡券
相比初赛 Demo 的升级
初赛 Demo 是一个纯前端的 HTML 原型，所有数据存在 localStorage，没有后端、没有数据库、没有用户系统。复赛把它做成了一个真正能用的完整产品：
| 维度 | 初赛 Demo | 复赛完整作品 |
|---|---|---|
| 架构 | 纯前端 HTML，localStorage 存储 | 前后端分离，Node.js + Express + SQLite |
| 用户系统 | 无 | JWT 双 Token 认证（用户端 + 管理端独立） |
| 数据持久化 | localStorage，刷新即丢 | SQLite 数据库，数据永久存储 |
| API 接口 | 无 | 24 个 RESTful API，覆盖全部业务 |
| 管理后台 | 无 | 独立管理后台，7 大功能模块 |
| 部署状态 | 本地 HTML 文件 | 已部署上线腾讯云，评审可直接访问 |
| 品类覆盖 | 仅游泳 | 游泳、健身、美食、儿童乐园、美容 5 大品类 |
| 场馆管理 | 手动输入 | 自动补全 + 连锁分馆识别 + 场馆聚合 |
| 过期处理 | 无 | 到期自动清理，5 处查询自动过滤 |
| 管理员权限 | 无 | 超级管理员 + 普通管理员（按地区隔离数据） |
三、产品演示视频
1-5 分钟录屏，清晰展示产品完整核心流程与亮点
演示视频链接：https://www.bilibili.com/video/BV1PfMU6iE8n/
视频内容覆盖：
- 用户注册登录 → 首页浏览筛选
- 发布闲置卡券全流程（30秒发布）
- 卡券详情页 → 查看联系方式
- 管理后台登录 → 控制台 → 投诉处理 → 场馆管理
- 管理员按地区权限隔离演示
四、产品创作历程
灵感诞生
做闲卡宝的想法，来自今年暑假一个很日常的场景。
带小孩去游泳，团购价也不便宜，去一次肉疼一次。后来偶然加入了一个微信游泳爱好者群，群里有人转让闲置的次卡，买来一用——性价比超高，同样的泳池，花不了几个钱就能游一次。
那一刻我就在想：这件事不该只发生在一个微信群里。群里的卡是有限的，群外的人不知道，群里的人也找不到同城同场馆的卡。如果有一个专门的地方，让所有想转卡的人和想找卡的人都能看到彼此呢？
后来跟身边人聊，发现几乎人人都有类似的经历：健身年卡只去了 5 次、美食套餐还剩 3 顿没吃、孩子长大儿童乐园卡用不了了……一边花了钱用不完在发愁，一边想用又不想办卡在犹豫。这两拨人，其实只差一个相遇的机会。
初赛 Demo：验证想法
初赛阶段，我用 TRAE Work 快速做了一个纯前端 HTML 原型，验证"闲置卡共享"这个想法是否成立。核心只做了一件事：让卡主能发布闲置卡，让消费者能找到它。
Demo 跑通后，收到了不错的反馈，但也暴露了真实使用中的问题：
- 没有用户系统，谁发的卡、谁联系谁，都说不清
- 数据存在浏览器本地，换个设备就没了
- 没有管理后台，无法处理投诉和违规
- 场馆名称全靠手打，同一场馆不同写法导致聚合失效
复赛完整作品：从 Demo 到产品
复赛阶段，目标很明确：把它从一个"能演示的雏形"，打磨成一个"他人可真实上手使用"的成品。
整个过程说白了就是一个循环：我跟 TRAE Work 提要求 → TRAE Work 完工 → 我上手体验 → 发现问题再提要求 → 再迭代。N 多次循环下来，产品就从 Demo 变成了真正能用的东西。我这个多年没碰代码的人，全程靠对话驱动，没写几行手敲代码。
第一阶段：用户前端打磨
跟 TRAE Work 说想要什么样的筛选交互、什么样的发布流程，它来写代码。写完我本地跑一遍，体验不顺的地方截图反馈，它再调。首页双层筛选（分类标签 + 搜索/排序行）、场馆自动补全（连锁分馆识别）、发布表单分步校验、品类 SVG 图标统一风格、过期卡券自动清理……都是这么一轮轮磨出来的。
第二阶段：管理端打磨
跟 TRAE Work 说需要哪些管理功能，它独立开发了控制台、投诉管理、发布管理、场馆管理、用户管理、管理员管理、城市管理 7 大模块。管理员地区权限隔离也是我提的需求——北京管理员只看北京数据，它帮我实现了数据级别的过滤。管理后台与用户端完全独立，职责分明。
第三阶段：Demo 转化为产品
这个阶段就是纯粹的"体验→反馈→修复"循环，把初赛 Demo 从纯前端 localStorage 方案彻底转化为前后端分离的完整产品。后端用 Node.js + Express + SQLite 搭建，7 张核心数据表、24 个 RESTful API、JWT 双 Token 认证。场馆名不存在时发布报错、到期日期校验逻辑不对、删除用户后卡券没同步下架、管理后台登录页暴露默认账号……每一个都是我实际操作时撞到的，截图发给 TRAE Work，它来修。N 多次循环，直到每个流程都跑通。
第四阶段：部署上线
连发布都是傻瓜式的。我不知道怎么部署到服务器，TRAE Work 一步步手把手教：生成部署包、上传服务器、执行脚本，每个步骤都给了具体命令。遇到部署后没有测试数据，截图发过去，它创建了种子数据脚本帮我解决。从本地运行到远程发布，全程被 TRAE Work 牵着走，我这个技术出身但多年没实操的人，硬是把产品部署上线了。
五、TRAE 实践过程
这个产品从产品方案到前后端代码，再到部署上线，全部在 TRAE 中完成。
开发流程
1. 需求梳理与方案规划（TRAE Work）
在 TRAE Work 中描述闲卡宝的创意构想，AI 协助生成结构化的产品方案，包括目标用户画像、核心功能模块、交易流程设计、数据表结构规划。
2. 用户前端开发与打磨（TRAE Work）
跟 TRAE Work 说想要什么样的筛选交互、发布流程，它来写代码。写完我本地跑一遍，体验不顺的地方截图反馈，它再调。首页双层筛选、场馆自动补全、发布表单分步校验、品类 SVG 图标、过期卡券自动清理，都是一轮轮磨出来的。
3. 管理端开发与打磨（TRAE Work）
跟 TRAE Work 说需要哪些管理功能，它开发了控制台、投诉管理、发布管理、场馆管理、用户管理、管理员管理、城市管理 7 大模块。管理员地区权限隔离也是我提的需求，它帮我实现了数据级别的过滤。
4. Demo 转化为完整产品（TRAE Work）
把初赛 Demo 从纯前端 localStorage 方案彻底转化为前后端分离的完整产品。后端用 Node.js + Express + SQLite 搭建，7 张核心数据表、24 个 RESTful API、JWT 双 Token 认证。大量实际使用中的边缘问题，都是我截图反馈、TRAE Work 修复，N 多次循环直到跑通。
5. 部署上线（TRAE Work）
TRAE Work 一步步手把手教部署：生成部署包、上传服务器、执行脚本。遇到部署后无测试数据，它创建了种子数据脚本解决。
最令我惊讶的几点
说实话，整个过程有几件事让我这个"多年没碰代码的技术人"真正被震撼到：
1. 自动测试
我本以为开发完就完了，结果 TRAE Work 主动帮我对 24 个 API 接口做全量联调测试，自动跑通注册登录、卡券增删改查、场馆管理、投诉处理等全部流程，还把测试结果一份份列给我看。我不需要写一行测试代码，它自己就能验证自己的输出对不对。这比很多人类开发者还靠谱——写完不测就交付的太多了。
2. 潜在需求发现与实现
有好几次，我只是提了一个基本需求，TRAE Work 却主动想到了我没说出口的问题。比如我提到"删除用户"，它不仅实现了软删除，还主动把该用户名下所有 active 卡券同步设为 offline，保证数据一致性；我说要"过期卡券清理"，它不仅实现了自动标记过期，还在 5 处关键查询里都加了过期过滤条件。更让我惊喜的是部署环节，它主动用 PM2 做进程管理，还提醒我配置开机自启和日志监控，保证服务稳定性——这些我压根没想到，但它替我想到了。
3. 全程 TRAE Work，没碰一行代码
这是最不可思议的一点。从产品方案、前后端代码、数据库设计、联调测试到部署上线，全过程都在 TRAE Work 里通过对话完成，我没碰过一次代码编辑器，没手写过一行代码。我做的事情就是：提要求、看效果、截图反馈、再说下一步。一个多年没写代码的人，就这样靠一轮轮对话，把一个完整的产品从零做到了上线。放在以前，这是不可想象的。
开发关键步骤截图
以下为 TRAE 开发过程中的关键步骤截图（不少于 3 张）
截图 1：调整设计
截图 2：功能开发
截图 3：部署
截图 4：生成社区帖子
关键任务 Session ID
以下为 TRAE 开发过程中的关键 Session，双击 TRAE 对话头像即可复制
- Session 1： 2707443366496480:f9944ccc1b85ef03054656fe9d9d1af5_6a5440e4a55467975eaa41c9.6a5450c0a55467975eaa4345.6a5450c0a55467975eaa4343:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/13 10:43:12)
- Session 2：
2707443366496480:ca8ca02c89dbebc95bacf624b758fe25_6a5440e4a55467975eaa41c9.6a6ac246988438bfc401a2c8.6a6ac246988438bfc401a2c6:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/30 11:17:26) - Session 3：
2707443366496480:fd5b7ce31b48c32cde69746e3b8a85ed_6a5440e4a55467975eaa41c9.6a6b0cc6988438bfc401a6e4.6a6b0cc6988438bfc401a6e2:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/7/30 16:35:18) - Session 4：
2707443366496480:ffd479a8a613bc253e2bf17c944db026_6a5440e4a55467975eaa41c9.6a70421fcc007bb471a8a2f4.6a70421fcc007bb471a8a2f2:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/8/3 15:24:15) - Session 5（部署上线与种子数据）：
2707443366496480:6f6e95685e284ea7f9c5d0bbce7cf26e_6a5440e4a55467975eaa41c9.6a72f0a419f5990999e5ce8b.6a72f0a419f5990999e5ce89:TRAE Work CN.0.1.41.no_sid.no_ppe.T(2026/8/5 16:13:24)
六、技术方案分享
技术栈
| 层级 | 技术选型 | 选型理由 |
|---|---|---|
| 前端 | 原生 HTML/CSS/JavaScript | 无框架依赖，加载快，适合移动端 H5 场景 |
| 后端 | Node.js + Express | 轻量高效，前后端同语言，开发效率高 |
| 数据库 | SQLite（node:sqlite 内置模块） | 零外部数据库依赖，部署简单，适合轻量应用 |
| 认证 | JWT 双 Token 体系 | 用户端与管理端独立 Token，权限隔离清晰 |
| 部署 | 腾讯云轻量服务器 + PM2 | 一键部署脚本，PM2 进程管理保证服务稳定 |
关键实现思路
1. 场馆聚合模式
信息架构采用"场馆聚合"：首页展示场馆列表 → 点击场馆进入该场馆闲置卡列表 → 点击卡片进入卡券详情。这种模式让消费者能快速找到同城同场馆的闲置卡，解决了闲鱼等综合平台"搜索效率低"的问题。
2. 场馆自动补全与连锁分馆识别
发布卡券时，输入场馆名实时匹配已有场馆，下拉列表标注"连锁·N家分馆"。卡券支持两种分馆模式：['all']（全部通用）和指定分馆列表（仅限指定分馆使用）。这解决了"同一场馆不同写法导致聚合失效"的问题。
3. 管理员地区权限隔离
管理员表设计 role（super/admin）和 city 字段。普通管理员的全部查询（控制台概览、用户管理、场馆管理、卡券管理、投诉管理）都自动追加城市过滤条件，实现数据级别的权限隔离。
4. 过期卡券自动清理
每次 API 请求触发检查（每 10 分钟最多执行一次），将 expire_date < 今天 的 active 卡券标记为 expired。5 处关键查询（首页列表、详情页、我的发布、浏览历史、场馆详情卡券列表）均增加 expire_date >= date('now') 条件过滤。
5. 软删除与数据一致性
用户删除采用软删除（status = ‘deleted’），同时将该用户名下所有 active 卡券设为 offline。所有列表查询默认过滤 deleted 状态，保证数据一致性。
七、社会价值分析
闲卡宝的核心价值不在于商业模式，而在于减少浪费。
资源浪费是真实的： 预付费会员卡的闲置率高达 30% 以上，大量次数过期作废。每一张作废的卡背后，都是辛苦赚来的钱。
供需匹配是低效的： 卡主想出手闲置次数，消费者想找便宜卡，但双方找不到彼此，只能在微信群、闲鱼零散交易，效率低、信任成本高。
闲卡宝做的事情很简单：让这两拨人相遇。平台不抽佣、不碰钱，只做信息撮合——一个人回血，一个人省钱，一张卡用完它的每一次，才是对它最好的交代。
从更宏观的角度看，这是一种共享经济在本地生活场景的微型实践。不需要重型基础设施，不需要复杂的信用体系，场馆前台本身就是验证环节，本地生活场景天然有信任基础。
八、产品迭代规划
已完成（复赛交付）
- 用户端：注册登录、首页筛选、场馆聚合、卡券发布、卡券详情、收藏/浏览历史、投诉建议
- 管理后台：控制台、投诉管理、发布管理、场馆管理、用户管理、管理员管理（含地区权限）、城市管理
- 部署上线：腾讯云轻量服务器 + PM2 + 一键部署脚本
近期规划
- 消息通知： 卡券被收藏/咨询时通知卡主，提升交易撮合效率
- 信用体系： 基于交易历史和投诉记录建立用户信用分
- 多城市扩展： 支持更多城市，优化城市切换体验
- 更多卡类扩展： 除了现有的游泳、健身、美食、儿童乐园、美容五大品类，继续扩展洗车卡、理发卡、按摩卡、教培课程卡等其他本地生活卡券类型，覆盖更多闲置场景
长期愿景
从闲置卡共享起步，逐步扩展到更多本地生活会员卡品类，打造一个本地生活互助生态——卡主回血、消费者省钱、商家获得新客流量，三方共赢才是长久之道。
最后
做闲卡宝的初衷，不是要做一个多牛的平台。
只是觉得，那些被浪费的次数、过期作废的卡，背后都是辛苦赚来的钱。如果有个地方能让它们流动起来，让需要的人用上，让不需要的人回点血，这件事本身就有意义。
一张卡用完它的每一次，才是对它最好的交代。
一个人从零到上线，不是因为我很强，是因为工具够好。TRAE 让一个想法变成一个产品，中间只隔着一轮又一轮的对话。
闲卡宝 — 让"拥有"不再重要，"使用"才是核心。
完全由 TRAE 开发 | 已部署上线 | 复赛作品
说明： 产品体验入口、测试账号等已通过飞书问卷私密提交，未在社区帖中公开。