我的「CEX&DEX课程」，从 2026 年 2 月 26 日开始，到昨晚结束，总共 10 节课，终于正式完结。至此，整个课程就全面转为录播课了。既然已经讲完了整个课程，我就想是时候来做一次完整的复盘了。
开头的不顺利
第一节课其实出现了一个意外。
在前面半小时内，讲着讲着，腾讯会议突然提示异常，直接把整个会议关掉了。后来回想，大概率是因为我展示了 Binance 的页面，触发了风控。
后面只能临时切到 Google 会议，才把这节课继续讲完。但 Google 会议每次只能讲 1 个小时，时间不够，中途又重新开了一次。
这一个小插曲，带来了两个影响：一是录制的视频被切成了几个不同的文件，后面整理和拼接都比较麻烦；二是我自己的节奏被打断了，后半段的内容，我始终觉得没有讲到一个理想状态。
所以最后我做了一个决定：干脆把第 1 课全部推翻，重新录一遍。
第二天我就把这件事落地了，重新录制了第 1 课。依然还是用腾讯会议，但这一次我刻意避开了 Binance 页面，防止再次触发风控。
现在回头看，这件事反而让我更确定一件事：做课程，最怕的不是出问题，而是出了问题之后选择将就。
如果只是为了赶进度，第 1 课其实也不是不能用。但我自己过不去，所以最后还是选择重录。至少这样，后面整套课的起点是干净的。
从 9 节到 10 节
这门课最早规划的是 9 节，最终讲了 10 节。
多出来的一节，并不是因为内容膨胀，而是我在备课过程中，意识到了一个之前没有被讲清楚的缺口。
前 5 节讲完之后，CEX 的核心模块——资金、撮合、账本、风控、钱包——其实都已经拆解过一轮了。按照原计划，接下来应该直接进入 DEX 的部分。
但在我同步设计白标 Perp DEX 的过程中，我逐渐意识到一个问题：前 5 节讲的，本质上都是“正向流”——订单如何进入系统、如何被撮合、如何结算。
但在真实系统里，还有一条同样关键的东西，一直没有被显性地串起来——反向流。
比如，订单服务将订单送入撮合引擎之后，撮合引擎的输出里，依然需要回流给到订单服务，订单服务才能更新订单状态。
还有其他暗线，比如，清算服务拿到撮合引擎的输出之后，其实信息还不足以执行清算，因为还缺少订单信息，那如何正确地获取订单信息，就是一条暗线。
还有，止盈止损和条件单，不同于限价单市价单等委托单，这些订单在交易链路里又是如何处理的呢？这也是一条支线。
这些内容，在前 5 节内容中都没有展开讲过，但又是非常重要的关键点。
所以我最终决定，在讲 DEX 之前加一节课：
第 6 节：全链路串联——交易系统的暗线与闭环。
后来我回头看，这一节其实不只是“补了一块内容”，而是补了一种视角：
大多数人在理解系统时，习惯只看“正向流程”——请求如何进入、如何被处理、如何输出结果。
但一个系统是否真正成立，往往不取决于这条正向路径，而取决于：状态能不能闭环。
也就是：
- 每一次状态变化，是否都能被正确传播
- 每一个依赖状态的模块，是否都拿到“最新且一致”的信息
- 整个系统，是否存在“看不见但关键”的数据回流路径
如果这些暗线没有建立起来，系统表面是“能跑的”，但本质上是不稳定的。
很多交易系统的问题，并不是出在“某个模块做错了”，而是——系统从一开始就没有形成闭环。
关于 DEX
关于 DEX 的几节课，其实也做过一次结构调整。如果你翻看我开课前后发布的内容大纲，会发现两版之间是有差异的。
本质原因很简单：在真正讲解和推演过程中，我意识到，DEX 这部分如果只是按“模块”讲，是讲不清楚的。
所以最后我选择换一种方式，把整个部分拆成三种模式来讲。
在课程中，我一共讲了三种典型模式：
- 单链充提 + 链下撮合 + 链上结算（以 dYdX v3 为代表）
- 多链充提 + 链下撮合 + 链上结算（以 ApeX Pro 为代表）
- 共识撮合模式（以 dYdX v4 和 Hyperliquid 为代表）
这三种模式的核心差异，并不只是“架构不同”，而是：它们背后的信任模型完全不同。
而一旦信任模型不同，整个系统在技术上的设计重点，也会随之发生变化。
第一种模式，最关键的是：如何在中心化撮合的前提下，保证用户资金与交易的不可篡改性。 因此它的核心设计是：
- ZK Proof（零知识证明）：用数学证明约束 Operator 行为
- Data Availability：保证数据可被重建
- Escape Hatch：确保用户拥有最终退出权
第二种模式，在用户体验上做了明显优化——支持多链充提。但与此同时，也带来了两个变化：
- 信任模型出现一定程度的退化
- 系统复杂度显著提升（尤其是跨链资产再平衡）
也就是说，它本质上是在做一个取舍：用更好的用户体验，换取更复杂的系统与更弱的信任假设。
第三种模式，则走向了另一条路径：将撮合本身纳入共识。 相比前两者：
- 性能下降
- 但透明性与去中心化程度显著提升
同时也引入了新的核心问题：
- 在多验证者环境下，如何保证撮合结果的一致性？
- Oracle Price 如何在共识中产生，并被所有节点接受？
这些问题，不再是“工程实现问题”，而是共识与系统设计的交叉问题。
课程中，我用三节课分别讲清了这三种模式。
而在最后一节，我换了一种方式，把前面所有内容重新串了一遍：
我给了一个完整的场景：
假设你被任命为一个新 Perp DEX 的技术负责人，从零开始做架构选型。
你会面对哪些关键决策？每一个决策背后的取舍是什么？
在这个场景下，我抽象出了 7 个核心决策点：
- 决策 1：Mode B 还是 Mode C？
- 决策 2：撮合引擎如何设计？
- 决策 3：账户模型如何抽象？
- 决策 4：风控与清算如何嵌入系统？
- 决策 5：Oracle 如何选择？
- 决策 6：是否从第一天就支持多链充提？
- 决策 7：画出你的服务依赖图 —— 暗线在哪里？
这 7 个问题，并不是 7 个孤立的选择。它们共同构成了一棵决策树。每一个决策，都会影响后续路径；而不同路径组合在一起，就形成了完全不同的系统形态。如果你能够把这 7 个问题想清楚，其实就已经掌握了这门课最核心的部分。
回头看，这一部分我真正想讲的，其实不是“三种 DEX 模式”，而是——系统设计，本质上是一系列关于“信任、性能与复杂度”的取舍。
这门课的核心，其实是一张认知地图
写到这里，我其实越来越清楚一件事：这门课表面上在讲 CEX 和 DEX，讲账户模型、撮合、风控、Oracle、多链充提...... 但我真正想讲的，并不是这些模块本身。
我真正想讲的，是一张“交易系统的认知地图”。
这里说的“认知地图”，并不是某一套具体架构，而是——在没有代码的情况下，你是否依然能够把整个交易系统在脑中推演出来。
包括：
- 系统有哪些核心模块
- 每一类状态在哪一层产生
- 数据是如何在系统中流动的
- 哪些是正向流程，哪些是反向闭环
- 哪些地方必须强一致，哪些可以最终一致
如果这些问题你是清楚的，那么你面对任何一个交易系统，都能迅速把它拆开。如果不清楚，那你看到的就只是一些“零散的组件”。
很多人在学习交易系统时，会习惯用“模块”的方式去理解：
- 撮合引擎是一个模块
- 账户系统是一个模块
- 风控是一个模块
- 清算是一个模块
但问题在于：模块，并不能构成系统。
真正让系统成立的，是这些模块之间的关系：
- 状态如何被生产，又如何被消费
- 数据在哪一层被持久化，在哪一层只是中间态
- 不同服务之间，是如何通过事件或状态建立依赖
这些关系，才是系统的骨架。
我自己正在实现的白标 Perp DEX，本质上也是在这张认知地图之上，一层层往下推演：先把系统结构想清楚，再逐步细化模块与流程，最后才是借助 AI 把它实现出来。
回头看，这门课真正想解决的，从来不是：“如何实现一个交易系统”。而是：
👉 当你面对一个交易系统时，你是否知道该从哪里开始拆解它。
👉 当你需要设计一个系统时，你是否清楚每一个决策背后的代价。
如果用一句话总结这门课，我会这样说：
这不是一门教你“怎么做”的课程，而是一门教你“怎么判断”的课程。
如果你具备了这种判断能力，那么实现本身，只是时间问题。
结尾
课程结束了，但我反而更确定了一件事：
在 AI 已经可以帮你完成大部分实现的今天，真正拉开差距的，从来不是代码，而是你如何理解一个系统。
你可以用 AI 写出一个撮合引擎，也可以很快拼出一个看起来“能跑”的交易系统。
但这些都不难。真正难的是：
- 你是否知道系统的边界在哪里
- 哪些地方必须强一致，哪些可以最终一致
- 风险是如何在系统中传播的
- 当系统出现问题时，应该从哪一层开始排查
这些问题，AI 可以给出答案，但不会替你做判断。
回头看，这门课对我来说，其实不仅是一次讲解，更像是一次把自己过去这些年对交易系统的理解，重新整理一遍的过程。
很多之前是“经验”的东西，在这次课程中，才被真正结构化下来。
最后，再补充下课程完结后的最新价格：2688 元。
要报名的朋友，还是和之前一样，加我微信（keegan704），私聊我转账即可。
扩展阅读：
