当 AI 学会 “区块链”:MIT 工程师如何打造 Web3 世界的 Cursor
“Cursor 和 Claude 能玩转 Web2 的 React,但到了 Web3,它们就像盲人摸象。”
Luke 说出这句话时,台下的黑客松选手会心一笑 —— 这种 “卡壳” 的痛,他们再熟悉不过。
写智能合约从不是 “拼几个函数” 那么简单。一个状态变量的微小偏差,可能直接撕开千万美元的安全漏洞;一行未考虑 gas 成本的代码,能让整个应用在链上寸步难行。
更讽刺的是,AI 早已让 Web2 程序员 “一夜变全栈”,Web3 开发者却还在 Remix、Hardhat、Foundry 之间反复切换,对着测试报告一遍遍排查 —— 生怕踩进链上那些 “看不见的坑”。
于是 Luke 决定自己动手:做一个真正 “懂区块链语义” 的 AI。能写合约、能测安全、能搞定上链全流程。
这,就是Nora的起点。@mynoraai
#MyNoraAI #BuiltWithNora #NoraAgent #CodeWithNora #NoraAI

一、从 MIT 到链上:AI 研究者掉进 Web3 的 “上下文陷阱”
在扎进 Web3 之前,Luke 是 MIT Media Lab 的 AI 研究员;后来,他成了少数深度参与区块链底层开发的技术专家,亲手设计过HotStuff 共识机制与BlockSTM 并行执行方案。
这段经历让他看清了一个关键问题:Web3 的瓶颈从不是代码本身,而是代码背后的 “链上上下文”。
智能合约的世界,从来不是单纯的逻辑运算,而是一套复杂的 “状态机生态”:每一笔交易都受前后区块影响,每一行代码都要在 “链上共识” 的规则里执行,甚至编译器的微小优化,都可能改变最终的执行结果。
他见过太多年轻开发者被这些 “隐形复杂度” 绊倒 —— 明明语法没毛病,合约却在链上跑崩;明明功能实现了,却因 gas 过高无人使用。
也是这时,一个念头在他心里成型:
“或许,AI 不该只懂代码语法,更该懂区块链的‘语言逻辑’。”

二、AI 工具的盲区:为什么 Web2 的 Cursor 搞不定链上开发?
要理解 Nora 的价值,得先看懂传统 AI 编码工具的 “Web3 盲区”。
如今的 LLM 编码助手 —— 不管是 Cursor、Claude Code 还是 Copilot—— 生成 React 组件、写 API 接口都游刃有余,甚至能搭出整站逻辑。但让它们写一份 Solidity 智能合约?几乎必出问题。
问题出在哪?
这些模型的 “语义理解”,完全建立在 Web2 的范式里:前端渲染、后端接口、HTTP 调用、函数的输入输出…… 它们看不见链上特有的状态流变化、虚拟机执行逻辑、gas 成本计算,更摸不清安全边界(比如重入攻击、权限控制)。
“它们懂 JavaScript 的世界,却听不懂区块链的‘方言’。”Luke 的总结,戳中了无数 Web3 开发者的痛点。
而这,正是 Nora 的切入点。

三、顿悟时刻:让 AI 读懂 “字节码的温度”
2024 年底,Luke 调试一个 Move 合约时遇到了个棘手问题:AI 生成的代码语法完全正确,但一上链就报错 —— 原因是编译器优化后,执行逻辑和原代码预期完全不一样。
就是这一刻,他突然想通了:要让 AI 写出安全的合约,必须先让它理解编译器与虚拟机的 “底层语言”。
这成了 Nora 最核心的设计原点。
和传统 AI Agent 不同,Nora 的模型架构里,直接嵌入了 **“编译器感知(Compiler-Aware)” 与 “虚拟机级上下文(VM-Level Context)”**。它不只是懂 Solidity、Move、Cairo、Rust 的语法差异,更能追踪编译后字节码的执行路径,分析每一条指令的流转逻辑。
这意味着:Nora 不只是 “写代码”,它还能自动验证合约逻辑、检测安全漏洞、甚至优化 gas 消耗—— 更像一个同时懂编译原理、共识机制和安全审计的 “全能工程师”。

5,654
6
本页面内容由第三方提供。除非另有说明,欧易不是所引用文章的作者,也不对此类材料主张任何版权。该内容仅供参考,并不代表欧易观点,不作为任何形式的认可,也不应被视为投资建议或购买或出售数字资产的招揽。在使用生成式人工智能提供摘要或其他信息的情况下,此类人工智能生成的内容可能不准确或不一致。请阅读链接文章,了解更多详情和信息。欧易不对第三方网站上的内容负责。包含稳定币、NFTs 等在内的数字资产涉及较高程度的风险,其价值可能会产生较大波动。请根据自身财务状况,仔细考虑交易或持有数字资产是否适合您。