资源介绍
视频数量：27个
总时长：1小时49分
课程介绍：
AI辅助的规范驱动开发实战
你有没有过这样的经历：兴致勃勃地打开AI编程助手，输入一段提示词，满心期待它给你写出一个完美的功能，结果代码跑出来一看，跟你脑子里想的完全不是一回事。于是你开始反复修改提示词，一次不行两次，两次不行三次，来来回回拉扯半天，最后还是觉得哪里不对劲。这大概是当下很多开发者用AI写代码时的真实写照。
问题出在哪里？出在我们给AI的那段简短提示词里，承载的信息量远远不够。AI只能靠猜，猜你想要什么样的数据结构，猜你想要什么样的业务逻辑，猜你想要什么样的错误处理。猜得多了，偏差自然就大了。
这门课程要讲的规范驱动开发，恰恰就是来解决这个问题的。核心思路其实不复杂：先别急着写代码，先把要写的东西用文档说清楚。需求文档描述业务目标，技术设计文档描述架构方案，任务清单把工作拆成小块——这些东西全写明白了，再让AI去生成代码，准确度会高出一个量级。整个课程用大约两个小时的时间，带你把这个工作流从头到尾走一遍。
一、为什么需要规范驱动开发：
课程一开始并没有急着上手工具，而是花了几节课帮你建立认知。先介绍课程的整体脉络和配套资源，然后聊聊当下创建软件的不同方式。有一个绕不开的概念叫做"氛围编程"，说白了就是凭感觉跟AI对话，靠不断试错来逼近目标。这种方式在写个一次性的小脚本时可能还行，但在正经项目里，它的弊端很快就会暴露出来——需求稍微变一下，之前辛辛苦苦调好的代码可能就得推倒重来。
课程里专门有一节讲"如果我们需求变了怎么办"，用具体的场景演示了两种工作流在面对变更时的不同表现。你会看到，没有规范支撑的项目，改一个字段可能牵出十几个文件的连锁修改；而有了规范文档作为参照，改动变得有据可依，影响范围一目了然。这种对比很直观，能帮你真正理解为什么值得在写代码之前多花一些时间做规划。
二、理解API契约的基础知识：
在动手实践之前，课程花了一个章节帮你补上API契约相关的背景知识。不管是REST API还是GraphQL，它们本质上都一种"约定"——告诉前端、后端、测试、文档生成工具，大家都按照同一个标准来沟通。
REST API那一节会讲它的核心约束和常见的设计模式，比如资源路径怎么命名、HTTP动词怎么选用、状态码怎么返回。GraphQL那一节则介绍它的查询语言机制，让你明白客户端如何精确地获取自己需要的数据。API契约那一节把前两者的共同点提炼出来，讲清楚一份好的契约文档应该包含哪些要素——路径、参数、请求体、响应体、错误码，这些都是构成契约的基石。理解了这部分内容，后面用AI生成OpenAPI文档的时候，你才知道该提哪些要求、该检查哪些地方。
三、三种主流工具的特点与选择：
课程介绍了三种目前比较流行的规范驱动开发工具，它们各有特色，适合不同的使用场景。
Kiro是亚马逊推出的一款集成开发环境，它把规范驱动开发的理念直接内嵌到了IDE里。你在里面创建项目时，它会自动生成需求文档、技术设计文档和任务列表的结构，你只需要在这些模板里填写内容，它就能驱动AI去生成对应的代码。好处是整个工作流非常顺畅，不用在多个工具之间来回切换。
GitHub Spec Kit走的是另一条路线，它是一个开源的命令行工具，最大的优势是不绑定任何特定的开发环境。不管你用的是VS Code搭配Cloud Code，还是JetBrains搭配Copilot，甚至是命令行里的Gemini CLI，它都支持。它的工作流分成四个阶段：明确需求、制定计划、分解任务、实现。每个阶段通过斜杠命令来触发，生成的Markdown文件会在下一步中被读取和使用。这种设计的好处是灵活，你可以把它接入到任何你觉得顺手的开发环境里。
BMAD方法的思路又不一样，它不是让一个AI代理干所有事情，而是组建了一个"虚拟团队"，每个代理负责一个专业环节。有专门做需求分析的代理，有做架构设计的代理，有做任务拆解的代理，它们接力协作，完成整个工作流。这种方式适合那些对代码质量要求比较高的复杂项目。
四、动手实战：从规范到部署的完整流程：
理论铺垫够厚了，课程接下来用一个大章节带你从头到尾做一个真实的项目。用户管理API，一个标准的增删改查服务，涉及创建用户、查询用户、更新用户、删除用户四个接口。
第一步是用AI生成OpenAPI文档。你会学到怎么写提示词才能让AI产出一份结构完整、字段准确、符合规范的API契约文档。课程附带了一份PDF文件，里面记录了完整的提示词，你可以直接拿来用或者在此基础上修改。
第二步是用Spectral对生成的OpenAPI文档做静态检查。Spectral是一款开源的lint工具，它会根据你定义的规则集检查文档中是否存在命名不规范、必填字段缺失、类型声明错误等问题。你会看到工具标出几十条警告，然后跟着课程逐一解决这些问题。这个过程很重要，因为契约文档的准确性直接决定了后续所有工作的质量。
第三步是在写任何代码之前，先把API跑起来。这里用到的是契约驱动的Mock服务器，它会读取OpenAPI文档自动生成可调用的接口。你可以用curl命令去创建用户、查询用户，看到接口返回正确的数据格式，这时候你心里就有底了——契约设计是可行的。
第四步是创建需求文档。需求文档不是简单地把用户口头说的话记下来，而是要明确写出功能的业务目标、用户场景、验收标准、用例描述。课程里会演示怎么借助AI从OpenAPI文档出发，扩展成一份完整的需求规格说明书。
第五步是创建技术设计文档。这份文档描述的是技术层面的决策——用什么编程语言、什么框架、什么数据库、什么部署平台。课程中的示例项目用的是Java和AWS Lambda的无服务器架构，数据存储用Cognito，部署工具用AWS SAM。你会看到技术设计文档里包含了完整的架构说明、模块划分、接口定义、数据模型、异常处理策略。
第六步是把任务清单拆出来。任务清单是连接规划和执行之间的桥梁，它把大的功能目标拆成一个个可执行的小任务，每个任务都有明确的输入、输出和验收条件。这种拆分让AI在执行的时候不会跑偏，也让你在检查进度的时候有清晰的节点。
第七步是执行任务清单。AI会按照任务列表一项一项地生成代码，每完成一项你都可以检查、确认、调整。课程里演示了这个逐步推进的过程，让你看到从规范文档到可运行代码的转化是怎么发生的。
第八步是部署到AWS并验证。课程教你用AWS SAM把生成的代码打包、部署到Lambda上，然后实际去调用部署好的接口，看看它能不能正常工作。这一步是验证整个工作流是否跑通的关键节点。
五、规范驱动的测试与微服务：
课程最后两个章节把规范驱动开发的理念延伸到了测试和微服务领域。
在测试那一节，你会学到OpenAPI文档可以作为测试用例自动生成的源头。既然契约已经定义了接口的路径、参数、响应格式，那么测试用例完全可以由契约自动推导出来，省去手动编写测试用例的繁琐。课程演示了这个自动化的过程。
在微服务那一节，重点讨论的是多个服务之间如何通过契约来正确通信。当你的系统由十几个微服务组成时，服务之间的调用关系会变得非常复杂。如果每个服务都有自己的接口定义，但彼此之间没有对齐，联调的时候就会出现各种莫名其妙的错误。课程展示了一种做法：先画清楚服务之间的调用关系图，标注每个调用点的契约要求，然后让各个团队按照统一的契约来开发自己的服务。这种自上而下的契约管理方式，能从源头避免很多集成问题。
六、适合谁学，怎么学：
这门课特别适合那些已经在用AI编程助手但觉得效果不够理想的开发者。如果你经常觉得AI生成的代码需要大改特改，如果你对"氛围编程"的工作方式感到疲惫，如果你想知道有没有更系统化的方法来用AI辅助开发，那这门课就是给你准备的。
从技术背景来看，最好有一定的编程基础，了解REST API的基本概念，对Java或类似的后端语言有基本了解。课程用Java做示例，但核心的规范驱动开发思想并不局限于某一种语言，你完全可以把同样的思路套用到Python、JavaScript、Go等其他语言的项目中。
工具的选择方面，课程提供了三种方案，你可以根据自己的习惯挑一个用。如果你是AWS生态的重度用户，Kiro会很顺手；如果你追求工具链的灵活性，GitHub Spec Kit是个好选择；如果你要做的是大型复杂项目，BMAD的多代理协作模式值得尝试。
学完这门课，你带走的不只是一套具体的工具操作步骤，更是一套思维方式：先想清楚再动手，先定义清楚再生成代码。这套思维方式在AI辅助开发的时代里，会变得越来越重要。