想把＂带朋友来吃返余额＂做成小程序?写代码前,先写完这份需求分析

想把"带朋友来吃返余额"做成小程序？写代码前，先写完这份需求分析

饭局上常有人跟我聊想法：我认识几家餐厅的老板，想做点餐的东西，顾客扫码自己下单，省掉服务员；再带"带朋友来吃，返你钱"的玩法，生意自己会滚。

聊到末了几乎都是同一句：我想找外包做，你说多少钱、多久上线？

这句话我太熟了，因为我自己就这么干过。后面你要看的这个项目，是我们从零做的「饭搭子 / MealMate」，点餐加一级以人推人裂变加返利余额。这篇用它做实名复盘，不编一个数字，关键决策当时怎么想、依据什么、坑在哪，原样摆给你。

可这篇先不讲代码，也不讲框架。先讲一件更无聊、更值钱的事：需求分析。

带返利的产品有一个共同特征。它的坑不在功能做不出来，在三件和代码无关的事上：钱怎么走、关系怎么锁、合不合规。

这三件事没想清就去找外包，报价越便宜，后面赔进去的时间越贵。

一句话总结这篇的主张：需求文档要当成给钱和合规立的合同来写，代码是合同里最晚出场、也最好改的部分。

这篇就干一件事：把一句饭桌上的话，变成一份能交出去、开发拿着就能开工的需求文档。

过程分五步。先回答三个先于代码的问题，再画四张表，然后把四张表翻译成一份 PRD 骨架，最后给你验收口径，让你知道做到什么程度算完。

先交代全局。从 0 到 1 系列一共八篇，路线如下：

• 第 1 篇需求分析：想法变成文档，也就是本篇
• 第 2 篇资金模型：钱怎么分、返利谁出钱，算到能拍板
• 第 3 篇技术选型与交付：用什么技术、叫谁写、怎么验收
• 第 4 篇服务商分账：资金如何实时到店
• 第 5 篇返利引擎与防薅：规则怎么在代码里落地
• 第 6 篇余额账务：记账纪律
• 第 7 篇小程序工程实录：前端与发布
• 第 8 篇审核上线与长期运营：过审与活下去

八篇别急着往后翻。本篇的四张表是全部地基，画歪了，后面每篇都在歪楼板上砌墙。

一、三个先于代码的问题

先别急着叫开发。

你想做扫码点餐加返利，于是找外包、找朋友、找 AI，开口常是：帮我做个点餐系统带分销返利，多少钱、多久上线？

真正专业的人不会先报价。他会反问你三个问题。

第一问：顾客付的 100 块钱，先进谁的账？

先进平台、平台再转给门店，还是直接到门店？

多数发起人第一反应是先到我这里，不然我拿什么抽佣。这个答法恰恰踩中最重的一条红线。

钱先进平台再分给门店，监管里叫二次清算，简称二清。没有支付牌照却截留商户资金做二次清算，轻则封号冻结，重则违法。平台能截留资金，就有了挪用和跑路的可能，历史上资金盘跑路，几乎都长着二清的脸。微信生态对这类结构零容忍，审核期就能识别，上线后一次举报或抽查，处置来得又快又重。

正确的答法，核心在平台怎么做到不碰钱。合规的路只有两条，门店各自持商户号直接收款，或者平台做微信支付服务商，用官方分账让资金实时到门店账上。两条路饭搭子都设计了，为什么分期走，后面章节讲。

第二问：返利关系怎么锁？

你拉我、给我返利，这个关系只锁一层，还是无限往下传？你拉来的人再去拉人，他下级的消费，跟你还有关系吗？

发起人常答：当然层级越多赚得越多，上三级分销。也有人根本没想过，把决定丢给开发看着办。

第一种是主动跳多级分销。在小程序生态里，多级分销约等于拒审加封号，这块没有空子可钻。第二种更隐蔽，等于把合规决策外包给开发。开发按行业常见套路实现，而行业常见套路里躺着一批被封过的多级结构。

正确答法只锁一层。A 把 B 带进来，B 每笔订单支付成功，A 拿一份奖励。B 再去带 C，A 和 C 没有任何关系。

一句话，返利只认你直接带来的那个人。

为什么只锁一层？二级以上就开始碰拉人头获利的边界。这个边界一碰，平台审核、监管认定、用户举报，每一关都够你受。合规的玩法要主动离边界远远的。

第三问：每单返的那笔钱，到底谁出？

返利要有一个确定的出资方。它从平台佣金里让利，还是商家额外掏，还是平台亏钱补贴？

发起人最爱答：羊毛出在猪身上，先把量做起来。听着豪迈，其实是把成本问题无限期搁置。

返利一旦承诺出去就成了负债。用户每拉一个人、每产生一笔消费，你都要兑现一笔钱。没人认领这笔账，返利发到一半你就发现自己在亏本，然后被迫改规则。改规则等于伤害已经拿到好处的老用户，比当初不发还伤信任。

饭搭子的答案：平台抽 8% 服务费，返利 2% 从这 8% 里让出来。商家不用额外掏钱，让的是平台自己的佣金。这笔账写清楚之前不做产品。

返利谁出钱，本质上在问增长预算从哪来。先答这个，再谈功能。

三个问题问完，你会发现没有一个关于代码怎么写。它们答不清楚，代码写了也是返工，而且是推倒重来级别的返工。结构选错了，改的是一整套资金和关系的骨架。

拿三问自测一遍再去询价。能不看资料、三句话答清钱不进我的账、关系只锁一层、返利由平台佣金让出，报价质量会完全不同。对方会把你当懂行的甲方来对待，报价质量也完全不同。

观点一：需求文档是给钱和合规立的合同。谁先想清这两件事，谁就掌握了项目的定价权。

二、表一 · 一句话定位

三问答完，开始画表。第一张最简单，也最容易被跳过，一句话定位。

饭搭子写下的第一行字：点餐加一级以人推人裂变加返利余额的产品。

三个词分别回答一个侧面。

点餐是履约工具。顾客扫码自助下单，门店省人力、提翻台，这是用户愿意打开它的理由。

一级以人推人裂变是增长引擎。老顾客把店分享出去，人带人来。这里用词是一级，呼应第二问的结论，关系只锁一层。

返利余额是留存钩子。被你拉来的人每消费一笔，你账户里多一笔下次吃饭能抵的钱。注意到账的是余额，只能消费抵扣，现金走不通。这个区别是整张资金表的地基。

表里藏着一个多数人都会想错的机制。返利要跟着真实消费走，拉一个人注册就给一次的路子走不通。

饭搭子把注册奖励直接关掉。新用户注册一分不送，余额只有一个来源，你邀请的人真实消费产生的返利。

两个原因。

第一，把一次性拉新变成长期关系。只奖首单，用户拉完一个人就不管了，后面跟他没关系。按每单奖，老用户会持续把店挂在嘴边，朋友每次来吃他都有进账。同样的预算，买持续的关系维护比买一次性动作划算得多。

第二，从源头掐掉刷量。注册就给钱等于公开招募注册机，批量注册批量薅，预算全喂脚本。奖励跟真实支付走，刷子想薅就得真金白银下单，成本高到他自己先退场。

再提醒一个认知误区：以为返利等于注册奖励，把预算花在拉新注册上，结果注册数很好看、订单纹丝不动。返利产品的正确姿势是让奖励跟着交易走，交易真实，关系才真实，增长才真实。

饭搭子定位多门店形态，堂食扫码、自提、外卖都覆盖，带规格和购物车。

为什么一开始就把盘子画大？返利天然需要多门店才滚得起来。单店顾客很快吃腻，增长引擎熄火。门店多，顾客有新鲜感，返利关系才有长期价值。

盘子一大，钱和关系的复杂度指数上升。多家店的钱怎么分、顾客从哪家店进来算谁的。这些更要靠后面的表把账算清，写代码的事往后放。

一句话定位有自测土办法。拿去问三个人，一个懂技术的、一个开过店的、一个完全不相关的，请各自复述这产品做什么。三人说法基本一致，表合格。三个人三个版本，说明你自己都没想清，开发更没法替你脑补。

观点二：定位的合格线，是随便抓三个人都能复述出同一件事。定位不清时写的代码，等于替一个含糊的生意买单。

三、表二 · 角色与关系绑定

第二张表回答谁在这笔生意里、各自认什么账。

返利系统的乱账，九成出在关系绑错上。这张表的重点在角色之间的两道绑定，列角色只是开头。

一期只放三个角色：食客、门店老板、平台运营。

每多一个角色就多一组利益关系要理清，首版越轻越好。店铺合伙人这种角色二期再谈。

食客付钱、拿返利。门店老板提供服务、收货款。平台运营搭连接、收服务费。

三者之间有两道绑定，是这张表的命门。

第一道：邀请关系。

A 把产品分享给 B，B 点进来，系统记下 B 是被 A 带来的。两条铁规矩，缺一条都出事。

一人只认一个邀请人，先到先得、不可更改。B 被 A 绑走，别人再来绑，系统一概不认，B 的消费返利终身只归第一个带他进来的人。

可更改意味着可交易。刷子可以让 B 先绑一个号攒返利，再改绑到另一个号变现，绑定就成了洗管道。一次性锁死，从结构上消灭这种操作。

只认一层。A 拉 B、B 拉 C，A 和 C 没有任何关系。这条对应多级分销红线，这里不重复。强调一点，这条规矩要落进数据结构，系统压根不存孙节点关系，想多级都多不起来。

第二道：门店归属。

B 扫了某家店的码进来，就被绑给这家店，一次性、不可改。这道绑定管另一笔钱，门店获客返点。某家店愿意为拉新掏 3% 返点，但这笔钱只认 B 真正到店消费的那家店。

两道绑定的区别一句话讲清。A 把 B 带进平台，A 在 B 的任何消费里拿 2% 余额，这是平台让利。门店掏的 3% 获客返点只认 B 真的走进的那家店。B 后来去了别家店，别家店不能因为 B 扫过我的码就分走返点，否则成了 A 店抽 B 店的佣金，账永远算不清。

绑错会怎样？给两个真实事故场景。

场景一，一人可绑多个邀请人。B 今天从 A 的链接进、明天从 C 的链接进，系统都认，A 和 C 为同一笔消费打起来。更糟的是刷子注册十个号互相邀请，把返利刷到一个号上集中变现。先到先得不可更改，是保命。

场景二，获客归属可篡改。B 本来在 A 店消费，路过 C 店扫了个码，系统把归属改给 C 店，A 店投的获客返点白花。一次两次能忍，三次四次 A 店直接退出加盟。门店归属一次性不可改，保护的是加盟体系里最脆弱的信任本身。

技术上，两道绑定轻得惊人。分享链接地址参数带两个标识，一个邀请人、一个门店，新用户落地时各写一次数据库。

真正难的决定全在需求分析阶段：谁绑谁、能不能改、锁几层。想清了代码水到渠成，想不清改绑定逻辑的代价远超想象，因为绑定另一头牵着真金白银的返利。

给每道关系绑定过三问自查。

谁绑谁？关系的主语宾语是谁。

能不能改？错了允不允许重绑，什么条件下、由谁发起。

锁几层？单层还是可传递，边界画在哪。

三问答完，关系骨架立住。这一道工序不写一行代码，却决定你后面要写多少代码、写完能不能上线。

观点三：返利系统的复杂度在关系绑定。一人一个邀请人、门店归属一次性、只锁一层，三条铁律必须在写代码前钉死。

四、表三 · 资金模型：100 元怎么拆

全项目最核心的一张表，也是我花心思最多的地方。前面所有合规讨论，最后都收束到这：钱怎么走，决定你合不合规。

先看最简单的第一种情形。

情形一：新客、没用余额、不在获客店，实付 100 元。

• 门店：92.00 元，货款，占 92%
• 平台：8.00 元，服务费佣金
• 推荐人：加 2.00 元余额，从平台佣金里拨

这里有个最容易想错的点。推荐奖励不从商家口袋出，也不从平台额外支出。它出自平台自己的佣金，平台收 8 元，拿出 2 元买增长，净拿 6 元。商家该收 92 元一分不少，用户该付 100 元一分不多。

情形二：用了余额抵扣。这张最关键。

老用户上次攒了 20 元余额。这次点 100 元的单，用余额抵 20，微信实付 80。

这 20 元余额要不要参与分账？

顺着每单都返的惯性想，容易按全额 100 元返。推荐人拿 2 元、门店拿 92 元、平台拿 8 元。恭喜，你算出了全项目最容易犯的一个错。

正确的拆法：不分。

微信分账只认实际发生的微信支付金额，80 元。那 20 元余额的本质，是门店给老顾客的折扣。门店少收 20 元，也就无需为这 20 元付佣金。于是 80 元这样拆。

• 门店：73.60 元，80 乘 92%
• 平台：6.40 元，80 乘 8%
• 推荐人：加 1.60 元余额，80 乘 2%

注意推荐人这次只拿 1.60 元。返利按实付算，被抵扣的 20 元没有产生现金流，自然无从返利。

门店这头呢？表面只收 73.60 元，但 20 元余额本来就是它当初让出去的折扣成本，加起来实际拿到 93.60 元的价值。它用少收 20 元换老顾客复购，这笔账在门店账本里是平的，在平台账本里也是平的。只有按原价算的账本是错的。

引出一条铁律，刻在墙上那种：

一切返利、佣金、分账，只按实付金额算，绝不按原价算。按原价算的账，表面平，一审计就穿。

为什么一审计就穿？平台分账的数据源头是微信支付的成功回调，回调里只有实付金额。按原价返利就得自己另造一套名义金额，这套金额没有第三方凭证背书。审计时每一笔都对不上微信流水，无法自证清白。按实付算，每笔返利能和微信的每笔交易一一对上，这就是合规的底气。

情形三：叠加门店获客返点。

B 被某家店拉来，回到这家店消费 100 元。

• 门店：95.00 元，92% 加 3% 获客返点
• 平台：5.00 元，8% 减 3%
• 推荐人：加 2.00 元余额，平台净收入只剩 3 元

门店为什么愿意多拿 3%？它把获客广告费直接变成给到店顾客的返点，钱花在自己店里，效果立竿见影。这 3% 由平台佣金让渡，平台用未来收入替门店补贴获客。

三种情形放一起，底层的钱规则只有一句话：

余额等于门店认可的折扣。折扣成本由门店承担，平台不核销、不垫付。返利余额只能抵扣、不能提现。真实资金从顾客直接到门店，或者经微信官方分账实时到店，平台自始至终不碰别人的钱。

这一句是资金模型的地基。地基打对，二清红线、资金池嫌疑全部自动避开。平台手里从来没有用户的货款，谈不上截留，更谈不上挪用。

演示三笔最容易算错的账，我都亲眼见过别人算错。

第一笔，把推荐奖励当额外成本。有人算每单返 2 元成本太高。真相是平台收 8 返 2 净拿 6，返利等于拿收入买增长。商家额外掏钱才叫真成本，要算进商家的让利预算，两码事。

第二笔，把余额当平台负债。用户账户有余额就紧张，平台欠钱了吗？模型 B 里余额是门店认可的折扣凭证，用户抵扣时是门店少收钱，平台只当记账员，记下这张折扣券属于谁。平台不欠用户现金，用户也兑不了现，这笔负债永远不会变成平台现金流出。

第三笔，把 8% 当净利润。有人算月流水 100 万就赚 8 万。真相是 8% 是服务费毛收入，返利 2% 从这里出，获客返点最多再让 3%，最重的情形平台只剩 3%。毛收入当净利算，是预算最常见错觉，返利产品把这个错觉放大三倍。

这张表算的根本账是每一笔钱从哪来到哪去、谁为它负责，赚多少反而排在后面。流向和责任钉死，后面写代码、过审核、谈加盟全有依据。

观点四：返利产品的资金模型只有一条铁律，按实付算、余额当折扣、平台不碰钱。谁先在这张表偷懒，谁就会在后面用封号补课。

五、表四 · 合规红线

调研阶段最怕的，从来功能做不出来，而是做出来了不能上线、上线第一天就被举报。

微信对返利分销类产品审核极严，全网公认。五条线一条都不能碰，每条都配上审核现场的画面。

红线一：仅一级返利。

A 推 B，B 每笔订单支付成功 A 得奖励。B 再推 C，A 不能从 C 的任何消费里获利。二级以上就从推荐有礼滑向拉人头获利。

审核现场：提审时审核员重点查返利规则说明。出现三级返利、团队业绩、下线消费返点这类描述，直接拒审，申诉都难。线上还有举报通道，任何一个被套的用户都可能举报涉嫌传销，每次举报都触发复查。

技术反推：返利关系只存一层，连层级树都不建。数据结构里没有我的下线是谁的下线这种查询。合规要靠结构上做不到违规，机制上杜绝多级。

红线二：余额不可提现、不可变现。

界面不出现提现入口，协议写明余额仅用于消费抵扣。后期允许转赠好友，双方依然不能提现。

审核现场：提现二字一出现，审核进入资金盘审查流程。余额从哪来、平台沉淀多少资金、资金池多大，全被翻出来。资金池是监管最敏感的地方。对用户是方便，对你是把返利营销变成准金融业务，性质完全不同。

技术反推：产品里压根没有提现这个功能，余额只存在于抵扣这一个动作里。转赠功能等产品站稳再上，上线越早被线下折价变现的风险越大。

红线三：不诱导分享。

分享文案禁分享得红包、转发解锁、分享领奖，只允许邀请好友一起来吃这类中性表达。

审核现场：诱导分享是微信明令打击的行为。分享得红包五个字，碰的是强制或利诱用户分享的平台底线，审核员连讨论余地都没有。线上运营时有人举报文案诱导，复查一样来。

技术反推：文案写死中性表达，奖励和用户主动分享的动作解耦。返利照发，但文案绝不承诺分享就给钱，奖励来自对方真实消费后的系统自动发放。增长机制保住，诱导红线远离。

红线四：严禁二清。

平台不得截留微信消费款再二次清算给门店。合规路径只有两条，服务商模式加分账让资金官方实时分账到店，或门店各自持商户号直收。

审核视角：提审时支付模式说明是必审项。用户付钱给平台、平台再转门店，直接按二清处理。

饭搭子把两条路都设计进去，一期走门店直收，二期切服务商分账。为什么分期？服务商资质申请加每家门店进件，周期不可控，功能越多首版审核越慢越敏感。先把闭环跑通、验证模式，再上重装备。完整逻辑放在系列第二篇资金模型，这里记住一句，二清是结构性的红线，第一天就要选对架构。

红线五：防薅。

有人注册一堆小号刷返利，返利产品的头号运营敌人。四件套防住：一人只认一个邀请人，数据库唯一约束；真实支付才发奖；设置最低消费门槛；同一设备、同一 IP、同一支付账户的异常注册下单被风控识别。

审核现场：这条严格说是存活红线，审核只负责把门，薅羊毛的住你家不走。返利越高、奖励越直接，被薅得越快。很多返利产品死在第一天被脚本薅穿。

技术反推：防薅写进规则，靠事后封号已经晚了。关系一次性锁死，奖励跟真实支付走，异常行为有风控识别。设计阶段花一块钱，能省运营阶段一百块。

还有一条小的：命名合规。名字要查重，不能仿冒知名品牌。蹭知名品牌边的名字，轻则改名重来，重则影响整个主体信用记录。

这张表看下来有个反常识结论。合规里最难的部分，几乎全靠产品架构解决，法务只做收尾。不做多级，就是不加层级表。不能提现，就是不设提现入口。防二清，就是第一天选对资金架构。不诱导分享，就是文案用中性表达。每一条红线，对应的是一个数据结构或一个判断分支，光发公告没有用。

收束成一句可署名的话。

合规这件事，法务兜不了底，它本质是产品架构问题。红线在需求分析阶段想清，后面全是顺水推舟。等代码写完再补，等于拆了重盖。

开工前自查清单：返利只锁一层了吗？余额有没有任何提现或变现场景？分享文案有没有得、领、奖字眼？支付架构有没有二清风险？防薅四件套都落位了吗？名字查重了吗？五条全过再谈开发。

观点五：合规是产品架构问题。红线在需求分析阶段想清楚，后面全是顺水推舟；等代码写完再补，等于拆了重盖。

六、从四张表到一份 PRD

四张表画完，决策齐了。可开发能看懂你的决策，却没法直接开工。

四张表是决策，是为什么这么做。开发需要的是需求，是具体做什么、做成什么样。决策能写一页纸，需求得拆成一条条可执行、可验收的条目。中间那层翻译，就是 PRD。

一句话讲清两者关系，也是文档的交付标准：

开发拿到你的 PRD，能复述出四张表的决策，这版需求文档才算合格。

开发读完跑来问返利锁几层、钱先进谁的账，说明 PRD 没写透，决策还在你脑子里。合格的 PRD 让开发只问实现细节，不必再问决策问题。

给一份 PRD 骨架范本，对齐饭搭子真实需求文档的章节结构，只引骨架不搬数据。九个部分。

第一部分：项目概述。

写背景、定位、目标与成功指标。背景写为什么做，定位直接抄表一那句话。

新手 PRD 最常翻车的就是指标写法，单独一节讲分寸。先记住一句：写立项时定的验收目标，不写已经做到的成绩。目标属于未来，现状属于今天，写混了就是给自己埋雷。

第二部分：用户与角色。

把表二展开，食客、门店老板、平台运营各自的目标、痛点、场景。每角色三五条就够。

饭搭子只写一期真实服务的三角色，二期角色在待确认里提一句，不让二期角色干扰一期设计。

第三部分：核心功能模块。

按页面和后台拆：点餐首页、邀请裂变、余额体系、结算支付、个人中心、门店结算后台。每模块写页面区块、核心交互、异常处理。

细到什么程度？开发照着能画出页面草图就够，像素级是设计稿的范畴，PRD 管不到那么细。但有一条写死，哪些页面本期做、哪些二期做，用模块清单划线，防止开发顺手把二期也做了拖慢首版。

第四部分：关键业务流程。

最容易被跳过、却最值钱的部分。四条主流程画出来：注册与邀请绑定、下单支付、返利与获客返点发放、门店结算。

流程要画到分支级别。余额够不够抵扣、这家店有没有获客返点、返利发放失败怎么办。按实付算的铁律在这里落地成一句开发能执行的规则，绑定的三问自查在这里落地成具体的绑定时机。

第五部分：数据需求。

列核心实体和关键字段，不要求表结构设计，但要写清系统必须记住什么。

饭搭子最核心的三样：用户及绑定关系，谁被谁邀请、从哪家店来，只写一次；余额流水，每笔增减有来源有去向，能追到订单；结算单，每笔订单的分账明细。

数据需求为什么重要？合规和返利都靠账能对上。实体清单列清，开发才知道哪些数据必须留痕。

第六部分：非功能需求。

写性能、安全、可维护性。饭搭子写了三条硬要求：支付回调必须验签并二次校验金额；幂等，同一订单不能重复发奖；金额计算禁浮点，用精确十进制。

这三条是钱的纪律。验签错了会被伪造回调薅穿，幂等错了会重复发奖，浮点算钱会算出诡异的账。非功能需求看着不性感，返利产品的命全系在上面。

第七部分：合规与风控。

把表四五条红线抄进来，标注红线需求必须满足。这一步把决策层的红线正式转成需求层的验收项。审核时、被举报时，你能拿出文档证明这产品在设计上就不具备多级、提现、二清的能力。

第八部分：分期与里程碑。

写一期做什么、二期做什么、每期怎么验收。饭搭子一期验证闭环，普通商户号直收加堂食自提加裂变。二期才上服务商分账、外卖、完整加盟这些重装备。分期背后的逻辑记在待确认事项备查，正文不用反复解释。

第九部分：待确认事项。

新手最爱删，老手最宝贝。所有没拍板、但不影响开工的问题集中记在这里，分两类。

已拍板决策，防止开发过程有人翻案，比如返利为什么只锁一层的来龙去脉。已确认关闭，讨论过决定不做的事，防止过两个月又有人翻出来重吵。口头确认的事三个月后没人记得，写进文档的才算数。

骨架就是这九段。反复讲饭搭子当时怎么定，因为 PRD 写作最大的障碍在拿不准写到多细算够，结构本身反而好办。

给一个判断标准：写完一部分问自己，开发照着这段能不能开工，会不会回来问决策问题。不会，够了。会，就补。

最后补验收写法的正反对照，新手高频雷区。

错误写法：首屏启动小于 1.5 秒、审核一次通过不低于 90%、分享打开率高于 15%、7 日留存高于 25%，然后拿这些数字当宣传卖点。数字本身没毛病，当成已达成的事实就出事了。

正确写法：立项时定的验收目标，首屏启动小于 1.5 秒、审核一次通过不低于 90%、分享打开率高于 15%、7 日留存高于 25%。以上为上线后要验证的目标，当前尚未实测。

饭搭子 PRD 里写的正是这类立项目标。这些数字是立项时定的验收线，今天还够不上成绩。需求文档能写目标，但不能把目标写成既成事实，这个分寸是需求文档可信度的分水岭。

观点六：四张表是决策，PRD 是把决策翻译成开发能执行、能验收的条目。合格的 PRD，开发读完能复述你的决策，不用回来问你返利锁几层。

七、需求分析做完，你手里有什么

到这里，需求分析完整做完。停一下，盘点手里的东西。

一份定位，问三个人能复述一致。一张角色表，三角色、两道绑定、三条铁律钉死。一张资金表，三种情形每笔钱去向都算得清。一张红线表，五条红线配上技术反推。一份 PRD 骨架，九部分，开发照此开工。一套验收写法，目标和现状分得清。

这六样，就是从一句话想法到一份可交付需求文档的全部距离。

你可能会想，一行代码没写、一个开发没联系，怎么就花掉这么多功夫。

对，这就是重点。这套需求分析的价值，在拿它询价的那一刻兑现。

预演询价现场。同样一个项目，两种问法。

问法一：帮我做个点餐返利系统，多少钱多久？对方听到模糊的需求、一个可能什么都不懂的甲方。报价里会含大量以防万一的水分，因为你说不清要什么，他只能把所有可能都算进去。更糟的是你没有衡量基准，判断不了他贵不贵。

问法二：需求文档在这，返利只锁一层、余额不可提现、支付走门店直收，一期就这些模块，验收标准在第六部分，报个价。对方听到专业甲方，不敢糊弄，报价收敛到实现成本附近，信息差利润的空间被压掉。PRD 就是议价权。

不写具体报价数字，地区团队差异太大，写了就是误导。方向确定：同一份需求，做完分析和没做分析，询价口径完全不同，省下的钱远超写文档花的时间。

需求分析这站走完，关于项目本身的功课告一段落。接下来轮到你一开始就想问的：用什么技术栈？组团队、找外包还是用 AI？怎么验收交付？

这些答案全要建立在这份需求文档之上。没文档谈选型和交付，等于没图纸谈施工队。

下一篇讲技术选型与交付：怎么从需求倒推技术栈，怎么在组团队、找外包、用 AI 三条路里选，交付拿什么标准验收。第二篇资金模型先补本篇只给了结论的账务细节，分期逻辑、获客返点动态配置、结算对账，留给那篇专门算。

你手里这份需求文档，就是整个系列的通行证。

写在最后

回开头那个饭局。现在你知道了，那个听起来不难点餐返利项目，真正难的部分在代码之前：钱怎么走、关系怎么锁、合不合规。

这篇用饭搭子走完全程。回头看你攒下的东西，定位、角色、资金、红线、PRD 骨架、验收口径，它们有个共同点，全部不依赖技术、全部可验证、全部是你能自己做完的功课。

发起人的护城河，在需求红线加资金模型加合规边界，代码反而排在后面。代码能外包、能组队、能让 AI 写，但钱怎么走、关系怎么锁、哪条线不能碰，外包不会替你想，团队未必替你想，AI 只会顺着你的含糊继续含糊。

这三件事想清并写进文档，项目成了一半。剩下的一半，才是技术问题。

这类产品做之前，最怕功能做不出来，更怕结构选错了还在埋头赶进度。花一个下午把四张表画完，比花一个月把代码推翻重写便宜太多。

这篇就聊到这。你在做类似的项目、卡在想法有了不知道从哪下手，评论区聊聊卡在哪一步。钱不知道怎么走、关系不知道锁几层、还是压根不知道怎么把想法说清，每一条我都会看。

常见问题直答

问：需求分析写到多细算够？

答：写到开发能照此开工、不会回来问决策问题就够。判断标准一条：PRD 交给开发，他读完能复述你的四张表决策，写透了。反过来问你返利锁几层，说明还停在你的脑子里。不追求厚度，追求决策完整。

问：没有支付牌照能做返利吗？

答：能，前提平台不碰钱。合规路径只有两条：门店各自持商户号直收，或平台做服务商靠官方分账让资金实时到店。共同点是货款不经平台之手，自然不存在截留资金二次清算的问题。没牌照还截留资金做二清，那才是问题。

问：返利会被判传销吗？

答：边界清楚就不会。判定传销的核心在拉人头获利和层级收益。你只锁一级，A 只能从直接带来的 B 的消费获利，B 拉 C 与 A 无关。你发余额不发现金，余额只能消费抵扣。奖励由真实消费触发，注册不送。三个设计叠加，离传销认定标准很远。反过来上了层级、开了提现，性质立刻变。

问：余额为什么不能提现？

答：能提现的返利余额等于资金池，资金池等于资金盘嫌疑，监管最敏感。余额一旦能提现，平台账户沉淀大量待兑付资金，规模一大你就从营销工具变成准金融平台，资质要求完全不同。把余额设计成只能消费抵扣的门店折扣，用户得实惠，平台避开资金池，双赢结构。

问：PRD 自己写还是让开发写？

答：决策层自己写，实现层让开发补。定位、角色、资金模型、合规红线这些决策，必须发起人想清并写进文档，这是护城河。每个功能怎么实现交给开发补充。可操作的分工：你写四张表和 PRD 的骨架与决策部分，开发补实现细节，最后验收他有没有改你的决策。

问：找开发之前最该先确认什么？

答：先确认三问和四张表。钱进谁的账、返利锁几层、返利谁出钱，三问答不清先别找人。答清了，把四张表和 PRD 写出来再询价。带着需求文档询价和空手询价，得到的报价和建议是两个水准，文档就是议价权。技术栈、工期、报价怎么谈，是拿到文档之后的事。

我是「随生门户」的主理人，长期写 AI 与 Java 生态、以及从 0 到 1 做产品的落地实战。

正在做技术学习产品「颐启学点」。

如果这篇对你正在做的项目有帮助，欢迎在评论区聊聊你卡在了哪一步。