用 AI 编码工具时，你让它加个功能或修个 bug，结果常常不是你想要的，只好反复改提示词。于是很多团队开始强调“先写规范”，也就是最近流行的规范驱动开发（Spec-Driven Development）。但不少开发者会问：这不就是老掉牙的瀑布模型吗？IBM Technology 的这期视频专门回答了这个问题。
瀑布模型的问题在哪
瀑布（Waterfall）是逐步推进的流程：需求、设计、构建、测试、部署，上一步做完才开始下一步。规范放在最顶端，而且在写任何代码之前就全部写完。问题有三个：阶段之间有交接；需求写错了，要“爬楼梯”回头修改，代价很高；验证发生得很晚，等到部署时，最初的规范多半已经过时，也没人回去更新。这正是行业后来转向短周期、用户故事和敏捷（Agile）的原因。
规范驱动开发：一个短循环
讲者的观点是：如果把整份规范一次写完、冻结，再交给智能体去做，那确实就是瀑布，只是“失败得更快”。真正的规范驱动开发是一个循环：
- 从规范出发，让智能体构建；
- 验证结果；
- 学到新东西或遇到边界情况，就修改规范；
- 再继续下一轮。
循环很短，一个功能只需几小时或几天，而不是整个项目几个月。视频里的例子是“密码重置”：规范只有三行（发送重置链接、15 分钟过期、只能使用一次）。跑一轮后发现链接其实没过期，又发现没说清楚用户请求两次链接怎么办，于是补一行“只使用最新链接”，再走一遍。规范是 Markdown 之类的文件，和代码一起放在仓库里做版本控制，所以不会像瀑布那样过时。讲者还打了个比方：先写一个失败的测试，那个测试就是一个小规范。
为什么 AI 让规范更值钱
- 上下文：和同事合作可以随时提问，而 AI 智能体遇到不清楚的信息会猜测或假设。好的规范把要做什么、项目约束、怎样算可用都交给它。
- 歧义：每个含糊的需求都会变成额外的提示和迭代，花钱也花时间。规范越清晰，循环次数越少。智能体也可以帮你起草和更新规范。
- 安全与合规：可以把“每个接口都要认证、日志里不存用户个人数据、不要硬编码密钥”写进规范，而不是等到瀑布式的测试阶段才发现，那时已经太晚。
当然，不必事事写规范：小的 bug 修复不需要，涉及多个服务的大功能或系统现代化改造才特别适合。
术语表
- Spec-Driven Development（规范驱动开发）：先写规范，让智能体构建，再验证并持续修订规范的短循环方法。
- Waterfall（瀑布模型）：需求、设计、构建、测试、部署依次进行，上一步完成才开始下一步。
- Specification（规范）：描述要构建什么、有哪些约束、如何验证可用的文档。
- Agile（敏捷）：用短周期和用户故事取代大型前置需求的开发方式。
- Context（上下文）：智能体否则只能猜测的项目信息。
自测一题
讲者认为，什么情况下规范驱动开发会变成“瀑布”？
A. 规范写在 Markdown 里 B. 一次写完整份规范、冻结后交给智能体 C. 循环只持续几小时 D. 规范与代码一起做版本控制
答案：B。
和求职、面试的关系
现在的面试越来越常问“你怎么用 AI 辅助开发”。能讲清楚规范驱动开发与瀑布、敏捷的区别，说出“短循环、规范随代码版本化、规范承载上下文与安全要求”这几点，会让你的回答更有条理。被问到“AI 生成的代码不符合预期怎么办”时，也可以回答：先检查规范是否有歧义，而不是只改提示词。
来源
本文是我对 IBM Technology 视频的学习笔记，内容为自己的理解和改写。原视频：Spec-Driven Development vs. Waterfall: What's Different for AI Coding?（IBM Technology）。课程页（含完整讲解与更多题目）：规范驱动开发 vs 瀑布模型。
没有评论:
发表评论