在一次与供应商的会议中，一切进行得很顺利。突然，对方提出了一个常见的问题：“这个功能是如何实现的？”此时，您陷入了沉默。并不是因为这个问题过于复杂，而是因为这个功能虽然由您负责，却是由AI生成的代码。您只大致浏览过一下，运行也成功了，便交付上线，然后继续了下一个任务。这种情况并非虚构，我亲身经历过。当时虽然没有发生重大问题，但那种“对自己交付的内容缺乏理解”的不安感，非常令人不适。这种担忧是真实且普遍的，尤其是在AI日益渗透我们日常生活中的时候。

如今，我们已经开始高度依赖AI，这种依赖并不是未来的趋势，而是当下的现实。资讯摘要让人省时，作业答疑无需自己思考，定制软件也可以轻松生成。然而，这种便利在某些行为模式上是有隐患的：

1. 阅读了AI的总结后便不再查看原始信息。 2. 接受现成答案而未进行自我思考，导致未能真正学习。 3. 采纳了代码却未理解其内部逻辑，以致问题出现时无从查起。 球友会

对于开发人员或IT从业者，这种依赖最終会带来后果。首先，您对系统运作的理解将变得肤浅。其次，排除故障的能力会下降。最后，您需要维护的代码库可能会成为负担，因为您无法清楚解释其功能。这些问题不会立刻显现，但总有一天会集中爆发。

作为管理者，我也经历过类似的转变。每位从编写代码转向团队管理的人员或许都有相同感受：转为管理后，直接的编码产出减少，技术操作的敏锐度下降。然而，伴随而来的是技能的转变。从架构角度理解系统、提出关键问题，以及判断真正的风险，这些能力逐渐变得重要。您不再是键盘上最活跃的人，却成为拥有更深理解能力的人。值得一提的是，您的旧技能在此过程中常常成为新技能的基础。

对于非技术领域的人士亦是如此。您在专业领域的经验在指导AI产生输出和确保其品质时极具价值。因此，关键并不是减少使用AI，而是确保替代的只是执行任务的物理过程，而非对理解和认知的思考。 球友会

为了避免落入这一陷阱，我将几乎所有编码工作交由AI完成，但我并未感到能力的减弱。我的做法包括：

- 主动要求AI解释其决策。我会不断追问“为什么”。一些提示我几乎每天使用：“请解释到我明天设计评审时能辩护的程度。”还有“考虑了哪些方案又放弃了哪些，理由是什么？”“哪些改动风险最大？”以及“流量增加十倍时，最先崩溃的是什么？”——这些问题不仅能帮助我学习，有时还能显现出潜在的问题。

- 遇到陌生术语时就停下。若一个术语在眼前掠过，您发现无法清晰定义，便应停下来询问AI或进行查阅。这个小习惯虽简单却至关重要，且效果显著。 球友会