AI可以用任何手段、写任何东西，但你得是个“中年老登”

本文来自微信公众号： InfoQ ，作者：Tina

“我现在陷入到一种巨大的虚无主义里，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基本上可以用任何方案、任何工具、任何手段去写任何东西。”

成本方面，峰值时一天会消耗约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，那就等着看笑话吧。”