10. 2023—2024：从补全代码到理解项目，AI 编辑器改变编程方式

来源：大模型技术演进

2024 年 7 月 13 日，Cursor 的一条更新记录介绍了实验性的 Composer：用户可以让 AI 跨多个文件进行编辑。公告很短，背后的变化却很大。AI 给出的结果，开始从聊天框里的一段代码，变成项目中一组需要共同审阅的修改。Cursor Composer 测试版公告

想象一下这种区别：以前，你让 AI 写一个搜索框，它返回一段可以复制的代码；现在，你提出“给这个项目加搜索”，工具开始有机会同时处理界面、数据读取和相关配置。后者仍然可能做错，但用户与工具分工的单位已经变化了。人不必逐段搬运答案，更多精力开始转向说明目标、检查修改和运行结果。

8 月 22 日，Cursor 宣布 Composer 默认向 Pro 和 Business 用户开启。同一天，开发团队在融资公告中报告已有超过四万名客户。这是公司自报的数据，不是独立市场份额统计；它至少说明，AI 编辑器已经不只是发布会上的概念，围绕它的使用和商业化正在形成。Composer 开放更新、Cursor 当时的公司公告

到这一年秋冬，GitHub Copilot 推出多文件编辑预览，Codeium 团队发布 Windsurf 编辑器，Cursor 也加入早期 Agent 能力。不同路线开始汇合到一个问题：如果 AI 要真正参与软件开发，应该怎样进入开发者正在工作的项目？

这篇文章就从这个问题出发。我们会回到代码补全的起点，再看聊天、项目上下文和跨文件修改怎样一步步结合。这里的 GitHub Copilot，是编程产品，与前面介绍的微软搜索助手、Microsoft 365 Copilot 分属不同产品线。

ChatGPT 出现之前，AI 已经站在程序员的光标旁边

2021 年 6 月 29 日，GitHub 发布 Copilot 技术预览。它使用当时的 OpenAI Codex，结合正在编写的代码提供整行乃至整个函数的建议。2022 年 6 月 21 日，GitHub 又向个人开发者正式开放 Copilot。这个时间早于 ChatGPT 的公开发布。Copilot 技术预览、2022 年正式开放记录

这里的 Codex 是早期代码模型的名称，不要直接与后来使用同名的编程 Agent 产品混为一谈。

代码编辑器原本就有自动补全。例如，输入一个对象名称后，它会列出可用的方法；输入函数调用时，它可以提示参数。大模型补全进一步尝试判断“接下来可能要实现什么”，不只从已有符号中挑选一个名字。

假设你写下一条注释，说明要把学习笔记按日期排列。模型可能据此提出一个排序函数。对使用者而言，新鲜之处在于：自己还没有完整写出来的意图，已经变成一段可接受、可修改或可忽略的代码。

这种方式与程序员原来的工作节奏相容。人选择正在修改的位置，AI 在附近提供建议，人决定是否接受。它特别适合较短、目标明确的代码，但项目的大部分组织工作仍由人承担：功能放在哪个文件，怎样连接现有接口，出了错应该先检查哪里。

补全有时也能使用周边文件的信息，所以不能简单理解为“早期 AI 只看得到当前这一行”。真正的区别在于，当时主要的交互单位仍是当前编辑位置附近的一段建议，而不是把完整需求交给系统持续处理。

2023 年，聊天进入编辑器，问题开始围绕现有代码展开

ChatGPT 让很多人意识到，可以直接描述一个编程问题，让模型解释或给出实现。但在网页聊天里开发项目，往往要反复搬运信息：复制代码、补充报错、解释文件之间的关系，再把答案放回编辑器。

即使模型回答得不错，这一来一回也会成为工作负担。尤其对初学者而言，最困难的可能不是写提示词，而是不知道该复制哪几段代码。漏掉一个调用方，模型就可能给出局部合理、放回项目却不能工作的修改。

2023 年 3 月 22 日，GitHub 公布 Copilot X 愿景，把基于 GPT-4 的聊天、代码解释、测试生成，以及开发流程中的其他辅助能力纳入方向。当时涉及技术预览和逐步推进的功能，不能写成一款名叫“Copilot X”的完整新产品已经全部上市。Copilot X 原始公告

到 12 月 29 日，Copilot Chat 在 VS Code 和 Visual Studio 中正式可用，并纳入现有 Copilot 方案。这才是编辑器聊天从此前预览走向正式开放的明确节点。Copilot Chat 正式开放公告

聊天放进编辑器，价值并不只是少开一个网页。编辑器掌握着一些与任务直接相关的信息：你选中了哪段代码、正在看哪个文件、当前出现了什么错误。产品可以围绕这些信息组织提问和修改，使对话更贴近实际工作。

例如，同样一句“为什么这里返回空结果”，在普通聊天框里缺少对象；在附带相关代码与报错的对话里，它才有明确的指向。自然语言逐渐成为与项目交互的一种入口。

但问答与编辑仍然有差别。模型解释了一个 bug，并不代表文件已经改好；生成了完整函数，也不代表它与项目其他部分一致。如何把建议落到正确的位置，成为下一阶段的重要问题。

Cursor，把 AI 参与编辑的过程放到产品中心

Cursor 是这条发展线上的代表性产品。它的早期更新记录可以追溯到 2023 年；3 月 18 日的记录已经涉及内置终端与代码差异显示，而让聊天建议自动插入编辑器，当时还被列为即将推出的功能。这样的史料很有价值：今天看似自然的操作，也是逐步补出来的。Cursor 早期更新记录

代码差异通常叫 diff，它把修改前后新增、删除或替换的内容显示出来。对 AI 编程来说，diff 是一个关键界面：用户需要看到 AI 究竟改了什么，才能决定接受多少，而不只是读一句“已经帮你优化好了”。

到了 2024 年，Cursor 中的补全、对话和 Composer 提供了不同粒度的协作方式。补全帮助继续当前编辑，对话帮助理解和讨论，Composer 则把一次要求延伸到多个文件。它们可以共存，并不是每次写代码都需要启动最大范围的自动修改。

从用户角度看，跨文件编辑带来的吸引力在于减少连接工作。一个功能往往散落在几处：按钮在界面文件里，请求在另一个模块里，返回数据的格式又在别处定义。让工具同时提出相关修改，比逐段复制代码更接近人们心中的“帮我完成这个改动”。

不过，决定改什么与实际改对文件，是两个问题。Cursor 在 2024 年 5 月介绍过 fast apply 的技术工作：把规划修改与应用修改分开，并训练专门模型提高应用代码变更的速度与准确性。本文不把文章标题中的速度数字当作任意项目的实测保证。Cursor 关于快速应用修改的研究

一个简单例子就能说明这种分工。模型提出“给所有笔记列表项增加一个收藏按钮”，不等于它应当重写整个页面。应用修改时，需要保留已有排序、样式和事件处理，把新增内容放进正确位置。改动意图对了，应用过程仍然可能漏掉代码，或覆盖无关内容。

因此，AI 编辑器的发展同时包含模型能力和编辑工程。更好的模型提出更有用的方案，更好的产品让方案以可检查的方式进入项目。

“理解项目”，需要先解决哪些信息进入模型

所谓项目，通常不是一个长文件，而是一组有关系的文件。界面调用服务，服务读取数据，配置决定运行方式，测试说明某些行为必须成立。开发者说的“这里不能这样改”，往往来自这些关系。

让模型参与项目工作，首先需要提供相关背景。可以是用户明确选择的文件，也可以是工具通过名称、符号、文本搜索或语义检索找到的内容。不同产品、不同版本会采用不同组合，不能仅凭“理解整个代码库”的宣传就推断具体内部机制。

这与第 5 篇的 RAG 有相通之处：外部材料先被组织，再按问题选取。代码搜索除了意思相近，还常需要精确名称。例如，要查某个函数被谁调用，只看一段语义相似的代码可能不够；需要追踪实际引用和接口关系。

第 8 篇的长上下文则让更多相关材料有机会进入一次任务。但窗口再长，也不等于每次应该塞进全部文件。依赖库、生成文件、历史备份和当前问题可能毫无关系，混入过多内容会增加成本，也可能干扰判断。

更强的基础模型使这种协作更有希望。2024 年 6 月发布的 Claude 3.5 Sonnet，就把代码修改与借助工具执行代码列为重要能力。这里的条件包括相关工具和指令，不是模型在任何聊天窗口里天然拥有文件系统与终端。Claude 3.5 Sonnet 发布说明

基础模型与编辑器由此形成两层分工。模型处理提供给它的上下文并提出判断；编辑器决定怎样取得上下文、如何调用模型、怎样应用结果。即使两款工具使用同一基础模型，检索、提示、修改方式和等待时间不同，体验也可能明显不同。

“项目已建立索引”同样不等于模型被训练成了你的专属模型。索引主要帮助查找材料；本次究竟读取了哪些文件，仍然影响结果。模型能找到一个函数，也不代表它已经知道项目里所有隐含约定。

GitHub 的多文件编辑，说明变化并不限于独立 AI 编辑器

2024 年 10 月 29 日，GitHub 的 VS Code 更新记录公布多文件编辑预览。用户可以围绕一组文件发出要求，让改动直接出现在编辑器中。11 月的设计说明进一步解释了 Copilot Edits 的工作集与审阅方式。2024 年 10 月更新记录

工作集可以先理解为：这轮编辑要围绕哪些文件进行。用户限定范围，再检查提出的修改，接受、撤销或继续补充要求。产品把“选背景—提出变更—检查变更”的过程放在同一个工作环境里。Copilot Edits 设计说明

这里出现了两种产品路线：在既有编辑器中增加更深的 AI 能力，以及围绕 AI 协作构建独立编辑器。前者可以延续已有开发习惯，后者可以更主动地组织交互。它们并没有一条简单的能力分界线，独立客户端不天然更聪明，插件也不天然只能补全。

真正需要比较的是任务如何完成：谁选择上下文，谁决定修改范围，结果如何进入文件，用户能否清楚检查。界面长得像聊天窗口，不代表背后的工作方式相同。

Windsurf 与早期 Agent，让修改开始连接执行反馈

2024 年 11 月 13 日，Codeium 团队正式发布 Windsurf Editor。发布材料把 Cascade 作为核心体验，结合代码库背景、编辑与搜索工具，并尝试跟上用户在编辑器中的操作。其工具范围已包括新增和修改文件、搜索以及代码执行。Windsurf 首发公告

这条路线触及一个真实的协作问题：人不会在 AI 工作时永远停手。你可能自行改了一个参数，删除了一段实现，或者先修好一个小问题。助手再次行动时，需要依据当前状态，而不是继续照着几分钟前的旧代码提出修改。

我们可以把它理解为“共同处理一个持续变化的项目”的尝试。发布材料中的全知、无缝等表述属于产品愿景，不能直接当作可靠性结论。捕捉到了人的操作，也不意味着一定正确理解了人的意图。

11 月 24 日，Cursor 0.43 的更新也明确写入 Composer 中的早期 Agent：它能够自行选择上下文并使用终端。终端是运行命令的入口，意味着系统可以开始把文件修改与运行结果连接起来。Cursor 0.43 更新记录

所以，2024 年末已经存在通向 Coding Agent 的明确过渡。我们把 2025 年的 Agent 发展放在后面的专篇展开，是为了讲清更广泛的产品演进，而不是把它写成在某个年份突然发明的新东西。

这几种协作方式，可以按用户交出的工作来区分：

协作方式	用户主要交给工具什么	仍需关注什么
代码补全	当前编辑附近的下一段代码	建议是否符合当前意图
编辑器问答	解释、分析或给出修改方案	背景是否充分，建议是否已实际应用
多文件编辑	一个涉及多处代码的改动	文件之间是否保持一致，改动范围是否合理
早期 Agent	寻找材料、修改、执行与根据反馈继续	任务是否真正完成，失败后如何恢复

这是理解任务分工的分类，不是互斥的产品标签。同一编辑器可以同时提供这些能力；后来功能变强，也不会让简单补全失去价值。

用一次“收藏笔记”改动，看清项目协作的含义

继续前几篇的个人复习助手。下面是教学构造：假设它已经有笔记列表和本地保存功能，现在想给每条笔记增加收藏状态，并且关闭应用后仍然保留。

如果只把它理解成“画一个星星按钮”，任务会显得很小。但真正的功能至少涉及几个相互联系的地方。列表需要展示状态，点击需要更新数据，保存格式需要记录状态，重新打开应用时还需要把它读回来。旧笔记没有这个字段，也应当能够正常显示。

补全工具可以帮助写其中一个事件处理函数；聊天助手可以解释应该怎样设计；多文件编辑则有机会同时修改相关部分。早期 Agent 再往前一步，可以运行已有检查，根据报错继续修正。这些能力减少了不同种类的人工工作。

但一句“已完成收藏功能”，无法说明哪一步真正成立。一个常见的假象是，点击后星星变亮了，刷新页面却又消失了。局部界面行为正确，保存与恢复仍然没有打通。

要描述这个任务，可以把完成条件说得更具体：点击后状态立即变化；重新打开后仍然保留；没有收藏字段的旧笔记默认未收藏；原来的删除和排序继续可用。这不是提示词口诀，而是把模糊愿望转成可以观察的行为。

检查也可以围绕同一组行为展开。先创建一条普通笔记，收藏后重新打开，确认状态仍在；再打开已有的旧笔记，看看是否报错；最后试一下原来的列表操作。这里描述的是验证思路，不声称已经执行过某个真实项目。

代码差异与运行结果提供不同证据。diff 帮助你判断修改是否只涉及相关范围，运行检查则帮助确认功能是否实际成立。两者都比接受一段流畅的完成说明更有说服力。

对于非专业程序员，这个变化很有价值：不必先熟练掌握每一处语法，才有机会尝试实现功能。但依然需要逐渐学会识别哪些文件承担什么职责，以及怎样判断结果。工具可以降低起步门槛，不能替用户决定“这件事到底算不算做成了”。

写得更快以后，瓶颈会移动到哪里

AI 编程的价值并非没有实验证据。2023 年公开的一项 Copilot 对照研究，让参与者用 JavaScript 实现 HTTP 服务器，报告使用 Copilot 的实验组完成任务更快。研究有明确任务与实验条件，不能据此断言所有真实项目都能按相同比例提速。Copilot 生产率研究

到了多文件编辑阶段，类似的边界更值得留意。一次生成更多代码，可能减少重复劳动，也可能同时扩大检查范围。模型改了十个文件，不自动意味着完成了十倍的有效工作；有时真正需要的修改只有两处。

对个人项目而言，效率可以从完整过程来看：理解需求花了多久，找到相关代码花了多久，应用修改是否顺畅，测试和返工又花了多久。只看生成速度，会漏掉大量决定交付结果的时间。

这也解释了为什么快速补全、较慢但深入的任务处理会长期共存。打字时的建议需要及时出现，复杂需求则可能值得等待更多分析。产品需要在不同环节安排模型和计算，而不是让每一个动作都使用同样的处理方式。

2023—2024 年留下的主要变化，是 AI 从一个提供代码答案的入口，逐步进入软件被理解、修改和检查的现场。Copilot 把辅助带进已有编辑器，Cursor 把更连续的 AI 编辑放到中心，Windsurf 等产品进一步把上下文、工具和人的操作联系起来。

这些产品的进展与模型能力相互推动：更强的代码理解和指令遵循，让更大范围的修改成为可能；编辑器又把模型连接到真实文件、错误和反馈，让能力有了可以反复使用的形态。新的瓶颈随之变得清楚——上下文选择、可靠执行、验证，以及持续使用的成本。

下一篇将把焦点放到最后一个问题：2024 年，随着 DeepSeek V2/V3、Qwen、豆包等模型及相关推理技术的发展，效率、价格和速度怎样改变了开发者能够负担的应用范围。

---

本文属于第 0 部分“大模型发展史”；全系列观察截止日期为 2026 年 10 月 3 日。本文按历史版本描述产品，不是当前功能或套餐说明。“搜索”“收藏笔记”等项目场景为教学构造，未声称完成真实软件测试。

---

上一篇：09｜2024：模型能看、能听，交互从文字走向多模态

下一篇：11｜2024：效率、成本和速度改善，更多应用开始做得起

返回：第 0 部分大纲