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

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

AI+Web3实战营日志 #1｜开营

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

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

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

1. 资产管理

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

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

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

3. 手续费的设置和收取

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

4. 再平衡的底层逻辑

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

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

AI 的不足

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

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

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

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

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

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

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

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

合约架构上的迭代

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

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

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

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

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

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

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

回过头来看，这几轮架构迭代的过程，其实是我在不断「驯化」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 原型。