排充电桩小程序的工期，最容易犯的错，是照着页面数量往下算。首页、站点、扫码、订单、我的，看上去并不多，真正费时间的却在页面后面：用户点下“开始充电”，命令要经过小程序、业务后台、设备平台或桩端，设备执行以后还要持续回传状态；充电结束，电量、时长、费率、支付和退款又要落到同一笔订单上。
界面做完，只能说明软件长出了样子。设备能启动、金额能结清、异常能收住，才接近可上线。
先分清要做的是哪一种项目
下面的区间按一个工作周 5 天计算，指软件项目从需求确认到具备上线条件的大致时间，不包含充电站土建、电力报装、设备生产采购和现场施工。平台审核、第三方资质审批也有外部不确定性，适合单独留机动时间。
| 项目情况 | 典型范围 | 工期主要花在哪里 |
|---|---|---|
| 已有成熟运营平台，只补小程序端或做轻量改版 | 4—6 个工作周 | 页面、登录授权、现有接口适配、基础测试与发布 |
| 单一设备品牌，新建小程序和业务后台，接厂家云或已验证协议 | 8—12 个工作周 | 设备接入、计费、微信支付、订单闭环、现场联调 |
| 多品牌设备、多站点运营，带会员、余额、优惠或电子发票 | 12—16 个工作周 | 统一设备模型、复杂资金流程、权限、数据迁移和多轮回归 |
| 还要接停车道闸、企业车队、分账、有序充电或监管平台 | 16—20 个工作周以上 | 多方接口、现场条件、合规边界和跨系统异常处理 |
这不是一张通用报价表。相同的功能清单，接厂家已经跑过大量设备的云接口，和从桩端二进制协议开始搭平台，周期可能差一倍。所谓“设备支持国标”也不能直接替代平台接口。比如 GB/T 27930-2023解决的是非车载直流充电机与车辆之间的数字通信，小程序后台控制充电桩，仍然需要桩到运营平台的协议，或者设备厂家的开放接口。
红数科技在做前期估算时，会先确认接入路线，再谈页面和功能。路线没定，报一个很精确的天数，看起来干脆，实际没有多少约束力。
一份能落到项目表里的排期
常规单品牌项目大致会经过这些工作。它们不是简单首尾相接，产品原型、后端基础和小程序开发可以并行；设备、支付和完整订单联调存在依赖，前面的条件没满足，后面很难靠加人赶回来。
| 工作内容 | 常见用时 | 到这一步应看到什么 |
|---|---|---|
| 范围确认与接入摸底 | 1—2 周 | 首期功能、设备型号、接入方式、计费与结算口径明确，测试环境能访问 |
| 原型、数据模型与技术方案 | 1—2 周 | 扫码到结算的流程走通，设备、枪口、费率、订单的关系定下来 |
| 小程序、后台与管理端开发 | 3—6 周 | 用户端和运营端主要功能可在测试环境运行 |
| 设备、支付和第三方联调 | 2—4 周 | 实桩启停、过程数据、结算、退款及回调能够闭环 |
| 异常测试、回归与发布 | 1—3 周 | 关键异常有处理结果，生产配置完成，提交审核并修正反馈 |
真正排计划时，还要把“开发时间”和“等待时间”分开。设备厂家迟迟不给真实报文、测试桩只能夜里使用、商户号没有完成绑定，这些都不会增加代码量，却会直接推迟交付日。更接近实际的算法是：
预计交付时间 = 可并行后的开发周期 + 必须串行的联调周期 + 外部等待与整改机动
排期开始前，至少要确认这几项：
- 充电桩是直连新平台，还是继续连厂家云；每个品牌、型号和固件版本分别走哪条路线。
- 桩端协议或厂家云 API 是否完整，是否包含启动、停止、实时数据、结束订单、故障、回调、重试和真实报文示例。
- 是否有一台可反复启停的测试桩，以及可实际充电的车辆、负载或厂家认可的模拟器。
- 费率由谁维护，尖峰平谷、电费、服务费、跨时段结算和费率版本以哪一端为准。
- 小程序 AppID、微信支付商户号、已备案域名、HTTPS 证书、服务器和管理员权限是否已经准备。
- 首期是否包含预付、余额、原路退款、分账、电子发票、停车费、优惠券或企业账户。
- 设备厂家、现场人员和第三方接口方各由谁配合，能看哪些日志，联调时间怎么约。
- 上线验收看哪些场景，设备动作、小程序状态、后台订单和资金记录以什么口径核对。
最容易拖慢进度的，不是同一类问题
设备在线，只能算联调刚开始
能收到登录和心跳，说明网络链路基本通了，并不代表充电流程已经通。后面还要核对枪口状态、远程启动、启动结果、实时电压电流、累计电量、主动停止、车辆结束、故障停止和订单补传。直流桩还会受到车辆握手、BMS 通信和车型兼容情况影响。
设备协议文档里最容易缺的是异常说明。平台下发启动后多久算超时？桩先返回“已受理”，稍后才报告执行失败，页面应该显示什么？设备断网后继续充电，恢复连接会补几条过程数据和几笔结束记录？这些没有约定，正常流程可能一天就跑通，异常流程却会来回改上好几轮。
还有一个常见误解：测试环境能模拟状态，就不必准备实桩。模拟器适合验证字段和基本流程，代替不了插枪、急停、断电、信号不稳、车辆主动停止这些现场行为。测试桩什么时候能用、谁能在旁边复位设备，应该直接写进排期条件。
最难收口的是充电状态和订单状态
一笔充电订单并不是“未支付、已支付”这么简单。扫码以后可能未插枪，启动命令可能已受理但还没出电，也可能小程序等超时了，充电桩随后才启动。充电过程中还会碰到临时离线、车辆停止、急停、跳闸、拔枪和费率跨时段。
这里真正要先定的是状态依据。设备已经开始输出电流时，即使小程序没有及时收到结果，也不能再允许用户创建第二笔订单；桩端已经结束但结束记录尚未补到平台，页面可以显示“结算中”，不能为了让界面好看直接猜一个金额。设备状态、过程数据、结束记录和平台订单各自负责证明什么，要在联调前说清楚。
最危险的情况不是明确报错，而是两边都给了一个看似合理、实际互相冲突的结果：小程序显示启动失败，桩已经充上；页面显示已结束，设备仍在出电；同一条结束记录重发两次，平台生成两次结算。处理这类问题需要命令编号、订单关联、幂等、超时查询和人工兜底一起配合，靠多加一个提示框解决不了。
支付能拉起，不代表钱和账已经对上
微信支付联调至少涉及下单、用户支付、异步回调、主动查单、关单、退款和对账。充电业务又多一层：开始前是预付、冻结额度，还是结束后按实际金额付款；预付金额高于实际消费时退差额还是进入余额；支付成功但设备没有启动，多久自动退款；设备已经启动但支付结果延迟，订单如何处理。
官方小程序支付要求小程序 appid 与商户号 mchid 建立正确关系。账号没绑定、产品权限没开通、API 密钥或回调域名没配置，开发端无法把联调做完。支付回调还可能重复、延迟或先于页面查询到达，后台必须按同一商户订单号处理，不能把页面上的“支付成功”当作唯一凭据。
到了验收，至少要对上四组记录：微信支付单、平台支付单、充电业务订单和桩端充电记录。只看用户付了多少钱，不核电量、费率版本、退款和日结差异，上线以后问题会集中落到运营人员手里。
第三方接口常常改的是主流程，不只是多一个按钮
地图导航和短信通常相对独立，停车、发票、分账和企业车队却会改变订单结构。停车费要不要与充电费一起付，车辆出场前金额是否还会变化；电子发票按支付金额开，还是按电费和服务费拆分；企业车队是司机付款、企业月结，还是账户额度扣减。答案不同，订单什么时候结束、谁承担欠款、退款退到哪里都不同。
如果这些能力首期必须上线，就要把第三方文档、测试账号、回调规则和联调联系人一并纳入计划。只把它们写成“后续接入”，同时又按现有订单模型开工，后面经常不是补接口，而是重做结算关系。
发布前的账号和隐私要求不能留到最后一天
小程序上线还要处理主体认证、成员权限、业务域名、服务器域名、隐私保护指引、用户授权和版本审核。项目使用手机号、定位等个人信息时，应按实际业务说明处理目的，并使用平台要求的授权流程。微信开放文档也明确了小程序的协同开发、体验版、审核和发布流程，提交审核不等于立刻上线。
这些工作大多可以与开发并行。问题通常出在没人负责：代码已经完成，管理员权限还没给；服务器能访问，域名尚未备案或没加白名单；页面调用了定位，隐私声明却没有对应内容。把账号准备放进项目第一周，比临发布时集中补材料省事得多。
另外，充电设备本身的合规不能由小程序替代。GB 44263-2024和GB 39752-2024已于 2025 年 8 月 1 日实施，分别涉及电动汽车传导充电系统和供电设备的安全要求。新项目做设备选型、采购与验收时，应核对实际型号适用的标准、认证和检测资料；软件侧则要把故障、急停、断电和异常结束如实接进业务流程。
用一个常见范围试算
假设首期接一个品牌、20 台交流桩，设备已经连在厂家云上，开放接口经过验证；用户端包含找站、扫码、启停、实时状态、订单、微信支付和退款，后台包含站点、设备、费率、订单和基础告警；不做余额、发票、停车和分账。小程序账号、商户号、域名、测试桩也都能按时提供。
这种情况按 8—10 个工作周估算比较稳妥：前两周把接入和业务口径定下来，中间四周左右完成主要开发，同时尽早接设备和支付，后两到四周完成实桩、异常、回归与发布。它不是“20 台桩逐台开发”，同品牌同协议通常只做一次适配，但至少要抽取不同固件或不同现场网络条件的设备验证。
如果同样的需求改成充电桩直连新平台，桩端协议从未在这批设备上验证，周期更适合放到 10—14 个工作周。再加入第二个品牌、停车计费和电子发票，通常还要继续增加接口适配与回归时间。这里增加的不是几个页面，而是新的状态来源、新的结算参与方和更多异常组合。
怎样把工期守住
- 开发启动后的前 3—5 天先做接入验证，用一台测试桩跑通登录、状态查询和一次远程控制。接入走不通，尽早暴露比等页面全部完成更有用。
- 设备、小程序和微信支付并行准备。账号申请、域名备案、商户绑定、测试桩协调不依赖页面完成，没有必要排到后面。
- 给首期范围设一条清楚的边界。临时加入余额、分账或停车，不应只在功能表上多一行，要重新评估订单、资金和测试范围。
- 提前写异常用例。启动超时、桩端拒绝、充电中断网、结束记录补传、支付回调延迟、重复回调、退款失败，都要有预期结果和责任系统。
- 把现场联调窗口当作正式资源。设备厂家、软件人员、现场人员和测试车辆同时在场的时间往往比写代码更难协调，排期里必须锁定。
一份经得住执行的工期表，应该同时写明功能范围、接入路线、外部前提、联调场景和不包含事项。红数科技给这类项目排期时，通常会把“技术接入跑通”“完整充电闭环通过”和“具备生产发布条件”分成三个时间点。这样哪一段在等待、哪一段已经完成，项目双方都看得见，也不会把所有风险压进一个含糊的上线日期里。
