ADG · 产品技术会议 · 团队对齐版
系统收敛为两大底层：DeePayment × JoogoPay
📅 2026-07-02⏱ 约 1 小时 55 分👥 AD 主持 · 产品技术部
1核心决议：全集团系统架构收敛已拍板
- DeePayment = 全行业合规支付底层（SaaS）——StarPago、SimplyPay、StarPay 等品牌全部作为它的"客户"接入；未来 AI 支付在此底层之上构建。
- JoogoPay = 高风险线底层（原 BetCash 系统，名称已由 JoogoPay 取代）——加密兑换、外汇、去中心化博弈、预测市场等高风险业务全部归入 JoogoPay。
- 两大底层能力互通、互相赋能——DeePayment 也具备加密收付相关功能，JoogoPay 也获得卡收/Plugin/订阅等其他场景赋能；按行业风险划分品牌归属，不按能力切割。
- 所有上游一律对接在两大底层上，再由底层输出给各品牌系统——不再有"某国通道单独直连某品牌"的架构。
- 新 SaaS 同时部署到两大底层，之后统一用 DeePayment + JoogoPay 两个品牌对外，存量品牌客户逐步迁移。
- 终局：全集团只维护两套系统，其余逐步退役；BD 侧同步收敛，只对接这两个系统。
- "SaaS" 定义就此统一：部署在两大底层上的能力集，与单一品牌/域名无关（会前三人三种理解，已对齐）。
2人事任命与角色明确已拍板
- CTO：老冯（技术部唯一 CTO）。
- 小马哥：兼任项目经理（PM），不兼 CTO——统筹项目进度、跨线协调、AI 汇报机制落地。
- Tina：担任 DeeFinch 产品经理——C 端线产品缺口就此补位。
3墨西哥通道问题：新架构第一个落地案例
现状暴露的问题：StarPago 未直接接上游，而是桥接经过 StarPay（Pago 相当于 StarPay 的一个商户），流水口径混乱且风险集中在一套要退役的系统上。
- 统一解法（承接第 1 条架构决议）：所有上游一律对接在 DeePayment / JoogoPay 两大底层，再由底层输出给 StarPago、StarPay 等品牌系统——不再有"某国通道单独直连某品牌"的架构。
- 墨西哥三家上游（OPM、Funch、OXXO）按此接入底层，经底层输出给当前主推的 StarPago，去除 StarPay 桥接；订阅支付等新功能直接做在底层侧。
- 商户现状：活跃约 160+ 家（StarPay 70+、Pago 80+，少量重叠）；流水管理账口径待统一。
4支付场景全景（全部呈现）
| # | 场景 | 归属底层 | 状态 |
|---|
| 1 | 各国本地代收代付 API（B2B 核心） | DeePayment | 存量主力，迁移中 |
| 2 | 订阅支付（Subscription） | DeePayment | 新增，做在底层侧 |
| 3 | Visa/Master 卡收（线上） | DeePayment | 新方向 |
| 4 | Plugin 模块化接入（无 API 能力的中小商户，填 URL 级配置） | DeePayment | 新方向，上游明确有需求 |
| 5 | OXXO 等国家特定现金/到店场景 | DeePayment | 墨西哥已有 |
| 6 | 换汇/汇率输出（法币↔法币） | DeePayment | BD 明确要的输出能力 |
| 7 | 加密兑换（U↔法币、U→美金） | JoogoPay | 已有上游 |
| 8 | 外汇（高风险线） | JoogoPay | 归入 JoogoPay |
| 9 | 去中心化博弈、预测市场 | JoogoPay | 归入 JoogoPay |
| 10 | C 端钱包（DeeFinch：充 U→美金→各国法币） | DeePayment 供换汇底层 | 已有真实客户注册 |
| 11 | AI 支付（AideePay 终局：AI Agent 全球支付层） | 基于 DeePayment 底层 | 链路开始成形 |
| 12 | 加密收付（合规行业场景） | DeePayment | 与 JoogoPay 加密能力互通 |
注：两大底层能力互通——场景归属指品牌主责，不是能力墙；JoogoPay 同样获得卡收/Plugin/订阅等场景赋能。
5服务器成本盘点（收敛的直接动因）
| 系统 | 月成本 (USD) | 系统 | 月成本 (USD) |
|---|
| BCPay | 27,000 | StarPago 巴基斯坦 | 5,500 |
| StarPago（主） | 16,000 | DeeFinch | 5,000 |
| 菲律宾+孟加拉+泰国 | ~10,000 | 新 SaaS（BETA） | 4,500 |
| StarPago 印度 | 4,000 | StarPay | 3,900 |
| StarPago 印尼 | 2,700 | 合计 | ≈78,600/月 |
"一个国家一套系统"是成本大头——收敛到两大底层就是降本主线。
6AI 工作方式定调全员对齐
AD："AI 是手，不是脑。" 认知必须超越 AI——它是帮手，但它骗你时你要能发现。
- 问题：AI 写完代码没测全就扔测试环境，反而增加负担；产品文档不够全是根因之一。
- 技术线建立标准 AI 工作流：输出 → AI 跑 → 人检查 → 评估奖惩。
- 关键岗位知识必须用 AI 蒸馏沉淀成文档，消除"一个人不在就没人能解决"的单点风险。
- 汇报方式升级：会议与进度以后用 AI 同步，AD 要求 12–24 小时内可见全部进度。
7新技术部门架构
技术部（CTO：老冯）
│ 项目经理：小马哥（兼任，不兼 CTO）：项目进度 / 跨线协调 / AI 汇报机制
│
├── DeePayment 底层组（全行业合规 SaaS）
│ 上游统一对接 · API/订阅/卡收/Plugin/换汇/加密收付能力建设
│ 输出给：StarPago · SimplyPay · StarPay ·（未来 AideePay）
│
├── JoogoPay 底层组（原 BetCash 系统并入）
│ 加密兑换 · 外汇 · 去中心化博弈 · 预测市场
│ 并获其他场景赋能（卡收/Plugin/订阅等，与 DeePayment 能力互通）
│
├── 存量系统维护与迁移组
│ StarPay / StarPago 各国 / BCPay 维护 · 客户迁移 · 逐步退役降本
│
├── DeeFinch（C 端）线 —— 产品经理：Tina
│
└── 横向机制（全员）
AI 工作流（输出→AI 跑→人检查→奖惩）
关键岗位知识 AI 蒸馏（先 DBA）
AI 进度汇报 → AD（12–24 小时可见）
8行动方案（三阶段）
- 收敛期（当前）：新 SaaS 部署到两大底层；所有上游改接底层（墨西哥为首个落地案例）；全品牌账号盘点；SaaS 定义/架构图全员宣贯。
- 迁移期：存量品牌客户迁移到两大品牌；原 BetCash 系统并入 JoogoPay（名称统一）；冗余系统退役，服务器成本从 ≈78,600 USD/月基线往下压。
- 新能力期：Visa/Master 卡收 + Plugin 产品化；订阅支付上线；DeeFinch 换汇链路打通；AI 支付（AideePay）在 DeePayment 底层上启动。
9后续具体事项
| # | 事项 | 负责 | 阶段 |
|---|
| 1 | 新 SaaS 部署到 DeePayment + JoogoPay 两底层，两品牌对外 | 技术部（CTO 老冯） | 收敛期 |
| 2 | 墨西哥三家上游（OPM/Funch/OXXO）接入 DeePayment 底层，经底层输出给 StarPago，去除桥接 | 技术部 | 收敛期 |
| 3 | 全品牌产品账号盘点 | 技术部 | 收敛期 |
| 4 | 支付场景全景（十二大场景）逐一呈现成产品文档/演示 | 产品 + 技术部 | 收敛期 |
| 5 | DeePayment 底层与老冯对齐对接方案 | AD + 老冯 | 收敛期 |
| 6 | 项目管理机制搭建（进度看板 + AI 汇报给 AD） | 小马哥（PM） | 收敛期 |
| 7 | 存量品牌客户迁移方案（StarPay/StarPago/BCPay/SimplyPay） | 技术部 + BD | 迁移期 |
| 8 | 原 BetCash 系统并入 JoogoPay（名称统一） | 技术部 | 迁移期 |
| 9 | 冗余系统退役与服务器降本计划 | 技术部 | 迁移期 |
| 10 | 关键岗位知识 AI 蒸馏成文档 | 技术负责人 | 收敛期起 |
| 11 | 技术线 AI 工作流（输出→AI→检查→奖惩）制度化 | CTO 老冯 | 收敛期起 |
| 12 | Visa/Master 卡收 + Plugin 产品方案 | 产品 + 技术部 | 新能力期 |
| 13 | 订阅支付功能上线（底层侧） | 技术部 | 新能力期 |
| 14 | DeeFinch 线交接给 Tina（产品经理），AD 单独约该线 | Tina + AD | 收敛期 |
| 15 | 组织全员技术会议 | Tina | 收敛期 |
| 16 | 本纪要同步全员 | AD → Tina | 即刻 |