AI编程工具横向评测：Cursor、Claude与Perplexity在ToDo应用重构中的实战对比-深圳市維司達科技有限公司

1. 项目概述：一次关于AI辅助开发工具的深度实践

最近在整理一个名为“RetEx_AI_Tools”的项目，它本质上是我个人对当前几款主流AI编程与信息获取工具的一次系统性“回测”和体验报告。作为一名长期在一线写代码的开发者，我深切感受到AI工具从“新奇玩具”到“生产力伙伴”的转变。这个项目没有复杂的业务逻辑，它的核心目的非常纯粹：横向对比不同AI工具在解决同一个具体开发任务时的实际表现、效率差异和产出质量，并试图回答一个我们都在思考的问题：这些工具到底在多大程度上改变了我们的工作流？

项目围绕一个经典的“待办事项”（ToDo）应用展开。我选择了最基础、无任何样式的原始版本作为起点，然后分别使用Cursor（及其Composer功能）、Claude Sonnet 4.6 和 Claude Opus 4.6来对这个应用进行重构和美化。最终，我将整个过程和对比结果，通过一个基于 Reveal.js 的幻灯片演示网站呈现出来。整个思考和实践过程，让我对如何高效地将AI工具融入日常开发，有了不少超出官方文档的体会。

2. 核心思路与工具选型解析

2.1 为什么选择ToDo应用作为测试基准？

在开始对比之前，确定一个公平、可衡量的测试基准至关重要。我选择经典ToDo应用，主要基于以下几点考量：

认知共识度高：几乎所有的开发者，无论前端后端，都清楚一个ToDo应用应该具备哪些基本功能（添加、删除、标记完成、数据持久化等）。这避免了因需求理解偏差导致的输出结果不可比。
复杂度适中：它足够简单，可以在短时间内完成；同时又具备一定的复杂度（涉及状态管理、事件处理、UI交互、本地存储），足以考验AI工具对前端开发常见模式的掌握程度。
设计空间大：从零样式到完整UI，有巨大的设计发挥空间，非常适合测试AI工具的审美、CSS架构能力和组件化思维。
结果可视化强：最终产出是一个可直接在浏览器中运行的网页，好坏优劣一目了然，对比非常直观。

这个选择确保了测试聚焦于工具的能力，而非任务的特殊性。

2.2 参评工具深度剖析

本次实践主要涉及三类工具，它们在开发流程中扮演着不同的角色：

1. Cursor & Composer：深度集成于编辑器的“副驾驶”

Cursor 的核心优势在于其与 VS Code 的深度集成和对项目上下文（Project Context）的强力感知。它不是一个聊天窗口，而是你编码环境的一部分。本次测试重点是其Composer 2功能，它允许你通过自然语言描述，让AI直接生成或修改一大段代码，并实时插入到正确的位置。

实操心得：Cursor 的威力在于“对话式编程”。你不需要离开编辑器去另一个网页描述问题，而是直接对着一行代码、一个函数或一个文件提问。例如，你可以选中一个陈旧的addTodo函数，然后输入指令：“用现代ES6语法和更健壮的错误处理重写这个函数，并添加JSDoc注释”。Cursor 会基于整个文件的上下文给出修改建议，这种“指哪打哪”的体验极大地提升了重构和优化代码的效率。

2. Claude (Sonnet & Opus)：强大的“策略顾问”与“架构师”

Anthropic 的 Claude 模型，特别是 Sonnet 和 Opus，在代码生成的逻辑性、安全性和对复杂指令的理解上表现出色。我将它们定位为“策略顾问”。

Claude Sonnet 4.6：在速度、成本和能力上取得了很好的平衡。对于日常的代码生成、解释和调试，它是性价比极高的选择。在本次测试中，我让它“为一个简易ToDo应用设计一个美观、响应式的UI，并实现完整功能”。
Claude Opus 4.6：这是目前公认能力最强的模型之一，尤其在需要深度推理、处理复杂多步骤任务和理解微妙需求时。我给它提出了更高的要求：“请以模块化、可维护的前端工程思想，重构这个ToDo应用。考虑状态管理、组件分离、CSS方法论（如BEM），并确保代码有详细的注释和良好的可测试性。”

两者的对比，可以清晰看出在不同复杂度需求下，模型选择对产出质量的直接影响。

3. Perplexity：高效的“研究助理”

严格来说，Perplexity 不是一个编程工具，但它在我构建这个知识分享项目时不可或缺。当我想在演示文稿（Reveal.js）中引用“AI对劳动力市场的影响”这类行业研究数据时，我不再需要手动在多个搜索引擎和学术网站间切换。Perplexity 的核心价值在于提供来源可溯、汇总清晰的答案。

我只需提问：“最新的关于AI对软件开发岗位影响的研究报告有哪些？”，它就能整合来自 Anthropic、arXiv、知名科技媒体等多方信息，并附上链接。这让我在准备演讲内容、丰富项目背景时，信息获取效率提升了数倍。

2.3 演示框架：为什么是 Reveal.js？

为了直观展示对比结果，我需要一个能呈现代码、效果和评论的演示网站。Reveal.js 是一个用HTML和JavaScript构建的演示文稿框架，选择它是因为：

完全可控：所有内容都是纯前端代码，我可以轻松地将四个不同版本的ToDo应用以<iframe>或直接嵌入的方式放在不同幻灯片中，实现实时对比。
开发者友好：其语法（Markdown 或 HTML）对开发者来说非常自然，我可以直接用代码块高亮展示关键代码片段。
专业美观：过渡动画和布局现代，适合做技术分享，最终的项目本身也成为了一个可交付的“作品”。

3. 实操过程：四版ToDo应用的生成与对比

3.1 第零版：原始基线 (Vanilla No Design)

这是起点，一个用最原始的 JavaScript、HTML 和行内样式写的功能原型。它丑陋但有效，代码结构通常是这样的：

<!DOCTYPE html> <html> <body> <input type="text" id="newTodo"> <button onclick="addTodo()">添加</button> <ul id="todoList"></ul> <script> let todos = JSON.parse(localStorage.getItem('todos')) || []; function addTodo() { const input = document.getElementById('newTodo'); // ... 简单的添加逻辑 } // ... 其他函数 </script> </body> </html>

存在的问题：全局变量污染、UI与逻辑高度耦合、无样式、可维护性为零。但这正是AI工具大显身手的完美“毛坯房”。

3.2 第一版：Cursor Composer 2 改造

任务指令：“为这个原始的ToDo应用添加一个现代化、简洁的UI。使用Flexbox布局，配色方案要专业柔和。重写JavaScript代码，使其更模块化，并保持本地存储功能。”

Cursor 的操作流程与产出分析：

我直接在原文件上，用 Composer 框选了整个<body>内的内容。
输入上述指令后，Cursor 开始流式生成代码。它首先构建了一个包含标题、输入区、列表和底部统计的完整HTML结构。
它生成了一套完整的CSS，包括对按钮、输入框、待办事项条目的样式设计，使用了CSS变量来定义主题色，确保了响应式基础。
在JavaScript部分，它没有简单地重写，而是将操作封装成了更清晰的函数，如renderTodoList()、saveToLocalStorage()，并改善了事件监听的方式（从onclick改为addEventListener）。

优点：

无缝集成：整个过程在编辑器内完成，无需切换上下文。
理解上下文：它准确地识别了原有代码中的数据结构和localStorage的使用，并在新代码中保留了这些逻辑。
产出即用：生成的代码直接可运行，UI立竿见影地变美观了。

不足与注意事项：

设计趋于保守：Composer 生成的设计风格比较“安全”和通用，缺乏令人眼前一亮的设计感。
架构提升有限：代码变得整洁了，但并没有引入真正的模块化或状态管理思想，更多是原结构的优化版。
需要人工微调：生成的CSS选择器命名可能比较随意（如.todo-item），对于大型项目，可能需要人工将其规范化为BEM等命名约定。

踩坑记录：在使用 Cursor 进行大规模生成时，务必先保存原文件或使用Git。有一次我让它“优化整个文件的性能”，它意外地删除了一段我认为无关但实际重要的初始化代码。虽然可以通过撤销找回，但这提醒我们，AI生成的代码必须经过仔细的审查和测试。

3.3 第二版：Claude Sonnet 4.6 重构

任务指令：“基于以下原始代码，创建一个具有现代UI的完整ToDo应用。要求：1. 使用ES6+模块化语法（如将功能拆分为独立函数或类）。2. 实现一个美观的界面，包含添加、删除、标记完成/未完成功能。3. 使用CSS Grid或Flexbox实现响应式布局。4. 保持数据在本地存储。请提供完整的HTML、CSS、JS代码。”

操作流程与产出分析：我将原始代码粘贴到 Claude 的聊天窗口中，并给出了上述指令。Sonnet 生成了一份完整的、三个文件分离的代码。

产出亮点：

结构清晰：它明确地提供了index.html,style.css,script.js三个文件的内容。
设计感更强：生成的UI比Cursor版更具细节，例如为完成的条目添加了删除线动画、更精致的阴影和悬停效果。
代码组织更好：在script.js中，它使用了class TodoApp来封装整个应用的状态和方法，这是一个显著的架构提升，更接近现代前端实践。

// Claude Sonnet 生成代码示例 class TodoApp { constructor() { this.todos = JSON.parse(localStorage.getItem('todos')) || []; this.init(); } init() { this.bindEvents(); this.render(); } addTodo(text) { if (text.trim() === '') return; this.todos.push({ id: Date.now(), text, completed: false }); this.saveAndRender(); } // ... 其他方法 }

对比与思考： Sonnet 展现出了更强的“设计意识”和“软件工程意识”。它不仅仅是在美化界面，而是在尝试构建一个更易于维护的程序结构。然而，它的TodoApp类仍然将DOM操作、事件绑定、渲染逻辑全部耦合在一起，距离理想的“关注点分离”还有差距。

3.4 第三版：Claude Opus 4.6 高阶重构

任务指令：“请以生产级前端应用的标准重构这个ToDo应用。我希望达到以下目标：

架构分离：严格区分数据模型（Model）、视图（View）和逻辑控制器（Controller），采用MVC或类似模式。
组件化：将待办事项列表、输入框、过滤按钮等视为独立组件。
CSS方法论：使用BEM命名规范来组织CSS类名，避免样式冲突。
可测试性：业务逻辑（如添加、删除、切换状态）应独立于DOM，便于单元测试。
高级功能：考虑添加过滤（全部/进行中/已完成）功能。请给出详细的实现方案和代码。”

产出深度解析： Opus 的响应展现出了质的飞跃。它没有直接给出代码，而是先提供了一个详细的实现方案：

项目结构建议：

/opus-todo-app ├── index.html ├── css/ │ ├── style.css # 全局样式 │ └── components/ # 组件样式 ├── js/ │ ├── app.js # 应用入口、控制器 │ ├── model.js # 数据状态与业务逻辑 │ ├── view.js # DOM渲染与更新 │ └── utils.js # 工具函数（如本地存储） └── README.md

核心代码实现：
- Model (model.js)：定义了TodoModel类，纯粹管理todos数组，提供add,delete,toggle,filter等方法，所有方法不涉及任何DOM操作。这是单元测试的理想对象。
- View (view.js)：定义了TodoView类，负责接收一个数据模型和根元素，并创建整个应用的DOM结构。它暴露出render方法，当模型数据变化时，由控制器调用此方法更新界面。
- Controller (app.js)：作为粘合剂，初始化 Model 和 View，并监听View上的用户事件（如点击添加按钮），然后调用对应的Model方法修改数据，最后再调用View的render方法更新UI。

价值评估： Opus 版的产出不再是一个简单的“脚本”，而是一个具备良好架构雏形的“应用程序”。它强制性地将数据、视图和逻辑分离，这使得：

代码可维护性：每个模块职责单一，修改数据逻辑不会影响UI，反之亦然。
可测试性：TodoModel可以轻松地用Jest等框架进行测试。
可扩展性：要新增一个“按优先级排序”的功能，你只需要在Model中添加排序逻辑，在View中添加对应的UI元素，在Controller中连接两者，修改是局部的。

当然，对于一个小型ToDo应用来说，这显得有些“杀鸡用牛刀”。但这正是测试的意义所在：Opus 能够理解并执行复杂的、面向工程最佳实践的指令，而不仅仅是完成功能。

4. 横向对比总结与工具使用心法

4.1 四版应用综合对比表

特性维度	原始版 (Vanilla)	Cursor Composer 2 版	Claude Sonnet 4.6 版	Claude Opus 4.6 版
核心目标	功能实现	快速UI美化与代码整理	现代化重构与基础架构	生产级架构与工程化
代码结构	脚本堆砌，高度耦合	函数式整理，略有改善	类封装，初步模块化	MVC模式，严格分离
UI/UX设计	无	简洁、通用、安全	美观、有动效、更细致	结构清晰，样式规范(BEM)
可维护性	极差	一般	良好	优秀
可测试性	无法测试	难以测试	部分可测	易于单元测试
开发速度	手动编写	极快（编辑器内直接生成）	快（聊天生成，需复制）	慢（需理解复杂架构并整合）
适用场景	概念验证	快速原型、旧代码翻新、日常小修小补	中小型项目启动、功能模块开发	复杂项目架构设计、代码规范制定、教学示例

4.2 不同场景下的工具选择策略

基于这次实践，我总结出一套自己的工具选用策略：

“我现在就要改这行代码！”—— 首选 Cursor当你正在专注编码，遇到一个具体函数需要优化、一个bug需要排查、一段代码需要解释时，不要离开编辑器。直接用 Cursor 提问，它能结合当前文件甚至整个项目的上下文，给出最精准的建议。它是你的“实时结对编程伙伴”。
“我需要从零开始生成一个功能模块或页面。”—— 对话式 AI (Claude/GPT)当你需要构建一个相对独立、完整的部分时，比如一个登录组件、一个数据表格、一个API工具函数集，使用 Claude Sonnet 或 ChatGPT。在聊天框中清晰地描述需求、输入输出示例、技术栈要求，你能得到一份完整、可用的代码块，直接复制到项目中。
“这个旧项目/模块需要彻底重构，提升可维护性。”—— 启用“重型顾问” Claude Opus当任务涉及架构设计、模式引入、代码拆分等需要深度推理的复杂工作时，值得为 Opus 的能力付费。用它来生成设计方案、评审代码、提出重构建议。虽然速度慢、成本高，但它提供的思路和方案质量，往往能节省你大量的后期维护成本。
“我需要为这个技术决策寻找依据或最新案例。”—— 求助 Perplexity在技术选型、方案论证、撰写技术文档或分享稿时，用 Perplexity 快速获取经过汇总和引证的行业信息、技术对比、研究数据。它能帮你快速构建认知背景，让你的决策和分享更有说服力。

4.3 必须警惕的“陷阱”与核心原则

无论工具多么强大，开发者必须保持主导地位。以下是几条血泪教训：

原则一：AI生成代码必审，逻辑必测AI会“幻觉”（Hallucination），即生成看似合理但完全错误的代码或引用不存在的API。永远不要盲目信任生成的代码。必须逐行审查，特别是涉及安全、数据验证和核心业务逻辑的部分。生成后，运行它，测试边界情况。
原则二：清晰指令 > 多次对话花时间构思一个清晰、具体、无歧义的指令，远比和AI进行多轮低效对话更重要。在指令中明确：背景、具体任务、技术要求、输入输出格式、禁止事项。例如，“用React函数组件实现一个计数器，使用useState Hook，按钮文字为‘增加’和‘减少’，初始值为0”，就比“写个计数器”好得多。
原则三：保护知识产权与隐私绝对不要将公司商业源代码、未公开的API密钥、数据库凭证、用户个人信息等敏感数据提交给任何在线AI工具。许多公司的合规政策已明确禁止此举。对于私有项目，使用本地部署的大模型（如通过Ollama运行本地模型）是更安全的选择。
原则四：AI是杠杆，不是替代品这些工具不会取代开发者，但会取代不会使用这些工具的开发者。它们的作用是放大你的能力，帮你处理重复性、探索性的工作，从而让你更专注于真正需要创造力和深度思考的部分：系统架构、产品设计、解决复杂模糊问题。你的判断力、工程经验和业务理解，才是不可替代的核心价值。

这次“RetEx_AI_Tools”项目对我而言，远不止一次简单的工具对比。它是一次主动将自身工作流置于AI浪潮下的压力测试。最终我得到的不是一个答案，而是一张动态地图——明确了在开发旅程的不同路段，该启用何种“导航”和“辅助驾驶”模式。地图在变，工具在进化，但手握方向盘、定义目的地的人，始终应该是我们自己。