# AI+Web3实战营日志 #2 | 完成底层合约

By [Keegan小钢](https://paragraph.com/@keeganlee) · 2025-09-20

---

这是我的 AI + Web3 实战营的第二篇研发日志，第一篇讲了开营的情况：

[**AI+Web3实战营日志 #1｜开营**](https://mp.weixin.qq.com/s/rcBgR9l6pxAmA21PdofHpA)

* * *

自从第一天开营后，我们连续又开了三节直播课，都是在每天晚上 8 点开始，时间我尽量控制在一个半小时，但通常会超出时间预期。

这三天内，我们完善了 MVP 版本的 PRD 文档，确定了简单的合约架构，以及完成了最核心的底层合约代码的编写。

底层合约主要包括了以下核心功能：

**1\. 资产管理**

主要包括初始化和修改资产配置，包括底层资产列表和对应的权重。

**2\. 份额代币的铸造和赎回**

用户可以通过投入一篮子底层资产来铸造对应数量的 ETF 份额代币，也可以通过赎回份额代币来换回等值的底层资产。

**3\. 手续费的设置和收取**

费率结构设置了赎回费和管理费，以份额的方式进行收取。

**4\. 再平衡的底层逻辑**

采用了类似闪电贷的方式执行再平衡策略，由上层合约决定具体的执行策略，底层对结果进行校验。

* * *

当然，这是我们最终的结果，其中，在这过程中发生的一些事情和思考，我想拿出来和大伙分享一下。

### **AI 的不足**

AI 在写文档和写代码时的效率毋庸置疑，可以在极短的时间内生成一大堆内容。但在实际开发中，它的不足也很明显，其中最突出的一点就是：**容易过度设计**。

第一天，我让它生成 PRD 文档。明明已经强调只需要一个 MVP 版本，它却给我写了一份功能非常全面的方案，远远超过了我们当下的需求。直到我再次提醒，它才重新生成了一份足够精简的 PRD。

类似的情况也出现在代码上。我本意只是想让它先初始化一个项目框架，但它不但搭好了框架，还自作主张写了一整套合约逻辑，外加部署脚本和单元测试。结果就是，我花了不少时间看它「提前完成」的工作，却发现根本不符合预期，因为很多设计还没有和我确认过。最后，我只能把整个项目删掉，要求它从头开始，并明确规定：不要过度设计，不要做多余的事情。

我之前就已经意识到：**AI 在开发中并不是一个「能独立完成的工程师」，而是一个「高速的助手」。** 它的优势在于快速产出和验证，而真正的取舍与方向，必须由人来决定。否则，它很可能会「跑题」，甚至「用力过猛」。

前几天，看到 CSDN 发的一篇文章 [**《深夜痛哭30分钟！15年老码农被Vibe Coding逼到崩溃，95%程序员正沦为「AI保姆」？》**](https://mp.weixin.qq.com/s/PlFSlTbypdDIcm0FuLHl5w)，读后深有感触。很多人之所以觉得自己成了「AI 保姆」，其实就是没有学会正确地和 AI 协作。

**我的体会是：** 与其说被 AI 牵着鼻子走，不如把自己放在「指挥」的位置上。AI 可以飞快地产出，但它不会自己区分轻重缓急，也不知道什么才是当前最重要的。要真正用好它，需要：

1.  **设定边界** —— 清晰告诉它要做什么，不要做什么；
    
2.  **快速迭代** —— 把它的输出当成原材料，而不是最终成品；
    
3.  **人工把关** —— 核心的架构决策和细节实现，必须自己来定。
    

这样，AI 才能成为放大效率的「快刀」，而不是一堆需要我们善后处理的「乱麻」。

**合约架构上的迭代**
------------

在合约架构的设计上，我和 AI 一起走过了好几个版本。整体过程让我越来越明确：**AI 能快速给出方案，但真正的方向和取舍，还是要由人来把控**。

一开始，它建议我采用**模块化分层架构**，给出的方案大致如下：

![](https://storage.googleapis.com/papyrus_images/aacda7882cb26275acea5f1d7b0d43ca491b15ca7345ccbe6cbc70f3598cba5f.png)

方向上没错，模块化确实是好架构。但问题在于：它把份额代币单独拆成一个合约，由主合约来控制铸造和销毁。这样一旦份额代币设置了错误的主合约，安全风险会非常大。

于是我提出，可以直接让主合约和份额代币**合二为一**，类似 UniswapV2Pair 的设计。于是有了第二版架构：

![](https://storage.googleapis.com/papyrus_images/728fc89120f221c0e8ed913e906fb605fdffc8ad16d3716342bea29b6be7ac9d.png)

到这一步，问题又出现了：**SwapRouter 和 PriceOracle 明显属于上层逻辑**，但在图里它们和底层主合约之间的依赖关系过于紧密，导致底层合约的耦合度偏高。架构设计里有个基本原则：**上层合约可以依赖下层合约，但下层合约尽量不要依赖上层合约。**

因此我让 AI 再次调整，形成了第三版：

![](https://storage.googleapis.com/papyrus_images/286bf00bdc49bdb40faee48d39041d39f9f93bd9d1a1a9983b7c138607bc9399.png)

不过，这张图还有一个隐含的问题没体现出来：底层合约在铸造时，如果支持「单一资产」输入，就必须在合约内部处理兑换逻辑，决定如何拆分成多个底层资产。这会让底层变得臃肿，不利于扩展。于是我最终提出，底层主合约**只接受完整的一篮子资产**，铸造时需要投入对应比例的多种资产，赎回时也直接返回多种资产。这样，单一资产兑换的逻辑可以放到上层合约里去做，底层保持最简洁和稳定。于是有了下面这个图：

![](https://storage.googleapis.com/papyrus_images/bf8069a218d90588f9f741ed73842913320e2e309e7ccfd4b23d375837a1ec4e.png)

回过头来看，这几轮架构迭代的过程，其实是我在不断「驯化」AI：让它从一开始的“想当然”式输出，逐步被引导到一个更符合我目标的方案。这也再次印证了前面说的观点——AI 是高速的助手，但真正的「指挥权」必须掌握在自己手里。

**Rebalance 的设计**
-----------------

在 ETF 产品里，**Rebalance 是最复杂、最核心的逻辑之一**。它的目标是保持资产池里各个底层资产的比例与目标权重一致。比如，当某个代币价格大幅上涨或下跌时，资产配置可能会失衡，这时候就需要通过 Rebalance 来调整。

一开始的时候，AI 给出的方案就是一个空实现。但作为不可升级的底层合约，就算 MVP 版本不做 rebalance 的执行，但后续依然需要可以迭代支持，但一个空实现肯定是无法扩展的。

之后，AI 也陆续给出了几种不同的实现方案，但都无法令我满意。比如，有一种方案是把 Rebalance 逻辑直接写进底层合约里，由合约自己去调用 SwapRouter 进行一系列兑换。这么做表面上很直接，但问题是：

*   底层合约逻辑过重，缺乏灵活性；
    
*   不同的 Rebalance 策略（定期、阈值触发、AI 算法驱动等）难以升级；
    
*   安全性和可审计性也会受到影响。
    

于是我提出一个改进思路：**让底层合约只负责校验结果，而不负责执行过程**。

具体来说：

1.  上层合约（Rebalance Manager）可以通过闪电贷的方式获取池子里的资产；
    
2.  在外部完成一系列 Swap 操作，把资产比例调整到目标范围；
    
3.  最后再把调整好的资产归还到底层合约；
    
4.  底层合约只检查最终资产比例是否符合要求，如果不符合则回滚交易。
    

这种设计有几个好处：

*   **灵活**：不同的 Rebalance 策略可以在上层灵活实现，而不用修改底层合约；
    
*   **安全**：底层只做结果校验，避免复杂逻辑带来的漏洞风险；
    
*   **可扩展**：未来无论是换新的 DEX、引入更复杂的策略，还是结合 AI 做动态调仓，都只需在上层迭代即可。
    

最终形成的方案，就是**底层负责「守门」与「验收」，上层负责「搬砖」与「执行」**。这符合架构上的一个基本原则：**底层保持最小化，越轻越稳；上层保持可扩展，越灵越活。**

**下一步**
-------

完成底层合约，是整个链上 ETF 项目的第一个重要里程碑。它像一个稳定的「资金金库」，保证了资产安全和份额代币的锚定关系。

接下来，研发的重点将转向两个方向：

1.  **Router 合约** —— 负责用户交互层的简化逻辑，让用户可以用单一资产直接申购，不需要自己手动配齐一篮子资产。
    
2.  **RebalanceManager 合约** —— 负责调度和执行再平衡逻辑，在保持底层安全简洁的前提下，灵活支持不同的 Rebalance 策略。
    

这两部分完成后，整个 MVP 的雏形就会真正跑起来。从「能发行份额」到「能灵活进出」再到「能自动调仓」，我们会逐步搭建起一个完整的链上 ETF 原型。

---

*Originally published on [Keegan小钢](https://paragraph.com/@keeganlee/ai-web3-2-2)*