## Dolores：机构级 AI 交易基础设施的产品化实践

> **目标岗位**：Web3 产品经理（后端 / 中台方向）
> **关键词**：Copy Trading、风控引擎、数据策略、AI Agent、B 端系统
> **项目定位**：面向跟单交易 SaaS 的核心信号与风控引擎

---

## 一、为什么我做了 Dolores？

在 Web3 交易产品中，我观察到一个长期存在却被忽视的矛盾：

* **散户真正想要的是“长期可复现的 Alpha”**
* 但主流跟单产品提供的却是：

  * 激进、不可解释的人类交易员
  * 或黑箱 AI 信号，回撤和爆仓风险不可控

于是我提出了一个反问题：

> **如果“跟单的不是人，而是一个可解释、可约束、可风控的 AI 交易系统”，会发生什么？**

**Dolores** 就是在这个假设下构建的：
它不是一个 Bot，而是一套**可作为跟单交易 SaaS 核心引擎的 AI 交易基础设施**。

---

## 二、项目一句话定义（面试官版）

> **Dolores 是一个“信号提供商（Signal Provider）级别的 AI 交易系统”，
> 它将非结构化市场信息标准化为可执行的交易决策，并通过中台风控系统确保策略可长期存活。**

这正是我投递 **Web3 产品经理（后端 / 中台 / 跟单交易）** 所需要展示的能力。

---

## 三、我如何匹配 JD 的核心要求？

### 1️⃣ 跟单 / Copy Trading 产品理解

在 Dolores 中，我**刻意没有把“交易执行”作为核心产品**，而是把系统设计成：

* 一个 **Signal Provider**
* 对外输出：

  * 决策方向
  * 仓位建议
  * 风险状态
  * 决策理由（Decision Log）

这使它天然适配：

* 跟单交易市场（供给侧）
* B2B2C 模式
* Social Alpha 订阅模型

**用户不是盲目复制交易，而是订阅一套“可解释的投资逻辑”。**

---

### 2️⃣ 后端 / 中台系统能力

整个系统采用**模块化微服务架构**，而非脚本拼接：

* 数据层（ETL）
* 推理层（AI Agent）
* 中台层（Risk / PMS / OMS）
* 执行层（实盘 / 模拟解耦）

这让我可以在产品层面回答：

> “如果从 Paper Trade 切到实盘，需要改哪里？”

答案是：**只切配置，不改架构**。

---

## 四、系统架构（后端 / 中台视角）

> 我更关注**系统边界、职责划分和数据流**，而不是 UI。

### 架构核心思想

* **OMS 与执行解耦**
* **AI 决策 ≠ 最终执行**
* **风控是“硬约束”，不是 Prompt**

系统结构可抽象为三层：

1. **ETL 数据层**：统一事实
2. **推理层（AI）**：生成策略意图
3. **中台层**：决定“能不能做”

（这里你可以放那张 Mermaid 图，作为技术补充）

---

## 五、关键模块的产品化设计

### 1️⃣ 数据服务（ETL）：AI 的“基础设施层”

我将数据服务定义为**独立中间层，而非工具脚本**。

它负责三件事：

* **标准化**
  将交易所行情、新闻、链上数据清洗为统一 DataFrame

* **特征工程**
  计算 RSI、MACD、Funding Z-Score、波动率等 20+ 指标

* **时间对齐**
  避免未来函数（如新闻时间戳与 K 线错位）

> 面试话术：
> *“AI 的质量取决于数据质量。我先解决数据一致性问题，再谈模型能力。”*

---

### 2️⃣ 新闻语境处理器：为 LLM 降噪

我没有直接把新闻喂给大模型，而是设计了一个 **News Context Processor**：

它像一个“宏观研究员”，输出的是 **Daily Briefing**，而不是原始噪音。

核心能力包括：

* 宏观事件过滤（CPI / 非农）
* 爆仓数据语义化（Pain Trade）
* 利率预期抽象（降息交易 / 风险偏好）

这样 DeepSeek 只需要回答一个问题：

> “在这个宏观语境下，这个量化信号是否合理？”

---

### 3️⃣ 推理引擎：Quant 与 Qual 解耦

这是我认为**最重要的产品决策**之一。

* **Quant（确定性）**
  Qlib + LightGBM 负责胜率与统计显著性

* **Qual（推理）**
  DeepSeek 负责叙事、宏观与反直觉判断

这样做的原因很简单：

> **LLM 不擅长算数，但擅长逻辑。**

这是典型的 **Neuro-Symbolic Architecture**。

---

## 六、中台风控：AI 的“最后一道门”

我把风控设计成一个**代码级 Gatekeeper**，而不是 Prompt 建议。

采用 **三道防线**：

1. **波动率防线**
   高波动 → 强制降杠杆至 1x

2. **宏观敞口防线**
   熊市 → 总仓位 ≤ NAV 的 50%

3. **集中度防线**
   最多同时持仓 3 个标的

即使 AI “想买”，也会被拦下来。

> 这是我作为中后台产品经理最核心的价值判断：
> **长期存活比短期收益更重要。**

---

## 七、如何把它变成“跟单交易产品”？

### 用户痛点

* 看不懂策略
* 不知道为什么亏
* 风控不可控

### Dolores 的解法

* **实时决策日志（Decision Log）**
* **推理证明（Proof of Reasoning）**
* **状态透明（Portfolio State）**

用户订阅的不是“买卖信号”，
而是一套**可被理解、可被信任的投资逻辑**。

---

## 八、数据驱动的产品迭代方法

我不是“感觉好就加功能”，而是：

* 提假设
* 做对照实验
* 用回测验证

例如：

> 假设：加入新闻情绪是否能降低回撤？

结果：

* 胜率几乎不变
* **最大回撤下降 15%**

于是我才把新闻模块产品化上线。

---

## 九、与基础版 AI 交易产品的本质差异

很多 AI 交易产品（如早期 nofi.ai）的问题在于：

* 纯 LLM
* Prompt 风控
* 无中台约束

而 Dolores 的进化是：

* 计算交给模型
* 推理交给 LLM
* **执行交给系统规则**

这让它从“助手”变成了“合成交易员”。

---

## 十、战略路线图（Web3 视角）

* **Phase 1**：CEX + OKX（当前）
* **Phase 2**：DeFi + 智能合约分润
* **Phase 3**：风控引擎 API / SaaS SDK

这正是我希望向 Web3 产品经理岗位展示的能力：
**不仅能做功能，还能设计平台级产品。**

---



因为整个 Dolores 的核心不是模型，而是：

* 系统边界怎么划
* 风险责任在哪里
* 用户价值如何被保护
* 如何从 MVP 演进到平台


