“我现在陷入到一种巨大的虚无主义里，AI 什么都能写。”

PingCAP 联合创始人兼 CTO 黄东旭在完成 db9 项目后这样说。

做 db9 之前，他心里预设过一个终点：复杂到某个阶段，AI 总该做不下去。结果是，每次系统看起来要撞墙，调整 harness、任务拆分和 agent 协作方式之后，它又继续往前走。三个月后，一两个人参与、100 多万行代码的数据库项目跑了出来。最后，他发现自己没有等到那个边界。

“我做 db9 过程中，最大的体会就是，我没看到边界。这已经是我能想到最复杂的软件了，但还是没有看到边界。”

那些让我们争得头破血流的东西，都没了

“没看到边界”的第一层含义，是过去很多被视为长期锁定的东西，开始松动了。

语言、框架、数据库选型，曾经都是软件工程里最重的决策。一个系统写进某种语言、某个框架、某个数据库以后，技术栈会慢慢长成组织结构。招聘按它来，测试体系按它来，部署方式按它来，线上事故的处理经验按它来，工程师的身份认同也按它来。时间越久，这个选型越不像一个技术选择，而更像一条公司命运线。

所以选型是一个漫长、谨慎、充满验证成本的过程。用 Rust 还是 Go？React 还是 Vue？MySQL 还是 Postgres？每有更换技术栈的事情，社区里都会为是否值得吵上好一阵。而且类似的迁移在过去往往是以“年”为单位的工程。Meta 从 Java 迁到 Kotlin，哪怕高度依赖自动化工具，也跑了整整 4.5 年；微软把 TypeScript 编译器用 Go 重写，也花了约 14 个月。

但 Bun 从 Zig 迁移到 Rust，用了 6 天。

Ghostty 作者、HashiCorp 联合创始人 Mitchell Hashimoto 说：“编程语言过去意味着锁定，但现在越来越不是这样了。Rust 并不重要，Bun 已经证明，他们几乎可以在一两周内用任何他们想要的语言写代码。”

Simon Willison 记录过一个应用层的类似案例。一家中型企业用 coding agent 将他们历史悠久、颇具代表性的遗留 App，包括 iPhone 和 Android 两个原生版本，都重写成了 React Native。他问这家技术负责人为什么要换框架，对方的回答是：“即使后来证明这个决策是错的，未来也可以再用 Agent 迁回原生。”

框架选型不再像过去那样是一条单行道，它开始变成一个随时可以撤回、可以重做的工程决策。

数据库也一样。黄东旭说，从 Agent 的视角看，MySQL 和 Postgres 之间，只是语法差异，就像方言问题，不是世界观问题。因为两者背后是同一个心智模型——SQL。这个模型极其稳定，在 LLM 的训练语料里到处都是。Agent 早就懂了。

Agent 没有偏好，“它不会在乎语法优不优雅，也不会在乎社区文化，更不会纠结‘哪一个更像正统’。只要接口是稳定的、语义是清楚的，生态是完备的，网上能找到丰富的文档，它就可以很快适配”。

那些让人类吵得头破血流的品味之争，在 Agent 这里，都不存在了。

“什么都能写”

如果语言、框架、数据库都不再构成不可动摇的长期锁定，那么接下来真正被打开的，就是软件实现本身。

黄东旭说，“AI 基本上可以用任何方案、任何工具、任何手段去写任何东西。”

db9 就是一个复杂度足够的例子。它被设计为一个面向 AI Agent 的数据库，完整的 Postgres 语法支持、具备向量检索 / 全文检索能力、TypeScript Serverless 函数、极致多租户。三个月内，从第一行代码到上线，代码量超过 100 万行 Rust。0 行由人类手写，0 行由人类 review。上线后，服务了超过 10,000 个数据库实例。

成本方面，峰值时一天会消耗约 10 亿 token；一个月下来，大约是 2000 美金级别的 token 成本。这个成本相对比最终产出，基本可以忽略不计。对比来看，过去做出同样规模的东西，至少需要几十个人的团队干上一年。“现在相当于我一个人一个月就干出来了，”他说，“所以还是很夸张的，当时我自己也非常震惊。”

这个项目始于感恩节假期的一个小实验，一开始就是想试试看它的边界在哪里。“我心里预想的是，应该做到某个阶段，它就做不下去了。”但每次到了做不下去的时候，就看看是什么地方出错了，然后跟它一起调整自己写的 harness 产品，不断优化人和 AI 协同的方式。结果发现它和它的团队越干越好，一直往前走。

“到某个点之后，我发现它已经超出了我能掌握或者说我能看的边界，我就不看了，因为看不过来。它的产出效率太高了。到今天，我已经不太关心代码细节了。至于开发过程，它肯定干得比我好。”

AI 做事太快，反馈链路太短。过去这段时间，黄东旭以前攒下的所有 idea，以前想做的但没时间做的所有东西，现在用 AI 一个不落地的都实现出来了。基本上每天做一个，每天做一个，到后来，他产生 idea 的速度已经跟不上 AI 做出来的速度了，这让他非常难受。

黄东旭本身技术能力足够强。当一个技术很强的人把 AI 握在手里，效果被放大无数倍，结果会很可怕：“我现在的状态是：至少生产软件这个过程已经没有什么意义了。你不会再觉得一个东西很难，或者觉得它是高科技。软件本身作为护城河，这件事已经没有了。我可以复制我看到的任何东西。但复制也没什么意义，因为人家已经做了。”

我们问他：那到底什么软件能写？是否需要一些特别的原始条件？

他回答：“没有什么原始条件。没有。所以我现在陷入到一种巨大的虚无主义里，什么都能写。”

“重写”格局小了

从“什么都能写”走向“什么都能重写”，可能是这轮变化里更值得关注的行业趋势。

AI 不只是降低了软件生产门槛，更在改变软件演进的方式。过去，“重写”往往意味着高风险：旧系统不能停、兼容性不能丢、业务逻辑不能错，所以很多老系统，只能继续运行下去，没人敢真正替换它们。

先是那些边界清楚的软件开始被重写，接着连没有源码的系统也开始被还原和重建。

这半年里，有大量的重写案例。

今年 2 月，Cloudflare 的工程师 Steve Faulkner 发现 Next.js 很难部署到无服务器平台，于是用 AI 在一个周末里重写了它，做出 Vinext——一个基于 Vite 的替代实现，Token 成本约 1100 美元，已跑进生产环境。

今年 3 月，一个叫 chardet 的 Python 库——requests 的依赖，很可能藏在你的项目里——它的维护者在维护了十二年后，用 Claude 重写了整个库，并把许可证从 LGPL 换成了 MIT。引发的争议至今没停。

更极端的是没有源码的重写。

总有一些没人愿意触碰、又人人依赖的系统，特别是在运行了几十年的大型企业核心系统里。它们构建于早已无人问津的技术栈，困在过时的数据库、老旧的操作系统、脆弱的虚拟机中。维护人员流失，文档缺失脱节，甚至连源代码都找不到了。

Thoughtworks 做过一个典型案例。一套企业系统，源代码完全丢失，只有二进制文件还在。数据库有 650 张表、1200 个存储过程，应用层是 45 个 DLL 文件。团队用 LLM 辅助反向还原：观察 UI 变化，追踪数据库写入，分析存储过程，反编译汇编代码，再由人做验证、校准和交叉确认。几周时间产出了足以驱动重写的规格。传统方式需要 20 人花 6 个月。

还有一个更戏剧化的个人项目。1992 年，Jon Radoff 开发了一款 MUD 游戏，获得了 1993 年《计算机游戏世界》杂志的艺术卓越奖，2000 年停运，源代码全部丢失，只剩下一些脚本、手册和游戏录像。他把这些材料丢给 Claude Code，说“自己搞明白”。Claude Code 逆向还原了他 30 年前设计的自定义脚本语言，然后从零重建了整个游戏引擎和完整世界。原版是 90 年代他花几个月写出来的 C 代码，这次变成了一个周末项目。

“一种我三十年前设计的语言，没有正式规范，只有一本 GM 手册和一堆示例脚本，被一个从未见过它的 AI agent 完整重建了。”

也就是说，就算没有源代码的软件系统，在大模型面前也能被重写、被复活。

代码不重要，知识才重要

徐昊把这类实践归为“知识工程”。他认为，真正有用的不是代码本身，而是文档、遗留下来的规则、业务逻辑、系统行为这些沉淀在软件里的知识。就像 Thoughtworks 的黑盒案例，背后其实也是通过反向工程去反推 specification，因为真正有用的是把这些知识还原回来。

徐昊在汇丰银行也用了很多类似 specification driven 的方法。面对遗留系统，先让 AI 生成一版 specification，讲清楚这个系统在做什么；人去读、修正，让 specification 变正确；再根据 specification 生成测试，用测试验证系统行为。之后基于这份 specification 做改造和迁移。

“这比你拿到一段代码，直接让 AI 去迁移，要重要得多。”因为“真正要反向出来的，不是代码，是 specification。”

这就回到了他一直在强调的那个判断：软件本身只是载体，真正的产品是软件中的知识。

如果知识已经留存下来，载体发生变化，这件事用交叉编译来理解更清楚——同一份代码以前要跑在不同芯片上，通过编译生成对应平台的可执行代码，你不会说“编译器帮我重写了软件”。因为 specification 是存在的，“编译器”只是帮它换了个载体。现在，通用大模型成了那个编译器，在不同技术栈之间做迁移和转换。

就像一本故事书，书本身不是产品，里面的人物、故事线、情节才是。至于是纸质书、电子书还是播客，差别不大。放到软件里，用 Rust 写、用 C++ 写，或者换一个框架，本质上都是载体变化。

徐昊说，他在行业里嚷嚷快 10 年了：软件不是产品，软件中的知识才重要，应该更加注重软件中的知识管理。现在 AI 终于让它变成了显学。

只谈“重写”，视角太狭隘了

如果从行业和社区的变化往前看，用 AI 来“重写软件”这个视角本身也窄了。

“重写”默认有一个边界清楚的软件：Photoshop、ERP、数据库、框架、编译器。先有固定对象，再讨论要不要换技术栈重新实现。但徐昊觉得，这个前提正在松动。未来很多软件可能不再以固定边界存在。

微软和英伟达正在准备把 agent 做进操作系统内核。Agent 一旦进入操作系统，软件入口就变了：过去是人打开应用、寻找功能；未来可能是人直接提出需求，系统现场生成能力。Hermes 这类系统已经在往这个方向走。很多 skill 不再来自下载，而是根据任务现场生成。这意味着，“应用程序”和“有固定边界的程序”可能会彻底消亡。

而我们今天讨论的“重写”，前提是“有一个固定边界的软件需要被重写”。如果这个前提本身正在瓦解，那“重写”这个话题的格局就小了。

徐昊举了 Photoshop 的例子。今天你说要重写它，因为 4000 个功能需要复刻。但未来，它可能只需要最核心的图像处理能力——你告诉 agent 要 P 图还是创作，它当场给你生成几个功能就够了。

软件的存在方式正在被重写，而“重写”这个概念本身，可能也只是一个过渡。

AI 能写一切，但“老登”说了算

既然什么都能写、什么都能重写，那人的价值会发生什么变化呢？

二三十年 IT 经验的滕昱说，AI 会给行业带来极大变化，90% 到 95% 的程序员会受到影响。但“老登们（老工程师们）”还有希望——那些真正能做判断、能掌舵的人。

滕昱最近两个月写了大量代码，但不是直接写。“谁还手搓代码呢？只需要 review，做判断。”

在他看来，Agent 写代码的能力已经超过绝大多数人，“所有还在学习中的新人、十年经验以内的人，都没 Agent 做得好。”

人写代码往往是 happy path 写完，顶多再加几条异常路径，出了问题再补。但 Agent 不一样，它不会偷懒，一写就是三五千行，把所有路径都堵上，在受过训练的领域里，这是它的强项。但问题是，它不能掌握方向。

因为 AI 只有讨好型人格，它是被一个没有痛苦反馈的系统训练出来的。面对一个复杂问题，它说不出口“我做不了，我不会”。相反，它会编答案，会忽悠你。你让它改到第三遍还不对，它还会继续给你一个看上去像那么回事的东西。如果没经验，你很容易被它忽悠，连测试它都能造假。

所以，做好的前提是有人掌舵。方向要自己定，设计要自己做——至少要给 AI 一个小设计，它才能做下去。那谁来掌舵？“老登”——只有那些踩过坑、做过决策、知道路通向哪里的老工程师，才知道该往哪个方向指。

黄东旭印证了这一点。他说，“我的观点就是，它确实什么都能干，但人要负责判断。”

因为它什么都能干、什么都能写，知道的东西又非常多，所以人的判断反而变得更重要。如果什么 input 都不给，让它自己干，刚开始很快，几万行代码的雏形一下就出来了。但越往后越推进不下去。这边改好一点，那边就崩了；那边改好一点，这边又崩了。甩手掌柜式的开发，做不了特别复杂的项目。

尤其是特别长、特别大的复杂模块，就会考验人的技术选型品位、经验和判断水平。

比如做数据库内核设计，你得告诉 AI：parser、优化器、执行器这三大组件怎么拆，不能把所有代码堆在一个大文件里；如果采用 volcano model，优化器该考虑哪些 metrics，什么算法最合适，参考哪篇论文、哪种实现——这些不能从书里抄来，得做了很多年内核才能知道。

另一类 Input 是软件工程层面的代码风格和技术选型：模块不能嵌套太深，文件超过 2000 行就得拆，做网站用 Vercel、不要用别的，用 Postgres、不要用 MySQL。AI 可能全都知道，但它不知道“应该用哪个”。这些约束来自经验，来自对“哪条路后面会省很多事”的判断。

徐昊从另一个角度解释了这件事。他说，敏捷软件开发里早就讲过一件事：开发过程中 80% 的工作是沟通、定义需求、定义验收条件。写代码只是剩下那 20%。现在流行的 harness engineering，本质上做的是同一件事——定架构规范、编码规范、架构分层，这叫前馈控制；后面写验收条件、写测试，这叫反馈控制。这些本来就是工程实践里该有的东西。

所以，程序员的工作从来就不是“写代码”。写代码是手段，不是目的。程序员的工作是写正确的代码，写 ROI 最高的代码，写优先级最高的功能，为客户交付价值。

如果一个人认为自己的工作就是写代码，徐昊说，“那这个人早就该被行业淘汰了，都不需要等到今天 AI 出现。”AI 只是把这件事变得不能再被忽视。

工具变了，但价值来源没有变。开发者真正值钱的地方，始终是为客户交付了什么，而不在于亲手完成了什么动作。

唯一还值得吵的事：企业软件维护

过去一年，软件工程里的老规矩一条条在断。技术栈锁不住了。重写没那么可怕了。代码也不值钱了。行业变了，开发者的价值也变了。软件的护城河也变了——用 AI 把 Salesforce 重写一遍自己用，听起来好像也不离谱。

黄东旭反而说，这是创业最好的时候。写代码本身不再稀缺，真正知道自己要解决什么现实问题、能带来什么业务价值的人，反而浮出来了。过去需要 1000 人解决的问题，今天两三个人经验丰富的人就可能搞定。所以对真正有 know-how、真正能解决实际问题的人来说，这是最好的创业时机。

徐昊的判断也类似。他不觉得这是一个很烂的时代，反而觉得这是最好的时代。过去企业买标准软件，常常要削足适履——上了 ERP，组织流程要迁就软件；不上，规模大了又管不过来。SaaS 把流程做短了，但根本矛盾还在：每家企业都有自己独特的运营模式，为什么一定要所有人适配同一套软件？大模型把这个问题重新打开了。企业可以用更低成本做出真正适合自己运营方式的软件。市场当然会洗牌，但没有永恒的业务模式。

然而，新世界正在降临，旧世界里的东西还没消失。

新软件可以重写，但企业内部那些跑了十几年、二十几年的系统，不会因为一句“AI 什么都能写”就消失。它们还在生产环境里，还在客户机房里，还在承担真实业务，还需要继续维护。这也是很多老一代技术人没那么乐观的原因——Spring 创始人、C++ 之父、传奇黑客 George Hotz 这些人担心的，不是 AI 写不出新代码，而是它会把已有代码库变得更乱。

于是，两种判断在这里分岔： 一部分人看到的是未来，另一部分人看到的是现实。

徐昊属于前者。他认为“维护”这个概念本身就非常“人类”——它的前提是“我要在现有代码上修改”。但如果重写的速度足够快，为什么还要维护？他举了编译器的例子。以前程序员写汇编，编译完还要自己手动改。后来编译器水平提高了，没人再去改编译器生成的汇编了。如今，也不会有人说要去维护编译器生成的东西——想改，重新编译一遍就行。

同理，那我们为什么还要去维护 AI 自动生成的代码？“只要控制好上下文，把它置于 harness engineering 的框架之下，在每一个具体上下文里，生成的代码行为都是可控、可验证的。需要什么功能，重新生成就好了。”

他甚至认为，现在的 Agent 工具已经可以直接接管一个代码仓库。人只需做知识标注、补充业务上下文，Agent 就能围绕仓库中的文件进行阅读、理解和索引，快速定位这些文件，并在上面直接修改。

只要一个已有代码仓具备充分的上下文标注，并托管给 Agent，它就能像人一样进行修改。

“现在绝大多数情况——至少据我所知，大部分企业——会逐步从手工写代码过渡到 Agent 托管。”新功能或新特性完全交由 AI 完成，这种情况确实存在。但更常见的工作形态是：以 Agent 托管为主，AI 改一部分，人则提供更强的 harness 或反馈。

直到有一天，AI 的理解能力足够强大，能在代码仓库里完全独立完成开发。到那时，就不再需要人类干预了，编程将完全由 AI 托管。至于这个代码仓最初是人写的还是 AI 写的，已经不重要了。

滕昱的视角更贴近当下的现实。他说企业软件很多都是屎山代码，前后不一致的判断太多，Agent 进去会精神分裂。Agent 确实能写代码，在本地当然也能让代码整体跑起来，可现在最大的问题是，一旦部署到客户环境，出了问题，不能甩手不管，还是得自己登录客户环境去处理。

他也提到，前一阵和朋友聊天，对方同样反映，AI 代码上线后，bug 数量明显增多，问题成堆。说白了这就是双刃剑，最终责任还得由人来承担。

问题在于，重写和迁移的成本下降是有前提的——得是在基本完成同样功能的前提下，基础的编程语言和 framework 基本能做到 1 对 1 mapping 时才能成立。

可现实中，很多细微的语言级别和行为细节上，但凡不能做到 100% 兼容，都会出现看起来很美、跑起来崩溃的情况。这一点在代码历史包袱重的企业软件上尤其突出：一旦有人把一个巨大重写的 PR merge 进来，基本上当前这个 release 就要面临延期的风险。

再比如，你让 AI 重写一个模块，语法能编译，单元测试能过，但一上线流量来了就崩。拿 JDK 升级来说，很多大版本升级都有语义差异，Java 的语义在不同版本间并不一样，比如 virtual thread 这类特性。语法上可以编译，刚跑起来也没问题，流量一上来行为就不可控，出了事连 debug 都没法做。

“今年下半年企业开发里一定会看到很多这种例子，”滕昱说道，“越是那种半懂不懂的人，反而越容易相信 AI，那就等着看笑话吧。”

采访嘉宾｜黄东旭、徐昊、滕昱（按文中出场顺序）