软件公司接一个「交易系统对接」项目，最常见的失败方式不是技术不行，而是在还没有地图的时候就开始挖地基：开发不知道行情是谁的责任、风控挂在哪个模块、回测数据从哪来、和客户的边界在哪。本篇文章先解决「全景」问题——一张系统地图、一份模块清单、一组角色分工，最后是里程碑与风险点。
读完你应该能回答三个问题：系统里有哪些模块？每个模块对接谁？团队里谁负责什么？
1. 交易软件系统地图
先看整体。任何一个「能真实下单、能真实亏钱」的交易软件，无论做得多大，解剖开都逃不出这张图：
┌─────────────────────────────────────────────────────────────┐
│ 客户端前端（用户侧） │
│ 桌面端 / Web / 移动端：图表、下单面板、持仓、账单、风控面板 │
└──────────────────────────────┬──────────────────────────────┘
│ 内部接口（REST / WebSocket / gRPC）
┌──────────────────────────────▼──────────────────────────────┐
│ 网关层（API Gateway） │
│ 统一鉴权 / 限流 / 路由 / 协议转换 / 多端接入 / 请求幂等 │
└──────────────┬─────────────────┬────────────────┬────────────┘
│ │ │
┌─────────▼──────┐ ┌───────▼───────┐ ┌─────▼───────────┐
│ 行情服务 │ │ 交易服务 │ │ 账户与资金服务 │
│ 行情网关/订阅 │ │ 订单路由/状态机 │ │ 余额/冻结/持仓 │
│ 快照/增量/落库 │ │ 回报处理/对账 │ │ 出入金/结算 │
└─────────┬──────┘ └───────┬───────┘ └─────┬───────────┘
│ │ │
┌─────────▼─────────────────▼────────────────▼───────────┐
│ 风控服务（独立进程） │
│ 前置校验 / 实时监控 / 熔断 / 审计留痕 —— 可拦截一切下单 │
└──────────────────────────┬──────────────────────────────┘
│
┌───────────────────────────────▼──────────────────────────────┐
│ 柜台 / 交易所 API（对接层） │
│ CTP DLL │ 恒生 UFT │ 易盛 │ 加密 REST/WS │ FIX │ IB API │
└───────────────────────────────┬──────────────────────────────┘
│ 交易所专线 / 公网 / 私有网络
┌───────────────────────────────▼──────────────────────────────┐
│ 交易所 │
│ 撮合引擎 / 清算 / 结算 / 风控 │
└───────────────────────────────────────────────────────────────┘
三个要点，第一次看图就该记住：
- 风控不在交易链路里，而是架在链路中间的一道闸门。 所有下单请求都必须穿过风控服务，风控与策略、交易代码分离（详见 05-风控与资金管理.md）。
- 行情与交易是两条独立的链路。 行情高频（每秒成百上千次）、交易低频（每笔几十毫秒），任何把它们耦合在同一队列的系统都会互相拖死。
- 对接层（柜台/交易所 API）是系统里最不稳定、最不可控的部分，它不归你管，一切工程手段（超时、重试、对账、冗余）都是围绕「对面不可信」设计的。
💡 模块边界一句话原则
行情系统只产数据，交易系统只动订单，账户系统只记钱，风控系统只说不，数据仓库只存档。 谁越界，谁的 bug 就越难查——行情与交易是两条独立链路，任何把它们耦合在同一队列的系统都会互相拖死。
2. 系统模块清单
| 模块 | 职责 | 关键输出 | 归属（典型分工） |
|---|---|---|---|
| 行情系统 | 行情接入、订阅分发、快照/增量、落库 | tick 流、K 线、盘口深度 | 后端开发 + 行情网关 |
| 交易系统 | 下单、撤单、订单状态机、回报处理 | 订单流水、成交回报 | 后端开发（核心） |
| 账户与资金 | 余额、冻结、持仓、出入金、结算 | 账户快照、资金流水 | 后端开发 |
| 风控 | 前置校验、实时监控、熔断、留痕 | 拦截记录、风控日志 | 风控 + 后端开发 |
| 清算结算对账 | 与柜台/交易所核对委托与成交、处理差异 | 对账报告 | 后端开发 + 风控 |
| 报表 | 账单、持仓报告、盈亏报表、监管报表 | PDF/Excel 报表 | 后端开发 |
| 监控告警 | 系统指标、行情延迟、订单成功率、资金异常 | 告警通知 | SRE |
| 数据仓库 | 行情、订单、资金的历史归档与查询 | 分析表、接口供回测 | 数据开发 |
| 回测研究 | 用历史数据验证策略，产出参数 | 回测报告、策略参数 | 量化研究员 + 策略工程师 |
模块边界的一句话原则：行情系统只产数据，交易系统只动订单，账户系统只记钱，风控系统只说不，数据仓库只存档。 谁越界，谁的 bug 就越难查。
3. 对接对象
一个交易软件要对接的外部对象，比一般软件多得多，且每一类都有完全不同的对接姿势：
| 对接对象 | 对接什么 | 特点 | 谁在管 |
|---|---|---|---|
| 交易所（直连） | 加密交易所 REST/WebSocket、CME FIX 等 | 协议公开、文档全、无中间层 | 后端开发 |
| 柜台（期货/证券） | CTP、恒生、易盛等柜台 API | 二进制/C++ DLL、需 AppID 认证、文档不公开 | 后端开发（需权限申请） |
| 数据供应商 | Wind、聚宽、天软、TickData 等 | 历史数据补全、复权、基本面数据 | 数据开发 |
| 银行 | 出入金、银期转账、银证转账 | 对公接口、审批流程长、对账麻烦 | 后端 + 商务 |
| 券商/期货公司 | 开户、结算单、**保证金**追加、风控通知 | 人工流程多，联调排期受制于人 | 项目经理 + 合规 |
一个反常识点：对接最难的不是交易所，而是柜台和银行。 交易所（尤其是加密交易所）文档公开、测试环境开放、自测即可；柜台文档要签协议才能拿到，接口是私有二进制协议，联调窗口受柜台方排期控制；银行接口涉及密钥证书、网银审批，动不动以「周」为单位。
⚠️ 对接最难的不是交易所而是柜台和银行
对接最难的不是交易所，而是柜台和银行。 柜台文档要签协议才能拿到、接口是私有二进制协议、联调窗口受对方排期控制；银行接口涉及密钥证书与网银审批，动不动以「周」为单位。
4. 岗位分工
量化研究员（Quant Researcher）
研究「怎么赚钱」的人。负责策略假说、因子挖掘、历史数据回测验证、绩效归因。不碰生产代码——研究代码写崩了浪费的是算力，生产代码写崩了亏的是真金白银。与策略工程师之间通过「策略描述文档 + 回测报告」交接，是团队里唯一不需要值班的岗位。
量化交易员（Quant Trader）
在研究员与实盘之间搭桥的人。负责理解策略逻辑、盯实盘运行、对异常行情与策略行为做判断、决定何时暂停/重启策略。交易员是风控触发时的第一响应人，也是最常被深夜电话吵醒的人。与策略工程师共同确认「策略上线参数」，与风控确认「策略敞口上限」。
策略工程师（Strategy Engineer）
把研究员的想法变成可运行程序的人。负责策略代码的工程化实现、数据接口接入、参数管理与版本管理、仿真环境验证。策略工程师写的代码运行在策略进程里，永远不直接持有交易权限——它只能通过交易接口发出「建议订单」，由风控闸门裁决。这是团队里最容易和「后端开发」混淆的岗位，两者分工见下表。
后端开发（Backend Engineer）
系统骨架的搭建者，也是对接层的唯一责任人。负责行情网关、交易服务、账户服务、对账模块、以及最核心的柜台/交易所 API 对接。后端开发是唯一直接持有柜台/交易所密钥、直接触达下单链路的人，因此必须写幂等、写重试、写状态机——对接层的每一条守则（见 04）都是给这个岗位的。
前端开发（Frontend Engineer）
负责客户端界面：行情图表、下单面板、持仓与账单页面、风控面板、告警展示。前端不与柜台打交道，但必须理解订单状态机的语义（什么状态可以撤、什么状态已成交），因为下单面板是所有错误的最直接出口。与后端通过接口文档与 Mock 服务协作。
运维 SRE（Site Reliability Engineer）
保证系统「活着」的人。负责服务器与网络、行情延迟监控、进程守护、日志收集、数据库运维、灾备与演练、发布与回滚。SRE 的 KPI 是可用性指标（行情延迟 P99、下单成功率、系统可用率），并对「交易时段内不允许发布、只允许紧急修复」这条铁律负责。
风控（Risk Manager / Risk Engineer）
「说不行」的人。负责风控规则制定（资金/仓位/频率**止损**）、风控参数配置、熔断决策、审计日志的定期审查、对账差异的复核。风控岗拥有系统里唯一的特权：一键熔断所有账户。风控不写策略代码，但风控规则由 TA 制定并验收——这是典型的「裁判不能是运动员」。
合规（Compliance）
对接中最容易被忽略、出事时最重要的岗位。负责开户资料、交易所/柜台权限申请、交易编码管理、监管报表、密钥与权限的定期审计、异常交易行为自查。合规不写代码，但每一个「权限申请单」「密钥轮换」「交易编码注销」流程都由合规把关。
岗位协作关系（一张图）
量化研究员 ──策略描述──▶ 策略工程师 ──实现────▶ 后端开发 ──下单──▶ 柜台/交易所
▲ │ ▲
│ ▼ │
回测报告 风控参数确认 │
│ │ │
量化交易员 ──实盘监控/决策────┴──────────风控闸门────┘
▲ │
│ ▼
└────────────── 风控 / 合规 / SRE（独立于策略链路）
5. 常见组织架构
大厂量化团队（如头部私募、券商自营）
- 岗位细分极致：研究员再分因子/基本面/高频，后端再分行情/交易/数据/底层架构。
- 风控是独立部门，有独立的开发与运维，与策略团队是「隔离墙」关系，风控代码不允许策略团队触碰。
- 基础设施自研率高：自研行情网关、自研撮合模拟器、自建机房或专线。
创业公司 / 小型软件公司（本篇文章的典型读者）
- 一人多岗：通常 3-6 名工程师撑起全部模块，典型配置是「1 名后端（兼行情+交易）、1 名后端（兼账户+对账）、1 名前端、1 名全栈（兼风控与数据）、0.5 名 SRE、0 名专职风控——由交易员兼职」。
- 风控兼职是最大的隐患，建议至少做到：风控参数改动需要两个人确认，风控日志独立存储。
- 柜台/交易所 API 对接外包的很少，但行情数据、历史数据、机房托管常常采购第三方。
💀 任何角色都无权无留痕修改风控参数
任何角色都无权在无留痕的情况下修改风控参数。 下单链路与策略代码必须物理隔离（策略崩了不影响交易链路），密钥只给一个人管并有轮换机制，风控校验独立于交易逻辑——即使只有两个人，这几条红线也绝不能破。
小团队的组织红线（即使只有两个人）
- 下单链路与策略代码物理隔离：策略崩了不影响交易链路。
- 风控校验独立于交易逻辑：风控代码由交易系统调用，而不是交易逻辑里顺手写一个 if。
- 密钥只给一个人管，并且有轮换机制。
- 任何角色都无权在无留痕的情况下修改风控参数。
6. 项目里程碑
① 调研（2-4 周） → ② 联调（4-8 周） → ③ 模拟盘（4-8 周）
需求梳理/柜台选定 CTP/交易所接口打通 全流程仿真
权限申请/文档索取 行情+下单+账户联调 双人确认 + 对账跑通
架构评审/里程碑评审 异常路径测试
④ 实盘试运行（2-4 周） → ⑤ 正式上线
小资金/单账户 全量账户切换
每日对账/问题清单 监控与值班就位
熔断演练/灾备演练 停止新功能开发窗口
| 里程碑 | 进入条件（DoD） | 常见失败 |
|---|---|---|
| 调研完成 | 柜台/交易所文档确认、权限申请回执、架构评审通过 | 没拿到文档就开工；没确认「对方测试环境是否开放」 |
| 联调完成 | 行情、下单、撤单、回报、对账全路径跑通；异常注入测试（断网/拒单/重复回报）通过 | 只测 happy path；用生产账号测（严禁） |
| 模拟盘通过 | 连续 N 个交易日全流程对账一致；风控拦截命中率 100% | 模拟盘与实际资金行为不一致（滑点、限频）没被发现 |
| 试运行通过 | 小资金实盘连续 M 天无重大事故；监控告警全部生效；每日对账记录齐 | 试运行期间直接放开大额权限 |
| 正式上线 | 灾备演练通过、值班表就位、回滚方案确认、合规备案完成 | 上线当天改代码；上线后发现密钥在代码仓库里 |
里程碑的每一阶段都有明确的「进入条件」和「退出条件」，没有 DoD 的里程碑只是日历上的日期。
7. 主要风险点
对接项目的风险，绝大多数在项目启动前就埋下了：
| 风险 | 表现 | 对策 |
|---|---|---|
| 需求边界不清 | 客户以为「做系统」含开户与合规流程，团队以为只管接口 | 合同写清对接对象清单与验收标准（见里程碑 DoD） |
| 权限周期失控 | 柜台 AppID、交易所 API Key、行情权限申请 2 个月没下来 | 调研阶段第一周就发起全部权限申请 |
| 文档/测试环境不可得 | 某些柜台仿真环境不对公开放 | 提前确认，准备「无测试环境的降级方案」（自建模拟柜台） |
| 联调排期受制于人 | 柜台方每周只有一天联调窗口 | 把联调窗口当资源排期，提前约满 |
| 试运行即全量 | 小资金测试一周就急着切全量 | 用里程碑卡死：对账不一致不允许扩大资金 |
| 一人独占系统 | 全系统只有一个人看得懂，TA 离职即停摆 | 强制文档化 + 双人复核 + 轮岗 |
风险提示
⚠️ 风险提示
本篇章定位为工程对接的全景说明，不构成任何投资建议。真实资金的交易系统对接是高风险工程：任何「先上线、后补风控」「先用生产账号联调」「密钥入库」的做法都可能直接导致资金损失。请务必在模拟盘完成全流程对账与异常注入测试后再进入实盘阶段，并对每一次权限变更、每一次风控参数修改保留完整留痕。