今年技术圈最出圈的热词，绕不开Vibe Coding，也绕不开Cursor和Claude Code。很多人把Vibe Coding简单理解成“跟AI聊几句就把项目写出来”，实际跑过完整全栈项目的开发者都清楚，这只是最表层的那层壳。真正让AI在全栈开发里稳定落地、把项目从想法推进到可演示状态的，是一套组合拳：用SDD（规格驱动开发）把需求变成AI能执行的规格，用Cursor和Claude Code分别承担交互式开发与自主执行任务，再用多Agent协作把前端、后端、测试拆成并行的产线。这篇文章就是我跑完这套完整流程之后的实战记录，适合正在用AI写代码、想从“偶尔用用”升级成“全流程依赖”的开发者，也适合计划在团队里推广AI开发流程的负责人参考。

1. 先盘清楚：Vibe Coding、SDD、多Agent到底在说什么

1.1 Vibe Coding不是偷懒，是开发者的工作重心变了

Vibe Coding的本质，是开发者从“逐行敲代码”变成“用自然语言描述意图，AI生成实现，人类负责决策与审查”。打个比方：以前你是上场打球的运动员，每个动作都要自己来；现在你是场边教练，要能看懂球员哪里跑位错了、战术哪里不合理，然后喊话调整。AI是那个体能好、手速快但偶尔犯迷糊的队员，你不再需要自己投篮，但你必须懂球。

这里有个很容易误会的点：很多人觉得Vibe Coding就是“随便说句话让AI生成”，交付质量全靠抽奖。实际上做得好的开发者，是把需求拆得很细、把数据结构想得很清楚、把验收标准写得很具体之后，才开始跟AI对话。所以Vibe Coding对系统设计能力的要求反而更高了，它对“表达”的要求，远超对“打字”的要求。我见过太多人抱怨“AI写出来的代码不能看”，细问之下，十有八九是需求描述只有一句话：“帮我写个博客系统”——这种输入，AI不跑偏才怪。

1.2 SDD规格驱动开发：给AI上第一道紧箍咒

SDD（Spec-Driven Development，规格驱动开发）的核心思路，是在写代码之前，先写一份足够清晰、结构化、可验证的规格文档，把“系统要做什么、边界在哪里、验收标准是什么”固定下来，然后让AI严格基于规格去实现。整个开发链条从“需求→设计→编码→测试”变成了“需求→规格→任务→代码→测试→验收”。

SDD在AI时代的重要性，比在传统开发时代大得多。大模型没有“常识边界”，你给它一个模糊目标，它就会以自己的理解自由发挥，结果往往是代码能跑，但完全不是你要的东西。规格文档就是给AI上的第一道紧箍咒。我见过有团队跳过规格直接让AI开工，前三天产出飞快，第四天发现接口设计、数据模型、权限逻辑全都要推倒重来——问题不在AI能力，而在规格没写清。写清楚一份规格，看起来多花了半天，实际省下的是后面三天的返工。

1.3 多Agent协作：把单线程助手变成一支虚拟小队

单Agent做复杂项目，最典型的瓶颈是上下文越来越长、返工越来越多、改一处带动另一处。多Agent的思路，是让不同角色的AI分工协作：规划Agent负责拆任务，实现Agent负责写代码，审查Agent负责找问题，测试Agent负责跑验证。每个Agent只管自己那一亩三分地，输出物明确，交接清晰。

Claude Code这一类和终端打交道的Agent工具天然适合做这种事，它可以起子Agent，也可以多会话并行；Cursor的Agent模式同样支持把不同任务放到独立的工作区里跑。多Agent不等于多多益善，Agent之间的协调成本、上下文传递成本都得算进去。中小型项目一般两到三个角色就够了：一个实现前端的、一个实现后端的、再加上人类的审查。团队越大、角色越多，需要投入的“管理成本”越高，这个度要自己把握。

2. 工具链选型：Cursor和Claude Code怎么搭最顺手

2.1 Cursor：人在回路的交互式开发主力

Cursor本质上是AI原生的代码编辑器，它能索引整个代码库，在对话里引用具体文件，提供Tab补全、行内编辑、Chat面板和Agent工作区。它的强项在于“人在回路”：代码就在你眼前，AI每改一步你都能立刻看到diff，能选中一段代码精确说“这里改成xxx”，也能直接在预览里看效果。做前端页面、调样式布局、改某个函数的边界条件，这种需要“眼睛盯着”的活，Cursor是我的首选。

我实测下来的感受是，Cursor更适合“我带着AI一起改代码”的场景，而不是“全权交给AI”的场景。因为它的交互节奏太快，人很容易陷入“一句一句喂、一段一段改”的低效循环。好处是你可以随时纠正方向；坏处是你得一直坐在驾驶座上。所以我把Cursor定位为“交互式开发主力”，适合那些我需要确认每一步效果的工作。

2.2 Claude Code：终端里的自主执行Agent

Claude Code是跑在终端里的Agent编程工具，能读项目文件、编辑代码、执行shell命令、运行测试、读取测试结果、自己决定下一步操作。它的自主性比编辑器内对话强很多：你可以把一个多步骤任务一次性丢给它，它会按“读规格→建文件→写实现→跑测试→修失败→提交”这种方式自己往下推。

在SDD流程里，Claude Code最合适的角色是“执行层”。把包含完整上下文的任务单交给它，让它自主完成，人只需要在它提交后做review。注意，给Claude Code的任务描述必须写清楚“做什么、别碰什么、做完怎么验证”，否则它会为了“完善细节”在你不关心的地方浪费大量上下文和算力。我见过它花十分钟去优化一个从来没有性能问题的函数的例子，纯粹是因为任务单里没写“不需要优化性能”这句话。

2.3 两个都要：分工比二选一更实际

被问最多的一个问题：只选一个行不行？我的答案是，如果预算和精力允许，最好两个都要。它们不是替代关系，是互补关系。

这套搭配的核心逻辑是：复杂项目里，“精确修改”和“自主执行”是两种完全不同的需求，一个工具很难同时做到极致。Cursor负责需要人在回路的精细活，Claude Code负责人可以放手的批量活，两者共用同一份Spec和同一套任务单，配合起来就是一条完整产线。

2.4 环境准备与最小配置（照着做就行）

第一步，安装Cursor并登录，在设置里选择你常用的模型。第二步，在项目根目录创建.cursorrules文件，写入项目技术栈、代码风格、禁止事项。第三步，安装Claude Code，在项目目录里完成授权登录，它会自动扫描并索引当前代码库。第四步，创建CLAUDE.md，内容与.cursorrules对齐，保证两个工具遵守同一套规则。第五步，建好标准目录：docs/放Spec，tasks/放任务单，src/放代码，scripts/放脚本，tests/放测试。

一份够用的CLAUDE.md，我一般控制在200到300行以内：

# 项目约定 - 技术栈：React + Vite + Node.js + Express + SQLite - 目录结构：src/components 放前端组件，src/server 放后端逻辑 - 测试命令：npm test（必须全绿才能提交） - 命名规范：接口URL用kebab-case，数据库表名用snake_case - 禁止事项：不要新增未在package.json中声明的依赖；不要修改docs/下的规格文档

实测提示：CLAUDE.md别写得像百科全书，太长反而稀释Agent对关键规则的注意力。把“技术栈、目录约定、测试命令、命名规范、禁止事项”讲清楚，足够覆盖多数场景。

3. SDD工作流的落地：从规格文档到Agent任务

3.1 规格文档：一份AI能直接执行的“需求说明书”

Spec不是给领导汇报的PPT式需求，而是给AI执行的结构化契约。我写Spec固定包含七个部分：项目背景与目标、用户故事清单、技术栈与架构约束、数据模型、接口契约、界面交互说明、验收标准与不做清单。其中“不做清单”最容易被人忽略，但恰恰是最重要的一个部分——它告诉AI哪些事情明确别碰，防止自由发挥。

验收标准尽量写成可验证的条目。比如“注册接口在邮箱格式错误时返回400及错误码INVALID_EMAIL”，而不是“邮箱校验要处理”。“处理”这个词，人和AI的理解差异极大，写成具体的状态码和错误码，AI才知道什么叫“算完成”。这一步就是给整个项目定基调，后面所有Agent的行为都要对齐这份文档。

3.2 任务拆解：把Spec切成Agent吃得到的小块

拿到Spec之后，把实现拆成若干个小任务，每个任务一个文件，包含目标、涉及文件、输入输出、约束条件、完成定义（DoD）、依赖任务。任务拆得越小，Agent执行越稳定，后续审查也越容易定位问题。我习惯把任务拆成“前端任务集”和“后端任务集”两条线：前端交给Cursor交互式实现，后端交给Claude Code自主实现，两条线各自在独立分支上跑，最后再合并。

一份任务单大概是这个样子：

## 任务T03：文章CRUD后端实现 - 目标：实现文章的创建、编辑、发布、软删除接口 - 涉及文件：src/server/routes/article.js、src/server/models/article.js - 依赖任务：T01（数据模型落地）、T02（数据库连接与迁移） - 约束：不修改前端目录；不引入额外依赖；所有SQL操作使用参数化查询 - 完成定义：所有接口通过supertest集成测试；测试代码提交到tests/api目录；npm test全绿

3.3 执行顺序：Spec→任务→实现→验证→回归的闭环节奏

整体的执行节奏是这样的：先写Spec，再拆任务单，然后按依赖顺序排优先级。一般先做数据模型和核心接口，再做前端页面接入。每完成一个任务，立刻跑验证：测试、lint、diff审查。验证不通过就返回重写，而不是把验证全部留到最后——最后统一验证的后果，大概率是一场填坑大会。

这套思路和传统工程里的持续集成是一脉相承的，只不过这里的“执行者”换成了AI Agent。人的角色变成了“产线调度员”：哪个任务卡住了，就去看是Spec表述不清，还是任务单粒度太粗，还是Agent跑偏了。别直接上手改代码，先回去改描述，再让Agent重跑。

3.4 上下文管理：多Agent协作里最大的成败因素

多Agent工程里真正卡脖子的，不是模型能力，是上下文。每个Agent的上下文窗口有限，你不可能把整个项目全部塞给它。我的方法是：项目根目录维护一份精简的“项目总览”文档，每个任务单自带上下文，Agent开工时只读“总览+任务单+它要动的具体文件”，无关文件一概不读。

相当于每个Agent只看到自己负责的这一亩三分地，而不是整个农场。这样准确率显著提升，Token消耗也明显下降。常见反面案例是：把整份需求文档全文塞给Agent，它读到中间某个无关业务模块的描述，行为立刻跑偏到十万八千里外。正确的粒度是“两三个相关文件 + 一份任务单 + 一份项目规则”，足够单个Agent完成单个任务。

4. 实战全过程：一个内容管理Demo从0到落地

4.1 项目背景：模拟项目X，覆盖全栈完整流程

我用一个做过的模拟项目X来还原整个流程。背景很简单：某团队需要一个轻量内容管理Demo，支持文章的创建、编辑、发布，分类与标签，以及简单的用户登录和权限区分（管理员、编辑、游客）。技术栈定为：前端React + Vite，后端Node.js + Express，数据库SQLite，所有操作走REST接口。目标是一个星期内出可演示、核心流程能跑通的版本。

这个项目规模不大，但覆盖了前端、后端、数据模型、权限控制、自动化测试五个层面，足够演示SDD + 多Agent的全流程到底怎么走。我希望通过这个例子说明一件事：AI能扛住的不只是单页面Demo，而是有权限、有数据关系、有验收标准的完整全栈项目，前提是你的流程足够规范。

4.2 阶段一：写Spec和拆任务，花一小时定基调

我先动手写了完整Spec，放进docs/spec.md。摘录其中的核心部分：

## 数据模型（核心） - User: id, username, passwordHash, role(admin|editor|viewer) - Article: id, title, content, status(draft|published), categoryId, authorId, createdAt, updatedAt - Category: id, name, slug ## 接口契约（核心） - POST /api/auth/login 参数(username,password) 成功返回token 失败返回401 - GET /api/articles?status=draft 仅管理员与作者本人可访问 - PATCH /api/articles/:id 仅作者本人或管理员可修改 ## 验收标准（摘录） - 登录接口密码错误时返回401和错误码INVALID_PASSWORD - 游客访问发布接口必须返回403 - 创建文章后按ID可查询到，字段完整

写完Spec后，我拆出8个任务单：后端接口与模型4个、前端页面3个、权限与种子数据1个。每个任务单都带完成定义。这个阶段花了我大约一小时，但它决定了后面所有Agent的工作边界，是整条流程里性价比最高的一小时。

4.3 阶段二：Cursor实现前端骨架，边看边改

前端三个任务在Cursor里做。我开的第一个提示大概是这样的：“按docs/spec.md和docs/tasks/T05.md实现文章列表页，使用React Router接入路由，页面包含状态筛选和分页，样式复用现有组件库，不要新增依赖。”这里有一个关键动作：必须强制Agent去读Spec和任务单，不许凭空发挥。

Cursor在做前端时最大的优势是即时反馈。列表页的加载态、空态、错误态这些细节，我在预览里看到效果后，直接选中对应代码要求重写，它马上就能改。这个过程很像带一个手速很快、但对业务理解不够深的初级工程师，你得坐他旁边盯着。每完成一个页面，我立刻在浏览器里过一遍交互，确认手感没问题再进入下一个任务。

4.4 阶段三：Claude Code自主完成后端与测试闭环

后端四个任务我全部交给Claude Code。在项目根目录执行一条命令，把任务链和边界条件一次性交代清楚：

claude -p "阅读docs/SPEC.md、docs/tasks/T01.md和T02.md，按顺序实现。每完成一步运行npm test确保通过。不修改前端目录，不引入额外依赖。全部通过后用git提交，commit信息按feat(api):描述规范写。"

它自己会按顺序读文件、建模型、写路由、写测试、跑测试、修复失败、提交commit。中间出现过两次测试失败，它读到报错信息后自己改了实现又重新跑通，全程没有打扰我。这一步是我认为整套流程里价值最大的——把“机械但繁琐”的后端实现和测试闭环完全放养出去，我只在提交之后做一次代码审查，省下来的时间可以并行推进其他工作。

4.5 阶段四：联调时两边Agent打架，回Spec层裁决

联调阶段出现了一个非常典型的冲突：前端任务里，Cursor按照自己的理解给文章列表接口加了一个排序参数sort=created_at，但后端根据Spec只实现了按创建时间默认排序，并没有实现sort过滤参数。两边都觉得自己没错，但接口就是对不上。

这种时候我不会在代码层“拉偏架”，而是回到Spec层解决。我在接口契约处补了一行：“GET /api/articles支持可选参数sort，取值created_at或updated_at”。然后给Cursor一个“前端改用Spec中sort约定”的指令，给Claude Code一个“后端补充sort排序支持”的更新任务。两边各自改完，重新联调一遍就通了。这条经验值很多钱：多个Agent意见不一致，别急着改代码，先回到规格文档重新定义契约，事半功倍。

4.6 阶段五：按验收标准逐条过，确认可交付

最后按Spec里的验收标准逐条验证：自动化测试全绿；手工过了一遍登录、权限区隔、文章发布全流程；权限边界用curl验证过三次，确认游客访问发布接口确实返回403。项目从写Spec到可演示，实际用了不到两个工作日，其中我真正坐在键盘前的时间大约占三分之一，其余时间都在写任务单、看diff、审Spec。

对比以前纯手工写这个规模的Demo至少要一周，效率提升非常明显。当然代价也很清楚：我花在Spec编写和任务拆解上的时间，比以往做“需求文档”的时间多得多。这段投入不能省，省掉了，后面AI返工的时间会加倍找补回来。

5. 常见问题与排查技巧实录

5.1 上下文爆炸：Agent做到一半“失忆”怎么办

典型症状：前期执行得好好的，到了后期开始重复修改同一个文件、忘记任务单早先明确的约束。原因很直接：单次会话上下文过长，早期信息被压缩甚至丢弃。解决思路是把任务拆小，一个会话只做一件事；关键约束同时写进任务单和项目总览，不要指望Agent记住对话历史；会话太长就主动开新会话，把必要上下文在任务单里重新声明一遍。我按这个策略调整之后，“失忆”问题基本消失。

5.2 Agent之间互相覆盖代码：怎么防踩踏

前端Agent和后端Agent如果同时碰某个共享文件，比如路由入口、package.json，就会互相覆盖，改完A改B，最后合并不了。防踩踏的办法有三个：第一，按目录和文件划分所有权，任务单里写死“不得修改前端目录”这类硬约束；第二，用分支隔离，前端线一个分支，后端线一个分支，联调时再合并；第三，遇到必须由两边共用、谁也说不清的共享文件，由人来改，不授权给任何Agent。

5.3 幻觉式产出：拦截AI“一本正经地胡说八道”

AI写代码时会出现引用不存在的依赖、臆造接口字段、调用从没写过的函数的情况。拦截靠三道防线：第一，在完成定义里强制要求“所有引用必须真实存在”，审查diff时先查依赖和import来源；第二，验收标准写具体，让测试兜底，凡是测不出来的边界基本等于没做；第三，重要模块不要一次性生成，先让Agent输出实现计划，人确认后再生成代码。我踩过最狠的一次，是Agent在配置里引了一个并不存在的中间件，直到上线前才暴露出来。从那以后，“禁止引用未安装的依赖”这句话固定写进CLAUDE.md。

5.4 效率陷阱：这些任务别硬塞给AI

这不是说AI能力不行，而是投入产出比问题。让AI去负责它擅长的“按已知方案快速实现”，把需要全局判断、安全责任、架构共识的事留给人，整体效率才最高。这是我跑了多个项目之后最深的体会。

6. 我的实操体会

上面这套流程，我是连续跑了好几个项目之后才稳定下来的。最大的体会是：Vibe Coding全栈实战，真正的工作量不在“让AI写代码”，而在“把需求翻译成AI能执行的规格”、在“把任务拆到AI不会跑偏的粒度”、在“AI产出之后做有效的审查”。工具只是把执行速度放大了，放大既可以是好事也可以是坏事——你的规格混乱，它会以同样的速度把混乱做成代码。

最后分享一个小技巧：每跑完一个项目，把“这次哪些任务AI做得好、哪些做得差”记到项目根目录的notes/retro.md里。下次开新项目时，让Agent先读这份回顾。AI不会主动记住上个月的教训，但你可以替它记住，而它会在你的提醒下，表现得比上次更好。