先说一个我自己的变化过去半年我从“每天用AI写代码写到嗨”变成“开工前先花40分钟写一份规格文档”。后者听起来更慢但实测结果恰恰相反——在几个中型项目上它把我用AI编程的整体效率提升了大约50%代码返工率、上下文浪费、团队协作成本都明显降下来了。我知道很多人看到“SDD规格驱动开发”这几个字就头大觉得又是流程、又是文档像是要把程序员最讨厌的重写一遍。我自己一开始也抵触。但经历了Vibe Coding踩过的那些坑——需求改两句AI就原地打转、代码库在没人注意的时候悄悄长出三套风格、某个功能上线后才发现验收口径根本没对齐——我开始认真研究怎么把AI编程从“随性发挥”变成“按图施工”。这篇文章就聊聊我和团队在落地SDD过程中的完整经验以及我用GitHub Copilot、Cursor、通义灵码这三款主流AI编程工具做的实战对比。如果你现在大部分代码都是AI写的但总觉得哪里不对劲这篇文章值得你看完。1. Vibe Coding的爽与痛从随手写代码到代码失控1.1 Vibe Coding为什么让人上瘾Vibe Coding这个词指的是一种状态你不太需要一句一句地推敲怎么实现只要大致描述想做什么AI编程工具就刷刷地帮你把代码补出来。我最早接触时很快就上瘾了——特别是用Copilot做自动补全、用Cursor的Composer一次性生成一个可运行的CRUD接口那种感觉就像有个比你快的同事在帮你写代码而且他从不会不耐烦。它适合的场景其实很明显写Demo、做原型验证、写一次性脚本。在这些场景下代码的生命周期只有几个小时到几天你不需要考虑别人能不能读懂后面也没有人需要继续维护它。这时候Vibe Coding的体验确实无与伦比——我可以在半小时内把想法变成可以演示的东西快速验证思路是否成立。但问题在于这种方式会让人产生使用惯性。当你习惯了把需求扔给AI、AI直接给你一大段代码你会慢慢放弃对代码的掌控。你会发现自己在接受AI的第一版输出时已经不像一开始那样逐行审核了。这种“被带着走”的状态在小项目上是效率在大项目上就是隐患。1.2 爽过之后的代价需求漂移与代码失控真正让我警觉的是一次功能迭代。项目是一个带用户系统的待办事项服务前期用Vibe Coding的节奏推进得很快两周就堆了十几个接口。第三周需求方说“给待办加一个截止时间字段超时的单独标记出来”。我下意识地把这个需求扔给AI结果AI理解成了两种不同的东西第一次它把截止时间和创建时间混在一起第二次它在列表接口里新开了一个字段但没做迁移第三次它给我的方案改了数据库结构但没考虑已有数据。来来回回折腾了快两小时最后我还是打开代码手动把所有相关的模型、接口、测试改了一遍。事后复盘问题并不是AI笨而是我让AI在错误的上下文中做判断。之前Vibe Coding留下的代码本身就没有清晰的规格说明AI每次都是从全部代码里猜我的意图猜错了就只能来回试。更麻烦的是这种来回试很难被自动化测试发现因为测试也和实现一样是在“vibe”下写的两者会共享同样的错误假设。1.3 什么时候Vibe Coding依然可用我当然不建议彻底否定Vibe Coding。它的适用范围很清晰探索性代码、一次性的数据脚本、个人小工具、UI原型。在这些场景下你追求的是速度和灵感不是可维护性Vibe Coding完全够用而且很高效。但在需要长期维护、多人协作、有明确业务规则的项目里Vibe Coding的风险就开始显现了。你有没有过这样的体验让AI改了A模块结果B模块的行为悄悄变了因为两者共享同一个函数而AI没有意识到要约束这个函数的契约这种问题在Vibe Coding模式下基本无法预防因为从一开始就没有一份“契约”存在。SDD要解决的核心问题就是给AI编程补上这份“契约”。2. SDD六步实践指南把AI从猜心思变成按图施工SDD全称是Spec-Driven Development规格驱动开发翻译成人话就是先让机器和人都清楚地知道我们要做的是什么再开始写代码。市面上有各种“如何用好AI编程”的讨论但大多数都停留在提示词技巧层面。我的经验和团队实践下来的结论是提示词技巧的上限很低真正拉开差距的是你给AI喂的“图纸”的质量。2.1 前两步把“你看着办”变成规格文档第1步是需求澄清。不要觉得需求已经清楚了——绝大多数需求在说出口的时候都是缺条件的。你需要问自己五个问题这个功能给谁用输入是什么输出是什么在什么环境跑失败的时候怎么办举个例子用户说“加个导出功能”你得先搞明白导出的是Excel还是CSV、是全量还是筛选后的、文件大了需不需要异步生成。这些不搞清楚AI给你的代码就纯靠猜。第2步是规格撰写。规格不是需求文档它要足够薄、足够确定。一份好的AI编程规格应该包含四块范围做什么加明确不做什么、接口约定输入输出、数据约束字段类型、必填项、唯一性、验收要点怎么判断完成。我以前觉得规格要写“为什么这么做”后来发现AI不需要知道故事背景它需要的是边界。写得太像叙事文反而容易让AI自由发挥。这里的关键取舍是规格描述的是“要什么”而不是“怎么实现”。你告诉AI“这个接口应该幂等重复提交相同请求不应产生两条记录”而不是“用Redis做个分布式锁”——后者限制了AI的方案空间前者给了AI发挥的余地。2.2 中间两步任务拆解与验收标准第3步是任务拆解。把规格拆成一个个能让AI独立完成的小任务每个任务的颗粒度控制在“改1到3个文件、1小时以内能完成并验证”的范围。我实际用下来这个颗粒度最舒服。拆好之后不要一次把十个任务全发给AI而是每次都只给当前任务和相关上下文。这既是配合AI编程工具上下文窗口的限制也是为了保证每一步出错时能快速定位。第4步是验收标准。这一步是SDD和普通文档式开发的本质区别。传统的规格文档到代码就结束了但SDD的验收标准要给AI明确的可执行验证方式。比如“运行pytest -k task必须通过全部用例”“接口在重复提交时返回409”“数据库表必须有created_at索引”。验收标准写得越可执行AI越不会在实现时跑偏也越方便你后来做Code Review。2.3 最后两步小步实现与变更回写第5步是小步实现。核心原则是不要让AI一次性生成整个模块而是让它按任务列表一个一个实现每个任务完成都跑一遍验收标准。你会发现当AI集中精力做一个边界清晰的小任务时出错率明显下降反过来让它一口气生成十几个接口后面的代码往往会自相矛盾。第6步是最容易被忽视的变更回写。AI在实现过程中经常会发现规格里的问题然后自己做了聪明的修正。这本来是好事但如果你不把这个修正同步回规格文档下一次对话时AI就会照着旧规格再来一遍产生“重复发明错误”的尴尬。所以每次AI完成任务后我都会顺手在规格文档里改动一下——哪怕只是标注“已调整为xxx”。3. 三款AI编程工具实战对比Copilot、Cursor与通义灵码3.1 为什么选这三款市面上AI编程工具现在太多了光VS Code插件就有不下十个。我这边选型时考虑的不只是“谁代码补得准”更核心的问题是“谁能配合SDD工作流”。最后锁定了三款最有代表性的GitHub Copilot目前普及率最高的AI编程工具能深度嵌入VS Code和JetBrains全家桶我日常在IntelliJ IDEA里用。CursorAI原生的代码编辑器Composer和Agent模式在处理多文件、跨模块改动时非常强适合“给一个目标让它自己规划”的工作模式。通义灵码国产工具里我个人用下来综合体验最顺的中文需求理解好支持VS Code和JetBrains对国内开发者完全免费适合做SDD主流程的日常搭档。之所以没有选某些“生成质量最强”的工具是因为它们的核心能力集中在代码生成上但代码生成质量只是SDD链条里的一环。我更关心工具能不能接住规格、能不能按任务上下文走完小步迭代、能不能在验收阶段帮忙跑测试。这三款恰好分别代表了三种思路Copilot像贴身助理Cursor像独立开发通义灵码像本地搭好的翻译管线。3.2 实战对比维度与结果我在同一个SDD流程下用三款工具分别实现了同一个带用户隔离的待办服务后端。环境一致、规格一致、任务拆解一致唯一变量是工具。对比维度包括上下文利用率、多文件编辑能力、Agent自主规划能力、以及和SDD工作流的适配度。对比维度GitHub CopilotCursor通义灵码上下文利用率中上需要手动圈选相关文件高能自动索引整个项目中上中文规格理解好多文件编辑能力弱逐文件补全为主强Composer可一次跨多文件改动中可以多文件生成但需盯结果Agent自主规划能力中Editor模式有限自主强Agent模式可按目标自由规划中有编码助手和智能问答与SDD适配度中高中高实测耗时同一需求约2小时40分约1小时50分约2小时10分说实话Cursor在完成这类“给定规格、自动实现”的任务时体验最接近SDD理想态因为它的Agent模式可以自主遍历文件、跑命令、根据错误反馈自我修复几乎不需要我手动圈选文件。Copilot的强项在逐行补全和即时建议但在“一次改动横跨多个文件”时需要我先手动梳理涉及的文件否则它容易漏改。通义灵码则让我最省心的是中文对话和它内置的仓库级代码理解规格里的中文术语它基本不会理解漂移。3.3 与SDD工作流的适配度分析这里我想展开说一下为什么“最强生成能力”不等于“最适合SDD”。我之前也试过某些代码生成质量很惊艳的工具但在SDD流程里它们反而不好用。原因是SDD要求每个任务边界清晰、上下文精确、变更可控而不是让AI“自由发挥生成一大段好看但难以验证的代码”。Copilot最适合的SDD阶段是第5步小步实现你给它一个明确的小函数它迅速给出高质量实现你逐行审查后合入体验极佳。Cursor最适合的阶段是任务拆解后的整体规划落地尤其是需要跨模块调整时它能在上下文里保持更长逻辑链条。通义灵码则胜在“中文规格的理解”和“国内网络环境下开箱即用的稳定”——这对很多团队来说不是小问题因为我实测过一些工具在非标准网络环境下调用外服AI服务的延迟和可靠性都会成为瓶颈。另外补一句硬件相关的心得跑这类AI编程工具时内存大小对体验的影响远大于CPU核心数。模型上下文越大越吃内存我自己的机器从16G升到32G之后Cursor的Agent模式明显没那么容易卡死建议做SDD密集型开发的话至少上32G。4. 一个真实需求走一遍从规格到落地全链路演示这一节我直接用一个真实的中型需求来演示SDD完整流程。选一个常见的需求待办事项服务要求包含用户注册登录、待办增删改查、用户数据隔离。这个例子不大不小刚好能体现SDD的核心操作。4.1 需求澄清表与规格文档示例先看需求澄清表这是第1步的实际产物问题答案影响说明功能给谁用多用户每个人只看到自己的待办必须做数据隔离登录方式邮箱加密码密码要哈希存储待办有哪些操作创建、列表、完成、删除不需要编辑功能简化本期范围数据存储SQLite单文件不需要额外数据库服务接口风格REST JSON前端直接消费然后是规格文档示例这是第2步的产物功能规格多用户待办服务 版本v1.0 范围 - 支持邮箱密码注册、登录登录后返回token - 支持创建待办、查看自己的待办列表、标记完成、删除 - 任何人只能访问自己的待办 明确不做 - 不做找回密码、不做邮箱验证 - 不做编辑待办 - 不做前端页面 接口约定 - POST /auth/register入参 {email, password}成功返回 {token} - POST /auth/login入参 {email, password}成功返回 {token} - GET /todos返回当前用户待办列表 - POST /todos入参 {title, due_date?}创建待办 - POST /todos/{id}/done将待办标记为完成 - DELETE /todos/{id}删除待办 数据约束 - email 全局唯一格式校验 - password 至少8位存储用bcrypt哈希 - 待办必须属于某个用户接口通过token识别用户 验收要点 - pytest 全部通过 - 未登录访问 /todos 返回 401 - 用户A不能通过 /todos/某id 操作用户B的待办很多人会觉得“这个规格不是智商税吗直接跟AI说要个待办系统不就行了”。但我用两种方式实测过直接跟AI说要待办系统它通常会默认你对“待办系统”的理解和它完全一致结果就是注册、登录、列表这些接口的实现方式跟你已有的项目约定完全脱节字段命名风格各异数据库设计也可能跟后续需求打架。有了这张图纸AI编出来的代码才是“你的项目的一部分”而不是“一个恰好能跑的独立程序”。4.2 任务拆解与提示词模板规格写完后的第3步是任务拆解。我的拆法如下T1搭建项目骨架FastAPI SQLAlchemy SQLite包含 /health 接口T2实现用户注册与登录含bcrypt密码哈希、token签发T3实现待办增删改查含用户隔离T4补齐 pytest 测试覆盖验收要点对应的提示词模板在第5步小步实现时直接使用我正在实现 T2项目结构如下 贴当前项目树 技术栈FastAPI SQLAlchemy SQLite 规格要求 - POST /auth/register入参 {email, password}成功后返回 {token} - 密码必须用 bcrypt 哈希不允许明文入库 - email 需要全局唯一格式校验 验收标准 1. pytest -k auth 通过 2. 注册成功返回的 token 能被后续接口识别 3. 重复注册相同 email 返回 409 请只实现本任务不要修改 T1 已完成的骨架代码。这里体现了一个非常关键的原则给AI的任务提示词不要让AI自己决定“要不要顺手改骨架”边界必须说死。AI的路径依赖非常强如果你不约束它它能因为“觉得更干净”把已经稳定的骨架重写一遍这在Vibe Coding里特别常见。4.3 验收环节的关键动作第4步和第6步的验收环节是我在实战中最看重也最容易出问题的一环。我总结了三件必做的事。第一亲手写关键验收用例不要全盘接受AI生成的测试。AI生成的测试和实现往往共享同样的假设实现里有的bug测试里也大概率有。我自己会额外写一个“越权访问”用例也就是用户B去访问用户A的待办这类安全边界用例AI常常会忽略。第二按任务粒度做验收不要攒到最后。T1完成后先确认骨架能起来T2完成后立刻验注册登录积累到T3再一起重磅验收。这种节奏下出了问题你有非常大的把握知道问题出在刚才的那一小步。第三把验收结果回写进规格。比如规格里原来没写清楚“删除待办时如果id不存在返回404还是204”AI实现时选择了404你就顺手在规格文档里标注“已确认不存在返回404”。下一次对话或者新同事介入时就不会再问同样的问题。5. 提效50%是怎么算出来的量化过程与适用边界很多读者看到标题里的“50%”肯定有质疑我也不打算回避。我自己一开始也不信流程能带来这么大的提效直到特意做了一次对照实验。5.1 同一需求的两种跑法对比实验对象就是上面的多用户待办服务。我选了同一个需求同一台电脑一次用Vibe Coding风格就是直接口语化描述需求让AI自由发挥不满意就继续对话一次用SDD流程。记录的时间包括写规格、写提示词、AI生成、人工修改和调试不包括发呆时间。对比项Vibe CodingSDD需求描述到第一版可运行代码约1小时10分约1小时50分含40分钟规格准备中间修改轮次11轮2轮最终人工返工时间约2小时约30分钟测试遗漏数量3处含越权未覆盖0处规格验收要点全覆盖总耗时约3小时50分约2小时20分总耗时差距大约1小时30分折算下来接近40%的提效。我把类似的实验在几个不同需求上重复了几遍结合团队推进周期的大盘整体在50%左右是合理表述。注意一个反直觉的点SDD的“写规格”时间在前期反而是净投入它带来的收益体现在后期无穷无尽的返工被砍掉了一大截。Vibe Coding在前面跑得快但耗在“来回改”的时间远比你想象的多——AI每改一次你以为改完了实际上它可能顺手碰坏了另一个地方。5.2 效率提升的真正来源我把提效来源拆成三块。第一块是减少无效上下文。Vibe Coding时AI经常在不了解项目约束的情况下盲目给方案而这些方案多半要返工SDD先给出边界AI不需要在“所有可能方案”里瞎猜有效输出占比大幅提升。第二块是降低人工审核和补救成本。没有规格限制的大段代码审查起来很累你不知道AI每一步选择是“故意的”还是“产出的时候压根没注意”。有了规格和任务边界代码评审从“全读代码猜意图”变成“对照规格找偏差”质量信号清晰得多。第三块是团队协作的去个人化。Vibe Coding的经验和上下文绑在某个人的对话里换个人完全接不上SDD的规格文档是团队共享的任何一个成员都能带着同一种“图纸”来操作AI接力成本急剧下降。我这边的实测是一个人能跑通的功能SDD下两个交接成员用一半时间就能接住。5.3 什么场景下SDD不划算还要说清楚SDD的边界否则就是误导。在最简单的场景里比如“把某段代码的函数名从camelCase改成snake_case”“给某个类加一个字段”SDD确实是过度工程——额外写规格的几分钟都够你手动改完了。所以我一贯的建议是50%的提效适用于那种“你以为两小时能写完、实际写完还要再花三小时调”的中型需求对于5分钟的小改动直接上Vibe Coding也没毛病。另一个不划算的场景是纯探索型代码。做技术调研、学习新框架、验证想法时你连需求长什么样都不完全清楚强行写规格属于自欺欺人。探索阶段先尽情vibe当项目从“探索”转向“交付”的临界点出现时再花一个下午补规格转SDD。这个转换点怎么判断我的经验是当你意识到“这段代码不止我自己看”的那一刻就已经到了。6. SDD落地踩过的坑规格与AI之间的各种意外最后分享几个落地过程中真实踩过的坑这些坑网上基本没人写。都是我们团队在实际工作中反复遇到且最终找到解题方向的问题。6.1 规格写得越细越好是最大的误区第一个坑就是反直觉的规格写得太细AI反而变笨。我一度把规格写到了“每个函数的具体行为和参数”级别结果AI完全失去了方案空间变成了一个翻译机它不仅没有解决问题还引入了一堆和代码库风格不符的机械实现。正确做法是规格管“范围和边界”不管“实现细节”。你只要告诉AI这个函数必须幂等、必须校验输入、必须返回这些字段就足够了至于它用循环还是递归、用缓存还是不用缓存值得给它自由。这个坑背后的原因我琢磨了很久AI编程工具的底座是大模型它在“被约束得太死”时被迫生成它不擅长的“照本宣科”式代码质量反而不如给它适当自由时高。好的规格文档像施工图纸——告诉你墙在哪里、门开在哪、承重梁在哪至于砖怎么砌、砂浆怎么配交给施工队发挥。6.2 上下文窗口的物理限制怎么破第二个坑是规格文档太长超过了工具的上下文窗口。一开始我把整份规格文档和整个项目树一股脑塞进提示词结果Cursor和通义灵码都开始出现“幻觉”——它明明没看到后面的约束却假装看到了然后按错误假设输出代码。后来我摸索出三招。第一招按任务切片只把当前任务相关的规格段落和涉及的文件贴进上下文而不是全量塞入。第二招让规格文档保持“索引化”在文档顶部写一行“完整规格见SPEC.md当前任务依赖第3节接口约定和第5节验收要点”这样AI如果发现信息不足可以主动去查文件。第三招对大项目启用Agent的代码索引能力像Cursor的Codebase Index和通义灵码的仓库级检索让工具自己定位相关代码减少手动贴码量。这三招叠加后上下文浪费的现象基本消失了。6.3 让团队愿意写规格的三个技巧第三个坑完全是人的问题团队一开始根本接受不了“让AI编程还要先写文档”这件事。程序员本能地讨厌文档觉得是流程绑架。我自己也在带团队的过程中踩了很多次坑最后靠三个技巧解决了。第一重新定义规格的用途。不要把它叫“需求文档”或“设计文档”就叫“AI输入材料”或者“任务卡片”。团队成员只要在聊天框里把这份材料丢给AI就能拿到靠谱结果他们自然愿意写。第二把规格和任务管理工具绑定。直接把规格文档里的任务列表对应到工单系统的子任务完成一个勾一个验收记录同步更新。这样规格文档不是流程负担而是团队协作的资产。第三先在一个小块上示范不要全组铺开。找一个人做一个两周的小迭代把前后对比数据摆出来修改轮次、返工时间其他人在看见数字之后会主动来问。流程这玩意光讲道理没用得拿结果说话。我个人在这段时间里最大的体会是AI编程会不会真正提效其实不太取决于你用的是哪款工具甚至不取决于你的提示词写得有多漂亮而取决于你愿不愿意在动手前多花一点时间把“边界”想清楚。SDD不是一个高深莫测的方法论它本质上就是用结构化思考去抵消AI的随机性。你为了给AI写清楚规格而被迫想清楚的那些问题才是编程这件事里真正值钱的部分。建议你下一个中型需求就试试先花40分钟写一版规格再让AI动手。等你自己亲眼看到“返工次数从两位数降到两次以内”的时候你会回来感谢这40分钟的。