Smart Parking 2.0
让一套停车系统，重新拥有演进能力
从无文档的外包系统逆向还原，到重新规划产品、接入内部业务体系并持续迭代。
1.0 外包黑盒2.0 自有体系
迁回内部的不是一套旧页面，而是停车产品的定义权与演进能力。
Business Scale
8 个 2.0 商场的月度运行规模
单量口径缴费单不等同于进场车次，页面不将两者混用。
金额口径应付金额为优惠抵扣前的原始停车费用，不是现金实收。
The Legacy Constraint
1.0 仍在运行，但已经难以继续演进
问题定位、修复与沟通依赖外部团队。
新业务能力无法跟随内部产品节奏持续演进。
后台和小程序存在明显体验问题。
会员、积分、卡券和订单需要专用接口反向查询。
真正失去的，是公司对停车产品的演进控制。
Black-box Reconstruction
没有文档，只能从线上系统反推产品
没有可直接使用的产品文档和开发技术文档，只能查看仍在运行的 1.0 后台和小程序，逐项还原功能、规则、状态、异常与能力边界。
功能覆盖接近原系统，但产品结构、业务规则、交互和系统分层重新规划。
1.0 线上系统
页面流程规则状态异常边界
Identity Decoupling
第一项重构：缴费不再以开卡为前提
XCU—MCU 身份解耦属于 2.0 首发能力，支付身份与会员身份从产品基线开始就被分开。
先承接车辆查询与停车支付。
再接入会员等级、积分和卡券。
这项设计满足支付宝平台授权边界，但不声称提升了开卡率或支付转化。
Native Architecture
把停车接回内部业务，再用统一协议连接外部系统
平台型接入某集团一次集团级对接可覆盖 19 个商场。
真实边界外部生态没有被完全标准化，独立部署系统仍可能逐客户适配。
Benefit Orchestration
四类权益进入同一套可解释的优惠规则
单次总减免上限用户选择顺序决定优惠优先级，先选择的权益优先占用额度。前端即时展示，后端重新校验资格、限制与总额度。
会员限制日 / 周 / 月使用上限车辆限制日 / 周 / 月使用上限
车辆维度来自多人绑定同一车辆、轮流使用会员权益的真实风控问题；任一维度达到上限，本次权益不可使用。消费减免按每名会员每天最多使用一次，不复制低频二次入场的复杂匹配。
Payment Lifecycle
同一笔优惠，从一次查询到可回退闭环
停车 1.0一次查询后直接使用
- 缴费页查询一次可用优惠
- 调用权益接口
- 直接通知停车场“优惠已使用”
没有冻结、支付结果确认或失败回退的生命周期。
停车 2.0每一步都有状态与回退
缴费页查询可用优惠支付时二次校验冻结权益创建待支付缴费单支付成功后扣减 / 核销失败、取消或超时后解冻通知停车中台与停车场
冻结防止同一积分、停车券或使用次数被并发重复占用；支付失败时，权益和订单都能回到可解释的状态。
Back to Evolution
从 1.0 黑盒重构为 2.0，再让能力持续扩展
既有业务可以运转，但产品维护和演进依赖外部团队。
重新规划身份、权益、支付与外部接入，停车重新拥有可维护的内部基线。
真实问题持续带来能力扩展
会员等级、积分抵现、商户停车券、消费减免和便捷出场进入统一体系。
从仅限制会员升级为会员与车辆双维限制，并增加绑定查询、后台解绑和操作日志。
针对 ETC 与小程序结果同步时间差，增加支付后 Loading 与等待出场提示；优化后未再明显发生同类问题。
现金与权益同步回退；再次执行只重试失败步骤，以校验时间处理跨日核销，超出宽限时由退款兜底。
Running at Real Scale
2.0 已真实运行，但仍处于渐进迁移阶段
当前停车业务总盘子35 个停车商场
某集团共 19 个商场，版本按商场配置并存。
其中一个 2.0 商场刚上线、交易数据较少，不把不完整月份包装为成熟月均。
退款能力已上线，但暂无真实线上退款订单；版本并存不等于全面替代 1.0。
Conclusion
迁回的是产品定义权与演进能力
从线上 1.0 黑盒还原能力，重新规划身份、权益、交易与系统分层，再通过真实问题持续完善 2.0。
不是重做页面不是原样复制不是全面替代
本人负责产品盘点、重构规划、规则与系统分层设计并推动上线；研发团队完成工程实现。
返回项目经历