很多需求刚开始只有一句话：“做一个能查车位、缴停车费的小程序。”这句话可以讨论方向，却没法直接排期。是给一个商业停车场做便捷缴费，还是把多个园区、路侧泊位和公共停车场接到同一平台；是沿用现有车牌识别设备，还是连道闸、摄像机和收费终端一起改造，后面的技术路线完全不同。
红数科技整理智能停车小程序或APP方案时，第一轮先看车辆从进场、识别、计费、缴费到出场这条链路目前怎么运行，准备改到什么程度，页面放在后面谈。下面这些资料不必一开始就写成正式文档，但关键事实要能核对，不能靠开发方猜。
一、先划清项目边界，再判断小程序还是APP
先列出首期要覆盖的车场、车道和用户。一个车场两进两出，与几十个车场统一运营，差别不只是数据量；后者通常还涉及分级管理、商户结算、跨场会员、区域报表和设备批量运维。
项目范围至少要说明：新建还是改造，停车场类型，车位总数，入口和出口数量，是否包含路侧泊位、充电车位或预约车位，服务临停车辆还是还要管理月租车、内部车、访客车和企业车队。驾驶人端需要做到哪一步，收费员、物业、财务和运营人员分别使用什么后台，也要写清。
小程序适合扫码、查费、缴费、开票、停车记录等低频使用场景，用户不用安装。APP更适合高频导航、持续消息提醒、复杂会员体系、车队管理或需要调用较多终端能力的业务。也可以先做小程序验证停车闭环，后台和接口按多端共用来设计，后续再增加APP。究竟选哪一种，应由使用频率和业务范围决定，功能多并不等于合适。
这一阶段还应提供项目名称、运营主体、品牌名称、Logo源文件、基础色、已有公众号或服务号、希望上线的城市和计划时间。若有招标文件、原方案、现场改造图或集团信息化规范，直接放进同一个资料包，避免方案做完才发现必须兼容另一套要求。
二、车场底账要能对应到现场，只有车位总数远远不够
最实用的做法，是按车场建立一张基础表。每个车场写明地址、经纬度、营业时段、车位类型和数量、入口出口、限高、收费主体、当前收费方式、值守安排，以及断网、停电时怎么放行。车场平面图、车道照片、岗亭照片和设备安装位置图也应一并提供。
收费规则不能只写“按小时收费”。需要把免费时长、首小时、计费单位、封顶价、跨日处理、进出场间隔、夜间价格、节假日价格、无牌车规则和优惠叠加顺序写成可计算的条件。政府定价、政府指导价或当地主管部门另有要求的停车场，还要提供现行收费依据、备案或公示材料；不同城市的管理口径有差异，不能拿另一地的规则直接套用。
再往前走一步，把近一段时间的进出场量、峰值时段、线上支付比例、人工开闸原因、识别失败情况和常见投诉整理出来。没有历史统计时，也可以先给原收费系统导出的原始记录。这些数据会直接影响服务器容量、岗亭保留方案和异常流程，只留在汇报里没有意义。
三、把道闸、相机、收费机和网络逐项盘清
智能停车软件要和现场设备一起跑。入口相机认出车牌后，识别结果要进入停车平台；平台算出费用，支付完成后再向出口设备下发放行。任何一个环节接口不开放，页面做得再完整也无法形成真实通行。
已有设备至少要整理以下信息：
- 道闸、车牌识别相机、车检器、余位屏、自助缴费机、岗亭电脑、对讲设备、打印机的品牌、型号、数量、固件或软件版本。
- 每条车道的设备对应关系、局域网地址、联网方式、供电和备用网络情况，是否能远程维护。
- 设备厂家提供的通信协议、SDK或云平台API，包含鉴权、字段、状态码、回调、重试、离线补传和真实报文示例。
- 当前停车系统的服务器部署位置、数据库类型、导出能力、管理员权限，以及历史订单、月租车和优惠记录能否迁移。
- 可长期使用的测试车道、测试车牌、测试账号和设备厂家配合人。只有文档，没有可反复联调的环境，仍然无法确认设备真实表现。
厂家所说的“支持对接”需要继续问清：开放的是相机识别结果、车道控制协议，还是只能调用厂家云；能不能获取原始图片和设备在线状态；平台下发开闸后是否有执行回执；断网期间记录存在哪里、恢复后会不会补传。不同答案会改变系统架构，也会改变改造费用。
项目尚未采购设备时，开放接口、协议版本、测试支持、远程升级和日志获取能力应写进采购条件。先买设备、后问能否对接，往往会被迫保留两套平台，或者重新更换控制器。
四、计费与通行规则，要把正常流程和“出问题时怎么办”一起写
正常流程通常不难：车牌识别进场，系统开始计时，车主缴费，出口核验后开闸。真正容易返工的是临界情况。比如同一辆车短时间重复识别，入口抬杆但系统没有入场记录，车主付了钱却迟迟没有收到支付回调，或者出口断网时车辆已经放行，后台订单仍在计费。
需求资料里应把这些业务逐项定下来：
- 临停、月租、访客、内部、黑白名单、无牌车、摩托车和新能源车怎样识别、计费与放行。
- 场内预缴后保留多长出场时间，超过时间是否补缴；同一车牌多次进场、套牌或识别纠错由谁处理。
- 商场消费券、物业减免、积分、停车码和人工优惠能否叠加，谁有发券和作废权限。
- 线上支付、岗亭支付、现金补录、退款、欠费追缴、无感支付和电子发票分别怎样入账。
- 相机离线、道闸故障、网络中断、停电、支付回调延迟、重复回调和手工开闸后，订单以什么状态结束。
规则最好配三到五笔算费样例，直接写进场时间、出场时间、车辆类型、优惠和应付金额。收费规则能算对，比写一长段“支持灵活计费”更有用。还要明确哪一端是最终依据：设备记录、平台订单还是支付渠道流水出现不一致时，系统如何自动处理，哪些情况必须转人工。
五、谁能看、谁能改、谁来对账，也属于需求资料
驾驶人看到的是缴费和记录，运营方关心的却是另一套问题：哪个车场收入下降，哪条车道经常离线，谁改过收费标准，人工抬杆有没有原因和凭证。账号角色如果等到后台做完再分，权限往往会越补越乱。
建议把参与方按实际工作列出来，包括平台管理员、区域负责人、车场负责人、岗亭收费员、客服、财务、商户、物业前台和设备运维人员。每类角色说明能看哪些车场，能不能修改车牌、减免费用、退款、开闸、导出数据和配置价格，敏感操作是否需要复核。
财务口径要单独确认。停车订单、支付流水、退款、优惠、发票和商户结算按日还是按月核对，跨日订单记在哪一天，支付手续费、渠道优惠和人工补录如何呈现。需要接财务系统或电子发票平台时，要提供对方接口文档、字段样例、测试账号和回调要求，不能只留一句“支持财务对接”。
六、平台账号和主体材料要提前办，代码完成后再申请会空等
小程序或APP由谁长期运营，相关账号就应尽量由谁申请和持有。常见的准备项包括营业执照、主体负责人和平台管理员资料、小程序AppID、APP包名与签名安排、已备案域名、HTTPS证书、服务器或云资源、短信签名、地图服务账号、消息推送账号，以及电子发票等第三方平台资料。
停车缴费还要准备支付商户号、结算账户和小程序或APP与商户号的绑定关系。开发联调需要用到API密钥、证书或公钥时，应由授权人员通过安全方式交接，不要把真实密钥直接放进需求文档、原型或普通聊天记录。
根据工业和信息化部《关于开展移动互联网应用程序备案工作的通知》，在境内从事互联网信息服务的APP主办者应履行备案手续，相关分发平台范围包含小程序、快应用等。项目排期里要把域名备案、APP备案、平台审核和支付申请的时间留出来。至于当地停车经营、收费公示、道路泊位接入或公共数据上报需要哪些材料，应由项目所在地的主管部门口径确定，不能用软件平台审核代替行业手续。
七、先画一张数据去向图，再决定收集哪些个人信息
停车业务天然会碰到车牌、手机号、车辆照片、进出场时间、停车地点、支付订单和发票抬头。这些字段一旦能关联到具体车辆或用户，就要认真处理。开发前应列出每项数据为什么收集、从哪里来、给谁使用、保存多久、是否提供给设备厂家或第三方平台，以及用户如何查询、更正、删除和注销。
《个人信息保护法》要求个人信息处理遵循合法、正当、必要和诚信原则，收集范围应限于实现目的的最小范围。《网络数据安全管理条例》自2025年1月1日起施行，对网络数据分类分级、个人信息处理、委托处理和安全责任作了进一步规定。落到智能停车项目里，至少要提前准备隐私政策、用户协议、第三方信息共享清单、权限调用说明、数据保存与删除规则，以及发生安全事件后的处置责任。
定位、相册、蓝牙等终端权限不要因为“以后可能会用”就默认申请。只有导航到车场时才需要定位，就在对应场景说明用途；只凭车牌和订单能完成缴费，也不应强制用户先提供一组无关信息。若要使用人脸识别、车辆轨迹分析或跨平台画像，必要性、单独告知同意、安全影响和替代方式都要另行评估，不能当成普通功能顺手加上。
数据接口资料同样要具体。接交管、城运、住建、路侧停车、聚合支付或集团数据平台时，应提供当前版本的接口文档、数据字典、签名与加密方式、网络白名单、调用频率、错误码、测试环境和验收样例。当地已经发布停车数据接入规范的，以当地现行规范为准。只给一个平台名称，没有接口材料，开发公司无法确认能否接入和需要多长时间。
八、把验收、预算和后续运维写清，方案才算能落地
报价之前，项目方最好给出预算范围、目标上线时间、必须首发的功能和允许后置的功能。方案范围没确认时，过早报出的精确价格并不可靠。硬件改造、软件开发、云资源、短信、地图、支付、发票、平台认证和后期维护分别由谁承担，也应拆开说明，避免把持续费用藏在一次性开发费里。
验收标准不要只写“功能正常、运行稳定”。可以直接按真实通行来验：车牌识别后多久生成入场记录，缴费成功到出口可放行允许多少时间，重复支付如何拦截，断网恢复后订单是否补齐，人工开闸能否追到操作人，财务报表与支付渠道按什么口径对平。多车道并发、峰值排队、数据备份、故障恢复、日志留存和权限审计，也要给出可测试的条件。
红数科技通常会把上线后的责任一起落到资料里：设备故障谁先响应，软件日志由谁查看，厂家接口变更谁通知，新增车场按什么流程接入，收费规则调整是否需要审批，历史数据保存多久。项目交付不能停在服务器启动、页面能打开这一步。停车场每天都在运行，任何一次识别、计费或放行异常，最终都要有人处理。
可以交给方案公司开始评估的资料包，不需要写得漂亮，但至少应包含项目范围表、车场底账、设备型号与接口、收费及异常规则、角色权限、平台账号清单、数据与合规说明、测试条件和验收口径。资料暂时缺失的地方也要标明由谁补、预计何时拿到。做到这一步，功能方案、技术路线、报价和工期才有共同的事实基础。
具体项目应以所在地停车管理要求、实际设备型号与固件版本、第三方平台最新审核规则和正式接口文档为准。
