简介这是一份互联网金融产品需求文档PRD模板面向产品经理、项目经理及金融业务人员用于规范产品从立项、需求收集到上线的全流程设计。文档基于V2.0版本结构清晰包含产品概述、背景描述、产品目标、Roadmap、预期时间以及业务模型、用户角色、功能清单、功能需求等章节其中登录、注册、我的账户、红包等模块均配有业务概述和行为者说明并附有用例图作为参考。包体为1个PDF文件大小3.88MB适合通读与直接复用。目前已有268人学习下载适合正在搭建互金产品框架或需要快速输出规范PRD的读者。通过这份模板可掌握金融场景下背景梳理、竞品分析、合规要求、功能优先级划分的落地写法减少从零起草的时间同时为团队评审、需求排期和后续迭代提供可复用的文档基础。1. 一份互联网金融 PRD 的 PDF到底在解决什么问题很多人拿到一份名为《互联网金融产品需求文档(PRD).pdf》的模板以为这就是一份“照着填就完事”的表格。其实能落地的金融产品 PRD解决的从来不是“有没有文档”的问题而是让产品、研发、测试、风控、法务甚至财务在同一个页面看到一致的钱、账、权、责。它适合做借贷、理财、支付、保险等有资金流转的产品的从业者。下面不假设你手里有现成 PDF只按可复现的路径讲核心要素怎么定、转 PDF 时怎么留痕、哪些坑会让文档和实现分家。标题里的 PRD 和 PDF 是两个问题内容怎么组织形式怎么交付。2. 把 PRD 拆成“金融产品”之前先立住这 4 个核心要素2.1 为什么互联网金融 PRD 不能只写功能流程功能型 PRD 可以写“用户点击按钮提交借款申请”到这一步开发能开始写代码。但互联网金融产品不行因为同样一次点击背后至少有四件事没有说清楚资金从哪来、账务记在哪、风险怎么拦、合规要件是否齐。少任何一件开发做完后会发现风控系统没接、资金通道没配、财务对不上账返工成本比写文档高一个量级。我一般会在动笔前先回答四个问题资金流是什么走向、哪个环节会产生账务记录、哪些节点需要风控判断、哪些字段是监管或协议要求的必填项。回答完之后再写功能功能只是这四个答案的外壳。反过来如果一份 PRD 评审时被问“万一放款失败怎么办”答不上来说明状态机没写完整不是评审人苛刻。这里放一张对比表用来检查你的 PRD 是功能导向还是资金导向。检查项功能型 PRD 常见写法金融型 PRD 应有写法借款申请用户填写资料提交填写资料后先过反欺诈与准入规则通过才允许提交提交即锁定申请号额度计算根据用户输入返回额度额度模型评分/风控策略结果记录计算版本号便于回溯放款点击放款按钮放款前二次校验银行卡、额度、当日限额失败走冲正还款自动扣款扣款顺序、宽限期、失败后重试策略、人工兜底入口差异的核心在于功能型描述的“人做了什么”金融型描述的是“系统在什么条件下做什么以及钱和状态怎么变”。后者的描述方式开发和测试才能做成可判定“通过/失败”的需求。2.2 用户故事要带资金、合规和异常分支示例怎么写常见的用户故事模板是“作为某角色我想要某功能以便某价值”。用在互联网金融里太薄。比如“作为用户我想要借款以便周转”——开发拿到手只能猜借款金额上限利率怎么算逾期了怎么办所以我会把用户故事改成“带条件的业务场景”并把非功能需求也塞进描述里。具体做法是用一个需求条目模板把每个功能点写成一组可测试的字段。下面是一个 YAML 形式的模板适合在文档里作为“需求编号-001”的示例需求编号: PRD-LOAN-001 场景: 用户在小程序提交借款申请 触发条件: 用户完成实名认证且已绑定银行卡 资金流: 来源: 平台资金池 去向: 用户绑定银行卡 手续费: 借款金额 * 0.2%向下取整 风控节点: - 反欺诈检查 - 额度占用检查 - 银行卡四要素校验 合规字段: 必填: [身份证号, 人脸识别回执, 借款协议版本号] 加密存储: true 状态流转: 初始: 草稿 提交后: 审核中 审核通过: 待放款 审核拒绝: 已拒绝 异常分支: 风控超时: 提示稍后重试状态保持草稿 放款失败: 自动冲正并通知用户 验收标准: - 风控判定拒绝后用户端不显示授信额度 - 借款协议版本号必须等于当前最新版本逻辑说明这里每一行都不是摆设。“触发条件”决定了这个需求什么时候能进入流程“资金流”把来源和去向写死开发才知道调哪条通道“风控节点”不能是“调接口”三个字要写明检查项顺序“状态流转”里没有为客户展示的步骤因为那属于另一节。参数说明需求编号建议按产品线加模块命名例如 PRD-LOAN 表示借贷模块后面接三位序号。这样评审、测试、缺陷单都能直接引用编号而不是引用章节标题。人脸识别回执在多数方案里会保存 6 个月以上所以要在合规字段里写出存储要求而不只是“必填”。2.3 状态机与资金流借贷/理财/支付产品的骨架金融产品里最“贵”的部分不是页面而是状态机。因为状态一旦错钱就会错。状态机的写法不是画一张图就结束而是列出每个状态的条件、动作和失败去向。下面用借贷产品的还款状态做示例用表格列关键状态。状态触发事件前置条件后置动作失败分支正常还款日系统发起扣款绑卡有效、余额充足扣款成功更新账务扣款失败进入“扣款失败”状态扣款失败银行返回失败无记录失败原因进入宽限期超宽限期仍未成功进入“逾期”逾期宽限期结束未还清上报征信推送催收任务用户主动还款进入“已结清”已结清还款完成欠款为零关闭账务生成结清证明无这张表的价值在于后置动作和失败分支必须同时存在。很多 PRD 写了“还款日自动扣款”但没有写“扣款失败后是 T1 重试还是进入宽限期”导致测试拿到需求都不知道怎么构造场景。所以我在写状态机时会强制自己在每个成功状态旁边写一个失败去向没有失败去向的就不算完成。资金流要跟着状态机走。比如“放款中”这个状态钱已经在途但账务上还不能记为已放款。PRD 里要写清楚“到账确认”的触发是银行异步通知还是日终对账因为开发实现方式完全不同。这一点我会在评审时专门用红色标出。2.4 合规字段表把“要件”前置到需求里互联网金融产品离不开实名认证、协议签署、风险提示、征信授权这些环节。它们不是简单表单而是有明确留存和展示要求的数据项。把合规字段前置到 PRD 里能避免开发把“协议勾选”做成一个 checkbox结果法务问起来却拿不出版本号。下面是我常用的合规字段清单节选字段类型来源是否必填加密/存储要求展示位置身份证号文本实名认证接口是加密存储脱敏展示借款申请页人脸识别回执 ID文本人脸服务商回调是原样存储关联用户认证记录详情借款协议版本号文本协议服务是随申请单保存确认借款页风险提示确认时间时间戳客户端回传是不可篡改电子签名页注意这里不写“必须用 xx 存储”这类方案级决策因为每个公司技术栈不同。要写的是“结果要求”需要加密、需要不可篡改、需要可追溯到某次操作。具体技术选型留到设计文档里。PRD 如果连“风险提示确认时间”都没有那上线后万一发生纠纷你连用户看没看过提示都说不清。3. 从 Word 到 PDF金融 PRD 的排版、导出与版本留痕3.1 模板结构封面、修订记录、字段表、流程图的位置先定结构再写内容。一份金融 PRD 的 PDF我建议按下面这个顺序组织封面产品名称、版本号、撰写人、评审人、日期。封面不承载内容但承载“责任人”。修订记录每次变更都要加一行写清版本号、变更内容、变更原因、作者、日期。目录在 PDF 里目录必须可跳转不能只是文字。正文从业务背景开始到功能需求、字段表、状态机、异常分支、验收标准。附件流程图源文件、接口文档链接、合规条款原文。这个顺序的核心逻辑是让一个刚接手的人能从上至下先知道“为什么做”再知道“做成什么样”。目录在 Word 里有自动生成转 PDF 后保持超链接这一步不能省。很多模板会把修订记录放在最后这是一个反模式评审人拿到 PDF第一件事是看这是不是最新版放在封面上或封底都不如放在目录前直观。我会在文档里放一个“文档速览”表格列出模块、对应页码、负责人。这样 PDF 打印出来开会时可以直接按页码翻到对应部分。3.2 用 Word/Markdown 产出后转 PDF 的两种路径常见做法是先用 Word 或 Markdown 写正文再转 PDF。两条路径我都用按场景选。路径 AWord 直接另存为 PDF。适合已有 Word 模板、需要多人协作修改的团队。关键是字体嵌入否则换一台机器打开可能出现乱码或排版错位。操作是文件 - 选项 - 保存 - 将字体嵌入文件勾选“仅嵌入文档所用字符”。转出后要抽查三处目录是否可跳转、表格是否跨页断行、批注是否消失批注在 PDF 里会被忽略所以重要评审意见必须落到正文或修订记录。路径 BMarkdown 配合 Pandoc 转 PDF。适合对排版要求不高的内容型文档优点是好追踪每次变更。下面是一个常见命令pandoc prd.md -o prd.pdf \ --pdf-enginexelatex \ --variable mainfontSource Han Sans SC \ --variable sansfontSource Han Sans SC \ --variable monofontSource Han Sans SC \ --variable geometry:margin2.5cm逻辑说明--pdf-enginexelatex是为了处理中文字符默认 LaTeX 引擎遇到中文会直接报错mainfont指定正文和中文界面字体如果没有思源字体可以换系统中文字体名geometry:margin控制页边距。Markdown 转出来的 PDF 表格样式相对朴素需要额外 CSS 或 LaTeX 模板所以我的习惯是正文用 Markdown最终用 Word 排一版封面和修订记录再转 PDF。参数说明--toc可以加目录但 Markdown 的章节层级要清晰。如果文件里有 PNG 流程图建议先统一分辨率为 300 dpi否则 PDF 里会虚。字体嵌入在 Pandoc/LaTeX 路径里默认做这点比 Word 省心。3.3 PDF 里图片、表格和批注怎么处理才不“糊”图片不清晰的来源大多是截图分辨率低。PRD 里的流程图、原型图如果用截图至少放大 1.5 倍再截或者在导出设置里选择“保真”而不是“压缩”。我在交付前会做一个检查把 PDF 拉到 200% 看流程图上的文字是否还能认出来。认不出来就让画图的人重新导出不要硬调对比度。表格的“糊”通常不是像素问题而是跨页断行。解决方法是给表格的标题行设置“重复标题行”并在 Word 表格属性里勾选“允许跨页断行”的合理版本。转 PDF 后跨页表格必须有连续性。另外表格列宽不要超过正文边距金融 PRD 的字段表经常有长文本过多的换行会降低测试同学逐行核对的速度。批注的处理和很多人想的不一样PDF 的批注不是正式内容开发很可能不装能看批注的阅读器直接把 PDF 发给测试批注就丢了。所以我要求评审期所有批注必须在一个工作周期内合入正文重新导出一版 PDF而不是等定了再合。PDF 编辑器的作用主要体现在这里用福昕或搜狗这类编辑器的“审阅功能”做圈改改完合入再导出分发给所有人。3.4 让 PDF 里的文字可以被检索OCR 与导出设置金融 PRD 的 PDF 经常被拿来检索关键词比如“征信”“冲正”“结清”。如果文档里有大量图片截图关键词搜不到就会有人用 pdf 解析工具去转 Word结果发现图片还是图片白折腾。所以我的原则是能用文字绝不放图。尤其是协议条款、字段名称、状态名必须落在文本层。如果确实只能用图片某个旧系统截图我会在图片下方用文字补一句可检索描述例如“图 3-1 放款失败冲正流程文字描述见 3.2 节”。或者对截图做 OCR至少保证 PDF 可以被检索。Windows 上可以用 PDF 阅读器的文字识别功能Mac 上自带预览也有“提取文本”的能力。做完 OCR 后用下面的 Python 代码验证 PDF 是否可检索import pdfplumber with pdfplumber.open(prd_loan_v1.2.pdf) as pdf: for page in pdf.pages[:5]: text page.extract_text() if text and 冲正 in text: print(f第 {page.page_number} 页可检索到关键词)逻辑说明pdfplumber 从 PDF 的文本层抽取文字如果截图没有 OCR这段代码什么都抽不出来输出为空。它不能证明“每个词都检索得到”但至少能发现最明显的文本丢失。参数说明pages[:5]只需要检查前几页因为关键字段表通常在前半部分。如果某些内容本身就在图片里这里的检查会漏掉所以必须配合人工按章节抽查。实际项目里我会在交付前跑一段类似的脚本把每个章节标题和几个核心词如“额度”“逾期”都检查一遍。4. 互联网金融 PRD 的避坑指南这 5 个坑我踩过不止一次4.1 坑一把“额度计算”写成业务规则没写系统校验逻辑现象PRD 里写“用户最高额度 月收入的 24 倍具体以风控结果为准。”开发照着做结果上线后发现用户已经处于逾期名单里系统仍给他计算了额度。原因是“逾期名单拦截”没有在规则里体现风控“知道”要拦但系统“没落”这条校验。原因需求描述停留在业务语义没有落到系统可执行的判定条件。业务规则和系统规则的区别是业务规则说“要”系统规则说“如果什么则拦否则放行”。解决额度计算的需求必须精确到“输入参数 - 中间结果 - 输出条件”。我一般会写成输入为用户实名信息、征信报告、历史借还记录中间结果为综合评分输出条件为“只有综合评分 620 且用户不在黑名单且当前未结清借款数 3 时才返回额度否则返回 0”。写清楚之后开发几乎不用问第二遍。4.2 坑二合规条款直接截图贴进 PRD导致 PDF 里的文字不可检索现象法务发了协议内容产品经理把 PDF 里的条款截图放进 PRD。评审时没人发现等测试要按条款写用例时发现 PDF 里搜不到“逾期罚息”这几个字只能重新找法务要原文。原因截图只保留视觉信息丢失了文本。对于金融产品协议条款不仅是展示还是需要被检索、被比对的需求输入。解决把条款转为文字再贴进 PRD必要时附上法务原文的链接。如果已经用了截图用 PDF 编辑器的 OCR 功能重新识别一次或者干脆重新导出。血的教训是合规类内容永远不要用截图当最终交付宁可多花十分钟复制文字。4.3 坑三状态流转图只有主流程没有失败回滚现象评审会一周后开发说“放款失败的状态我建了但失败后的钱怎么退还没想好”。PRD 的状态图只有“待放款 - 已放款”没有“放款失败 - 冲正中 - 冲正完成”。原因画状态图的人习惯按“用户视角成功路径”画没按“系统资金安全路径”画。失败分支不只是一种异常而是必须和成功分支一样可追踪。解决每个状态机至少补两个失败分支资金流转失败和系统校验失败。放款失败要明确是银行拒绝、超时、账户异常还是风控拦截对应的动作分别是原路退回、重新发起、人工处理。我把这些也写进状态机小节而不是放到“异常处理”里单独说因为状态机缺了它就不完整。4.4 坑四PDF 交付后版本混乱评审记录和文档对不上现象文档文件名是“PRD_v2.0_final.pdf”内容里却还是旧版额度规则而评审记录表引用的是 2.1 的条款。最后测试用 2.0 文档开发产品以为自己给的是 2.1。原因版本只写在文件名没有写进文档内部。文件名的“final”是没有约束力的覆盖之后没人记得到底哪份是新的。解决文件名统一为“产品名_模块_版本号_日期.pdf”文档封面和修订记录里也必须出现同样的版本号。每次评审结束把“待修改”合入正文再递增版本号导出一份新的 PDF并同步更新修订记录。这里我有一个习惯发布 PDF 的同时附一条“变更摘要”写清和上一版的差异而不是让评审人自己 diff。4.5 坑五把“运营活动”写死成功能导致扩展不了现象做“首投加息 0.5%”活动PRD 里直接写“新用户首次投资加息 0.5%”。等活动结束第二次活动改利率开发要提需求改代码因为利率是硬编码。原因把营销活动当作单一功能写忽略了活动规则是一个可变配置。金融产品的利率、费率、限额、积分几乎都该参数化。解决PRD 中把“首投加息”拆为“活动配置表 参与规则”利率作为活动参数而不是产品常量。配置表里至少包含活动编号、适用人群、利率值、起止时间、是否与存量活动互斥。把这个表放进 PRD 的附件开发只要建一张配置表和一套执行逻辑后续活动只加数据不改代码。这个调整会让 PRD 多写一页但节省的返工时间远超一页篇幅。5. 让 PRD 真的能落地从 PDF 到开发、测试与验收5.1 把 PRD 里的验收标准拆成测试用例字段表怎么映射PRD 写完只是开始。测试如果照着 PDF 自己发挥最后验收时会有大量“隐式需求”冒出来。所以要在 PRD 里把验收标准写到位每条标准都应该能拆成具体的测试步骤和预期结果。一个简单映射表是这样用的需求编号验收标准测试步骤预期结果PRD-LOAN-001未通过风控的用户不显示额度用黑名单用户发起借款申请等待风控返回拒绝页面不出现额度字段且申请单状态为“已拒绝”PRD-LOAN-002放款失败自动冲正模拟银行返回失败回调订单进入“冲正中”账务流水生成冲正记录这里的关键是验收标准不要写“页面提示错误”要写“哪个状态、哪个字段、哪条账务记录发生变化”。测试同学只需要从 PDF 里把“预期结果”摘到用例系统而不是再翻译一遍需求。我会在 PRD 里为每个需求编号建立“字段变化清单”列出需求执行前后哪些字段会变这是测试断言最省事的来源。5.2 用最小可行评审法先让风控和法务批“边界”再让研发批“流程”很多团队把所有人拉到同一个评审会结果风控看流程细节研发看风控规则法务等流程结束才发言会议低效。我的做法是分三轮。第一轮先评审“边界”额度规则、合规字段、状态机。参加者只有产品、风控、法务目标是确认每个边界条件可判定。第二轮再评审“流程”页面路径、接口时序、异常提示。参加者是产品、研发、测试目标是确认状态流转和页面交互一致。第三轮是“变更确认”任何人提出的修改合入后快速单独确认而不是再开大会。这个分层评审有一个天然的好处越靠前的评审发现的问题越便宜。风控规则如果在第一轮就定下来开发阶段不会出现“额度计算口径”的争执。PDF 在这个流程里是“物证”每一轮评审完都要冻结版本下一轮基于新 PDF 继续。冻结的意思不是不能再改而是改必须走修订记录并递增版本号。5.3 如何让 PDF 里的原型图保持和线上版本同步PRD 里的原型图最容易被忽视。原型工具经常导出 PNG 后工具又改了交互PDF 里却是旧图。等到开发问“这个弹窗文案改了吗”只能对着线上版本猜。解决办法有三个。第一PDF 里每张原型图下标注“原型源文件路径 版本号”源文件是唯一事实图片只是快照。第二需求变更时先改原型图再重新导图不能只改文字。第三交付前检查所有图的截图时间超过 3 天的图要复核。这里可以用图片的元数据看创建时间Windows 右键属性里有Mac 在“显示简介”里。另外如果一个页面有多个状态不要只放一张默认态。把空态、loading、失败态、异常兜底态都放出来。金融产品的支付失败页、风险提示弹窗、额度为 0 的页面比成功态更需要图。测试拿到这些图才知道每种情况该长什么样。5.4 给测试留一条“从 PDF 直达缺陷”的路径测试同学提缺陷时如果只写“额度计算不对”产品要去查是哪个需求。让 PDF 成为可回溯的依据需要在文档里给每个功能点一个稳定的编号并约定缺陷单必须引用这个编号。我的做法是在 PRD 正文右侧放一列“需求 ID”并定期检查 ID 与标题、验收标准一一对应。测试提单时标题写成“[PRD-LOAN-001] 逾期用户仍显示额度”这样开发能直接跳到需求文档对应章节。PDF 的目录和书签在这里很有用转 PDF 时务必保留书签。没有书签的 PDF在缺陷定位时会浪费大量时间。还有一种做法是用 PDF 解析把文档内容拉出来接到需求管理平台。常见做法是把 PDF 里的章节标题和需求 ID 做成索引表开发或测试在本地用编辑器搜索“需求 ID”几秒钟就能定位。这比让 AI 读 PDF 更可靠因为文档结构由你自己把控。6. 进阶给你的 PRD 加一份“异常分支速查表”比正文更值钱写正文写到最后我已经把状态机、字段表都写清了但发现评审时大家还是一页一页翻找不到“如果放款失败发生重复回调怎么办”。后来我养成了一个习惯在 PRD 最后放一张“异常分支速查表”把所有资金相关的异常路径浓缩到一页里并把它放到 PDF 的最后作为附录。表的格式如下异常场景触发条件预期处理通知对象兜底动作支付重复回调银行重复发送放款成功通知以第一次为准后续幂等忽略无记录重复回调日志触发告警放款超时银行接口 30 秒未响应进入冲正流程原路退回运营、财务手动核对渠道流水额度不足用户申请金额超过剩余额度中止申请提示可用额度无释放临时占用还款扣款失败余额不足或卡过期进入宽限期T1 再试用户宽限期后仍未成功转人工催收这张表的价值在于它迫使你把“如果 XX 失败”变成确定行为而不是模糊的“应当提醒用户”。每次评审我先过这张表大家只花十分钟就能把所有风险点对齐。我曾经因为没有这张表重复回调问题上线一个月才通过日志发现现在我会先写表再写正文正文成了表的展开。注意表里的“兜底动作”不是临时拍脑袋而是要写进对应需求模块有明确的负责人。如果某个异常场景的兜底动作还是“找人工处理”那至少要把“人工处理”的入口、超时时间、升级路径写出来。这样这张表才不会变成废纸。我也在表里放“处理优先级”比如 P0 是资金安全相关P1 是体验相关。优先级不同测试用例的深度也不同。P0 的场景必须做故障演练不能只靠 PRD 文字。这些经验是我踩坑换来的希望帮到你。本文还有配套的精品资源点击获取
