不，AI 不会编程。那些说相反的人只是在卖弄烟雾。

Source: Dev.to

几周前，在看到无数个视频中一位 “专家” 声称 “Gemini 3 Pro 革命性地改变了自动化” 并且 “AI 代理已经能够构建完整的应用程序” 时，我感到既不可置信又愤怒。
愤怒源于看到缺乏真实项目经验的人伪装成权威，毒害刚入门者的判断。

1. 实际测试

我决定做他们都不做的事：一次真实的测试。不是用 10 个文件的玩具仓库，也不是用一个简单的 API，而是用一个具体的集成问题：

• 目标： 将 MCP 服务器连接到 jdt‑ls，使用 LSP4J。
• 初始思路： 生成一个自包含的 Java 类，少于 500 行，不集成其他任何东西。
• 结果： 甚至连这个最小的测试都没能通过。

评估模型

整体结果： 8 个模型，0 次成功。没有一个生成可运行的代码；多个模型陷入了不断修复编译错误的循环，我不得不亲自指出修正方案才能让它们编译出一点东西。

2. 背景的现实

视频仍然承诺“处理拥有一百万 token 的仓库！”。听起来很惊人……直到你打开一个真实的项目。

一个专业应用的单个模块已经 超出市场上最先进上下文能力的 150 %。当他们承诺 AI “理解你的仓库” 时，他们在撒谎：它只理解一个 极其微小的子集，一张模糊且裁剪过的系统现实的照片。

3. Demos vs. 编程真实

我见过典型的演示：

• “用 React 创建一个 TODO 应用”。
• “做一个带图表的仪表盘”。

它们相当于 组装 IKEA 家具：所有部件都在，说明书也很清晰，但最终得到的往往像个家具…却并不像你期待的那样工作。

真实的编程 并不是拼装预制件。它是：

• 知道 为什么 选择某种结构而不是另一种。
• 确保系统 不会 在自身重量下崩溃，无论是几个月还是几年后的生产环境。

当你把一个真实的问题（比如集成 LSP 协议、处理异步状态以及应对 jdt‑ls 的特定配置）交给 LLM 时，它会崩溃。它没有 系统的心理模型，只有 token 统计。

“那不是 编程。那是 生成看起来像 Java 代码的文本”。

IA 不能 做的事

• 检测 代码味道不好 的地方。
• 预见数月或数年后的后果。
• 与你的团队 讨论取舍。
• 保持与其他系统的 兼容性。

4. 炒作的后果

• 一名初级程序员看到“布道者”说：

  “别再浪费时间学习语言了，学会以正确的方式向机器提出请求”。

  并承诺 LLM 具备“博士级推理能力”、 “能够理解你意图的 Vibe Coding”……

• 初级程序员会问 为什么要学习算法或架构，如果机器“已经可以做到”？

• 实际上在掩盖的是：在没有判断标准的情况下，他们把关键任务委托给一个 概率盒子，连它自己的内存都装不下。

5. 这则呼吁的对象是谁？

内容创作者

• 停止夸大其词。 如果你们想教授人工智能，要教会它的局限性。
• 展示它在机械任务或重复代码、重构时的有效性，但永远不能取代对问题的理解。

初学者

• 学习基础。 人工智能是一个强大的工具，在熟练工匠手中。
• 在新手手中，它是一个气锤，会把触碰到的一切都毁掉。

我

• 我将继续写类似的文章，用代码（在可能时）和真实错误展示炒作与现实之间的差距。

6. 额外的轶事

我一直有个疑问：如果问题不是 Java，而是复杂性本身呢？

几天后，我想起了十一月底发生在我们身上的一件事…

背景： 我和一位同事必须介入公司的网页应用。它的 前端超过 50 000 行 JavaScript 和 TypeScript 代码。
我们的背景： Java 架构师；对 React 只知道名字。
AI 的承诺： 使用 Gemini CLI 来让它解释需要更改的内容并生成代码。
结果： 解释很连贯，代码在语法上也完美……但 悄然失败。

7. 结论

AI 不会编程。
程序员会编程。
其他人只做演示。

如果有“大神”再次声称 AI 能编程，我会把我那八次失败的尝试作为证据发给他。看看他是否有勇气去修复它。

这篇文章几天前已经准备好发布。但思考仍在：一个工具的真正考验是它在复杂且真实的问题上的表现，而不是精心打磨的演示。

教训 (陈旧闭包)

Gemini忘记在 useCallback 中声明依赖。它写了一个看不到状态变化的函数。我们没有办法修复，于是让 AI 给我们概述 React 的哲学、hooks 和 闭包。我们阅读、理解并指出了错误。AI 修正了，但犯了一个初级错误，我们不得不再纠正它。

现实

• 并不是他们不懂 Java。
• 当复杂性是真实的——异步状态、复杂的生命周期或与 活 系统的集成——无论使用何种语言，都会出错。
• AI 没有心理模型；只有概率。
• 在真实项目中，这会以调试工时的形式付出代价。