当 AI 写代码比你快的时候，程序员到底该焦虑什么

不卖课、不贩卖焦虑、不搞成功学。这是一篇关于 AI 编程工具的长文，聊聊我看到的真实变化，以及一些可能没用但诚实的判断。

先说个事

上个月我们组来了个实习生，入职第一天就用 Cursor 写完了我给他的练手需求——一个不算简单的 CRUD 接口，带参数校验、异常处理、单元测试，整套。我当时看了他的 commit，说实话，心里咯噔了一下。

不是因为他写得有多好（代码本身也就中规中矩），而是因为他用的时间。我原本预估这个需求至少要两天，他一个下午搞完了，中间还问了我两次业务逻辑。

这种事搁在三年前，你得是个写了三五年代码的老手才能做到这个速度。现在一个实习生可以了。

所以问题来了：当 AI 把"写代码"这个动作的门槛拉到这么低的时候，程序员到底该焦虑什么？

我先给个不那么讨喜的答案：该焦虑的不是 AI 会不会替代你，而是你有没有搞清楚自己到底在做什么工作。

AI 编程工具的真实体感

我自己用了差不多两年的 AI 编程辅助，从最早 GitHub Copilot 的 tab 补全，到后来的 Cursor、Windsurf，再到最近试的 Claude Code 和各种 MCP 集成的方案。说几句掏心窝子的话。

好用的场景是真好用。 写一些样板代码——比如类型定义、JSON 解析、正则表达式、测试用例——AI 简直是神兵利器。以前写个 email 正则能折腾半天，现在一句话搞定。数据库迁移脚本、Dockerfile、CI 配置，这些"不难但烦"的东西，AI 帮你干掉的效率提升是实打实的。

难用的场景也是真难用。 但凡涉及业务逻辑稍微复杂一点的——多个实体之间的关系、异步流程的状态管理、性能敏感的路径优化——AI 给你的代码经常是"看起来对但跑起来一堆坑"。你得花更多时间 review 和 debug，有时候还不如自己从头写。

我印象最深的一次，让 AI 帮我写一个并发控制的模块。它给了一套看起来很优雅的方案，用了好几个设计模式，代码结构也漂亮。我当时差点就直接合了。还好多了个心眼，跑了一下压测，发现高并发下有竞态条件。修了两个小时才修好，比自己写多花了一倍时间。从那以后我就学乖了——AI 写的并发、分布式、性能敏感的代码，必须严查。

我身边有两类人用 AI 编程工具的方式截然不同。

第一类人，每天对着 Cursor 疯狂 prompt，产出量翻倍，但质量不稳定，经常需要返工。他们觉得自己在"驾驭 AI"，但其实大部分时间花在了跟 AI 聊天上——"这个不对""换个方案""再试试"。说白了，他们把 AI 当成了一个需要不断沟通才能出活的初级工程师。

第二类人，只在特定场景用 AI——写测试、生成初始框架、查文档、理解别人的代码。他们把 AI 当成一把趁手的锤子，该用的时候用，不该用的时候放下。

你猜哪种人最后代码写得更好？

对，第二类。

这不是因为第一类人不够聪明，而是因为他们犯了一个认知错误：把"写代码的速度"等同于"解决问题的速度"。这俩根本不是一回事。

真正该焦虑的三件事

行了，不说废话了，直接说我觉得程序员真正该关注的东西。

第一，别再当"翻译机"了。 过去十年，很多程序员的工作本质上是"把产品经理的需求翻译成代码"。需求文档拿来，拆成任务，一个个实现。这个工作模式正在被 AI 严重侵蚀——因为翻译恰好是 AI 最擅长的事。

你给 AI 一段需求描述，它真的能给你吐出一段像模像样的代码。不是每次都好用，但方向是对的。如果你的价值就是"我能比 AI 更准确地把需求翻译成代码"，那你确实需要重新想想自己的定位。

这不是说你不需要写代码了，而是说光会写代码已经不够了。你得能理解需求背后的业务逻辑，能判断方案的可行性，能识别那些"看起来对但跑起来一堆坑"的陷阱。这些东西，目前的 AI 还真不太行。

第二，系统思维比 coding 能力更重要。 我见过太多技术能力很强但写出来的东西一塌糊涂的程序员。不是他们代码写得不好，而是他们没有站在系统的角度想问题。一个接口设计得漂亮，但放在整体架构里是冗余的；一个方案短期能 work，但三个月后会变成维护噩梦。

AI 编程工具放大了这个问题。以前你写代码慢，所以你会花更多时间想清楚再动手；现在有了 AI，你可以在还没想清楚的时候就开始写，结果就是一堆垃圾代码堆得更快了。

如果你之前就具备系统思维，AI 是倍增器；如果你之前就缺这个，AI 只会让你更快地制造技术债。

第三，沟通和协作能力正在变得更值钱。 这一点可能有点反直觉。不是说技术不重要了，而是当"写代码"这个环节的效率被 AI 提升之后，你在整个软件开发流程中的瓶颈就转移了。

以前瓶颈在"把想法变成代码"，现在瓶颈在"把业务问题变成正确的需求"、"把多个系统集成在一起"、"让团队对技术方案达成共识"。这些全是沟通和协作的事。

我最近在项目里碰到的一个典型场景：业务方想要一个"智能推荐"功能，需求文档写得很模糊。以前我会直接开始做，因为反正需求改来改去是常态。现在我会先拉着业务方、产品、数据团队开一轮会，把"智能推荐"到底是什么意思、用什么数据、边界在哪里、什么算成功，全部聊清楚。

为什么？因为我知道 AI 可以帮我把代码写出来，但它没法帮我在需求阶段就把方向搞对。方向错了，写得再快有什么用？

几个我正在用的习惯

说了这么多焦虑和判断，也聊聊我在实操中的一些调整。不保证有用，但确实让我的工作方式变了不少。

写代码之前先写 prompt。 这个习惯听起来有点搞笑，但真的有用。现在接到一个需求，我会先写一段自然语言描述——不是给 AI 的 prompt（虽然有时候确实会用），而是给自己理清思路用的。当你能把一个功能用自然语言准确描述出来的时候，你对这个功能的理解就已经够深了。

AI 写的代码，默认不信任。 这个原则帮我省了很多时间。AI 生成的代码，我会默认它是有问题的——不是因为 AI 不行，而是因为如果你默认它是对的，你就会跳过 review，然后在测试阶段踩坑。与其这样，不如一开始就带着怀疑去看。

把"会不会用 AI"从能力考核里拿掉。 这点可能得罪人，但我真的觉得不应该把"熟练使用 AI 工具"作为程序员的核心竞争力。就像你不应该把"熟练使用 IDE"作为核心竞争力一样。工具是锦上添花的事，用得好的确省时间，但用不好也不代表你不行。真正重要的是你能不能解决问题，而不是你用什么工具解决问题。

定期"裸写"代码。 这是我最近开始做的一个实验：每周至少有一天，完全不用任何 AI 辅助，纯手写代码。目的不是自虐，而是保持手感。你不能让自己的"编码肌肉"退化，否则当 AI 工具出问题（服务器挂了、网络不好、模型降级）的时候，你会发现自己写不出东西来。

还有一个习惯是"用 AI 学，不用 AI 做"。碰到新技术栈，我会让 AI 给我讲解核心概念、对比不同方案、生成学习路径。但真正动手做的时候，我尽量自己来。因为学东西的过程本身就是价值，跳过了这个过程，你只是"会用"，不是"会了"。这两者的差距，会在你碰到边界 case 的时候暴露出来。

一些不那么流行的观点

最后说几个可能会引起争议的想法，纯个人观点，不同意没关系。

AI 不会让程序员失业，但会让"只会写 CRUD 的程序员"更难找工作。 这不是什么新观点，但值得再说一次。如果你的日常工作就是写增删改查、调 API、搬砖，那你确实需要加速升级。不是因为 AI 会取代你，而是因为会用 AI 的同行会取代你。

"Prompt Engineer"这个职位大概率会消失。 我不觉得"跟 AI 对话"是一种需要专人来做的技能。就像当年"会用 Google"也是一种技能，但现在没人会把"搜索能力"写进 JD 一样。写 prompt 会变成每个程序员的基本功，而不是一个专门的岗位。

AI 最大的价值不是写代码，是学东西。 我现在学新技术的第一步不是看文档，而是让 AI 给我讲。"帮我解释一下 Rust 的所有权机制，用我熟悉的 TypeScript 做类比"——这种提问方式的学习效率比读文档高太多了。AI 是你专属的、不知疲倦的、什么都知道的老师，这个价值可能比它帮你写代码更大。

AI 编程工具会让代码同质化。 你有没有发现，AI 生成的代码风格越来越像？都是一样的命名习惯、一样的代码组织方式、一样的错误处理模式。这在短期内不是问题，但长期来看，技术栈的多样性会下降。当所有人都用同一种方式写代码的时候，那些"不合常规"但有效的解决方案就更难出现了。

行了，不灌鸡汤了。

说到底，AI 编程工具就是个工具——一个非常厉害的工具，但本质上跟你的 IDE、你的终端、你的搜索引擎没有区别。它能帮你更快地到达目的地，但没法替你决定要去哪里。

程序员最该焦虑的，从来不是"AI 会不会取代我"。而是"我有没有在做真正需要人来做的事"。

如果你每天的工作就是在 AI 的帮助下写越来越多的代码，但从来不想这些代码到底解决了什么问题——那确实该焦虑。反过来，如果你能把 AI 当成加速器，把省下来的时间用在思考、判断、沟通这些更难被替代的事上——那你不但不该焦虑，甚至还该偷着乐。

毕竟，工具越强，用工具的人越重要。