简介一份针对贷超贷款超市平台前后台设计的互联网金融产品原型包版本v1.0.1适合产品经理、交互设计师、前端开发者及金融科技行业新人。压缩包共293个文件含110张PNG页面截图、63个JS脚本、37个SVG图标、35个HTML页面、34个CSS样式、9张GIF动图、3张JPG图片另有rp源文件与crx浏览器插件可判断为基于Axure制作的完整可交互原型兼顾后台运营与前台浏览体验。整包大小仅4.14MB轻量便于下载查看。已有172人学习浏览。从目录结构可系统学习贷超产品的核心模块前台涉及贷款产品推荐、对比、搜索筛选、在线申请与进度追踪后台包括用户管理、产品上下架、风控审核与数据统计等流程版本号1.0.1也体现了小版本迭代中的体验优化与细节修正思路。借助这批原型既能快速建立贷超业务闭环和页面设计规范也可直接参考其rp源文件、HTML演示与JS/CSS实现用于同类项目踩坑与二次开发无论是课程设计还是商业落地都具有较强的借鉴价值。1. 贷超原型包的文件结构里藏着定位问题压缩包表层是一串CSS和CRX扩展axure_rp_page.css负责渲染Axure页面page_notes.css控制原型备注面板debug.css只在开启线框模式时加载。这堆文件本身不是能运行的源码软件而是Axure导出的可交互原型。很多人下载后去找数据库配置方向就错了。这套贷超后台与前台的v1.0.1原型把贷款产品的上下架、进件审核、前台申请流程做成了可点击的页面适合产品、前端和测试用来对齐业务规则。拿到它先解决的应该是“怎么把原型跑起来”而不是“哪里有接口文档”。2. 前台页面拆解从HTML导出文件还原贷超用户旅程Axure导出原型时每个页面会生成独立的HTML文件文件名往往被转成apply_identity.html这种风格直接看文件名等于看天书。所以我第一步永远是扫描HTML元信息把所有页面标题和备注抓出来再做一张真实的前台页面地图。2.1 页面文件与导航结构映射解压后根目录下会看到index.html、start.html以及一组按页面路径命名的HTML文件。不要凭文件名猜页面直接抓取每个HTML的title和后缀的page_notes数据更可靠。我一般用下面这段Python脚本去扫描import os import re from pathlib import Path proto_dir Path(./贷超原型_v1.0.1) html_files list(proto_dir.rglob(*.html)) page_map [] for f in html_files: raw f.read_text(encodingutf-8, errorsignore) title re.search(rtitle(.*?)/title, raw, re.S) # Axure会把页面说明放在 window.pageNotes 之类的全局变量里 notes re.search(rpageNotes\s*\s*(\[.*?\]);, raw, re.S) page_map.append({ file: f.relative_to(proto_dir).as_posix(), title: title.group(1).strip() if title else , notes: notes.group(1)[:200] if notes else }) for p in page_map: print(p[file], |, p[title], |, p[notes])这段脚本的核心是正则抓title和pageNotes。pageNotes是Axure原型中产品经理写的页面备注经常包含“本页需展示通过率”“拒绝原因由风控回传”这类文字是后续做需求澄清的重要依据。errorsignore是为了避免Windows下把GBK字符读炸导致漏文件。扫完以后把输出贴到Excel里按“贷超前台-首页”“贷超前台-产品列表”这样的语义重新分组就能得到一张真实的页面导航地图。2.2 搜索筛选的交互逻辑与筛选参数对于贷超前台搜索筛选是转化率最敏感的部分原型里通常会包含贷款金额、期限、放款速度、是否有信用卡这几个筛选项。我拿到原型后会优先在页面上操作一遍筛选然后把URL里的参数记下来。Axure原型中筛选条件往往没有真实后端而是通过全局变量和条件触发来模拟。一个常见的做法是用window.AxureGlobalVariable存选中的值再靠Set List/Grid Selected动作去过滤中继器数据。// 在浏览器Console里手动模拟筛选逻辑时可以这样读取Axure全局变量 // 打开产品列表页后执行 const gv window.AxureGlobalVariable window.AxureGlobalVariable.get(); console.log(gv.selectedLoanAmount); // 用户选中的借款额度 console.log(gv.selectedTerm); // 借款期限 console.log(gv.selectedMerchantId); // 如果按机构筛选这里会存机构ID这里读取的selectedLoanAmount并不是服务端参数而是原型里用于驱动列表展示的临时值。它对应需求文档里的“贷款金额区间”在正式开发时要转换成接口请求参数比如minAmount、maxAmount。你会在原型中看到“额度50万免息”“7天速放”这类运营位它们本质上都是产品数据标签需要注意区分筛选条件是硬性过滤还是软营销位这点后续做接口设计时非常关键。2.3 借款申请流程的状态与校验贷超前台的借款申请一般分成四步身份信息、联系人、银行卡绑定、确认提交。原型里会通过多个页面串成流程Axure中的“全局变量 动态面板”控制步骤条高亮和下一步按钮的可点状态。要验证流程设计是否完整我习惯把每个页面的下一步按钮事件导出来看条件规则。步骤页面文件名示例关键交互校验规则1 身份认证apply_identity.html从产品列表点击借款进入手机号格式、身份证18位2 联系人授权apply_contact.html上一步数据自动带出联系人手机号与本人不一致3 银行卡绑定apply_bindcard.html支持支付通道银行卡号Luhn校验、预留手机号4 确认提交apply_confirm.html生成申请单号并跳转进度页必须勾选授权协议Axure原型中这种步骤条通常是用多个动态面板切换实现的。开发时真正要留意的并不是原型怎么画而是校验规则从哪来。比如银行卡Luhn校验可以在前端做但“与本人身份的实名一致性”必须走后端接口。所以拆原型时要把“原型中能看到的校验”和“必须依赖服务端能力的校验”分开记录。原型里如果只有一个弹窗提示“校验失败”你也应该在旁批注“调用风控预审接口返回code10023”。3. 后台业务模块拆解产品、风控、审批的状态流贷超后台在原型中通常藏在admin_开头的页面里。相比前台后台原型更依赖表格、弹窗和状态流转这些在Axure中大多用中继器和条件触发器实现。我拿到后台部分以后会先把左侧菜单栏里的菜单项列出再逐个页面看顶部筛选条件和表格列就能拼出一套后台功能全貌。3.1 用户与权限模型的角色矩阵贷款超市的后台用户不会只有管理员一种角色至少需要运营、风控、财务、客服四类。原型里如果没有单独做权限分配页通常会在每个操作按钮上标注“仅管理员可见”或“运营可见”的备注。角色可见菜单可操作动作常见隐藏字段运营人员产品管理、内容管理、数据报表产品上下架、排序、配置佣金用户身份证脱敏字段风控人员进件审核、黑名单、规则配置审核通过/拒绝、人工复审渠道商分润比例财务人员放款管理、还款对账、清算对账导出、调整异常账单用户联系方式客服用户管理、工单系统查询用户申请进度、发起还款提醒风控评分明细角色矩阵是后台原型最该提前锁定的内容。以我拆过的类似后台来看很多团队在原型评审时只关注页面长什么样等开发到权限中间件时才发现“运营不小心点进了风控审核”这种设计漏洞。因此你要把原型中每一个按钮都归属到一个角色下哪怕原型中只画了一个“编辑”按钮也要在演示时问清楚是资料编辑还是状态编辑。3.2 产品上下架与业务状态机贷超后台最核心的业务流是贷款产品的上架、编辑、停用和审核。原型里产品列表会有“草稿、待审核、已上架、已驳回、已下架”这些状态点击操作时弹窗会提示状态变更。# 用文本扫描方式检查原型中产品状态枚举 # 在解压目录下执行以下Python代码 import re from pathlib import Path for f in Path(./贷超原型_v1.0.1).rglob(*.html): text f.read_text(encodingutf-8, errorsignore) states set(re.findall(r(草稿|待审核|已上架|已驳回|已下架|停用), text)) if len(states) 3: print(f, states)这段脚本非常简单作用是把所有包含产品状态字样的页面找出来确认状态机是在同一个页面里切换还是分布在不同子页面。rglob(*.html)会递归扫描所有子目录set去重后方便对照。状态机在原型里的呈现往往是表格行内按钮的文案变化比如“上架”按钮在停用状态下变成“再次上架”。开发时要特别注意原型中的状态中文文案只是显示层真实系统中要用枚举值或整型编码避免前后端因“已停止”和“已停用”这种同义词产生歧义。3.3 风控审核面板与人工复审流程风控审核页通常是一个列表进件记录每行有关联单号、用户姓名、申请金额、风险等级、渠道来源右侧是操作列“通过/拒绝/人工复核”。原型里点击“通过”后会弹出一个二次确认框里面写着“该操作将触发放款队列”这是业务规则的直接提示。我在这类原型里最关注的是“拒绝”按钮下面的交互逻辑拒绝时是否强制填写原因原因列表是否有穷举项如果原型没画我在评审时就会追问。因为拒绝原因不填写后续客服工单就没办法做归类统计。比较常见的做法是写一个reasonCode字段下拉框里放“额度不足、信用评分低、疑似欺诈、重复进件、用户主动取消”等枚举值如果你是前端看到这种弹窗就应该意识到后台需要单独维护一组字典表而不是写死在页面上。4. 从原型到可运行系统反推表结构与接口设计把原型看成静止页面是浪费它的价值在于可以反推出贷款系统的数据结构和接口约定。很多产品经理画原型时不会画数据库但会画字段、按钮和页面跳转这些恰恰是建模的输入。4.1 从原型字段推导数据库表结构贷超系统至少会有这么几种核心表product贷款产品、product_channel渠道、loan_apply进件、user_info用户信息、user_bank_card绑卡、audit_record审核记录。原型的表单里出现的每个label基本都能对应到表里的一个字段。原型页面字段数据库字段接口字段说明产品名称product_nameproductName运营录入前台列表展示最低借款金额borrow_amount_minminAmount与风控预审结果联动最高借款金额borrow_amount_maxmaxAmount校验申请金额上限借款期限term_daystermDays示例值“7,14,30”利率apply_rateapplyRate日利率后台配置-- 基于贷超后台原型中“产品管理”页推导出的建表语句精简版 CREATE TABLE product ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 产品ID, product_name VARCHAR(64) NOT NULL COMMENT 产品名称, borrow_amount_min DECIMAL(10,2) NOT NULL COMMENT 最小可借金额, borrow_amount_max DECIMAL(10,2) NOT NULL COMMENT 最大可借金额, term_days VARCHAR(32) NOT NULL DEFAULT 7,14,30 COMMENT 可借期限天, apply_rate DECIMAL(5,4) NOT NULL COMMENT 借款利率日, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1待审核 2已上架 3已驳回 4已下架, creator VARCHAR(32) NOT NULL COMMENT 后台操作人, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT贷款产品表;原型里产品编辑页有“最小金额、最大金额、期限组合、利率、还款方式”这些在数据库里都要按最细粒度拆字段。需要注意term_days我用了逗号分隔的字符串实际项目中可以用独立的product_term明细表但在这个原型基础上先做单表字段更容易让前端快速联调。status用TINYINT而不是直接存中文是为了后期加筛选索引和状态机流转。从原型字段到建表语句的关键不是把text一一变成varchar而是把“弹窗里可选的值”变成枚举字典。4.2 接口请求与响应结构示例原型的“借款申请”提交按钮对应接口POST /api/loan/apply。请求体中应该包含产品ID、用户ID、申请金额、期限、银行卡ID。注意原型中的申请金额控件可能是个滑块或下拉框接口层要校验金额是否落在该产品的min/max范围内。{ productId: 10086, userId: 23871, applyAmount: 5000.00, applyTermDays: 14, bankCardId: 5521, fromChannel: h5_list }响应设计也要符合原型里下一步页面的展示需要不能只返回一个“成功”{ code: 0, message: 申请已提交, data: { applyId: A202503170001, status: AUDITING, toastText: 预计2小时完成审核 } }这段响应里的toastText是直接在原型页面上写死的提示语放在接口里是为了让运营可以在后台配置文案。接口设计阶段把这类文案字段化能减少后续发版频率。status用英文枚举而不是中文避免前端分支判断时出现诡异编码问题。原型中如果看到“申请单号”和“预计审核时间”说明接口返回里必须有这两个字段否则页面就会留白。4.3 交互原型到前端组件映射Axure原型落地到前端时可以按页面元素直接映射成组件。动态面板对应Tabs或Stepper中继器对应Table组件全局变量对应zustand或redux状态。原型里的点击事件在原型工具里是逻辑在前端里是onClick加一次异步请求。// 以审核按钮为例从原型事件到前端处理的映射 async function auditApply(applyId, action) { // action: PASS / REJECT / NEED_MANUAL const res await fetch(/api/audit/apply, { method: POST, body: JSON.stringify({ applyId, action, reasonCode: action REJECT ? reasonCodeRef.current : }) }); const result await res.json(); if (result.code 0) { message.success(action PASS ? 已通过 : 已拒绝); refreshList(); // 刷新进件列表 } else { // 原型的弹窗里展示了错误码对应这里的result.code message.error(result.message); } }这段代码里我用action标识三种审核结果后端每次审核都要记录操作人和原因所以前端传reasonCode时要注意只有REJECT才必填。映射过程中最容易遗漏的是“刷新列表”背后的状态同步。原型里点完按钮后列表数据会自动变化这在真实前端里意味着要重新拉一次列表接口而不是本地删行。如果后端接口返回了新的分页数据还要处理当前页为空时回退到上一页的边界这些都是原型上看不到、但联调时一定会撞上的问题。5. 用CRX扩展离线调试原型并组织评审的实用技巧Axure原型不仅用来演示还能用来做评审留痕。压缩包里的axure-chrome-extension.crx是Axure官方的Chrome扩展安装以后可以直接在浏览器中打开本地原型文件并且保留页面备注和思维导图。很多同事在评审时只知道F5刷新却不知道这个扩展能直接在现有页面里看备注并复制路径。5.1 加载CRX扩展并快速定位页面备注Chrome浏览器打开chrome://extensions/右上角打开“开发者模式”把axure-chrome-extension.crx拖进窗口就能完成安装。安装完成后再用Chrome打开原型根目录的index.html扩展会自动注入一个侧边栏显示当前页面所属的父级页面和页面备注。对于贷超后台这种页面数量较多的原型评审时可以用CtrlShiftF在扩展内部搜索“利率”“审核”等关键词直接定位到对应页面而不是在几十个HTML文件里乱翻。# 如果本机装了Python也可以不解压扩展直接用命令行检索原型内容 cd 贷超后台_前台_v1.0.1 grep -ril 利率上限 . | head -20grep -ril的r是递归i是忽略大小写l是只输出文件名head -20避免刷屏。这招在评审前临时找某个规则字段时特别有用。注意如果文件太多可以先排除resources和css目录只搜html文件速度会快很多。5.2 从版本号判断更新内容并整理给开发v1.0.1中的1.0.1意味着主版本1小版本0修订1Axure原型也遵循这个语义化版本习惯。拿到这个包后要对比上一版改动可以直接用版本控制工具或者对比两个目录的HTML文件修改时间。我通常会在评审纪要里单独列一节“版本变更对照”把从原型里看到的改动点转成开发者能执行的清单新增了哪些字段、哪些页面流程被打通、哪些按钮文字变了。这样产品、设计、前端、后端在同一个版本号下沟通就不容易再把旧版原型当作需求基线。本文还有配套的精品资源点击获取