最近刷掘金，满屏都是「AI 编程让我效率翻十倍」「我用 Claude Code 三天重构了十万行代码」「不会用 AI 的程序员正在被淘汰」。
说实话，看多了有点审美疲劳。
不是因为我否定 AI 编程的价值------恰恰相反，我是国内最早一批在团队里全面推行 AI 辅助开发的技术负责人。从 GitHub Copilot 到 Cursor，从 Codex CLI 到 Claude Code，我几乎把市面上能用的工具都跑了一遍。
但用了两年之后，我得说句可能不太讨喜的话：AI 编程工具最大的价值，不是让你写代码更快，而是让你更清楚地看到------自己到底哪里不行。
一、写得快不等于写得好
这是我观察到的最普遍的幻觉。
很多开发者用上 AI 之后，第一感受是：「天哪，我一天能写完以前一周的量。」但如果你仔细看这些代码，你会发现一个残酷的事实------速度上去了，但思考的深度下来了。
以前的开发流程是什么？拿到需求，先画流程图，再想数据结构，然后写伪代码，最后才动手。每一步都在脑子里过一遍。现在呢？把需求往对话框里一扔，Tab 键一通狂按，代码就出来了。
看起来天衣无缝。但问题是：
- 你有没有想过，AI 帮你选的那个状态管理方案，在你的数据规模下是否会引发性能瓶颈？它不会告诉你，当用户列表超过一万条时，那个看起来优雅的响应式监听会直接把主线程卡死。
- AI 帮你写的那个并发请求逻辑，有没有处理竞态条件？你兴高采烈地部署上线，结果在弱网环境下，用户看到的页面数据是上一次请求的残留------这种 Bug 你自己写得出来吗？写得出来。但 AI 帮你写的时候，你连看都没看就 Accept 了。
- 那个被 AI 引入的第三方库，你知不知道它上次更新是什么时候？它的 maintainer 是不是一个已经失联三年的大学生？
写得快，只是降低了你犯错的成本，并没有降低犯错的概率。 甚至可以说，它把犯错的概率提高了------因为你不再逐行审查，你开始信任一个你不真正理解的黑盒。
二、代码审查能力的退化，比你想的更严重
这是我团队里真实发生的事。
去年我们招了一个 5 年经验的后端工程师，简历上写了「熟练使用 Claude Code 和 Codex 进行 AI 驱动开发，效率提升 60%」。入职后确实快，需求交付速度在团队里排前三。
但在一次 Code Review 中，我让他审查一段同事写的、AI 生成的鉴权中间件代码。他看了三分钟，说「没问题，可以合」。
我问他：「这段代码里，Token 刷新逻辑有一个时间窗口漏洞，你看到了吗？」
他愣了。然后重新看了一遍，脸色变了。
那段代码确实跑得通，单元测试也过了。但它在 Token 过期前 5 秒发起刷新请求时，如果恰好有一个并发请求用了旧 Token，旧的请求会在新 Token 生效前返回 401，导致用户被意外登出。这是一个典型的并发鉴权竞态问题。
这件事让我意识到一个更深层的问题：
当一个人习惯了被 AI 喂代码，他的代码审查能力会不可逆地退化。因为审查代码需要的不是「看懂语法」，而是「看到代码之外的东西」------并发场景、边界条件、异常路径、安全漏洞。这些恰恰是 AI 最不擅长、也最容易省略的部分。
AI 擅长生成 Happy Path，但生产环境从来不是 Happy Path。
三、真正的资深，是知道什么时候该关掉 AI
用了两年之后，我现在的工作流是这样的：
写 CRUD 模板代码、写表单校验、写那些「我知道怎么写但不想手敲」的样板代码时，Codex 全开、Claude Code 全开。这些代码逻辑简单、风险可控，用 AI 省下的时间是真的。
但在以下场景，我会把 AI 关掉：
- 设计领域模型时。 这是最需要人类判断的地方。你的业务上下文、你的组织架构约束、你的未来扩展预期------这些东西无法被 Prompt 完整描述。让 AI 来设计领域模型，就像让一个不了解你家庭的装修工来设计你家格局------他能给出一个看起来合理的方案，但住进去之后你会发现到处别扭。
- 处理线上故障时。 当生产环境出现一个偶发的内存溢出，你需要的是读 GC 日志、分析堆快照、理解 JVM 内存模型。这时候 Claude Code 帮不了你------它连你的线上环境上下文都不具备，更别说理解你那套运行了三年的遗留系统的各种隐式依赖。
- 做技术选型决策时。 AI 会给你一个「看起来客观」的对比表格，但它的判断基于训练数据里的热度分布，而不是你团队的实际状况。你的团队对 Rust 的掌握程度、你的运维体系能否支撑 Kafka 的复杂度、你的预算是否允许引入某个商业组件------这些只有你自己能判断。
把 AI 当工具用的人，和被 AI 当工具用的人，差距就在这里。 前者知道 AI 的边界在哪里，后者以为 AI 没有边界。
四、我现在面试时最看重的三个能力
如果你来我这里面试，不管你简历上 AI 提效写得多亮眼，我真正在意的是这三件事：
1. 你能不能在没有 AI 的情况下，把一个复杂问题的排查思路讲清楚？
我不会考你背诵 API 签名------那种东西查文档就行。但我会给你一个真实的生产故障场景，问你：从用户反馈到定位根因，你的排查路径是什么？你会看哪些日志？你会做什么假设？你怎么验证？
这道题 Codex 帮不了你，Claude Code 也帮不了你。因为它考察的不是知识储备，而是工程直觉------一种只有在无数个深夜排查线上问题后才能长出来的东西。
2. 你有没有一套约束 AI 产出的工程化机制？
我会问：你的项目里，是如何保证 AI 生成的代码不会偏离团队规范的？你有没有维护一套 Type Definition 约束层？你有没有在 CI 里加 AI 代码的自动化审计？
如果一个候选人告诉我他直接把 Claude Code 生成的代码粘贴进项目就提 PR，那不管他效率多高，我都得犹豫。因为这意味着他的代码库里正在以一种不可控的速度积累技术债。
3. 你能不能看出 AI 代码里隐藏的「沉默债务」？
我会给他一段 AI 生成的、能跑通但有隐患的代码，问他：这段代码里，有哪些东西是正确的废话，哪些是隐蔽的坑？如果这段代码运行两年后出了问题，最可能的故障模式是什么？
能回答这个问题的人，才是真正能驾驭 AI 工具的人。因为他不是在「使用」AI，他是在「审计」AI。
最后
说句掏心窝子的话。
AI 编程工具是好东西，Codex 和 Claude Code 确实让我的团队人均产出提升了一个台阶。但我也看到了一个危险的趋势：工具越强，人越懒；人越懒，判断力越弱；判断力越弱，就越依赖工具。 这是一个会让人温水煮青蛙的恶性循环。
我见过太多开发者，用 AI 的时间越长，越不敢质疑 AI 的输出。不是因为他们信任 AI，而是因为他们逐渐丧失了质疑的能力------当你的肌肉记忆变成了 Tab + Enter，你还有多少机会去真正理解一行代码为什么这么写？
AI 编程工具最大的悖论在于：它最有用的地方，恰好是那些不需要它的人最擅长的地方。 一个能写出高质量样板代码的资深工程师，用 Codex 省下的时间是真省。但一个连样板代码都写不明白的初级开发者，用 Claude Code 只是更高效地制造垃圾。
所以，如果你问我用了两年 AI 编程工具后最大的收获是什么，不是效率，不是产出，而是一个认知：
真正的资深工程师，不是代码写得最快的那个，而是在 AI 给出答案后，仍然会问一句「为什么」的那个。
你们觉得呢？
标签： 前端 后端 AI 编程 职场成长 技术管理