跳到主要内容

从输入到成交：我如何把 RFQ 从站点功能升级成 Global 级交易能力平台

27 分钟阅读

RFQ（Request For Quote）是一种面向机构和大额交易用户的询价交易模式。它通过聚合多做市商报价，为用户提供更确定的成交价格和更优的流动性。

如果从业务链路去看，一个完整的 RFQ 系统通常会串起这些能力：

  • 用户准入与 KYC 校验
  • 询价请求与报价返回
  • 做市商报价聚合
  • 用户确认与订单执行
  • 基于 OTC 的清算结算
  • 与 FX、用户风控、定投等业务联动

所以 RFQ 从来都不只是“一个交易页面”，而是一套高度业务化的交易系统能力。

这篇文章不是写“某个组件怎么写”，而是更偏项目复盘、面试表达、晋升答辩的文章。

我想讲清楚的是：

  • RFQ 为什么值得单独做成公司级能力
  • 它早期为什么难做、卡在哪里
  • 我做了哪些关键改造
  • 这套能力给业务和团队带来了什么价值
  • 它未来还能往哪个方向继续演进

一、为什么 RFQ 值得单独做成公司级能力​

很多人看到 RFQ，第一反应可能是：

不就是一个“获取报价 -> 确认成交”的交易页面吗？

但如果真正拆开看，你会发现它远远不只是一个前端页面。

用户表面上看到的流程只有几步：

  1. 选择交易对
  2. 输入金额或数量
  3. 获取报价
  4. 确认成交
  5. 查看订单结果

但在系统内部，这背后同时串起了：

  • 用户身份与 KYC 校验
  • 交易权限与合规控制
  • 实时报价与流动性路由
  • 订单创建与状态流转
  • 资产冻结与资产更新
  • 多站点、多币种、多法币规则适配
  • 活动、定投、FX 等业务能力复用

所以 RFQ 不是“一个交易页面”，而是交易能力、风控能力、资产能力、合规能力、站点能力的交汇点。

一旦这条链路足够稳定、足够抽象，它就不再只服务某一个页面，而会变成 Global、HK、ID 多市场共享的交易底座。

二、项目背景：RFQ 早期到底卡在哪里​

RFQ 虽然是公司 Global 体系中的核心交易能力，但在早期，它并不是一个真正的平台化系统，而更像是一组“为单一站点快速拼出来的定制功能”。

当时主要有 4 类问题。

1. 站点定制化严重，复用能力弱​

  • 香港站、全球站、印尼站在业务规则、交易对、法币、合规要求上都有差异
  • 早期实现更偏站点单独适配
  • 每次开新站、上新玩法，都需要重新拼流程、重新接接口、重新做风控兜底

结果就是：

  • 新站点上线周期长
  • 维护成本高
  • 逻辑容易分叉
  • 一旦核心链路有调整，需要多处同步修改

2. 交易链路长，用户决策成本高​

RFQ 是即时报价交易，用户对“快”和“确定性”的敏感度非常高。

如果流程冗长、提示割裂、状态不清晰，就很容易出现这些问题：

  • 用户不知道当前价格是不是可执行价格
  • 用户点了按钮后，不知道系统现在处于哪一步
  • 价格过期、余额不足、KYC 限制等错误，在错误的时机才暴露

这种问题本质上会直接伤害成交转化率。

3. 业务扩展受限，难以支撑 FX、定投等新形态​

RFQ 不只是简单的买卖币能力，随着业务发展，它开始承接：

  • FX 外汇交易
  • 定投交易
  • Stable 类营销与收益活动
  • 多站点扩张

如果底层交易模型不统一，后续每增加一个业务形态，都会变成一次新的“局部开发”，系统很快就会进入不可控状态。

4. 缺少统一的数据指标与效果评估体系​

团队当时很难回答这些关键问题：

  • 询价成功率到底是多少
  • 哪一步流失最严重
  • 下单失败主要集中在哪些错误码
  • 某次流程优化到底带来了多少业务改善

没有数据闭环，就很难从“主观感觉优化”走向“数据驱动优化”。

三、项目目标：不是做个页面，而是搭一套可复制的交易底座​

这个项目的目标，不是简单优化某一版 RFQ 页面，而是围绕 RFQ 全链路完成一次平台化升级。

我把它拆成 5 个明确目标：

  1. 打造可复用、可扩展的 RFQ 交易能力
  2. 优化交易体验，提高询价成功率与成交转化率
  3. 支撑 FX、定投等多业务形态发展
  4. 实现多站点快速复制，降低交付成本
  5. 建立数据驱动体系，支撑持续优化

如果用一句更适合面试表达的话来概括，这个项目做的是：

把一个站点级交易功能，升级成公司级可复用的交易能力平台。

四、项目产出的直接价值​

围绕 RFQ 交易能力，团队最终完成了：

  • 覆盖香港站、全球站、印尼站的多站点建设
  • 落地 RFQ、FX、定投等多种交易形态
  • 打通从交易入口、实时报价、确认成交、订单管理到资产与合规提示的完整链路
  • 将复杂的合规与交易能力规模化交付到不同市场

这些成果直接支撑了公司多区域业务开展与实际收入增长。

1. 打造 Global 级核心交易能力​

  • RFQ 作为 Global 站最重要的交易能力之一，从站点定制实现升级为可复用、可扩展的交易能力平台
  • RFQ 能力快速复用到印尼站并稳定运行，显著降低新站点交易能力建设成本

2. 交易体验与业务指标显著提升​

通过“询价前置 + 流程简化 + 交易链路优化”，RFQ 交易从“可用”升级为“高效、稳定、可规模化放量”的核心能力。

这类优化直接带来三类收益：

  • 降低用户交易决策成本
  • 提升询价成功率与下单效率
  • 降低交易中断与无效操作比例

3. 数据驱动优化，形成可量化增长闭环​

  • 建立 RFQ 关键指标统计与分析体系
  • 可以持续跟踪询价、确认、下单、执行等关键节点
  • 为后续交易能力持续优化提供数据决策基础

五、RFQ 全链路拆解：从交易入口到成交回执​

如果从用户视角看，RFQ 的完整链路大致可以拆成 7 步。

1. 交易入口​

交易入口并不只来自一个页面，它通常分布在多个流量来源中：

  • 首页 Banner 导流
  • 行情页 / Price 页跳转
  • 历史交易页返回
  • 活动页或定投关联入口

在当前项目里，对外很多入口仍然叫 rfq，但实际承载已经统一收敛到 flash 路由。

这一步的意义不只是路由重定向，而是：

前台入口统一、后台能力统一。

2. 初始化交易上下文​

用户进入页面后，系统需要先完成一轮交易上下文准备：

  • 解析 URL 中的默认币对
  • 获取支持交易的币种、法币、交易对关系
  • 获取交易精度、最小值、最大值、交易状态
  • 读取用户最近一次成功交易的币对偏好
  • 初始化当前 tab：BUY / SELL / CONVERT

这一层决定了页面是不是“可交易”，也决定了后续参数映射是不是正确。

3. 实时预询价​

当用户输入金额或数量后，系统不会等到最后一步才报价，而是先做一轮实时预询价。

这一步的业务意义很大：

  • 让用户先看到真实可参考的价格
  • 在输入阶段尽早暴露不合法金额、精度或限额问题
  • 提前缩短用户的决策路径

从体验上看，这一步只是页面上实时展示汇率与倒计时。
但从业务上看，这一步相当于把“价格确认”前置了。

4. 正式询价​

用户点击 Get Quote 后，系统发起正式询价，拿到：

  • quoteId
  • quotePrice
  • quoteQuantity
  • quoteTotalAmount
  • ttl 或等效报价有效时间

这一阶段的关键不是“再调一次接口”，而是：

  • 把展示级报价切换成可执行报价
  • 将这次报价纳入一个可下单、可追踪、可过期控制的正式交易上下文

5. 报价确认​

用户进入确认页后，页面会展示：

  • 买卖双方币种
  • 支付金额 / 接收金额
  • 执行价格
  • 报价倒计时
  • 零手续费或活动权益提示

这一步是整个 RFQ 的核心信任节点。

因为用户不是“盲下单”，而是在明确确认当前成交条件后才点击确认。

6. 下单与执行​

当用户点击 Confirm 后，系统进入真正的交易执行阶段：

  1. 使用 quoteId 发起下单
  2. 服务端校验 quote 是否仍有效
  3. 校验用户资格、风控规则、订单幂等
  4. 冻结对应资产
  5. 异步向流动性侧或 MM 发起对冲 / 执行
  6. 更新订单状态
  7. 前端轮询订单执行结果

7. 结果回传与后续动作​

如果成功：

  • 展示成交结果页
  • 更新用户资产
  • 引导到定投、划转、后续交易等页面

如果失败：

  • 展示失败原因
  • 允许用户回到交易页重新发起流程

这意味着 RFQ 不只是“下单”，它还承担了成交回执、资产反馈、后续业务转化三个职责。

六、后端核心时序：quote 是怎么生成的，order 是怎么执行的​

前端看到的是一个交易页面，后端实际跑的是一套多系统协作链路。

结合后端时序，可以把 RFQ 拆成“报价链路”和“执行链路”。

1. 报价链路：quote 是怎么出来的​

报价不是简单读一个行情价格返回给前端，而是一个带合规、汇率、MM 价格、缓存的组合过程。

大致过程如下：

  1. 用户发起某个币种与法币的询价，例如数币 / IDR
  2. RFQ 服务生成 quoteId
  3. 查询用户信息，获取 KYC 状态、交易权限、用户等级
  4. 查询当前交易对的行情价格
  5. 校验用户权限与币对交易状态
  6. 根据输入类型计算币数量、法币金额和对应价格
  7. 查询法币与 USD 的汇率，例如 IDR/USD
  8. 基于数币 / USD 与法币 / USD 汇率，计算对应法币报价
  9. 向 MM 侧获取或校准初始报价
  10. 计算最终对用户展示的成交价格
  11. 把 quoteInfo 存入 Redis
  12. 把法币 / USD 汇率等关键上下文与 quoteId 做缓存关联
  13. 将报价返回给前端

这条链路说明了一个很重要的点：

RFQ 的 quote 不是一个“单纯的价格结果”，而是一个“带业务上下文、带时效、可下单、可追踪”的交易快照。

2. 执行链路：order 是怎么完成的​

当用户点击确认后，系统不是直接成交，而是进入订单执行状态机。

核心步骤如下：

  1. 从 Redis 取回 QuoteDetail
  2. 从 Redis 取回与该 quote 绑定的汇率上下文，例如 IDR/USD
  3. 做幂等与有效性检查
  4. 创建订单并记录关键汇率字段
  5. 写入订单状态流转记录
  6. 做分布式锁控制，避免重复执行
  7. 冻结用户资产
  8. 异步向 spot / MM 发起执行或对冲
  9. 轮询 MM 结果
  10. 如果成功，更新订单状态并继续写入状态流转记录
  11. 前端轮询订单结果并展示成功或失败页

这条链路的核心价值在于：

  • 保证订单执行具备时效一致性
  • 保证报价与下单使用的是同一份业务快照
  • 保证资产冻结、状态流转、外部执行三者可追踪

七、为什么这个项目难做：业务难点与技术难点​

这类项目真正的难，不在“页面多复杂”，而在：

每一步都牵涉多个业务系统，且任何一步出错都会直接影响交易结果。

1. 参数语义复杂，尤其是 Convert​

Buy、Sell 看起来相对清晰，但 Convert 会引入一个非常典型的问题：

  • 用户理解的是 from -> to
  • 系统执行的是 tradeCurrency + settlementCurrency + side

也就是说，前端看到的输入方向，并不等于后端实际执行方向。

当交易对只存在单向时，系统还需要动态判断应该走 Buy 还是 Sell 语义。

这件事难的地方不是写 if/else，而是：

  • 任何一处映射不一致，都会造成“报价展示正确、下单参数错误”
  • 同一套页面逻辑要兼容 Buy / Sell / Convert 多种模式
  • 还要适配 FX、定投等业务继续复用

2. 时效性与一致性要求都很高​

RFQ 不是长期有效价格，quote 天生带 TTL。

一旦用户停留时间较长，就会出现“用户看到的价格”和“系统可执行价格”之间的时间差。

所以系统必须处理好：

  • 预询价与正式询价的衔接
  • 确认页的报价刷新
  • 下单前 quote 过期检查
  • 重新询价后的状态一致性

这类问题如果处理不好，最常见的后果就是：

  • 用户频繁下单失败
  • 用户感知价格跳动大
  • 投诉价格不一致

3. 风控门禁不是一个点，而是一条链​

RFQ 会同时受这些因素约束：

  • 是否登录
  • 是否完成 KYC
  • BOA / POA 等合规审核状态
  • 是否具备该币对交易权限
  • 最小 / 最大订单限制
  • 精度是否合法
  • 余额是否足够
  • 币对交易状态是否开放

这意味着风控不是某个弹窗，而是一套贯穿“输入 -> 报价 -> 下单 -> 执行”的门禁系统。

4. 多站点、多法币、多业务复用​

站点一多，复杂度会指数级上升。

因为不同站点会有不同：

  • 支持法币
  • 合规规则
  • 活动策略
  • 页面入口
  • 本地化文案
  • 交易玩法

如果系统是站点定制模式，那每开一个市场都像重做一次 RFQ。
而如果想做成平台能力，就必须把“站点差异”沉淀成“规则与配置”，而不是“复制代码”。

5. 前端状态天然容易失控​

前端这条链路里同时存在：

  • tab 状态
  • 币对状态
  • 输入状态
  • fast quote 状态
  • quote confirm 状态
  • order result 状态
  • 资产信息
  • 用户信息
  • 本地缓存

再叠加防抖、轮询、异步接口、切换交易对，就很容易出现：

  • 状态覆盖
  • 旧请求污染新结果
  • 边界条件难兜底

八、为什么这个项目有价值：业务痛点与改造收益​

项目真正有说服力的地方，不是“我重构了代码”，而是：

我解决了什么业务痛点，并让业务更容易增长。

1. 早期 RFQ 只能算能用，不能算可放量​

早期 RFQ 的问题不是不能交易，而是：

  • 流程割裂
  • 体验不稳定
  • 复用成本高
  • 交易链路容易中断

这类系统在业务初期还能顶住，但一旦要做 Global 主交易能力，就会暴露出明显瓶颈。

2. 每个新业务都在“重复造轮子”​

如果 RFQ 只是一个单点功能，那么：

  • 做 FX 需要再适配一套
  • 做定投需要再接一套
  • 做新站点还要再适配一轮

长期来看，这种模式的成本不只是开发成本，更是组织协作成本和持续维护成本。

3. 缺少数据闭环，优化难以自证​

很多交易系统都会做优化，但如果没有指标体系，就只能停留在“感觉变好了”。

而交易业务最怕的就是：

  • 不知道哪一步流失最严重
  • 不知道失败码主要集中在哪
  • 不知道流程优化有没有真正提高成交效率

4. 这次改造带来的核心收益​

这次 RFQ 项目之后，团队获得的不是“一个新版页面”，而是三层收益。

第一层是业务收益：

  • RFQ 交易量显著提升
  • 询价成功率与成交转化率明显提升
  • RFQ 成为支撑 Global、ID、HK 的重要交易基础能力

第二层是组织效率收益：

  • 新站点 RFQ 能力建设周期大幅缩短
  • 复用 Global 成熟能力，减少重复开发与维护成本
  • 交易链路稳定后，运营与问题处理成本显著下降

第三层是技术资产收益：

  • 一套核心系统支撑多区域、多业务
  • 统一交易模型与技术标准
  • 为 FX、定投以及后续新型交易产品提供基础能力

九、项目执行过程与阶段性落地​

这个项目不是一次性重写完成的，而是随着业务节奏逐步推进的。

时间项目举措详细描述
2025.07.22HK RFQ 全新改版询价前置，在下单前完成报价判断，减少无效操作
2025.08.13Global RFQ 定投上线拓展定投交易形态
2025.09.08HK FX 上线支持外汇交易场景
2025.09.24HK RFQ 定投上线定投能力复用，多业务能力落地
2025.10.28Global RFQ 流程优化简化交易步骤，减少用户等待时间与中断点，提升整体交易流畅度
2025.10.28Global RFQ 改版升级对 Global 站 RFQ 核心链路进行系统性重构，提升可维护性与扩展性
2025.11.26ID RFQ 快速复用快速支持印尼站上线
2025.12.03HK RFQ 迁移与优化完成 RFQ 能力迁移并统一交易模型，支持 FX 与定投等多业务场景
2025.12.15数据统计与效果评估建立 RFQ 关键指标体系，持续评估优化效果

如果把这些动作抽象一下，会发现项目推进路径非常清晰：

  1. 先优化核心链路体验
  2. 再扩展多业务玩法
  3. 再做 Global 化与平台化升级
  4. 最后补齐数据闭环与效果评估

这也是一个很适合在面试里讲的“从战术优化走向战略能力建设”的项目路径。

十、项目结果：业务价值、效率价值、技术价值​

1. 业务价值​

  • RFQ 交易量显著提升，成为 Global 主交易能力中的持续放量模块
  • 询价成功率与成交转化率明显提升
  • RFQ 成为支撑 Global、ID、HK 的核心交易基础能力

2. 效率价值​

  • 新站点 RFQ 能力建设周期大幅缩短
  • 复用 Global 成熟能力，减少重复开发与维护成本
  • 链路稳定后，运营与问题处理成本显著下降

3. 技术价值​

高稳定性：

  • 多站点高并发场景下稳定运行
  • 核心链路可靠性持续提升

平台化与复用能力：

  • 一套核心系统支撑多区域、多业务
  • 统一交易模型与技术标准

可持续演进：

  • 支持 FX、定投等持续扩展
  • 为后续新型交易产品提供基础能力

十一、这段经历在面试里应该怎么讲​

如果要把这个项目讲得“既懂业务又懂系统”，建议不要只讲“我做了一个 RFQ 页面”，而要按下面这个结构来讲。

1. 先讲项目级别​

可以先定调：

我做的不是单一页面优化，而是围绕 RFQ 核心交易链路做了一次平台化升级，目标是让这套能力可以支撑 Global、HK、ID 多站点，以及 FX、定投等多业务形态。

这句话能直接把项目从“需求开发”拉升到“核心能力建设”。

2. 再讲你解决的核心矛盾​

建议用“旧系统为什么不行”来讲，而不是直接堆功能点：

  • 旧系统站点定制化严重，复用能力差
  • 交易链路长，用户决策成本高
  • 参数语义复杂，尤其是 Convert 映射容易出错
  • 缺少指标体系，优化难以闭环

3. 然后讲你的关键动作​

你可以把动作概括成 4 个关键词：

  • 流程前置：把询价前置，减少无效操作
  • 模型统一：统一交易模型和参数语义
  • 平台复用：让能力可支撑多站点、多业务
  • 数据闭环：建立关键指标统计与效果评估体系

4. 最后讲结果​

结果不要只讲“上线了”，而要讲三类结果：

  • 业务结果：交易量、询价成功率、转化率提升
  • 效率结果：新站点接入更快、复用成本更低
  • 技术结果：系统更稳定、更可扩展、更可持续演进

如果面试官继续追问细节，再展开你对下面这些点的理解：

  • quote 与 order 的两段式链路
  • Convert 参数映射
  • 风控门禁前置
  • 多站点差异抽象
  • 数据指标设计

基本就能把项目讲深了。

十二、项目未来：从内部交易系统走向白标 SaaS 能力​

我对这个项目未来的理解，不只是继续做几个站点，而是把 RFQ 系统从内部工具升级为可对外输出的白标 SaaS 产品，实现降本增收与生态拓展。

整体可以分三阶段、约 18 个月推进。

第一阶段：底座重构​

目标是抽象参数配置、做配置化设计，并拆分报价、风控、结算等核心模块，逐步演进成更轻量、更标准化的服务。

预期收益：

  • 减少运营成本
  • 提升复用性
  • 提升稳定性与运维效率

第二阶段：业务扩容​

在现货 RFQ 基础上，逐步纳入更多产品线：

  • 合约
  • OTC
  • 理财

最终形成统一报价、统一交易入口、统一撮合与风控逻辑的多产品 RFQ 平台。

第三阶段：商业化与生态化​

把 RFQ 能力标准化为多租户 SaaS 方案，通过订阅制加“流动性租户”模式，服务线上或线下的中小型 P2P OTC 业务服务商。

这一步一旦跑通，RFQ 的角色就会从：

  • 公司内部交易系统

升级为：

  • 可输出的流动性与交易基础设施产品

如果这条路能走通，它的价值就不仅仅是支撑公司现有业务，而是变成新的收入模型与生态能力。

总结​

RFQ 项目最值得讲的地方，不是页面有多复杂，而是它把交易、风控、资产、合规、站点扩张、业务复用、数据驱动这些原本分散的能力，整合成了一套真正可规模化交付的交易底座。

对我来说，这个项目最大的收获不是“做完了一次改版”，而是理解了一个核心事实：

真正有价值的系统，不是把一个需求做完，而是把一类业务能力沉淀成平台。

如果后续还要继续写下一篇，我会重点展开这个话题：

《RFQ Convert 参数统一建模：如何把 from/to 语义映射成可复用的交易执行模型》

从输入到成交：我如何把 RFQ 从站点功能升级成 Global 级交易能力平台

RFQ 是一种面向机构和大额交易用户的询价交易模式，通过聚合多做市商报价，为用户提供确定性价格和更优流动性。其核心流程包括用户准入（KYC/等级）、询价请求、做市商报价、报价聚合、用户确认以及基于OTC的清算结算。同时，RFQ系统通常与FX换汇、用户风控体系以及定投服务深度联动，形成完整的交易闭环

这不是一篇“组件怎么写”的前端总结，而是一篇更适合面试、晋升答辩、项目复盘的业务型文章。 我想讲清楚的是：RFQ 为什么重要、原来为什么难做、我做了哪些关键改造、它给业务和团队带来了什么价值，以及这套能力未来还能往哪里走。

目录​

  1. 为什么 RFQ 值得单独做成公司级能力
  2. 项目背景：RFQ 早期到底卡在哪里
  3. 项目目标：不是做个页面，而是搭一套可复制的交易底座
  4. 项目产出的直接价值
  5. RFQ 全链路拆解：从交易入口到成交回执
  6. 后端核心时序：quote 是怎么生成的，order 是怎么执行的
  7. 为什么这个项目难做：业务难点与技术难点
  8. 为什么这个项目有价值：业务痛点与改造收益
  9. 项目执行过程与阶段性落地
  10. 项目结果：业务价值、效率价值、技术价值
  11. 这段经历在面试里应该怎么讲
  12. 项目未来：从内部交易系统走向白标 SaaS 能力

1) 为什么 RFQ 值得单独做成公司级能力​

RFQ（Request For Quote）不是普通的下单页，它是一个高度业务化的交易系统能力。

用户表面上只看到了一个简单流程：

  1. 选择交易对
  2. 输入金额或数量
  3. 获取报价
  4. 确认成交
  5. 查看订单结果

但在系统内部，这背后同时串联了：

  • 用户身份与 KYC 校验
  • 交易权限与合规控制
  • 实时报价与流动性路由
  • 订单创建与状态流转
  • 资产冻结与资产更新
  • 多站点、多币种、多法币规则适配
  • 活动、定投、FX 等业务能力复用

所以 RFQ 不是“一个交易页面”，而是 ​交易能力、风控能力、资产能力、合规能力、站点能力的交汇点​。 一旦这条链路做得足够稳定、足够抽象，它就不再只是服务某一个页面，而会成为 Global、HK、ID 多市场共享的核心能力底座。

2) 项目背景：RFQ 早期到底卡在哪里​

RFQ 作为公司 Global 体系中的核心交易能力，在早期并不是一个真正的平台化系统，而更像是一组“为单一站点快速拼出来的定制功能”。

当时主要有 4 类问题。

2.1 站点定制化严重，复用能力弱​

  • 香港站、全球站、印尼站在业务规则、交易对、法币、合规要求上都有差异
  • 早期实现更偏“站点单独适配”
  • 每次开新站、上新玩法，都需要重新拼流程、重新接接口、重新做风控兜底

结果就是：

  • 新站点上线周期长
  • 维护成本高
  • 逻辑容易分叉
  • 一旦核心链路有调整，需要多处同步改

2.2 交易链路长，用户决策成本高​

RFQ 是即时报价交易，用户对“快”和“确定性”的敏感度非常高。 如果流程冗长、提示割裂、状态不清晰，就很容易发生：

  • 用户不知道当前价格是不是可执行价格
  • 用户点了按钮后不知道系统处于哪一步
  • 价格过期、余额不足、KYC 限制等错误在错误的时机才暴露

本质上，这种问题会直接伤害成交转化率。

2.3 业务扩展受限，难支撑 FX、定投等新形态​

RFQ 不只是简单的买卖币能力，随着业务发展，它开始承接：

  • FX 外汇交易
  • 定投交易
  • Stable 类营销与收益活动
  • 多站点扩张

如果底层交易模型不统一，后续每增加一个业务形态，都会变成一次新的“局部开发”，系统很快就会进入不可控状态。

2.4 缺少统一的数据指标与效果评估体系​

团队很难回答这些关键问题：

  • 询价成功率到底是多少
  • 哪一步流失最严重
  • 下单失败主要集中在哪些错误码
  • 哪次流程优化到底带来了多少业务改善

没有数据闭环，就很难从“主观感觉优化”走向“数据驱动优化”。

3) 项目目标：不是做个页面，而是搭一套可复制的交易底座​

这个项目的目标，不是简单优化某一版 RFQ 页面，而是围绕 RFQ 全链路完成一次平台化升级。

我把它拆成 5 个明确目标：

  1. 打造可复用、可扩展的 RFQ 交易能力
  2. 优化交易体验，提高询价成功率与成交转化率
  3. 支撑 FX、定投等多业务形态发展
  4. 实现多站点快速复制，降低交付成本
  5. 建立数据驱动体系，支撑持续优化

如果用一句面试化的话来概括，这个项目做的是：

把一个站点级交易功能，升级成公司级可复用的交易能力平台。

4) 项目产出的直接价值​

团队围绕 RFQ 交易能力，最终完成了覆盖香港站、全球站、印尼站的多站点建设；落地了 RFQ、FX、定投等多种交易形态；打通从交易入口、实时报价、确认成交、订单管理到资产与合规提示的完整链路；将复杂的合规与交易能力规模化交付到不同市场，直接支撑公司多区域业务开展与实际收入增长。

4.1 打造 Global 级核心交易能力​

  • RFQ 作为 Global 站最重要的交易能力之一，通过架构梳理与流程重构，从站点定制实现升级为可复用、可扩展的交易能力平台
  • RFQ 能力快速复用至印尼站并稳定运行，显著降低新站点交易能力建设成本

4.2 交易体验与业务指标显著提升​

通过“询价前置 + 流程简化 + 交易链路优化”，RFQ 交易从“可用”升级为“高效、稳定、可规模化放量”的核心交易能力。

这类优化直接带来三类收益：

  • 降低用户交易决策成本
  • 提升询价成功率与下单效率
  • 降低交易中断与无效操作比例

4.3 数据驱动优化，形成可量化增长闭环​

  • 建立 RFQ 关键指标统计与分析体系
  • 可以持续跟踪询价、确认、下单、执行等关键节点
  • 为后续交易能力持续优化提供数据决策基础

5) RFQ 全链路拆解：从交易入口到成交回执​

如果从用户视角看，RFQ 的完整链路可以拆成 7 步。

5.1 交易入口​

交易入口并不只来自一个页面，它通常分布在多个流量来源中：

  • 首页 Banner 导流
  • 行情页 / Price 页跳转
  • 历史交易页返回
  • 某些活动或定投关联入口

在当前项目中，对外很多入口仍然叫 rfq，但实际承载已经统一收敛到 flash 路由。 这一步的意义并不只是路由重定向，而是 ​前台入口统一、后台能力统一​。

5.2 初始化交易上下文​

用户进入页面后，系统需要先完成一轮交易上下文准备：

  • 解析 URL 中的默认币对
  • 获取支持交易的币种、法币、交易对关系
  • 获取交易精度、最小值、最大值、交易状态
  • 读取用户最近一次成功交易的币对偏好
  • 初始化当前 tab：BUY / SELL / CONVERT

这一层决定了页面是不是“可交易”，也决定了后续参数映射是不是正确。

5.3 实时询价​

当用户输入金额或数量后，系统不会等到最后一步才报价，而是先做一轮实时预询价。

这一步的业务意义很大：

  • 让用户先看到真实可参考的价格
  • 在输入阶段尽早暴露不合法金额、精度或限额问题
  • 提前缩短用户的决策路径

从体验上看，这一步只是页面上实时展示汇率与倒计时； 从业务上看，这一步相当于把“价格确认”前置了。

5.4 正式询价​

用户点击 Get Quote 后，系统发起正式询价，拿到：

  • quoteId
  • quotePrice
  • quoteQuantity
  • quoteTotalAmount
  • ttl 或等效报价有效时间

这一阶段的关键不是“再调一次接口”，而是：

  • 把展示级报价切换成可执行报价
  • 将这次报价纳入一个可下单、可追踪、可过期控制的正式交易上下文

5.5 报价确认​

用户进入确认页后，页面会展示：

  • 买卖双方币种
  • 支付金额 / 接收金额
  • 执行价格
  • 报价倒计时
  • 零手续费或活动权益提示

这一步是整个 RFQ 的核心信任节点。 因为用户不是“盲下单”，而是在明确确认当前成交条件后才点击确认。

5.6 下单与执行​

当用户点击 Confirm 后，系统进入真正的交易执行阶段：

  1. 使用 quoteId 发起下单
  2. 服务端校验 quote 是否仍有效
  3. 校验用户资格、风控规则、订单幂等
  4. 冻结对应资产
  5. 异步向流动性侧或 MM 发起对冲 / 执行
  6. 更新订单状态
  7. 前端轮询订单执行结果

5.7 结果回传与后续动作​

如果成功：

  • 展示成交结果页
  • 更新用户资产
  • 可引导到定投、划转、后续交易等页面

如果失败：

  • 展示失败原因
  • 允许用户回到交易页重新发起流程

这意味着 RFQ 不只是“下单”，它还承担了 成交回执、资产反馈、后续业务转化 三个职责。

6) 后端核心时序：quote 是怎么生成的，order 是怎么执行的​

前端看到的是一个交易页面，后端实际上跑的是一套多系统协作链路。 结合后端时序，可以把 RFQ 拆成“报价链路”和“执行链路”。

6.1 报价链路：quote 是怎么出来的​

报价不是简单读一个行情价格返回给前端，而是一个带合规、汇率、MM 价格、缓存的组合过程。

大致过程如下：

  1. 用户发起某个币种与法币的询价，例如数币/IDR
  2. RFQ 服务生成 quoteId
  3. 查询用户信息，获取：
  • KYC 状态
  • 交易权限
  • 用户等级
  1. 查询当前交易对的行情价格
  2. 校验用户权限与币对交易状态
  3. 根据输入类型计算：
  • 币数量
  • 法币金额
  • 对应价格
  1. 查询法币与 USD 的汇率，例如 IDR/USD
  2. 基于数币/USD 与法币/USD 汇率，计算对应法币报价
  3. 向 MM 侧获取或校准初始报价
  4. 计算最终对用户展示的成交价格
  5. 把 quoteInfo 存入 Redis
  6. 把法币/USD 汇率等关键上下文与 quoteId 关联缓存
  7. 将报价返回给前端

这条链路说明了一个很重要的点：

RFQ 的 quote 不是一个“单纯的价格结果”，而是一个“带业务上下文、带时效、可下单、可追踪”的交易快照。

6.2 执行链路：order 是怎么完成的​

当用户点击确认后，系统不是直接成交，而是进入订单执行状态机。

核心步骤如下：

  1. 从 Redis 取回 QuoteDetail
  2. 从 Redis 取回与该 quote 绑定的汇率上下文，例如 IDR/USD
  3. 做幂等与有效性检查
  4. 创建订单并记录关键汇率字段
  5. 写入订单状态流转记录
  6. 做分布式锁控制，避免重复执行
  7. 冻结用户资产
  8. 异步向 spot / MM 发起执行或对冲
  9. 轮询 MM 结果
  10. 如果成功，更新订单状态并继续写入状态流转记录
  11. 前端轮询订单结果并展示成功或失败页

这条链路的核心价值是：

  • 保证订单执行具备时效一致性
  • 保证报价与下单使用的是同一份业务快照
  • 保证资产冻结、状态流转、外部执行三者可追踪

7) 为什么这个项目难做：业务难点与技术难点​

这类项目的难，不在“页面多复杂”，而在“每一步都牵涉多个业务系统，且任何一步出错都会直接影响交易结果”。

7.1 难点一：参数语义复杂，尤其是 Convert​

Buy、Sell 看起来相对清晰，但 Convert 会引入一个非常典型的问题：

  • 用户理解的是 from -> to
  • 系统执行的是 tradeCurrency + settlementCurrency + side

也就是说，前端看到的输入方向，并不等于后端实际执行方向。 当交易对只存在单向时，系统还需要动态判断应该走 Buy 还是 Sell 语义。

这件事难的地方不是写 if-else，而是：

  • 任何一处映射不一致，都会造成报价展示正确、下单参数错误
  • 同一套页面逻辑要兼容 Buy/Sell/Convert 多种模式
  • 还要适配 FX、定投等业务继续复用

7.2 难点二：时效性与一致性同时要求很高​

RFQ 不是长期有效价格，quote 天生有 TTL。 一旦用户停留时间较长，就会出现“用户看到的价格”和“系统可执行价格”之间的时间差。

所以系统必须处理好：

  • 预询价与正式询价的衔接
  • 确认页的报价刷新
  • 下单前 quote 过期检查
  • 重新询价后的状态一致性

这类问题如果处理不好，最常见后果就是：

  • 用户频繁下单失败
  • 用户感知价格跳动大
  • 投诉价格不一致

7.3 难点三：风控门禁不是一个点，而是一条链​

RFQ 会同时受这些因素约束：

  • 是否登录
  • 是否完成 KYC
  • BOA / POA 等合规审核状态
  • 是否具备该币对交易权限
  • 最小 / 最大订单限制
  • 精度是否合法
  • 余额是否足够
  • 币对交易状态是否开放

这意味着风控不是某个弹窗，而是一套贯穿“输入 -> 报价 -> 下单 -> 执行”的门禁系统。

7.4 难点四：多站点、多法币、多业务复用​

站点一多，复杂度会指数级上升。

因为不同站点会有不同：

  • 支持法币
  • 合规规则
  • 活动策略
  • 页面入口
  • 本地化文案
  • 交易玩法

如果系统是站点定制模式，那每开一个市场都像重做一次 RFQ。 而如果你想做成平台能力，就必须把“站点差异”沉淀成“规则与配置”，而不是“复制代码”。

7.5 难点五：前端状态天然容易失控​

前端这条链路里同时存在：

  • tab 状态
  • 币对状态
  • 输入状态
  • fast quote 状态
  • quote confirm 状态
  • order result 状态
  • 资产信息
  • 用户信息
  • 本地缓存

再叠加防抖、轮询、异步接口、切换交易对，就很容易出现状态覆盖、旧请求污染新结果、边界条件难兜底的问题。

8) 为什么这个项目有价值：业务痛点与改造收益​

项目真正有说服力的地方，不是“我重构了代码”，而是“我解决了什么业务痛点，并让业务更容易增长”。

8.1 痛点一：早期 RFQ 只能算能用，不能算可放量​

早期 RFQ 的问题不是不能交易，而是：

  • 流程割裂
  • 体验不稳定
  • 复用成本高
  • 交易链路容易中断

这类系统在业务初期还能顶住，但一旦要做 Global 主交易能力，就会暴露出明显瓶颈。

8.2 痛点二：每个新业务都在“重复造轮子”​

如果 RFQ 只是一个单点功能，那么：

  • 做 FX 需要再适配一套
  • 做定投需要再接一套
  • 做新站点还要再适配一轮

长期来看，这种模式的成本不是开发成本，而是 ​组织协作成本和持续维护成本​。

8.3 痛点三：缺少数据闭环，优化难以自证​

很多交易系统都会做优化，但如果没有指标体系，就只能停留在“感觉变好了”。 而交易业务最怕的就是：

  • 不知道哪一步流失最严重
  • 不知道失败码主要集中在哪
  • 不知道流程优化有没有真正提高成交效率

8.4 这次改造带来的核心收益​

这次 RFQ 项目之后，团队获得的不是“一个新版页面”，而是三层收益。

第一层是业务收益：

  • RFQ 交易量显著提升
  • 询价成功率与成交转化率明显提升
  • RFQ 成为支撑 Global、ID、HK 的重要交易基础能力

第二层是组织效率收益：

  • 新站点 RFQ 能力建设周期大幅缩短
  • 复用 Global 成熟能力，减少重复开发与维护成本
  • 交易链路稳定后，运营与问题处理成本显著下降

第三层是技术资产收益：

  • 一套核心系统支撑多区域、多业务
  • 统一交易模型与技术标准
  • 为 FX、定投以及后续新型交易产品提供基础能力

9) 项目执行过程与阶段性落地​

这个项目不是一次性重写完成的，而是随着业务节奏逐步推进的。

时间项目举措详细描述
2025.07.22HK RFQ 全新改版询价前置，在下单前完成报价判断，减少无效操作
2025.08.13Global RFQ 定投上线拓展定投交易形态
2025.09.08HK FX 上线支持外汇交易场景
2025.09.24HK RFQ 定投上线定投能力复用，多业务能力落地
2025.10.28Global RFQ 流程优化简化交易步骤，减少用户等待时间与中断点，提升整体交易流畅度
2025.10.28Global RFQ 改版升级对 Global 站 RFQ 核心链路进行系统性重构，提升可维护性与扩展性
2025.11.26ID RFQ 快速复用快速支持印尼站上线
2025.12.03HK RFQ 迁移与优化完成 RFQ 能力迁移并统一交易模型，支持 FX 与定投等多业务场景
2025.12.15数据统计与效果评估建立 RFQ 关键指标体系，持续评估优化效果

如果把这些动作抽象一下，会发现项目推进路径非常清晰：

  1. 先优化核心链路体验
  2. 再扩展多业务玩法
  3. 再做 Global 化与平台化升级
  4. 最后补齐数据闭环与效果评估

这也是一个很适合在面试里讲的“从战术优化走向战略能力建设”的项目路径。

10) 项目结果：业务价值、效率价值、技术价值​

10.1 业务价值​

  • RFQ 交易量显著提升，成为 Global 主交易能力中的持续放量模块
  • 询价成功率与成交转化率明显提升
  • RFQ 成为支撑 Global、ID、HK 的核心交易基础能力

10.2 效率价值​

  • 新站点 RFQ 能力建设周期大幅缩短
  • 复用 Global 成熟能力，减少重复开发与维护成本
  • 链路稳定后，运营与问题处理成本显著下降

10.3 技术价值​

高稳定性：

  • 多站点高并发场景下稳定运行
  • 核心链路可靠性持续提升

平台化与复用能力：

  • 一套核心系统支撑多区域、多业务
  • 统一交易模型与技术标准

可持续演进：

  • 支持 FX、定投等持续扩展
  • 为后续新型交易产品提供基础能力

11) 这段经历在面试里应该怎么讲​

如果你要把这个项目讲得“既懂业务又懂系统”，建议不要只讲“我做了一个 RFQ 页面”，而要按下面这个结构来讲。

11.1 先讲项目级别​

可以先定调：

我做的不是单一页面优化，而是围绕 RFQ 核心交易链路做了一次平台化升级，目标是让这套能力可以支撑 Global、HK、ID 多站点以及 FX、定投等多业务形态。

这句话能直接把项目从“需求开发”拉升到“核心能力建设”。

11.2 再讲你解决的核心矛盾​

建议用“旧系统为什么不行”来讲，而不是直接堆功能点：

  • 旧系统站点定制化严重，复用能力差
  • 交易链路长，用户决策成本高
  • 参数语义复杂，尤其是 Convert 映射容易出错
  • 缺少指标体系，优化难以闭环

11.3 然后讲你的关键动作​

你可以把动作概括为 4 个关键词：

  • 流程前置：把询价前置，减少无效操作
  • 模型统一：统一交易模型和参数语义
  • 平台复用：让能力可支撑多站点、多业务
  • 数据闭环：建立关键指标统计与效果评估体系

11.4 最后讲结果​

结果不要只讲“上线了”，而要讲三类结果：

  • 业务结果：交易量、询价成功率、转化率提升
  • 效率结果：新站点接入更快、复用成本更低
  • 技术结果：系统更稳定、更可扩展、更可持续演进

如果面试官继续追问细节，再展开你对：

  • quote 与 order 的两段式链路理解
  • Convert 参数映射
  • 风控门禁前置
  • 多站点差异抽象
  • 数据指标设计

这几部分的思考，基本就能把项目讲深了。

12) 项目未来：从内部交易系统走向白标 SaaS 能力​

我对这个项目未来的理解，不只是继续做几个站点，而是把 RFQ 系统从内部工具升级为可对外输出的白标 SaaS 产品，实现降本增收与生态拓展。

整体可以分三阶段、约 18 个月推进。

第一阶段：底座重构​

目标是抽象参数配置、做配置化设计，并拆分报价、风控、结算等核心模块，逐步演进成更轻量、更标准化的服务。

预期收益：

  • 减少运营成本
  • 提升复用性
  • 提升稳定性与运维效率

第二阶段：业务扩容​

在现货 RFQ 基础上，逐步纳入更多产品线：

  • 合约
  • OTC
  • 理财

最终形成统一报价、统一交易入口、统一撮合与风控逻辑的多产品 RFQ 平台。

第三阶段：商业化与生态化​

把 RFQ 能力标准化为多租户 SaaS 方案，通过订阅制加“流动性租户”模式，服务线上或线下的中小型 P2P OTC 业务服务商。

这一步一旦跑通，RFQ 的角色就会从：

  • 公司内部交易系统

升级为：

  • 可输出的流动性与交易基础设施产品

如果这条路能走通，它的价值就不仅仅是支撑公司现有业务，而是变成新的收入模型与生态能力。

总结​

RFQ 项目最值得讲的地方，不是页面有多复杂，而是它把交易、风控、资产、合规、站点扩张、业务复用、数据驱动这些原本分散的能力，整合成了一套真正可规模化交付的交易底座。

对我来说，这个项目最大的收获不是“做完了一次改版”，而是理解了一个核心事实：

真正有价值的系统，不是把一个需求做完，而是把一类业务能力沉淀成平台。

如果后续要继续写下一篇，我会重点展开这个话题：

《RFQ Convert 参数统一建模：如何把 from/to 语义映射成可复用的交易执行模型》

Loading Comments...
0%