“这就意味着宇宙普适的物理规律不存在，那物理学……也不存在了。“汪淼从窗外收回目光说。

——《三体》

多年以后，面对黑色屏幕上闪动的白色光标，我们将会回想起，那个 AI 编程横空出世的 2025。

2025 年是 AI 编程的大年，从 OpenRouter 的年终统计 来看，AI 编程用的 Token 占了整个 Token 使用量的一半左右。 programing-token

作为“资深程序员”，我今年也贡献了很多的 token 使用量，深切感受到 AI 编程对于软件开发领域带来了不可逆的影响。至少从技术上，我认为这些影响绝大部分都是正向的。

之前写程序一定程度上是“体力劳动”，不管有多宏大的想法，代码总要一行一行写。 AI 编程让程序员向脑力劳动又前进了一步，我们需要更激进地学习新知识、使用新工具，从这个角度来说，我认为 AI 编程是提高了对计算机从业者的要求，而不是某些媒体鼓吹的“技术平权”。

这篇文章总结下我对 AI 编程现状的观察，以及对后续发展的预期。

开发工具⌗

首先从开发工具讲起。明星创业公司 Cursor 因为 VS Code + Claude 一夜走红，算是彻底带火了 AI 编程。但是我想讲的不是这个，而是为什么突然所有的公司都开始做 CLI 工具，比如 Claude Code, Codex, Gemini CLI 等等？

我认为这里有三个方面的原因：

  • 投入太大： IDE 或者可视化编辑器这一块，VS Code已经是绝对的霸主，这可以说是一个已经解决的问题。如果新产品还从这个方向切入，势必要投入不少精力追赶，这在这个快速迭代的时代是不可想象的。虽然市面上还是有不少基于 VS Code fork 出来的编辑器，但是很难像 Cursor 刚出来的时候给人的惊艳感，包括 Amazon 的 Kiro 刚出来的 Spec 模式确实很不错，但是这些模式很容易被同行快速学习和复制，后续也渐渐陷入平庸。
  • 产出太小：其实如果投入大但是又是必须的话，那么还是避免不了要去做。但是对模型来说它并不需要一个 IDE，做 AI 编程最重要的是给模型提供一个高效的环境，而这个环境有命令行已经够了。而且这里有个逻辑是，如果你说你在做个新东西，但是又对过往路径有强依赖的话，可能要重新思考这个方向你到底该不该做，因为大概率竞争不过市场上的领先者。
  • 未来趋势：这个我觉得更加重要。VS Code 这样的编辑器是针对人使用设计的，最大的需求是给人提供便利；但是命令行工具很容易自动化，也很容易和别的工具协同工作。当模型和工具越来越成熟之后，人的参与度会越来越低，而这件事情实际上已经发生了。很多基于 IM、文档、网页等等提供的 AI 编程的工具已经开始被大家使用，我相信这背后肯定是这些 CLI 工具作为支撑。这些工具带来的最大的变化是多会话的管理，因为人同时只能处理一个问题，但是你可以开很多个 CLI 同时让模型做事。

总结来说，2025 年大部分人应该都能通过大模型加速写代码，我认为 2026 年开发者需要找到自己的工具，把工作并发起来，而且这可能不能单纯靠等待市场上产品成熟，也需要自己做好准备，比如开发规范、测试规范、发布流程等都配套跟上。

编程语言⌗

其实目前各大编程语言都已经找到了自己的位置：

  • JS/TS 除了做 web 应用，几乎还能做一切，不得不感叹前端圈真的太卷了！代表作 VS Code
  • Python 是数据处理和机器学习领域绝对的王，代表作 PyTorch
  • Golang 在各种分布式系统中发光发热，代表作 k8s
  • C/C++/Java 等“传统”的编程语言依旧在企业中大行其道，很难被替代

但是！这个问题我还是实在忍不住要讨论，因为我已经彻底锈化了！这里我不想再列举 Rust 开发的系统或者应用，甚至我也不想提 Rust 已经进入 Linux 内核领域，我觉得大家可以思考一下 AI 编程时代我们需要什么样的编程语言？

一种论调是，AI 编程时代语言已经不重要了，因为反正都是 AI 写。但是如果都是 AI 写，为什么不用一种，往上能编译成 WASM 给 JS 用，中间可以通过 pyo3 把性能敏感部分用 Rust 写成扩展，让 Python 关键路径飞起来，往下还能写数据库和 Linux 内核的语言？

AI 编程在很大程度上缓解了 Rust 之前广受诟病的那些问题：陡峭的学习曲线、和编译器的拉扯等。而且用 AI 写过代码的都知道，Rust 编译器这么强的检查对于功能保障太重要了！ 一定还会有新的编程语言出来，但是我认为 Rust 就是现在能看到的 AI 编程最佳理想型。

魔法库⌗

魔法库在我这里是个贬义词，魔法库 == 过度设计。最典型的代表，Java 世界的 Spring，各种语言的 ORM 框架，以及炒得火热的 LangChain，其他的项目欢迎自己对号入座。

当然我不是一味否定他们的价值，流行一定有他的原因，有他的场景和受众，而且 AI 编程之前程序员是“体力劳动”的时代，有个代码库帮我们做点事情稍微减少我们的工作量还是有一定帮助的。在很多常见业务场景里，AI 直接帮你现搓一套简单实现往往已经够用，而且代码简洁清晰，想改就改，不必为魔法库的各种配置和绕路方案买单。

我认为在 AI 编程的时代，给公共库的开发者和使用者都提出了更高的要求：

  • 对于开发者：这个库的功能足够单一吗？接口是标准的吗？对使用者系统的侵入性大吗？需要复杂的配置和学习成本吗？里面的魔法多吗？理论上来说越标准、越简洁、确定性越高的公共库，越适合被 AI 使用（当然也包括人，但是人有时候容忍度很高）。作为公共库的开发者，需要以各种语言的标准库的标准来要求自己。
  • 对于使用者：也就是我们大多数人，需要建立自己的审美和世界观。这个库提供了什么功能？是不是最好的实现方式？有没有其他的不对代码太多侵入的方案？我的场景需不需要这么复杂的库？一定程度上，这并不比开发一个公共库更简单，因为理论上你随便写段代码放出去就可以认为自己做了个公共库，但是从使用者角度理论上你需要做好 Fork 任何公共库改为己用的准备，你能不能接受？

计算机的世界没有魔法，如果有，那我们应该成为参与者而不是旁观方。

测试⌗

软件测试是软件开发过程中逃不开的话题，过往就有各种测试相关的技术被提出，各有千秋。在 AI 编程的时代，这件事应该要发生一些改变了。

最大的调整在于，在绝大多数业务系统里，我认为可以把对单元测试的执念放低，把精力更多迁移到集成测试或接口测试上。这里的原因很简单，因为 AI 实在是太会改代码了，在几分钟就能输出大块大块的代码，如果有一堆单元测试，势必会造成很多测试都失效，而且 AI 自己给自己的代码写的单元测试，很难保证能有什么用。

接口测试不一样，我们可以把测试当成一个一个的产品功能或者说故事：

  • 功能稳定性得以保证，不管 AI 怎么发挥，就算它还避免不了一些低级错误，只要基本的故事是通的，不至于出现大的问题
  • 维护成本较低，对于后端开发来说，除非预期中，我们很少会破坏现有的功能；接口测试一旦写好，不管代码细节怎么改，接口行为不能改变
  • 降低沟通成本，这个测试文件甚至可以作为前后端联调的文档，通过这个文档后端可以告诉前端该怎么使用这些接口，参数和返回值的预期是什么

推荐一个 HTTP 测试工具叫 HURL ，谁用谁知道

Code Review⌗

大厂里面，代码 Review 是一个永恒的问题，所有人都希望有人 review 他的代码，所有人都不愿意 review 别人的代码。这里最主要的原因在于，reviewer 作为不是写这份代码的人，很可能不了解需求或者代码库的细节，所以往往只能找找变量命名之类的错误，或者提一些代码组织上可有可无的变动，很难给出实际有效的建议。

AI 就不一样了，只要你开口，他可以孜孜不倦地帮你 review，并且如果你想，他还甚至直接给你把问题修复了，它不怕麻烦，也不怕承担责任（虽然它也不承担）。体感上，AI reviewer 给提交代码的人感觉不是一个”挑刺者“，而是一个帮我们减少问题的好伙伴。

目前市面上做得好的 code reviewer 不多，包括很多大厂做的工具。但是这里不得不夸一夸 OpenAI 的 Codex，不管是本地 review，还是和 github 集成的工具，都非常有效，真的能发现各种实际的问题，除了慢没毛病。

我相信 2026 年 code review 会变得越来越成熟可靠，和开发流程的结合也会越来越紧密，毕竟”资深程序员“都知道提交代码之前自己先 review 一遍。

单体架构⌗

微服务架构过去几年已经一定程度上被祛魅了，随着新一波 AI 公司的兴起，以及 AI 编程的发展，我觉得单体架构会重新变得伟大。这里面主要有这样几个原因：

  • 从 AI 编程的角度，单体架构能更好地让 AI 了解整个系统的上下文，避免各种微服务像魔法一样封装了各种不确定的行为，让 AI 只能靠猜。当然组织良好的微服务或者接口能一定程度上缓解这个问题，但是这会牵涉到第二点
  • 从维护的角度，单体架构维护成本较低，只要配置好一套 CI/CD 流程，所有人都可以共享，Devops 的投入相对很少。并且开发的维护成本也比较低，如果是微服务想变个接口，还需要各种上下游协调，长期下去接口会变的臃肿和混乱

其实说到底微服务更多是团队组织上的需求，因为公司拆出来了各种团队，团队间为了有一个清晰的边界，所以服务也需要定义边界。AI 编程的普及首先会让公司对于团队规模的需求极度缩小，在不需要这么大团队规模的前提下，微服务的必要性就没那么高了。

可观测性⌗

这个方向不知道什么原因，看到的相关新闻不多，但是我觉得是一个很好的方向。跟上面提到的代码 Review 类似，可观测性是系统上线后运维很重要的一部分。

目前我觉得机会很多：

  • 过往监控系统最为人诟病的就是误报和漏报，一方面是因为监控规则实在晦涩难写（bosun 谁用谁崩溃），另一方面静态规则实在难以适应线上不断变化的场景，所以很多大厂做的“智能监控”实在很难称得上智能。
  • 另外接入这些监控系统的门槛也不低，metrics 怎么打点，日志怎么格式化，这些长期需要占据研发很多心力
  • 最后线上的问题往往是架构迭代方向的重要指导，过去往往是线上出事故了再来复盘，如果有 AI 能长期盯盘，防患于未然，那么 AI 又离“资深程序员”更进了一步 随着这一波 AI 应用的野蛮生长进入稳定期，系统可观测性和服务稳定性一定会进入舞台中央，这一块的创业者们准备接受洗礼吧。

慢就是快⌗

其实软件开发还涉及到很多其他方面，篇幅太长就写这些吧。最后想写一点，就是关于快与慢。

大模型跟过往工业革命一样，好像把世界变小了，时间变快了。一个最明显的例子，仅仅是过去几个月发布的模型，效果也不错，过了几个月好像就过时了一样。包括媒体上或者社区上，也不断会有人说一个周末做出了什么应用，一个月发布好几个版本，以及不到一年就数十亿美金卖了。所有的东西看起来都那么快在变化，如果不去学就跟不上了。 作为浩瀚宇宙一个渺小的个体，我们应该如何自处？

我的建议，不要把自己变成别人的生意！不要以为点进去一条 twitter 看看也没什么，不要总在抖音浪费 15s，不要只看到“美颜”后的光鲜，要去看背后的真相。不管看到什么，先问问自己，我为什么看到这个信息？他为什么发这个信息？这个信息对我的影响是什么？这个信息对他的价值是什么？学会这个真的很简单吗？不学这个真的影响很大吗？

我想变成一个什么样的人？

没有什么毫无道理的横空出世。如果你觉得别人随随便便就成功了，那是因为你不了解他人在背后的积累和付出。在这样一个快速发展和变化的时代，我们反而应该慢下来思考、学习和沉淀。

多年以后，当你再面对黑色屏幕上闪动的白色光标时，你便会想起那个遥远的2026。那时，各种技术和工具层出不穷，人们兴奋地看着每天爆出来的新闻，指指点点。