AI辅助编程开始接管码农了吗？
极客见识约 21 分钟2024年已经接近尾声，AI 的热度也逐渐趋于平淡，从编程、搜索、图像、视频、音乐到销售等各种自动化工具和应用项目，在一定程度上确实提高了效率，然而产生的价值还远远没有达到大家的期望，也就是还没有那么完美。
很多产品大家都是抱着尝尝鲜的心态去体验一下，现实中，大家其实没有那么多需要用到 AI 的地方（因为目前 AI 还并没有那么完美），不过，一旦 AI 与工作结合起来，就在一定程度上变成一种刚需，因为我们工作的事情是不得不做的，为了提高效率，大家都愿意使用，比如，AI辅助编码、AI图像视频辅助创作者。
最近，大家对 Cursor、Devin、Github Copilot 等 AI 辅助编程这个话题讨论得比较多，刚好在浏览 X 时，有一位有着多年编程经验和 AI 应用经验的大佬，Sankalp，在其博客上面分享了一篇关于AI与编程的文章，文章写着过去6年 AI 辅助编程功能的演变，以及需要哪些技术突破才能达到现在的水平，跟大家分享一下。
文章开始前，我们先来看看 Devv.AI 的 Jiayuan 对于“AI会不会代替程序员是一个典型的 class1/class2问题”的一些理解。
by Jiayuan @ Devv.AI
Class1问题：某项技术「不够完美」导致的问题
Class2问题：某项技术「足够完美」导致的问题
Part 1
对应到 Al Coding 的发展，我们其实还处在解决 Class1问题的阶段。
Al Coding 的 Class 1 问题：
当前的 Al Coding 工具(Cursor、GitHub Copilot、bolt、Devin 等)在代码补全、生成、调试方面已经展现出极大的潜力，但依然会：
难以理解大型、复杂系统的全局设计
容易在边缘场景中失效
需要大量的人类辅助
会生成包含 bug 的代码
在部分场景和技术下不够成熟
这些都属于典型的 Class1问题，也就是技术尚未达到“完美”所导致的问题。
这也是现在大部分创业公司在解决的问题（也正因为此，这些创业公司才有机会），例如大模型公司 OpenAl、Anthropic，应用公司 Cursor、Devin 等。
在 Class1 问题下，AI Coding 不会代替程序员，它的更多目的是帮助程序员提效，或者代替掉 SDLC 工作流中的某一个环节（例如端到端的测试）。
拥有编程知识的人可以更好地采纳这些 AI Coding 工具，来进一步提升自己的效率和能力，例如一个普通的开发者可以借助 Al Coding 的工具成为一个 10X developer。
在这一阶段下，程序员应该保持非常大的开放心态，尽可能多、快地把 AlCoding 的能力融入到自己的工作流中，而不是固步自封，采取封闭保守姿态。
完全不用担心是否会被 AI代替的问题，因为这不是这个阶段要解决的事情。
Part 2
当大量的资金、公司进入到这个领域，解决 or部分解决了 Class1的问题，我们就会进入到Al Coding 的 Class 2 问题阶段。
Al Coding 的 Class 2 问题：
经过若干时间的发展，AI 在编程层面变得非常成熟:它能理解庞大的代码库(并能快速学习)，对业务逻辑、底层实现都能给出高质量的解决方案，能写出 0 bug 的代码，能够根据需求直接产出最终的结果。
这个时候造成的问题已经不再是技术上的问题，而更多的是：
安全：如何保证能力这么强大的 A1是安全的，如何避免人类不会被毁灭？
伦理：程序员是否会被大规模代替？
教育：CS 知识的学习是否还有意义？
有些公司已经开始解决潜在的 Class2 问题，例如 llya Sutskever 的 SSI，愿景是构建安全的超级智能。
而在这个阶段，曾经熟悉传统编程方法的工程师可能会被“时代洪流“所淘汰。但同时，也会诞生一批新的工作角色和形态。组织结构、开发流程和生产力方式都将经历深度变革。
在这个阶段，程序员要做的是如何尽快转化到新的角色上来，否则结果肯定是被时代抛弃。
Part 3
智能的进化并不是线性发展的（参考下图），一定会存在一个「wocao」时刻。回想一下 GPT-3的代码能力和 Claude 3.5 Sonnet 的代码能力，而这才仅仅过去了 2年。
在当下，AI Coding 工具还在解决「不够完美」的 Class1问题，所以焦点在于如何补足技术短板、提升开发效率，程序员大可不必恐慌被取代。而当技术日臻成熟，跨入「足够完美」的 Class2 阶段时，真正带给我们的将是对安全、伦理、教育以及社会组织方式的反思和挑战。
保持开放心态，持续学习，拥抱变化。技术拐点常在意料之外出现，而能否抓住那个「wocao」时刻，取决于我们此前做了多少积极的准备。
下面是 sankalp 对于 AI 与编程研究。
标题：
AI 辅助编码功能和开发人员交互模式的演变
2024 年 12 月 22 日
By：sankalp
X：https://x.com/dejavucoder
原文链接：https://sankalp.bearblog.dev/evolution-of-ai-assisted-coding-features-and-developer-interaction-patterns/
是的，我同意这个标题很花哨。但请考虑一下，起初只是简单的自动补全建议，如今已发展成强大得多的功能了。现在的 AI 能够即时生成完整的函数，搭建具备合理架构的完整文件，甚至能从头开始构建整个代码库。这些工具已经从辅助输入的助手发展成了协作编码的伙伴。
进展相当惊人。无论你是新手开发者还是经验丰富的专业人士，我认为理解并适应这些功能 / 工具都是当务之急。随着这些工具不断发展，要弄清楚该使用哪些工具来保持严格控制、何时让人工智能主导，变得有点复杂了。
我们应该给予这些 AI 辅助编码功能多少控制权呢？在此我打个比方。你可以把 AI 辅助编码功能想象成汽车的挡位。挂在一挡时，你对引擎有最大的控制权，但车速很慢，这就好比自动补全功能。依次升挡（对话助手、光标聊天、智能体模式），你会用精细控制来换取更高的速度和自动化程度。
在这篇文章中，我们将从三个角度探讨 AI 辅助编码的演变：
历史叙述 - 发生了什么突破，让我们走到了今天。我认为这对于我们更深入地欣赏和理解这些工具至关重要。你们中的一些人太被宠坏了，认为这些工具是理所当然的。
交互模式 - 我们如何使用这些工具，它们解锁了什么样的用户体验，以及对其使用过程中出现的一些模式的观察。
齿轮类比 - 控制与自动化 - 您愿意用多少控制和信任来换取速度。
友情提醒：
这篇博客会在介绍新的 AI 功能和讲述历史脉络之间来回切换。
01 自动完成
1. 代码建议时代
我在 2018 年末开始了我的编程之旅。我的第一门编程语言是 Python。我通过 Coursera 的 Python for Everybody Specialization 和一些 sentdex 和 Corey Schafer 视频学习了 Python。当时，Kite 凭借其基于“机器学习”的代码建议而引起轰动。然而，我在 Pycharm 和 Spyder IDE 中编写了我的代码。
大约在同一时间，微软在 VsCode 和 Visual Studio IDE 中发布了Intellicode（2018 年至今），它可以提供有关下一个方法、变量的上下文感知建议，本质上对“Intellisense”列表中最可能的建议进行优先排序。
他们在 Github 上托管的几个开源项目上训练了他们的模型。他们最初使用马尔可夫链，并在 2020 年逐渐转向基于深度学习的建议（GPT-C）。您可以在该项目的一位个人贡献者的博客文章中阅读更多详细信息。
其他突出的功能包括“重复编辑”检测 - 检测编辑中的模式并建议在整个代码库中自动执行类似的更改、“快速操作”和重构建议。
还可以在公司的存储库上训练 Intellicode，以使其建议与团队的编码标准保持一致。（我相信是企业部分）
2. 迈向单行自动完成
微软最终推出了“整行预测”。整行代码预测意味着根据上下文预测下一个逻辑代码行。还记得编辑器中的灰色预测吗？
值得注意的是，早期的代码完成模型并不像今天的工具那样与语言无关。每个模型都有自己的专长：Intellicode 专注于 C# 和 .NET，ReSharper 专注于 C#，Eclipse IDE 专注于 Java。
3.多行自动完成
第一个真正的突破来自 Jacob Jackson 的 Tabnine。它是第一个集成 GPT-2 进行代码补全的代码编辑器。它为未来的 AI 代码编辑器奠定了基础。我不能 100% 确定，但看起来 TabNine 是第一个支持基于本地上下文的语言无关多行代码补全的编辑器。
GPT-2 在不同代码库上的训练实现了第一个真正与语言无关的代码补全模型。Karpathy 的推文展示了制表符补全曾经的样子。这里还有一个视频 。它显示了下一行的建议以及百分比。
您可能会注意到自动完成一直是 Tab。
4. 输入块级代码完成
我们显然没有块级代码完成功能，例如基于用户输入和上下文感知代码生成或理解用户意图生成整个函数或方法。
直到OpenAI Codex模型发布。OpenAI codex 为 Github Copilot 提供支持。它能够以相当高的准确度执行上述功能。
来源：Github Copilot 如何更好地理解你的代码
5. 填满中间
到目前为止，我们讨论的自动补全仅限于从左到右的操作。这些模型只能“追加”。它们无法提前查看后缀中的上下文。早期的模型无法填补这一空白。
def calculate_total ( items ):# [此处有差距]返回 总计
后来，OpenAI 引入了填充中间技术来解决了这一限制。FIM 代表填充中间。有时也称为双向意识，即理解光标前后的位置。阅读此博客的许多人可能是第一次听说 FIM。
我建议阅读 Codeium 的这篇博文，以了解 FIM 的直觉。OpenAI论文提供了有关训练的详细信息。
Codeium 是第一个将 FIM 集成到其扩展中的公司，击败了 Github Copilot，后者也于 23 年 5 月开始大规模支持它。您可以从博客中开始看到“快速工程”和“上下文窗口”等术语。
现代自动完成功能通过以下方式进一步发展：
LSP（语言服务器协议）集成，用于实时语法信息和符号引用
用于跟踪功能关系的强大代码库索引
通过 AST 和符号表分析增强上下文感知
从简单的文本完成到上下文感知代码生成的历程展示了我们已经走了多远，但这只是人工智能辅助编码可能性的开始。
时间线已经到了 2023 年 5 月。当然，我们不想仅限于自动完成。我们从 2022 年底开始使用编码助手。现在是时候讨论编码助手了，我们稍后会回到自动完成。
02 面向（对话式）编码助手和 AI 优先编辑
2022年11月30日，ChatGPT 研究预览，包含 GPT-3.5
ChatGeeBeeDee 3.5 可能是人们第一次开始意识到通过 LLM 生成代码的潜力。你可以与这个聊天机器人交谈，它可以为你解释整个代码块。如果你给它提供足够好的提示和相关的上下文，它可以提供准确的代码。
快进到 23 年 3 月，我们得到了 GPT-4 模型，它在代码生成方面表现非常出色。Copilot 集成了 GPT-3.5/GPT-4 以进行副驾驶聊天。
23 年 7 月之后，我们发布了 Llama-2，这引发了开源本地 LLM 领域的大爆发——在代码生成微调、角色扮演等领域。
1. AI 代码编辑器的机会
长期以来，工作模式是将代码转储到 chatGPT (Plus) 中，编写合适的提示，然后将代码复制粘贴回我们的编辑器。这也需要你找到正确的粘贴位置。我个人长期以来对这种工作流程很满意 xD，因为我可以更多地查看代码并仔细阅读差异。
另一个缺点是“上下文切换”的惩罚不仅限于更改窗口，还可能开始浏览。GPT3.5/4 的推出为各种 AI 编辑器开辟了市场空间。为了获得更好的开发者体验，有很多问题需要解决，主要是：
消除聊天平台和编辑器之间的上下文切换
从 LLM 输出中实现直接代码编辑
找到更有效地为法学硕士提供背景的方法
代码库索引/更好的上下文感知以提供给 LLM
2. 输入光标
挑战在于能否以流畅且低延迟的方式完成上述所有操作。我建议查看 cursor 的Problems-2023 博客。
Cursor 是第一个放弃 GPT-4 的公司，他们实现了聊天体验和差异编辑生成工作流程（他们会自动应用编辑并以差异格式显示）。事后看来，这对于利用 GPT-4 的炒作至关重要。快速交付和提供出色的用户体验是关键。
不久之后，Cursor 添加了部分接受和拒绝、代码库上下文等功能，这些功能可以在您的代码库中语义地搜索您的查询。后来，他们添加了 CMD+K（行编辑）、CMD+L（聊天）工作流程。
图片来源：Cursor Changelog
还有其他几个项目，例如 Continue Dev（也支持 OSS 模型）、Codeium，但它们没有像 Cursor 那样早地实现编辑体验。他们的 diff-apply（现在是 fast-apply）加上聊天界面也很流畅，很受人们的青睐。
3. 返回自动完成 → Copilot++
Cursor 的自动完成功能是我迄今为止使用过的最先进的自动完成功能。它就像我们讨论过的自动完成功能之王 - 它经过训练（或微调？），可以预测开发人员的下一步操作。非常有针对性。 “我做了这个更改，模型应该进行的下一行是第 18 行……模型应该知道这一点”。您可以尝试重构变量的名称，它会建议进行多行重构。您可以为函数签名或代码的一部分编写注释，它会相应地建议完成（使用 FIM ofc）。
Karpathy 转向 Cursor 可能是他们的一个转折点。但在我看来，Cursor 的主要转折点是 24 年 6 月下旬 Sonnet 3.5 的发布。它在代码生成方面比任何其他模型都要好得多，而且更具代理性（在指令跟踪和函数调用方面更好）。巩固的 UI/UX 体验，copilot++ 帮助他们乘上了 Sonnet 的浪潮。
4. Supermaven（主要实现自动完成）
Supermaven（由 Tabnine 创始人开发）也具有与 Cursor 相当的自动完成功能。我个人没有使用过它，因此根据传闻和阅读其他人的意见，它与 copilot++ 相当或略差，但肯定更快。SuperMaven 在发布时的特色是 100K 令牌上下文窗口（超过 GPT-4 和 Sonnet（200K 上下文）当时还不存在），这有助于为更好、更快的自动完成生成提供大量上下文。他们训练了自己的模型，并对原始自注意力进行了修改。
https://x.com/jbfja/status/1760780340342505653?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1760780340342505653%7Ctwgr%5E06ea0f0f572492c58b626d94bdf3cbc02139b87b%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fsankalp.bearblog.dev%2Fevolution-of-ai-assisted-coding-features-and-developer-interaction-patterns%2F
他们后来添加了类似 Copilot++ 的下一步动作预测功能（包括Cursor 可能还无法做到的跨文件跳转）和1M 上下文窗口。
Supermaven 没有集成聊天体验 - 它是一个扩展。由于 VSCode 的扩展 API 限制，他们无法添加几个功能。他们最近与 Cursor 合并。我很期待 Cursor 即将推出的代码库索引和自动完成体验。Jacob在这次采访中提到：
0:49-1:14：他们对人工智能编码的愿景和方法是一致的，并且有很大的重叠；
2:11-2:14：由于 VS Code 扩展限制，Super Maven 最终需要构建自己的 IDE，从而重复 Cursor 的工作；
2:35-2:52：两支团队的优势互补 - Cursor 专注于用户体验，而 Super Maven 专注于 AI 模型；
28:12-28:19：Jacob 的原话：“在 Super Maven 期间，我一直认为如果有另外一支队伍我愿意加入，那就是 cursor”。
我期待对制表符自动完成循环进行重大升级 - 它可能能够同时预测您在多个文件中的操作。supermaven 的 1M 长上下文模型应该可以改善自动完成功能以及光标聊天/作曲家代理模式下的上下文检测。
5. OSS 代码编辑器
2024 年，OSS 代码编辑器和扩展程序开始出现/越来越受欢迎/获得资金支持，例如 Continue dot dev（自动完成、OSS 模型、代码解释但不应用编辑）、Aider-chat（llm 聊天 + 通过终端编辑）、Pear AI、AIDE、avante.nvim 插件……就我个人而言，我发现只有 aider-chat 有点意思。我喜欢他们的博客。
03 模式
汽车的档位越低，您对发动机的控制力就越强，但速度也会降低。如果您感觉可以控制，请换到更高的档位。如果您不知所措或陷入困境，请换到更低的档位。人工智能辅助编码就是在您需要获得更精细的控制时以及在您需要放弃控制以更快地行驶时进行探索。档位越高，出现错误和信任问题的可能性就越大。提示是方向盘（2 档及以上）。
一小部分人的观察结果显示，资深人士或处于前沿的人更喜欢低档位。非技术人员则更喜欢高档位（讽刺）。
1. 1st Gear 自动完成
通过 LLM 生成代码备受重视，但模型级 UX 解锁（“嵌入权重”）真正让编辑器感觉像一个神奇舒适的地方是自动完成。自动完成可能是 AI 代码编辑器中第一个或第二个最常用的功能 - 您会发现自己在现有代码库中工作的频率比从头开始编写代码的频率更高。
如果你问高级工程师（他们仍然在写代码，而不仅仅是开会），他们会说他们主要使用自动完成功能。在 LLM 成绩还不够好的专业领域工作的人也可能从自动完成中受益最多。
当您在现有代码库上工作时，您所做的编辑比编写全新的代码要多。在生产代码库中，您会发现自己经常通过模式匹配来编写新功能。生产代码需要比粗略的笔触更多的精确性。
您主要在文件之间进行编辑，目标是在某处插入功能或修复某些错误，甚至可能进行重构。在这里，输入到模型中的本地化上下文（还记得 supermaven 1M 上下文模型吗？）非常重要。
我想要表达的观点是 - 自动完成功能满足了你对更精细地控制自己行为的渴望。这就像驾驶汽车时挂一档。档位越低，对汽车引擎的控制就越高。而一个好的自动完成模型可以通过确定确切的上下文和意图来满足你的控制偏好。
我喜欢 Cursor 工程师将自动完成功能构建为更通用的“下一步行动预测”模型问题的方式。
首先，我们扩展了 Copilot++ 来预测您的下一个位置。将此与下一次编辑预测相结合，该模型可以完成一系列低熵变化：
我们按 11 次 Tab 键，按 3 次其他所有键。我们称之为 “光标流” （原因很明显）。
我们正在努力预测您将移动到的下一个文件。您将运行的下一个终端命令。下一个编辑，取决于您之前的终端命令！ 下一步行动预测模型。
此外，模型应该在您需要时显示信息。无论它是正确的代码片段还是文档。
光标应该 感觉 像是你的意志的延伸。当你想到一个改变时，语言模型只需要最小的意图就可以立即执行它。
2. 2nd Gear - 对话式LLM / 独立聊天
很多编程工作可以归结为三件事：
知识
本地化语境
理解
如果您想在现有代码库中添加一项功能，并且您已准备好实施，那么下一步就是弄清楚您到底想在哪里进行更改。我之所以用粗体字写“fuck”，是因为我患有创伤后应激障碍，因为我需要挖掘庞大的 Java 代码库来查找想要进行更改的文件。（我也不能使用 AI，所以最快的方法是运行服务器并连接 Intellij 调试器。设置几个断点，然后了解程序的流程）。
这时，光标聊天等功能就派上用场了。您可以使用 @codebase 功能在整个代码库中提问，该功能使用跨代码库的语义搜索来搜索相关文件。发布后，您可以提出问题以加深对代码库的理解。
或者，如果允许复制粘贴，您可以复制相关文件或将整个代码库转储到 claude 的 200K 上下文或 1M 长的上下文模型（如 gemini 2.0 flash / 1206 exp）中，然后询问在哪里可以找到什么。
自动完成 + 聊天功能就像类固醇一样，尤其是在编辑或调试内容时。我觉得这是一种“认知水平”的解锁，因为你正在提高对代码的理解。
2024/5 年和发布中，人们非常重视代码生成，但很少关注如何使用这些工具来加深我们对代码库以及最终技术本身的理解。我想这是另一篇文章的主题了。
3. 3rd Gear - 光标聊天 + 应用编辑、风帆冲浪级联聊天
我会把从 ChatGPT/Claude AI 平台复制粘贴生成的代码放在第二档。它为用户提供了更多的控制权，因为他们必须手动确定更改的位置，而且速度较慢。还涉及上下文切换，这很容易受到更改标签和上网绕行的影响。
第三个档位可能是由 Cursor 引入的。解析 LLM 输出并将编辑应用于正确的位置。强调正确的位置，因为它节省了大量的劳动力，并解决了上下文切换问题。
diff 格式还帮助我快速检查代码。这样不仅速度快，而且我可以检查代码。控制权仍然存在，并且不会触发您的信任问题，因为您仍然可以验证更改（并拒绝更改）
由于 GPT-4 等模型中的惰性编码，这实际上是一个很难解决的问题，尽管 Sonnet 可能让开发人员更容易了。他们关于这个问题的博客已经不存在了，但最初主要是通过使用统一差异来解决的。他们后来添加了推测性编辑以使其更快。）
对于编写大量新功能或从 0 到 1 进行操作的人来说，3 档是一个最佳选择。
我对 Gear 3 的建议是将任务分成子任务，然后分别处理每个任务。确保刷新每个任务的上下文窗口。提示：加号按钮。
如果你在比较成熟的代码库中工作，那么你将在 Gear 1 到 3 中进行最多的操作。
4. 4th Gear - Agentic 功能 - Windsurf Cascade 和 Composer Agent 模式
值得一提的是：Composer - 普通模式对于多文件编辑和重构非常有用。它可以自行检测上下文，但说实话不太可靠。不过 Composer 代理模式解决了这个问题。
事情变得有点棘手。这种装备之所以可能实现，是因为像 Claude 3.5 Sonnet 这样的模型具有很强的代理能力。“代理”——用简单的语言来说，是指模型能够自行找出、计划并主动执行子任务以完成主要任务的能力。
更具体地说，该模型可以规划子任务，做一些事情，了解中间状态，查看中间上下文，调整其执行过程并完成最终用户任务。
代理能力是通过预训练和微调函数调用而“嵌入权重”的。当人们说一个模型具有代理性时，他们的意思是它能够准确地遵循你的指令（“很好地遵循指令”）并且它擅长工具/函数调用。
为了擅长代理代码生成，模型显然也需要非常擅长代码生成。Sonnet 在出色的编码技能和 SOTA 代理性能之间实现了良好的平衡。Sonnet new 在代理代码生成方面甚至更胜一筹。它比旧版 Sonnet 更积极主动。TLDR：代理模式是模型级别的一项功能解锁。
您可以在上面的视频中看到 Sonnet 如何多次调用“Artifact”来完成任务。我相信这是一个打开 Artifacts 的工具调用。这是代理性的。
Codeium 的Windsurf似乎是第一个在编辑器级别引入正确代理模式的编辑器。它的主要功能模式是“级联”。当我第一次使用它时，感觉就像瞥见了编码的不远的未来。
编辑：我几周前就体验过 Windsurf。他们现在还添加了聊天模式，您可以在其中集思广益并手动应用编辑。
您基本上可以给出一些高级指令，模型将继续规划和执行一系列任务，通过终端运行命令，创建文件等，以完成您的任务。它显示了它自己的“代理”。Windsurf 提供了一个很棒的界面来查看模型正在做的所有事情，并像 Cursor 一样显示不同的编辑。就 UI/UX 而言，我认为它比 Cursor Agent 模式更好。在检测上下文方面也略胜一筹（基于几周前的一些个人使用情况和朋友的传闻的观点）
编辑器中的“代理模式”对于重构文件和创建/编辑多文件非常有用。与开发阶段的中间阶段相比，当您处于 0 到 1 阶段时，它的实用性更强。不过，在文件检测方面可能会经常出现错误，或者只是代码不理想（生成大量代码，因此上下文窗口可能会令人筋疲力尽，知识截止问题）
为了更快地交付，您在这里放弃了很多控制权。编辑器实现了不同的视图，因此至少您可以查看更改。当我大致知道要编辑哪些文件时，我很乐意在光标中使用代理模式。
似乎经验较少的程序员更喜欢 Windsurf，因为 Cascade 很有吸引力（尽管我觉得他们最喜欢的是 gear 3）。Windsurf 与 Cursor 竞争激烈，但它仍然需要一些完善和对次要功能的支持（例如从链接获取文档）。Cursor 更以高级用户为中心，并提供更多可操作的 gear。也就是说，Windsurf 倾向于减少用户方面的决策。
个人观察
在编程中，卡住是很常见的。当我卡住时，我想尝试不同的操作模式 - 在那里我可以控制更多，速度也更慢。这样，可以选择从代理模式切换到较低档位（如聊天）是一种很好的方式，可以让我放慢速度并思考问题。初学者更容易陷入错误循环...
代理模式也会更快地耗尽你的请求配额。经验较少的人/非技术人员会在这里遭受更多痛苦，因为他们会更频繁地陷入循环。这就是为什么我更喜欢聊天+编辑模式，因为在这个模式下你可以更隐蔽地控制你的请求配额。
我喜欢的一种使用模式是 - 使用代理制作功能草稿（因为它可以在正确的位置创建文件）然后继续聊天+自动完成。
5. 5th Gear - 编码代理工具
我一直对代理持怀疑态度，但在推出新的十四行诗并最近参与一个包含代理成分的项目后，我意识到，如果你缩小要解决的问题范围，代理是有效的。你获得的价值在于减少人工时间。
我亲自尝试过 bolt.new。它的工作原理相同。范围很明确 - 使用固定的前端框架（LLM 也擅长）进行 0 到 1 的引导。bolt.new非常适合 0 到 1。一旦代码库成熟，您就会开始看到收益递减。
我们还看到了 Replit Agent 的出现，Devin，尽管我个人没有尝试过这些。这些是范围更广的端到端代理。如果你愿意的话，可以称其为“人工智能软件工程师”。例如，Devin 可以浏览你的代码库、做笔记、进行更改、报告。它可以异步工作（但根据我所读到的，它很慢）
代理都是关于如何失去控制以更快地完成任务。错误和事故的范围也是最大的，尤其是在范围广泛的代理中。我个人更喜欢编辑器（1 到 4 档），而不是编码代理工具。
6. 代理工具的常见缺陷及注意事项
您可以使用光标代理或 windsurf cascade 快速交付。独立工具也是如此。您只有在遇到困难之前才会很快，而当您遇到困难时，有时很难调试（尤其是对于经验较少的程序员或非技术人员）。由于知识过时，模型经常会陷入循环（例如，sonnet 无法调试 nextjs 15 对 nextjs14 的重大更改）。
您将必须阅读文档和 stackoverflow/github 讨论，以传统方式搜索解决方案。换挡 - 挡 2 和挡 3 在这里非常有效。我的建议是此时提高您对代码的理解。了解您要解决的问题，以便更好地提示或手动解决错误。
AI 辅助编码可以非常快，直到它
大多数减速都发生在功能的最后一英里 - 因此您需要了解代码中发生了什么。否则调试将会很痛苦。截图来自“ 70% 的问题：关于 AI 辅助编码的残酷真相”。我强烈建议阅读此博客，因为它提供了可操作的见解，以便更好地进行 AI 辅助编码。
隧道视野
避免狭隘的视野。如果你被困在某个地方，就休息一下。放开视野，开阔思路。与法学硕士或队友讨论替代方法，然后继续前进。
如果对某个领域不熟悉，请学习基础知识
我还建议你至少学习你正在做的任何工作的基础知识，以便更好地进行提示。学习基础知识意味着你能够将未知的未知数转化为已知的未知数。
现在该结束这篇文章了。这篇文章很长。
结论
AI 辅助编码今后只会越来越好。现在是我们充分利用它的时候了。我们已经有了非常强大的模型，它们只会变得更好。在整合上下文方面还有很多工作要做。抱歉，这个词在这篇博客中出现了 30 多次，但上下文才是关键。
我希望齿轮类比能对您的日常工作流程有所帮助。