dingdingtao 版 AI 交易策略 · 四层架构方案 · LLM 只在设计期介入，执行期必须确定性

系列第三篇。前两篇拆了 VergeX。这一篇开始我讲我们自己的方案。

核心一句话：

LLM 不做实时决策，只做策略生成。执行层必须是确定性的、可审计的、可回滚的。

如果 VergeX 是"把 80% 决策权交给 LLM"的架构，我们是"把 LLM 限制在设计期、把执行期还给代码"的架构。

我给它起名叫 四层架构——因为每一层都在做一件事，而且每一层都有明确的进入条件。不符合上一层约束的东西不能进入下一层。

---

一图看全貌

┌────────────────────────────────────────────────┐
│  Layer 1 · Philosophy (哲学层)                 │
│  YAML：你是谁？信什么？不做什么？              │
│  产出：philosophy.yaml                         │
└────────────────────────────────────────────────┘
                    ↓ 喂给 Opus 4.7
┌────────────────────────────────────────────────┐
│  Layer 2 · StrategySpec (规范层)               │
│  JSON Schema：入场/出场/资金/杠杆/止损/时段    │
│  产出：strategy.json (必通过 validator)        │
└────────────────────────────────────────────────┘
                    ↓ 强制 72h Paper Trading
┌────────────────────────────────────────────────┐
│  Layer 3 · Executor (执行层)                   │
│  确定性 TypeScript 脚本                        │
│  → Binance / OKX MCP 下单                      │
└────────────────────────────────────────────────┘
                    ↓ 实时监控
┌────────────────────────────────────────────────┐
│  Layer 4 · Guardrail (守门层)                  │
│  Drawdown 硬停机 + Webhook 告警 + 人工审批     │
└────────────────────────────────────────────────┘

每一层我详细讲。

---

Layer 1 · Philosophy（哲学层）

为什么要有哲学层

VergeX 的策略直接是"提示词 + 参数"。我觉得不够。

问题：提示词写"遇到信号就做多"——这个"信号"是作者脑子里的哪种信号？RSI？成交量？情绪？LLM 猜。

解法：在写任何策略之前，先让交易者把自己是谁说清楚。

Philosophy YAML 的字段

trader_id: dingdingtao
version: 2026-04-19

style:
  primary: trend_following      # 趋势 / 反转 / 对冲 / 事件 / 做市
  timeframe: [4h, 1d]           # 偏爱的周期
  beliefs:
    - "BTC 是主趋势，山寨是杠杆"
    - "趋势反转比趋势延续更危险"

risk:
  max_single_trade_loss_pct: 2        # 单笔最大亏损占本金 %
  max_daily_loss_pct: 5               # 日最大亏损 %
  max_drawdown_hard_stop_pct: 20      # 组合回撤硬停机线
  max_leverage: 5                     # 全系统任何策略不得超过

avoid:
  symbols: ["meme coins", "< $50M market cap"]
  scenarios: ["FOMC day ±4h", "主流交易所维护期"]
  behaviors: ["追高 > 10% 阳线后进场", "补仓 losing position"]

关键原则

• avoid 列表是硬约束——下一层生成的 StrategySpec 必须尊重
• max_leverage 是系统级上限，任何策略不得超过
• beliefs 是自由文本，用于喂给 Opus 4.7 作为风格参考
• 写哲学的过程比写策略更慢——这是特性，不是 Bug

哲学不是可选的。如果用户没填哲学 YAML，系统拒绝生成任何策略。

---

Layer 2 · StrategySpec（规范层）

为什么要有规范层

VergeX 的"策略"是一段自然语言 prompt。LLM 每次读这段 prompt 都可能得出不同结论——这是可复现性灾难。

解法：让 LLM 只在生成期工作，产出一个符合严格 schema 的 JSON。JSON 生成之后就冻结，后面的执行只认 JSON，不认 prompt。

StrategySpec 的字段

interface StrategySpec {
  id: string;
  name: string;
  philosophy_ref: string;              // 关联哲学 YAML

  market: {
    symbols: string[];                 // 必须通过 philosophy.avoid 过滤
    timeframe: "5m" | "15m" | "1h" | "4h" | "1d";
  };

  entry: {
    type: "indicator" | "price_action" | "event";
    conditions: EntryCondition[];      // 结构化条件，不是自然语言
  };

  exit: {
    take_profit: PriceRule[];          // 可分批
    stop_loss: PriceRule;              // 必填，不能 null
    time_exit?: { max_holding_hours: number };
  };

  sizing: {
    method: "fixed_notional" | "kelly_fraction" | "volatility_target";
    params: SizingParams;
    max_notional_per_trade_usd: number;
  };

  risk_guards: {
    max_leverage: number;              // 必 ≤ philosophy.max_leverage
    max_single_trade_loss_pct: number; // 必 ≤ philosophy 对应字段
    max_concurrent_positions: number;
  };

  execution: {
    exchange: "binance" | "okx";
    order_type: "limit" | "market";
  };

  meta: {
    created_at: string;
    created_by: "human" | "opus-4.7";
    prompt?: string;                   // 原始用户 prompt，留档
  };
}

Validator：Opus 输出必须过检

function validateSpec(spec: StrategySpec, philosophy: Philosophy): string[] {
  const errors: string[] = [];

  if (spec.risk_guards.max_leverage > philosophy.risk.max_leverage) {
    errors.push(`杠杆 ${spec.risk_guards.max_leverage}x 超过哲学上限 ${philosophy.risk.max_leverage}x`);
  }

  for (const sym of spec.market.symbols) {
    if (philosophy.avoid.symbols.some((p) => sym.match(p))) {
      errors.push(`${sym} 在 philosophy.avoid.symbols 里`);
    }
  }

  if (!spec.exit.stop_loss) {
    errors.push("必须有 stop_loss，不能没有");
  }

  // ... 更多约束

  return errors;
}

Validator 不过就拒绝 Opus 的输出，带着错误列表让它重写。这是硬门。

Opus 4.7 的生成流程

1. 用户自然语言需求 + philosophy.yaml 一起喂给 Opus
2. 系统 prompt 里把 StrategySpec TypeScript 类型 + 禁止行为清单 给 LLM
3. Opus 返回 JSON（用 response_format: json_schema 强制结构）
4. Validator 跑一遍，不过就 reject + 返回错误
5. 人工审批通过后才进入 Layer 3

关键设计：LLM 永远只负责"把哲学 + 需求翻译成 spec"这一件事。它不参与后面任何实时决策。

---

Layer 3 · Executor（执行层）

为什么执行层要是确定性代码

VergeX 的执行层是 LLM 每 15 分钟跑一次推理。这带来三个问题：

1. 不可复现——同策略不同 Agent 表现悬殊，就是这个原因
2. 贵——每次 API 调用要花钱，高频策略打不起
3. 不可审计——出事后问"为什么 14:15 下了这单"，LLM 回答不了

dingdingtao 版的 Executor

// lib/strategy/executor.ts（骨架）

export async function runStrategy(
  spec: StrategySpec,
  tick: MarketTick,
  state: StrategyState,
): Promise<Action[]> {
  // 1. 入场检查（纯指标计算，无 LLM）
  if (state.position === null && evaluateEntry(spec.entry, tick, state.indicators)) {
    const size = computeSize(spec.sizing, state.equity, tick);
    if (size > spec.sizing.max_notional_per_trade_usd) {
      return [{ type: "reject", reason: "size exceeds max_notional" }];
    }
    return [{ type: "open", side: "long", size, sl: ..., tp: ... }];
  }

  // 2. 出场检查
  if (state.position) {
    if (tick.price <= state.position.stop_loss) {
      return [{ type: "close", reason: "sl" }];
    }
    if (tick.price >= state.position.take_profit[0]) {
      return [{ type: "close_partial", size: 0.3 }];
    }
    if (state.position.holding_hours > spec.exit.time_exit?.max_holding_hours) {
      return [{ type: "close", reason: "time_exit" }];
    }
  }

  return [];
}

整个函数没有任何 LLM 调用。

纯 if-else、纯指标运算、纯参数对比。同一个 spec 跑 1000 次必然给同一个结果。

下单：Binance / OKX MCP

下单走我们未来接的 Binance MCP 或 OKX MCP（两个交易所都有官方的 skill 扩展）：

// 伪代码
await binanceMcp.placeOrder({
  symbol: action.symbol,
  side: action.side,
  quantity: action.size,
  price: action.price,
  timeInForce: "GTC",
  // 本策略的 meta 作为订单 clientOrderId 标记，便于日志回溯
  clientOrderId: `${spec.id}-${Date.now()}`,
});

每一单都打上 spec id，出事后能回溯"哪个策略哪个版本下的这单"。

---

Layer 4 · Guardrail（守门层）

三重保护

① Paper Trading 72h 强制期

新策略（Opus 生成的 + 人工写的都一样）必须先跑 72 小时模拟盘：

• 用真实行情 + 真实滑点估计
• 不下真单，只记录 shadow fills
• 72h 后导出 KPI：净利 / 最大回撤 / 夏普 / 胜率 / 盈亏比
• 必须同时满足才能进实盘：
  • 最大回撤 < 哲学设定
  • 夏普 ≥ 1.0（不求高，求有）
  • 交易次数 ≥ 20（样本必须够）

② 实时 Drawdown 硬停机

setInterval(async () => {
  const equity = await getCurrentEquity();
  const drawdown = (peak - equity) / peak;

  if (drawdown >= philosophy.risk.max_drawdown_hard_stop_pct / 100) {
    await stopAllStrategies();
    await sendAlert("🚨 drawdown 触发硬停机");
  }
}, 60_000);

组合回撤到哲学设定（比如 −20%）就停所有策略。

这是 VergeX 目前没有的。

③ 人工审批 + Webhook 通知

• Opus 生成的任何 spec → Slack / 企业微信卡片 → 审批人点通过
• Paper Trading → 实盘之间再审一次
• 大额单（> $X）事前通知
• 异常事件事后邮件

---

和 VergeX 的对比

不是说 VergeX 错——定位就不同。VergeX 是普惠工具，我们是纪律执行器。

---

落地路线（不在本轮实施）

每一个 v 都会有对应的 /posts 文章说明设计 + 验证。

---

下一篇

这一篇讲了"架构"。下一篇 #219 讲"为什么架构第一层是哲学"——

没有哲学的 AI 策略等于上杠杆开盲盒。三类交易者（趋势 / 反转 / 对冲）的哲学怎么决定他们会生成完全不同形态的策略。

然后 #220 收尾——资金管理 + 杠杆纪律 为什么才是 AI 交易的真正护城河。

---

声明：本方案已归档在项目内部 docs/ai-trading-strategy-blueprint.md，本文是对外简化版。方案尚未落地成代码，当前仓库只实现了交易所的只读聚合（lib/exchanges/binance.ts / lib/exchanges/okx.ts），没有下单能力。本文不构成投资建议。