产品需求文档

项目：游戏技能指导服务小程序（暂用名） 版本：v1.0　日期：2026-10-16 编制：乙方开发方　确认：甲方 关联文件：需求问卷 V4（75 题）、信息架构树、界面线框图、数据库结构、流程图、一期方案（线下支付）、保真模型（36 屏）

〇、这份文档怎么用

先说清楚一件事：需求问卷还没回收，很多答案还是空的。所以这份文档不是"甲方的需求"，而是 "目前能确定的需求 + 我方给出的建议值 + 明确标出来的待确认项"。

每条需求后面都有一个状态标记：

为什么要把待定项一条条列出来：待定项不是拖延，是风险。比如"教练和平台是什么关系" 这一条不定，就不知道要不要额外办一张经营许可证。先回答待定项，比先看功能列表重要得多。

第二部分怎么用：文档末尾有一张「待确认清单」，按卡住的严重程度排序。建议甲方 从上往下回答，回答完前面的，后面的很多会自然有答案。

一、产品定义

1.1 一句话

一个让人可以按时间预约游戏高手、付费请对方指导自己打游戏的小程序。

1.2 解决什么问题

1.3 这个产品不解决什么

这一条同样重要，它决定了一期不做哪些东西，避免工期失控：

• 不做社交社区。用户之间不能互相发帖、不能加好友、不能私聊（只能在订单里跟教练沟通）
• 不做实时语音通话。一期的"语音"只指教练上传一段自我介绍录音
• 不做自由发布的接单需求。用户不能发"今晚想找人打排位"让别人来报名，只能浏览平台列出的服务并下单
• 不做跨端通用。只做微信生态，不做手机应用、不做网页版用户端

为什么：自由发帖会触发"内容平台"的监管要求，要额外申请类目、建完整的过滤机制、长期养审核人员。 一期把这些砍掉，换成"平台生成、平台可控"的形式，风险小很多。详见 03_合规与资质/筹备期注意事项与行业参考.md。

二、目标用户与使用场景

2.1 三类人

2.2 三个典型场景

场景一：用户找教练 小林今晚 8 点有空，想找人教他打野。他打开小程序 → 首页选「王者荣耀」→ 看推荐列表 → 点进一个教练的主页 → 看段位、战绩截图、听语音介绍、翻评价 → 点「预约」→ 在日历上选今晚 20:00-22:00 → 确认订单 → 支付。（一期支付走线下，见第三节）

场景二：教练接单 小 K 每天晚上 7 点后可以接单。他打开小程序（跟用户是同一个，登录后切换身份）→ 工作台把「接单开关」打开 → 去「接单广场」看平台推过来的订单 → 觉得合适就点「我要接单」→ 到点了在订单里点「开始服务」， 计时自动跑 → 服务完点「结束服务」→ 用户确认后钱进他的钱包。

场景三：运营处理纠纷 用户在后台提了退款申请。客服登录后台 → 订单管理里搜到这笔单 → 看订单详情里的状态流转记录和沟通记录 → 判断责任 → 走退款审批。

三、业务模式

3.1 是哪种模式

C2B（用户对商家）：用户向平台入驻的教练下单，而不是向"任意一个陌生人"下单。

这一点决定了很多设计：

• 教练必须先通过平台审核才能被看到、才能接单（不能自己注册完就上架）
• 教练的服务内容和价格由平台审核后展示，不是随便写
• 平台对服务过程有责任，纠纷时平台要介入判责

3.2 钱怎么走 —— 一期用线下支付 【已定】

背景：微信支付的商户号、分账比例、平台收款是否算"二次清算"，这几件事都要等甲方主体资质办下来 才谈得上。为了不卡住开发，一期先把支付这块绕过去。

开发上的好处：所有跟钱有关的代码按最终形态写好，只是把"真转账"换成"记一笔账"。 二期开通微信支付后，只需要把空着的那个分支填上，业务代码一行不用改。

3.3 平台怎么赚钱 【待定-07】

平台从每笔订单里抽成。具体比例甲方还没定（问卷第 12 题）。

【建议】 抽 20%（教练拿 80%）。

⚠️ 有个坑要提前说：微信支付的分账功能，默认单笔分账比例上限是 30%。 如果按"平台抽 20%、教练拿 80%"来设计，意味着要给教练分 80% —— 这超出了一般情况下的上限， 需要提前向微信申请提额。这件事必须在开通支付之前办，否则二期上线时才发现分不了账。

四、三端与交付形态

【已定】 教练端跟用户端共用一个小程序。理由：小程序名称、主体、类目都只有一套， 做两个要审两次、维护两套，一期没必要。

技术选型 【已定】：原生小程序开发方式 + TypeScript + 微信云开发（免服务器、免备案）。

五、功能需求

5.1 主客户端（用户端）

5.2 教练端

5.3 管理后台

六、页面与交互设计

【已定】 已经出了高保真原型（能看清每个页面长什么样、有什么按钮、点了去哪）， 共 9 份文件 / 46 个界面，覆盖三端、三套主题，外加启动页与宣传物料：

视觉风格（2026-10-16 变更）

【已定 · 最新】只做一套风格：简约清新。 原来的三套像素主题（霓虹科幻 / 奶油糖果 / 简约商务） 全部作废。

同时作废的：功能需求表里的 U-19「主题外观切换」—— 只有一套风格，没有可切换的对象。

风格变了，什么没变：换风格只动配色、圆角、阴影、字体、图标这五样。 页面的结构、信息顺序、按钮位置一个都没动 —— 所以前面确认过的骨架依然有效，不用重新讨论。

已经出了一张风格样张（04_设计/风格样张/风格样张-简约清新.html），含 5 个手机屏 + 1 个后台窗口。 甲方看过说「就是这个感觉」之后，再铺全部界面 —— 避免做完了推倒重来。

像素稿存档说明

04_设计/保真模型/ 下的 9 个文件（46 个界面）是三套像素主题时期的产物， 已作废，仅作记录保留，不再作为设计依据。

启动页是用户打开小程序先看到的那一屏；分享卡片与海报是用户转发到群里时对方看到的样子 —— 这个产品的用户基本都来自群里转发，卡片上写什么直接决定别人点不点，是转化率最高但最常被忽略的一个界面。

⏳ 待定-17：甲方需要确认这七份原型的视觉风格。 三套主题是甲方指定的方向 （霓虹科幻 / 奶油糖果 / 简约商务），已经做出来了，但具体配色深浅、字号、图标风格 还需要甲方看过之后拍板 —— 这个必须在开发动工前定，否则做完了返工量大。

设计细节另外有三份图纸：信息架构树.md（页面层级）、界面线框图.md（版面分区）、 流程图.md（业务流转）。

七、订单全流程

7.1 订单状态

 0 待支付 ──→ 1 待派单 ──→ 2 待服务 ──→ 3 进行中 ──→ 4 待确认 ──→ 5 已完成
   │            │                                        │
   │            │ 无人接单超时                            │ 超时未确认自动完成
   ↓            ↓                                        ↓
 6 已取消     7 退款中 ──→ 8 已退款                   （触发结算）
                              ↑
                          9 售后中

一期调整：因为走线下支付，状态 0「待支付」的实际含义是**「待确认收款」**， 由运营在后台手动推进。

7.2 订单来源

【待定-08】 具体用哪种（或哪几种组合），问卷第 16 题还没答。目前三端原型是按 "用户直接下单 + 教练抢单"两种都支持来做的。

八、数据与账号

【已定】 数据库设计已经出稿，见 04_设计/数据库结构.md：

账号体系

• 一个微信号 = 一个账号，这套账号同时是"用户"和"教练"的载体，靠身份切换区分
• 用户和教练的权限差别：教练多出接单广场、接单、收入、提现；前提是入驻审核通过
• 【待定-18】 是否要求实名才能下单（问卷第 51 题）
• 【待定-19】 实名认证怎么做：用微信自带的实名信息 / 接第三方服务 / 人工审证件照（问卷第 52 题）

九、前提条件（卡在甲方这边的事）

这些不是开发的活，但不定就上不了线。排期里已经把它们标成 G1–G4 四个卡点。

⚠️ 最重要的一条：微信的服务类目里没有「陪玩 / 陪练」这类选项。 所以这个小程序对外不能以"陪玩"的名义做。目前方案是走**「游戏教学 / 技能指导」的路子， 这也是原型界面上统一叫「教练」**、不叫"陪练 / 打手 / 陪玩"的原因。

【待定-01】 甲方需要回答：教练和平台是什么关系？ - 如果是平台签约的服务人员（按平台规则干活）→ 属于自营内部调度，不需要额外许可 - 如果是自由入驻的第三方商家（自己定价、自己结算）→ 属于第三方交易平台，需要额外办经营许可

这一条是全项目最关键的一个问题，它决定要不要多办一张证。

十、一期明确不做的事

写下来是为了验收时有据可依，避免"这个怎么没有"的争议。

十一、验收标准

一期算不算"跑通"，按这几条判：

不包含在验收范围：真实收款、真实打款、真实短信、真实语音通话。

十二、待确认清单（按卡住的严重程度排序）

建议甲方从上往下回答。前面几条答完，后面很多会自然有答案。

第一档：不定就没法动工

第二档：决定核心流程怎么走

第三档：影响具体功能取舍

附：文档版本