先说结论

如果我只用一句话概括这份活动图谱，我会这样写：Yaq 在 ETH2030 里扮演的，不是单一的编码执行者，而是一个把研究资料、路线图、上游实现、AI 代理、测试系统和运行验证组织成连续流水线的人。

换句话说，ETH2030 真正展示出来的，不只是编码速度，而是一种新的大型系统研发顺序。

  • 先摄取研究和规格。
  • 再把路线图压成可追踪的工程缺口。
  • 再划清哪些地方复用上游，哪些地方自己实现。
  • 再把多代理并行推进的产出压进验证系统。
  • 最后用 devnet、主网兼容、RPC 校验和站点文档，把可信度一层层补上。

所以“一个人开着 AI 狂写 70 万行代码”更像外部看到的戏剧化表面，真正有价值的是背后的方法论。

先说边界：这是一张工程活动图谱，不是人物自述

下面的判断，主要来自本地可读到的 ETH2030 仓库本身，包括 README.md、docs/PROGRESS.md、docs/GAP_ANALYSIS.md、docs/EIP_SPEC_IMPL.md、pkg/devnet/kurtosis/README.md、CLAUDE.md、.gitmodules、tools/ 脚本，以及本地仓库的目录结构、代码分布和最近 500 条提交节奏。

所以这篇更接近“从公开工程痕迹反推一个人的活动方式”，并不等于 Yaq 本人逐条写过这样的自我说明。

我会尽量把推断和事实区分开来。事实部分来自仓库。推断部分则是基于这些工件做出来的工程判断。

图一：Yaq 在 ETH2030 里的大颗粒度活动闭环

如果先把细节都拿掉，只看大颗粒度，我觉得这条闭环大概长这样：

研究论坛与 EIP 讨论 -> 本地规格库与参考实现库 -> 路线图映射与缺口审计 -> 多代理并行实现 -> 单元测试与差分验证 -> Kurtosis devnet 与真实网络验证 -> README、站点、文档对外输出 -> 新问题重新回流到实现和验证层。

Mermaid 图一：ETH2030 的研发活动闭环

这条线里最重要的，不是某一环特别亮眼，而是它几乎每一环都在仓库里留下了对应工件。

这一层可以直接拆成六个环节来看。

  • 研究摄取：直接证据是 tools/fetch-all.sh、tools/fetch-ethresearch.py、tools/fetch-magicians.py。这说明他不是只看 README 和 EIP 摘要，而是在主动抓论坛、研究讨论和原始话题。
  • 规格沉淀：直接证据是 specs/、docs/ROADMAP.md、docs/ROADMAP-DEEP-DIVE.md。这说明上游材料不是看完就算，而是被沉淀成项目内部的可调用上下文。
  • 上游复用：直接证据是 .gitmodules 里 40 多个子模块，尤其是 refs/go-ethereum、refs/consensus-specs、refs/execution-specs、refs/circl、refs/gnark。这说明它不是闭门从零写，而是重度围绕上游生态做“带边界的复用”。
  • 工程实现：直接证据是 pkg/ 下 48 个包，覆盖执行、共识、DAS、P2P、zkVM、proofs、txpool、rpc 等。这说明他把路线图拆成了可并行推进的工程模块，而不是堆在一个大目录里。
  • 验证闭环：直接证据是 EF state tests、pkg/devnet/kurtosis/、eth2030-geth、50+ RPC methods、snap sync 验证。这说明项目不是停在“能编译”，而是一路压到“能验证、能对比、能联网”。
  • 对外输出：直接证据是 README.md、docs/PROGRESS.md、docs/GAP_ANALYSIS.md、site/。这说明叙事不是后来补的包装，而是工程可信度的一部分。

单看这张表，我对 Yaq 的第一判断就是：他在做的已经不是一个纯开发任务，而是一种“工程操作系统”。

图二：把活动图谱往下拆，可以看到六层活动栈

大颗粒度之下，我会把这套活动方式拆成六层。每一层都有自己的工件、节奏和目标。

Mermaid 图二：Yaq 的六层研发活动栈

如果只看这张图，它其实不是“先写代码，再写文档”的线性流程，而是一套带反馈回流的活动栈。

可以把这六层按“活动 + 工件 + 判断”顺着读下来。

  • 第一层，资料摄取层：主要活动是把论坛、研究、EIP、参考实现和工具链拉到本地；对应工件是 tools/、refs/、specs/。我对这层的判断是，它决定了 AI 代理拿到的上下文质量。没有这层，后面再强也容易瞎跑。
  • 第二层，路线图编译层：主要活动是把 Strawmap 和 EIP 清单压成追踪表、gap 表和 phase 表；对应工件是 docs/ROADMAP.md、docs/GAP_ANALYSIS.md、docs/EIP_SPEC_IMPL.md。我对这层的判断是，它本质上在把模糊愿景翻译成可分配任务。
  • 第三层，边界定义层：主要活动是判断哪些功能委托给 geth，哪些必须 ETH2030 自己写；对应工件是 pkg/geth/、pkg/cmd/eth2030-geth/、README 里的 Native vs Delegated Architecture。我对这层的判断是，它更像总架构师的工作，不像普通 coder 的工作。
  • 第四层，并行实现层：主要活动是让多个包并行推进，并把新增功能挂到统一类型、状态和接口上；对应工件是 pkg/core、pkg/consensus、pkg/das、pkg/engine、pkg/p2p、pkg/zkvm 等。我对这层的判断是，它最接近大家想象中的“AI 写代码”，但它实际上建立在前三层之上。
  • 第五层，验证闭环层：主要活动是用测试、差分、devnet、RPC、网络启动去校准产出；对应工件是 pkg/core/eftest/、pkg/devnet/kurtosis/、docs/PROGRESS.md。我对这层的判断是，它说明项目不是 demo 心态，而是持续逼近可运行工件。
  • 第六层，公开叙事层：主要活动是把项目状态、覆盖范围、已完成和未完成边界对外公开；对应工件是 README.md、site/、docs/PROGRESS.md、docs/GAP_ANALYSIS.md。我对这层的判断是，它像产品经理和技术布道，但它服务的是可信度，不只是传播。

如果把这六层合起来看，Yaq 的角色就会变得非常具体。

  • 他是规格编译者。
  • 他是边界裁剪者。
  • 他是多代理调度者。
  • 他是验证系统设计者。
  • 他也是最终集成人。

很多人会高估第四层，也就是“并行实现层”，但我反而觉得真正稀缺的是前面三层和后面两层。写代码当然重要，但定义什么该写、怎么复用、怎么验证、怎么公开，决定了这 70 多万行代码能不能站住。

图三：仓库重心本身，就是一张活动热力图

从本地代码统计看，ETH2030 的 Go 代码大概可以这样看。

  • 源码文件：1175
  • 源码行数：348522
  • 测试文件：1085
  • 测试行数：438296

最值得注意的，不是源码多，而是测试行数比源码还高。

这对活动图谱的意义很大。它说明 Yaq 的主活动不只是“扩张功能面”，而是同时在做“功能实现 + 测试跟上 + 行为校准”。如果没有这种习惯，70 多万行代码不太可能在这么短时间里维持基本可讨论状态。

再看几个本地统计里最重的代码区块：

  • core/vm，约 76826 行：执行语义和虚拟机层是最重的核心区。
  • core/state，约 41700 行：状态管理不是边缘模块，而是主战场之一。
  • core/types，约 23927 行：类型系统被认真经营，说明接口边界很重要。
  • crypto/pqc，约 22261 行：后量子不是点缀功能，而是独立投入的一条主线。
  • trie/mpt，约 16307 行：状态树和底层存储结构权重很高。
  • crypto/bls，约 12271 行：共识相关密码学是基础能力，而不是外挂。
  • engine/payload，约 6974 行：Engine API 和 payload 生命周期是实际对接重点。
  • txpool/encrypted，约 4325 行：加密 mempool 不是 PPT，而是已经进入实现层。

这些分布给我的感觉非常明确：Yaq 的活动重心不是做一个“以太坊功能展示集”，而是在最难出系统问题的地方持续投入。

如果换成更直白的话说，这个人花精力最多的地方，不是首页、demo 和包装，而是执行、状态、密码学、Engine API、P2P 和验证。

图四：git 节奏显示的，不是单次爆发，而是高频校准

从本地仓最近 500 条提交日期看，活动节奏大概是这样：

  • 2026-03-02：30 次提交
  • 2026-03-03：19 次提交
  • 2026-03-04：15 次提交
  • 2026-03-05：71 次提交
  • 2026-03-06：89 次提交
  • 2026-03-08：101 次提交
  • 2026-03-09：77 次提交
  • 2026-03-10：37 次提交
  • 2026-03-11：36 次提交
  • 2026-03-12：25 次提交

这条线很像一个典型的 AI 强化研发节奏。

  • 前半段先快速铺开。
  • 中段进入高峰，大量并行生成和接线。
  • 后半段明显转入稳定化和校准。

如果再看最近 500 条提交标题里最常见的前缀，会更清楚。

  • fix(engine)，24 次：说明执行载荷、forkchoice、payload 生命周期是高频打磨区。
  • fix(rpc)，17 次：说明最终暴露给外部系统的接口一直在对齐。
  • fix(chain)，13 次：说明链状态、重组、finalization 等系统一致性问题持续在被修。
  • devnet，12 次：说明本地多节点网络验证不是偶尔跑一下，而是主流程的一部分。
  • test，12 次：说明行为回归和修复并行发生。
  • fix(txpool)，10 次：说明交易池与真实交易流量接近时问题很多，也被反复校准。

所以如果只盯着“大量代码生成”，反而会看错重点。真正显眼的是后半段的校准强度。

后半段说明，这套研发不是一次性喷射，而是“快速生成 -> 高压验证 -> 快速修正 -> 再验证”的循环。

这也让我更确信，Yaq 在这里并不只是 prompt 工程师，而更像一个拿 AI 当执行分身的技术总包。

从仓库反推，Yaq 平时最可能在做哪几类事

如果我要把这张活动图谱再压缩成几个最核心的日常动作，我会这样总结。

1. 他在持续做“规格摄取”

tools/fetch-ethresearch.py 和 tools/fetch-magicians.py 这类脚本看起来不起眼，但它们暴露了一个很重要的习惯：Yaq 并不是等别人把结论总结好再看，而是主动把上游论坛和研究讨论抓回来。

这意味着他平时的一个重要活动，不是写函数，而是持续把原始材料变成自己的本地上下文池。

对 AI 时代的大系统来说，这可能比写代码更重要。模型能写实现，但项目有没有可能做对，往往取决于你给模型喂的上下文到底有多完整。

2. 他在持续做“路线图编译”

docs/GAP_ANALYSIS.md 和 docs/EIP_SPEC_IMPL.md 最像的，不是普通项目文档，而是一种任务分配与可信度控制系统。

这说明 Yaq 平时很可能在反复做一件事：把 Strawmap、EIP 和研究设想，翻译成可以逐条对照、逐条验证、逐条补洞的工程对象。

这是一种很强的中间层能力。它既不是研究本身，也不是编码本身，而是把研究压成工程的翻译层。

3. 他在持续做“复用边界判断”

ETH2030 对 go-ethereum 的处理特别说明问题。它没有把“从零重写一切”当成英雄主义，而是通过 pkg/geth/ 适配层，把 geth 变成执行、状态和 trie 的后端底盘。

这说明他平时的活动里，一定有大量“划边界”的工作。

  • 哪些地方直接借上游。
  • 哪些地方在上游外围做适配。
  • 哪些地方必须自己重新定义。

这种判断非常像高级架构工作，而不是单纯的实现工作。

4. 他在持续做“多代理调度”

README 明确写了项目是基于 Claude Code，在大约 8 天内完成，并给出 966 个 session 文件、其中 957 个是 sub-agent 的统计。同时 .claude/settings.json 还显式打开了 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS。

这说明多代理在这里不是传说，而是公开写在工件里的研发事实。

从活动图谱上看，这意味着 Yaq 平时做的很可能不是自己盯着每一行代码，而是持续地：

  • 切任务。
  • 组织上下文。
  • 把不同代理产出挂回统一边界。
  • 再用验证系统筛掉坏结果。

这本质上已经接近“工程编排”了。

5. 他在持续做“验证架构”

ETH2030 最容易被忽视的一层，是它的验证基础设施太重了。

  • EF state tests。
  • 48 个包级测试。
  • 30 个 Kurtosis feature tests。
  • 多客户端 devnet。
  • RPC 方法校验。
  • Sepolia snap sync 和 mainnet 启动验证。

一个人如果只是痴迷生成速度，通常不会同步把验证系统铺这么深。验证系统这么重，反而说明 Yaq 的日常活动里，至少有相当大一部分时间是在想“怎样知道这东西没跑偏”。

6. 他也在持续做“对外可信度管理”

README.md、PROGRESS.md、GAP_ANALYSIS.md 和 site/ 共同说明，Yaq 没有把公开输出当成最后才做的门面，而是把它和实现同步推进。

这意味着他的活动里还有一层很现实的内容：把项目状态表达清楚，让外部读者能判断已经做到哪、还差哪、哪些是真实现、哪些是功能性闭环、哪些仍带实验性质。

我会把这层称为“可信度管理”。它不是附属技能，而是大项目在 AI 时代越来越关键的一部分。

所以，Yaq 的真正活动图谱更像什么

如果把前面的表再压缩一次，我最后会给出这样一个判断：

Yaq 更像一个把自己放在研发流水线中央的人。

他的一只手在抓上游规格、研究讨论和参考实现。 另一只手在抓模块边界、验证系统和真实运行反馈。 AI 代理则被放在中间，负责把已经组织好的上下文快速展开成实现。

也就是说，他不是站在流水线最末端当一个更快的 coder，而是站在流水线中枢，控制材料进入、任务拆解、边界定义、验证回流和最终集成。

这和大家熟悉的“天才工程师”叙事有一点不一样。

传统叙事里，最耀眼的人通常是写出最多代码的人。

但从 ETH2030 这份代码库看，真正稀缺的人，更像是那个能把研究、上游、代理、测试和运行系统组织起来的人。代码量只是结果，本质是组织能力。

我对这篇系列最后一篇的建议写法

如果这是你想写的系列最后一篇，我会建议把它写成“方法论收束”，而不是再写一篇人物传奇。

我会建议你重点抓住三件事。

  • 第一，Yaq 的价值不是神话式爆发，而是把未来路线图压成工程闭环。
  • 第二，AI 在这个案例里不是主角，更像一个被组织起来的大规模执行层。
  • 第三，这个案例最值得普通架构师学习的，不是复制 Yaq 的产出规模，而是复制他的顺序：先摄取规格，再定义边界，再并行实现，再把验证前置。

如果这样收尾，整组文章会更完整。

第一篇回答“这件事是真是假”。 第二篇回答“Yaq 是什么样的人和方法型工程师”。 第三篇则回答“从代码反推，他到底是怎么工作的”。

我觉得这才是这组内容最有长期价值的落点。