【标签】 生活娱乐
【标题】 【生活娱乐赛道】满电青年——电动车一站式综合服务平台
1. 先和大家打个招呼
你好，我是一名前端开发工程师，坐标长沙。
在这个项目之前，"满电青年"这个想法其实在我脑子里已经躺了两年了。两年前我在大学城的时候就萌生过做这样一个平台的念头，但当时面对用户端、商户端、管理后台三端同时开发的复杂度，个人的精力和能力确实不允许，只能把这个想法暂时搁置。
直到遇到 TRAE，事情开始变得不一样了。
初赛的时候，我用 TRAE 完成了从 0 到 1 的起步——从需求梳理、架构设计、规范文档到第一版代码生成，TRAE 帮我跨越了最艰难的起步阶段。但那个时候的产品更像一个"骨架"：核心功能有了，但离一个真正能用、好用的完整产品还有不小距离。
复赛阶段，我继续和 TRAE 并肩作战，把这个"骨架"一点点填上了肉。这一个多月里，我做了三大新模块、补了三大业务闭环、搭了一套运营体系、还做了一次架构升级。过程中经历了三轮冒烟测试、数十个版本迭代，产品终于从"能跑的 Demo"变成了"可用的成品"。
说个真实的数据：我是 TRAE IDE 使用超过 400 多天的用户了，从它早期的版本一路用到现在，亲眼见证了它一步一步变强。所以这次比赛，算是用老朋友的工具，做了一个新朋友的项目。
说实话，如果没有 TRAE，我可能依然无法启动这个项目；而如果没有 TRAE 持续的助力，我也不可能在一个多月的时间里把产品打磨到现在这个程度。
一句话定位： 满电青年是电动车后市场的「美团+贝壳」——用大学城场景做切入点，一边连接 3 亿电动车车主，一边连接百万线下维修店和车行，解决维修不透明、二手车无保障的行业痛点。
2. 产品简介（复赛版）
是什么
满电青年是国内首个聚焦大学城场景的电动车后市场服务平台，涵盖用户端 H5、商户端 H5、管理后台 Web 三端，核心解决维修不透明、二手车无保障、配件价格不透明三大行业痛点。
一个反常识的观察：电动车维修这个看起来又脏又累的生意，可能是本地生活最后一个还没有被互联网改造的千亿级赛道——全国 3 亿+ 电动车保有量，维修保养、配件、二手车交易加起来是一个千亿级的市场，但至今没有一个全国性的服务平台。
平台以维修报修为流量入口、二手车交易为高价值业务、发现社区为粘性引擎，形成"工具→交易→社区"的完整用户生命周期。
项目以大学城为切入点和首个试点场景，逐步向外拓展，最终服务于更广泛的电动车车主群体——包括通勤白领、外卖骑手、社区居民等。
简单说：你的电动车出了问题、想买车、想卖车、想找配件、想了解骑行知识——打开满电青年就够了。
核心业务闭环
满电青年不是功能的堆砌，而是三条完整的业务闭环：
维修服务闭环：一键报修 → 商户接单 → 在线报价 → 维修进度 → 完成评价 → 平台质保
二手车交易闭环：发布车辆 → 同城距离 → 下单支付 → 担保交易 → 确认收货 → 评价体系
社区内容闭环：浏览内容 → 发帖互动 → 关注用户 → 粘性留存 → 反向带动交易
面向谁
核心目标用户：广大电动车车主——项目以大学城学生群体为首个切入点和试点场景，逐步覆盖通勤白领、外卖骑手、社区居民等更广泛的电动车用户。
典型使用场景：
| 场景 | 用户行为 | 平台价值 |
|---|---|---|
| 路上车坏了 | 打开 App 一键报修，选故障、拍照片、等商户接单 | 快速找到靠谱维修店，价格透明 |
| 想买配件 | 逛配件商城，分类筛选，到店自提或快递 | 品类齐全，对比方便 |
| 想卖车 / 想买二手车 | 发布 / 浏览二手车，同城筛选，站内联系，线下面交 | 交易有保障，信息更对称 |
| 买新车凑团购 | 参加团购，凑人数享批量价 | 省钱省心 |
| 日常刷手机 | 逛"发现"看圈子、读用车攻略、问 AI 助手 | 从工具到生活方式，提升粘性 |
| 外卖骑手修车 | 高峰期车坏了，快速叫上门维修，减少误工损失 | 高效响应，保障收入 |
| 通勤族日常保养 | 预约保养、购买配件，一站式搞定 | 省时省力 |
另一侧用户：电动车商户（维修店、配件店、车行），平台为商户提供线上获客、订单管理、经营数据统计等能力。
完整功能清单
用户端（24+ 功能模块）
维修服务
- 一键报修：选择故障类型、描述问题、上传图片、选择商户
- 订单全流程：待接单 → 已接单 → 已报价 → 维修中 → 已完成 → 已评价
- 维修进度追踪：商户上传维修进度照片，实时可视化
- 上门服务：选择上门地址，预约时间，支持到店 / 上门两种模式
- 评价体系：完成后打分评价，建立商户信誉
配件商城
- 商品浏览：分类筛选、搜索、排序
- 商品详情：规格选择、图文详情、评价查看
- 购物车：加减数量、批量结算
- 订单管理：待付款 / 待发货 / 待收货 / 已完成
- 地址管理：增删改查、默认地址
- 支付流程：确认订单 → 选择地址 → 优惠券抵扣 → 支付
二手车交易
- 发布车辆：上传照片、填写车况、定价、定位
- 浏览筛选：品牌、价格、车龄、里程多维度筛选
- 同城距离：列表显示距离，支持距离排序、导航
- 收藏功能：感兴趣的车辆一键收藏
- 交易闭环：下单 → 支付 → 卖家确认交车 → 买家确认收货
- 买卖双角色：同一账号可同时发布和购买
团购活动
- 活动列表：进行中 / 即将开始 / 已结束
- 参团流程：选择规格 → 支付参团 → 等待成团
- 成团进度：实时显示参团人数和进度条
- 团购订单：参团后订单管理、收货地址、发货状态
发现模块（社区内容生态）
- 圈子（UGC）：用户发帖、点赞、评论、双列瀑布流
- 快捷入口：新鲜事 / 互助问答 / 骑行活动 / 好物推荐 / 改装分享
- 推荐（PGC + 精选）：官方动态、热门精选、附近商户推荐、二手车精选
- 用车（工具内容）：购车指南、维修教学、用车攻略
- 个人主页：我的帖子 / 我的点赞
小满 AI 智能助手
- 电动车领域专业问答：故障诊断、购买建议、保养知识、平台使用指引
- 流式输出打字机效果，多轮上下文对话
- 会话历史管理，左滑删除
- 服务稳定可靠，多机制保障高可用
同城化体系
- 城市选择器：2 级省 / 市选择，最近 5 城市快捷切换
- 自动 GPS 定位 + 手动选择 + 位置云端持久化
- 8 大列表同城过滤：商品 / 商户 / 二手车 / 团购 / 维修选商户 / 首页 3 区域 / 购物车结算 / 搜索
- 切换城市全局同步刷新
个人中心
- 资料编辑：头像、昵称
- 学生认证：上传学生证，审核通过享专属权益（大学城试点场景专属）
- 车辆管理：我的车辆增删改查
- 我的订单：维修 / 商品 / 二手车 / 团购统一入口
- 消息中心：系统通知 + 对话消息
- 优惠券：领券中心 + 我的优惠券
- 价格指南：维修价格参考，防止被宰
商户端（18+ 功能模块）
工作台
- 商户信息展示：店铺名称、头像、营业状态
- 快捷入口：订单管理、商品管理、团购管理、评价管理
- 待办事项：待接单 / 待发货 / 待回复 数量提醒
- 数据统计：总收入 / 订单数 / 客单价 / TOP5 商品
- 城市入口：同城切换 + 地址完善度提示
订单管理（统一入口）
- 维修订单：接单 / 拒单 / 报价 / 标记完成 / 上传进度照片
- 商品订单：待发货 / 已发货 / 已完成，发货操作
- 团购订单：参团订单查看、发货管理
- 二手车订单：卖家视角（待交付 / 已完成）+ 买家视角（待收货 / 已完成）双角色切换
- 上门服务：展示上门地址、预约时间、服务模式标签
商品管理
- 商品列表：上下架、编辑、删除
- 商品编辑：上传图片、设置价格库存、规格管理
- 分类管理
团购管理
- 团购活动创建和管理
- 参团订单查看和发货
二手车管理
- 发布车辆 / 编辑 / 上下架
- 卖出订单管理 + 买入订单管理
- 定位 + 距离排序
消息与评价
- 消息中心：订单通知 + 系统通知，标记已读
- 评价管理：查看用户评价、回复评价
店铺管理
- 店铺信息编辑：名称、头像、简介、营业时间
- 入驻地址：3 级级联地址 + 详细地址 + 一键定位
- 营业状态切换
管理后台（12+ 功能模块）
用户管理
- 用户列表 / 详情 / 禁用启用
- 学生认证审批：认证列表 / 详情 / 通过 / 驳回
商户管理
- 商户审核：入驻申请列表 / 详情 / 通过 / 驳回
- 商户列表：地区三级筛选（省 → 市 → 区）、禁用启用
- 商户详情
商品管理
- 商品列表 / 上下架 / 详情查看
- 违规商品下架
订单管理
- 维修订单管理
- 配件订单管理：查看、备注
- 二手车订单管理
二手车管理
- 车辆列表 / 审核 / 上下架
团购管理
- 团购活动审核
- 团购订单查看
内容管理
- 社区帖子管理：置顶 / 加精 / 删除 / 恢复
- 官方内容管理：创建 / 编辑 / 上下架 / 删除
- 评价管理：列表 / 详情 / 删除违规评价
- 公告管理
- 轮播图管理
运营工具
- 优惠券管理：平台优惠券创建 / 管理
- 维修价格指南：价格数据维护
数据统计
- KPI 卡片：核心指标概览
- ECharts 趋势图：收入趋势 / 用户增长 / 订单趋势
- 排行榜：商品销量排行 / 商户营收排行
- 支持按商户维度筛选
- CSV 数据导出
埋点统计
- 数据概览：总事件数 / 日活趋势 / 模块分布
- 埋点明细：多维度筛选（端 / 事件类型 / 时间 / 用户）
- 超级管理员专属权限
消息通知中心
- 铃铛提醒 + 消息面板
- 待审核事项聚合：认证 / 商户 / 订单 / 纠纷
系统管理
- 管理员账号管理：创建 / 启用禁用 / 重置密码
- 角色权限控制
相比初赛 Demo 的升级
初赛的满电青年是一个 “能跑的骨架” ——核心功能有了，但更像一个技术验证的 Demo。
复赛的满电青年是一个 “可用的成品” ——业务闭环完整、运营体系健全、用户体验打磨到位。
具体升级可以用「3+3+1+1+N」来概括：
三大新模块上线
| 新模块 | 价值 | 核心能力 |
|---|---|---|
| 发现模块 | 从工具型平台 → 生活方式平台 | 圈子 UGC + 推荐 PGC + 用车教程 三层 Tab，点赞评论发布全互动 |
| 小满 AI 助手 | 7×24 小时智能客服，降本增效 | 电动车领域专业问答，流式输出，高可用保障 |
| 同城化体系 | 天然本地生活服务的基础 | 23 项功能，城市选择 + GPS 定位 + 8 大列表同城过滤 + 云端持久化 |
三大业务闭环补齐
| 业务线 | 初赛状态 | 复赛状态 |
|---|---|---|
| 二手车交易 | 仅浏览 + 发布 | 完整交易闭环：发布 → 定位 → 距离 → 下单 → 支付 → 买卖双角色订单 → 确认收货 |
| 团购活动 | 仅展示活动 | 完整参团闭环：参团 → 支付 → 成团进度 → 商户发货 → 订单管理 |
| 配件商城 | 商品展示 + 购物车 | 完整交易闭环：地址管理 → 结算 → 优惠券 → 支付 → 订单 → 评价 |
一套运营体系建成
- 埋点统计系统：三端 60+ 埋点事件，管理后台数据看板（KPI + 趋势 + 排行 + 明细）
- 管理后台大扩充：从 5 个模块 → 12+ 个模块，具备正式运营能力
- 内容审核体系：社区帖子 + 官方内容 + 评价全链路审核
一次架构升级
- 云函数架构重构：43 个分散云函数 → 13 个业务服务 + 4 个独立函数，按业务域聚合，维护成本大幅下降
- 实时通信升级：从轮询 → WebSocket 实时推送，30 秒心跳 + 指数退避重连 + 降级轮询
- 统一权限校验：requireAuth / requireRole 分层校验体系
N 项体验优化
经过反复多轮冒烟测试和数十个版本迭代：
- 金额单位全链路统一（分 → 元转换修复）
- 分页加载机制修复（scroll-view 高度问题）
- 位置选择体验优化（直辖市穿透、刷新不回退）
- 消息对话体验优化（分页、头像回填）
- AI 对话体验优化（自动滚动、Markdown 清理、快捷问题）
- 搜索体验优化（安全正则、多 Tab 切换）
- 安全加固（禁用商户全链路过滤、权限校验统一）
3. 产品演示视频
- B站地址 https://www.bilibili.com/video/BV1SsuJ6FEjF/?pop_share=1&spm_id_from=333.40164.0.0&vd_source=84a41b84f229cde2c227c5153cf6a8a5
- 抖音地址 https://www.douyin.com/video/7670891285284130094
4. 产品创作历程
灵感起源：一个躺了两年的想法
这个想法诞生于我在长沙大学城的亲身经历。
大学城里电动车是最主流的代步工具之一，学生几乎人手一辆。但与之配套的服务却非常原始——维修靠路边摊、购车靠熟人介绍、配件靠万能的淘宝。整个体验割裂、低效，且充满了信息不对称。
其实不止是学生，外卖骑手、通勤白领、社区居民——只要是骑电动车的人，或多或少都遇到过类似的问题：车坏了找不到靠谱的店、换配件不知道价格合不合理、想买二手车又怕被坑。
我实地调研过很多用户和商户，收集到了非常真实的痛点：
对用户来说——维修难、价格不透明、二手车交易信任缺失。
对商户来说——获客难、效率低。
我和多家电动车店铺的老板进行过多次深入沟通，他们均表示这个平台会极大地提高店铺的用户粘性，同时增加营收机会。有老板甚至说：“如果有这个平台，我愿意第一个入驻。”
之所以选择从大学城切入，是因为大学城是一个天然的封闭市场——用户集中、需求明确、商户密度高，非常适合作为 MVP 的验证场景。一旦模式跑通，可以快速向外复制。
但两年前的我，面对三端同时开发的复杂度，只能把这个想法搁置。
初赛阶段：从 0 到 1 的跨越（TRAE Work + TRAE IDE）
遇到 TRAE 之后，事情开始变得不一样了。
第一阶段：从想法到蓝图（TRAE Work）
项目最开始的阶段，我用了很长时间和 TRAE Work 反复沟通需求。从最初一个模糊的"我想做一个电动车服务平台"，到一步步明确出用户端、商户端、管理后台三端的划分，再到 MVP 版本的功能取舍——每一轮对话都让项目的轮廓更加清晰。
TRAE 帮我完成了这些原本需要好几天甚至一周的工作：
- 架构设计：三端技术选型、20 个云函数的职责划分、15 个数据库集合的设计
- 规范文档：接口文档、错误码规范、云函数开发规范、命名规范
- UI 风格定义：极简清新风，主色 #4ECDC4，整套 CSS 变量和 BEM 命名规范
- 第一版代码：按需求生成的三端基础代码框架
第二阶段：从蓝图到 Demo（TRAE IDE + TRAE Work 协作）
代码生成后，我切换到 TRAE IDE 进行调试。逐页排查代码问题、修复兼容性和逻辑错误、优化交互细节。
TRAE IDE 的代码理解和定位能力让调试效率很高，遇到问题基本上能快速定位原因并给出修复方案。同时 TRAE Work 在补充新功能时，能保持与已有代码的一致性。
最终，初赛版本完成了核心功能骨架：维修报修、配件商城、二手车浏览、团购活动、商户入驻——产品的"形"有了。
复赛阶段：从 Demo 到成品的蜕变
初赛结束后，我马不停蹄地开始了复赛版本的迭代。这个阶段的核心目标很明确：把 Demo 做成真正能用的产品。
关键决策一：先补闭环，再加模块
复赛初期我面临一个选择：是先加新功能，还是先把现有功能的体验做好？
我的决策是：先补业务闭环，再加新模块。理由很简单——一个只有半条流程的功能，用户是用不起来的。
于是第一轮迭代（v0.2.x 系列）的重点是：
- 配件商城补齐结算、支付、订单全流程
- 二手车补齐交易闭环
- 维修订单补全评价体系
- 商户端补齐商品订单管理、评价回复、数据统计
- 管理后台补齐商品管理、订单管理、数据统计
这个阶段的工作量其实比想象中大——每一条业务线的闭环都涉及前后端联动、状态流转、异常处理。但 TRAE 帮了大忙：它能快速理解现有代码结构，生成的新代码和已有逻辑保持高度一致，大大减少了联调成本。
关键决策二：做"发现"模块，从工具到社区
核心闭环补齐后，我开始思考：用户用完就走，怎么提升粘性？
答案是做内容。于是有了发现模块。
但直接做 UGC 社区会面临冷启动困难——早期没有内容沉淀，用户来了就走。参考九号 App 的设计，我采用了三层 Tab 架构：圈子（UGC）+ 推荐（PGC + 精选）+ 用车（工具内容），让发现页同时承载用户互动、官方运营、专业教程三类内容。
这个设计的好处是：即使没有用户发帖，官方内容和用车教程也能撑起发现页的价值；随着用户内容增多，圈子 Tab 会越来越活跃，实现平滑冷启动。
关键决策三：接入 AI，打造"小满"智能助手
电动车用户有大量的咨询需求——故障排查、配件选购、保养知识。这些问题重复度高，如果全靠人工客服，成本会很高。
于是我决定做一个 AI 智能助手，取名**“小满”**——取自项目名"满电青年"的"满"，同时也是二十四节气之一，意为"物至于此小得盈满"，象征成长与收获。
接入过程中，TRAE 帮我快速完成了后端服务封装、流式输出处理、前端对话界面开发。印象最深的是 AI 对话的自动滚动逻辑——用户手动滚动时不自动滚到底，用户停留在底部时新消息自动滚动——这个交互细节 TRAE 一次就做对了。
关键决策四：同城化，本地生活服务的基石
满电青年是一个天然的本地生活服务平台——维修要到店、配件要到店、二手车要面交、团购要到店。但初赛版本有个致命问题：全国数据乱序显示，用户在长沙可能刷到北京的商户，完全无法履约。
于是我启动了同城化体系建设，分三层推进：
- 入口层：首页顶部加城市选择器，支持 GPS 自动定位 + 手动切换
- 过滤层：8 大列表全部按城市过滤，切换城市全局刷新
- 基础层：商户入驻强制填写 3 级地址，存量数据回填
整个同城化涉及 23 项功能改动，三端 + 5 个云函数服务都要改。这个复杂度如果放在以前，我可能要捋好几天的需求。但在 TRAE 的帮助下，从需求文档的撰写、到技术方案的设计、再到代码的分批实现，整个过程有条不紊。
关键决策五：云函数架构重构
随着功能越来越多，云函数的数量也从最初的 20 个膨胀到了 43 个。问题也随之而来：
- 冷启动频繁，响应慢
- 重复代码多，维护成本高
- 权限校验不统一，安全风险大
于是我做了一个重要决策：云函数合并——按业务域把 43 个云函数合并为 13 个业务服务 + 4 个独立函数。
合并的原则是：
- 按业务域聚合（用户域 / 商户域 / 订单域 / 商品域 / 内容域 / 管理域 / 系统域）
- 统一入口模板，统一权限校验（requireAuth / requireRole）
- 新旧 action 名双兼容（ACTION_ALIASES 别名映射），前端平滑切换
这次架构升级的效果很明显：云函数数量减少约 70%，冷启动频率大幅降低，代码复用率和安全性都有了质的提升。
质量打磨：三轮冒烟测试
功能做出来只是第一步，好不好用、稳不稳定才是关键。
复赛阶段我做了三轮冒烟测试，每一轮都记录了几十个问题，然后逐一修复。从金额单位错误、分页加载失效，到位置选择体验差、消息对话逻辑 bug……这些问题如果不修，用户体验会大打折扣。
TRAE 在这个阶段的价值也很突出——我把 bug 描述给它，它能快速定位到问题代码，给出修复方案，很多时候一次就能改对。这让修复效率提高了很多。
一路走来的感悟
从初赛到复赛，这一个多月的迭代让我感触很深：
-
TRAE 不是"一键生成"的魔法，而是"效率倍增器"。它不能替你思考产品方向，但它能帮你把想法快速变成现实。以前可能要一周的工作量，现在一两天就能搞定。
-
从 Demo 到成品，中间隔着 100 个细节。核心功能可能只占 20% 的工作量，剩下 80% 都是体验优化、边界处理、异常兼容。但恰恰是这些细节，决定了用户会不会真的用你的产品。
-
一个人也能做三端项目。放在两年前，我想都不敢想自己一个人能做完用户端 + 商户端 + 管理后台 + 后端。但有了 TRAE，这件事变得可行了——它帮你扛住了大部分的代码量，你只需要专注在最核心的业务逻辑和产品判断上。
-
这个项目不是终点，而是起点。即使比赛结束了，我也会继续完善这个项目，直到它真正上线落地、服务于更多的电动车车主们。因为它对我来说不是一个"比赛作品"，而是一个"做了两年的梦"。
-
AI 时代，个人开发者的天花板被彻底拉高了。以前一个前端工程师想做完整的三端产品几乎不可能，但有了 TRAE，一个人就是一支队伍。这不是"替代"，而是"赋能"——TRAE 帮你扛住了大部分重复性工作，你只需要专注在产品判断和业务逻辑上。
5. TRAE 实践过程
对话太多,仅摘取部分关键对话,本次开发过程全部由Trae Work 和 Trae IDE 开发,全部开发记录均有保留,基本上使用Trae Work制定计划和写文档,由Trae IDE执行开发任务
初赛部分
564472155997755:34664999de9a811411c1658cb60635d3_6a338e4f0b0697dda235e879.6a338e500b0697dda235e87c.6a338e4f0b0697dda235e87a:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/18 14:21:04)
564472155997755:56c3dc5c976cf8b5f63e6001d150f2c0_6a338e4f0b0697dda235e879.6a33918d0b0697dda235e8b4.6a33918d0b0697dda235e8b2:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/18 14:34:53)
564472155997755:9e8e59255d8f3bae328ec22c040227c2_6a338e4f0b0697dda235e879.6a3a54109cfd215729e1470a.6a3a54109cfd215729e14708:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 17:38:24)
564472155997755:2d57931bde588732f0e0f605b9b30ce8_6a338e4f0b0697dda235e879.6a3a61009cfd215729e1472a.6a3a60ff9cfd215729e14728:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 18:33:36)
564472155997755:3c3fb7ef3a101625cf50af6ec6dfe675_6a338e4f0b0697dda235e879.6a3a62e69cfd215729e14747.6a3a62e69cfd215729e14745:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 18:41:42)
564472155997755:5a09ecdf6f6e9b79ac81392eb17cbf72_6a338e4f0b0697dda235e879.6a3a64939cfd215729e14766.6a3a64939cfd215729e14764:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 18:48:51)
564472155997755:261e0a501bd1f257f0c07eda9cff5d39_6a338e4f0b0697dda235e879.6a3a67579cfd215729e1477d.6a3a67579cfd215729e1477b:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 19:00:39)
564472155997755:4a2659cf0f2b738c26efbf5b589fe09b_6a338e4f0b0697dda235e879.6a3a67ec9cfd215729e1478b.6a3a67ec9cfd215729e14789:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 19:03:08)
564472155997755:bf632d432827b6566c23f169c9a5f2e8_6a338e4f0b0697dda235e879.6a3a68a39cfd215729e14796.6a3a68a39cfd215729e14794:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 19:06:11)
564472155997755:8b3063ff7dc0df224261c65dd6f3f7d0_6a338e4f0b0697dda235e879.6a3a6dd59cfd215729e147cf.6a3a6dd49cfd215729e147cd:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/23 19:28:21)
564472155997755:bd5a3d8d298e6c49f380dd174dbbad76_6a338e4f0b0697dda235e879.6a3b2e219cfd215729e148d4.6a3b2e209cfd215729e148d2:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/24 09:08:49)
564472155997755:1a2096a343c217ef706a5e7c72efa6b8_6a338e4f0b0697dda235e879.6a3b35209cfd215729e14900.6a3b35209cfd215729e148fe:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/24 09:38:40)
564472155997755:af0b95aaf2757cbc31d067e4e1af84fe_6a338e4f0b0697dda235e879.6a3b7387998f8bffa3812e6a.6a3b7387998f8bffa3812e68:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/24 14:04:55)
564472155997755:c6ea9a15927a1ab3430e6dd508647eba_6a3bbebba20e709715f30792.6a3bbebba20e709715f30795.6a3bbebba20e709715f30793:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/24 19:25:47)
564472155997755:afb6880e3fbb559e83fd3ce21e066bac_6a3bbebba20e709715f30792.6a3bc0f2a20e709715f307e5.6a3bc0f1a20e709715f307e3:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/24 19:35:14)
.564472155997755:4ac7838bba89081af5b3116a4a64a8f7_6a4625d336f76e5b5194f190.6a4a36fe1ce79f34228fa281.6a4a36faab6233149065d644:Trae CN.T(2026/7/5 18:50:38)
.564472155997755:89d6b00ef1968725a967de036b43b411_6a4625d336f76e5b5194f190.6a4a609a1ce79f34228fa73e.6a4a6096ab6233149065d647:Trae CN.T(2026/7/5 21:48:10)
.564472155997755:346fbe7d9d7362fc4ea988bd20bb87f6_6a4625d336f76e5b5194f190.6a4a68121ce79f34228fa83b.6a4a680fab6233149065d648:Trae CN.T(2026/7/5 22:20:02)
.564472155997755:f1fa184132df812992b7873e5955dffa_6a4625d336f76e5b5194f190.6a4a788d1ce79f34228fab2b.6a4a788cab6233149065d64d:Trae CN.T(2026/7/5 23:30:21)
564472155997755:79ddb599c581ddca7600bec990456aaa_6a3bbebba20e709715f30792.6a476c34819f26189c26a8d6.6a476b8d819f26189c26a8d4:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/3 16:00:52)
564472155997755:00ec918d89c01ca923ed47af5a236383_6a3bbebba20e709715f30792.6a477fc8819f26189c26ae1e.6a477fc7819f26189c26ae1c:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/3 17:24:24)
564472155997755:ecfbcc81fa227f380b6a3516ed51fe55_6a3bbebba20e709715f30792.6a4b079af6eaf61b37711f6e.6a4b079af6eaf61b37711f6c:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/6 09:40:42)
.564472155997755:db7bfcc40ad8545e6597a7d7e8d55c3f_6a4625d336f76e5b5194f190.6a4bcf45407c4bf4dfacd88e.6a4bcf4457dde1fe9fe29266:Trae CN.T(2026/7/6 23:52:37)
复赛部分
.564472155997755:ad16c1e47a614ea84525a079bd9eccaa_6a57800c5eb94013b9bf7730.6a5791675eb94013b9bf7998.6a579166551acd08df8ee57b:Trae CN.T(2026/7/15 21:55:51)
.564472155997755:16ea21742cf7a7a6475e5c8859df2cf6_6a60acaabc656e91b8469ae4.6a616febd926c119daa2233f.6a616fea51c5622a51ec52e4:Trae CN.T(2026/7/23 09:35:39)
.564472155997755:194566773dd6553b8cc60dd28573c260_6a66dfa3309adfe18800c892.6a66e031309adfe18800c894.6a66e0316762abacdc6a14e3:Trae CN.T(2026/7/27 12:36:01)
.564472155997755:14f88f6db82458a394c3de7664e270e9_6a66e409309adfe18800c982.6a66e479309adfe18800c99c.6a66e4796762abacdc6a14e6:Trae CN.T(2026/7/27 12:54:17)
.564472155997755:7faff389cdef1107472f5c2720d8e110_6a69f5e75ebaa0ae9de4f323.6a69f6705ebaa0ae9de4f325.6a69f66ff22ad6774373a65b:Trae CN.T(2026/7/29 20:47:44)
6. 技术方案分享
技术栈选型
| 层级 | 技术选型 | 说明 |
|---|---|---|
| 用户端 | UNIAPP (Vue2) + uniCloud | H5 形态，后续可编译为微信小程序 |
| 商户端 | UNIAPP (Vue2) + uniCloud | H5 形态，后续可编译为微信小程序 |
| 管理后台 | Vue2 + Ant Design Vue + ECharts | Web 形态，通过 HTTP 网关调用云函数 |
| 后端 | uniCloud Serverless（云函数 + 云数据库 + 云存储） | 前端工程师独立完成后端开发 |
| AI 服务 | 大语言模型 + 云函数封装 | 电动车领域专业问答，流式输出 |
| 实时通信 | WebSocket（uniCloud 云函数 + onWebsocketConnection） | 30 秒心跳 + 指数退避重连 |
架构设计
云函数架构（v1.0 合并后）
设计原则：
- 按业务域聚合，而非按页面聚合
- 统一入口模板，统一异常处理，统一权限校验
- 前端通过
FUNCTION_NAME_MAP做新旧云函数名映射，平滑切换 - 非必要不新增云函数，新增功能通过新增
action实现
前端架构
用户端 / 商户端（UNIAPP）：
- 页面组件化，公共组件抽取到
components/目录 - Vuex 状态管理（用户信息、位置信息、购物车等）
request.js统一请求封装，含云函数名映射、Token 自动注入、错误码统一处理utils/工具函数库（formatPrice、formatDate、storage 等）- mixins 混入复用页面逻辑（列表分页、下拉刷新等）
管理后台（Vue2 + Ant Design Vue）：
- Vue Router 路由管理，路由守卫鉴权
- Vuex 状态管理（用户信息、菜单、标签页等）
- axios 请求封装，拦截器统一处理 Token 和错误
- 布局组件（侧边栏 + 顶部栏 + 标签页 + 主内容区）
- ECharts 数据可视化
关键实现思路
1. 同城化过滤体系
核心挑战：8 大列表需要同时支持同城过滤，且切换城市后全局刷新。
实现方案：
- 前端：Vuex 统一管理当前城市信息（cityCode、cityName 等 10 个字段），切换城市时广播
city:change事件，各列表页面监听事件自动刷新 - 后端：5 个云函数服务统一加
cityCode参数过滤，products 表采用 JOIN 策略（关联商户表的 cityCode），避免商品表冗余字段 - 定位：uni.getLocation + 20 城热区矩形匹配（MVP 方案，后续接入逆地理 API）
2. WebSocket 实时推送
核心挑战：uniCloud WebSocket 的连接管理、心跳保活、断线重连。
实现方案：
- 服务端：
message-ws云函数，onWebsocketConnection 事件模型，统一推送模块ws-push.js - 客户端：30 秒心跳保活，指数退避重连（1s → 2s → 4s → 8s → 最大 30s），连接失败降级为轮询
- 推送场景：订单状态变更、新消息通知、系统公告等
3. AI 对话流式输出
核心挑战：大语言模型的流式响应在 uniCloud 云函数中的处理，以及前端打字机效果的实现。
实现方案：
- 服务端：云函数封装 AI 服务，开启流式输出，逐块返回给前端
- 前端：分段接收流式响应，实时追加到消息内容，模拟打字机效果；scroll-top 受控方案，智能判断是否自动滚动
- 容错：多机制保障服务高可用，用户无感知
4. 埋点统计系统
核心挑战：三端统一埋点规范，数据上报不影响用户体验，后台多维度分析。
实现方案：
- 埋点规范：统一事件类型（tab_click / quick_entry_click / menu_click / sub_tab_click），统一上报字段（eventType、eventName、pagePath、timestamp 等）
- 上报策略：批量上报 + 页面卸载时立即上报，减少请求次数
- 数据分析：管理后台埋点统计页面，支持按端、事件类型、时间、用户多维度筛选，KPI 卡片 + 趋势图 + 分布饼图 + 明细列表
4. 商业化与社会价值分析
商业模式
满电青年的商业模型是典型的双边平台模式（车主 + 商户），变现路径清晰且有层次感。我们不追求"什么钱都赚"，而是聚焦高价值业务，逐步建立平台的服务标准和信任体系。
| 变现方式 | 说明 | 阶段 | 亮点 |
|---|---|---|---|
| 维修订单佣金 + 质保服务 | 每笔维修订单抽佣 + 5-10元30天延保服务（同一故障免费返修） | 试点运营期 | 高毛利 + 建立信任 + 差异化 |
| 二手车交易服务费 | 平台担保交易，确认收货后打款给卖家，交易成功收服务费 | 试点运营期 | 高客单价 + 平台价值明确 |
| 配件销售分成 | 商户通过平台销售配件，平台抽成 | 试点运营期 | 高频刚需 |
| 认证商户年费 + SaaS | 980元/年，含认证标识+流量倾斜+经营数据看板+营销工具 | 成长期 | 订阅制收入 + 筛选优质商户 |
| 团购活动抽成 | 团购成团后向商户收取一定比例 | 成长期 | 拉新工具 + 社交传播 |
| 广告位投放 | 首页 Banner、推荐位、搜索竞价等 | 成熟期 | 规模效应 |
| 增值服务 | 车辆健康档案会员、AI助手高级功能、数据分析工具等 | 成熟期 | 高毛利 recurring revenue |
交易闭环与资金安全
平台所有交易（维修、配件、二手车、团购）均走平台闭环支付，商户 T+7 提现。这个机制有三重价值：
- 用户保障：维修满意、二手车确认收货后，资金才打给商户，解决信任问题——和淘宝支付宝的担保交易逻辑一致
- 质保基础：为「满电质保」服务和二手车担保交易提供了资金基础
- 正向现金流：随着 GMV 增长，在途资金规模持续扩大，平台现金流天然为正，降低运营风险和融资需求
资金由微信支付/支付宝托管，平台不经手资金，T+N 是「确认收货后触发打款」的机制，而非资金池模式。
线下运营策略：自营打样 + 认证扩张
试点阶段，我们采用**「1 家官方标杆店 + N 家认证合作店」**的线下策略，既保证服务质量，又避免加盟模式的重资产和管理负担。
官方标杆店（1家）：与一家优质商户合作挂牌，核心目的不是靠开店赚钱，而是：
- 跑通单店盈利模型和成本结构
- 制定维修服务标准、质保流程、价格体系
- 作为其他商户入驻的培训基地和参考样板
- 验证自营模式下的单位经济模型
认证合作店（5-8家）：交认证年费、接受平台服务标准、享受三大权益：
- 流量倾斜：搜索排名靠前、优先派单、认证标识增加用户信任
- SaaS 工具：经营数据看板、客户管理、电子优惠券、订单管理
- 平台背书：30天维修质保（平台兜底）、配件集采优惠
普通入驻商户：免费入驻，按单抽佣，有升级认证店的晋升路径。
这种「自营打样 + 认证扩张」的模式是轻资产快速扩张的可行路径——用 1 家自营店跑标准，用认证店快速复制规模。
落地节奏
计划以长沙大学城为首个试点城市，成立运营公司、上架微信小程序、接入真实支付，通过地推和校园合作完成首批商户和用户的冷启动，验证商业模式后再向更多城市复制。
社会价值
对电动车车主：
- 解决维修难、价格不透明的痛点，保护消费者权益
- 降低购车、用车成本（团购、二手交易）
- 提供骑行知识和安全意识教育（发现模块、AI 助手）
- 针对外卖骑手等职业群体，减少车辆故障导致的误工损失
- 「满电质保」服务让维修更有保障，消除用户后顾之忧
对商户群体：
- 帮助中小商户线上获客，扩大营收
- 提升经营效率（在线接单、电子订单、数据统计）
- 建立信誉体系，优质商户脱颖而出
- 认证商户体系帮助商户提升品牌形象和客单价
- 为大学生提供校园合伙人/团长的兼职和创业机会
对社会：
- 促进二手物品流通，符合循环经济理念
- 规范电动车服务市场，提升行业整体水平
- 服务城市社区，提升居民生活品质
- 推动线下服务行业的数字化转型
可复制性
- 单点验证，快速复制：大学城是天然的封闭市场，用户集中、需求明确、商户密度高，非常适合作为 MVP 验证场景。一旦在某个大学城跑通，模式可以直接复制到更多城市和区域，边际成本极低。
- 双边网络效应（飞轮效应）：车主越多，入驻商户越积极；商户越多，服务越丰富，车主黏性越强。飞轮效应一旦启动，壁垒会越来越高——这是双边平台最核心的护城河。
- 标准可复制：从自营标杆店跑通的服务标准、质保体系、定价策略，可以快速复制给认证合作店，再扩展到普通商户
- 延展性强：从大学城起步，平台积累的服务标准、商户资源、技术架构可以直接迁移到更广泛的场景（外卖骑手、社区居民、通勤白领）。
5. 产品迭代规划
当前版本为 H5 演示环境，下一步的核心方向是从 Demo 走向商用落地。规划分为三个阶段，核心原则是：先跑通一个城市的一条主营业务线，再谈扩张——少即是多，聚焦才能跑得快。
短期规划：商用落地（未来 1-3 个月）
这个阶段的核心目标是完成产品商用化准备，在长沙大学城启动试点运营，跑通二手车 + 维修双业务闭环。
长沙大学城试点运营（最优先级）
- 1 家官方标杆店：与优质商户合作挂牌，跑通单店模型和服务标准
- 商户拓展：签约首批 10-20 家电动车维修店、配件店、车行入驻（含 5-8 家认证合作店）
- 用户冷启动：通过校园推广、社团合作、地推等方式获取首批种子用户
- 运营验证：跑通维修、二手车核心业务流程，验证商业模式可行性
- 数据回收：收集用户反馈和经营数据，为下一阶段迭代提供依据
产品形态升级
- 微信小程序上架：用户端和商户端从 H5 编译为微信小程序，切换企业主体后正式上架微信公众平台
- 真实支付接入：接入微信支付，开通商户号，实现维修、配件、二手车、团购全链路真实收款
- 推送通知：接入微信模板消息 / 订阅消息，订单状态变更、消息通知主动推送
公司与资质
- 公司注册：成立运营主体公司，完成工商注册、税务登记
- 资质办理：办理 ICP 备案、小程序类目资质等运营必备资质
运营功能完善
- 「满电质保」服务：维修订单30天质保，用户加购，平台与商户按比例分成
- 积分体系：完整的积分获取和消费体系，提升用户留存和复购
- 邀请有礼：邀请码机制、邀请记录、奖励阶梯，助力用户增长
- 商户端体验优化：批量发货、订单导出、移动端适配优化
中期规划：功能深耕与区域深耕（未来 3-8 个月）
长沙试点验证跑通后，进入功能深耕和区域深耕阶段——先把长沙做透，再考虑向外扩张。
- 认证商户体系推广：从试点的 5-8 家扩展到 20-30 家认证店，跑通认证店模型
- 车辆健康档案：每辆车建立专属档案，记录维修历史、保养记录、配件更换，基于里程和时间自动推送保养提醒；推出会员版（9.9元/月）
- 会员体系：付费会员享专属折扣、优先服务、免费质保等权益
- 上门救援服务：大学城范围内的上门救援，高客单价高毛利，同时作为拉新场景
- 换电站点导航：整合市面上主要换电品牌的网点信息，用户一键查询就近换电站点（信息聚合，MVP阶段不接API）
- 骑行打卡与车友活动：骑行里程统计、打卡排行榜、发起约骑、组织骑行活动，和发现社区联动
- 长沙区域深耕：从大学城向长沙市区辐射，覆盖更多电动车密集区域（外卖骑手聚集地、大型社区等）
长期规划：规模化扩张（未来 8-18 个月）
在单城模型跑通、认证体系成熟的基础上，启动规模化扩张。
- 多城市复制：从长沙扩展到 5-8 个核心城市的大学城及周边区域，复制「自营打样 + 认证扩张」模式
- 服务标准输出：把长沙试点跑通的维修服务标准、质保体系、认证体系复制到新城市，建立行业标准
- 横向业务拓展：保险代理/分期、上门救援规模化、二手车检测服务等增值服务
- 用户圈层扩展：从大学生向外卖骑手、通勤白领、社区居民等群体渗透
- 智能调度系统：基于位置和订单的智能派单、路径优化（订单量达到一定规模后启动）
后续重点方向：
- 长沙大学城试点，跑通二手车 + 维修双业务闭环
- 上线「满电质保」服务，建立平台信任体系
- 打造 1 家官方标杆店，验证单店盈利模型
当前为 H5 演示环境，三端均支持体验登录，核心业务流程已闭环。登录页均已默认填充体验账号，直接点击获取验证码即可自动填充。
用户端和商户端为移动端 H5 页面，使用 PC 端浏览器访问时，建议 F12 打开开发者工具后切换到移动端模式。
演示中用到的商户数据、商品数据、用户头像、商品图片等所有素材，均由 TRAE Work 模拟生成，快速搭建出完整的演示环境。
以上，就是满电青年的故事。从一个躺了两年的想法，到初赛的 Demo，再到今天的完整成品——TRAE 陪我走完了这段旅程。感谢 TRAE，也感谢看到这里的你。欢迎大家体验并提出宝贵的意见 