最近我在做一件很有意思的事：我正在尝试用 AI 从零搭一套白标 Perp DEX。
前天才刚发布过一篇文章，介绍了当前的进展：《我的白标Perp DEX完成了Portfolio Service》。
目前已经完成的几个功能模块，代码 100% 都是 AI 写的，系统设计文档也是 AI 帮我生成的。
那我在做什么呢？我每天主要做的事情其实是：
- review AI 给出的系统设计
- 找出它判断错的地方
- 修正业务逻辑和规则设计
- 调整关键模块的架构
在这个过程中，我越来越确定一件事：AI 最大的问题不是写错代码，而是做错判断。
它会做错业务逻辑判断，也会做错系统架构判断。
而在交易系统里，最危险的往往不是代码报错，而是：判断错了，但系统仍然能跑。
这种问题在测试阶段可能完全看不出来，但一旦遇到极端行情、资金对账或者强平场景，就可能直接变成系统事故。
下面分享几个我最近实现这款 Perp DEX 时遇到的真实例子。
AI 到底会犯什么错？
案例一：账本用了单式记账
第一个例子是关于账本记账的。
AI 最初实现的方案，有余额变更记录，有 ledger_entries 表，对账逻辑也有，正常业务功能是没问题的。
但是，之后我想到了一个场景：我要怎么查看手续费收入多少呢？
发现系统里缺失了手续费收入账户，才发现 AI 的实现是用单式记账的。
即是说，AI 给我的记账方案里，每一笔交易只记录了 用户侧的余额变化。例如用户 A 成交后扣了 USDT、扣了手续费，这些记录都有。
但系统侧呢？没有。
用户被扣了 5 USDT 手续费，但系统里根本没有手续费收入账户。不是“有账户没记”，而是这个账户在设计里压根不存在。
这就是典型的 单式记账：只记录钱从哪里扣掉，却没有记录钱到哪里去。
在功能测试阶段完全看不出问题。用户下单、成交、扣款，一切正常。
但一旦上线，很快就会出现问题：
- 用户扣掉的手续费，在系统里找不到对应收入
- 手续费算错时，没有对手方记录可以交叉验证
- 系统也无法做 借贷平衡校验
正确的做法是 复式记账：
用户账户 -5 USDC
手续费账户 +5 USDC
每一笔资金变动，都必须同时存在借方和贷方，金额必须相等。
交易系统最重要的不是余额，而是资金流。
AI 会犯这个错误，是因为从“功能能跑”的角度，单式记账已经够用。但交易所的账本最终要解决的，是 对账、审计和资金安全。
而这个设计错误，如果不是我想到查手续费收入这个场景，也很难发现。
案例二：订单信息通过撮合引擎透传
第二个例子是 模块边界问题。
清算服务监听到撮合引擎的成交事件后，就要开始执行清算流程，但是，撮合引擎输出的成交事件里只有两个订单 ID，而清算时需要获取详细的订单信息，怎么获取呢？
最直观的方案就是清算服务通过 gRPC 方式同步调用订单服务获取需要的订单信息。但同步调用引入延迟，且高并发下订单服务会成瓶颈，以及服务耦合高。所以该方案其实并不太可行，关于这一点，AI 也能认识到，所以 AI 也不推荐这个方案。
AI 提供了另外一种方案，将订单信息完整传给撮合引擎，撮合引擎再将数据输出到成交事件中，透传给到清算服务。
这个方案在功能上完全跑得通。但这个设计有一个根本性的问题：撮合引擎被迫携带了一堆它不需要、也不应该知道的业务属性。
为什么这是个问题？
- 撮合引擎的核心原则是纯粹：它只做一件事：格优先、时间优先的规则匹配买卖双方。它不需要知道手续费率，不需要知道 reduce_only，不需要知道用户 ID。这些字段的存在不会影响撮合结果，但会让撮合引擎的数据结构变得臃肿、耦合。
- 上游业务变更会波及撮合引擎：今天透传手续费率，明天产品要加一个 VIP 等级字段，后天要加一个跟单标记。每加一个字段，撮合引擎的数据结构都要跟着改。一个本该最稳定的核心组件，被迫随着业务需求不断变动。
- 撮合引擎是全系统吞吐量的天花板：每一个多余的字段都在增加它处理每笔订单的数据量。在高频场景下，这些"无害"的字段会累积成实实在在的性能负担。
正确的做法是什么？订单服务在提交订单给撮合引擎之前，先把完整的订单信息写入一份快照（比如 Redis）。撮合引擎只收到它需要的东西：价格、数量、方向。成交之后，清算服务拿着成交记录中的订单 ID，自己去读快照，补全它需要的业务字段。
这样一来，撮合引擎完全不碰业务属性，清算服务也能拿到完整信息，两边互不干扰。
AI 为什么会这样设计？因为"透传"是最直觉的数据传递方式。A 有数据，B 需要数据，那就让 A 把数据传给 B。AI 思考的是数据怎么流通最短路径，而不是模块之间的职责边界应该怎么划。它不理解"撮合引擎不该碰业务属性"这条约束，因为这条约束不是功能性的。违反它系统照样能跑，只是架构在慢慢腐化。
案例三：AI 只知道 Mark Price，漏掉了 Last Price 触发
交易系统里，Trigger Engine 负责监控价格，在满足条件时触发条件单，比如止损、止盈。
问题在于，条件单的触发价格并不只有一种。用户可以选择用 Mark Price 触发，也可以选择用 Last Price 触发。前者是公允价格，后者是最新成交价。大多数时候两者接近，但在极端行情或流动性不足时，可能出现明显偏差。
AI 给出的触发引擎设计里，只监听了 Mark Price，Last Price 触发类型完全不存在。
这意味着什么？
如果用户设置的是一个 Last Price 触发的止损单，那么这个单永远不会被触发。价格已经暴跌，用户的止损却毫无反应，因为系统根本没有监听这个价格源。一个本应用来保护用户的止损单，就这样变成了废纸。
AI 为什么会漏掉这个设计？
因为在它的知识里，“条件单触发”最常见的默认答案就是 Mark Price。而 Last Price 触发不是一个显眼的架构模块，而是藏在产品规则和交互细节里的需求。你不主动指出，AI 根本不会意识到这里还需要另一条监听链路。
这也是它和前两个案例的区别：前两个案例，是 AI 给了方案，但方案错了；这个案例，是 AI 根本不知道这里还有东西需要设计。
为什么 AI 会在这些地方犯错？
这三个案例看起来完全不同：
- 一个是账本设计
- 一个是模块边界
- 一个是触发链路
但背后的原因其实是同一种问题：AI 在系统设计上，最容易出错的是“判断”。
这些判断大致可以分为三个层次。
第一层：单模块判断
在单个模块内部，AI 很擅长给出一个“能跑”的方案。但很多系统设计的要求，并不是为了让功能跑起来，而是为了保证系统在 对账、审计和异常排查 时仍然成立。这些约束，如果没有经历过真实系统运行，很难意识到它的重要性。
第二层：跨模块判断
当系统涉及多个模块时，问题就不再只是“功能是否正确”，而是 模块之间的职责应该如何划分。很多设计从功能角度看完全合理，但从架构角度看却会破坏系统的边界，使模块之间逐渐产生不必要的耦合。
第三层：系统级判断
在更高层次上，AI 还很难意识到那些 不在主链路上的系统依赖。这些依赖往往不属于任何单一模块，而是分散在产品规则、系统行为和极端场景里。如果没有整体视角，很容易在设计时被忽略。
这三类问题有一个共同点：它们都不是代码问题，而是系统判断问题。
而这种判断，往往只有做过完整系统的人才会特别敏感。很多时候，如果没有相关经验，甚至很难意识到 AI 的设计哪里出了问题。
AI 时代下，什么能力在升值？
AI 的出现，其实正在改变软件工程的能力结构。
过去很多人认为，工程师最核心的能力是 写代码。但当 AI 可以快速生成代码之后，实现层面的门槛正在迅速降低。
比如我在 2019 年写过一套撮合引擎，当时从详细设计到开发完成，大概花了一个月时间。
而这一次用 AI 重做，从完成设计到代码实现，不到两天时间，而且性能还比我当年的版本更高。
实现一个复杂系统的成本，确实被 AI 大幅降低了。
但与此同时，我花时间最多的地方反而不是写代码，而是反复检查一件事：这个系统的设计到底对不对。
AI 可以帮你写一个撮合引擎，但它不会告诉你：
- 账本设计能不能通过审计
- 模块边界是否被污染
- 在极端行情下系统是否还能稳定运行
换句话说：AI 可以帮你实现系统，但很难帮你验证系统。
所以在 AI 时代，一个很有意思的变化正在发生：实现能力的门槛在降低，而 系统级判断能力反而变得更稀缺。
当 AI 可以生成越来越多代码时，真正有价值的能力不再只是“写什么代码”，而是：判断这个系统应该怎么设计。
这也是我做「CEX&DEX 课程」的原因。
CEX&DEX课程到底教什么？
这门课完整的名称应该叫 「CEX & DEX 交易系统架构课」，一共 10 节，从 CEX 讲到 DEX。
但它不教你怎么写代码。因为在 AI 时代，代码实现本身正在越来越快地被抹平。
它真正要讲的是：交易系统每一层的核心判断点是什么。
比如：
- 撮合引擎为什么必须是系统的裁决中心，不能被绕过也不能被分裂？
- 账本为什么必须用复式记账？"余额对了"为什么不等于"账对了"？
- 风控为什么必须同步嵌在交易流程中，而不能做成异步旁路？
- 主链路之外的反向流、旁路链路和共享状态——这些暗线在哪，为什么它们才是系统复杂度的主要来源？
- 从 CEX 到 DEX，信任模型怎么变化？哪些模块的逻辑完全不变，哪些必须重新设计？
这些问题的答案，不在任何一个模块的代码里，也不在任何一篇技术文档里。它们散落在系统设计的决策过程中，只有做过完整系统的人才能告诉你。
这门课做的，就是把这些关键判断点系统地拆开、讲清楚。
课程结构我拆成了 10 节：前 6 节讲 CEX 的核心架构，后 4 节讲 DEX 的模式差异和扩展路径。
| 节次 | 主题 |
|---|---|
| 第 1 节 | 交易所首先是一个资金系统 |
| 第 2 节 | 撮合引擎为什么必须是系统中心 |
| 第 3 节 | 账本（Ledger）为什么一定是系统兜底 |
| 第 4 节 | 风控为什么必须嵌在交易流程中 |
| 第 5 节 | 钱包与链上资产管理 |
| 第 6 节 | 全链路串联：交易系统的暗线与闭环 |
| 第 7 节 | 从 CEX 到 DEX：信任模型与架构重构 |
| 第 8 节 | 从单链到多链：Perp DEX 的充提扩展与信任代价 |
| 第 9 节 | 共识撮合：当撮合引擎嵌入区块链 |
| 第 10 节 | 实战推演：从零设计一个 Perp DEX |
最后一节不是概念总结，而是一个完整的实战推演。
我会给你一个真实约束场景：15 人团队、6 个月、USDC 保证金永续合约。然后带你亲手走一遍，从模式选择到服务依赖图，完成 7 个关键架构决策。
前面提到的那三个 AI 犯错案例，其实分别对应的就是这门课里的核心内容：
- 账本单式记账 → 第 3 节
- 撮合引擎职责污染 / 全链路依赖缺失 → 第 2 节 + 第 6 节
- Last Price 触发链路漏设计 → 第 4 节
课程里不只是告诉你“正确答案是什么”，更重要的是讲清楚：为什么这个答案成立，违反它的代价是什么。
为什么是我来讲？
因为我有过多次从 0 到 1 搭建 CEX 和 DEX 的完整经验。
不是只做某一层，而是从账户模型、撮合引擎、风控清算、钱包充提到链上合约，每一层的架构决策我都亲自做过。
正因为做过，我知道一个正确的系统设计长什么样。所以当 AI 给出一个“能跑但不对”的方案时，我能很快看出问题在哪。
这篇文章里的三个案例就是最好的证明：没做过完整系统的人，很多时候连 AI 的错都看不出来。
而这门课想传递的，就是这种判断力。
课程进展
目前，课程已经讲完了前面 6 节，即已经讲完了 CEX 部分，接下来就要开始讲 DEX 部分的内容了。
另外，关于第 10 节的内容，我又做了一个挑战，加入了一个实战推演，将前面的内容全部串联起来。
课程价格，目前为 2399 元。
等 10 节课全部讲完之后还会再涨一次价。
还是和之前一样，要报名的朋友加我微信（keegan704）直接转账即可，报名后我将邀请加入学员群。
扩展阅读：
