一直对EVM状态机的概念理解的不够深刻，结果突然意识到，这玩意不就是类似git的版本控制吗。一个commit 就是一个block。 于是问了下 GPT 两者的区别，答案如下： Git 的 Commit 是代码仓库的某一时刻的完整目录快照。 EVM 的 Block 是状态转换记录，他执行交易后得到的新状态根（State Root），而不是直接将新的完整的状态写进区块。 进一步理解 Git Commit 记录的是一个目录指针，没有被改变的指向旧文件，更改了的指向新文件，所以只要提供提交版本号，可以当场复原所有数据。即 Git 的 Commit 本身就是版本。 EVM 的 Block 不是状态，而是生成状态的输入即变化。这是理解区块非常重要的点，块代表的是状态变化，而不是状态。上一个状态+当前Block = 当前状态。 他们之间的类比： Commit ≈ Block Commit checkout 工作目录 ≈ Block 的 World State Git Repository ≈ Archive Node 这又引申出节点的两种类型，普通节点和 Archive 节点。 普通节点只保存历史Block+当前状态，如果你想查询历史状态需要从头计算。 Archive 节点会保留所有历史状态，所以体积超大，但是历史数据一查便知。 奇奇怪怪的知识 ～

Spec-Driven Development 如果把任务的颗粒度拆得过细，且没有控制好任务边界和不做什么的声明，在调度多 agents干活时，特别容易出现过度设计问题。 over engineering 更让人头疼，下面是一个很高频的 case。 原始目标只是：给后台系统增加一个文件上传能力。 结果因为没有明确约束： * 一个 subagent 引入 repository pattern * 一个 subagent 开始设计 storage provider abstraction * 一个 subagent 顺手兼容 S3 / OSS / GCS * 另一个开始补异步队列和事件系统 * 最后甚至拆出了 upload-sdk 硬生生干出了一套半成品云存储框架🥹，可真实需求只是：单机部署，上传到本地磁盘。 从局部看，哪哪儿都没毛病，还写的挺好，全都是最佳实践，但离原始目标已经十万八千里了。 最头疼的是，你的同事给你提了这样的代码 PR，你合还是不合？