当开发者把 AI 当作 Black Box 时到底会发生什么
Source: Dev.to
请提供您希望翻译的具体文本内容，我将把它翻译成简体中文。
隐藏的 AI 生成代码的认知债务
我看到一位有才华的初级开发者花了 四个小时 去修复 AI 生成的代码在我们的结账流程中引入的一个 bug。并不是因为代码特别复杂，而是因为他 根本不知道它到底在干什么。
- 他是从 ChatGPT 直接复制粘贴的。
- 代码看起来合理，代码审查通过，且在开发环境中可以运行。
- 然后它在生产环境中悄悄损坏了客户数据，持续了三天才被人发现。
当我让他解释逻辑时，他说不出来。并不是因为他不聪明——他很出色——而是因为他 从未真正阅读过这段代码。他把 AI 当成自动售货机：投放问题 → 获取答案 → 继续前进。
这是一种没人谈论的新技术债务。
不是代码本身，而是 开发者将理解外包给黑盒子 所累积的 认知债务。
为什么 AI 生产力叙事是错误的
- 没有理解的高速度并不是生产力，只是速度而已。
- 在过去一年里，我看到这种模式在数十位开发者中反复出现。
- 他们使用 AI 工具生成代码，比以往更快。
- 拉取请求激增，速度指标飙升，管理层对此很满意。
- 六个月后，没人能维护代码库，因为没有人真正理解任何东西是如何运作的。
代码甚至并不糟糕——往往相当不错。问题在于 架构。当你把 AI 输出当作神谕式的宣告，而不是理解的起点时，你会创建只能 AI 自己解释 的系统。AI 虽然能力强大，但对以下内容没有上下文：
- 您特定的业务逻辑
- 您团队的约定
- 几个月前做出的决定，这些决定塑造了当前的结构
您变得依赖这个黑箱来维护它所创建的东西。
使用 AI 的两种方式
| 方法 | 结果 |
|---|---|
| 加速理解 | AI 充当思考伙伴。你会获得解释、权衡分析以及加深你知识的洞见。 |
| 避免理解 | AI 变成你从不质疑的代码生成器。你交付更快，却失去深度，变得可以被取代。 |
与 AI 的正确关系
- 要求解释，而不仅仅是可运行的代码。
- 逐行阅读生成的代码，质疑每一个假设并验证边缘情况。
- 在开始编写之前使用 AI 来构建思路，而不是让它为你撰写文档。
- 利用代码解释器来了解为什么选择了某种方法以及存在哪些替代方案。
AI 加速学习而不取代学习本身。
认知债务黑箱的产物
- 不使用的技能会丢失。 这不是民间智慧，而是神经科学的结论。
- 将问题求解外包给 AI 而不亲自参与解决，会导致核心工程能力的 退化：
- 对算法复杂度的推理
- 捕捉细微 bug 的能力
- 理解性能影响的能力
我看到中级开发者在大量使用 AI 的六个月后变得能力下降。他们在 提示工程 上变得流利，却失去了 真正的工程 流利度。他们能够把问题描述得足够清晰让 AI 解决，但却无法验证这些解决方案是否正确。
讽刺的是，这种工具本应提升他们的生产力，却让他们更依赖它。 他们获得了速度，却失去了深度。他们可以更快地交付功能，却在出现问题时无法进行调试。
调试循环陷阱
当 AI 生成的代码出现故障时，你无法让 AI 说明 在你的具体部署和具体数据下 出了什么问题。你可以请求修复方案，但如果不理解最初的意图，就无法判断这些修复是否解决了根本原因，还是仅仅在打补丁。
典型循环：
- 使用 AI 生成代码。
- 代码在生产环境中失败。
- 将错误信息复制给 AI。
- AI 提出修复建议。
- 在未理解的情况下应用修复。
- 出现新错误 → 回到第 3 步。
每一次迭代都会向代码中加入更多 AI 生成的补丁，而这些补丁没有人真正理解。系统变得越来越脆弱、难以理解，最终被迫 重写——而这需要真正的理解，而黑箱式的方法从未培养出这种理解。
不可避免的现实：面试
- 面试仍然在考察 实际的工程能力。
- 你可以在副项目、带回家的作业，甚至行为面试准备中使用 AI，但 白板或现场编码面试 会让你独自面对问题。
这时认知债务就会显现。面试官并不是在寻找死记硬背的答案；他们在评估你的能力：
- 实时思考问题
- 阐述权衡取舍
- 识别模式
- 随机应变
如果你把这些思维肌肉外包给了 AI，你会感受到差距。
结论
AI 是一个强大的盟友，当它用于augment理解，而不是取代它时。把它当作一个thinking partner，帮助你结构化、解释和探索，而你保留逻辑和架构的所有权。否则，你将面临隐藏的cognitive technical debt，这会侵蚀技能，阻碍可维护性，最终削弱 AI 所承诺的生产力。
问题
把 AI 当作 黑盒 的开发者会发现——为时已晚——光有令人印象深刻的 GitHub 活动并不能转化为面试表现。他们无法解释自己构建的系统，因为他们根本没有真正构建过；他们只是拼凑了自己不理解的组件。
市场仍然更看重 理解胜于拼装。
为什么忽视问题无济于事
- 回避 AI 工具既不切实际也愚蠢。
- 正确使用时，AI 加速开发。
- 真正的问题在于与 AI 输出的 关系，而不是工具本身。
与 AI 建立更好的关系
- 将生成的代码视为对话的起点，而不是最终答案。
- 当你使用 Crompt AI（或任何 AI）来解决问题时：
- 提出后续问题。
- 请求解释具体的实现选择。
- 让 AI 拆解复杂的部分。
- 使用 Research & Analysis 功能来了解所建议模式的更广泛背景。
- 在信任之前，让 AI 先解释自己。
如何处理生成的代码
- 阅读生成代码的每一行。
- 不仅仅是验证语法（容易的部分），更要验证逻辑。
- 自问：
- 它是否正确处理了边缘情况？
- 在高负载下会怎样？
- 它如何与系统的其他部分交互？
- 对数据结构或用户行为有哪些假设？
- 当某些内容不清晰时，抵制直接接受并继续的冲动。
- 使用 AI Tutor 功能进一步拆解。
- 目标是扩展自己的理解，以便下次能够自行编写类似的代码。
AI 使用的悖论
“最需要 AI 工具的开发者，恰恰是应该最少使用它们的——或者说，他们应该以完全不同的方式使用它们。”
对初级开发者
- AI 可以 加速学习，但前提是你 抵制跳过学习环节。
- 每一段 AI 生成的代码都应该是 学习的机会，而不是捷径。
- 将查找语法节省下来的时间投入到 理解模式 上。
对高级开发者
- AI 应该让你 更快实现已经理解的方案。
- 让它处理样板代码，而你专注于 架构和业务逻辑。
- 如果你依赖 AI 来解决自己无法解决的问题，那就是在用自动化 掩盖技能缺口。
黑盒开发的隐藏成本
- 成本不会体现在冲刺速度或功能完成率上。
- 当有人需要修改系统时，几个月后才会显现出来，发现没有人理解它是如何工作的。
黑盒代码库的症状
- 风格一致、格式整洁、模式合理——但没有连贯的架构。
- 每个组件单独看起来都不错，但在整体上下文中毫无意义。
- 函数为实际使用场景而过度设计。
- 错误处理不一致。
- 性能特性不可预测。
代码读起来像是由一个对编程有一般了解但对这个特定程序不了解的人写的。AI 把握的是通用模式，而不是你的具体需求，开发者从未建立起维护所需的整体理解。
未来展望
AI 工具不会消失；它们正变得 更好、更集成、更强大。
能够蓬勃发展的开发者：
- 阅读并理解每一段生成的代码。
- 利用 AI 加速学习，而不是跳过学习。
- 把 AI 输出视为思考的起点，而非终点。
- 构建能够向初级开发者解释的系统，即使这些系统部分由 AI 编写。
- 保持核心工程技能，这些技能将工程师与“装配工”区分开来。
没有理解的速度，只是 带有速度问题的未来技术债务。
可操作的要点
- 积极使用 AI，但 绝不要合并你不理解的代码。
- 未来的你——在凌晨 2 点调试生产环境时——会感激你的。
准备将 AI 作为 思考伙伴 而不是黑箱使用吗？免费试用 Crompt AI——生成的代码伴随理解，而不仅仅是结果。