企业官网建设流程全解析

简介：骑士加油商业需求文档面向产品经理、创业者及传统油站数字化改造从业者，依托石油行业年交易额近3万亿、全国超11万座加油站的背景，重点解决油站效率低成本高、车主支付不便等痛点，适合项目立项、融资汇报与内部方案评审等场景；内容涵盖市场分析、商业模式、产品规划、收益成本与风险对策五部分。包体为1个PPTX演示文稿，整体2.26MB，结构清晰，便于直接阅读或作为互联网+项目需求文档模板。已有59人学习。文档内嵌SWOT、竞争对手对比、盈利模型与里程碑规划，给出储值卡系统、第三方支付、会员等级、进销存管理等功能设计，以及按100家油站测算的技术服务费与硬件收入估算。通过“小步快跑”迭代策略，读者可借助其完整论证路径与数据测算思路，快速搭建B端商业计划或撰写产品需求文档。

1. 为什么“骑士加油商业需求文档.pptx”这份 PPT 值得认真对待

“骑士加油商业需求文档.pptx”不是给传统加油站写的方案，而是面向同城配送骑手的续航补能服务：骑手打开小程序，就能看到几百米外的换电柜，扫码租走满电电池。把商业需求写成 PPT，目的是让决策者在 20 分钟内看懂“做的是什么生意、值不值得做、先做哪几步”。这份文档既是产品方向说明书，也是开发、测试、运营后续对口径的起点。

我见过不少同类 BRD，最容易失败的是两种：宏观到老板点头、开发发呆，或者细到变成一份伪 PRD，没人讨论商业价值。下面这套写法会把商业假设、需求优先级、主流程字段和验收标准压进一份 PPT，同时留出机器可读的检查手段。适合正在写 BRD 的产品经理，也适合要接手这份 PPT 的开发与测试负责人。

2. 给“骑士加油商业需求文档.pptx”搭优先级：商业假设 + MoSCoW

2.1 先立商业假设：骑士“加油”要解决谁的什么问题

商业需求文档不该一上来就铺功能列表，第一步是把“骑士加油”锁在一个商业假设里：骑手的核心成本不是饭钱，而是全天跑单中的电量焦虑。充电要排队，换电要付押金，路线不熟还会绕路。于是产品被定义为：聚合换电柜、充电桩和骑手专属优惠的补能钱包。

我习惯在 BRD 第 2 页放一张角色表，而不是直接说“我们要做一个 App”。不同角色对服务的价值感受完全不同：众包骑手在意“午高峰前能不能换到电”，专送骑手在意“这个月补能支出比上月省多少”，站长则希望“少几个因为缺电迟到的骑手”。这三类人会直接决定首页放地图还是放账单。

需要提醒的是，这张表叫商业假设，不等于已验证。BRD 评审通过后要安排小型访谈，样本量不用大，20 个骑手加 5 个站长就够。访谈结果如果和某一行冲突，优先修正表格，而不是为了让功能好看硬留需求。也正因为这样，这份文档停留在商业需求层，把功能和交互留给下一份 PRD。

2.2 先锁边界，再谈功能和参数

这段把“骑士加油”限定到一个最小闭环：把骑手从“找柜-换电-支付”这条链路上的等待和不确定性降到最低。边界的作用是排掉多余预期。例如有人会提出“为什么不能加低碳积分”，边界里已经写了不做，评审时可以先把这类需求放回需求池而不是当场讨论。

锁边界时还要把关键参数写进去：默认查询半径 3km，按直线距离计算；换电柜电量低于 10% 时不展示；“免押金”只对首次完成绑车的骑手开放。用参数而不是形容词来定义边界，开发排期时才知道功能背后有容忍度。如果没有这些参数，边界只是一个口号。

2.3 用 MoSCoW 给需求池定级

BRD 里最常见的是 P0/P1/P2 标注法，但 P 的含义在不同团队里波动太大：有人说 P0 是“本周上线”，有人说 P0 是“必须做”。我更喜欢 MoSCoW，因为它把“不做”也列为一种明确态度，适合商业验证期的需求取舍。给“骑士加油”的需求池做一张示意表：

Must 意味着缺了不能上线，即使成本高也要排期；Should 是有价值但不构成最小闭环；Could 是资源富余时再做；Won't 是文档默认拒绝。优先级字母加理由比字母本身更重要，所以成功标准和依赖两列必须填。R01 如果被标成 Should，开发会问“首版连柜子都找不到，那还做什么”，填好理由后，评审焦点就变成了“为什么 Must 的依赖是柜端”，而不是反复争论级别。

这个表还会在后续开发中变成排期依据：Must 进入第一个迭代，Should 进入第二个迭代，Could 进入待定池，Won't 在这份 BRD 内不再讨论。每个迭代的验收都对着“成功标准”列做检查，比人工记忆优先级可靠得多。写到这一步，“骑士加油商业需求文档.pptx”的核心商业和需求优先级就已经立住了。

3. 从“骑士加油”主流程拆需求和 JSON 字段

3.1 主流程只需要一条主链路，别画十种分支

每份 BRD 都要画流程图，但我不建议把完整业务流程图放进 PPT。分支一多，评审会就变成“异常分支怎么处理”，而不是“主链路是否成立”。我一般只保留一条主路径：打开小程序；手机号登录；绑定车辆和电池型号；按距离找换电柜；扫码占用柜格；取出电池；完成结算。

这条流程决定了后续很多设计：登录用手机号，因为骑手换手机号频率高，账号要能迁移；绑定车辆要选电池规格，因为 48V 和 60V 电池不能互换；找柜要优先展示距离，因为骑手对“近”的感知比“便宜”更强。把这些判断写成文字放在流程图旁边的批注里，比画箭头更有用。

3.2 流程节点拆成需求规则表，开发才能排期

主流程最终要转成可检查的规则，我把它拆成一张表：

这已经是 BRD 页面里最小的颗粒度。开发拿到这张表还会问“3km 是直线还是骑行距离”、“5 分钟锁格能不能配置”，所以要把参数直接落实在规则里：查询半径 3km，取直线距离，后台可调；柜格锁定时间 5 分钟，可配置范围为 1 到 15 分钟。没有这些参数，开发会按自己理解实现成 1km 或 30 分钟，然后测试再按开发的理解写用例，最后完全偏离业务预期。

3.3 接口不用全给，但响应样例必须固定

BRD 阶段不需要完整 API 文档，我会固定几个关键语义。比如“查询附近换电柜”的响应样例，用 JSON 写好字段名和含义，前后端联调时就不会各写各的命名：

{ "code": 0, "message": "ok", "data": { "cabinets": [ { "cabinet_id": "HC-1024-01", "distance_m": 320, "address": "长宁路 88 号", "battery": { "spec": "48V20Ah", "available": 8, "total": 12, "avg_charge_percent": 78 } } ], "expire_time": 30 } }

code为 0 代表成功，非 0 的错误码要定义公共错误码；cabinet_id在全网唯一，是后续工单和支付对账的唯一键；distance_m用米表示距离，后端返回前排序，前端不要做二次排序；available为 0 时前端隐藏该柜点；avg_charge_percent是柜内可用电池的平均电量，避免骑手跑到现场才发现没满电；expire_time是客户端缓存秒数，30 秒后必须重新查询。

这个样例不是在教后端写接口，而是在锁定业务语义。比如available究竟是当前能借的电池数，还是柜内所有电池数，不写清楚，后端大概率会叫battery_count但含义却是剩余可借数。文档固化了这些名词，后续接口设计可以在此基础上增加字段，不能改含义。这就是为什么“骑士加油商业需求文档.pptx”值得放一页接口样例：它让抽象的商业需求落到了开发能直接建表的地步。

4. 用 python-pptx 校验“骑士加油商业需求文档.pptx”完整性

4.1 评审前用脚本扫一遍，比重读幻灯片可靠

评审会上经常出现这种场景：产品翻到第 5 页，发现漏了优先级；开发当场问“验收标准是什么”，所有人都沉默。我习惯在评审前用脚本把 PPT 逐页读出文本，再用若干关键字做门禁检查。脚本只判断“有没有”，判断“对不对”的事仍然留给评审会，但至少不会在机械问题上翻车。

先安装依赖：

pip install python-pptx

这个库不依赖 Office 环境，能在本地和 CI 中直接跑。注意安装完之后代码里导入的包名是pptx，不是python_pptx，这是最容易被新人卡住的第一个坑。

4.2 抽取每一页的标题和正文文本

下面脚本可以打印每一页里的所有文本，包括普通文本框和表格内容：

from pptx import Presentation def extract_slide_text(pptx_path): prs = Presentation(pptx_path) for idx, slide in enumerate(prs.slides, start=1): print(f"=== 第 {idx} 页 ===") for shape in slide.shapes: if shape.has_text_frame: text = shape.text_frame.text.strip() if text: print(text) if shape.has_table: for row in shape.table.rows: print(" | ".join(cell.text.strip() for cell in row.cells)) if __name__ == "__main__": extract_slide_text("骑士加油商业需求文档.pptx")

代码里做了两件关键事：第一个，shape.has_text_frame只判断文本载体，页面标题、占位符、文本框都会读到；第二个，shape.has_table负责读取表格，否则 MoSCoW 表和流程规则表都会丢。这里没有用shape.text直接取值，是因为从协同编辑环境生成的文件里，text 属性可能不完整；用shape.text_frame.text更稳定。

4.3 用关键字清单自动定位缺失内容

抽取完文本后，我定义一份“必现清单”：

REQUIRED_KEYWORDS = { "骑手": "用户角色页", "换电柜": "业务场景页", "优先级": "需求优先级页", "验收标准": "验收页", "数据指标": "目标页", } def check_keywords(pptx_path): prs = Presentation(pptx_path) pages_text = [] for slide in prs.slides: texts = [] for shape in slide.shapes: if shape.has_text_frame: texts.append(shape.text_frame.text) if shape.has_table: for row in shape.table.rows: texts.append(" ".join(c.text for c in row.cells)) pages_text.append(" ".join(texts)) for keyword, page_hint in REQUIRED_KEYWORDS.items(): hit_pages = [i + 1 for i, text in enumerate(pages_text) if keyword in text] status = "通过" if hit_pages else "缺失" print(f"{keyword}: {status} 期望位置[{page_hint}] 命中页 {hit_pages}") if __name__ == "__main__": check_keywords("骑士加油商业需求文档.pptx")

REQUIRED_KEYWORDS就是这份脚本的参数，不建议超过 5 个，关键词越少越准，至少不容易误报。“换电柜”这条如果不出现，可能文档用了“充电桩”做替代词，说明产品定义不一致，这时正好提示你回看第 2 章商业假设。输出中“命中页”直接显示页号，缺失时不用再逐页找。

提示：python-pptx 不会读取 SmartArt 和嵌入图片里的文字。如果流程图是图片，请先把图中关键判断点写进备注，或者改用文本框重画主链路，否则脚本会漏检。

脚本只适合做增量检查，不能替代业务评审。例如“验收标准”四个字出现一次，可能正文只是说“需要验收标准”却没有内容。所以我在评审前会额外设置一个参数：MIN_HIT_PAGES = 2，要求“验收标准”至少命中两页，代表既有定义、又有实例。上面的代码里没有实现，你可以按同样方式扩展，原则是参数宁可少，不在检查上打扰评审。

5. 把验收标准写进备注，定格“骑士加油”评审结论

PPT 正文页面要保持干净，评审时的关键验收规则不要全塞进页面，写在备注栏更合适。写法用 Given-When-Then 三段式，不要写“页面可正常展示”这样的空话。以“骑士加油”两个核心需求举例：

Given-When-Then 最大的好处是测试用例可以直接复制。R01 的 Given 已经写“3km 内有 3 个柜”，测试就覆盖 0、2、3 个三种情况；R02 的 When 里“确认租用”表示存在二次确认动作，开发不能做成扫码即结算。

下面这段代码可以批量把这些验收标准写入每页备注：

from pptx import Presentation prs = Presentation("骑士加油商业需求文档.pptx") notes_content = { 1: "R01 验收标准：Given 骑手授权定位；When 打开找电页；Then 展示可换电柜及距离、可用电量。", 2: "R02 验收标准：Given 柜格二维码可识别；When 扫码后确认租用；Then 柜门打开且进入待结算。", } for slide_index, note in notes_content.items(): slide = prs.slides[slide_index - 1] slide.notes_slide.notes_text_frame.text = note prs.save("骑士加油商业需求文档_review.pptx")

notes_slide代表 PPT 的备注页，不存在时 python-pptx 会自动创建；notes_text_frame.text直接赋值，也可以用\n区分多行。这里按页码写入时有一个脆弱点：中间插入一页备注就会错位，如果文档结构经常变动，建议改为按页标题定位幻灯片，再写备注。

评审通过后，只要再跑一遍第 4 章的提取脚本，把备注内容导出成 CSV 或直接导入测试管理工具，测试就能基于备注里的 Given 条件建用例。这份 pptx 的正文讲商业目标，备注记验收共识，唯独一点要记住：任何改动都要在原文件上改并让文档评审同步更新，不要为了保持“干净”把备注放在本地草稿里。如果团队用 Git 管理这份 PPT，拉取合入前跑一次关键字校验，把校验结果和备注一起提交，后面看历史版本时，一个文件就能还原当时的商业判断。

本文还有配套的精品资源，点击获取