人工智能可以在代码生成与自动补全方面显著放大生产力与创造力。本章将探讨由 AI 驱动的工具如何重塑编码体验，把原本耗时的手工过程，转变为一种交互式、高效率、并且能减少错误的工作方式。
AI 在代码生成领域的出现，并不仅仅是为了加快开发者的打字速度；更重要的是，它能理解开发者正在做的事情的上下文，给出相关的代码片段建议，甚至在极少输入的情况下生成复杂的代码块。这些工具由复杂的机器学习算法驱动，能够从公有与私有数据库中海量的代码仓库里学习，从而持续提升建议的质量与准确性。
我将分析：在一个具体的软件开发任务中，软件工程师如何从“自己完成 100% 的工作”，转变为“审阅由 AI 工具提供的贡献”的角色。这需要你向这些工具提供关于需求的正确输入，并对输出进行彻底修订，以确保交付物满足要求。
这些 AI 工具强大而令人印象深刻，人们很容易掉进一个陷阱：在缺乏必要防范的情况下直接使用它们的输出——比如还没验证代码为何能工作、如何工作，就直接开一个 pull request，或者把代码推到生产环境。这样的粗心做法带来两项重要风险：
过时代码
大多数 AI 工具训练所用的数据已经不再最新，这意味着它们可能会建议过时的框架或功能用法。
错误答案
支撑这些工具的核心技术——大语言模型（LLM）——有时会生成通常被称为“幻觉”的内容。也就是说，输出可能包含错误陈述、bug，或者根本不存在的代码函数或 API 端点。
软件工程师与开发者必须使用 AI 工具来帮助自己工作得更好、更快，但不能让它取代自己的判断——就像我们对待大多数集成开发环境（IDE）里已经很常见的自动补全功能那样。当然，用 tab 键补全而不是逐字符敲代码确实省事；但自动补全的建议有时完全贴合，有时则毫无用处。是否采用或丢弃它，取决于你的判断。
本章介绍的 AI 工具同样需要这种持续的评估。很多时候，它们生成的代码能完美运行，并且完全符合任务需求；但在另一些情况下，它可能只完成了一部分，或包含 bug、性能问题，或其他必须修订的缺陷。你需要做的，就是决定：使用、丢弃，还是修改它。
代码生成工具的类型
本章评测的 AI 工具主要分为两大类，在软件开发中的使用方式略有不同：
基于浏览器的工具
使用这类工具（例如 ChatGPT）时，你在浏览器里登录并直接与模型交互。你的本地电脑上并没有实际执行什么操作，本质上只是通过互联网与一个网站交互。这类工具易用、适配的场景也更多，但最大缺点是上下文窗口有限。每次交互你都必须手动在提示词里输入或复制/粘贴上下文；当你面对大型代码库或大量文档时，这就会成为限制。
基于 IDE 的工具
这类工具（例如 GitHub Copilot）以插件形式安装在你本地电脑的 IDE 中，也就是你写代码的环境里。安装后，它们会嵌入到你的开发体验之中，直接出现在你编写代码的现场。它们最大的优点是上下文窗口更大：这类工具能够把整个代码库作为每次交互的上下文输入。
使用场景
数以百万计的软件工程师正在采用 AI 工具来支撑日常工作。在开发过程中，这些工具影响最明显的五个使用场景是：
生成代码片段
你不再需要在代码库里逐字逐函数地敲出来，而是向 AI 工具给出代码应满足的具体要求。它会用主流编程语言（如 Java、Python、PHP 或 JavaScript）输出可直接使用的代码。这既能加速原型验证，也能加快开发流程。本章讨论的工具可以为广泛的应用生成代码，包括 Web 开发、数据分析、自动化脚本或移动应用开发。总体而言，这是一类 AI 帮你弥合“想法到落地”的鸿沟、让技术开发更可达、更高效的场景。
调试
这个场景尤其有价值，因为调试往往是软件开发中最耗时、也最令人沮丧的部分。AI 工具会分析错误信息与有问题的代码片段，并建议具体的修改或改进。这既节省时间，也能充当一种学习工具，让你的调试能力随时间提升。一些工具（如 ChatGPT）还能解释为什么会出现某些错误，有时甚至会解释为避免这些错误所隐含的架构取舍。对软件开发中常见陷阱的这种更深理解，正是许多开发者把 AI 当作编程助手的关键原因之一。
加速学习
如果你想在自己并不熟练的技术栈里快速上手、学习一门新的编程语言或框架，或者理解某些具体实现细节——例如在 MySQL 里为表添加索引，或从 Stripe API 拉取上个月的交易记录——AI 工具可以充当讲师。它们能提供教程、示例，以及对各类技术文档的精炼总结。通过与 AI 工具的这种教学式互动，无论你学习的具体技术是什么、学习范围多大，都能更快成长。
优化代码
许多软件工程师用 AI 工具来审阅代码，让其更高效、更易读、更易维护。这包括重构建议、更高效算法的建议、以及性能或安全方面的最佳实践。代码优化是一个持续性的挑战，也很容易被忽略；但终究，那些不够理想的代码会不断累积成巨大的技术债，最后不得不以大范围、因而成本很高的方式在全代码库层面重构。用 AI 工具在任务粒度审阅代码，能对整体代码库质量产生显著影响。
自动化文档
文档对维护和理解软件项目至关重要，但开发者常常忽视或优先级不足。有些 AI 工具可以生成文档，包括行内注释，以及关于函数、类、模块的说明。这既节省时间，也能确保文档与代码库同步保持更新。通过提供清晰、全面的文档，AI 工具能提升代码可读性，让团队协作更容易。这个场景在大团队或开源项目中尤其有价值，因为清晰的文档是其他开发者有效参与贡献的关键。自动化文档也能提升项目的可维护性，并促进开发团队内部更好的知识传递。
如前所述，面向软件开发的 AI 工具有两大类：基于浏览器的与基于 IDE 的。我们将从基于浏览器的工具开始介绍。
基于浏览器的工具
基于浏览器的 AI 工具只需访问一个网站即可使用，因此非常方便。另一方面，这类工具要求用户把所有上下文都写进提示词里。这使得它们在面对大型代码库、或为复杂应用生成代码时不太实用，因为那通常需要在浏览器工具与软件工程师实际写代码的 IDE 之间进行大量复制/粘贴式的交互。
ChatGPT
ChatGPT 是由 OpenAI 开发的大语言模型（LLM），可能也是本书将要介绍的 AI 工具中使用最广泛的一款。自 2022 年 11 月发布以来，ChatGPT 经历了爆炸式增长。到 2025 年 4 月，它的每周活跃用户数约达 8 亿，并且在短短几周内就把用户规模翻了一倍。该平台每天处理超过 10 亿次查询，已成为全球访问量排名前五的网站之一。1
随着 ChatGPT 的走红，OpenAI 的营收也大幅飙升，预计 2025 年将超过 127 亿美元，而 2024 年为 37 亿美元。这一增长由其 Plus、Team 和 Pro 等档位的 2,000 多万付费订阅用户推动，仅订阅就至少贡献了每月 4.15 亿美元的收入。如此迅速的普及，很大程度上归因于它持续的创新。2024 年 5 月推出的 GPT-4o 带来了多模态能力，使用户能够通过文本、语音和图像进行实时交互。之后的更新——包括原生图像生成，以及 GPT-4.1 和 o3 等更强的推理模型——进一步增强了其功能。2
ChatGPT 的演进，使它从一个基于文本的聊天机器人转变为一个多用途的 AI 助手，重塑了个人与企业与技术交互的方式。它友好的界面与强大的能力，使其成为广泛应用场景中不可或缺的工具，从个人生产力到企业级解决方案皆是如此。
如图 1-1 所示，ChatGPT 提供了一个聊天机器人式的界面，用户可以输入提示词，并在几秒内获得回复。OpenAI 最近还新增了 ChatGPT 代码编辑器，可在屏幕右侧打开，并配有控制台与预览功能。
图 1-1. ChatGPT 界面
这是 OpenAI 试图弥合“基于浏览器工具”和“基于 IDE 工具”之间差距的一次尝试。允许开发者直接在 ChatGPT 内编辑并运行代码，旨在尽量减少在 ChatGPT 与开发者 IDE 之间的复制/粘贴操作。
Google Gemini
Gemini 是 Google 对标 ChatGPT 的直接竞争产品，于 2023 年 12 月发布，是其前身 Bard 的升级演进。Gemini 能无缝融入 Google 的生态系统，在 Gmail、Docs 和 Sheets 等应用中增强用户体验。到 2025 年 4 月，Gemini 已拥有相当规模的用户群，月活用户约为 2.75 亿。3
随着诸如 Gemini Live（提供实时对话式协助）以及 Audio Overviews（把文档转换为播客风格的摘要）等功能的引入，Gemini 的能力不断扩展。此外，Gemini Advanced 用户还可以根据文本提示生成短视频，从而在无需传统视频制作工具的情况下完成内容创作。
该平台的增长还得益于超过 150 万名开发者使用 Gemini 进行构建，为其多样化应用贡献力量。作为 Google 将 AI 作为战略重点的一部分，Gemini 持续演进，提供覆盖广泛用户需求的创新解决方案。
与 ChatGPT 类似，Google Gemini 也提供聊天界面，用户可以提交提示词并获得回复。它同样推出了“浏览器内开发环境”的体验：屏幕右侧有代码面板与预览面板（见图 1-2）。对许多软件工程师而言，这个便捷功能使 Gemini 足以胜任小型脚本与小项目的开发。
图 1-2. Google Gemini 界面
基于 IDE 的工具
接下来，我们来回顾市面上最主流的 IDE 端工具，它们用于帮助软件工程师工作，既包括原生集成 AI 的 IDE，也包括面向主流 IDE 的 AI 助手插件。
GitHub Copilot
GitHub Copilot 于 2021 年推出，并迅速演进为软件工程师的重要工具。它提供 AI 驱动的代码建议，并可在多种开发环境中集成使用。到 2025 年，Copilot 拥有超过 100 万付费订阅用户，并被超过 77,000 家组织使用，企业端采用率同比增长 180%。该工具也显著推动了 GitHub 的财务增长：截至 2025 年 4 月，GitHub 平台年化收入运行率达到 20 亿美元，其中 Copilot 贡献超过 40%。4
Copilot 的功能早已超越基础的代码补全。它现在包含诸如 Copilot Chat 等特性，使开发者能够与 AI 进行交互，获得代码解释与建议；还包括 Copilot Extensions，可与 Azure、Docker、MongoDB 等工具集成。此外，Copilot Pro+ 的推出让用户可以使用更高级的 AI 模型，包括 Anthropic 的 Claude 3.7 和 Google 的 Gemini Flash 2.0，从而增强了工具的通用性与覆盖面。
Copilot 对开发者生产力的影响相当明显。研究显示，使用 Copilot 的开发者编码效率最高可提升 55%，并且报告更高的工作满意度。5 随着持续迭代与用户规模增长，GitHub Copilot 正在重塑软件开发版图，让全球开发者的编码更易上手、更高效。
Copilot 的界面不会改变它所安装的 IDE 的默认使用体验；但它增加了一层键盘快捷键，允许用户打开聊天功能——既可以作为右侧面板（如图 1-3 所示），也可以在代码视图中以内联方式触发，用于自动补全或与特定代码块交互。
图 1-3. GitHub Copilot 界面
GitHub Copilot 可与所有主流 IDE 集成，例如 Visual Studio Code、JetBrains、Eclipse 和 Xcode。这让它从一开始就实现了平滑增长：多数软件工程师本来就在使用这些 IDE，因此安装 GitHub Copilot 只需在扩展市场里点一下即可。
这种把 AI 助手推向软件开发市场的路径，随后受到了所谓“AI 原生 IDE”的挑战——下一节我会介绍。另一个变化是：Copilot 过去只提供 OpenAI 模型；但自 Cursor 与 Windsurf 走红之后，Copilot 也开始提供从 OpenAI、Anthropic 和 Google 等模型中进行选择的选项。
Cursor
Cursor 由 Anysphere 于 2023 年推出，并迅速崛起为领先的 AI 原生代码编辑器，重新定义了软件开发体验。它基于 Visual Studio Code 的一个分支（fork）构建，将高级 AI 能力直接集成进编码环境，提供智能代码生成、智能重写、以及用自然语言查询整个代码库等功能。与 GitHub Copilot 以及其他主流 IDE 的扩展（如 Tabnine 或 AWS CodeWhisperer）不同，Cursor 本身就是一个需要用户下载安装到设备上的 IDE。因此，它不仅与 GitHub Copilot 等扩展竞争，也与 Visual Studio Code 以及所有主流 IDE 直接竞争。Cursor 刚推出时，这被视为一种非常大胆的策略。
到 2025 年初，Anysphere 达成了一个非常亮眼的里程碑：年经常性收入（ARR）达到 2 亿美元。这一增长很大程度上归功于 Cursor 以用户为中心的策略：超过 360,000 名个人订阅用户选择了其 Pro 与 Business 方案。值得注意的是，Anysphere 在几乎没有任何市场投放的情况下取得了这一成绩，主要依靠口碑传播以及 Cursor 强大的功能集来吸引用户。6
Cursor 的成功还体现在它被多家知名科技公司的工程师采用，其中包括 OpenAI、Shopify 和 Instacart。它直观的界面与强大的 AI 集成，使其成为希望提升生产力、简化编码流程的开发者的偏好工具。考虑到大多数软件工程师多年来一直使用同一款 IDE、切换成本很高，这种偏好尤为显著。
Cursor 的界面（图 1-4）与 Visual Studio Code 很相似——毕竟它是后者的一个分支。与 GitHub Copilot 类似，它也提供一系列快捷键来启用功能：从与特定代码块的内联交互，到用于更复杂交互的聊天面板。
图 1-4. Cursor 界面
Cursor 的聊天交互会为了满足用户需求而创建文件与文件夹。当建议的代码令人满意且运行正常时，这非常方便；但一旦建议的代码破坏了应用、或影响了原本正常工作的功能，要回滚就会变得很困难。事实上，这是我对 Cursor 以及本章其他 IDE 端工具最大的抱怨之一。
Windsurf
Windsurf 由 Codeium 于 2024 年 11 月推出，是一款 AI 原生 IDE，旨在革新编码体验。它建立在 Codeium 早期工具的基础之上，引入了一种面向软件开发的“智能体化”（agentic）方法，把 AI 辅助与开发者工作流融合在一起。其旗舰功能 Cascade 充当一个智能代理，能够预判开发者的需求，提供具备上下文感知的代码建议、自动化调试，以及实时协作能力。
到 2025 年初，Windsurf 在开发者社区引发了显著关注，估值约为 27.5 亿美元，年经常性收入超过 4,000 万美元。平台的快速采用归因于其直观的用户界面、AI 功能的深度集成，以及包含免费档位、并提供每月 10 美元的可负担 Pro 版本的定价模式。
Windsurf 的创新特性——例如多文件编辑、自然语言指令支持、以及完整的上下文感知能力——使其成为 AI 驱动开发工具赛道里极具竞争力的选手。它强调帮助开发者保持“心流状态”（flow state），让编码更高效、更少被打断，并为现代 IDE 的体验设立了新的预期标准。
Windsurf 的界面（图 1-5）与 Cursor 相似。它同样提供一系列快捷键来启用功能，包括与特定代码块的内联交互、打开聊天面板进行更复杂的交互，以及内置终端。
图 1-5. Windsurf 界面
工具对比
为了筛选出本章重点介绍的工具，我评估了 30 多款 AI 工具。本章涵盖的每一款工具都满足以下标准：
- 是一个专业项目，背后有能力过硬的团队。
- 其生成代码的质量门槛较高。
- 提供一定程度的免费功能或试用。
- 在写作时（2025 年中）拥有较高的采用度。
我在本章采用的流程如下：我给每一个入选的代码工具提交一个简短的代码挑战，在每个工具里对同一个挑战严格只运行一次，然后比较它们的输出。接着，我按 1 到 10 的尺度给每个工具打分：1 分代表最差（解答报错、完全跑不起来），10 分代表无可挑剔的解答；5 分则代表解答能运行，但只解决了问题的一部分。
本章描述的所有测试都在 2025 年 4 月完成。考虑到这些工具及其底层模型的迭代速度很快，你在之后的某个时间用同样的提示词，很可能会得到不同的结果。
我给每个工具的提示词完全相同，内容是一个我作为面试官在数十场编程面试里使用过的代码挑战：
用 JavaScript 生成代码来解决以下挑战。
背景：
- 我们有一个二维数组，数组中只包含 0 和 1。
- 我们需要找出所有由 0 组成的矩形的起点和终点。
- 已知这些矩形彼此分离、互不接触；但它们可以贴着数组边界。
- 一个矩形可能只包含一个元素。
期望输出：
- 返回一个数组，其中每个元素代表一个矩形。
- 每个矩形元素本身是一个包含 4 个元素的数组，用来描述矩形（左上角 Y、左上角 X、右下角 Y、右下角 X）。
示例数组：
input1 = [ [1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 0, 0, 0, 1],
[1, 1, 1, 0, 0, 0, 1],
[1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 1, 1, 1, 1] ]
input2 = [ [0, 1, 1, 1, 1, 1, 0],
[1, 1, 1, 1, 1, 1, 1],
[1, 1, 1, 0, 0, 0, 1],
[1, 1, 1, 0, 0, 0, 1],
[1, 1, 1, 1, 1, 1, 1],
[1, 0, 0, 1, 1, 1, 1],
[1, 0, 0, 1, 1, 0, 0],
[1, 0, 0, 1, 1, 0, 0] ]
这是一个二维数组挑战，属于算法类谜题。通常，我会在一场一小时的现场手写面试（live-coding interview）开始时，把题目说明几乎原封不动地给到候选人，就像我这里给每个工具的一样。候选人随后一边口述思路一边写出解法，过程中偶尔会用 Google 搜索一些帮助。
在这场一小时的面试里，几乎没有候选人能解出题目的完整范围（多矩形）。大多数候选人会给出部分解法，只能找到一个矩形，或者只能找到左上角，或者是其他某种变体。图 1-6 展示了我在运行各个工具的解法后截取的控制台日志截图。
图 1-6. 运行各工具对该代码挑战的解答结果
如图 1-6 所示，这五个工具都对该代码挑战返回了正确结果。每个工具生成的代码都可在本书的 GitHub 仓库中找到。ChatGPT、Gemini 和 Windsurf 给出的解法代码清晰且高效；我对它们的结果没有任何负面评价。Copilot 和 Cursor 使用了深度优先搜索（DFS）算法——这种算法通常用于遍历树结构，对这个特定问题而言属于“大材小用”。这种额外复杂度会让它们能处理非矩形的形状，但这并不是本题要求。
无论我如何做代码分析，事实是：这些工具只用了几秒钟，就给出了一个完美结果，而这样一道题在一小时内能完整做出来的候选人却屈指可数。
这让我意识到：以这些 AI 工具当前的发展水平，这类代码挑战已经过于简单。基于这个测试，我会给它们全部打 10/10。因此，我决定给每个工具再出第二个、更复杂的挑战：要求它们创建一个完整可运行的应用：
我想做一个待办清单（to-do list）应用，需求如下：
- UI 要简单，包含一个看板（Kanban board）和一个 “New task” 按钮。
- 点击 “New task” 按钮会弹出一个模态框，用来创建新便笺，模态框里只有一个简单的 textarea 输入框。
- 添加新任务后，后端会通过与 OpenAI 的 API 集成，自动拉取分步说明（step-by-step instructions）。
- 所有便笺都存入数据库；每条便笺有三个字段：用户创建的任务标题、从 OpenAI 拉取的说明、以及时间戳。
同样，你可以在本书的 GitHub 仓库中看到这五个工具分别产出的解法。下面是各工具解法的截图与我的分析。
ChatGPT
ChatGPT 的解法运行得很好。我觉得它生成的仓库结构容易理解，把所有内容复制/粘贴到对应文件也不难；而且当我第一次运行解法遇到一些配置错误时，它也能很好地带我排查。几分钟之内，我就在浏览器里把应用跑起来了，如图 1-7 所示。
图 1-7. ChatGPT 生成的应用
默认界面里有 “New task” 按钮；点击后，屏幕中央会出现一个模态弹窗，我可以在里面写任务。点 Create 按钮后，后端会花几秒钟向 OpenAI API 发起请求。最后，它会显示一张任务卡片，里面是 ChatGPT 生成的任务说明（图 1-8）。
图 1-8. ChatGPT 生成的说明
在我看来，ChatGPT 在这项任务里表现非常好：无论是生成的代码、运行代码的说明，还是我提出的调试请求，它都处理得不错。我依然觉得略显负担的一点是：使用 ChatGPT（以及任何其他基于浏览器的助手）时，我必须把所有文件的内容复制/粘贴到我的 IDE 里。即便这个 to-do list 这样基础的项目，也包含十几个文件，嵌套在 client 与 server 文件夹以及它们的子文件夹之下。在这个层级上就已经容易出错、也很难追踪改动了——这会成为使用 ChatGPT 等浏览器助手处理更复杂项目、尤其是代码库更大时的一道主要障碍。
从代码评审的角度看，ChatGPT 的解法是一个经典的 React.js + Express.js 项目骨架：它用一个看板式 UI、“新建任务”的模态框，以及一个能工作的 OpenAI 调用，把需求干净利落地覆盖到位，并且都放在环境变量后面。代码库以直观的 client/server 方式拆分，使用了现代 React hooks、async/await，以及较为克制的错误处理。
不足之处在于：所有任务都只存在内存里，因此服务器重启就会清空看板；并且没有任何输入校验、鉴权或限流。这些缺失让它明确停留在“原型”层面；但它也没有明显的安全漏洞，因此可以作为一个安全的起点，后续再加固与扩展。ChatGPT 的浏览器形态让把代码复制/粘贴到正确文件里这件事变得更麻烦；但完成这一步后，解法无需太多反复就能跑起来。
解法 UI 基础，但确实满足需求，代码质量也相当不错。基于这些，我给 ChatGPT 在本次测试中打 8/10。
Google Gemini
Gemini 的解法没有跑起来。我像对其他工具一样投入了同样的时间，最终也整理出了一个能跑的版本——你可以在本书的 GitHub 仓库里看到对应代码。前端和后端都能启动，我也解决了过程中出现的一些错误，Gemini 也帮我修复了其中一部分。
但最终 Gemini 给我的最好结果，是一个空白窗口，如图 1-9 所示。
图 1-9. Gemini 生成了一个空白窗口
除了“解法没跑通”之外，Gemini 在生成超过单文件复杂度的代码时，会变得非常慢且容易出错。不同于 ChatGPT，Gemini 会把所有代码都生成在它代码编辑器里的一个巨大单文件中（见图 1-10 右侧面板）。这使得我很难把代码复制进我的 IDE：我必须手工创建每一个文件夹与文件，再把内容逐个复制进去；同时，也很难追踪调试过程中发生的修改。
图 1-10. 测试时的 Gemini 界面
基于以上原因，Gemini 在第二个测试中的表现让我非常失望。
当我审阅 Gemini 的代码时发现，它其实试图做一个有质感的前端：TypeScript、Tailwind、Framer Motion、Hero icons——如果能跑起来，本可以做出一个干净现代的 UI；但它就是没工作。React 代码里还有一个明显错误：它导出了 app 组件，却没有真正把它渲染出来。这类错误本应是 Gemini 很容易就能发现的。
后端部分代码看起来包含了期望的功能，但它把 OpenAI API key 直接暴露在代码里，而不是用环境变量。这是一个严重的安全问题，会让这个解法即便在测试环境也不可接受，更不用说部署。
Gemini 提供的是五个工具里最令人沮丧的体验：先是把代码复制/粘贴到正确文件里这件事就笨重且易错，然后前后端运行时不断报错，再然后它在修复导致 UI 无法渲染的 React 问题上原地打转。即便我投入了不少时间，最后还是没有得到可用的解法。考虑到 Gemini 在第一个挑战里能给出正确解，并且在第二个挑战里也生成了一些相关代码（虽然整体失败），我给它打 4/10。
GitHub Copilot
Copilot 的解法一开始跑得挺顺畅，因为它使用的库与依赖很少。在处理 OpenAI API 请求结构时，它需要几轮调试：先是用了错误的 endpoint，然后 payload 结构不对，又出现了解析错误。但几分钟之后，我就得到了图 1-11 与图 1-12 里展示的可运行解法——只是前端非常笨拙，由几乎没有样式的原生 HTML 组成。
按钮能用，添加新任务时也确实会触发后端逻辑。但前端在我完成后不会自动关闭模态弹窗，也没有 “x” 按钮可以关闭；视觉效果也很单薄，想把 UI 做得像样需要多轮迭代。
图 1-11. GitHub Copilot 的解法——模态弹窗
图 1-12. GitHub Copilot 的解法——任务已添加
从代码评审的角度，Copilot 做的是一个极简的概念验证：前端是纯 HTML/CSS/原生 JavaScript；后端是一个很小的 Express 服务器；依赖极少。优点是极致简单：任何人几分钟内就能读懂代码，部署也很轻量。
代价是几乎所有最佳实践都没做：OpenAI key 被硬编码；没有数据库；没有校验；没有响应式设计；也没有框架层面的可扩展性。它很适合黑客松，但如果不做大规模重构，用在面向用户的场景会很危险。
考虑到我并没有提示 Copilot 我希望的代码质量或鲁棒性细节，我认为这种做法有其价值。作为 CTO，我也认可先从简单开始；在这道题里，Copilot 确实生成了五个工具中最简单的应用。我给它打 8/10。
Cursor
Cursor 把代码拆分成前端与后端文件夹，在 Cursor 里用简单的 NPM start 命令就能分别跑起来，非常省事。后端流程跑得很好：数据库与 OpenAI API 集成也都工作正常；但前端比较笨拙。初始 UI 很怪：标题在最上面，“New task” 按钮却在最底部，如图 1-13。
图 1-13. Cursor 的解法 UI
点击 “New task” 后会弹出一个窗口。样式还可以，但输入框是单行的，较长的便笺描述会被截断，如图 1-14。
图 1-14. Cursor 的解法弹窗
当在弹窗里创建任务后，任务卡片会渲染在按钮下方，也就是屏幕最底部（图 1-15）。
图 1-15. Cursor 解法中的弹窗
Cursor 的解法实际上第一次就把功能跑通了，让我很容易启动前后端。但它呈现出来并不像我要求的看板（Kanban board）。它的 UI 比 Copilot 好一点，但仍然偏基础。
看代码可以发现，Cursor 原本想做一个更“丝滑”的 UI，用了 Material UI 和 react-beautiful-dnd；但不知为何，最终界面并不讨喜。它的组件拆分做得不错，并且正确使用了环境变量，因此基础是稳的。后端则有点“光秃秃”：所有逻辑几乎都塞在一个 Express 文件里，用的还是内存数组；没有输入校验，也没有错误处理。
一句话总结：Cursor 的开发者体验无可挑剔——它生成的代码能跑，前后端第一次就启动成功。功能满足需求，即便 UI 不够好、底层也仍有大量改进空间。我给 Cursor 打 9/10。
Windsurf
我觉得让 Windsurf 的解法跑起来比较费劲。它一开始提出了一个过于复杂的方案，引入了很多不必要的依赖。
首先，前端完全跑不起来。Windsurf 一头扎进了一个“vibe debugging”的兔子洞——问题来自它自作主张使用的 Chakra UI（一个前端库）的依赖冲突。最终，我不得不提示它完全不要用这个库，才能继续往下。移除该库后，前端终于能跑起来了（图 1-16）。
图 1-16. Windsurf 解法 UI
然后后端也遇到类似问题，这次是 MongoDB 依赖。对这么简单的任务来说，Windsurf 不知为何总会钻进各种兔子洞里；最后我不得不提示它简化后端并使用内存存储。
最终它跑起来了，并且能把我创建的任务放在 To Do 列里，形成一个真正的看板 UI（图 1-17）。
图 1-17. Windsurf 看板
不过，它要求我把任务拖到 In Progress 列，才会触发 OpenAI API 请求——但我一拖动它就崩了（图 1-18）。
图 1-18. Windsurf 解法崩溃
我又给 Windsurf 更多时间调试这个问题，最终应用能无错误运行了。但我感觉它跑得“太快”，结果也有点让人失望。后来我发现，Windsurf 在调试过程中误删了 OpenAI API 集成的代码——而这正是应用的关键功能之一（图 1-19）。
图 1-19. Windsurf 误删了 OpenAI 集成
最后，在经历了大量来回迭代之后，我终于得到了一个可运行的 Windsurf 解法：它有优雅的看板 UI，也满足后端功能（图 1-20）。
图 1-20. 完成后的 Windsurf 解法
从代码角度看，Windsurf 的解法功能最完整：它使用 React 的拖拽能力、模态创建、实时刷新，并且把 routes、controllers、components 清晰拆分。它尊重环境变量，错误处理也更用心一些，代码风格一致、易读。
有意思的是，Windsurf 在这次测试里走的是最“极繁”的路线：它尝试使用一些花哨的库，结果把自己带进了几次出不来的兔子洞。我不得不三次把它“提示”出来，明确要求 Windsurf 不要使用制造麻烦的依赖（先是 Chakra UI，然后 MongoDB，再然后是拖拽相关依赖）。它的智能体化（agentic）方式，让它成为我测试里能力最强、也最“自主”的工具——甚至比 Cursor 和 Copilot 更像能独立干活的那种。但这种自主性也让它几次走进死胡同，需要有经验的开发者把它拉回来。
Windsurf 也是让我花最长时间才跑通的工具：超过一小时。但它做出了最顺滑的 UI，代码质量也相当不错。我给它打 9/10。
表 1-1 汇总了我在测试中对各工具表现的评分。
表 1-1. 代码生成工具概览
| 工具 | 形态 | 测试表现 |
|---|---|---|
| ChatGPT | 浏览器 | 8/10 |
| Google Gemini | 浏览器 | 4/10 |
| GitHub Copilot | IDE | 8/10 |
| Cursor | IDE | 9/10 |
| Windsurf | IDE | 9/10 |
结论
多年来，我在面试中用第一项测试——二维数组代码挑战——用了几十次。令人难以置信的是：本次评测的五个工具都能在短短 10 秒内，产出与顶尖软件工程师同等水平的结果。
显然，在这类任务上，这些工具远远强于人类：任务需求清晰、输入输出规范明确、生成的代码能放进单个文件里、且有大量相关训练数据可用。所有这种“面试题式”的挑战都符合这一描述；更广泛地说，任何一款这样的 LLM 工具大概率都能在几秒钟内轻松解出类似的算法谜题。
当我给它们更复杂的挑战——需要产出更庞大的代码仓库——时，有些工具就开始遇到困难，即便只是一个带便笺与后端自动化的简单看板（Kanban）UI。使用基于浏览器的工具（例如 ChatGPT 和 Google Gemini）时，把代码复制/粘贴到正确文件里会变得非常痛苦：工作量大，而且极易出错。相比之下，这种体验明显不如基于 IDE 的工具——后者把代码与控制台终端都纳入了它的上下文窗口。作为开发者，我不需要复制/粘贴任何东西；我的工作变成了审阅，并决定接受还是拒绝建议。IDE 端工具更像一个高效的代码评审循环：我提出修改，它当场写出来，我在几秒内完成审阅、接受并测试。
同样显而易见的是：来自不同厂商的多种最先进模型，已经具备生成高质量软件代码的能力。我测试的所有 IDE 端工具（Cursor、Windsurf、GitHub Copilot）都允许开发者在下拉列表中选择模型。基于浏览器的工具则提供了更封闭的环境：ChatGPT 只使用 OpenAI 的模型，Gemini 只使用 Google 的模型。
这意味着，这个市场上的竞争越来越聚焦于开发者体验本身。在我看来，基于浏览器的工具已经基本退出这场竞赛：向它们共享上下文就已经够麻烦了，把代码再复制/粘贴回仓库则更麻烦。这个赛道最终的胜出方案会扎根在 IDE，而不是浏览器。
即便在 IDE 端工具之间，也存在不同路径。GitHub Copilot 仍然带着最初那种“把一个类似 ChatGPT 的聊天引入 IDE”的气质：能访问代码、也能做修改。Windsurf 则把抽象层级抬得更高：它采用智能体式（agentic）的方式创建文件夹和文件、进行改动，并给我一个简单按钮来审阅这些改动并“一键全部接受”，就像在做代码评审。Cursor 则介于两者之间：它的聊天交互体验比 Copilot 更好，同时也提供了启用智能体模式的选项（我在这次测试中并未使用）。
从软件工程师的视角看，我们未来的工作显然会更少是“亲手写代码”，而更多是“给这些工具写提示词，并审阅它们生成的代码”。不过，这听起来比实际容易得多。这些工具确实存在把整个代码库带向“到处是 bug、难以维护”的巨大风险——就像我在 Windsurf 上遇到的情形。想象一个生产级代码库有几百个文件，而 Windsurf 用智能体模式随意引入一些库、又删掉后端功能的关键部分。我完全能预见：如果以“vibe coding”的方式来操作，让开发者不经思考地接受建议、而不认真审阅与测试，工具可能造成很大破坏。
作为软件工程师，你当然应该使用这些工具：它们能帮你更快交付功能，而且很多时候还能把质量标准提高。但你必须始终在把 AI 生成的代码推到生产环境或提交 pull request 之前进行审阅。无论其中多少代码由 AI 生成，都要把代码变成“你的代码”。这些工具确实有把你原本可用的代码弄坏的风险，因此你应该用覆盖面足够广的测试套件去验证它们生成的代码——既覆盖主流程（happy path），也覆盖边界情况与错误状态。所有测试变绿，是代码满足需求的一个可靠确认。最后，请务必回到你所在公司的规范里，确认在专业用途上使用任何 AI 工具时应遵循的准则。
1 Gȕlen, Kerem. 2025 年 4 月 15 日。《ChatGPT 刚突破 10 亿用户并把自己的服务器“烧”了》。Dataconomy。
2 Palazzolo, Stephanie；Efrati, Amir. 2025 年 4 月 1 日。《ChatGPT 营收在短短三个月内暴增 30%》。The Information。
3 Sentisight.ai. 2025 年 1 月 24 日。《Google Gemini：到目前为止用户反馈如何？》
4 Millward, Wade Tyler. 2024 年 7 月 31 日。《微软 2024 财年 Q4：CEO 纳德拉称 Copilot 增长速度为任何 M365 套件中最快》。CRN。
5 GitHub Copilot Resources. 《衡量 GitHub Copilot 的影响》。GitHub，访问于 2025 年 6 月 4 日。
6 Shibu, Sherin. 2025 年 4 月 9 日。《这家 AI 初创公司营销投入为 0，但 3 月营收已达 2 亿美元》。Entrepreneur。
