AI 会重写所有软件吗

AI 会重写所有软件？

从 Vercel 创始人 Guillermo Rauch 的预测说起

人物与趋势理解　|　资料核对至 2026 年 11 月 5 日

这是一条很重要的预测，人类写过的大量软件，运行缓慢、漏洞不少，连需求都没交代清楚。AI 会把它们重写，而且不止一次，直到更快、更省钱、更安全。说这话的是 Guillermo Rauch，Vercel 的创始人兼 CEO。他做过开发工具，也写过被无数开发者使用的开源软件。他的预测值得认真听，也值得拆开看：当写代码越来越便宜，软件真的会跟着变好吗？

▍说这话的人，写过什么

Guillermo Rauch，中文可译作吉列尔莫·劳赫，X 账号是 @rauchg。他来自阿根廷布宜诺斯艾利斯附近的拉努斯，少年时就热衷于 Linux，后来进入 JavaScript 和网页开发的世界。[1][2]

他的名字，藏在不少开发者熟悉的工具背后：Socket.IO 让网页与服务器保持实时通信，适合聊天、协作这类需要即时更新的场景；Mongoose 帮助开发者读写 MongoDB 数据库；他还设计并共同编写了 Next.js。[1]

Next.js 可以理解为一套搭建网站和网页应用的工程框架。页面怎样组织、数据怎样加载、一些底层工具怎样配好，它替开发者处理了许多重复工作。Vercel 则提供把应用发布到网上、交付给用户所需的云平台。[2][3]

这条经历，让他的预测有了一条线索：软件开发的门槛，可以被工具一层层降低。现在他把这个判断推到了更远的地方——如果 AI 连代码本身都能写，接下来的改进还能走多远？

也要记住，他同时是一位企业经营者。Vercel 已把人与 Agent 共同构建软件写进公司定位；这里的 Agent，指能够调用工具、执行任务的 AI 系统。他对这个未来既有技术判断，也有商业投入。[4]

履历能解释一个判断从何而来，验证仍得交给结果。

▍他看见的，是过去没算过来的成本账

在那条帖子里，Rauch 预言，AI 会反复重写软件，考虑更多故障情形，做验证和负载测试，把内存使用容易出错的底层代码改得更稳健；需要时，还能补齐文档、图示、动画和幻灯片。负载测试，就是模拟许多人同时使用，看系统会不会撑不住。[5]

这里藏着一个比「AI 会写代码」更有意思的变化：以前许多改进，算不过来成本账。一个程序能用，重写却要占用团队很久，还可能弄坏原有功能。于是，慢一点、绕一点的实现，被留了下来。

Google 已经给出一个具体例子。它在 2025 年介绍的 AlphaEvolve，会提出候选程序，再交给自动评估工具运行、评分，保留更好的方案继续尝试。Google 报告，其中一项调度改进平均释放了约 0.7% 的全球计算资源。这个数字是资源利用改善，不能理解成所有程序都快了 0.7%。[6]

这套办法的关键，在于能测出什么叫「更好」：结果要对，耗时要少，资源要省。AI 可以多试几条路，评估工具负责筛选。

普通人也会受到影响。一个小团队专用的排班工具、一份按自家规则生成的报表，过去可能因为开发和维护太贵，一直停留在想法里。如果这些成本下降，小需求就更有机会被照顾到。只是，生成一个演示界面，离长期可用还有一段路。

图 1｜从想法到可用软件：每次改进，都需要能把失败送回去的验收环节。

当尝试更便宜，原本被搁置的改进才有机会进入日程。

▍浏览器里的旧漏洞，已经被翻出来了

Rauch 对安全的期待，已有现实支撑。Mozilla 在 2026 年 4 月披露，Firefox 150 修复了初次评估 Claude Mythos Preview 时发现的 271 个漏洞。这个数字说的是被发现并修复的安全问题，不能当作 271 次完整攻击。[7]

这样的成果足以改变我们对旧软件的认识。一套长期维护、反复检查的程序，仍可能藏着以往没被发现的缺陷。AI 让一些昂贵的检查有机会做得更密、更广。

但 Mozilla 后来的技术复盘，也把另一半工作写得很清楚：模型需要放进能运行复现测试的工具流程，发现之后还要去重、判断影响、写补丁、复核并发布。这轮加固有超过 100 人贡献了代码。[8]

AI 能更快提出「这里可能有问题」，团队仍得回答「问题是真的吗，修好了没有，能不能发给用户」。对使用者来说，价值落在修复真正进入更新的那一刻。

发现问题越快，修复和发布就越需要跟得上。

▍一道绿灯，还不够放行

「会找漏洞」和「写出的代码安全」，需要分开验证。安全公司 Semgrep 在 2026 年 9 月，用 SWE-agent 1.1.0 搭配 Claude Opus 5.5，运行了 SusVibes v1.0 的 186 项 Python 开源项目任务，并给了通用安全提醒。结果：93.5% 通过功能检查，同时通过功能与安全检查的只有 54.8%。[9]

这些任务专门来自曾出现漏洞的功能，并非随机抽取的日常开发工作。公开项目的答案也可能进入训练数据；研究者发现大量输出与项目实现高度相似。因此，这组数字能说明特定测试里的落差，不能当作所有 AI 代码的安全概率，也不能据此判定 AI 普遍不如人。[9]

图 2｜分母均为全部 186 项任务。通过安全检查，只表示未重现该基准检查的原有漏洞。

更深一层的问题，是规则本身可能没写清。比如做一套退款工具：优惠券算不算退款？手续费退不退？跨月订单按哪天的规则处理？没有答案，程序就得猜。

Rauch 提到的形式化验证，可以理解为用数学方法检查程序是否遵守明确写出的规则。它很有价值，但退款规则若写错了，证明代码严格执行规则，钱仍会退错。

2026 年 10 月的一项预印本研究也观察到，模型生成的规格可能过弱，或被错误实现带偏，让错误程序通过验证。这个结论来自特定实验，尚不能覆盖所有验证工具，却提醒我们：验收标准也需要检查。[10]

标准若沿着同一个错误写出来，再多的绿灯也可能指错方向。

▍重写一套系统，要带走它的历史

「AI 会把它们全部重写」，是 Rauch 最大胆的一步。旧系统里，除了代码，还有历史。

想象一套用了多年的订单系统：某个看起来多余的字段，可能连着财务报表；一段绕来绕去的逻辑，可能照顾着旧客户的特殊约定；一个已经没人喜欢的文件格式，可能仍被合作方每天读取。这些都是举例，却足以说明迁移要面对什么。

把代码重新生成，未必能同时找回所有约定。切换时还要确认旧数据能不能读、合作方能不能接、账能不能对上；出了问题，要能退回旧版本。

Mozilla 的态度很有代表性：即使团队长期推动 Rust 这种能减少常见内存安全错误的语言，也无法停下所有工作，重写几十年的 C++ 代码；而 Rust 只能缓解某些类别的漏洞。[7]

所以，我更倾向于一种逐步发生的未来：先替换一个边界清楚的模块，让新旧结果对照运行；确认规则和数据都接得住，再扩大范围。有些系统会重写，有些会继续修补，有些值得长期保留。AI 让选择变多，具体怎么选，仍要算整笔账。

图 3｜一种渐进迁移思路。旧系统保留服务，候选模块通过对照和小范围验证后再扩大使用。

重写前，先找出旧系统里那些没人再敢随便改的规则。

▍软件会更贴身，维护也要跟上

再往前推一步，我更看好的是小软件变多、具体需求得到更多回应。这是一种趋势推演，速度仍取决于维护和验证能不能跟上。

一家几十人的公司，可能只需要一套符合自家习惯的审批流程；一个门店，可能只想把每天的库存和订单对起来。过去常常得迁就通用产品。如果生成和修改更容易，这些场景就更可能拥有自己的工具。

但软件交到手里，维护也跟着来了。业务规则变了谁来改，数据能不能导出，更换工具时能不能带走，运行费用会不会超过省下的时间？这些问题，会越来越早地进入购买和自建的比较。

软件公司的价值也可能随之变化。页面和基础功能更容易复制之后，稳定服务、理解行业规则、接好已有系统、长期照看数据，会更影响客户愿不愿意留下。

开发者同样要面对这笔新账。读懂现有代码、解释业务例外、设计可靠的检查，可能变得更重要。代码生成得越多，团队越需要知道哪些修改值得留下，哪些应该撤回。

一个工具省下多少时间，要连同维护它的时间一起算。

▍当代码变便宜，判断要跟上

顺着这些变化看下去，软件开发的重心可能继续移动：提出方案、生成实现会更快，澄清需求、设计验收、处理例外会占据更大的分量。团队还要把维护成本、运行费用和失败后的损失一起算进去。

对开发者来说，可以把 AI 接进实际流程：让它针对一个明确问题提出修改，再用保留的测试、真实工作负载和人工复核检查结果。尤其要防止它为了通过检查，顺手把检查标准也改了。

对不写代码的人来说，也有一条很近的路。挑一个熟悉、出错后容易撤回的小任务，比如用脱敏或虚构数据，把一张费用表按既定规则分类。把输入长什么样、分类依据是什么、遇到例外怎么办写下来，再亲手准备正常、边界和错误输入三类样例。

可以把下面这段话交给正在使用的 AI 工具。先让它追问，再开始生成：

我要做一个费用分类工具。

先问清分类规则和例外情况。

使用我提供的虚构样例。

保留原始数据，另行输出结果。

用我准备的样例逐项验收。

遇到不确定的项目，标记待确认。

这一步会让你发现，自己对需求的理解可能也有空白。AI 把实现拉近了，也把原本藏在讨论里的含糊照了出来。

Rauch 把这种未来称作「软件工程真正的诞生」。这句话带着创业者的锋芒。我们可以保留它的期待，同时用更具体的标准衡量进步：过去没做的检查，今天是否做得起；以前不敢动的模块，今天是否能有把握地改。

代码可以反复生成，验收的依据要能留得下来。

当一套软件允许人查清规则、复现失败、看懂修改，并在出错时退回上个版本，AI 才真正把它往前推了一步。

来源

· [1] Guillermo Rauch，About（个人官网）：https://rauchg.com/about

· [2] EY，Guillermo Rauch 人物资料（2025）：https://www.ey.com/en_gl/weoy/class-of-2025/argentina

· [3] Next.js 官方文档，What is Next.js：https://nextjs.org/docs

· [4] Vercel，About Us：https://vercel.com/about

· [5] Rauch 的 X 帖子，本文依据读者提供截图转述：https://x.com/rauchg/status/2118166970273292299 。网页读取受限，未独立确认发帖日期；「几周、几个月」指看清旧软件问题的时间，并非完成全部重写的期限。

· [6] Google DeepMind，AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms，2025-05-14：https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/

· [7] Mozilla，The zero-days are numbered，2026-04-21：https://blog.mozilla.org/en/firefox/privacy-security/ai-security-zero-day-vulnerabilities/

· [8] Mozilla Hacks，Behind the Scenes Hardening Firefox with Claude Mythos Preview，2026-05-07：https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

· [9] Semgrep，Claude Opus 5.5 Writes Working Code but Only Half of It Is Secure，2026-09-29：https://semgrep.dev/blog/2026/claude-opus-5-5-susvibes-benchmark/ 。特定 Agent、模型与基准的一次实测，存在公开代码记忆与评测工具修正等限制，不能外推为真实项目安全率。

· [10] Wang 等，Are LLM-Generated Formal Specifications Faithful to Their Requirements?，2026-10-23，预印本：https://arxiv.org/abs/2610.32053

· 说明：人物资料与案例取自上述一手来源；文中的成本分析、迁移路径和未来判断为本文综合解读。退款、订单系统与费用分类均为解释性假设案例。