2026 年孟德尔·格林伯格分享 OurCar 开发经验：解决家庭共享汽车难题！

需求是发明之母

围坐餐桌，分摊汽油费成难题，加入家庭后情况更糟。嫂子提议按行驶公里数加油，但因只能按升加油，方案有问题。后来意识到结合行程里程表和油耗读数可精确计算耗油量，可他人不愿每次计算。最终决定每次用车后加满油，可小事用车时很麻烦。共享汽车还存在不知谁用车、车在哪、日程冲突等问题，油箱空的问题成了导火索。于是，开发解决问题且不增加使用难度的应用的想法萌生，立刻开始制作原型。

产品诞生

项目范围定义为 "一款比 WhatsApp 群组更适合共享汽车的应用"，需具备了解汽车位置、状态，跟踪油箱及使用量等功能。当时未找到适合朋友或家人共享汽车场景的应用。选择 [Pocketbase](https://pocketbase.io) 和 [Flutter](https://flutter.dev) 技术栈，后来添加 [Riverpod](https://riverpod.dev) 进行状态管理，[Auto Route](https://github.com/Milad-Akarie/auto_route_library) 进行导航和路由。

开始项目时，智能开发处于起步阶段，依靠工具开发不太值得，但工具在故障排除和研究方面有用。后来 Claude Code 更有用，开始尝试智能开发。花一周完成初始原型，制作了主页、行程列表、还车表单、加油记录列表、加油表单、通知表单等页面，后三个页面是后来添加的。核心功能基本不变，后来添加了用户管理、汽车设置等页面，将加油和行程记录合并成统一时间线。后端为 Pocketbase 添加钩子发送推送通知，选择 Pocketbase 很明智。

原型有漏洞瑕疵，但有产品与市场契合度。将应用上传到应用商店，用测试版功能分发。苹果 iOS 公证流程烦人，绑定妻子手机简化流程；发布到谷歌 Play 商店相对简单。最终上传应用，收集大家邮件即可下载。为项目取名，最初命名 "gastrax"，妻子坚持换名，和 ChatGPT 讨论后取名 OurCar，上传并分享应用后收到反馈。

明确范围，即学会说 "不"

收到各种想法和抱怨，如跟踪保养计划、自动识别仪表盘、GPS 跟踪、分摊汽油费、安排定期行程等。需在想做和需改进的事间做选择，决定不做哪些事。大部分反馈已考虑过，有些想法需拒绝，如 GPS 跟踪，一是耗电，二是侵犯隐私，只需要知道汽车最终停放位置。有些抱怨和请求合理，是因用户体验糟糕，若解决此问题，大家会觉得应用更易用。

日常应用的设计

外观和感觉上，采用 "原生" 理念，让应用融入平台，快速、直观、易用。面临挑战，自己不是设计师，构建的用户界面布局密集、难导航、操作笨拙。Flutter 未提供自动为各平台使用正确组件的方法，需为每个页面构建两个独立视图，幸有 [Flutter Platform Widgets](https://pub.dev/packages/flutter_platform_widgets) 包提供自适应版本组件，但 Android 和 iOS 布局习惯差异大，代码处理复杂。

难找到具有原生感觉的应用示例，参考 WhatsApp 和 iOS 日历应用的表单设计，改进应用连贯性后，自己和他人都更满意。读《设计心理学》发现，遵循标准设计习惯，人们易明白如何使用应用。

编写代码

修复早期 bug 时，遇到行程计时器不显示问题，需在用户更改后强制更新应用，选择 [Riverpod](https://riverpod.dev) 管理多页面状态同步，虽仍有同步问题，但多数问题更易追踪。

性能方面，Flutter 卡顿问题大多已解决，应用性能问题是代码不佳所致。创建的大型组件需拆分，因状态变化可能导致大量重绘，拆分组件可解决问题，但找到正确拆分方法不易，导致某些表单输入文本速度慢。

这不可扩展

开发中为跟踪汽车状态的数据模型苦恼，数据模型复杂，燃油和行程记录分页面易混淆。将两者合并成单一时间线，采用日志方式确定汽车当前状态，像状态机。虽简化更新处理方式，但设计和实现花很多时间，有很多 bug，执行效果有待提高。若重写，会设计成使用 "抽象" 状态机，让逻辑与数据无关，便于测试和发现 bug。与此同时，开始将应用推向公开测试版。