AI在编程中：工具还是拐杖？

发布: 2天前 (2026年1月18日 GMT+8 16:53)

15 min read

I’m ready to translate the article for you, but I need the full text you’d like translated. Could you please provide the content (excluding the source line you’ve already shared)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and any code blocks or URLs.

问题：思维外包

说清楚点：我越来越常看到程序员，尤其是新人，面对每个问题时把需求复制到 AI 中，然后粘贴生成的代码。零思考，零理解，零学习。就好像我们正在目睹一种 “思维外包”——问题不再是要解决，而是要委托。

一个老问题，但被放大

这个问题并不是随着 AI 出现的。谁没有在完全不理解的情况下从 Stack Overflow 复制代码？谁没有把一个可行的解决方案直接粘贴到自己的项目中，却没有真正弄清楚自己的版本为什么不起作用？

不理解的复制粘贴问题自编程论坛出现起就一直存在。关键的区别在于，当时的过程里嵌入了 “自然刹车”。

传统流程

阅读讨论线程
了解他人的问题背景
查看提问者与回答者之间的对话
手动将代码适配到你的具体情况

即使最终是复制粘贴，过程中仍然有最基本的认知加工：你必须阅读、解释、适配。

使用 AI 时

我写下问题
收到针对我的特定情况完美格式化的代码
把它粘贴进去

结束。这个循环如此快速流畅，以至于完全绕过了任何形式的思考。

此外，在 Stack Overflow 上你不仅能找到代码，还能看到：

为什么该解决方案有效的解释
评论中的利弊讨论
其他用户提出的替代方案

那是一个即使是无意中也鼓励通过思想碰撞学习的环境。AI 给你直接、干净的答案，却不让你参与讨论和推理的复杂性。它的效率极高，但对学习者来说也极其危险。

计算器的类比

想象一个小学的孩子需要学习加法。如果每次要做 7 + 5 时都拿起计算器，会发生什么？

他永远学不会心算。
他不会培养数字感。
他也不了解背后的数学推理。

当他遇到没有计算器的情况时，就会完全迷失。

同样的道理也适用于编程。如果每次你实现算法、解决 bug 或构建应用时都求助于 AI，你并没有在培养程序员的基本能力。

无保证的抄袭

还有一个有趣的类比：在学校抄作业。当你从别人那里抄时，你并不能保证那个解答是正确的。你可能在抄一个和你水平相当，甚至更差的人。

使用人工智能更糟：AI 可以生成能够编译、看起来能运行的代码，但其中可能隐藏细微的 bug、安全漏洞或巨大的低效。如果你没有能力去理解这些代码，怎么知道它是好是坏？

我们真正失去的东西

问题解决能力
编程不仅仅是写出正确的语法，更是要能够分析问题、将其拆解、找到创造性的解决方案。如果让 AI 替你思考，你永远不会培养这种能力。
原创性与创造力
AI 生成的代码从定义上讲是对已有模式的重新组合，无法真正创新。如果你想为旧问题发明新方案，就必须培养自己的思维方式和独特视角。
调试与维护能力
这点至关重要。如果代码不是你写的，且你没有深入理解它，当它不可避免地出现故障时，你该如何调试？如何进行优化？当需求变化时又该如何适配？

正确使用 AI 的方式

现在，请注意：我并不是说 AI 完全没有用或有害。恰恰相反！有很多优秀的方式来使用这些工具。

1. AI 作为个人导师

AI 可以成为学习的优秀导师。你在学习一门新语言吗？可以让 AI 为你解释概念，展示示例，澄清不同方法之间的差异。

实际示例

“请解释 Python 中列表和元组的区别。”
“Rust 中 trait 系统是如何工作的？”
“Observer 模式相较于 Publisher‑Subscriber 模式有哪些优势？”

此时 AI 并不是在为你编写代码，而是充当教师。区别细微却关键：你在使用 AI 学习如何做 某事，而不是让它 替你完成。

2. 理解经典算法

想了解 Quicksort 的工作原理吗？可以让 AI 逐步为你解释，甚至提供可视化示例。这是主动学习，而非被动委托。

3. 文档编写支持

你已经编写了一段复杂的代码并希望做好文档？AI 可以帮助你组织文档结构，建议包含哪些内容，甚至生成基础注释，随后由你进行润色。

这里的智力工作是你完成的；AI 只是在帮助你处理过程中的“枯燥”部分。

4. 测试生成

你实现了一个函数并想进行彻底测试？可以让 AI 生成测试用例，包括你可能未考虑的 边界情况。

同样地：代码是你写的，你了解它的功能，而你使用 AI 来进行更全面的验证。生产代码仍然是你思考的结果。

黄金法则

使用人工智能来学习、理解、验证、记录。 不要将其用于取代你的批判性思维和解决问题的能力。

人工智能应该像一本高级教材，而不是像一个让你抄作业的同学。

法律与伦理问题

有一个许多人低估但至关重要的方面：法律和许可证问题。

许可证问题

生成式 AI 是在互联网上大量可用的代码上进行训练的。很多代码是开源的，拥有诸如 GPL、MIT、Apache 等特定许可证。

价值百万美元的问题是：当 AI 在生成代码时受到其训练过的代码的启发，这段新代码是否应被视为原始代码的“衍生作品”？

如果答案是肯定的，就会出现问题。像 GPL 这样的 copyleft 许可证要求衍生代码保持相同的许可证。这意味着，如果你使用的是在 GPL 代码上训练的 AI 生成的代码，你可能需要将整个项目以 GPL 许可证发布。

法规灰色地带

目前，这仍是一个灰色地带。相关诉讼正在进行中，法规框架也在不断演变。已有多家公司因这些风险而禁止在生产代码中使用生成式 AI。

如果你在公司工作并使用 AI 生成代码，可能会引入巨大的法律风险。公司可能面临因侵犯版权或许可证而产生的诉讼。

更不用说那些（虽少见但已有记录）AI 几乎原样复制其训练集片段的情况，甚至包括原始的注释和变量名。在这些情况下，毫无疑问：这是一份直接拷贝。

职业培训的伦理

还有一个更广泛的伦理问题：作为社区，我们有责任培养有能力的程序员。如果我们把使用 AI 作为思考的替代品常态化，就会损害整个行业的整体质量。

Source: …

朝向平衡的愿景

人工智能不会消失。相反，它会变得越来越普遍。而且完全从开发工具中剔除它也并非理想的做法。关键是 找到恰当的平衡。

四大指导原则

第一原则 – 先在没有 AI 的情况下学习基础
如果你刚开始学习，或在学习一种新语言或新范式，请在没有 AI 辅助的情况下进行。动手实践，犯错，调试，稍微受点苦。这才是真正的学习方式。
第二原则 – 用 AI 加速，而不是取代
当你已经掌握了某项技能，AI 可以帮助你更快地完成任务。但理解必须先行。
第三原则 – 始终进行验证
永远，且我再强调一次，不能在不完全理解的情况下直接复制 AI 生成的代码。阅读它，分析它，测试它，确保它完全按照预期工作。
第四原则 – AI 作为能力的放大器
你越优秀，从 AI 中提取的价值就越大。经验丰富的程序员会对特定任务进行精准、手术式的 AI 使用。一个把所有事情都交给 AI 的初学者，将永远停留在初学者的层次。

我的个人工作流程

我做的事

探索新的 API 或库：“这个函数怎么用？”或“给我一个配置示例”。
进行架构头脑风暴：“这种方法的优缺点是什么？”（但最终决定始终由我做）。
生成基础测试，然后手动扩展和细化。
编写文档，但仅在代码已编写并且可运行后。
如果需要经典算法，我会请求伪代码或工作原理的描述，而不是完整实现。这样，实际代码在我的环境中的“转换”仍由我掌控。

我不做的事

不使用 AI 编写应用的核心逻辑。
不使用 AI 解决复杂的 bug。
不使用 AI 实现我应该了解的算法。

能力是不可替代的

记住：人工智能是一个非常强大的工具，但它只是一个工具。能力、深度理解、批判性和创造性思考的能力——这些只能来自经验、学习、错误和纠正。

没有捷径可以成为一名优秀的程序员。

结论

人工智能是一种强大的工具：它可以加速工作，减少低级错误，并充当导师。但和所有工具一样，它的价值取决于我们如何使用它。如果我们用它来委托思考，就有可能培养出一代无法解决问题、创新和维护自己代码的程序员。相反，如果我们把它作为推理的支持、导师以及工作机械部分的辅助工具，就能把它转变为职业成长的真正盟友。

选择使用人工智能来增强你的思维，而不是取代它。

结论

在编程中，人工智能如果用于学习、深入、验证和文档编写，可以成为宝贵的盟友。当它取代你的批判性思考并阻碍你培养真实技能时，就会成为问题。

我的呼吁，尤其是给刚入门的人：不要急于求成。编程是一项需要时间、刻意练习和错误才能构建的技能。每一个你们独立解决的问题，都是向你们技能库中添加的一块砖。