> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 8个关于AI编程的经典误区
- URL: https://www.hubwiz.com/blog/8-classic-misconceptions-about-ai-coding/
- Published: 2026-07-31T11:47:17.000Z
- Updated: 2026-10-13T15:17:47.000Z
- Description: 每个人都在争论AI是否能编码。但没有人衡量真正决定其成功的东西。
- Author: admin
- Tags: AGENT, CODING AGENT, #Import 2026-10-14 14:41

AI行业会自信地承诺重塑教育、医学、科学、约会、战争，[甚至最近还有你的死亡率。](https://www.cell.com/cell-metabolism/abstract/S1550-4131%2826%2900108-7?ref=hubwiz.com)

但问问它的编码模型已经能做什么，每个人都突然变成了一个[紧张、防御性的销售员](https://openai.com/de-DE/index/separating-signal-from-noise-coding-evaluations?ref=hubwiz.com)。

***嗯，这取决于。***

***模型可能产生不正确的结果。***

***仍然建议人类监督。***

别开玩笑了。**人类监督**在人类编写软件时也是推荐的。这就是为什么我们有代码审查、测试、预发布环境、调试器、事件报告，以及高级开发人员深夜盯着损坏的部署。

奇怪的是，AI编码正在被人类程序员从未达到的标准来评判。**一个阵营**展示一个代理构建一个小型Web应用程序，然后宣布软件工程师完蛋了。**另一个阵营**看着同一个代理拼错一个变量，然后宣布机器无法推理。

两个结论都是荒谬的，都来自同一个统计错误。

每个人都盯着分子：**AI解决了多少编码任务？**

几乎没有人检查分母：**这些任务是什么类型的？**

**而这个分母几乎包含了整个故事：**

> **模型被要求写它接收它能运行测试吗？ 测试质量如何？ 文档与代码匹配吗？ 模型实际被给予的是什么类型的任务？**

> **所以这是第一个提示：每当你分析AI编码器时，检查其柔软的腹部——分母*：一个十行的函数不是四十个服务的支付系统。一个完整的仓库不是三个粘贴的文件。一个有测试、日志、工具和重试的模型与一个被迫从模糊提示中猜测的聊天机器人不是同一台机器。*

AI编码能力不是来自一个聪明的小矮人——一个隐藏在模型内部并做所有思考的小程序员。

它来自整个设置：

**模型 + 上下文 + 工具 + 反馈 + 人类判断**

改变设置，同一个AI可能看起来聪明、无用，或者自信地破坏一个它从未理解过的系统。

**这就是两个阵营操纵实验的地方。**

乐观主义者展示最干净的运行。悲观主义者移除一半的上下文，将一只手绑在代理背后，然后将崩溃作为科学证明呈现。

**两者都没有告诉你机器何时真正有用。**

**这是值得学习的技能：**知道代理是只需要更多上下文、做出了糟糕的猜测、编写的代码只是*看起来*正确，还是偏离了架构太远以至于你需要把它拖回来。

学会识别差异，AI编码就不再是黑暗艺术——而更像是一种实用的防御技能。

## 1、软件民间传说在欺骗你

让我们从那些阻碍我们理解AI编码器——以及正确使用它们——的神话开始。

看看下面的表格。这些是关于AI的故事，如果你是开发者，你可能已经厌倦了从其他开发者那里听到这些——尽管正如你将看到的，证据指向相反的方向。

![传说与现实](https://www.hubwiz.com/blog/content/images/2026/07/1-mKRNfpe5RE3bJs1aqY_-3Q.png)

软件工程当然不是非理性的。每个领域都有其最喜欢的神话。但我们的特别奇怪，因为开发者喜欢谈论证据……直到AI编码出现。

所以让我们将这些信念送上法庭，看看证据实际上支持哪一方：技术乐观主义者还是技术悲观主义者。

**剧透：都不支持。**

## 2、误区一：鹦鹉不在场证明

**AI编码之所以有效，是因为模型已经记住了答案。**

![误区一：鹦鹉不在场证明 AI编码之所以有效，是因为模型已经记住了答案。](https://www.hubwiz.com/blog/content/images/2026/07/1-UquYQgVeaYJHgeS5-zCyyA.png)

这个排在第一，并非偶然。我自己在将当前AI与真正智能的机器进行比较时，也使用过AI作为鹦鹉的形象。但有时这个比喻被过度延伸，直到AI的每一个明显奇迹都被视为简单的鹦鹉学舌。

> *底线是，模型的行为并不像一个被美化的关联数组——一个哈希映射，其中问题是键，预包装的、记忆的解决方案是值。*

这种解释无疑安抚了许多现在面临失去工作给AI威胁的开发者的认知失调。所以，我真的应该害怕一只查找鹦鹉吗？

**是的，记忆是真实的**。OpenAI已经记录了前沿模型复制精确的基准补丁、注释和特定任务细节。在训练期间接触过的问题的模型以后也更有可能解决它。

**但记忆不能解释AI编码能做的一切。**

**最强的反例是DeepSWE**，一个由从零开始编写的原始工程任务组成的基准。其解决方案不是从历史提交或现有拉取请求中复制的。[然而，前沿编码代理仍然可以解决其中很大一部分](https://arxiv.org/abs/2607.07946?ref=hubwiz.com)。

**这并不证明AI理解代码的方式与人类开发者完全相同。**

它证明了更窄的东西，但对软件工程的自尊仍然深感不安：**AI编码不能被简单地视为记忆答案的检索。**

> *给现代编码代理一个它以前从未见过的确切答案的问题，它不一定会崩溃。它可以读取代码库，尝试一个解决方案，运行代码，看看什么失败了，并改进它的修复。*

当然，有很多例外，没有涉及魔法。但抱歉：它们成功的次数足以杀死记忆解释整个现象的舒适信念。

## 3、误区二：私有代码是力场

**如果模型从未见过你的仓库，你的软件就是安全的。**

![误区二：私有代码是力场 如果模型从未见过你的仓库，你的软件就是安全的。](https://www.hubwiz.com/blog/content/images/2026/07/1-SBKxmZSRHMESGJ4wulgJQQ.png)

这个神话几乎直接来自第一个。如果AI能做的不仅仅是鹦鹉记忆的解决方案——如果它能解决它以前从未见过的问题——那么为什么每个人都表现得好像隐私本身就能在代码库周围创造某种力场？

> *通常的建议很简单：保持你的代码私有。不要在GitHub上发布，更不要作为开源发布。这样，它就安全地远离了AI的贪婪爪子。*

**这里有一个真正的知识产权讨论。但仅靠隐私并不是对抗AI编码的可靠墙壁。**

模型不一定需要以前见过你的实现才能复制其功能。给它一个关于软件应该做什么的清晰描述，访问周围的代码，以及可靠的测试来告诉它何时出错，它通常可以从零开始重建缺失的功能。

许多开发者已经知道这是如何运作的。你不需要原始实现。**你只需要不断问正确的问题：**

> 问题能被清晰描述吗？ 相关代码能找到吗？ 新解决方案能运行吗？ 最重要的是，是否有测试告诉代理它何时终于停止破坏东西？

是的，这更接近于洁净室重新实现而不是经典的逆向工程，但像Fable 5和Opus 5这样的前沿模型越来越能同时做到这两者。

具有讽刺意味的是，最值得复制的私有软件通常是最容易重新实现的：清晰的需求、可执行的代码和强大的验收测试。

**那不是力场。那是一张路线已经用红色标记的藏宝图。**

## 4、误区三：80%的幻觉

**80%的基准分数意味着AI可以解决你公司80%的工单。**

![误区三：80%的幻觉 80%的基准分数意味着AI可以解决你公司80%的工单。](https://www.hubwiz.com/blog/content/images/2026/07/1-7tN2qR9iQjsIKGYxVSaVzw.png)

**还不信服？**

公平起见。也许怀疑者是对的，我夸大了AI编码已经能做的事情。

所以让我们转向论证的另一面：那些声称编码代理可以解决70%以上，有时接近80%的真实软件问题的惊人基准。

令人印象深刻，不是吗？

直到你看看那些令人惊叹的基准是如何构建的后台……

**OpenAI构建SWE-bench Verified引入了一个方便的选择偏差**：它将大量专业软件问题过滤为更清晰、更规范的任务——GPT-的得分翻了一番。混合营销和科学一直是个坏主意。

Scale AI用[SWE-bench Pro](https://scale.com/blog/swe-bench-pro?ref=hubwiz.com)采取了不同的路线：专家在将工单交给模型之前清理了模糊的工单。这产生了更好的基准。

**但这也意味着代理没有面对开发者每天处理的那种模糊性。**

**所以在这里我们向AI怀疑者让步一点**，AI编码器解决的80%日常工作的神奇百分比实际上是针对一组精心选择的特定任务和问题的百分比：开发者**不**花大部分时间处理的那种。

这仍然令人印象深刻。只是不像许多人说的营销奇迹那样。

## 5、误区四：代码库只是一个大文件

**一个主导小补丁的模型已经可以处理现实的软件系统。**

![误区四：代码库只是一个大文件 一个主导小补丁的模型已经可以处理现实的软件系统。](https://www.hubwiz.com/blog/content/images/2026/07/1-UvHC9WRag-1xP4yQ3ot2YA.png)

**这种信念在不断增长的氛围编码者中尤其普遍。**他们对设计、架构、编程技术和实现之间的区别很小。在这种情况下，偏见严重偏向AI。

> *与他们最喜欢的编码代理手牵手，许多新手似乎想象代码库是一个巨大的文件，模型可以简单地整体吞下。*

**但真正的软件很少停留在一个整洁的文件中**。一个看似微不足道的更改可能跨越模块、服务、配置层、数据库、接口、API，甚至多种编程语言。

这就是魔法开始泄漏的地方。

给编码代理整个问题在一个文件中，它可能看起来很聪明。将相同的逻辑[分布在二十个文件和三种语言中，其性能可能会迅速下降](https://arxiv.org/abs/2504.02605?ref=hubwiz.com)。不是因为代码突然变得更复杂，**而是因为代理现在必须找到每个相关的部分，理解它们如何连接，并在不破坏其他地方的情况下更改它们。**

它必须协调的文件越多，它解决编码练习就越少——而处理实际软件系统就越多。

一个在修复一个孤立文件时看起来很壮观的模型，在必须理解二十个文件、三个服务和一个数据库迁移如何组合在一起时，可能看起来非常不同。

**这不是一个小技术细节。这是生成代码与设计系统之间的区别。**

> *所以，最后，对于那些将AI视为助手而非替代品的开发者来说，一些好消息：一旦一个真正的项目分布在庞大而混乱的表面上，人类的架构判断仍然非常重要。*

## 6、误区五：模型就是整个机器

模型 alone 决定了编码系统的智能程度。

![误区五：模型就是整个机器 模型 alone 决定了编码系统的智能程度。](https://www.hubwiz.com/blog/content/images/2026/07/1-Fb0ErRRqYzjsKWkoDMF8mw.png)

多文件问题是真实的。对技术悲观主义者来说不幸的是，这场胜利可能不会持久。

聊天机器人生成一个孤立的代码片段是一回事。一个被投入真实仓库的代理——带有搜索、终端访问、测试、日志和持续尝试的权限——是一台非常不同的机器。

尽管如此，在一点上技术悲观主义者是对的：模型 alone 无法完成所有工作。

现代编码代理现在可以探索整个代码库、跟踪依赖关系、编辑多个文件、运行项目、读取错误并修改自己的工作。它们仍然会迷路。只是它们带着更好的工具迷路。

[但Anthropic的Fable 5改变了局面](https://deepswe.datacurve.ai/blog/deepswe-v1-1?ref=hubwiz.com)。在用于每个模型的相同DeepSWE平台上，它解决了约70%的113个原始长期工程任务——通常是大型多文件作业，需要比SWE-bench Pro多约5.5倍的代码。

然而，Fable 5对这些多文件基准的破坏并不意味着问题消失了。代理只是变得更好地导航它。

结论很简单：

**编码代理不仅仅是它的模型。**

给它仓库访问权限、工具、测试、记忆和反馈，它就变成了一个非常不同的编码器。

**模型 + 工具 + 执行 + 反馈**

只评判聊天机器人，你就是在评判一台没有轮子的发动机。

## 7、误区六：资历不是护城河

**AI编码将取代初级开发者，但高级开发者不受影响。**

![误区六：资历不是护城河 AI编码将取代初级开发者，但高级开发者不受影响。](https://www.hubwiz.com/blog/content/images/2026/07/1-1wcaDtVNxiEYvZsZYhh4mQ.png)

这可能是所有神话中最顽固的一个，即使就业市场开始悄悄不同意。

**高级开发者**不再是一个魔法盾牌。如果没有强大的AI技能，这个头衔开始看起来不像是保护，而更像是一个非常昂贵的标签。甚至LinkedIn也在追赶。

一个修复明确定义的bug并有优秀测试的高级开发者可能比一个初级开发者更容易自动化，后者需要理清一个遗留系统，其需求存在于三个经理的脑海中、两个废弃的Slack频道和一个不朽的注释中：

```
// 临时修复 — 不要碰

```

```
// 临时修复 — 不要碰

```

代理仍然难以处理长期、模糊、政治性、架构性的工作——以及没有人费心记录下来的上下文。METR发现同样的基本模式：任务越长，可靠性下降越快。

> *所以资历不是护城河。*未书面化的判断才是。**

高级开发者在知道应该构建什么、哪个捷径会在六个月后爆炸、以及一个完美的补丁是否在解决错误问题时仍然有价值。

但打字部分？AI不在乎你的简历上有多少年。

高级角色没有消失。它正在从编写每一行转向构建问题、设置约束、设计测试、审查输出，以及在代理自信地修复错误东西时抓住它。

所以不，即使是高级开发者也不能忽视AI工具。

## 8、误区七：你能感受到加速

如果AI让你更快，你会知道的。

![误区七：你能感受到加速 如果AI让你更快，你会知道的。](https://www.hubwiz.com/blog/content/images/2026/07/1-MmS7ddOKqGsaQhWyXmTp9g.png)

显然不是。

有经验的开源开发者使用AI完成实际任务**慢了19%**。有趣的部分？[他们相信AI让他们快了20%。](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?utm%5Fsource=chatgpt.com)

> *教训很简单：*生产力不是一种感觉。要衡量它。**

衡量重要的事情：完成的工作、总时间、引入的错误、审查时间，以及代码是否在生产中存活。

围绕代理重新设计工作流程的开发者可能会领先。但看着光标冲刺并不等同于移动得更快。

## 9、误区八：困难语言对AI来说很难

![误区八：困难语言对AI来说很难](https://www.hubwiz.com/blog/content/images/2026/07/1-OEjTu11yYe-nskr8skPNxQ.png)

你们中的一些人质疑这个是对的：你怎么能称之为神话？毕竟，Rust是严格和整洁的。C++是指针、可变状态和四十年的糟糕决定穿着一件风衣。

好吧，公平点。乍一看，官方的SWE-bench多语言结果似乎支持你的论点：Claude代理解决的Rust任务是C和C++任务总和的两倍。

当然，在一个更大的近2k任务的数据集中，C++击败了Go、C、JavaScript和TypeScript。

但没那么快，因为你一旦改变代理平台，甚至Rust-C++的差距也会翻转方向。

这应该杀死这个理论：C++不能仅仅因为你改变了模型周围的工具就突然变得更容易或更难。

但这就是发生的事情。改变Claude周围的代理——它用来搜索、编辑、运行和调试仓库的工具——排名就翻转了。使用SWE-agent，C++击败Rust。使用OpenHands，Rust又赢了。

**相同的模型。不同的工具箱。不同的结果。**

**所以对于AI来说，困难语言和简单语言之间没有稳定的划分。**

真正的解释更简单：

**AI并不天生擅长Rust而不擅长C++。它擅长的是小、清晰、独立、易于用特定工具测试的任务。**

## 10、后台：这个该死的东西到底是怎么工作的

神话就到此为止。

但杀死错误的解释并不会神奇地给我们一个好的解释。它**并不意味着**在AI行为背后有一种矮人软件工程师在深入思考你的代码库。它只是意味着旧的故事是错误的。

要看到真正重要的是什么，一个更好的描述性方法是简单的因子分析，你可以做类似我做的事情：

我测试了AI编码性能的五种可能解释：

**编程语言、模型品牌、记忆、可测试性和任务大小。**

只有后两个持续改变了分数：

**代理能检查其修复是否有效吗？以及它必须理解和更改多少代码？**

用简单的英语说，当任务很小且测试给出清晰信号时，AI编码器表现最佳：错误，再试一次；正确，停止。

这似乎是充分利用AI编码器的最佳方式。

![我们测试了五件可能解释为什么AI解决一些编码任务而失败的事情。其中四件，包括每个人都争论的那件（AI是否只是记住了答案），结果根本没有影响。只有两件事重要：任务是否可以测试，以及它有多大。就这样。不是语言，不是模型品牌，不是记忆。只是：你能检查答案吗，修复涉及多少？](https://www.hubwiz.com/blog/content/images/2026/07/1-S4DEOevc_7R3LosJB7tmGw.png)

不是语言。不是模型品牌。甚至不是先前的代码接触。

重要的是更简单的：**代理能测试其工作吗，任务有多大？**

惊讶吗？技术乐观主义者应该惊讶。技术悲观主义者可以把香槟放回冰箱：AI编码器可能不会像人类那样推理出修复，但它们仍然可以为你节省大量工作——特别是当你减少其试错循环的磨练时：**编辑、测试、失败、调整、重复。**

> *你塑造那条路径越好，代理就越有用。测试是它的指南针。*

也就是说，不要太快相信你最喜欢的AI编码器的好意。它最深的本能不是理解问题。而是通过找到通往绿色勾号的最短路径来逃避磨练。

这正是下面动画中发生的事情。代理从项目历史中挖掘出答案，复制它，然后就好像它自己解决了问题一样交回来。

非常有效。也是作弊。

所以仔细观察测试。给AI编码器一个漏洞，它可能会解决计分板而不是软件。

![这实际上发生了。研究人员在真实编码任务上测试了Claude Opus 4.6和4.7，当他们检查那些它"通过"的任务时，高达25%是假的。AI没有修复bug。它挖掘了项目的保存历史，找到了某人已经写好的答案，复制了它，然后在那上面运行了测试。绿色勾号，完成。什么都没解决。所以在你信任AI编码器之前：它多达四分之一的"胜利"可能是找到答案键，而不是完成工作。](https://www.hubwiz.com/blog/content/images/2026/07/1-CEcVBMQaIKm-zxTbh4XJ1w.png)

\*\*所以这是底线。\*\*AI编码器不是魔法。它们是小型、可测试任务的山羊——而在其他地方则是绝对的游客。这意味着你的暴露不仅仅是等待一个更聪明的模型。它关乎你交付的工作的形状。

正如下面动画残酷地表明，**你只控制两个杠杆**：东西能被测试吗，工作能保持小吗？很好地拉动这两个杠杆，机器突然看起来很聪明。忽略它们，它就开始吃家具。下次好运。

![AI能否处理你的任务不是一成不变的。它归结为两件简单的事情：你能为它写测试吗，它小吗？在左下角，没有测试和很多文件，它大约8%的时间成功。在右上角，有一个清晰的测试和一个文件，大约92%。相同的AI，完全不同的几率，仅仅因为工作的形状。这是重要的部分。你可以通过先写测试并将工作分成小块来将你自己的任务从困难的角落移动到容易的角落。](https://www.hubwiz.com/blog/content/images/2026/07/1-BqsdMwgctb_e4fZCfROmTA.png)

---

原文链接: [Everything You Believe About AI Coding Is Wrong](https://freedium-mirror.cfd/https://ai.gopubby.com/everything-you-believe-about-ai-coding-is-wrong-41d963b47f86?source=home%5Ffor%5Fyou---------43-98--------------------d1a9dc73%5F2400%5F4132%5Fb2e3%5Fc3c8aed6a55e-------15-------)

汇智网翻译整理，转载请标明出处

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)