企业官网建设流程全解析

1. 需求规格说明书到底在解决什么问题

做过共享单车类小程序的人都有一个共同感受：功能列表看起来不复杂，扫码、开锁、计费、还车，四步走完就结束了。但真正进入开发阶段，问题会像潮水一样涌出来——用户扫码后锁没弹开但订单已经计费了怎么办？用户骑到运营区外突然锁车，费用怎么算？同一辆车被两个人同时扫，谁先谁后？这些场景如果不在需求阶段写清楚，开发就只能靠猜，测试只能靠碰，上线之后客诉就会教你做人。

需求规格说明书的核心价值，不是把功能罗列一遍，而是把边界条件、异常流程、状态流转、数据约束这四件事写透。它面向的读者包括产品经理、前后端开发、测试工程师、UI设计师，甚至包括后期接手的运维人员。一份合格的需求文档，应该让一个完全没参与过需求讨论的新人，看完之后能独立画出业务流程图，并且能准确回答“如果用户在骑行过程中手机没电了，订单状态会怎样”这类问题。

这篇文章我会从实际项目经验出发，把共享单车小程序需求规格说明书的完整结构、关键细节、常见坑点全部拆开讲。不管你是刚接手这类项目的产品经理，还是需要根据需求文档做技术方案的后端开发，或者正在准备测试用例的QA，都能从中找到可以直接参考的内容。

2. 整体架构与核心模块拆解

2.1 需求文档的骨架应该怎么搭

很多需求文档写到最后变成了一锅粥，根本原因是骨架没搭好。共享单车小程序的需求规格说明书，我习惯按“角色-场景-功能-数据-异常”五层结构来组织。角色层定义用户、运维人员、运营后台管理员三类主体；场景层描述扫码开锁、骑行中、临时锁车、还车结算、故障上报等核心场景；功能层把每个场景拆成具体的功能点；数据层定义车辆状态、订单状态、用户账户状态等核心数据实体；异常层则穷举每个环节可能出现的异常情况。

这个结构的优势在于，开发和测试可以按层推进。开发先看功能层和数据层，测试先看场景层和异常层，产品经理重点维护角色层和场景层的变更。各角色关注点分离，文档的维护成本会低很多。

注意：需求文档不是一次性写完就锁死的。共享单车业务变化很快，电子围栏规则、计费策略、调度逻辑都可能调整。建议在文档开头就建立版本变更记录表，每次修改标注日期、修改人、修改内容和影响范围。

2.2 核心状态机设计：车辆与订单的双轨模型

共享单车业务最核心的技术设计就是状态机。车辆有车辆的状态，订单有订单的状态，两者必须严格联动，否则就会出现“车已锁但订单还在计费”或者“订单已结束但车还显示在使用中”这类数据不一致问题。

车辆状态我一般定义为六种：空闲可用、已预约、使用中、临时锁定、故障待修、低电量调度中。订单状态定义为七种：待开锁、骑行中、临时锁车、待支付、已完成、已取消、异常待处理。这两个状态机之间的转换关系必须在需求文档中用表格明确写出来，不能含糊。

这张表看起来简单，但实际项目中我见过太多团队在这里翻车。比如“临时锁定”状态下用户直接关掉小程序走了，车辆一直停在临时锁定状态，其他用户扫不了，运维也找不到。所以需求文档里必须补充一条：临时锁车超过X分钟（通常30分钟）未操作，系统自动结束订单并通知用户。

2.3 计费模型的需求描述要点

计费是共享单车最敏感的部分，也是客诉重灾区。需求文档里写计费规则，不能只写“每15分钟1元”，必须把以下要素全部定义清楚：

• 起步价与时长费的组合方式：是前15分钟1.5元，之后每15分钟1元，还是直接按分钟计费
• 计费起始时间点：是扫码成功开始计费，还是锁弹开开始计费，还是车辆移动开始计费
• 计费截止时间点：是用户点击还车开始，还是锁扣合上开始，还是系统收到锁状态变更开始
• 不足一个计费单元的处理：不足15分钟按15分钟算，还是按实际分钟折算
• 封顶价格：单次骑行最高收费多少，超过多少小时自动结束订单
• 优惠券与余额的扣减顺序：先扣优惠券还是先扣余额，优惠券是否可叠加
• 异常情况下的计费豁免：开锁失败是否计费，车辆故障导致无法还车是否计费

这些规则每一条都需要产品经理和运营方确认，不能由开发自己拍脑袋。我经历过一个项目，开发把计费起始时间点设成了“锁弹开”，结果用户扫码后锁没弹开但订单已经开始计费，客诉率直接飙升。后来改成“锁状态变为已开启”才解决。

3. 核心功能模块的详细需求描述

3.1 扫码开锁模块的完整需求

扫码开锁是用户接触的第一个核心功能，也是异常最多的环节。需求文档需要覆盖以下内容：

正常流程：用户点击扫码按钮，调用摄像头识别车辆二维码，解析出车辆编号，向服务端发起开锁请求，服务端校验用户资格（是否实名、是否有未支付订单、信用分是否足够），校验车辆状态（是否空闲、电量是否充足），下发开锁指令到车辆锁具，锁具执行开锁并回报状态，服务端更新车辆和订单状态，小程序展示开锁成功并进入骑行页面。

异常流程必须逐条列出：

• 二维码损坏无法识别：提供手动输入车辆编号的入口
• 用户有未支付订单：拦截并引导支付，支付完成后自动继续开锁流程
• 用户信用分不足：提示无法使用并说明原因
• 车辆已被他人预约：提示车辆已被预约，推荐附近其他车辆
• 车辆电量低于阈值：提示车辆电量不足，推荐附近其他车辆
• 开锁指令下发后锁具无响应：等待超时后提示“开锁失败，请重试”，并自动取消订单
• 开锁成功但小程序未收到回调：用户端展示“开锁中”，轮询查询订单状态，避免用户重复扫码

实操心得：开锁超时时间建议设置为8-12秒。太短了锁具还没执行完就报失败，太长了用户等待焦虑。我一般设10秒，同时在小程序端做倒计时动画，让用户知道系统在工作。

3.2 骑行中与临时锁车模块

骑行中的需求重点在于状态同步和异常处理。用户骑行过程中，小程序需要定时上报位置（用于计费和轨迹记录），同时监听车辆锁状态变化。这里有一个关键设计：位置上报频率。上报太频繁耗电，上报太少轨迹不准。通常建议每30秒上报一次，同时根据移动速度动态调整——速度越快上报越频繁。

临时锁车的需求要写清楚：用户点击临时锁车，车辆锁扣合上但订单不结束，计费暂停还是继续？这个必须明确。大部分共享单车的做法是临时锁车期间继续计费，因为车辆仍然被该用户占用。但也有一些产品设计为暂停计费，这取决于运营策略。需求文档里必须写明，并且在小程序端明确提示用户。

临时锁车还有一个容易忽略的点：用户临时锁车后，如果车辆被移动（比如被人推走），系统应该如何处理？需求文档需要定义：临时锁车状态下，如果车辆位置发生超过阈值的移动，系统应记录异常并通知运维，同时在小程序端提示用户“车辆位置异常，请确认车辆安全”。

3.3 还车结算模块的需求细节

还车是订单闭环的关键环节。需求文档需要定义还车的三种方式：手动点击还车、锁扣手动合上触发还车、系统自动还车（如超时未操作）。

还车流程的核心校验点包括：

• 车辆是否在运营区内：不在运营区则提示用户骑回或支付调度费
• 车辆是否停在指定停车点：如果运营方要求定点还车，需要校验位置
• 车辆锁状态是否正常：锁扣未合上则无法完成还车
• 用户是否有未完成的支付：有则先支付再还车

结算页面的展示内容也需要在需求文档中明确：骑行时长、骑行距离、费用明细、优惠券抵扣、实际支付金额、支付方式选择。这里有一个细节：费用明细的展示顺序。我建议按“起步价-时长费-调度费-优惠券抵扣-实付金额”的顺序展示，让用户清楚每一笔费用的来源。

注意：还车时如果车辆锁扣合上但服务端未收到状态变更，小程序端应展示“还车中”并轮询查询，超过30秒未成功则提示用户“还车处理中，请稍后查看订单状态”，避免用户重复操作导致订单异常。

3.4 故障上报与运维调度模块

故障上报是用户参与运维的重要入口。需求文档需要定义故障类型（刹车失灵、链条脱落、车座损坏、二维码损坏、锁具异常等）、上报方式（拍照上传、文字描述、选择预设标签）、上报后的处理流程（系统通知运维、车辆状态变更为故障待修、用户本次骑行费用减免）。

运维调度模块的需求通常面向运营后台，但小程序端也需要配合。比如运维人员到达现场后，通过运维端小程序标记车辆已修复，车辆状态恢复为空闲可用。这个状态变更需要实时同步到用户端，避免用户扫到故障车。

4. 数据模型与接口需求描述

4.1 核心数据实体定义

需求文档中需要定义的核心数据实体包括：用户、车辆、订单、支付记录、优惠券、运维工单。每个实体需要列出关键字段和约束条件。

以车辆实体为例，关键字段包括：车辆编号（唯一）、当前状态、当前电量、当前经纬度、所属运营区、最后通信时间、累计骑行次数、累计骑行里程、投放时间、最后维护时间。其中车辆编号需要定义编码规则，通常采用“区域码+批次码+序列号”的组合方式，便于运维识别和管理。

订单实体的关键字段包括：订单编号、用户ID、车辆编号、开锁时间、还车时间、骑行时长、骑行距离、费用明细、支付状态、支付方式、优惠券ID、订单状态。这里有一个设计要点：订单编号的生成规则。建议采用“日期+用户ID后四位+随机码”的方式，既保证唯一性又便于人工排查。

4.2 关键接口的需求描述

需求文档不需要写接口的具体实现，但需要定义接口的输入输出和业务规则。以开锁接口为例：

输入：用户ID、车辆编号、用户当前位置经纬度输出：开锁结果（成功/失败）、失败原因码、订单编号（成功时返回）业务规则：

• 校验用户是否有未支付订单
• 校验用户信用分是否达到阈值
• 校验车辆状态是否为空闲可用
• 校验车辆电量是否高于最低阈值
• 校验用户位置与车辆位置的距离是否在合理范围内（防止远程扫码）
• 开锁指令下发后等待锁具响应，超时则返回失败

这些业务规则需要在需求文档中逐条列出，开发才能准确实现，测试才能设计用例。

4.3 数据一致性与并发处理需求

共享单车业务天然存在并发问题。同一辆车被多个用户同时扫码，两个请求同时到达服务端，如果处理不当就会出现“一车两单”。需求文档必须定义并发处理策略：

• 服务端在收到开锁请求时，先对车辆记录加锁（数据库行锁或分布式锁）
• 校验车辆状态为空闲可用后，立即将车辆状态更新为“已预约”或“使用中”
• 后续请求发现车辆状态不是空闲可用，直接返回失败
• 锁具响应超时后，需要回滚车辆状态

这个流程需要在需求文档中明确写出，并且标注每一步的时序要求。我见过一个项目因为没写清楚并发处理，上线后出现同一辆车被两个用户同时开锁，两个订单同时计费，最后只能人工退款。

5. 异常场景与边界条件穷举

5.1 用户侧异常场景

用户侧异常是需求文档中最容易遗漏的部分。我整理了一份常见异常清单，每次写需求文档时都会对照检查：

5.2 车辆侧异常场景

车辆侧异常包括锁具通信失败、电量骤降、GPS定位漂移、车辆被非法移动等。需求文档需要定义每种异常的检测方式和处理策略。比如锁具通信失败，系统应记录最后通信时间，超过阈值未通信则标记车辆为“失联”，通知运维排查。

GPS定位漂移是一个容易被忽略的问题。车辆上报的位置可能因为信号问题出现大幅偏移，导致计费距离异常。需求文档应定义：当两次上报位置之间的距离超过合理阈值（如1分钟内移动超过1公里），系统应丢弃该次定位数据，使用上一次有效位置。

5.3 支付与退款异常

支付异常包括支付成功但订单状态未更新、支付失败但扣款成功、重复支付等。需求文档需要定义对账机制：每日定时对账，比对支付流水和订单记录，发现不一致时自动生成异常工单，由人工处理。

退款场景也需要明确：哪些情况可以退款（车辆故障、计费异常、重复支付），退款流程是什么（用户申请-客服审核-原路退回），退款时效是多久（通常1-3个工作日）。这些规则需要在需求文档中写清楚，避免客服和开发之间扯皮。

6. 非功能性需求与验收标准

6.1 性能需求

共享单车小程序对性能的要求集中在开锁响应速度和并发处理能力上。需求文档应明确：

• 开锁接口平均响应时间不超过2秒，95分位不超过5秒
• 系统支持同时在线用户数不低于10万
• 支持每秒开锁请求数不低于500
• 订单状态查询接口响应时间不超过500毫秒

这些指标需要根据实际业务规模调整，但必须在需求文档中写明，作为后续压力测试的验收标准。

6.2 安全需求

安全需求包括用户隐私保护、支付安全、防刷单机制。用户位置信息属于敏感数据，需求文档应定义：位置信息仅用于计费和轨迹记录，不对外共享；支付接口必须使用加密传输；同一用户短时间内频繁扫码开锁应触发风控拦截。

6.3 兼容性需求

小程序需要兼容主流操作系统和屏幕尺寸。需求文档应列出支持的客户端版本范围，以及在不同网络环境（4G、5G、WiFi）下的降级策略。比如网络较差时，优先保证开锁和还车功能可用，轨迹记录可以降低精度。

7. 需求评审与变更管理实操

7.1 需求评审的组织方式

需求评审不是把文档念一遍，而是要让开发和测试真正理解业务。我通常采用“场景走查”的方式：产品经理按用户使用路径逐步讲解，开发和测试随时提问，重点讨论异常场景的处理方式。评审结束后，开发和测试需要各自输出一份理解文档，产品经理确认无误后才进入开发。

7.2 变更管理流程

共享单车业务变化快，需求变更不可避免。关键是要建立变更管理流程：变更提出-影响评估-变更评审-文档更新-通知相关方。每次变更都要评估对开发进度、测试范围、已上线功能的影响。我见过一个项目因为需求变更没有通知测试，导致新功能上线后测试用例没更新，漏测了一个关键异常场景。

7.3 需求文档的维护技巧

需求文档建议采用在线协作工具维护，每次修改保留历史版本。关键需求点用批注标注确认人和确认时间。文档结构保持稳定，内容更新时在变更记录中说明。我个人的习惯是每周五下午花半小时回顾本周的需求变更，确保文档和实际开发保持一致。

8. 常见问题与排查技巧实录

8.1 开锁成功率低的排查思路

开锁成功率低通常有三个原因：锁具通信问题、服务端并发处理问题、用户端网络问题。排查时先看服务端日志，确认开锁指令是否成功下发；再看锁具通信记录，确认锁具是否收到指令并执行；最后看用户端网络请求日志，确认请求是否成功到达服务端。这三个环节逐一排除，基本能定位问题。

8.2 订单状态不一致的处理

订单状态不一致表现为用户端显示骑行中但服务端显示已完成，或者反过来。这类问题通常是因为状态更新时没有加锁或者没有做幂等处理。排查时先查订单状态变更日志，找到最后一次状态变更的记录，确认变更来源和变更时间，然后对比车辆状态变更日志，找出不一致的时间点。

8.3 计费异常的常见原因

计费异常包括多计费、少计费、计费时长与实际不符。常见原因有：开锁时间记录错误、还车时间记录错误、计费规则配置错误、优惠券抵扣逻辑错误。排查时先拉取订单的完整计费明细，逐项核对计费规则，再检查时间戳是否准确。

避坑技巧：建议在订单表中增加“计费快照”字段，记录计费时的规则版本和参数，方便后续排查计费争议。

8.4 需求文档常见遗漏点速查

• 临时锁车超时自动结束订单的阈值是否定义
• 运营区外还车的调度费规则是否明确
• 优惠券叠加使用规则是否清晰
• 用户信用分低于阈值的处理流程是否完整
• 车辆故障上报后的费用减免规则是否定义
• 支付超时未完成的订单处理策略是否明确
• 同一用户短时间内频繁开锁的风控规则是否定义

这份清单我每次写需求文档时都会过一遍，基本能覆盖80%的常见遗漏。

9. 从需求到上线的个人经验

做了几个共享单车项目之后，我最大的体会是：需求文档的质量直接决定了项目的返工率。一份写得细的需求文档，开发阶段的问题会少很多，测试用例也更容易设计。反过来，如果需求文档只写了正常流程，开发就得自己猜异常怎么处理，测试就得自己碰边界条件，最后上线必然一堆问题。

另外一个经验是，需求文档要跟着业务走，不能闭门造车。我习惯在写文档之前先跟运维人员聊一次，了解实际运营中遇到的车辆问题、用户投诉、调度难点，这些信息往往能补充很多需求文档里想不到的异常场景。比如运维提到“冬天电池掉电快，很多车骑到一半就没电了”，这个场景如果不提前考虑，上线后就会大量出现“骑行中车辆断电”的客诉。

最后分享一个实用技巧：需求文档写完后，自己模拟一遍完整用户旅程，从扫码到还车，每一步都问自己“如果这里出错了会怎样”。这个习惯帮我发现了不少遗漏的异常场景，也让我写的需求文档越来越扎实。