AI编程：仍在测试阶段

在我之前的文章中，我回顾了我与 AI 辅助编码的历史以及一些普遍的经验教训。虽然你可以单独阅读这篇文章，但额外的背景信息可能会有所帮助。

说到这里，我花了很多时间与 AI 工具合作来构建项目，我之前也提到过——无论是模型还是工具都在不断进步，使它们变得越来越强大。同时，了解这些模型的能力和局限性，以及如何与它们进行有效沟通，都是非常有帮助的。

AI 工具正在自我改进

几天前，微软的 CEO 萨提亚·纳德拉 指出 他们正在使用 ChatGPT 的 o1 模型与 Copilot 一起改进 Copilot，使其变得稍微更好/更快。这个 AI 工具正在“利用自身”进行改进。我不想夸大这一点，尤其是因为其他工具已经在做类似的事情——例如 Aider（一个开源 AI 编程工具）最近的更新中，已经编写了 77%（!!）的自有代码。

Aider 版本 0.59 的更新日志

现在，这并不是一些人所认为的 AI 自我递归改进的版本，认为这将是 AI 起飞的时刻。要达到这一点，它还缺少一些东西。首先，它只是稍微改进了所使用的工具，而不是模型本身。其次，它缺乏主动性——这些操作是在用户要求后由模型执行的。我确实认为这是我们所看到的未来发展轨迹的一个初步迹象。也许我们永远无法获得那种自我递归改进的超智能 AI 模型，但我认为这是我们所能获得的最早版本。

Use AI 是一个由读者支持的出版物。要接收新文章并支持我的工作，请考虑成为免费或付费订阅者。

已订阅

当前状态和局限性

谈到早期版本——我认为这对 AI 辅助编码（或 AI 配对编程）来说是公平的说法。市面上有很多工具，它们以略微不同的方式执行任务，我们都在摸索与 AI 模型沟通的最佳策略，以及如何应对其局限性。

我认为可以安全地说：从未有过任何工具能像 LLMs 一样，将自然语言转化为实际代码。我们可以讨论 Claude 的 Sonnet 3.5 或 OpenAI 的 o1 模型哪个更好，但我认为这并不是重点。看到这一点非常令人惊叹，但仍然存在一些关键的局限性：

• 上下文：尽管最近上下文窗口大幅增加，但我们仍然无法简单地将整个代码库输入到 AI 模型中。以每行大约 10 个标记计算，即使是 60k 的上下文也只能覆盖大约 6000 行代码。虽然这比以前有了巨大的改进，但对于中大型代码库来说仍然不够。不过，工具在不断改进——Cursor 在这方面取得了很大进展，但我们还没有完全到达那个阶段。
• 懒惰编码：在过去的 6 个月里，我们在这方面看到了很大的进步，主要体现在两个方面：
  • 模型在完整输出方面变得更好：o1 模型可以稳定地输出更大的代码块（700–800 行，可能高达 2000 行）
  • 工具变得更智能：Aider 使用搜索和替换模式，而 Cursor 使用快速的专用模型逐行比较代码
• 代码质量：这可能是最重要的因素。如果你是编程新手，想要构建某个东西（想象一下自我运行的贪吃蛇），AI 已经可以远远超过你。像 Bolt.new 或 Replit Agent——这两者都可以通过几条指令构建跨多个文件的基本应用。但当你深入系统架构和更大的代码库时，局限性就变得明显。虽然模型可以编写功能性代码，但它们往往会忽视重要的架构考虑，并且在复杂设计模式上表现不佳。
• 幻觉：模型有时会引用不存在的函数、模块或 API，尤其是在使用专用库时。虽然在更好的模型中这种情况似乎减少了，但所有工具能做的就是尽可能简化 CTRL + Z 的操作。
• 保持更新：即使是最新的模型也落后于当前的技术趋势和框架版本。在这些工具中添加上下文中的文档或包含网页有助于解决这个问题。

工具的发展方向

工具正在朝两个有趣的方向发展：

1. 与您并肩工作

模型在输出完整解决方案方面变得更好，工具在分解大变更方面变得更智能。Cursor 正在通过快速重排序模型来处理上下文管理，该模型可以将 50 万个标记过滤到最相关的 8 千个。他们还在扩展以预测您在整个编辑器中的下一个操作。

GitHub Copilot 专注于集成，添加了在 GitHub 实体中搜索和在 VS Code 中的新技能等功能。他们还在为企业客户开发定制模型，以更好地理解公司特定的模式。

Aider 采取了一种有趣的方法，通过使用“架构师”模型来描述如何解决问题，以及使用“编辑器”模型将该解决方案转化为实际的代码更改。这与 o1 模型结合其他模型（如 Sonnet 或 Deepseek）非常有效，其中 o1 负责思考，而其他模型则负责实际编写代码。

使用 Aider 的架构师模式的结果

2. 为您构建一切

像 Replit Agent 和 Bolt.new 这样的工具正在尝试完全不同的方式——它们不是帮助您编写代码，而是试图从头开始构建整个应用程序。这些工具使编码变得更加可及：您描述想要构建的内容，它们处理从选择技术栈到编写代码的所有内容。

不过，有一个问题——虽然这些工具在快速启动某个项目方面令人印象深刻，但您往往会很快遇到瓶颈。随着应用程序的规模和复杂性增加，小的更改开始引入越来越多的错误。这不仅仅是编写代码的问题——还涉及理解整个代码库、管理依赖关系以及保持一致性。

这确实让人感觉像是 AI 辅助开发的两种不同方法的早期阶段。我们在这两个方向上都看到了快速的进步——要么使配对编程工具更智能、更具上下文意识，要么构建能够处理整个项目的自主代理。观察这一切非常有趣，目前尚不清楚哪种方法（或哪种方法的组合）最终会被证明是最有效的。