AI 时代编程学习必要性探讨

近期，一个话题被频繁提及。

几乎每隔数日，便有人在评论区或私信中询问：如今代码皆由 AI 完成，是否还有学习编程的必要？

不仅新人有此疑问。许多有数年经验的程序员也感焦虑，他们发现团队中已有人开始使用 Cursor、Copilot 快速生成代码，效率惊人，于是开始担忧。我这编码速度似已跟不上 AI，这饭碗还能端多久？

此问题，我也深思良久。

因我正是那个「用 AI 写代码但又不完全交给 AI」的人。我日常主要使用 IDEA，大部分时间并非在与 AI 聊天以生成整段代码，而是使用代码提示。写到一半，AI 猜测我欲写内容，助我补完下一行或下一方法。此感觉如同，你知欲言何物，旁坐一打字迅速但偶有错字之助理。

坦白而言，此体验甚佳。确实快了许多，尤其是一些重复性代码，如 getter setter，几乎刚想到，手未动，AI 已为你写就。

但问题即在此处。

一次我写微服务接口，需对接一已有内部框架，此框架有其注解规范、异常处理模式、日志打印格式，皆为团队数年沉淀之物。我将需求丢给 AI，其为我生成一整套代码，Controller、Service、Dao 俱全，看似有模有样。

然后我发现，糟糕。

注解用的是 Spring 原生，但我们团队自己封装了一套。异常捕获方式不对，日志格式与项目其他模块不一致。底层调用方法名为其自编，数据库根本无此字段。怎么说呢，其生成代码，与项目画风完全不合。。。= =

非说代码本身有语法错误。语法是对的，逻辑也能跑。但就是不符合规范。就像一刚入职新人，看了两天 Spring 教程就开始写代码，写的都对，但跟你团队的习惯完全对不上。

我当时就把那堆代码删了大半，只留了几个工具方法的骨架，剩下的全部自己重新写了一遍。

此事让我想明白了一件事。

AI 生成的代码，最大问题不是「不对」，而是「不对味」。

其能写代码，但不知你项目上下文。其不知你们团队约定俗成的写法是什么，不知你们用了哪个版本的内部依赖包，不知你们的架构演进到了哪个阶段，不知你们最近刚重构完哪部分不能乱动。

这些信息，不在其训练数据里。在人的脑子里。

故我越来越觉得，编程这件事的核心能力，正在发生一个很微妙但也很根本的转移。

以前我们说「会编程」，指能自己把需求翻译成代码，一行一行写出来，能调试、能优化。此能力当然还在，但它不再是唯一的入场券了。因 AI 确实帮我们分担了很大一部分「翻译」和「拼写」的工作。

现在真正值钱的能力是什么？

是能审 AI 的代码。

是 AI 给你生成了一段代码，你能在几分钟之内判断出来，这段能不能用，哪里需要改，改完之后对整个项目有没有副作用，跟已有的代码会不会打架。

此事，不懂编程的人做不了。

举个最简单的例子。AI 给你生成了一段数据库查询的代码，看着没问题，但你一眼就能看出来它用的是全表扫描，生产环境跑起来肯定炸。你不懂 SQL 执行的原理，不懂索引是怎么回事，这一段你就审不出来。代码上线了，某个深夜你被报警电话叫起来，发现数据库 CPU 飙到 100%。

那一刻你就会知道，会审代码，比会写代码重要得多。

我有时候觉得，「会审代码」这件事，有点像古代的校对官。书不是他写的，但他必须能看出来这本书哪里抄错了、哪里漏了一段、哪里的用词不符合当时的规范。这个权利和责任，比写书的那个人还大。

代码出了事，AI 不背锅。你背。

所以回到最开始的那个问题，代码都让 AI 写了，还要学编程吗？

我的答案是，当然要。

但学的东西变了。

你不需要把所有的 API 都背下来，不需要记住每一个框架的配置细节，这些东西 AI 比你知道得多。但你必须能一眼看出一段代码的架构对不对，能判断这个设计方案有没有坑，能理解你们项目的上下文并且确保 AI 生成的代码契合这个上下文。

这些能力，不是看几篇 Prompt 技巧文章就能掌握的。它是你在真实的项目里一行一行写过来、改过来、踩过坑之后，沉淀下来的东西。

是那种「我一看这段代码就觉得不太对劲」的直觉。

AI 给你不了这个直觉。这些年的积累，是你审 AI 代码的底气。

说到项目规范和上下文这件事，我其实特别想再展开聊聊。

很多人觉得 AI 写代码不行是因为模型不够强。不是的。Claude 很强，GPT-4o 也很强。但你让它去写你们公司内部那个维护了五年的微服务系统的新模块，它写出来就是会翻车。

为啥呢？

因为你那个项目里的很多东西，是「人传人」的隐性知识。

你想想看，你们的代码规范可能在 Confluence 上有一份文档，但那文档已经两年没更新了。真正有效的规范，是你们团队在做 Code Review 的时候口口相传的。「这块别用那个工具类，用我们自己封装的」「这个字段的命名要跟前端对齐」「这个接口的返回值格式参考一下 XX 模块的写法」。

这些东西，AI 看不到，它没办法。

所以你会发现一个很有意思的现象。越是标准化的、通用的代码，AI 写得越好。比如一个独立的工具函数、一个单纯的数据处理脚本，AI 写出来基本不用改。但越是跟具体项目耦合深的业务代码，AI 写得越离谱。

微服务代码尤其明显。

我之前试过让 AI 帮我生成一个微服务模块，它生成的调用链、熔断配置、消息队列的使用方式，跟我们项目里实际用的框架版本都对不上。不是说它不会写微服务，而是我们这个项目用的是一套两年前选型的方案，市面上最新的教程和文档讲的是另一套。

AI 学的是互联网上的通用知识，你项目里的是特定版本的特定方案，中间差了两年。这两年的差距，就是一堆编译错误和运行时的诡异 bug。

这时候谁能救？只有你自己。你懂这个项目的来龙去脉，你知道当初为什么选了这套方案而不是那套方案，你知道哪个服务是敏感的不敢随便动，你知道哪段代码是老张离职前写的那个坑。。。？？？

这些，都只有你知道。

说真的，我是真的觉得，AI 写代码这件事，看起来是在「降低编程的门槛」，但实际上它是在「提高编程的质量要求」。

以前你能写出来就行，代码丑点慢点都无所谓。现在不行了，因为 AI 能写得比你快还比你好看，你在「写」这个维度上已经没有竞争力了。你的竞争力转移到了「审」和「改」上面，而「审」和「改」需要的能力，比单纯的「写」要高。

你得懂架构，懂设计模式，懂性能优化，懂安全规范，懂项目的上下文。你不但要能看出 AI 写的代码哪里不对，还要能准确地告诉它怎么改，或者干脆自己动手改。

这不是入门级的能力。这是高级工程师的能力。

所以每次有人问我「AI 时代还要不要学编程」，我都想反问一句，你打算学到什么程度？

如果你想学到「能跑就行」的程度，那 AI 确实可以帮你省掉这一步。但如果你想要的是「能审、能改、能负责任」的程度，那你该学的东西一个都不能少，甚至要学得比以前更深。

因为你的对手，从一个不会写代码的自己，变成了一个写代码很快但经常出错的 AI。

你得比它更懂。

我觉得还是挺重要的，想明白这件事。

因为在未来很长一段时间里，编程都不会是「把需求丢给 AI，代码就出来了」这种魔法。至少在复杂的企业级项目里不是。它更像是一个协作的过程，AI 帮你完成 70% 的体力活，你用你的经验和判断力去审那 70%，补上剩下的 30%，确保最终产出的代码符合你项目的规范、满足你业务的场景、经得起生产的考验。

这 30%，才是你不可替代的价值。

而能补上这 30% 的能力，就是你现在去学编程的意义。

不是为了比 AI 写得快，是为了比 AI 懂得多。

不是为了替代 AI，是为了驾驭 AI。

这种事可能没法速成。但那个「一看到代码就觉得不太对劲」的直觉，那些在一个个项目里磨出来的判断力，那种对自己项目的上下文了如指掌的底气。

这些，才是 AI Coding 时代，一个程序员真正的护城河。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。