AI写的代码比我好，我还算程序员吗？

那天我用 GPT-4 生成了一个完整的 API 接口，从签名到测试用例，一次成型，几乎没怎么改。我挺满意的，心里冒出一丝“AI 终于变成我的工具人了”的得意。

结果合并 PR 时，同事在评论区丢下一句：

“你这个分页逻辑，能支持 offset-based 和 cursor-based 吗？大数据量下的性能验证过吗？”

我当场愣了三秒，才想起——我压根没测这些边界情况。

更让我发懵的，不是代码有问题，而是那个瞬间脑子里突然跳出来一个更大的问号：

如果我只是照搬 AI 生成的代码，我还算程序员吗？

真正的恐慌，是身份感正在松动

很多人以为程序员对 AI 的焦虑，是怕被裁、怕没活干。但我越来越觉得，真正让我们不安的，是那种“好像还能写代码，却不确定自己是不是还算程序员”的失落感。

我可以让 AI 一键生成脚手架、配置参数、测试用例，但却越来越讲不清其中的 trade-off 和逻辑推理。debug 本能在退化，对系统的掌控感也在消散。

就像一个朋友说的：“我没失业，但我有点‘失格’。”

以前我们靠“能从零写出正确代码”建立专业自信。现在，AI 生成的代码更规范，命名更整齐，结构更系统，我们却开始怀疑：

我是不是也只是个调 AI 的人？
十年的手感，是不是抵不过一句 prompt？
我还配得上工程师这个 title 吗？

这不是写代码的能力问题，而是身份认同危机：当我们不再是那个“搞得懂、写得出、修得快”的人，我们到底还算谁？

类似的焦虑，其实技术史上出现过很多次。

当 IDE 出现时，老程序员说“真正的高手用 vim”；当 Stack Overflow 火起来，有人担心“复制粘贴会让人丧失思考能力”。但最后我们都接受了工具带来的效率，并在新的规则下，重塑了专业判断力。

所以问题不在于工具强弱，而在于这次的工具进化，速度和深度真的不一样了。

这次不只是工具升级，而是能力外包

我们必须承认，现在的 AI，不只是帮我们写得更快，而是开始“自己写完”。

它能生成带 retry 和超时控制的 Kafka 消费者逻辑，也能一键生成 B+ 树原理的解释图。甚至在你还没完全搞清需求时，它就已经给出三种解决方案了。

我最近用 Claude 写了一个 JVM 性能调优脚本，含 G1GC 参数建议。当它建议我设置

G1MixedGCLiveThresholdPercent

为 45%，我没多想就照做了。但合上编辑器后，我突然意识到：

我根本不知道这个参数是干什么的。

这不就是能力空心化的前兆吗？

就像 GPS 让我们失去方向感，计算器削弱了心算能力，AI 也正在让我们“看起来在写代码”，但实际上只是 API 接口的搬运工。

更糟的是：当 AI 出错时，我们也失去了识别错误的能力。

所以这些底层能力真的不重要了吗？

我的答案是：重要，但需要重新定义重要性的边界。

我们不需要每天都手写快排，但当系统出现性能瓶颈时，我们必须能够理解排序算法的time complexity为什么会影响整体性能。我们不需要每次都从零实现数据库索引，但当查询变慢时，我们必须知道B+树和Hash索引的区别。

换句话说，我们需要保持对底层原理的理解能力，而不是实现能力。
如果连我们自己都不知道什么是"好的解决方案"，如何指导AI给出更好的建议？如果我们失去了对底层原理的理解，当AI给出错误建议时，我们如何发现并纠正？

我们需要的，不是拒绝 AI，而是升级协作方式

我曾经试着完全脱离 AI来找回专业感，比如重新手写红黑树插入逻辑，但发现这种裸机挑战太过极端，无法融入日常节奏。

后来我换了个思路，把 AI 当成协作对象，划分出三种使用方式，既保持效率，也不放弃判断力。

Level 1：AI 工具人

这个阶段，我把 AI 当成能写代码的 StackOverflow。比如：

写一个支持时间范围查询的 Spring Data JPA repository 方法。

它会给出标准写法，我照着集成，再用自己的业务理解微调边界条件。

关键在于：不要直接 merge，而是像 code review 一样审 AI 的代码。看它有没有异常处理、有没有考虑分页性能、有没有线程安全问题。

Level 2：AI 合作者

当我开始让 AI 参与方案设计时，它的价值才真正体现出来。

我会这样 prompt：

我要设计一个用户行为打分系统，需要支持高并发、低延迟、易扩展。请列出3种实现思路，并分析优缺点。

这个时候，我不是在等答案，而是在和它对话，一起构思方案。它给出草案，我用自己的经验改进，然后再反过来提问它逻辑漏洞。

这种来回踢球的过程，很像和资深同事 pairing。

Level 3：AI 指挥者

当我能把一个模糊的问题转化为一组结构化指令，并引导 AI 持续优化结果时，让AI Agent按照我的命令设置好上下文，一步一步的去执行时，我不是在用 AI 写代码，我是在用代码去驾驭 AI。

比如这组 prompt：

我正在做 Kafka 消费者代码的调优。以下是我的现有配置：[贴出配置]。请帮我逐个参数解释含义、性能影响，以及建议的调优方向，并说明你的推理过程。”

它会像助教一样逐个解释：

fetch.min.bytes

如何影响吞吐量，

max.poll.records

与延迟的权衡，甚至指出 JIT 编译下的 deoptimization 风险。

这个过程，不是交出控制权，而是训练自己重新理解原理，并建立对 AI 输出的监督能力。

防止能力退化的保底练习

除了使用分层协作法，我还保留了几种认知训练方式，防止自己彻底变成只会复制粘贴的操作员。

每月花4-6小时做离线练习，直接刷Leetcode的题库（不查 AI，只查文档），保持系统级思考能力。
AI代码的反推练习：对 AI 生成的复杂逻辑（如 Kafka 重平衡过程、消息幂等实现等），强迫自己画出调用图、时序图，倒推出核心机制。
极端场景预演：想象 AI 搞不定的场景（JVM 内存泄漏、GC 触发频繁、死锁等），问自己：这个时候我能不能独立查 dump，能不能自己 debug 出问题？

这些练习不是为了证明自己比 AI 强，而是为了保持那种能在混乱中找到解法的本能。

我们是谁，不由 AI 定义

AI 写得快不等于你不重要。你是否还配得上“程序员”这个身份，也从来不取决于你手敲了多少代码。

我们真正的角色，是提出好问题、做出好选择、发现错误、改进方案的人。

就像产品经理不会因为没画界面就不是设计者，程序员也不该因为少写几行代码就失去专业性。

我们做的不该是抵制工具，而是重塑能力边界、强化判断权力、保持思考惯性。

所以最后我还是回到那句话：

真正的程序员，不是代码的搬运工，而是问题的解决者。

AI 会让我们更快，但不能代替我们“搞懂这个世界是怎么运行的”的好奇心和判断力。

结尾附上几个实用的模版。
三个可以直接上手的AI协作模板

从我的实践中，我总结出三个特别好用的协作模板，既能提高效率，又能保持学习和思考：

模板一：代码审查伙伴

"我需要实现[具体功能描述]，请先分析这个问题的核心挑战是什么，然后给出解决思路，最后再提供代码实现。实现完成后，请从性能、安全性、可维护性三个角度帮我review一遍，指出potential issues。"

这个模板的好处是让AI做完整的思考过程，而不只是输出结果。你能看到它的reasoning，也更容易发现问题。

模板二：技术方案顾问

"我在做[项目背景]，现在需要解决[具体问题]，约束条件包括[性能要求/成本限制/时间限制等]。请给我3个不同的解决方案，每个方案包括：1)核心思路 2)优缺点分析 3)适用场景 4)实施难度评估。不需要具体代码，重点是帮我理清思路。"

这个模板特别适合做pre-research，让你在动手之前就能看清各种选项。

模板三：调试助手

"我的[语言/框架]代码遇到了[具体问题描述]，以下是相关代码[贴代码]。请帮我：1)分析可能的root cause 2)提供排查步骤3)给出修复建议。重要的是，请解释你的推理过程，让我理解为什么会出现这个问题。"

这个模板的重点是解释推理过程，让你学会debug思路，而不只是修复这一个bug。