Vibe Coding全栈实战：用SDD和多Agent搭建AI开发流水线

今年技术圈最出圈的热词绕不开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上第一道紧箍咒SDDSpec-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终端里的自主执行AgentClaude Code是跑在终端里的Agent编程工具能读项目文件、编辑代码、执行shell命令、运行测试、读取测试结果、自己决定下一步操作。它的自主性比编辑器内对话强很多你可以把一个多步骤任务一次性丢给它它会按“读规格→建文件→写实现→跑测试→修失败→提交”这种方式自己往下推。在SDD流程里Claude Code最合适的角色是“执行层”。把包含完整上下文的任务单交给它让它自主完成人只需要在它提交后做review。注意给Claude Code的任务描述必须写清楚“做什么、别碰什么、做完怎么验证”否则它会为了“完善细节”在你不关心的地方浪费大量上下文和算力。我见过它花十分钟去优化一个从来没有性能问题的函数的例子纯粹是因为任务单里没写“不需要优化性能”这句话。2.3 两个都要分工比二选一更实际被问最多的一个问题只选一个行不行我的答案是如果预算和精力允许最好两个都要。它们不是替代关系是互补关系。维度CursorClaude Code工作界面图形化IDE终端命令行交互方式实时可见、逐处确认自主连续执行擅长场景前端调试、样式调整、精确修改、代码审查后端实现、批量任务、跑测试闭环、git操作项目记忆.cursorrules 会话上下文CLAUDE.md 会话上下文人工介入频率高适合人在回路低可以无人值守这套搭配的核心逻辑是复杂项目里“精确修改”和“自主执行”是两种完全不同的需求一个工具很难同时做到极致。Cursor负责需要人在回路的精细活Claude Code负责人可以放手的批量活两者共用同一份Spec和同一套任务单配合起来就是一条完整产线。2.4 环境准备与最小配置照着做就行第一步安装Cursor并登录在设置里选择你常用的模型。第二步在项目根目录创建.cursorrules文件写入项目技术栈、代码风格、禁止事项。第三步安装Claude Code在项目目录里完成授权登录它会自动扫描并索引当前代码库。第四步创建CLAUDE.md内容与.cursorrules对齐保证两个工具遵守同一套规则。第五步建好标准目录docs/放Spectasks/放任务单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?statusdraft 仅管理员与作者本人可访问 - 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按照自己的理解给文章列表接口加了一个排序参数sortcreated_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很难掌握全貌人先设计再让AI执行局部改造安全敏感代码权限、加密、支付类出问题代价太高人写核心AI辅助review架构决策需要多人共识与长期演进视角人在会议里定AI做落地线上紧急故障排查紧急时刻AI只会给一堆推测人先看日志定位AI做辅助分析这不是说AI能力不行而是投入产出比问题。让AI去负责它擅长的“按已知方案快速实现”把需要全局判断、安全责任、架构共识的事留给人整体效率才最高。这是我跑了多个项目之后最深的体会。6. 我的实操体会上面这套流程我是连续跑了好几个项目之后才稳定下来的。最大的体会是Vibe Coding全栈实战真正的工作量不在“让AI写代码”而在“把需求翻译成AI能执行的规格”、在“把任务拆到AI不会跑偏的粒度”、在“AI产出之后做有效的审查”。工具只是把执行速度放大了放大既可以是好事也可以是坏事——你的规格混乱它会以同样的速度把混乱做成代码。最后分享一个小技巧每跑完一个项目把“这次哪些任务AI做得好、哪些做得差”记到项目根目录的notes/retro.md里。下次开新项目时让Agent先读这份回顾。AI不会主动记住上个月的教训但你可以替它记住而它会在你的提醒下表现得比上次更好。