去年有一段时间我几乎每天都在“vibe coding”。需求丢给 AI它飞快地吐代码我看着预览窗口点点头点一个“accept”然后继续下一段。新鲜感过去之后代码库慢慢变成了一场事故没有统一的设计约束命名一会儿驼峰一会儿下划线错误处理经常被 try/catch 吞掉最要命的是几乎没有测试。最惨的一次一个内部工具从“能跑”变成“不敢动”只花了一个下午。后来我在团队里把规格驱动开发SDD整套流程引入日常AI 编程才从“写着玩”变成“能交付”综合算下来提效确实是往 50% 靠拢的。这篇文章不聊某个花哨的提示词技巧而是想把经过我验证的一套 SDD 六步实践指南完整盘一遍再用 GitHub Copilot、Cursor、JetBrains AI Assistant 这三个主流工具在同一个需求下做一次实战对比。如果你每天都要和 AI 一起写代码但又觉得代码质量不太稳或者正准备把 AI 编程引入团队协作这篇应该能给你一个直接可用的参考。1. Vibe Coding 看起来很爽为什么项目越来越难改1.1 Vibe Coding 的爽与痛Vibe Coding 大概是 2024 年底开始流行的概念核心是“跟着感觉走”把写代码这件事从传统的手工敲键盘变成给 AI 下指令描述一个模糊的效果然后让 AI 生成一段看起来能跑的代码。它最大的爽点在于即时反馈拿到一个需求往编辑器里一贴用几句自然语言描述AI 就给你一整段可以演示的东西。做原型、做 demo、做一次性脚本时这种模式效率确实无敌我直到现在都还在用。但问题恰恰出在“感觉”上。Vibe Coding 依赖的是语感和脑补而不是确定性的契约。代码一旦进入生产项目生命周期就不是几分钟而是几个月甚至几年这段生命周期里最消耗成本的动作是理解、修改、排查而这三个动作恰好是纯 Vibe Coding 最不擅长的。我见过不少把 Vibe Coding 用进业务的团队前两周跑得飞快后面每天都在下坡路上补坑你想加一个字段顺着 AI 生成的逻辑往回找至少要翻三四个文件每个文件里的代码看起来都“差不多”但谁也不敢保证改了不会影响别处。这不是 AI 能力的问题而是工作方式的问题。Vibe Coding 默认“AI 能猜中我想要什么”但实际项目中需求很少是清晰的边界条件、异常流程、性能约束、代码风格这些隐含信息如果不主动给出来AI 只能靠概率补全。于是代码的“正确性”变成了靠运气而不是靠设计。1.2 没有规格AI 就是在盲写很多人把 Vibe Coding 失败归因于“AI 太笨”其实这是把因果关系搞反了。大模型的生成能力早就不是短板真正稀缺的是“输入质量”。我在项目中做过对照组实验同样让 Cursor 写一个库存模块一种方式是直接说“帮我写个库存 API”另一种是先给它一份一两百字的规格说明里面写清楚接口路径、请求参数、校验规则、错误码和测试要求。后者的产出质量明显上一个台阶第一版就能通过大部分单测而前者写出来的代码接口命名随意字段类型混乱连最基本的数据校验都要靠人肉补。原因在于大模型的本质是“续写概率最高的内容”。上下文越模糊它越倾向于续写“最常见的代码”而不是“你需要的代码”。规格就是打破这种模糊的工具它把业务约束、边界条件、技术栈限制用文字显性化AI 续写时才会往正确方向走。Vibe Coding 的“vibe”给不出这些约束所以生成结果只能看运气。1.3 什么时候应该换 SDD我并不是说 Vibe Coding 一无是处它非常适合探索性的场景。但如果你的项目满足下面任意一条就值得认真考虑引入 SDD代码要提交到共享仓库供多人协作和长期维护功能会持续迭代后续大概率要改或者扩展涉及数据一致性、金额、权限、库存这类不能出错的逻辑需要给测试同学、运维同学甚至审计交代行为反过来如果你只是写一个临时脚本、调一个接口看结果、做一次性的数据清洗那 Vibe Coding 完全够用没必要套方法论过度设计也是成本。2. SDD 六步实践指南把规格当代码来写2.1 SDD 的核心思想SDD 全称是 Specification-Driven Development规格驱动开发。它的核心逻辑一句话就能讲清楚先花时间写清楚“要做什么、怎么算完成”再让 AI 写“怎么做”。听起来很简单但真做起来和多数团队的日常习惯差别很大。大多数团队的习惯是拿到需求就开写写一步想一步发现问题再回头改。这种模式在没有 AI 时还能靠人脑兜底因为在敲代码的过程中人会不断修正对需求的理解。但 AI 没有这个能力或者说它不会主动修正你的模糊指令。你给它一句“做个注册功能”它就真的只给你一个“看起来像注册”的东西至于手机号格式、密码策略、重复注册、验证码超时这些细节它会默认简化掉。SDD 做的事情就是把这些细节前置到开发开始之前。我把整个流程拆成六步这六步不是硬性理论而是我从实际踩坑里总结出来的操作清单。2.2 六步法第一步到第三步意图、验收标准、技术约束第一步写意图描述。用自然语言写清楚这个功能在什么场景下使用用户是谁核心目标是什么。比如“用户输入手机号和验证码完成注册注册成功后自动登录”这个描述比“写一个注册接口”要有用得多因为它交代了流程的上下游。第二步写验收标准。这是整个 SDD 里最关键的一步。“功能完成”不能靠感觉判断必须有一组可验证、可执行的标准。最好的形式是一组行为描述比如“当手机号已注册时注册接口返回 HTTP 409且响应体里包含 error_codePHONE_EXISTS”。这比“需要处理重复注册”要强一个数量级因为 AI 可以直接根据这个描述写出对应断言也可以根据断言反推实现逻辑。第三步写技术约束。语言、框架、依赖、目录结构、代码风格、性能要求都写清楚。团队里有约定俗成的规范时一定要写进去否则 AI 会生成一套与仓库风格完全脱节的代码。举个例子你们统一用 Zod 做参数校验但没写进规格里AI 大概率会给你手写 if 判断这样代码进到 review 阶段等于重写。2.3 六步法第四步到第六步骨架先行、分块实现、评审重构第四步骨架先行。让 AI 先生成接口签名、数据模型、目录结构或者测试用例而不是直接堆实现逻辑。这一步很多人会跳过去它的价值在于先定契约先告诉 AI“模块长什么样”再让它填肉。你可以在规格文档里直接定义好接口路径和数据结构让 AI 严格按这些定义生成骨架。骨架通过你的确认之后再进入下一步否则后续修改成本会翻倍。第五步分块实现测试兜底。把功能拆成若干个小模块一个模块一个模块地让 AI 实现每完成一块就立刻跑测试。跑过再继续下一块没跑过就当场让它修。这样比一次性让 AI 生成几百行代码再统一调试要稳得多因为出错范围被压缩在一个小块里定位问题轻松很多。第六步评审与重构。把 AI 生成的代码当成同事写的代码来 review删冗余逻辑、统一命名风格、补边界条件、确认异常处理策略。这一步是很多 AI 编程实践里被省略的但恰恰是决定代码能否长期维护的关键。AI 生成的代码通常能跑但往往存在过度设计、重复计算、不必要的抽象评审就是把这些问题提前按住。2.4 为什么这条流程能提效 50%很多人以为提效来自“AI 写得快”但 SDD 的提效主要来自减少返工。传统 AI 编程里来回让 AI 修 bug 的时间可能占到总耗时的一大半。有了规格和验收标准之后生成质量被前移AI 第一版就能接近正确代码评审阶段从“整个重写”变成“小修小补”。在我自己的项目统计里同样的一个约 300 行的后端模块Vibe Coding 模式从开始到合入平均需要 3 到 4 轮修改SDD 模式平均 1.5 轮再算上测试自动兜底节省的回归时间总耗时大概省下四到五成。这个数不精确但方向和量级我是有把握的。3. 三工具实战对比Copilot、Cursor、JetBrains AI Assistant3.1 对比前提与测试需求为了让这场对比尽量客观我特意设计了一个既能体现代码生成能力、又能测试 Agent 感知能力的统一需求用 TypeScript Express Vitest 实现一个完整的商品库存模块包含三个接口——入库、出库、库存查询出库时库存不足必须返回 HTTP 400库存量不允许为负数数据暂存内存即可。我把同一份 SDD 规格文档分别喂给 GitHub Copilot、Cursor 和 JetBrains AI Assistant记录各自的表现包括是否能一次跑通、错误处理是否完整、测试覆盖是否到位、需要额外修改几轮。这个需求比“写个 hello world”要复杂但也足够收敛能比较真实地反映日常后端口开发场景。下面是三个工具的表现记录。3.2 GitHub Copilot稳但更像高级补全GitHub Copilot 是目前装机量最大的 AI 编程助手它最强的点是把补全体感做进了编辑器写一行函数签名按一下 Tab 就能接受剩下的函数体几乎不打断思维流。在 SDD 流程里Copilot 最合适的角色是“执行者”——你按照规格把骨架搭好它负责填充每一个函数体。它处理样板代码、工具函数、测试用例里的重复部分非常高效上下文感知偏局部但它能捕捉同一个文件里的变量名和语义。拿这次测试来说我把规格文档粘贴到代码文件顶部的注释里然后开始写路由Copilot 基本把 controller 和 service 层完整补了出来测试部分也能生成但它在出库时库存不足的状态码上一开始写的是 500而不是规格里要求的 400。这说明它读注释的能力有限更依赖你先把函数签名和注释写到位。想要让 Copilot 真正按 SDD 干活你得自己搭骨架、写清晰注释再让它填充主体整体节奏由你主导。3.3 Cursor最接近“读规格干活”的 Agent 体验Cursor 是目前 Agent 模式的标杆之一它最大的特点是可以同时读取多个文件、执行终端命令、运行测试并基于反馈自我修正。这和 SDD 的天然契合点在于你把规格文档放在项目仓库里Cursor 可以直接读文件、分析现有目录结构再按规格从骨架到实现一步步完成。测试中我把规格写在 REQUIREMENTS.md 里然后给它一句“按规格实现库存模块并运行测试确保通过”。它自动创建了 routes、services、types 和测试文件第一次测试失败后不需要我干预它自己看报错信息把库存不足的返回码从 500 改成了 400再跑测试通过。整个过程基本不需要手动介入十次里大概有两三次会碰到比较怪的边界情况需要我点拨一下但整体体验已经是“代理干活、人类验收”的模式。Cursor 另一个比较大的优势是上下文窗口大。规格文档、目录结构、错误信息可以一起喂进去不容易像某些工具一样到后面就“断片”。对 SDD 来说上下文大太重要了因为规格本身就是靠上下文起作用的窗口一小后面的约束容易被遗忘。3.4 JetBrains AI Assistant老牌 IDE 里的稳重型选手如果你的主力 IDE 是 IntelliJ IDEAJetBrains AI Assistant 的集成体验是三个工具里最顺滑的。它直接嵌在 IDE 右侧面板提供对话、代码补全和重构建议和现有开发流程融合得很深。它的补全质量在写 Java、Kotlin、Go 这类强类型语言时尤其稳定这也符合 JetBrains 系产品面向专业开发者的调性。但在这场对比中它的 Agent 能力明显不如 Cursor 激进能理解项目上下文也能生成跨文件改动但在执行命令、自动跑测试、根据结果自我修正这几个环节上更保守。它更像是一位“很懂语法的结对程序员”而不是自动执行任务的代理。测试中它生成的代码质量不差但需要我通过多轮对话逐步引导第一轮生成路由第二轮补服务层第三轮补测试。好在每一轮生成都稳定可控适合喜欢逐步确认的开发节奏。如果你恰好是 IntelliJ IDEA 全家桶用户团队协作方式也是标准编码加少量 AI 辅助JetBrains AI Assistant 是很省心的选择如果想追求极致自动化还是 Cursor 更合适。3.5 三个工具的横向对比与选型建议对比维度GitHub CopilotCursorJetBrains AI Assistant补全质量优秀行级补全极快优秀但更侧重整块生成优秀强类型语言尤其稳Agent 自主执行能力弱主要靠人驱动强可自动跨文件实现并跑测试中能生成跨文件改动但需要多轮对话上下文处理偏局部窗口有限窗口大能读多文件中依赖 IDE 项目模型SDD 适配度高适合按骨架填充极高适合“读规格→自动实现”高适合“逐步确认式”开发推荐场景已有成熟流程只想局部提效自动化优先希望 AI 当代理JetBrains 生态深度用户选型建议很直接主力 IDE 是 VS Code 或者 WebStorm团队重视自动化优先考虑 Cursor主力 IDE 是 IntelliJ IDEA团队还保持传统编码节奏JetBrains AI Assistant 更合适如果你已经有成熟的代码规范和流程只想要一个能随时补全代码的助手GitHub Copilot 依然是性价比很高的选择。三个工具并不互斥我在实际项目中就是组合使用的。4. 实战同一份规格文档三工具的真实产出差异4.1 规格文档示例为了让这场对比可以复现我把测试用的规格文档核心部分贴出来。这份文档我控制在 300 字以内之所以强调字数是因为规格不是越长越好太长的规格会让 AI 注意力分散漏掉后面的约束。要点是把最重要的规则前置这份文档我按照“目标→接口→约束→测试要求”的顺序组织。# 商品库存模块规格 ## 目标 提供商品库存管理能力支持入库、出库、库存查询。 ## 接口定义 - POST /api/products/:id/stock-inbody: { quantity: number }入库 - POST /api/products/:id/stock-outbody: { quantity: number }出库 - GET /api/products/:id/stock返回当前库存 ## 业务规则 1. 出库数量大于当前库存时返回 HTTP 400error_code 为 INSUFFICIENT_STOCK 2. 库存不允许为负数任何把库存置为负数的操作都必须失败 3. quantity 必须为正整数非法输入返回 HTTP 422 4. 商品不存在时返回 HTTP 404 ## 技术约束 - 使用 TypeScript Express参数校验使用 Zod - 数据先存内存 Map - 使用 Vitest 编写测试覆盖所有业务规则这份规格看起来不长但每个细节都在约束 AI 的行为接口路径固定了、状态码固定了、技术栈固定了、测试要求固定了。这样就避免了很多常见的“AI 自由发挥”问题。4.2 各工具产出过程记录GitHub Copilot 的产出过程是“骨架由我搭函数体它填”。我手动在项目里建好文件结构和路由入口把规格中的接口定义写成注释Copilot 根据注释把 controller 和 service 补全。测试部分它也能生成一开始对“库存不足 400”这个边界用例覆盖缺失我在注释里提示“请补充 INSUFFICIENT_STOCK 的用例”之后它补上了。整个过程大概需要 15 分钟其中有 5 分钟是在补充边界条件和修正测试用例。Cursor 的产出过程则流畅得多。我把 REQUIREMENTS.md 放进仓库在对话框里给出指令它自动创建了 routes/products.ts、services/stock.ts、tests/stock.test.ts 等文件。第一次运行测试时它把库存不足场景返回成了 500我没有干预它自己看报错、改状态码为 400重新跑了测试。整个过程 10 分钟左右除了生成文件它还会主动汇报“哪些测试通过、哪些有疑问”体验已经接近一个初级开发者在按规格推进任务。JetBrains AI Assistant 的产出过程更接近结对式。它先写路由和类型定义我再发一条消息让它补服务层再发一条消息让它补测试。每一轮都稳定没有需要回滚的大改动但总时长也拉到了 15 到 18 分钟。它的输出质量和规范性很好如果你喜欢一步步确认代码走向这种模式反而更有把握。4.3 代码质量与测试覆盖对比对比项GitHub CopilotCursorJetBrains AI Assistant能否直接运行需要小修补一次通过需要小修补是否覆盖核心业务规则需要提示补充边界自动覆盖还补了参数校验覆盖主要规则边界稍弱非法输入校验部分覆盖完整覆盖基本覆盖额外修改轮次2-3 轮1 轮左右2 轮左右是否符合规格文档中等偏高高高从结果上看Cursor 在“读规格→自动执行→自测修错”这条闭环上优势明显Copilot 需要你更主动地编写高精度注释来引导补全JetBrains AI Assistant 则适合喜欢分步确认的开发流程。4.4 我的真实体感真正让我决定把 SDD 当作标配的不是某一个工具多聪明而是当我给足规格之后三个工具都明显变靠谱了。工具之间的差距远小于给不给规格的差距。哪怕是最擅长局部补全的 Copilot只要在注释里把接口定义和状态码写清楚产出质量也会上一个台阶。这一点我觉得比纠结“该买哪个 AI 编辑器”更重要。规格写作能力正在变成 AI 编程时代最核心的差异点。5. SDD 在团队协作与面试中的延伸应用5.1 规格即文档沟通成本降一半团队里引入 SDD 后最大的变化是需求描述从口头沟通变成了“可读、可查、可评审”的规格文档。以前开需求评审会产品讲一遍、前端理解一种、后端理解另一种在代码里体现出来的差异要等联调阶段才暴露。现在所有人在动手之前先对齐规格文档前端、后端、测试都以这一份文档为准争议点当场澄清。这个习惯一旦建立新同学上手项目也方便很多。以前新人入职要翻代码、猜逻辑现在先读规格文档再对着代码看实现理解速度至少快一倍。规格文档还能沉淀下来当作模块的技术说明书减少“这个功能是谁写的、为什么这么写”的经典虚无问题。5.2 代码评审的逻辑变了传统代码评审是评审者猜实现意图为什么这个函数叫这个名字为什么这里有一个特殊判断考虑的是“代码自身是否自洽”。SDD 之后评审逻辑变成“对照规格逐条打勾”接口路径符合规格吗状态码符合吗参数校验符合吗异常处理符合吗评审变成了一种结构化的校验而不是玄学式的感觉。AI 生成的代码尤其适合这种评审方式因为你不用追问它“当时怎么想的”只要对照规格检查结果。5.3 面试中的 AI 编程考察点现在很多技术面试官会问 AI 编程相关的问题我见过太多人只准备“提示词技巧”这是方向上的偏差。真正该考察的能力是把一个模糊需求整理成可以交付给 AI 的规格文档的能力。面试时可以给候选人一个半成品需求见一下他能不能拆解出边界条件、定义出验收标准、指定技术约束再让他用 AI 实现。这一整套下来比背几个 prompt 模板更能看出真实水平。AI 编程时代稀缺的不再是写代码的手而是能用语言把逻辑“锁死”的能力。6. 常见问题与排查技巧实录6.1 规格写得太细太长AI 反而不听话规格不是越长越好。我一开始写规格喜欢事无巨细连函数命名都要规定结果 AI 在生成了几个文件之后明显忽略了文档后半部分的约束。后来调整策略把最重要、最不可妥协的业务规则放在规格文档前 30% 的位置并用关键词比如“必须”“不允许”加重表达把次重要的技术细节放到代码注释里分开引导。实践下来AI 对核心规则和代码上下文的注意力都有明显提升。6.2 上下文被截断规格被“遗忘”很多 AI 工具都受上下文窗口限制项目一大规格文档和代码互相挤占空间。我常用的解决办法有两个。一是把一个大规格拆成多个小规格一个模块一个规格文件让工具只关心当前模块的上下文。二是尽量让 AI 读取文件而不是把内容粘贴进对话比如 Cursor 可以访问项目里的 REQUIREMENTS.md其他工具也可以通过 引用文件。这样能省下大量上下文空间工具才“记得住”约束。6.3 AI 自己加戏擅自扩展功能AI 很爱自作主张加功能规格里没写的“搜索”“分页”“删除”它都能顺手给你加上。对付它最有效的办法除了在规格里明确“不需要什么”之外就是依靠代码评审。我见过有团队偷懒让 AI 生成完就直接合并结果代码里多了一堆从没要求过的页面和接口这种“加戏”代码在后期会产生大量维护成本。评审时盯住规格和最终产出的差异劝自己沉住气把多余代码删掉这是 AI 编程的日常纪律。6.4 生成的测试太弱只测“正常路径”AI 生成的测试普遍天然偏向 happy path对空值、重复、越界、并发这类边界场景覆盖不足。我的做法是在规格文档里专门加一段“测试必须覆盖的场景”列出空值输入、库存不足、商品不存在、参数非法等具体用例名称然后再让 AI 生成测试。这样生成的测试质量会显著提升。另一个经验是让 AI 使用 Given-When-Then 的结构写测试描述把“前置条件、执行动作、期望结果”显性化测试的阅读成本和维护成本都会低很多。6.5 规格也会过时需要配套变更记录规格文档不是写一次就完事。功能迭代之后规格如果没有同步更新AI 后续会基于过期规格生成错误代码。关键是不要让规格变成一个独立的、没人维护的 Markdown 文件而是把它纳入代码评审流程中代码合并时同时评审规格是否需要更新。另外建议在规格文档顶部加一个“变更记录”记录修改日期、修改人、修改原因这个习惯能避免很多“文档和代码对不上”的历史争议。我自己现在的工作流就是需求评审后先花 20 分钟把规格文档写好然后让三个工具各司其职——Copilot 处理琐碎的函数补全Cursor 一次性搭大模块JetBrains AI 做重构和代码梳理。这套组合用了半年最直观的感受是返工少了而不是打字快了。要补充的是SDD 不是银弹它解决的是“AI 生成代码方向不可控”的问题如果你的项目需求本身就很模糊那再好的方法论也救不了。先把需求想清楚再让 AI 动手这可能是我在新一轮 AI 编程实践里做得最值的一笔投入。