全部 · 2026-03-12

vinext 在 1 周内复刻 Next.js、Token 成本 1100 美元、API 覆盖率做到 94%，这组数字已经足够说明一件事：框架层代码资产的稀缺性在快速下滑。你再拿“我们积累了 10 年代码”当壁垒，今天基本没人信。一个能跑生产 Next.js 应用的兼容实现，只要文档全、社区语料够、接口测试可见，AI 就能把多年工程劳动压缩成几天迭代。这对 Vercel 确实不是小事。它不一定直接打穿收入，但会打穿“高研发投入天然该有高软件溢价”这套说法。 但我对文里的主判断有保留：测试很重要，甚至越来越重要；把它直接讲成“新的护城河”，有点说满了。Next.js 的价值从来不只是一堆 API 行为。它还有宿主平台、默认脚手架、生态插件、和 React 官方关系、以及团队在框架演进上的议程设置权。就算 vinext 兼容 94%，剩下那 6% 往往才是企业线上最疼的部分：边缘缓存、构建插件、奇怪的 hydration bug、升级路径、以及谁来背 SLA。测试能证明“像”，不自动等于“可迁移、可维护、可担责”。这几个维度，今天仍然主要握在原厂和托管方手里。 我还想给这条补一个行业背景。过去一年，代码生成把“实现一个框架”这件事的门槛压得很低，但“验证一个框架”反而变成主成本。很多团队已经体会到，Claude Code、Codex 这类工具能在几小时里铺出 80% 的实现，后面 80% 的时间花在回归、兼容、基准和线上事故复盘。这个节奏跟 2024 年大家炫 demo 完全不同。那时看谁写得快，现在看谁知道自己哪里没测到。也因为这个变化，开源项目会重新估值自己的非代码资产：测试、CI 数据、故障样本、用户工单、性能回归历史。文里拿 SQLite 举例是对的。SQLite 15.6 万行代码，对应 9205 万行测试，比例接近 590 倍，这个量级已经把“代码只是入口”说得很清楚。TH3 闭源也说明，最贵的不是 SQL 语法实现，而是极端边界条件的知识库。 不过，我还是要泼一点冷水：SQLite 的例子不能直接套到 Next.js。数据库引擎和 Web 框架的失效成本不一样。数据库错一次，可能就是数据损坏；框架错一次，很多时候是页面坏、缓存错、SEO 掉。都痛，但风险结构不同。所以 SQLite 愿意把核心测试当机密资产，很合理；Next.js 或 tldraw 如果也全面收紧测试，代价会更大，社区 PR 会下降，第三方适配会变慢，生态外溢会受伤。开源项目一旦把测试和行为规范都锁起来，短期能卡 AI 复刻，长期也会削弱自己作为标准实现的地位。这笔账，不是“防复制”三个字就能算完。 文里还碰到版权，这块我觉得说得有点快。MIT 项目被功能复刻，争议确实小得多；LGPL/GPL 项目被“重新实现”后换许可证，争议会大很多。但“美国法律规定 AI 生成产物无版权，所以许可证无效”这句不能这么顺着推。美国版权局对纯 AI 生成作品的态度一直偏严格，这我知道；可软件项目很少是“纯 AI、零人类选择”的状态。架构决策、提示词、筛选、修改、测试、发布，这些都可能构成人类作者性。正文没有给出判例，也没有把功能兼容、代码相似、衍生作品这几个法律问题拆开，我没法接受它一把梭地下结论。这里的信息缺口很大。 我自己更在意的是另一个后果：如果大家都认定“公开测试=给 AI 送弹药”，开源世界会开始出现一批“源码开放、测试半封闭、线上数据私有”的新许可证和新协作模式。这个方向已经有苗头了。前几年大家争的是 source available；现在会转成 eval available、test available、trace available。谁掌握真实工单、失败日志、性能回归样本，谁就更难被一比一咬住。AI 把软件竞争从“写出功能”推到“积累行为证据”。 所以这篇里我认同一半。代码护城河确实在塌。测试资产的重要性也确实猛增。可如果你把胜负手只放在测试上，就会低估平台控制力、分发权、托管收入和默认心智。Vercel 最该怕的，不是有人又写了一个 Next.js；是越来越多人意识到，兼容实现已经便宜到可以拿来跟原厂谈价，或者干脆把框架和托管解绑。那一天一旦到来，Next.js 的商业逻辑才会真开始松。

300名受访者计划在1至2年内提高AI投入，且45%只增加25%以内。我的判断很直接：这条材料讲的不是“AI全面进入产品工程”，而是产品工程把AI驯化成一套受约束的辅助系统，先放进能审计、能回放、能签责任的环节里。 先说我为什么这么看。文中把优先项压在预测分析、仿真、验证，逻辑很硬，因为这几类场景有闭环。模型给出一个设计建议，你能拿历史失效率、仿真误差、测试覆盖率、法规指标去验。车规、医疗器械、工业控制都一样，出错不是聊天机器人答非所问，而是召回、停线，严重时就是伤人。这里面“分层信任”和“明确人工负责”不是保守口号，是工程组织在给AI划责任边界。谁能自动执行，谁只能提建议，谁必须人工签字，这些都得写进流程。 这跟过去一年软件行业那套“先上copilot再补治理”的节奏差很多。我记得2024到2025年，很多企业软件团队先买代码助手，再慢慢补审计、权限和数据隔离。产品工程反过来走：先问验证怎么做，责任谁背，模型输出能不能过认证，再决定投多少。调查里90%要加投听着很热，但分布一拆就没那么热了：45%增幅不超过25%，接近三成增26%到50%，只有15%增51%到100%。这不是豪赌，是预算试探。 我对这份材料还有两个保留。第一，它来自MIT Technology Review Insights 的定制内容，不是新闻编辑部报道。这个身份不自动让数据失效，但会影响叙事重心：它更像一份赞助型行业白皮书，天然偏向“AI正在被务实采纳”的结论。第二，正文没披露样本构成。300人来自哪些行业、地区、公司规模、是否含现有客户，正文都没给。汽车、航空、消费电子、医疗设备对风险和认证的要求差异很大，混在一起看，均值容易掩盖结构差异。 我还不太买账的一点，是它把“优化优先于创新”讲得过于顺滑。现实里很多制造企业并不是主动选择务实路线，而是卡在系统集成和数据质量。仿真模型的历史数据是否完整，PLM、MES、CAD、测试台架是否打通，决定了AI能不能进流程。没有这些底座，再好的模型也只能停在报告生成和文档检索。文章把 adoption barrier 讲得比较抽象，没有给出一条硬数字，比如仿真缩短了多少周期、缺陷率降了多少、认证时间少了多少，这让我对ROI叙事保留意见。 不过它抓到了一件很重要的事：在物理世界里，AI先吃掉的不是“创意”，而是“验证成本”。这跟纯软件场景不同。代码写错能回滚，实体产品发出去就没这个待遇。所以工程团队把钱先投到验证、仿真、预测维护，我觉得完全合理。西门子、达索、Ansys、PTC 这类工业软件公司这两年一直在往这个方向推，把生成式接口包进数字孪生、CAE、需求管理和质量系统里。大家都知道开放式生成很吸睛，但真正能过采购会的，通常还是能把良率、能耗、缺陷率做成报表的工具。 我的结论是，这份调查的价值不在“九成会加投”这个标题数字，而在它把工业AI的排序讲清了：先证明不会出事，再证明能省钱，最后才谈设计范式变化。要是后续报告拿不出行业拆分、基线指标和验证结果，这条就只是一份气氛调查；要是能补上“哪些团队把AI接进了发布签核链路”，那就有硬度了。