有没有可能，代码的可维护性，本来就是个伪命题？

你好，我是司沐。

从 AI coding 出来之后，我对于它始终是全盘接收的。不过，要说在这个过程中对AI coding的看法始终如一，那也是不可能的。

我对其生态位与看法，其实经历过许多次转变。

从代码补全到宝宝Cursor

在早期 GitHub Copilot 时代（2022年中期，这时候ChatGPT，也就是经历过对话微调的GPT-3.5还没有问世，GitHub Copilot后台接的是GPT-3），模型可以在程序员敲了前半句之后智能地补全出后半句，甚至通过注释补全出一行或多行实际代码。

那时我就认为，这种可以让生产效率翻倍的技术，一定会在将来成为一种主流开发方式。

而到了 2022 年末的 ChatGPT 时代，AI 已经可以一次性生成一个完整的程序脚本，或者某个模块中的部分代码了。我当时的感受是，AI 编程在将来一定会成为每个人都离不开的东西。同时，它也会彻底重塑编程相关的教学模式——因为 AI 让那些简单的代码课后习题变的简单无比，许多学生自然就不愿意深入底层学习了。

值得一提的是，2023 年初，我还碰到了当时才推出没几天的“宝宝版” Cursor，那时候它的 logo 是一个会发光的、有点丑的光标，比现在丑多了。
那会儿，Cursor 还只支持框选修改和对话修改，更重要的是完全免费。我还向几个朋友推荐了它，当时觉得他套壳套的确实很快。不过真的没有想到它可以活到现在，而且发展的这么扎实。

不过在那会儿，我并没有认为 AI 编程能够完全大行其道，因为当时的 AI 在生成超过 100 行的代码时，经常会有各种各样的错漏，和注意力涣散。

工具的演进与开发习惯的重塑

时间来到 2024 年。

年初的时候，谷歌模型还很拉，但 Claude 已经慢慢体现出自己深厚的编程能力；GPT 系列还是在给人们带来惊喜，而不是像现在这样挤牙膏。

这个时候的大模型给我一种很明显的体验：AI 在生成上百行级别的代码块时，已经很难出错了。

于此同时，市面上不少 AI coding 产品已经初步崭露头角。不过由于对早期 Cursor 纯套壳的刻板印象，那时我还是更喜欢用各种提示词工程的技巧，和手动总结项目规范约束的方式，在网页端完成编码工作，然后再手动复制到 IDE 里。

当时有过合作经历的豆包 MarsCode 更加深了我的这种刻板印象，直到后面字节 Trae 问世

到了 24、25 年交际时，DeepSeek V3 的出现让我一改对国内模型代码能力差的印象。

当时我使用 Cline 作为自己的 AI copilot，一开始配的是 Claude 模型，效果很棒但实在是太贵了。而换上 DSv3 之后，我发现它真的几乎可以媲美 Claude 模型的效果。

这个时候，我已经会用 AI 直接接到项目里来实现一些复杂需求了。我的工作状态也从“改代码”，慢慢过渡到了“改提示词”上——毕竟有了 AI 帮忙，很多肉眼能找出来的 Bug 已经懒得手动改了，告诉 AI 哪里错了，让它去改就好了。

过了几个月，字节砍掉豆包 MarsCode，转向 Trae 这款新的 AI IDE 的开发，并做了很重磅的宣传。前期的免费策略确实有很大的诱惑，我就试了一下，感觉编程体验还不错（最重要的是它不像 Cline 一样要花钱），于是就成为了 Trae 的用户。

那段时间也会用到 Cursor，但最终由于用户交互设计上一些不喜欢的点，还是选用了 Trae，它的用户交互很符合我的直觉。

如果不是 Anthropic 全面禁止中国企业使用 Claude 的 API，我可能还会一直就这么做 Trae 的钉子户。但当 Trae 失去了 Claude 后，其他模型的表现真的让人直咂舌——Gemini 模型单次生成效果很棒，但长程注意力经常涣散，而且很容易把自己写自闭；GPT 系列更是几乎不可用，代码能力与项目理解力都比较差。

当然，现在的 5.3/5.4 Codex 版本已经好多了。

所以，我又切回了 Cursor。

此时的 Cursor 好像已经经历过几次用户界面大改，用起来倒还比较顺手。而且它的工程能力也相当强，很明显强过 Trae。即使用 Composer 1.5，也基本可以满足我的日常开发需求；如果换上 Claude，那就更爽了。

发展到这个阶段，AI 会犯的错，已经仅限于任务完成后忘记修改状态机状态、用错各种 Session，以及跨模块的复杂业务没有联动到所有需要修改的点——这些比较高维的问题了。

放弃 Review：属于下一个范式的开发形态

到了这个时候，我的代码 AI 参与率已经超过了 99%。虽然作为旧时代手搓算法代码过来的开发者，我还是会 Review AI 写出的每一行代码，但是遇到问题已经不会自己动手改了，而是告诉 AI 问题在哪，给出解决方案，让 AI 来修。

很反直觉的一点是，我至今没有使用过 Claude Code。因为 CC 不带 IDE 的设计哲学让我感觉对 AI 与代码的管控力被削弱了。作为从“前 AI 时代”过来的开发者，我潜意识里还是比较在意代码效率、架构、算法逻辑这些细节。

不过，变化的日子可能即将要来了。因为我见到一位朋友，使用五六个 CC 终端同步开发需求，几千行代码飞快写出，而她只负责 Review。

既然如此，可能这种基于终端并发的异步开发方式也会是我几个月后的归宿，那为什么不早点尝试呢？或许在四月份，我就会尝试切到这种方式来做开发。

核心探讨：代码的可维护性，是个伪命题吗？

随着 AI Coding逐渐深入软件开发的整个流程，就会引出一个问题 —— 在每日上千行代码的开发量下，Review 整个小组产出的所有代码是一件非常痛苦的事情。

有时我会想，虽然现在自己还是会人工 Review 所有代码，但按现在 AI coding 的发展趋势，以后代码量膨胀到人类无法人工 Review 的地步，似乎已经是必然了。

这就引出了一个非常本质的疑问：有没有可能，代码的可维护性，本来就是个伪命题呢？

仔细想想，为什么我们会有软件工程、设计模式、开发约定、DDD 驱动等等规范？

是因为旧时代的代码生产力太低，人类的大脑工作记忆太有限（只能处理 7±2 个信息块），计算机设备的算力又太弱。

我们必须通过各种架构和抽象，把代码写得“像人话”，让人类在未来的某一天能读懂它。

但在算力饱和、AI 极大加速代码生产力的今天，“可读性”的受众已经变了。

对于拥有超长上下文窗口，并深谙代码之道的大模型来说，它们“拉”出来的那些在过度设计与边界缺失两个极端反复横跳的史山代码，说不定可能真的比人类精心设计的几十个微服务更好理解、更好维护呢。

更别说现在随着更新的 Harness 工程思想发展，AI4Coding方向已经形成了许多开发维护大型项目的方法论，比如DDD，多写文档，使用通用目录结构，反复在上下文中加载卸载代码等等。

还有更重要的一点：在现在正火的 Vibe Coding 趋势下，我们需要的是快速迭代，抢先把想法变为现实。

人类负责提供灵感和业务直觉，而底层的代码逻辑，完全可以交由 AI 去构建和维护。人类不需要看得懂机器码，未来或许也不需要看得懂高级语言。

未来，我们看待代码可能会像现在看待汇编语言一样——我们知道那是底层运转的逻辑，但谁会去逐行 review 编译器生成的汇编指令呢？未来的开发者，维护的将是需求意图、系统架构，项目规范，而具体的代码逻辑，将完全由 AI 来维护、生成、甚至在几秒钟内推翻重构。

代码，将仅仅变成一种人机沟通的“中间态”。我们需要的是快速迭代，抢先把想法变为现实。

当然，对于我们这样的前 AI 时代过来的开发者来说，把史山代码彻底交给 AI 维护，听起来确实非常毛骨悚然。2025 全年，几大 IT 基建服务商依次宕机，波及了全球大量的 IT 业务，很难说这与 AI 深度接手代码没有联系。

但是，看一看各家大厂的裁员潮、职位合并，以及技术的演进方向，这种“毛骨悚然”已经成了我们迟早要接受的现实。

既然这样的未来是历史的必然，那早点接受现实，并拥抱变革，一定是好事。

阵痛期与无限增长的需求

不过，至少在短期来看，大型项目的重构壁垒依然存在。

大量基础的大项目并不容易被 AI 全盘接手，反而是一些中小体量的业务系统，在 AI 的加持下能够极快地产出。虽然二者都是由代码织成的，但它们背后的工程复杂度有着天壤之别。

其实这就像就像管理国家一样：

• 管理千万人口的国家，通常安排好国内一两个长板支柱产业，做好二次分配，再在国际上适当发声就足够了；
  而管理上亿人口的国家，通常要处理地理折叠、贫富分化、多民族或地区发展不均衡问题，需要做基建转移，拥有较为完备的工业体系与出口加工系统。
  这完全是两个范式。
• 同样，管理万行代码（可能只有四五个中间件），十万行代码（十几种中间件，微服务架构，DDD 驱动，熔断与锁），百万行代码（大量中间件，定制化中间件，自动缩容扩容，链路追踪，三方集成）也完全是不一样的开发范式。

现在 AI 可以比较从容地处理万行代码级别的项目；在人的辅助下，也能理解十万行体量的项目；但对于百万行的超大型项目，目前只能辅助人做其中某个特定模块的维护与迭代，完全无法 Handle 全局。

所以，AI 彻底取代开发者，还需要经历几次大型的范式改变，这需要时间进化。

“这是开发者的末日吗？”

那么可能有人会恐慌：这样一来，原本需要 100 个人才能干完的活，现在 10 个，甚至 5 个人就能干完了，这是编程行业的末日吗？

我认为并不是。

不知道你是否听过上世纪 80 年代这一句著名的流言：比尔·盖茨曾说，个人机的内存不会超过 640k，这已经非常够用了。

当然，盖茨曾经多次辟谣，自己并没有说过这样的话，他一直很费解，为什么会有人认为他能说出来这样短视的话

而我们今天个人 PC 的内存已经是 16G 起步，上不封顶，比当时的主流观念翻了不知道多少倍。这是因为一切计算机行业的基础建设都在迭代更新，需求始终在不断增长。

想想看，如果现代的 100 个顶尖程序员，带着当下一切的先进编程工具回到 80 年代，我相信这 100 个人可以维护当时全世界所有的电子信息软件。但这并不意味着 46 年后的今天，就只需要 100 个程序员。

随着更好用的工具出现，也一定会有更难的挑战和需求等着我们去解决。

只要需求增长的速度超过生产力增长的速度，行业就不会走下坡路。

很直观的两个设想：

• 如果人类未来要开发 1:1 模拟的虚拟现实游戏（就像《从零开始》里描绘的那样）；
• 又或者是拥有了星际航行能力，需要为一座几千米长的星际战舰编写中枢系统；

那这些软件的复杂程度与规模会到一个什么量级？恐怕穷尽当下全世界所有程序员的力量，也不一定能把它造出来。更不用说眼下的企业数字化转型，AI赋能，与与此相匹配的一系列数字基建，与AI配套产业的完善了。

这样的大型项目，必然需要 Coding 侧生产力产生断层式的跃升才可以做到，这也是整个人类文明发展路上的必由之路。

历史的尘埃，与个人的选择

所以这样来看，内需是一定会增长的。只是资本市场的波动，可能会让它晚一年、两年、五年或者十年再增长。

这就不是 AI 的问题，也不是整个编程行业的问题了，而是资本主义制度下的世界市场的结构性问题。

所以，真的不用惧怕 AI。因为最终让我们失业的，往往是投机资本、无管制的市场经济，或者其他宏观因素。 即使没有 AI，在这个体系下的世界市场也会因为别的原因出现经济危机。

一个很近的例子：在大模型走入我们生活之前，投机资本主要投资的是元宇宙领域。但作为业内人士，我们完全可以看出，当前人类的硬件和软件水平远远不足以支撑起元宇宙这个规模的产业。

所以，如果大模型当时没有爆火并吸走资本，那当未来元宇宙泡沫破裂时，经济产生的动荡，比现在的所谓 AI 危机还要大得多。

这样来说，或许 AI 产业能在两三年内迅速成长起来，接力并挤掉元宇宙的泡沫，反而是我们的幸事。

如果我们只看表面而一味反对 AI 技术，那就像是工业革命时期的卢德主义者一样——工人们愤怒地砸毁生产机器——这样又有什么用呢？机器并不是原罪。

在好的社会与分配制度下，机器可以解放我们的双手，让我们有更多的时间感受世界；只有在一个充满隐患的分配制度与生产关系下，先进的生产力才会反过来使我们失业、收入减少、工厂倒闭。

软件行业的需求始终在持续扩张。眼下的困境，只是因为 AI 产业让生产力扩张的速度，暂时超过了市场扩张的速度。这中间会有一个迟滞期，而这个迟滞期，正是我们所有从业者必须熬过去的阵痛期。

我们还是要相信，阵痛期一定会过去的。

不过，时代的一粒尘埃，落在每个人身上就是一座山。

个人的力量无法阻止历史的必然，那么能做的，就只有提前准备，拥抱变革，然后静待花开。