类似的硬件卸载架构在企业基础设施中也被证明能够显著提升效率。例如，在微软 Azure Stack HCI 的实验环境中，DPU 架构能够带来最高 12 倍的 CPU 资源效率提升以及约 60%的吞吐量提升。这些结果表明，将网络和安全功能从 CPU 迁移到专用处理单元，能够显著减少主机负载并提升整体性能。
对于运行高性能计算任务或关键生产系统的环境而言，这种性能提升具有重要意义。Akamai 企业安全高级副总裁 Ofer Wolf 表示，在水厂、制造系统或高性能计算集群中，首要任务始终是保证系统以满负荷运行。如果安全软件占用过多资源，可能导致系统崩溃或关键计算任务变慢。通过将分段和可视化能力卸载至 DPU，可以在阻断攻击的同时最大程度释放 CPU 算力。
Next.js 一直在开发一等适配器 API，我们也在与其合作，目前仍处于早期阶段。但即便有了适配器，构建过程依然要依赖高度定制化的 Turbopack 工具链。此外，适配器只覆盖构建与部署环节。在开发阶段，next dev 完全在 Node.js 中运行，无法接入其他运行时。如果你的应用使用了平台特定 API（如 Durable Objects、KV 或 AI 绑定），除非采用变通方案，否则无法在开发环境中对这些代码进行测试。
vinext 介绍
如果不采用适配 Next.js 输出的方式，而是直接基于 Vite 重新实现 Next.js 的 API 会怎样？Vite 是除 Next.js 外大多数前端生态所使用的构建工具，支撑着 Astro、SvelteKit、Nuxt、Remix 等框架。这是一次干净的重新实现，而非简单的封装或适配。老实说，我们原本并不认为这能成功。但如今已是 2026 年，软件构建的成本已经完全改变了。
我们取得的进展远超预期。
npm install vinext
只需将脚本中的 next 替换为 vinext ，其余保持不变即可。你现有的 app/、pages/ 和 next.config.js无需修改就能正常工作。
这并非基于 Next.js 和 Turbopack 输出的封装层，而是对 API 的完整替代实现：路由、服务端渲染、React Server Components、服务端操作、缓存、中间件——全部基于 Vite 构建并以 Vite 插件的形式实现。最重要的是，得益于 Vite Environment API，Vite 的构建输出可在任意平台上运行。
Next.js 的定义十分清晰。它拥有详尽的文档、庞大的用户群体以及多年来积累在 Stack Overflow 上的问答和教程。其 API 已经广泛存在于训练数据中。当你让 Claude 实现 getServerSideProps 或解释 useRouter 的工作原理时，它不会出现幻觉。它完全了解 Next 的运行机制。
Vite 是非常优秀的基础框架。它解决了前端工具链的核心难点：快速热更新、原生 ESM、清晰的插件 API 以及生产构建。我们无需从零开发打包器，只需要让它适配 Next.js 的使用方式即可。@vitejs/plugin-rsc 目前仍处于早期阶段，但它已经为我们提供了 React Server Components 支持，不必从头实现 RSC。
我们还为代码审查设置了 AI 智能体。PR 提交后，智能体会自动执行审查；审查意见返回后，另一个智能体会处理这些意见。整个反馈流程基本实现了自动化。
它并非每次都能完美运行。有些 PR 本身就是错误的。AI 常会“自信”地实现一些看似正确、却与 Next.js 实际行为不符的逻辑。我必须定期纠正方向。架构决策、优先级排序、判断 AI 何时走入死胡同——这些都由我负责。当你给 AI 清晰的方向、充足的上下文和完善的约束时，它的效率会非常高。但最终，依然需要人类来掌舵。
AI 没有这样的限制。它可以在上下文里容纳整个系统，并直接编写代码。它不需要借助中间框架来维持结构，只需要一份规范和一个构建基础。
目前尚不清楚哪些抽象是真正基础的，哪些只是人类认知的拐杖。这条界限在未来几年将会大幅改变。而 vinext 就是一个例证：我们只提供了一份 API 契约、一个构建工具和一个 AI 模型，剩下的中间层全部由 AI 编写，无需额外的中间框架。我们相信这种模式会在大量软件中复现，多年来搭建的层层封装并不会全部保留下来。
试试看
vinext 包含一个用于处理迁移的 Agent Skill。它适用于 Claude Code、OpenCode、Cursor、Codex 等数十种 AI 编码工具。安装它，打开你的 Next.js 项目，告诉 AI 进行迁移：
休息期间，员工们试用了 Anthropic 公司最新款的 Opus 4.5，却意外地发现了一个令人不安的事实：它的编码能力已经发展到开发者无需再逐行检查代码的地步。开发者不再需要与 Cursor 代码编辑器中的 AI 助手协作，而是可以向自主运行的智能体发出高级指令，并接收已完成的功能——有时甚至能收到最终产品。而这恰恰是个问题。
“我提到的大多数公司……他们的观点是 Cursor 如今已经过时了，”Insight Partners 联合创始人兼前董事总经理 Jerry Murdock 上周在 20VC 播客节目中表示。
今年 2 月，抵押贷款服务初创公司 Valon 的 90 多名员工取消了 Cursor 的订阅。理由很简单：他们不再需要这款编辑器了。取而代之的是，他们转而使用 Claude Code 强大的代理程序，实现了端到端工作流程的完全自动化——包括系统间数据迁移、修复漏洞等等。Valon CEO Andrew Wang 表示，这些任务的完成速度提升了“10 倍”。
在开发者社区中，围绕 Cursor 是否即将消亡的讨论也在迅速升温。一些开发者认为，这家曾经风头正劲的 AI 编程工具公司，如今正面临来自模型厂商的直接冲击。
有网友直言，Cursor 的“护城河”其实非常脆弱。一位用户调侃称，Cursor “曾经风光无限，但也就两分钟”，随着更强大的模型能力不断释放，其优势很快被削弱。在他看来，在 AI 编程工具领域，真正拥有长期护城河的往往是掌握底层模型能力的大公司，而不是基于模型构建工具的初创企业。
也有开发者从产品体验角度给出了更为细致的评价。一位长期用户表示，自己目前主要使用 Claude Code 和 OpenCode，但仍认为 Cursor 的用户界面在同类产品中依然是最好的。不过，他认为 Cursor 在商业策略上的失误加速了用户流失。公司后来对订阅功能进行了较为严格的限制，导致不少用户开始寻找替代工具。
在技术层面，这位开发者依然肯定 Cursor 的一些核心能力。他指出，Cursor IDE 在代码索引和嵌入式检索方面表现出色，能够比传统的grep等工具更准确地定位代码上下文。此外，如果 Cursor 能进一步整合浏览器自动化能力，例如在 IDE 内置 Playwright 或 Chrome 的 MCP 接口，其开发工作流管理能力原本有机会变得更强。不过，他也强调，当前吸引开发者转向其他工具的关键因素，并不只是终端工具本身，而是模型性能的跃升——尤其是 Claude Opus 的表现。正是这一点，让越来越多开发者开始直接使用 Anthropic 的工具生态。
# 文件：lazyllm/__init__.py
def __getattr__(name: str):
if name == 'tools': # 调用中间模块的加载逻辑
return importlib.import_module('lazyllm.tools')
elif name in __all__:
tools = importlib.import_module('lazyllm.tools')
builtins.globals()[name] = value = getattr(tools, name) # 导入后会缓存导入结果以避免后续重复导入
return value
raise AttributeError(f"module 'lazyllm' has no attribute '{name}'") # 保证加载在顶层init中声明/暴露出来的子模块
效果：
👉顶层 API 暴露完整，但实际导入延后到首次访问 👉导入后写入 globals()，后续访问几乎无额外开销
# lazyllm/tools/__init__.py
def __getattr__(name: str):
if name == 'fc_register':
agent = import_module('.agent', package=__package__)
globals()['fc_register'] = value = agent.register
elif name in _SUBMOD_MAP:
return import_module(f'.{name}', package=__package__)
elif name in _SUBMOD_MAP_REVERSE:
module = import_module(f'.{_SUBMOD_MAP_REVERSE[name]}', package=__package__)
globals()[name] = value = getattr(module, name)
return value
当用户编写 from lazyllm.tools import Document 时，才会实际导入 lazyllm.tools.rag。
3️⃣依赖集中检查：子模块导入时统一检测
解决的问题：
👉实际使用依赖时才暴露缺少依赖。
👉多个同时需要的依赖出现异常时，提示分散在不同的场景、log、时间等维度。
lazy的方法：
在子模块被导入时触发整个依赖组的检查。
关键代码：
# lazyllm/tools/rag/__init__.py
from lazyllm.thirdparty import check_dependency_by_group
check_dependency_by_group('rag') # 模块init中指定该子模块隶属于哪个依赖组
# lazyllm/thirdparty/__init__.py
def check_dependency_by_group(group_name: str):
missing_pack = []
for name in load_toml_dep_group(group_name): # 依赖分组信息直接从整个工程的配置toml文件中获取
real_name = package_name_map_reverse.get(name, name)
if not (config['init_doc'] and real_name in module_names or check_package_installed(real_name)):
missing_pack.append(name)
if len(missing_pack) > 0:
msg = f'Missing package(s): {missing_pack}\nYou can install them by:\n lazyllm install {group_name}'
LOG.error(msg) # 提示安装依赖组的命令
raise ImportError(msg)
# 文件：lazyllm/__init__.py
def __getattr__(name: str):
if name == 'tools': # 调用中间模块的加载逻辑
return importlib.import_module('lazyllm.tools')
elif name in __all__:
tools = importlib.import_module('lazyllm.tools')
builtins.globals()[name] = value = getattr(tools, name) # 导入后会缓存导入结果以避免后续重复导入
return value
raise AttributeError(f"module 'lazyllm' has no attribute '{name}'") # 保证加载在顶层init中声明/暴露出来的子模块
效果：
👉顶层 API 暴露完整，但实际导入延后到首次访问 👉导入后写入 globals()，后续访问几乎无额外开销
# lazyllm/tools/__init__.py
def __getattr__(name: str):
if name == 'fc_register':
agent = import_module('.agent', package=__package__)
globals()['fc_register'] = value = agent.register
elif name in _SUBMOD_MAP:
return import_module(f'.{name}', package=__package__)
elif name in _SUBMOD_MAP_REVERSE:
module = import_module(f'.{_SUBMOD_MAP_REVERSE[name]}', package=__package__)
globals()[name] = value = getattr(module, name)
return value
当用户编写 from lazyllm.tools import Document 时，才会实际导入 lazyllm.tools.rag。
3️⃣依赖集中检查：子模块导入时统一检测
解决的问题：
👉实际使用依赖时才暴露缺少依赖。
👉多个同时需要的依赖出现异常时，提示分散在不同的场景、log、时间等维度。
lazy的方法：
在子模块被导入时触发整个依赖组的检查。
关键代码：
# lazyllm/tools/rag/__init__.py
from lazyllm.thirdparty import check_dependency_by_group
check_dependency_by_group('rag') # 模块init中指定该子模块隶属于哪个依赖组
# lazyllm/thirdparty/__init__.py
def check_dependency_by_group(group_name: str):
missing_pack = []
for name in load_toml_dep_group(group_name): # 依赖分组信息直接从整个工程的配置toml文件中获取
real_name = package_name_map_reverse.get(name, name)
if not (config['init_doc'] and real_name in module_names or check_package_installed(real_name)):
missing_pack.append(name)
if len(missing_pack) > 0:
msg = f'Missing package(s): {missing_pack}\nYou can install them by:\n lazyllm install {group_name}'
LOG.error(msg) # 提示安装依赖组的命令
raise ImportError(msg)
Konata9(+2) 我因为做周刊，每周都需要阅读很多文章。我一开始也尝试让 AI 总结后再阅读，但体验后感觉有一些我感兴趣的部分 AI 没总结到，也没有自己阅读的感受。所以我现在会自己先看一遍，然后在做周刊的时候让 AI 事后总结，看看自己和 AI 的观察点有哪些不同。
当然这分文章，如果只是工具类的介绍文章，我就直接让 AI 读了。但如果是需要深入理解的，我还是倾向于自己慢慢看。
Lonestahhh(+2) 首先个人最习惯读书的时候打开一个 chatbot 让它随时准备好迎接我丢过来的问题，在这一点上 AI 确实能够帮助我强化理解，解答我的很多疑问（尤其是在我去读陌生领域的经典作品时）。另外就是在同个别 chatbot 问答的过程中它会帮助你拓展知识边界，不拘泥于你抛出的问题，引导你去往更多的地方思考，这一点对读者来说也是很好的。
但是我在面对 AI 时总有一个「复古癖」的执念，就是觉得 AI 不应该干预一些最原始的体验。我总觉得像阅读这种历史悠久的人类活动，里面总有些东西是容不得 AI 参与的，否则就会丢失这件事情本身的意义，毕竟我认为阅读的目的是为了更好地服务人本身。在看似 AI 能帮我们解放头脑和双手的情况下，不去亲自体味这些事情里的辛酸苦辣，我们作为人又怎么能成长呢？虽然 AI 能帮我们省时省力，可多出来的时间和精力，我总觉得还是得踏踏实实用在这些传承已久的事情上。
CG 艺术实验室(+1) 我的感受是，在最开始，因为有一堆旧习，而在很多场景下想不起来用 AI。
现在，AI 能切实落地，把事做好的场景越来越多，我已经变得开始好奇把一个事情交给它会怎样。
看书的场景下得分什么书，文学类的当然是自己看过瘾，看不懂都没事儿，追求的是感受。
纯知识理论类型，直接用来提升自己的书，我甚至会让 AI 先给我讲一遍作者的大致观点和论述逻辑，如果特别靠谱或者自己十分好奇，也会选择先过一遍原文。
如果单单以车手成绩去看待 F1 的比赛，那么当然会有「无聊」的比赛。但是，必须要记住，F1 这个赛制中永远有两套比赛在同时进行：世界车手冠军（World Drivers' Championship）以及世界车队冠军（World Constructors' Championship）。车队之间有技术竞赛也是 F1 好看的部份，但并不会在现场车手的动作当中那么反映得出来。在 Liberty Media 接手 F1 并推出 F1 TV Pro 流媒体之后，他们推出了一档节目叫做 Tech Talk，就是方便车迷了解到每个赛季车队技术竞赛的最新状况。而且车队在车手比赛中使用的策略也很重要。如摩纳哥这样的比赛中，排位和正赛策略基本上决定胜负的关键。所以，观看 F1 不要单纯地只看车手比赛的结果，然后判断无不无聊——因为这样你就错过了车队之间的竞赛。
而且，一个人能够稳赢是很不容易的。在 F1 多年的历史当中，像 Max Verstappen、Lewis Hamilton、Michael Schumacher、Aryton Senna、Alan Prost 等这样的车手可谓少之又少，而且他们并不都是简简单单就赢。任何赛车运动，恐怕除了 Rallycross 系列之外，都需要观众能够欣赏车手的专业能力、韧性还有坚持，也就是他们一圈圈把同样的动作做到完美、还要应对突发情况，这样去做至少一个小时的能力。
不能欣赏车手、车队的专业能力和他们做的事情，只期望比赛当中能够充满电影里的那些戏剧性以及各种疯狂超车，在一个小时的时间里获得多巴胺，那只会从 F1 或者是任何赛车竞赛系列中获得失望，基本上你只能看 Rallycross 和 Race of Champions。
而如果你从一个赛季的视角来对待每一场比赛，从一个车手的成长历程来对待他的每一场比赛，从 F1 的发展来看待每一场比赛，那有意思的东西就很多了。
后来在 ESPN 看过一段时间，其中文解说翻译车手名字跟我们有一些差别，比如他们管 Kimi 叫「拉」科宁（那时候 Kimi 还是希望新星），大学毕业后经历了布朗 GP 牛逼闪闪的一年，当时正好工作在上海，电视转播看了好多比赛。再后来，就是得知小周要进 F1 以后，从 21 年阿布扎比开始一直到现在了，通过 B 站各位 up 主，还有像飞驰圈这样的播客，深入的了解了 F1。
和传统 IDE 内置的审查插件不同，Code Review 主要运行在 GitHub 和 CI 流程中，而不是开发者本地的 IDE 里。也就是说，它更像是被放在代码提交之后、人工审查之前的一道自动检查关卡。乍一看，这确实像是个很有吸引力的新功能——毕竟在 AI 持续抬高代码产能之后，代码审查已经成了越来越多团队不得不面对的新问题。
更贵，也更慢：Claude 开始收“审代码税”
实际上，Anthropic 的 Claude 模型本身已经具备按需进行代码审查的能力——甚至可以通过让 Claude 审查自己写的代码，来评估 AI 生成代码的质量。此外，公司还提供了 Claude Code GitHub Action，可以在 CI/CD 流水线中自动触发代码审查。而新的 Code Review 服务，则把这种能力做得更深入——当然，成本也更高。
不过网友的质疑也很直接：既然 Claude 能审代码，为什么不一开始就把代码写对？有人吐槽，现在看起来像是 Claude 先写代码，再让 Claude 自己审代码，最后还抓出一堆 Claude 自己写出来的 bug。还有人说得更犀利：这会不会违背了“裁判不能同时当刽子手（既当运动员，又当裁判）”的基本原则？万一 Claude Code 先制造出问题，再靠修复这些问题继续收费呢？
