项目价值速览
从交易入口，走向分行可自主经营的微信黄金渠道
客户侧形成开户、交易和资产管理闭环，分行侧同步获得渠道、数据、运营与运维能力。
项目复用总行积存金、电子二类户、风险测评、报价和核心交易能力，由分行重新设计微信入口、客户状态路由、开户与资金路径、交易后数据加工以及持续经营机制。
- 累计交易额
- 21 亿元+正式上线后的累计业务结果。
- 新增用户
- 5 万+正式上线后的累计业务结果。
- 持续迭代
- V1—V1.4围绕交易、数据、合规与稳定性持续演进。
客户旅程
在微信内连续完成资格判断、开户、资金准备、买卖、持仓与收益查看。
分行经营
承接支行推广、活动运营、渠道归属、数据分析和客户后续经营。
生产能力
围绕真实交易建立状态追踪、错误定位、批量校正与持续运维机制。
这不是重建黄金交易核心，而是把总行成熟能力、微信客户触达和分行经营能力连接成一条可生产运行的完整链路。
业务背景、用户问题与项目目标
从“已有交易入口”到建设分行自主经营渠道
项目并非因为市场缺少积存金，而是要在手机银行和第三方平台之外，建立由银行自主经营、能够承接微信流量并持续沉淀客户关系的自有渠道。
积存金和总行核心能力已经成熟，第三方合作也验证了微信生态中的客户需求与经营价值。但合作模式在渠道自主权、手续费分成和客户经营数据沉淀方面存在长期约束；手机银行能够交易，却无法完全替代微信触达、支行私域和活动传播所对应的客户旅程。
因此，项目真正要回答的不是“能不能再做一个黄金页面”，而是“如何把已经存在的投资需求，更有效地转化为银行自己的客户、交易和长期经营关系”。
需求已经存在
黄金投资需求和微信场景价值已经被验证，项目重点是承接与转化，而不是创造全新品类需求。
补足渠道自主权
第三方负责借助外部平台获得流量，自营渠道负责银行能否自主承接、转化和持续经营客户。
微信承担不同旅程
把微信触达、即点即用、资格判断、开户、资金准备和真实交易尽量放在同一条路径内完成。
竞争转向经营能力
竞争不再只是有没有产品，而是渠道是否开放、体验是否连续以及能否持续运营客户。
核心用户问题
客户要完成的是一次投资，不是理解银行内部系统
客户侧｜路径长且状态复杂
协议、二类户、身份、人脸、风险测评、积存金开户、充值和交易连续发生；产品必须依据客户当前状态动态决定下一步。
业务侧｜触达与经营断开
如果最终仍跳回手机银行或第三方，分行难以把营销继续连接到开户、首购、支行归属、活动、漏斗与再经营。
产品侧｜原子能力不等于旅程
总行能力回答某一金融动作能否执行，产品需要继续回答客户能否购买、缺少什么条件、资金如何准备以及结果是否确定。
一期目标
先证明自营渠道能够真正承接金融交易
交易闭环
跑通准入、开户、风险测评、资金准备、买卖、持仓与收益查看。
渠道增长
验证微信小程序能否成为手机银行和第三方之外的新客户承接入口。
自主经营
建立支行归属、活动配置、用户与交易统计等基础经营能力。
生产可用
满足账户、适当性、交易、数据和合规要求，并能定位与处理生产异常。
项目价值不是多做一个积存金入口，而是连接微信触达、总行金融能力和分行自主经营，建立银行自己能够掌握的“获客—开户—交易—经营”链路。
整体解决方案与客户旅程
总行核心复用、分行流程与数据编排、小程序场景交付
以客户状态为主线，将账户、适当性、资金、交易、持仓和运营能力组织成连续闭环。
买入、充值并购买与卖出交易编排
交易前校验、价格预查询、资金处理、核心交易、交易后加工和结果恢复共同构成一次完整交易。
一次交易由前置校验、价格预查询、资金处理、核心成交、交易后加工和结果恢复六段组成。
- 余额充足直接买入，我行卡余额不足可充值并购买，他行卡先充值再购买。
- 核心成交事实与持仓、成本和收益等后处理分开。
- 请求已发出但结果未确定时保留处理中状态，并提供后续查询与恢复。
当前闭环
客户主旅程
让客户按当前状态完成下一步，而不是理解内部系统边界。- 进入黄金专区并识别客户状态
- 完成准入、协议与电子二类户
- 完成风险测评与积存金开户
- 根据账户能力准备资金
- 预查询价格并完成买入或卖出
- 查看持仓、收益、明细与账户服务
核心能力
- 状态路由
- 开户前置
- 差异化资金路径
- 交易结果承接
总行核心能力
继续承担实名、电子二类户、风险测评、报价、积存金账户与核心买卖等权威处理。
分行产品编排
负责客户状态识别、页面路由、开户与资金路径、交易阶段状态、本地数据加工和异常承接。
经营与运行支撑
补齐渠道归属、活动、用户与交易分析、批量任务、日志、错误统计及客诉定位。
客户看到的是一条连续旅程，系统内部则通过状态路由和分层编排，在不改变总行权威边界的前提下完成体验与经营闭环。
关键产品决策
六项取舍，控制一期范围与生产风险
每个决定都对应账户、资金、数据或生产约束，并保留明确代价。
复用总行核心，不自建交易核心
- 业务约束
- 账户、适当性、报价、协议和核心交易受统一制度与风险体系约束。
- 产品决策
- 总行承担金融核心，分行负责客户入口、状态路由、流程编排、数据加工和经营能力。
- 选择原因
- 降低合规与建设风险，把资源集中在客户旅程和渠道经营。
- 代价与边界
- 产品能力受总行接口性能、业务规则和版本节奏约束。
01复用总行核心，不自建交易核心
- 业务约束
- 账户、适当性、报价、协议和核心交易受统一制度与风险体系约束。
- 产品决策
- 总行承担金融核心，分行负责客户入口、状态路由、流程编排、数据加工和经营能力。
- 选择原因
- 降低合规与建设风险，把资源集中在客户旅程和渠道经营。
- 代价与边界
- 产品能力受总行接口性能、业务规则和版本节奏约束。
02把高成本失败尽量前置
- 业务约束
- 客户可能完成二类户等高成本操作后才发现协议重复、账户上限或风险不匹配。
- 产品决策
- 正式开户前先检查本地账户、实名信息、存量协议、二类户数量和风险状态。
- 选择原因
- 在用户投入大量操作之前暴露问题，并跳过已经完成的步骤。
- 代价与边界
- 需要增加接口调用和状态同步，链路复杂度提高。
03一期优先闭环主动买卖
- 业务约束
- 一期时间和跨团队资源有限，需要先验证自营渠道能否承接真实金融交易。
- 产品决策
- 优先跑通开户、资金准备、买卖、持仓收益和账户管理。
- 选择原因
- 以最短路径获得真实用户、交易和生产反馈。
- 代价与边界
- 定期积存、提醒等增值能力后置。
04按账户能力设计差异化资金路径
- 业务约束
- 行内卡和他行卡的充值、支付能力不同，强行统一会增加失败。
- 产品决策
- 我行卡余额不足可充值并购买；他行卡先完成充值，再进入购买。
- 选择原因
- 在能力边界内缩短行内客户路径，同时保留跨行准入。
- 代价与边界
- 他行客户步骤更多，产品需要清楚解释当前资金状态。
05采用边界清晰的本地成本收益口径
- 业务约束
- 总行累计字段无法直接满足小程序展示，全渠道成交数据也不实时完整。
- 产品决策
- 基于小程序渠道交易计算移动加权平均成本，并区分实时收益与 T-1 历史收益。
- 选择原因
- 选择可持续计算、可以验证且能够向客户解释的口径。
- 代价与边界
- 结果只代表小程序渠道，不等同全渠道统一口径。
06核心成交与交易后处理解耦
- 业务约束
- 核心成交后持仓查询可能因并发或外部依赖失败，不能覆盖真实交易结果。
- 产品决策
- 核心成交独立确认，持仓、成本和收益后处理可降级，并通过刷新与批量同步校正。
- 选择原因
- 确保金融事实优先，避免把局部失败错误展示为整笔交易失败。
- 代价与边界
- 本地持仓仅是临时兜底，最终仍需总行权威结果校正。
产品不以页面最少或流程完全统一为目标，而是在强规则、多系统约束下，让高成本失败前置、关键结果清晰、异常能够恢复。
产品与系统设计
产品功能、状态路由与交易流程形成统一设计
平台同时服务个人客户、支行推广、业务运营以及客服运维，不以单一客户端页面定义产品边界。
产品功能总体架构
从用户触点、业务应用、核心产品机制、数据运行支撑到总行既有能力形成五层闭环。
从用户触点、业务应用、核心机制、数据运行支撑到总行及既有能力，说明平台同时具备客户交易与分行经营两类产品能力。
客户侧产品
专区首页、开户、风险测评、账户资金、买入卖出、资产收益、明细查询和客服。
经营运营侧
渠道与网点归属、活动规则与达标、用户和交易统计、埋点漏斗及批量运行。
核心产品机制
客户状态路由、开户资格前置、交易编排、收益计算、错误解释与异常恢复。
系统、接口与数据机制
让职责边界、阶段状态和权威来源成为共同语言
系统设计不止是接口字段清单，而要统一回答谁负责什么、业务进行到哪一步、事实来自哪里以及异常如何恢复。
整体系统架构
分行编排层承接客户触点，连接总行原子能力与本地数据、批量和运营体系。
分行在线服务与编排层连接客户触点和总行原子能力，本地数据、批量与运营支撑层承接数据加工、配置和运行观测。
当前运行机制
准入与开户
依据客户状态动态路由，并在高成本操作前识别关键限制。业务输入
- 协议与实名状态
- 电子二类户与绑定卡
- 风险测评和积存金账户
执行过程
- 读取本地与总行状态
- 执行开户资格预判断
- 跳过已完成步骤并路由下一步
状态输出
- 直接进入专区
- 继续开户或补测评
- 明确不可办理原因
数据口径与运行边界
权威事实
账户、实际持仓、报价和核心成交以对应总行能力为权威，本地保存必要过程与快照。
本地衍生
成本和收益基于小程序渠道交易计算，明确属于单渠道口径，不外推为全渠道统一结果。
实时与历史
实时持仓收益使用实时金价，历史每日收益使用 T-1 收盘价，避免混淆时间基准。
经营与运行
渠道、活动、埋点、返回码和批量日志服务产品运营与问题定位，不替代正式财务核算。
生产落地、运营与项目成果
通过多轮灰度，把产品从能跑、做对、做稳推进到可经营
真实上线不是项目结束，而是产品开始面对真实客户、容量、外部依赖和持续经营的起点。
2025.05
启动与调研
确认业务范围，核对总行能力与测试接口，多轮迭代产品原型。阶段输出：一期范围与可行性明确2025.06—07
设计与研发
推进 UI、接口流程、数据计算逻辑、研发周会与前后端联调。阶段输出：核心功能进入投产准备2025.08—09
灰度与验收
多轮全链路测试、数据修正、消保文案和异常路径加固。阶段输出：核心流程完成测试并对客运行2025.09 起
运营与持续优化
围绕活动、报表、渠道归属、性能并发、客诉与错误持续迭代。阶段输出：从可交易进入可经营、可运维后续阶段
能力扩展
在一期稳定运行基础上继续调研定期积存等产品能力。阶段输出：进入下一阶段方案设计
生产结果
一期核心闭环正式上线并持续迭代，累计交易额 21 亿元+、新增用户 5 万+。
质量保障
全流程测试和灰度阶段推动修复后端问题 20 余项、前端优化 50 余项；仅作为测试与上线保障贡献。
运营运维
上线后继续通过活动、报表、错误分析、批量日志和客诉定位，把生产信号重新转化为产品需求。
我的贡献与项目复盘
把业务目标、金融规则和生产约束转化为完整产品方案
我的核心职责覆盖业务与产品定义、核心机制、系统数据、质量交付以及上线后的经营运维；具体研发与专业规则由对应团队共同完成。
已完成成果
0 → 1 建成自营渠道
完成首页、开户、风险测评、账户、买卖、持仓收益、记录、客服与运营闭环。
进入正式生产与持续经营
通过多轮灰度和全流程测试完成正式投产，并持续处理活动、数据和生产问题。
形成真实业务规模
累计交易额 21 亿元+，新增用户 5 万+。
真实边界
- 本人承担主要产品判断、方案转译、测试验收、投产和上线后运营推进；具体前后端研发由广州研发中心团队完成。
- 业务规则与合规口径由分行结算、网金等专业部门共同确认；总行提供既有账户、适当性和积存金核心能力。
- 累计交易额不等同于净流入、AUM、资产沉淀或收入；新增用户不等同于新增银行客户或高质量活跃用户。
个人核心贡献
业务与产品定义
把“做一个积存金小程序”重新定义为“总行核心复用 + 分行渠道编排 + 数据经营闭环”，明确项目边界和一期优先级。
核心产品机制
设计客户状态路由、开户前置判断、差异化资金路径、预查询锁价、充值并购买、交易后加工和异常恢复机制。
系统与数据设计
组织账户、适当性、交易、资产、行情和运营能力，设计关键接口流程、阶段状态、数据对象及成本收益口径。
质量与生产交付
负责全流程测试和数据核验，推进多轮灰度、生产配置、问题沟通、投产申请和正式上线。
上线后经营与运维
持续参与活动、经营看板、错误分析、埋点、客诉定位以及并发与持仓问题优化。
关键复盘
更早建立经营指标体系
从渠道、激活、开户、首购、持仓、复购到留存形成统一漏斗和指标字典，并区分自然流量与活动流量。
更早统一状态与对账语义
提前定义核心成交、资金、持仓和后处理结果的统一状态，并逐步建立自动对账、差错和可重算机制。
更早规划全渠道一致性
提前规划手机银行、柜面与小程序等渠道的完整成交数据，避免成本收益长期停留在单渠道口径。
更早沉淀生产治理标准
建立容量基线、监控告警、发布清单、回滚预案和服务指标，把灰度经验沉淀为标准机制。
持续关注增长质量
活动不能只看短期新增与交易额，还需观察持仓、复购、卖出、留存、活动成本和长期客户质量。
产品证据
产品证据与截图
截图只用于证明产品机制；页面数据与对话内容均为匿名化合成素材。产品功能总体架构
页面说明展示客户侧、经营侧、核心机制、数据支撑与总行能力之间的完整产品边界。
用户任务理解平台不只是交易页面，还包含经营和运行能力。
证明机制呈现从客户触点到总行核心的五层产品结构。
开户与状态路由
页面说明展示协议、电子二类户、适当性和积存金开户的连续编排。
用户任务理解系统如何依据客户状态决定下一步。
证明机制体现开户资格前置与已完成步骤跳过机制。
交易编排与结果恢复
页面说明展示买入、充值并购买和卖出的校验、资金、核心交易与后处理链路。
用户任务理解不同账户和余额状态如何进入可用交易路径。
证明机制体现核心成交优先、后处理可恢复的交易原则。
系统架构、接口与数据机制
页面说明展示分行编排、总行原子能力、本地数据运行、接口编排与数据加工体系。
用户任务理解总分行职责、接口编排和本地数据加工如何共同完成业务。
证明机制用整体系统架构、接口与交易架构、数据架构与数据处理体系三张原图呈现职责边界与一致性治理。
数据一致性与异常恢复
页面说明展示权威来源、本地状态、用户刷新和批量校正的协作方式。
用户任务理解局部失败发生后，持仓和派生结果如何被恢复。
证明机制体现总行权威结果不被本地局部失败覆盖。
积存金首页与资产总览
页面说明真实产品原图，展示持仓克重、持仓价值、收益、实时金价、交易记录和买卖入口。
用户任务快速了解当前黄金资产状态并进入后续交易或账户服务。
证明机制将资产查看、行情和交易入口组织在同一客户首页。
开户、身份验证与风险测评
页面说明真实产品原图，依次展示开户提示、证件上传、人脸验证、信息填写以及风险测评完整流程。
用户任务完成积存金交易前的账户、身份与适当性要求。
证明机制呈现多套账户和风险能力如何被组织进连续开户旅程。
购买与充值并买入结果
页面说明真实产品原图，展示买入克重、实时金价、预计支付、资金账户以及充值并购买成功结果。
用户任务确认交易要素、选择可用资金路径并查看最终成交结果。
证明机制呈现价格、资金与核心买入能力在客户端的连续反馈。
收益明细与交易记录
页面说明真实产品原图，展示买入、卖出、克重、金价、手续费、成本和收益等历史信息。
用户任务查询历史交易和持仓收益变化。
证明机制将过程交易、成功流水及收益口径转化为客户可查询明细。
账户管理、充值、提现与交易明细
页面说明真实产品原图，展示电子账户总览、绑定卡、充值、提现和账户交易明细。
用户任务管理积存金资金账户并查询账户级资金变化。
证明机制承接我行卡与他行卡对应的账户和资金操作路径。
版本与投产演进
页面说明展示项目从投产准备、灰度测试、版本验收到正式对客运行的演进。
用户任务理解强规则金融产品为何需要多轮灰度。
证明机制体现功能、数据、合规与稳定性风险被逐步收敛。
个人贡献与团队边界
页面说明展示本人主责、跨团队共同决策与专业团队交付之间的职责关系。
用户任务理解项目成果由不同团队如何共同完成。
证明机制避免把具体研发或全部经营结果表述为个人独立产出。