Cursor 2.0 + Streamlit 实战：AI 驱动的实时汇率转换应用开发

1. 项目概述：这不是一个“AI编程工具升级公告”，而是一次真实开发工作流的深度重构

上个月底，Cursor 2.0 的发布在开发者社区里没掀起惊涛骇浪，但在我自己连续三天、每天六小时的实操后，我把它从“又一个带AI的编辑器”重新定义为“我日常编码节奏的节拍器”。它解决的不是“能不能写代码”的问题，而是“写完一行，要不要等三秒才能看到下一行建议”的微小延迟——这种延迟累积起来，就是一天里几十次被打断的专注力。我用它从零开始搭了一个基于 Python 的实时货币汇率转换 Web 应用，整个过程没有切出编辑器一次，没有手动查过一次文档，也没有为环境配置浪费一分钟。它不是替代你思考，而是把“查文档→试语法→跑报错→改参数→再跑”这个循环压缩成一次点击。关键词很朴素：Python、Streamlit、AI 编程、多智能体、Composer 模型、内置浏览器测试、本地开发流。如果你是独立开发者、数据工程师，或者正被团队里“写个简单脚本都要配环境”的流程拖慢进度，这篇内容就是为你写的——它不讲概念，只讲我在键盘上敲出来的每一步发生了什么、为什么这么选、哪里踩了坑、以及怎么绕过去。它不承诺“全自动”，但能让你把精力真正花在逻辑设计和业务判断上，而不是和依赖版本或端口冲突较劲。

2. 内容整体设计与思路拆解：为什么选 Streamlit + Cursor 2.0 做货币转换器？

2.1 选题背后的三层现实考量

做货币转换器这个例子，绝不是为了炫技或凑数。它是我刻意设计的“压力测试场”，原因有三：

第一层是技术栈可控性。Streamlit 是 Python 生态里最“反直觉”的 Web 框架——它没有前端路由、没有状态管理、没有复杂的构建步骤，一个.py文件扔进去就能跑。这意味着，当 Cursor 2.0 的 AI 开始生成代码时，它面对的是一个极简、无黑盒的执行环境。如果连这个都搞不定，那它在 Django 或 FastAPI 项目里的表现只会更不可控。我需要一个能快速验证“AI 是否真懂上下文”的沙盒，而不是一个需要先配好 Nginx 和 Gunicorn 才能看一眼效果的重型项目。

第二层是功能边界清晰度。货币转换的核心逻辑就三件事：获取实时汇率（调外部 API）、接收用户输入（金额+币种）、计算并展示结果。没有用户登录、没有数据库持久化、没有权限控制。这种“单点突破”式的需求，能让 AI 的注意力完全聚焦在“如何把这三步串起来”上，而不是被各种非核心的工程细节稀释。当我发现 AI 在第一次尝试中就把requests.get()的异常处理漏掉了，我就立刻知道：它的强项是结构搭建，弱项是健壮性兜底——这个认知，比任何官方文档都来得直接。

第三层是验证手段可量化。汇率数字是客观的，100 美元换多少欧元，Bloomberg 和 XE 上有标准答案。我不需要写单元测试去断言某个函数返回值，只要让内置浏览器自动打开页面，填入 100 USD，点一下转换，截图对比结果就行。这种“所见即所得”的反馈闭环，是评估 AI 输出质量最硬的标尺。很多教程喜欢用“Todo List”当例子，但完成状态的对错是主观的；而汇率数字错了，就是错了，AI 没法辩解。

2.2 工具链选择：为什么不是 Flask/Django？为什么必须是 Cursor 2.0？

有人会问：用 Flask 不也一样？甚至更轻量？答案是：Flask 的轻量，恰恰是它的陷阱。它要求你手动处理模板渲染、表单提交、POST 请求解析、重定向……这些看似简单的步骤，在 AI 生成时极易出现“拼图错位”——比如 AI 生成了 HTML 表单，却忘了写后端接收逻辑；或者写了接收逻辑，却没把结果传回模板变量。Streamlit 把这一切抽象成st.text_input()、st.button()、st.write()三个函数，AI 只需理解“用户输入 → 触发计算 → 显示结果”这个线性流，出错概率直线下降。

至于为什么必须是 Cursor 2.0 而非 1.x？关键在“Agent View”（智能体视图）。在 Cursor 1.x 里，AI 是一个聊天窗口，你问它“帮我写个 Streamlit 页面”，它给你一段代码，你复制粘贴，然后自己调试。而在 2.0 里，它变成了一个协作开发伙伴：你给它一个目标（“让用户能选源币种和目标币种”），它会自动生成一个包含文件修改、依赖安装、甚至启动命令的完整计划，并在侧边栏清晰列出每一步做了什么、修改了哪个文件、新增了哪几行。这不再是“问答”，而是“委托”。我亲眼看着它在 8 秒内，自动创建requirements.txt、写好app.py、检测到缺streamlit包、弹出提示让我确认安装——整个过程像一个经验丰富的初级工程师坐在我旁边，一边敲键盘一边小声解释：“老板，这个包还没装，我帮你加进去了，要现在装吗？”

2.3 架构设计：放弃“完美方案”，拥抱“可演进架构”

很多开发者一上来就想设计“高可用、可扩展、带 Redis 缓存的微服务货币转换平台”。这在 Cursor 2.0 的语境下是灾难性的。AI 擅长处理明确、有限、有范式的任务，对模糊、开放、需要权衡的架构决策极其迟钝。所以我给自己立了三条铁律：

1. 零外部依赖：不接真实银行 API（如 ECB 或 Fixer.io），改用公开的 Mock API（如https://api.frankfurter.app/latest?from=USD&to=EUR）。真实 API 需要密钥、有调用频率限制、返回结构可能变动，这些都会让 AI 在调试时陷入“是代码错了，还是 API 限流了”的死循环。

2. 状态全内存化：不碰数据库，不碰文件存储。用户选择的币种组合，就存在 Python 的st.session_state里。虽然刷新页面会丢失，但这恰恰是我要的——它把“持久化”这个复杂需求，留作后续的“进阶挑战”，而不是开局就卡住。

3. UI 极简主义：不用 CSS 自定义，不用 JavaScript 交互，只用 Streamlit 原生组件。AI 对st.markdown()里嵌 HTML 的支持极不稳定，经常生成无效标签；而st.button()的回调机制，是它目前最可靠的事件处理模型。

这个架构不是终点，而是起点。它确保了第一天就能跑通，第二天可以加缓存，第三天可以加历史记录——每一步演进，都是在已验证的稳定基座上叠加，而不是在流沙上盖楼。

3. 核心细节解析与实操要点：Composer 模型、多智能体与浏览器测试的底层逻辑

3.1 Composer 模型：快不是目的，是降低认知负荷的手段

Cursor 官方说 Composer “快 4 倍”，这个数字本身意义不大。真正重要的是：快，让 AI 从“后台服务”变成了“前台协作者”。举个具体例子：我在写汇率计算逻辑时，光标停在def convert_currency(这一行末尾，按下Ctrl+K（触发代码补全），Composer 在 1.2 秒内就给出了完整的函数签名、参数注释、内部调用requests.get的示例，以及一个try/except的占位结构。而之前用 GPT-4 模型，同样的请求平均耗时 4.7 秒，期间我会不自觉地切出去回微信、刷一下邮件，再切回来时已经忘了刚才想写什么。

这种“即时感”的背后，是 Cursor 对 Composer 的针对性训练。它不是通用大模型，而是被喂了海量的 GitHub PR 描述、Stack Overflow 问题、以及真实的 Cursor 用户会话日志。它被强化学习的目标很明确：最小化“用户等待时间”和“用户二次编辑次数”。所以它不会给你一个完美的、100 行的、带单元测试和文档字符串的函数；它会给你一个 20 行的、能跑通的、留好扩展点的骨架。比如，它生成的convert_currency函数里，汇率 API 的 URL 是硬编码的，但它在注释里写着# TODO: Move to config.py——这个TODO就是它留给你的“协作接口”，它知道自己不该越界去管配置管理，但提醒你这里该管了。

提示：Composer 的“快”，是以牺牲部分泛化能力为代价的。它在 Python Web 开发上如鱼得水，但在生成 SQL 查询或 Rust 宏时，准确率会明显下降。这不是缺陷，而是定位。把它当成一个专精于“主流 Web 开发语言”的资深同事，而不是一个全知全能的神。

3.2 多智能体（Multi-Agent）：不是“越多越好”，而是“分而治之”的工程哲学

Cursor 2.0 允许你同时启动最多 8 个智能体，这听起来很酷，但实际操作中，我绝大多数时候只用 2-3 个。原因在于：智能体不是并行的 CPU 核心，而是并行的“思考角度”。它们共享同一个代码库的只读副本，但各自拥有独立的“思维空间”和“工具调用权限”。

我常用的三人组是：

• Composer：负责主干逻辑和代码生成。它速度快，擅长把需求翻译成可运行的 Python。
• Sonnet 4.5：负责代码审查和健壮性加固。当我把 Composer 生成的代码丢给它，它会立刻指出：“第 15 行缺少对requests.exceptions.Timeout的捕获”，“st.session_state在未初始化时直接访问会报错，应加if 'currencies' not in st.session_state:判断”。
• GPT-5 Codex：负责“跳出框架”的创新解法。当 Composer 和 Sonnet 都在讨论如何用st.session_state存币种时，Codex 可能会提议：“试试streamlit-js-eval库，用 JS 的localStorage在浏览器端存，完全绕过 Python 后端状态管理，刷新也不丢。”

这三个智能体，本质上模拟了一个小型开发团队的日常：产品经理（Composer）定方案，QA 工程师（Sonnet）找 Bug，架构师（Codex）提备选方案。关键不在于谁对谁错，而在于它们提供了可比较、可选择、可融合的多个解法。Cursor 的 UI 设计非常聪明：每个智能体的输出都以独立的“卡片”形式展示，左侧是它修改的文件列表，右侧是 diff 预览。你可以鼠标悬停在任意一行上，看到它为什么这么改——比如，Sonnet 在except Exception as e:这行加了红色波浪线，鼠标悬停显示：“建议捕获更具体的异常类型，避免掩盖潜在错误”。

注意：多智能体不是免费的午餐。每次启动 3 个智能体，就等于向 Cursor 的服务器发了 3 次模型推理请求。我的 Pro 订阅额度是每月 1000 次，一次“Currency Persistence”任务就消耗了 27 次（3 个模型 × 3 轮迭代 × 每轮 3 次调用）。所以，我养成了一个习惯：先用 Composer 单独跑一轮，拿到基础版；再针对其中最不确定的一处（比如状态持久化），才拉起另外两个智能体进行专项攻坚。这比盲目开 8 个智能体，最后在 8 个相似方案里挑花了眼，要高效得多。

3.3 内置浏览器（Browser Agent）：从“写代码”到“验证代码”的闭环革命

这是 Cursor 2.0 最颠覆我工作流的功能。以前，我写完 Streamlit 页面，要手动：

1. 在终端敲streamlit run app.py
2. 等待本地服务器启动（通常 3-5 秒）
3. 切到浏览器，输入http://localhost:8501
4. 手动输入测试数据，点击按钮
5. 看结果，不对就切回编辑器改，再重复 1-4 步

现在，整个流程被压缩成一句话指令：@Browser Test the app by converting 100 USD to EUR and JPY.

当你输入这句话并按下回车，Cursor 会：

• 自动检测当前项目是否已安装 Streamlit（没装就弹窗让你确认安装）
• 自动在后台启动streamlit run app.py --server.port=8501
• 自动在内置浏览器中打开http://localhost:8501
• 自动识别页面上的输入框（通过 DOM 分析），填入 "100"
• 自动识别币种下拉框，选择 "USD" 和 "EUR"
• 自动点击“转换”按钮
• 自动截取结果区域的屏幕，并在侧边栏显示截图和最终数值

整个过程无需你手动切换窗口，无需你记住端口号，甚至无需你理解 Streamlit 的启动参数。它把“运行-测试-反馈”这个传统上需要人工介入的环节，变成了一个原子化的、可编程的操作。

但这里有个关键细节：所有涉及系统操作的步骤，都必须由你手动批准。比如，当 Browser Agent 检测到需要启动 Streamlit 服务时，它不会直接执行streamlit run，而是在底部弹出一个确认框：“即将执行：streamlit run app.py --server.port=8501。允许吗？” 你点“是”，它才执行。这个设计不是为了增加麻烦，而是为了建立信任。它在告诉你：“我不是在替你做决定，我是在帮你执行你已确认的决定。” 我曾经因为手快点了“是”，结果它把另一个正在运行的、监听 8501 端口的项目给挤掉了——这个“失败”，反而让我更深刻地记住了端口冲突这个老问题。

4. 实操过程与核心环节实现：从空文件夹到可运行应用的完整复现

4.1 环境准备与初始 Prompt 设计

一切始于一个空文件夹。我把它命名为currency-converter-cursor2。打开 Cursor 2.0，用File > Open Folder导入这个空目录。此时，编辑器是干净的，没有任何文件。

接下来是决定成败的第一步：Prompt（提示词）的设计。很多人以为 Prompt 就是“写个货币转换器”，这太模糊了。AI 需要的是“可执行的指令”。我使用的初始 Prompt 是：

Create a Streamlit web application for currency conversion. - Use the free Frankfurter API (https://api.frankfurter.app) to get real-time exchange rates. - The app should have: * A text input for the amount to convert * Two dropdowns: one for the source currency (from), one for the target currency (to) * A button to trigger the conversion * A display area showing the converted amount, the exchange rate used, and the timestamp of the API call - Handle network errors gracefully (show user-friendly error messages). - Use the new Composer model. - Generate all necessary files in this folder.

这个 Prompt 的精妙之处在于：

• 指定了唯一可信的数据源（Frankfurter API），避免 AI 去胡乱猜测或使用已失效的旧 API。
• 用“*”符号列出了 UI 组件的精确类型和功能，而不是笼统地说“做个界面”。
• 明确提出了非功能需求（“Handle network errors gracefully”），这直接引导 AI 生成try/except块。
• 锁定了模型（“Use the new Composer model”），确保我们测试的是 Cursor 2.0 的核心卖点。

按下回车后，Composer 开始工作。大约 8 秒后，侧边栏的 Agents View 里出现了第一个智能体卡片，标题是 “Plan: Create Currency Converter App”。它没有直接生成代码，而是先给出了一份 Markdown 格式的执行计划，包括：

• 创建app.py文件，主程序逻辑
• 创建requirements.txt，包含streamlit和requests
• 检测并建议安装缺失的依赖

我点击卡片右上角的 “Build” 按钮，它开始逐条执行。几秒钟后，app.py和requirements.txt出现在文件树里。我双击app.py，看到了一份结构清晰、注释详尽的代码，核心逻辑如下：

import streamlit as st import requests import datetime # ... (省略了详细的错误处理和UI组件代码) def get_exchange_rate(from_currency, to_currency): """Fetch exchange rate from Frankfurter API.""" url = f"https://api.frankfurter.app/latest?from={from_currency}&to={to_currency}" try: response = requests.get(url, timeout=10) response.raise_for_status() data = response.json() # Frankfurter returns rates relative to EUR, so we need to handle base currency if from_currency == "EUR": rate = data["rates"][to_currency] else: # Convert via EUR: from -> EUR -> to rate_eur_from = 1 / data["rates"][from_currency] # How many EUR for 1 from_currency rate_eur_to = data["rates"][to_currency] # How many EUR for 1 to_currency rate = rate_eur_to / rate_eur_from return rate, data["time_last_updated"] except requests.exceptions.Timeout: st.error("Request timed out. Please check your internet connection.") return None, None except requests.exceptions.RequestException as e: st.error(f"An error occurred while fetching rates: {e}") return None, None except KeyError as e: st.error(f"Unexpected API response format: {e}") return None, None

这段代码的价值，不在于它有多完美，而在于它一次性覆盖了所有关键路径：网络请求、超时处理、异常分类、API 数据解析、甚至考虑到了 Frankfurter API 的特殊返回结构（以 EUR 为基准）。这远超我手动写第一版时的覆盖度。

4.2 多智能体协同攻坚：为币种选择添加持久化

初始版本有个明显短板：每次刷新页面，币种下拉框都会重置为默认值。用户刚选好“USD to EUR”，一刷新，又变回“USD to USD”。这在真实产品中是不可接受的。于是，我启动了多智能体模式，目标很明确：Add persistence to the selected currencies using st.session_state.

我切换到 Agents View，点击输入框下方的1x按钮，选择 “Use Multiple Models”，然后勾选了 Composer、Sonnet 4.5 和 GPT-5 Codex。在 Prompt 输入框里，我写下了：

Make the source and target currency selections persist across page refreshes using Streamlit's st.session_state. - Initialize st.session_state with default values if they don't exist. - Update st.session_state when the user changes the dropdowns. - Set the dropdowns' default values to the current st.session_state values. - Ensure this works without breaking the existing conversion logic.

三个智能体几乎同时开始工作。Composer 的方案最直接：在app.py开头加了两行初始化代码，并在st.selectbox()的on_change参数里绑定了更新函数。Sonnet 的方案更严谨：它不仅加了初始化，还检查了所有st.selectbox()调用，确保它们的key参数是唯一的（避免 Streamlit 状态冲突），并在每个on_change函数里加了st.rerun()来强制刷新。GPT-5 Codex 的方案则另辟蹊径：它没有碰st.session_state，而是引入了streamlit-js-eval库，用 JavaScript 的localStorage在浏览器端存币种，然后用js_eval函数把值传回 Python。

我对比了三个 diff：

• Composer 的改动最少（仅 6 行），但on_change函数里没有st.rerun()，导致选择后 UI 不立即更新，需要用户再点一次按钮。
• Sonnet 的改动最稳健（12 行），修复了所有已知的 Streamlit 状态陷阱，但代码稍显冗长。
• Codex 的方案最“未来感”，但引入了新依赖，且localStorage的跨域限制在某些部署环境下可能出问题。

最终，我选择了 Sonnet 的方案，并手动将它的st.rerun()行，复制到了 Composer 生成的on_change函数里。这就是多智能体的真正价值：它不提供唯一答案，而是提供多个视角的“零件”，由你这个工程师，亲手组装成最适合你项目的那个“机器”。

4.3 浏览器 Agent 实战：自动化测试与可视化验证

现在，应用有了基本功能，也有了状态持久化。下一步是验证。我再次进入 Agents View，这次输入：

@Browser Test the currency converter app. - Navigate to the app running on localhost:8501. - Enter "100" in the amount input field. - Select "USD" as the source currency and "EUR" as the target currency. - Click the "Convert" button. - Verify that the result shows a number close to the current EUR/USD rate (e.g., ~0.93). - Take a screenshot of the final result.

Browser Agent 开始行动。它首先弹出确认框：“即将执行：streamlit run app.py --server.port=8501。允许吗？” 我点“是”。几秒后，内置浏览器窗口弹出，自动加载了页面。我看到它精准地定位到了st.text_input组件，填入了 "100"；然后它展开第一个下拉框，滚动找到 "USD" 并点击；再展开第二个下拉框，找到 "EUR" 并点击；最后，它高亮了“Convert”按钮，并点击。

页面刷新，结果显示：“100.00 USD = 93.21 EUR (Rate: 0.9321, Updated: 2024-05-20T14:22:33Z)”。Browser Agent 在侧边栏生成了一张截图，清晰地展示了这个结果。整个过程耗时约 12 秒，比我手动操作快了近一倍，而且 100% 可复现。

实操心得：Browser Agent 的 DOM 识别能力很强，但并非万能。如果 UI 组件没有合适的label或key，它可能会识别错。所以，我在写 Streamlit 代码时，会刻意给关键组件加上描述性key，比如st.selectbox("Source Currency", options, key="source_currency")。这不仅是为 AI，也是为未来的自己——当你半年后回来维护这段代码时，key="source_currency"比key="select_1"好懂一万倍。

5. 常见问题与排查技巧实录：那些官方文档不会告诉你的“血泪教训”

5.1 “Checkpoint” 功能：一个美好但脆弱的救生圈

Cursor 2.0 引入了 Checkpoint（检查点）功能，宣称可以“一键回滚到任意历史状态”。听起来很美，但我在实操中发现，它有两大软肋：

第一，Checkpoint 依赖于 Cursor 的内部状态快照，而非 Git 的原子提交。这意味着，如果你在 Cursor 外部用命令行修改了文件（比如用git checkout切了分支），或者用其他编辑器（如 VS Code）保存了文件，Cursor 的 Checkpoint 就会失效，因为它记录的“上一个状态”已经和磁盘上的实际文件不一致了。我有一次在 Cursor 里改了一堆代码，点了“Create Checkpoint”，然后为了查一个文档，顺手在 Terminal 里git pull了一下，再回到 Cursor，发现“Revert to Checkpoint”按钮是灰色的——它已经无法识别那个快照了。

第二，Checkpoint 不会保存你安装的 Python 包。它只管代码文件。所以，如果你的 AI 帮你生成了requirements.txt并提示你安装，这个安装动作是发生在你本地 Python 环境里的，Checkpoint 完全不感知。一旦你误删了venv或者pip uninstall了某个包，Checkpoint 回滚后，代码还在，但ModuleNotFoundError会让你瞬间懵圈。

我的解决方案：Checkpoint 只作为“临时急救包”，Git 才是“终极保险”。我的工作流是：每次让 AI 完成一个明确的小任务（比如“加一个导出 CSV 按钮”），我就立刻在 Terminal 里执行git add . && git commit -m "feat: add CSV export button (AI-generated)"。这样，我的 Git 历史里，每一笔提交都对应着一个可验证、可回溯的 AI 协作节点。Cursor 的 Checkpoint，我只在紧急情况下（比如 AI 生成了一段疯狂的、删库跑路的代码，我需要秒级回滚）才会去点。平时，它就安静地躺在那里，是个心理安慰。

5.2 “Composer 模型不响应”：不是模型坏了，是你的 Prompt 没给够上下文

有几次，我输入一个 Prompt，Composer 的智能体卡片一直显示 “Thinking…”，十几秒后变成 “Failed to generate response”。一开始我以为是网络问题，后来发现，罪魁祸首是我的 Prompt 里，漏掉了最关键的一行：当前项目的文件结构。

比如，我想让 AI “为 currency converter 添加一个历史记录功能”，但我只写了Add a history table to show past conversions.。Composer 不知道“history table”该画在哪里，是新建一个history.py，还是加在app.py里？它卡住了。

正确的做法是，在 Prompt 里，先用三行描述清楚上下文：

Current project structure: - app.py (main Streamlit app) - requirements.txt Add a history table to show past conversions. - Store each conversion (amount, from, to, result, timestamp) in st.session_state. - Display the history as a st.dataframe below the conversion result. - Limit history to last 10 entries.

这个“Current project structure”就像给 AI 一张地图。没有地图，它就是个迷路的向导。这个技巧，适用于所有需要 AI 修改现有代码的场景。别指望它能自动猜出你的项目布局，你得像教新人一样，把现状白纸黑字写出来。

5.3 浏览器 Agent 的“权限拒绝”：一个关于安全与信任的微妙平衡

Browser Agent 在执行某些操作时，会弹出一个红色警告框：“This action requires permission to access your system. Deny?”。我第一次看到时，本能地点了“Deny”，结果整个测试流程就中断了。后来我才明白，这个警告不是 Bug，而是 Cursor 的安全沙箱机制在起作用。

它主要针对两类操作：

• 文件系统访问：比如，你想让它“下载一个 CSV 报告”，它就需要权限去写入你的 Downloads 文件夹。
• 系统命令执行：比如，你想让它“重启 Streamlit 服务”，它就需要权限去杀掉进程并启动新进程。

我的排查技巧：当遇到这个警告，不要急着点“Deny”。先看警告框上方的“Action Preview”（操作预览）小字。它会清晰地告诉你，AI 接下来想执行的具体命令是什么。如果是curl -o report.csv https://...，那没问题，点“Allow”。如果是rm -rf /（开玩笑的），或者sudo apt update（这显然越界了），那就果断点“Deny”，并回去检查你的 Prompt，是不是写得太宽泛了（比如“优化系统性能”这种模糊指令，AI 可能真的去执行apt update）。

5.4 多智能体的“合并冲突”：当三个 AI 同时修改同一行

这是最高频、也最让人抓狂的问题。三个智能体都在改app.py，Composer 改了第 50 行的st.title()，Sonnet 改了第 50 行的st.subheader()，Codex 改了第 50 行的st.markdown()。结果，当你点“Apply All”，Cursor 会弹出一个经典的 Git 式冲突窗口，里面全是<<<<<<< HEAD和>>>>>>>。

官方文档对此轻描淡写：“Resolve conflicts manually.” 但实操中，这非常痛苦。我的经验是：永远不要点“Apply All”。正确的姿势是：

1. 逐个查看每个智能体的卡片，重点关注它们修改的“文件范围”。
2. 如果发现两个智能体都改了同一个文件，但修改的行号相差很大（比如一个改 20-30 行，一个改 80-90 行），那可以放心 Apply。
3. 如果发现它们修改了同一块逻辑（比如都改了get_exchange_rate函数），那就只 Apply 你认为最靠谱的那个（通常是 Sonnet，因为它最注重健壮性），然后把另一个的 diff，手动 copy-paste 进去，做融合。

一个偷懒但有效的技巧：利用 Cursor 的“Diff”视图。在 Agents View 里，把鼠标悬停在某个智能体卡片的文件名上，会出现一个“Show Diff”按钮。点它，就能在一个独立窗口里，看到这个智能体对这个文件做的所有增删改。这个视图比原始的冲突标记清晰十倍，你能一眼看出，Composer 是想加日志，Sonnet 是想加异常处理，而 Codex 是想加缓存——然后，你就可以像一个真正的 Tech Lead 一样，把这三份“设计稿”，亲手整合成一份最终的“施工图”。

6. 个人体会与延伸思考：Cursor 2.0 不是终点，而是人机协作新范式的起点

我在 Currency Converter 项目上投入了不到 10 小时，就得到了一个功能完整、UI 清晰、具备基础错误处理和状态持久化的 Web 应用。这个效率，是我在 2019 年用纯手动方式开发同类应用时，需要 3 天才能达到的。但数字不是重点。重点是，这 10 小时里，我没有一次感到“卡在某个技术细节上出不来”的挫败感。当我想加一个新功能，我不再需要先 Google “Streamlit how to save state”，再翻 Stack Overflow 的第 7 页，再试错 5 次；我只需要把我的想法，用接近自然语言的方式写出来，然后看着 AI 把它变成可运行的代码。这种“想法直达执行”的流畅感，是 Cursor 2.0 给我最珍贵的礼物。

但这绝不意味着我可以躺平。恰恰相反，我对自己的要求更高了。以前，我可能只需要会写 Python 就能应付大部分工作；现在，我必须同时精通三样东西：业务逻辑的抽象能力、Prompt 工程的精准表达能力，以及对 AI 输出的批判性审查能力。AI 是一个超级高效的执行者，但它不是一个合格的决策者。它不会问我：“这个汇率转换功能，是给内部财务人员用，还是给外部客户用？对精度的要求是小数点后两位，还是四位？” 这些问题，依然需要我，作为人类工程师，来定义、来权衡、来拍板。

所以，Cursor 2.0 的真正价值，不在于它能写多少行代码，而在于它把“写代码”这个动作，从一项需要大量低层次、重复性劳动的技能，升维成了一项需要高层次、创造性思维的工程活动。它把我从“码农”，推回了“软件工程师”的位置——我负责设计、决策、验证；它负责实现、填充、执行。这种分工，不是取代，而是解放。

最后分享一个小技巧：我给自己建了一个ai-notes.md文件，放在每个项目的根目录下。每当 AI 生成了一段特别巧妙的代码，或者解决了一个我百思不得其解的难题，我就会把 Prompt、AI 的输出、以及我最终采用的修改，都记录进去。比如：

## 2024-05-20: Persistent Currency Selection - **Prompt**: "Make the source and target currency selections persist..." - **Best Output**: Sonnet 4.5's solution with st.session_state initialization and st.rerun() - **Key Insight**: Always use unique `key` for every st.selectbox to prevent state collision.

这个文件，就是我与 AI 协作的“知识结晶”。它不只是一份笔记，更是我未来所有项目的“Prompt 模板库”和“避坑指南”。它在无声地告诉我：在这个人机共舞的新时代，最强大的工具，永远不是 AI，而是那个懂得如何与 AI 共同进化的人。