AI 编程工具大盘点：Cursor、v0 与我的工作流重构

前言

从 2023 年写 ChatGPT API 接入开始，到今年研究 MCP、做多模态，AI 已经从”我研究的对象”变成了”我干活的工具”。这一年我把主流 AI 编程工具都重度用了一遍：Cursor 当主力 IDE、v0 出原型、Claude Code 跑终端任务，工作流几乎被重塑了一遍。

年底正好适合做个盘点。这篇文章先横向梳理 2025 年 AI 编程工具的格局，然后完整还原我现在的开发工作流——从需求到上线，每一步用什么工具、喂什么 Prompt，最后聊聊哪些活儿交不掉，以及我对前端岗位的一点思考。

1. 2025 年 AI 编程工具格局

AI 编程工具工作流

1.1 四类玩家，四种定位

一年用下来，我把工具归成四类，关键是认清各自的生态位：

IDE 深度集成型（Cursor、Windsurf）：编辑器即 Agent。优势是上下文全——能索引整个代码库，改代码、跑命令、看 diff 一气呵成。适合在既有仓库里做中大型改动，是我现在 80% 时间的主战场；
终端 Agent 型（Claude Code、Codex CLI）：活在终端里，擅长跨文件的多步任务：批量重构、补测试、修 CI、生成文档。不需要 GUI，方便接进脚本和 CI/CD；
原型生成型（v0、Bolt、Lovable）：从一句话或一张截图直接生成可运行的前端应用，天然贴着 React + Tailwind 这套现代前端栈。适合 0→1 的原型和落地页，产出质量高到可以直接当代码起点；
对话辅助型（ChatGPT / Claude 网页版）：不碰仓库，纯问答与方案讨论。别小看它，”先用自然语言把方案吵清楚”恰恰是效率最高的环节。

选型的心法就一句话：按任务的”半径”选工具——改动一个函数用 IDE 内联补全，改动一个模块用 Cursor Agent，跨服务跑任务用 Claude Code，从零起页面用 v0。

2. 我的工作流重构全过程

2.1 第一步：用 v0 把需求”变成看得见的东西”

需求的第一瓶颈从来不是写代码，而是”对齐想象”。以前是画线框图，现在直接让 v0 出可交互原型。

我的真实 Prompt（节选）：

帮我做一个"看图说话"的 Web 应用界面：
- 左侧是图片上传区，支持拖拽，上传后显示缩略图和压缩前后的大小对比
- 右侧是对话区，底部输入框，模型的流式回复逐字显示
- 中间有一个"开始录音"按钮，录音时显示实时波形
- 整体用暗色主题，风格参考 Linear，组件用 shadcn/ui
先出桌面端，移动端布局下一轮再说。

心得：给 v0 的 Prompt 要”给边界、不给实现”——说清楚有哪些区块、什么交互、什么风格参照，但不要指手画脚写实现细节。v0 生成的代码是标准 React + Tailwind + shadcn/ui，质量足以直接进仓库，但千万不要让它直接上线：它不懂你的业务约束，也没处理边界情况。

2.2 第二步：Cursor 重构落地

把 v0 产出搬进真实仓库后，轮到 Cursor 做融合：对齐项目规范、把 mock 数据换成真实接口、补鉴权和错误分支。这一步我的做法是”小步快跑”：一次只让 Agent 做一件事，每件事给足上下文。

真实 Prompt（节选）：

把 src/features/vision/ 下的 mock 实现（vision-client.ts）替换为真实 API 调用：
1. 请求统一走 src/lib/http.ts 的 fetch 封装，带错误码处理
2. 图片压缩逻辑复用 src/lib/image.ts 的 compressImage，不要重复造轮子
3. 参考同目录 receipt.ts 的现有风格
先列改动计划，我确认后再动代码。

心得：**”先列计划再动手”**这一句最值钱。Agent 直接开改经常南辕北辙，先让它输出计划，我花 10 秒钟校准方向，返工率能降一大半。另外明确告诉它”复用哪些现有模块”，能显著减少重复造轮子。

2.3 第三步：Claude Code 补测试与文档

功能落地后的”体力活”整体外包给 Claude Code，在终端里一段话交代清楚：

为 src/features/vision/ 目录补齐单元测试：
- 覆盖 compressImage 的边界：超大图、透明 PNG、损坏文件
- 覆盖 parseReceipt 的异常：非法 JSON、字段缺失、金额为负
- 用 vitest，mock 掉 fetch，跑通后输出覆盖率报告
完成后把 vision 模块的使用文档补进 docs/vision.md，包含 API 说明和示例代码。

它会自己读代码、写测试、跑测试、看失败原因、修、再跑，几轮之后把覆盖率从 0 拉到 80% 以上。我的角色从”写测试的人”变成”review 测试的人”——重点检查它有没有为了凑覆盖率写”永远为真”的断言。

3. Rule 文件与上下文管理

工具的上限取决于喂给它的上下文质量。这一年在规则文件上我沉淀了两条经验。

3.1 .cursorrules 写什么

原则是”写约束，不写常识”。模型都知道怎么写 React，但它不知道你们团队禁止 any。顺带说下规则文件本身的演进：Cursor 官方现在主推 .cursor/rules/ 目录，规则拆成一份份 .mdc，还能按 glob 只挂到特定路径生效；老的 .cursorrules 单文件目前仍然兼容，我暂时没迁。下面是我 .cursorrules 的核心内容：

# 技术栈约束
- React 18 + TypeScript strict 模式，禁止 any / @ts-ignore
- 样式用 Tailwind，不引入新的 CSS 方案
- 状态管理：服务端状态用 TanStack Query，本地状态用 zustand

# 代码风格
- 组件用函数式 + hooks，文件名小写中划线
- API 层统一走 src/lib/http.ts，禁止裸 fetch

# 项目上下文
- 这是 Hexo 博客仓库，文章在 source/_posts
- public/ 下是构建产物，改之前先确认

# 协作方式
- 复杂改动先输出计划，经我确认再实施
- 引用现有代码时给出文件路径，不要凭空假设 API 存在

3.2 AGENTS.md：给终端 Agent 的”入职文档”

终端 Agent 这一派读的是仓库里的 AGENTS.md（Codex CLI、Gemini CLI 都认这份文件；Claude Code 读的是 CLAUDE.md，常见做法是把它软链到 AGENTS.md 共用一份），我放的是另一类信息：项目怎么跑起来、怎么测试、哪些目录不要碰——相当于新同事入职第一天发的那份 README。两个文件各司其职：**.cursorrules 管”怎么写代码”，AGENTS.md 管”怎么干活”**。

还有一条上下文管理的心得：不要指望工具自动理解一切。让 Agent 干活前，把相关文件的路径、领域术语、历史决策显式喂给它；但上下文也不是越多越好，塞一堆无关文件只会稀释注意力——这一点和写 Prompt 是同构的。

4. 哪些活交不掉

一年下来，我明确梳理出四类”交不掉”的活：

架构决策。选型、模块边界、技术债的取舍，需要对业务和团队的理解，Agent 给的方案永远”看起来都对”，但拍板的责任在人；
Code Review。AI 生成的代码更要严审：它会一本正经地写出能跑但方向错的实现，还会为凑答案编造不存在的 API。Review 是现在质量保障的主战场，投入比以前更大而不是更小；
需求澄清。产品经理嘴里的”简单改一下”背后是什么，只有人能问出来。Prompt 工程的上游是需求工程；
跨系统的隐性知识。为什么这个服务不能重启、那个接口只能低频调用，这些不在代码里的知识，Agent 永远不知道要问。

5. 效率提升的粗略估算

（以下是主观体感估算，不是严格测量，仅供参考。）

原型与 UI 阶段：v0 把”出可交互原型”从 2-3 天压到半天以内，体感提升 3-5 倍；
常规业务开发：Cursor 加持下大约快 40%-50%，主要是样板代码和胶水逻辑几乎零成本；
测试与文档：提升最猛，过去”永远排不上优先级”的活现在基本零心理负担，体感 5 倍以上；
整体：以”需求上线”为口径，估摸提升 50% 左右。但要注意：省下来的时间并没有变成摸鱼，而是流向了架构思考、Review 和需求澄清——这些恰恰是过去被压缩的环节。