简介：一份51信用卡管家APP的产品需求文档，面向产品经理、交互设计师及金融科技从业者，用于学习如何从用户、业务、交互等维度撰写完整PRD，并理解信用卡管理类App的常见功能设计与业务流程。文档为docx格式，共1个文件，压缩包大小2.95MB。内容覆盖产品概述、体验环境、核心功能（账单管理、还款、借贷、理财）、用户画像、产品结构图、全局交互规则以及登录、账单、消息等关键页面的原型交互展示，并结合成长值、会员等级、砍账单等特色功能进行说明。目前已有202人学习，适合需要参考金融类App需求文档或提升产品分析能力的人群。

1. 为什么值得拆 51 信用卡管家：倒推式 PRD 能练什么

「51 信用卡管家 app 产品需求文档.docx」这份资源，是一位产品从业者用 Axure 把 51 信用卡管家从使用、体验、研究三个角度完整倒推出来的一份 PRD 文档。它不是官方产品说明，也不是功能清单，而是把一款真实运行的金融类 App 拆解成「需求文档」的完整样例。文档覆盖了登录注册、账单导入、消息、财富、借钱、发现、我的等主要模块，还补了公积金查询、我的红包这类延伸功能，并且单独写了网络异常、交互规则、业务逻辑这些全局说明。适合想转岗产品的人、刚起步的产品助理，以及那些想知道一份 PRD 到底该写多细、原型该画到什么程度的从业者。看完你能拿到一套可复用的 PRD 骨架，以及具体的原型交互参考。

2. 先定骨架：五大模块与成长值体系怎么落到文档

2.1 五大模块的职责边界：账单是核心，其余都是业务延伸

文档里产品结构图把 App 分成账单、财富、借钱、发现、我的五个模块。拆解一款产品的时候，最直接的做法是打开 App 看底部 Tab 栏，一个 Tab 对应一个一级业务模块，文档目录就出来了。51 信用卡管家这五个 Tab 的边界很清晰，我用结构树整理一下：

51信用卡管家 App ├─ 账单：账单导入、信用卡更新、账单详情、还款、砍账单入口 ├─ 财富：51产品详情、基金产品详情、投资券使用 ├─ 借钱：信用借款、借款券、运营商信息认证 ├─ 发现：金融资讯、知识内容、活动入口 └─ 我的：个人信息、我的红包、公积金查询、设置

这个结构最值得学的地方在于「账单」为什么被放在核心位置。信用卡用户的真实诉求是账单管理——先导入账单，才能知道欠了多少钱、什么时候还；还款动作完成之后，用户对资金的需求才会浮出水面，这时借钱和理财才有转化入口。也就是说，账单是获客和留存工具，借钱和理财是变现工具，发现负责增加打开频次，我的承载用户资产信息。做 PRD 的时候如果搞不清这个主次关系，评审会上会被反复追问「为什么借钱入口放在财富前面」「为什么发现模块要占一个 Tab」。

对比一下常见误用，很多新手拆 App 会把所有页面平铺列出来，账单、财富、借钱、发现、我的各写一页，页面之间没有逻辑关联。这份文档的做法是先定业务归属，再定页面优先级，表格里可以看得更清楚：

你倒推其他 App 的时候，先把这个表画出来，再往下写原型，效率会高很多，章节结构也不会跑偏。

2.2 成长值体系：等级阈值、权益映射与发券逻辑

文档名词解释部分定义了一套成长值体系，这是 51 信用卡管家的用户分层基础。成长值由用户在应用内的行为综合计算出来，包括管理账单、绑定信用卡数量、投资、贷款等。等级分为五档：新手会员 0～150 成长值、普卡会员 150～500、银卡会员 500～1500、金卡会员 1500～3500、白金会员 3500 以上。

这套体系单独看就是一组数字，但放进业务场景里才有意义。文档同时定义了还款金、投资券、借款券、砍账单四类资产：还款金可用于信用卡还款时抵扣；投资券用于投资时加息或调整利率；借款券是借款时的抵费券；砍账单是邀请好友助力，随机获取金额，可叠加在还款场景使用。

从 PRD 写作的角度看，这组定义的价值在于「把后端逻辑前置到名词解释里」。成长值怎么计算、各等级有什么权益、券怎么核销，这些都是后端逻辑，前端只负责展示余额和使用入口。很多新人写 PRD 会把成长值计算规则写在某个原型页下面，结果同一套规则在不同页面重复出现，口径还不一致。文档这种做法是把规则抽到顶层，原型页直接引用，评审的时候所有人看的是同一份定义，这是值得复用的写法。

砍账单是另一个值得展开的运营功能点。它的核心是社交裂变：用户发起砍账单，分享给好友，好友进入后帮砍一个随机金额，砍下来的钱可用于还账单。PRD 里如果只写「邀请好友随机获取金额」，开发会不知道怎么实现——随机金额的范围是多少、同一个好友能不能重复砍、一个账单能发起几次。文档里定义得还不够细，这部分我在第 5 章避坑清单里会专门说。

2.3 从结构图到原型页面的顺序：先画信息架构，再补交互

文档的目录顺序是产品概述、名词解释和功能点、产品结构图、全局说明、部分功能原型交互展示。这个顺序本身就是一份合格 PRD 的标准骨架。

我见过很多新人拿到 Axure 就开始画页面，画到一半发现交互规则不知道放哪儿，数据加载方式也不知道怎么写，最后把所有注释都堆在原型页顶部，评审会上别人根本看不完。正确顺序应该是先写清楚产品目标和用户画像，再画信息架构图，然后把所有页面共用的交互规则抽到「全局说明」里，最后才动手画具体原型页。

这样做的原因很实际：全局说明就像代码里的公共函数。toast 展示几秒、弹框点外部能不能关、键盘弹数字还是字母、网络异常怎么展示，这些规则如果拆到每个页面单独写，写十页就累了，写到后面还会有遗漏和冲突。抽成公共规则后，原型页里只需要写「参照全局说明 3.2」，页面干净，评审效率也高。这份文档的全局说明写得尤其细，下一章单独拆开讲。

3. 全局说明才是 PRD 的底子：网络异常、交互规则和数据约定

3.1 网络异常的三级反馈：缓存兜底、浮窗提示、toast

一般 PRD 里网络异常就是一句话：「断网时给出提示」。这份文档把场景拆成了三种级别：

网络请求失败 ├─ 页面有本地缓存 → 展示缓存数据 + 页面底部浮条提示网络异常 ├─ 页面无本地缓存 → 展示插图和提示性文案 └─ 非一级页面请求失败 → toast 提示网络异常，2 秒后自动消失

第一层「有缓存就展示缓存数据」，这是金融类 App 特别在意的取舍。用户打开账单页面最怕白屏，账单信息加载不出来，用户会焦虑，甚至担心自己欠款出了问题。所以账单、财富这类一级页面必须做本地缓存兜底；同时因为数据可能是旧的，页面底部要常驻一个浮条提示「网络异常」，而且这个浮条只有网络恢复正常才消失，或者用户手动删除，不能用 toast 一闪而过——网络异常不是临时事件，toast 展示两秒就没了，用户根本没看到。

第二层「无缓存就展示插图加文案」，适用于首次安装、还没有产生本地数据的场景，这时候没有数据可兜底，只能给一个友好的空状态引导用户重试。

第三层是次级页面，比如资讯消息类内容页，这类页面数据可以接受短暂加载失败，toast 提示一次就够了。

PRD 写到这里，开发不需要追问「到底什么时候弹什么」，直接按层级实现测试用例也有依据。如果你倒推的是工具类、社交类 App，这套三级反馈思路同样通用，差别只在缓存策略和提示级别的选择上。

3.2 交互规则的细节：toast、dialog、浮窗、键盘、生物识别、空状态

文档的全局说明里列了六类交互规则，每一条都可以原样抄进自己的 PRD 模板：

操作反馈 toast：反馈型 toast 展示时间为 2 秒，文案按对应交互场景设计，iOS 位于屏幕中间，Android 位于屏幕偏下。这里的关键参数是 2 秒，太短用户看不清，太长又挡内容，两个平台的位置差异也要写明，否则 UI 验收的时候风格不统一。

进程型 toast：需要带 icon 和文案反馈当前进程，比如「正在加载」「正在登录」，进程结束后消失。这类反馈适合耗时操作，但注意不能和加载动画混用，一般页面局部刷新用 toast，整页加载用 loading 态。

dialog 弹框：必须用户点击弹框上的 button 才消失，点击页面其他地方弹框不消失。这条最容易踩坑——移动端不少弹框设计是点击遮罩层关闭，但支付确认、借款协议这类强确认场景如果也能点外部关闭，用户误触一下就完了。所以文档这条规则是在保护用户资产安全，写 PRD 时要把「点击外部不消失」作为默认约定，除非明确标注某个弹框允许点击遮罩关闭。

异常情况浮窗：异常消失或者用户手动点击删除才会消失。典型场景就是网络异常时一级界面展示缓存数据，用浮窗而不是 toast，因为浮窗常驻，能让用户持续感知数据不是最新状态。

键盘规则：用户点击手机号码、验证码、金额、身份证号码、支付密码等输入框时弹起数字键盘；点击登录密码等需要输入文本的位置弹起常规键盘。这条看起来基础，但很多 App 实际做出来验证码输入弹的是全键盘，用户切数字要手动点，体验很差。PRD 里明确写明输入框类型和对应键盘类型，开发就不用猜。

生物识别：用户开启手势密码和生物识别后，优先使用生物识别；生物识别不了才回落到手势密码。这条逻辑在金融 App 里是安全性和便捷性的平衡，很多产品把顺序搞反，逻辑写得不清不楚。

空状态：页面正常情况下没有数据时，展示插图配提示性文案，必要时根据场景增加引导 button 或链接。比如账单列表为空时，除了「暂无账单」文案，还要给一个「导入账单」的引导按钮，这才是合格的空状态设计。

六类规则的表格整理如下：

3.3 业务逻辑和数据说明：借款认证、开户约束与缺失的数据说明

文档业务逻辑部分写了两条硬性规则：用户借款时需要真实信息和运营商信息认证；用户投资时需要开通北京银行个人账户。

第一条说明借款流程依赖第三方征信和运营商数据，PRD 里要明确前置认证条件——不是用户点击「借款」就能借，而是先完成实名认证、运营商认证，系统才有依据评估授信额度。写这类需求时，字段清单要包括真实姓名、身份证号、手机号服务密码或运营商授权 token，认证失败的分支也要写清楚。

第二条说明理财业务的资金账户是银行存管模式，51 信用卡管家只做导流和产品展示，用户的资金账户开立在合作银行。这个业务边界不写清楚，开发会默认 App 自己维护资金账户，对接起来就出大问题。

需要提醒的是，文档里第 4 节「数据说明」实际是空白的，没有给出具体字段定义。这是这份文档最大的缺口——PRD 写到全局说明阶段，至少要把账单、用户、消息这三类核心实体的字段列出来，开发才能评估工作量、测试才能设计用例。这一点我在第 5 章会专门展开讲，真拿到文档照着画原型的时候，这块必须自己补上。

4. 登录注册与账单导入：验证码规则和短信更新流程怎么拆

4.1 登录注册流程：三种登录方式与验证码限流规则

登录注册是每个 App 逃不开的模块，51 信用卡管家同时支持账号密码登录、手机验证码登录和第三方 QQ/微信/微博登录，注册流程里还带了邀请码机制。

流程拆出来是这样的：手机号注册后，先通过验证码验证身份，验证通过后用户可自主设置账号密码；如果用户走第三方授权登录，登录后必须绑定手机号完成身份认证。注册时可选填朋友给的邀请码，用于后续运营活动追踪。

文档里最有价值的是验证码获取规则，写得很定量：

• 同一手机号只能绑定一个账户；
• 2 分钟内不可多次请求验证码，同手机号 2 分钟内第二次请求时，toast 提醒「请求验证码过于频繁，请 1 分钟后再试」；
• 一天最多请求 6 次验证码，第 7 次请求时 toast 提醒「今天已请求 6 次验证码了，请明天再试」。

这两条规则本质上是后端限流策略的前端表现，2 分钟和 6 次是服务端限制，前端只是把限制结果翻译成用户能理解的文案。PRD 里如果只写「验证码 60 秒后可重新获取」而不写明当天的上限次数，会被滥发短信攻击，短信费用和风控都出问题。我建议照文档的写法把限制参数和 toast 文案放在一张表里，评审时后端、前端、测试三方口径完全统一：

这里还有一个细节：验证码输入错误后的处理、验证码有效期（常见是 5 分钟或 10 分钟）、重新发送后旧的验证码是否立即失效，这些文档里没有展开。实际写 PRD 时建议补上「验证码有效期 10 分钟」和「重新发送后旧码作废」两条，后端实现时常见做法是以最后一次下发的验证码为准。

提示：验证码相关的文案和参数属于「运营配置」而不是「硬编码」，PRD 里最好标注这些参数可通过后台配置修改，避免以后改个数字还要发版本。

4.2 账单导入与信用卡更新：验证码弹框交互细节

账单模块是整份文档的重点。前置条件很明确：用户需要先导入账单，才可以在首页查看账单、接收账单通知。也就是说，未导入账单的用户进入首页看到的是空状态引导页，而不是直接展示一个空列表。

页面逻辑拆开看分两种路径：普通账单导入时，用户利用手机验证码或者登录第三方账户，验证身份后获取最新的账单信息；信用卡更新账单时，交互就更细了：

1. 用户点击「更新」按钮，按钮文案变为「输入验证码」，同时服务器下发短信验证码；
2. 用户点击「输入验证码」，弹出验证码输入弹框；
3. 用户输入验证码，判断正确后账单开始更新。

文档作者在页面描述后加了一条个人建议：「点击更新账单后，验证码弹框和数字键盘自动弹起，用户即可填入验证码进行验证。」这条建议是一个典型的交互优化点——如果用户点了「输入验证码」之后还要再点一次弹框、再等键盘弹起来，多一步操作体验就钝了。PRD 里写功能描述时顺手补这么一句「建议」，评审会上的观感会明显不一样，说明你已经把交互走查过了。

信用卡更新账单这个流程里还有几个隐含状态值得写进 PRD：更新中按钮要置灰并显示加载状态；验证码输入错误时的 toast 反馈；服务器下发验证码失败的异常分支；验证码过期后怎么重发。文档只描述了主流程，分支状态需要在使用 Axure 画原型时自己补齐，评审会上开发最常追问的就是「验证码错了怎么办」。

4.3 借钱与理财的原型展示：外部业务嵌入的边界

财富、借钱这两个模块的原型页包括 51 产品详情、基金产品详情、借钱列表等。这些页面本质上是第三方业务的容器页，App 本身不做资金和风控，只是把第三方的产品或借款产品接进来，展示给用户。

写这类页面的 PRD 时，业务逻辑不用从零定义，但要明确三个边界：一是跳转规则——用户在 App 内点击产品卡片，是跳到 H5 页面还是原生页面、是否需要登录态透传；二是数据来源——产品列表和利率信息由第三方接口提供，App 只负责展示，接口字段和刷新策略要写清楚；三是授权流程——用户借款时需要的真实信息和运营商认证，这个动作在 App 内完成还是跳转到第三方 SDK 完成，决定了对开发的工作量评估。

文档对这两块的描述就是标准的「透传式」写法：说明前置条件，交代认证要求，然后交给第三方。这样处理是合理的——第三方业务的细节不该占用核心精力，PRD 写得越重，评审时越容易被细节拖住。

5. 避坑清单：这份 PRD 里最容易被细节坑到的五个地方

5.1 「数据说明」是空的，评审会上被追问到哑口无言

现象：文档全局说明的第 4 节标题是「数据说明」，但正文里没有给出任何字段定义和数据结构，整节是空的。

原因：原作者大概率是把字段细节留在了 Axure 原型的分页里，没有整理进文档。这种「原型里有、文档里没有」的情况非常常见，文档一旦脱离原型单独流转，数据定义就彻底丢了。

解决：必须补一张数据字典表，至少覆盖三类核心实体——用户（用户 ID、手机号、姓名、成长值、会员等级）、账单（账单 ID、卡类型、账单金额、还款日、账单状态、所属用户）、消息（消息 ID、类型、标题、内容、发送时间、已读状态）。字段要标明类型、长度、是否必填、默认值，开发拿着就能建表。

5.2 账单详情页没有展开，核心页面反而写漏了

现象：文档目录里有「账单详情」，但正文部分账单写完就跳到消息模块，账单详情页的原型和交互逻辑没有实际内容。

原因：账单详情是字段多、状态多、操作多的页面，写起来麻烦，容易被跳过。这是 PRD 写作的老毛病——首页写得很详细，二级页面一笔带过。

解决：账单详情页单独拆一小节，至少列出三类信息：账单基础字段（账单金额、最低还款额、账单日、还款日、卡种）；状态分支（未出账、已出账、逾期、已结清），每个状态的展示内容不同；操作按钮（还款、分享、砍账单）在不同状态下的可点击性。文档在交互规则部分已经定义了「可操作、不可操作、操作后」三种状态，这里正好应该引用。

5.3 产品目标写得无法验收，评审时说不出成功标准

现象：文档产品目标里有「提高用户体验」「拉取更多用户」「增强用户活性」这类句子，没有量化指标。

原因：目标写成了方向，没有写成分解后的指标。方向本身没错，但开发、测试、运营无法判断「做到什么程度算达标」。

解决：改成可衡量的指标。「支持市面上大部分机型」可以写成「兼容 Android 10.0 及以上、iOS 13.0 及以上，主流机型覆盖率 ≥ 95%」；「极速借款」可以写成「从点击借款到授信结果返回平均时长 ≤ 3 分钟」；「拉取更多用户」可以写成「砍账单活动新增用户占比 ≥ 20%」。评审会上这样写，每一项都能被验证，而不是被一句「需求不清晰」打回。

5.4 成长值体系只定义了数值，没有落成页面和入口

现象：名词解释里写了成长值 0～150 是新手会员、150～500 是普卡会员，但原型展示部分没有对应的等级说明页或成长值明细页，用户看不到自己的等级和权益。

原因：成长值体系作为后端逻辑定义了，但前端页面没有同步设计。用户在一个产品里感受不到等级的存在，整个体系就废了。

解决：在「我的」模块补上成长值入口，点进去展示当前等级、距离下一级还差多少成长值、各等级权益对照表。顺手把等级权益和发券逻辑打通——还款金、投资券、借款券的发放规则应该在等级页里有所体现，比如「银卡会员每月可领 1 张还款金」。功能点之间不打通，PRD 就还停留在概念层。

5.5 砍账单规则不完整，开发拿到需求无从下手

现象：文档定义砍账单是「邀请好友，随机获取金额数，可用于还账单时使用」，但缺少最关键的运营参数：随机金额范围、单笔账单可砍次数、同一好友能否重复砍、砍下来的金额有没有提现门槛。

原因：砍账单是运营活动，运营还没给出确定口径，产品就把一个不完整的功能写进了 PRD。这在团队里会造成两个后果：开发排期不准确，测试用例没法设计。

解决：把砍账单当成一个完整的功能点，补全参数：活动时间（起止日期）；金额上下限（比如单次砍掉 0.5～5 元）；每个账单可发起砍价的次数（比如 3 次）；同一好友对同一账单只能助力 1 次；好友助力需要关注的验证条件；砍下来的金额进入还款金账户还是单独的活动账户。参数不一定全由产品定，但 PRD 里要留出明确的运营配置位，并在备注里写明「以上参数由运营端配置，后端按配置下发」。

6. 进阶用法：拿这份 PRD 当模板倒推其他金融 App

这份文档最好用的场景，是当模板去倒推另一款 App。我拿它试过一次记账类 App，整个流程走下来大概五步：

第一步，用 Xmind 把目标 App 的底部 Tab 栏拆成一级模块，明确哪些是自研业务、哪些是第三方合作业务，这一步决定了后续的工作量分配。第二步，逐个 Tab 截图记录页面元素，把每个页面的字段、按钮、状态写出来，参照账单模块的写法标注交互分支。第三步，直接复用文档里的全局说明——网络异常三级反馈、toast 2 秒、dialog 点击外部不消失、数字键盘规则、空状态设计，这些规则在金融类 App 里几乎全量通用，不需要重新定义。第四步，抽业务规则，重点参考登录注册里验证码限流的写法，把成长值、积分、还款金这类运营资产抽象成名词解释加等级表，单独成节。第五步，选一个核心流程做深度拆解——像 51 信用卡管家的账单导入一样，拆到「异常情况都注明」的程度，然后对照第 5 章的避坑清单检查数据说明有没有补、账单详情页有没有漏。

我第一次独立写 PRD 的时候直接把 Axure 原型的链接丢给开发，注释全写在原型页顶部，开发审完跟我说看得很痛苦，每个页面的边界条件都要追问一遍。后来我强制自己先写结构图，再写全局说明，最后画原型，迭代三版之后评审会基本不用再解释页面逻辑了。从那以后我每次倒推 App 都强制走一遍这套流程，先骨架后细节，先规则后页面。这份文档的价值就在于此——它提供了一套可以直接照做的 PRD 骨架，你唯一要做的就是拿一个真实 App 去练一遍。希望帮到你。

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