1. 项目概述告别“氛围编程”拥抱规范驱动的AI开发如果你和我一样在过去一年里深度使用过Cursor、Claude Code或者GitHub Copilot这类AI编程助手那你一定对“氛围编程”这个词不陌生。那种感觉就像是你和一个非常聪明但有点心不在焉的实习生结对编程你描述一个功能它噼里啪啦给你生成一堆代码乍一看挺像那么回事但仔细一瞧数据库字段命名和你现有的规范对不上或者API返回的结构里漏了几个关键字段。你指出问题它道歉、重写但下一个功能点可能又会在别的地方出岔子。几个回合下来你发现自己花在沟通、纠错和上下文修复上的时间可能比直接手写代码还要多。这就是“氛围编程”的典型困境依赖模糊的自然语言提示导致输出不可预测、决策不可追溯一旦需求变更整个对话上下文都可能被污染推倒重来的成本极高。我最初接触mariano-aguero/spec-driven-development-skill这个项目时正是被其核心主张所吸引——将规范作为唯一的真相来源。这不是一个简单的提示词合集而是一套完整的、用于AI辅助开发的工程方法学或者说是一个“元技能”。它强迫开发者和AI在动手写第一行代码之前先就“要建造什么”以及“如何建造”达成精确、可验证的共识。简单来说Spec-Driven Development Skill为你的AI编程助手无论是Cursor、Claude Code还是Copilot安装了一套“严谨模式”。它通过一系列结构化的命令如/sdd:specify/sdd:plan和预定义的模板引导你将模糊的需求转化为层层递进、相互锁定的技术工件从需求规格说明书到架构与数据模型设计再到原子化的、带有依赖关系的开发任务列表。最终你的编码工作变成了在严格规范约束下的“填空题”AI的发挥被限制在解决具体技术问题的范围内从而极大提升了输出的确定性、可维护性和团队协作效率。2. SDD核心工作流与五大阶段深度解析SDD技能将开发过程明确定义为五个顺序执行的阶段每个阶段都有明确的输入、输出和“质量门禁”。理解这个工作流是有效使用该技能的基础。下面我将结合一个具体的案例——为一个小型博客系统“添加文章评论功能”——来拆解每个阶段。2.1 阶段零澄清与界定这是很多开发者容易忽略但SDD特别强调的“第零阶段”。它的核心目标是在编写正式规范之前消除所有歧义。当你有一个初步想法时不要直接跳到/sdd:specify。正确操作是先与AI进行一次开放式的“澄清对话”。例如你可以对AI说“我们计划为博客系统添加评论功能。在开始撰写正式规格说明之前请列出你对这个功能的所有隐含假设包括但不限于用户角色游客可读登录后可写、评论的层级结构是否支持回复、审核机制是否需要后台审核、垃圾信息防范策略、以及它与其他模块如用户系统、文章发布的关联。”AI可能会反馈一系列假设比如“假设1评论功能面向已登录用户。假设2评论支持两级回复即对评论的回复。假设3新评论默认需要管理员审核后才公开显示。假设4评论会关联到具体的文章和用户。” 这时你就能立即发现并纠正那些不符合你预期的假设。比如你可能希望支持无限级嵌套回复或者希望评论无需审核直接发布但包含举报功能。在这个阶段修正假设成本几乎为零。如果等到规格说明书都写完了再发现可能就需要重头再来。实操心得我习惯将这个阶段的输出保存为一个名为research.md的文件。它不算是SDD的正式产出物但却是后续所有工作的基石。这个文件记录了最初的讨论、被否决的方案和达成共识的核心边界条件对于后续回溯决策原因至关重要。2.2 阶段一制定规格说明书这是SDD的基石。使用命令/sdd:specify “添加文章评论功能”技能会引导AI在specs/blog-comments/目录下生成一个spec.md文件。这个文件不是一篇散文而是一份结构严谨的技术合同。一份合格的spec.md应包含目标简洁陈述要解决的问题或实现的价值。范围与边界明确说明功能包含什么、不包含什么。例如“本规格包含前端评论组件、后端RESTful API、数据库表设计但不包含评论的通知推送如邮件和高级反垃圾算法”。用户故事与验收标准这是核心。每个AC必须是独立可测试的。糟糕的AC“用户可以发表评论”。良好的AC“作为一名已登录用户当我在文章详情页的评论框内输入不少于2个字符且不超过1000个字符的文本并点击‘提交’按钮后系统应将该评论保存至数据库并立即在当前页面评论列表顶部显示同时清空评论框。前端应对提交按钮添加防重复点击处理。”非功能性需求如性能列表加载时间500ms、安全性防止XSS注入等。注意事项SDD引入了MoSCoW优先级分类法Must have, Should have, Could have, Won‘t have要求为每个AC标记优先级。这能帮助你在后续开发或时间紧张时清晰地做出取舍。例如“评论支持Markdown格式”可能被标记为[COULD]而“评论内容必须持久化存储”则是[MUST]。2.3 阶段二制定实施方案有了“做什么”的合同接下来是规划“怎么做”。执行/sdd:planAI会基于spec.md在同一个目录下生成一系列设计文档plan.md高层架构设计。例如采用REST API还是GraphQL评论服务是独立微服务还是集成在文章服务内这里会识别技术风险比如“无限级嵌套评论的查询性能风险”。>{ postId: 123e4567-e89b-12d3-a456-426614174000, content: 这是一条测试评论。, parentId: null // 用于回复顶级评论为null }响应成功示例{ id: 456f7890-f12c-34d5-b678-527725285111, postId: 123e4567-e89b-12d3-a456-426614174000, author: { id: user-1, name: 张三 }, content: 这是一条测试评论。, createdAt: 2023-10-27T08:30:00Z, updatedAt: 2023-10-27T08:30:00Z }错误响应示例必须定义所有可能的错误状态如400请求体无效、401未授权、404文章不存在、429评论频率超限。安全要求如“必须验证用户身份令牌”、“请求体需进行XSS过滤”。实操心得在实现阶段阶段四我会将这份契约文件的内容直接粘贴到AI会话的上下文窗口最顶部并强调“以下API契约是必须严格遵守的任何偏离都是不可接受的。” 这能极其有效地约束AI的输出确保生成的控制器、DTO数据传输对象、序列化逻辑与设计完全一致。3.3 数据模型与迁移策略>