长途拼车产品系统Vibe Coding

1. 核心业务场景：长途自驾拼车匹配（C2C 共享出行）

这是项目的灵魂，属于垂直领域的共享经济。

具体场景成都至新疆（及返程）的长距离自驾路线。
用户角色：
车主（供方）：有空位，希望分摊油费/过路费，寻找靠谱旅伴。
乘客（需方）：希望降低长途交通成本，或寻找有共同语言的旅伴，而非单纯坐大巴/火车。
痛点解决：
信息不对称：传统贴吧/论坛信息杂乱、时效性差。
信任缺失：陌生人拼车的安全顾虑（通过“人工审核+实名+保险指南”解决）。
匹配效率低：通过结构化表单（出发地、目的地、日期、车型）提高匹配精度。
行业属性：非营运性质的互助合乘（注意规避非法营运风险，强调 AA 制分摊成本）。
2. 运营场景：私域流量社群运营（微信生态）

这是 MVP 阶段的核心交付形态，属于内容驱动的用户增长。

流量入口：微信订阅号【长途车找人找车】。
SEO 策略：利用高频搜索词（找车、找人、拼车）获取自然流量。
内容背书：通过《防骗指南》、《AA制公约》建立专业感和信任感。
转化路径：公众号文章/菜单 -> 添加个人客服微信 -> 人工审核（风控） -> 拉入微信群。
社群价值：
即时沟通：群内实时发布余位信息，比静态页面更灵活。
氛围营造：通过群公告、昵称规范（出发地-目的地-日期）营造有序的交易环境。
长尾效应：老用户沉淀在群里，形成口碑传播（老带新）。
3. 技术场景：轻量级 SaaS 平台演进（Web 开发）

这是项目的技术骨架，属于低成本快速迭代的互联网产品开发。

MVP 阶段（无代码/低代码）：
工具：腾讯文档智能表 + 画廊视图。
优势：零开发成本，无需服务器，数据天然结构化，手机端体验好。
场景：验证需求，积累初始用户数据。
进阶阶段（自有 H5 平台）：
技术栈：Vue3 + Vant UI (前端) + 腾讯云 CloudBase/Node.js (后端) +

1.1 车找人
车找人表示已有车主/司机在找乘客同路。乘客在车找人列表里看到合适行程后，核心动作是“请带上我”，发起时需要填写同行人数。

提交“请带上我”前需要校验剩余座位数。如果填写人数大于剩余座位数，则不允许发起请求，并提示用户“剩余座位数不足”。

车主/司机同意某个“请带上我”请求前，需要再次校验当前剩余座位数是否大于等于该请求的同行人数。校验通过后才能同意；校验不通过时不能同意，并提示“剩余座位数不足”。

车主/司机也可以一键拒绝乘客请求。拒绝时弹窗填写拒绝原因，拒绝原因非必填；填写后保存到请求记录里。

车主/司机确认后，系统根据可载人数和当前乘客数判断进入“寻找同路中”还是“已满员”。

1.2 人找车
人找车表示暂无车主/司机的乘客在找车。司机在人找车列表里看到合适行程后，核心动作是“带上他”，并填写可载人数。

乘客同意后，行程当前类型变为车找人，司机成为当前车主和 owner_user_id，状态按可载人数做满员判断；只要还没满员，就保持“寻找同路中”。原始类型仍保留为人找车。

一个人找车行程可以同时收到多个司机的“带上他”请求。当前 owner_user_id 同意其中一个司机后，其他仍在申请中的司机请求自动变为“已拒绝”，拒绝原因默认填写“已找到车主”。

1.3 审核权归属
后续所有“请带上我”申请统一交给 owner_user_id 审核，不再按最初创建人判断。

如果人找车行程被司机接起并变更为车找人，则当前司机接管 owner_user_id。如果负责人取消同行，则必须先转交给其他参与人，新负责人继续接管审核权限。

1.4 我的
“我的”页拆成两个入口：“作为车主”和“作为乘客”。

列表展示时要同时标记行程来源：我创建的 或 转交，方便区分当前负责人是谁，以及这趟行程是不是后来转交过。

1.5 取消与转交
创建人既可以做“取消行程

以下均在 AI （gpt-5.5）的协助下完成
1、负责项目功能规划
2、负责整个项目的产品 prd
3、我负责整个项目技术方案设计
4、AI 完成 coding
5、AI 协助负责整个项目的测试验证