工程师怎么保持对 AI 的正确态度——不盲目崇拜也不排斥

适读人群：正在使用或考虑使用 AI 工具的工程师 | 阅读时长：约10分钟 | 核心价值：用真实案例说清楚两种极端态度的代价，以及什么是真正有效的使用心态

去年我们公司有两个工程师，我在心里把他们叫做"AI 信徒"和"AI 保守派"。

先说 AI 信徒，叫小王。他在 AI 出来之后基本把自己的判断力外包出去了。有次他在 Review 一段数据库操作的代码，我问他"这里为什么不加事务"，他说"AI 帮我写的，应该没问题"。我问他"AI 说加不加事务了吗"，他说"没说，但 AI 应该考虑到了吧"。

结果那段代码上线后，在并发场景下出现了数据不一致，查了半天才找到根源。

再说 AI 保守派，叫老李。他对 AI 工具的态度是：我二十年写代码都过来了，不需要这玩意。他的理由听起来也不是没道理："AI 写的代码我不放心，我得自己写。"问题是他的"自己写"里有一半时间花在搜 Stack Overflow，还有一部分时间花在手写样板代码。他每天在 IDE 里敲着几十年前就有的 Java boilerplate，效率比同组的年轻人慢了一大截，项目排期被拖。

这两个人，一个因为 AI 犯了不该犯的错，一个因为拒绝 AI 成了团队的瓶颈。

我观察了不少人，两种极端的背后，其实是同一个根源：没搞清楚 AI 工具是什么，以及自己的价值在哪里。

"AI 信徒"的具体危害

AI 信徒的问题，不在于"用 AI 多"，在于"把自己的判断替换成了 AI 的判断"。

我总结了几个具体的危害场景。

危害一：对 AI 的错误失去感知

AI 有一个特点：它犯错的时候，表现得和它答对的时候一样自信。

如果你习惯了"AI 说的就对"，你会逐渐丧失对错误的警觉性。有一次我看到一个同事用 AI 生成了一段 Spring Security 的配置，AI 给的代码是旧版本的写法，在新版本里已经被弃用且行为不同。他直接用了，上线后登录逻辑出了问题。他后来告诉我，他根本没去确认过那段代码是否适用于当前框架版本，"因为看起来就是对的"。

危害二：技能退化

这是一个长期危害，短期内不明显。

如果你把所有的算法题、数据结构、设计模式都外包给 AI，你的这些能力会慢慢退化。就像导航软件出现后，很多人的路感变差了一样。路感差了通常只是小事，但工程判断力退化了，出问题的可能是整个系统。

我有个朋友是技术 Leader，去年招人时明显感受到：有些候选人用 AI 把简历和作品集做得很好看，但一到白板题或者深入问设计原理，就原形毕露。AI 帮他们产出了，但没帮他们理解。

危害三：承担不了责任

"AI 写的"不是甩锅的理由，但"AI 信徒"会不自觉地把自己的工程责任感稀释掉。

代码是你署名提交的，bug 是你的 bug，事故是你的事故。AI 是你的工具，不是你的替罪羊。

"AI 保守派"的具体危害

保守派的危害往往更隐性，因为他们通常不会出什么明显的事故，危害是慢慢积累的。

危害一：效率差距越来越大

2023 年 GitHub 发布的一份研究数据表明，使用 Copilot 的工程师在完成特定任务时速度平均提升 55%。这个数字你可以质疑它的方法论，但趋势是真实的。

当你团队里 80% 的人都在用 AI 辅助工作，剩下那 20% 拒绝的人，产出差距会越来越明显。这不是说拒绝用 AI 的人不努力，是单纯的工具效率差距。

危害二：错过了真正的学习机会

保守派通常有一个逻辑：我要自己写，这样才能真正学到东西。

这个逻辑本身没问题，但落地的时候往往走偏。他们拒绝 AI 协助，但同时还在用 Stack Overflow，还在用 IDE 的自动补全，还在抄官方文档的示例代码。这些都是"外部帮助"，和 AI 的本质区别只是形式。

真正的学习，是理解你在做什么，而不是"所有字符都是自己手敲的"。用 AI 生成代码，然后认真理解这段代码在做什么，可以学到东西；自己手写但不理解为什么这样写，学不到东西。

危害三：可能成为团队的阻力

这个说起来有点得罪人，但我在不止一个团队观察到过：当一个资深工程师强烈排斥 AI，他的态度会影响团队其他人，尤其是新人。团队因此形成了一种"用 AI 是不专业"的氛围，导致大家不敢公开讨论 AI 的用法，工具实践也难以推进。

这种阻力，从业务角度看是成本。

正确的使用心态是什么

我不喜欢说教，所以我就说说我自己是怎么用的。

把 AI 当一个很厉害但不了解你业务的同事

这是我觉得最准确的一个心态定位。

一个厉害的外包工程师，你可以给他清晰的需求，他能给你高质量的代码。但他不了解你的系统历史，不知道三个月前的那次重构留下了什么坑，不知道你们有个特殊的业务规则文档里没有写清楚。

用 AI 的时候，我会给它足够的上下文，然后认真看它给我的东西，而不是直接用。这和你用一个外包工程师的结果做最终上线前的检查，是一个道理。

让 AI 做它擅长的，自己做 AI 不擅长的

AI 擅长什么？

• 样板代码（CRUD、配置文件）
• 已知模式的实现（排序、解析、格式转换）
• 文档和注释
• 调试思路提示
• 快速原型

AI 不擅长什么？

• 你们系统的具体业务规则
• 跨越多个文件的设计一致性
• 涉及未来演进方向的架构决策
• 安全敏感场景的判断
• 和你们特定技术债相关的权衡

这么一分，你就知道什么时候全力用 AI，什么时候需要自己主导。

保持"我要能解释这段代码"的底线

这是我给自己定的一条线：任何 AI 帮我写的代码，我必须能向别人完整解释它在做什么，以及为什么这么做。

如果我解释不了，我就不提交。

这条线不是为了证明我比 AI 强，是为了确保我对代码负责，也是为了确保我的工程判断力在持续运作，而不是在萎缩。

对 AI 的输出保持适度怀疑

"适度"这个词很重要。不是说 AI 给什么都要质疑，而是对于关键路径、安全敏感、业务逻辑复杂的部分，要有主动验证的习惯。

我养成了一个习惯：让 AI 生成代码后，追问它"这段代码有什么潜在问题"或者"在什么情况下这段代码会出错"。这个追问往往能让 AI 暴露它自己都知道的边界条件，也能帮我把自己的注意力引导到需要仔细看的地方。

一个具体的例子

给大家看一个我自己的例子，感受一下"适度使用"是什么感觉。

上个月我要写一个限流组件，用令牌桶算法。

我让 AI 做的：

• 生成基础的令牌桶实现代码
• 给我 Redis 实现分布式令牌桶的方案草稿
• 写单元测试的测试用例列表

我自己做的：

• 判断这个场景用令牌桶还是滑动窗口更合适（AI 给了意见，但我做了决定）
• 确认 Redis Lua 脚本里的原子性保证是否满足我们的一致性需求
• 决定限流超出后的降级策略（返回错误还是排队等待）
• 评估在我们当前 Redis 配置下的性能是否可接受

AI 帮我节省了大概 60% 的时间。但整个方案的关键决策，是我做的，我能完整解释每一个选择的理由。

这就是我认为的"正确使用"。

---

有个话我想说直接一点：

AI 工具不会让优秀的工程师变普通，但会让普通的工程师和优秀的工程师之间的差距变得更明显。

真正的工程价值，从来不是你能把代码敲多快，而是你能不能做出正确的判断。AI 提升了敲代码的速度，但判断力这件事，没有捷径。