考察点
SDD 是 2025 下半年到 2026 年 AI 编程方向的热门概念题（GitHub Spec Kit、AWS Kiro 带起来的），面试官想看你有没有跟上方法论的演进，以及能否讲清「为什么偏偏是 AI 时代需要它」。深层考察点：你理解 AI 编程的核心矛盾是意图传递，不是生成速度。追问常往「spec 写成什么样才算合格」「和传统详细设计文档有什么区别」走。
参考答案
定义：spec 是一等公民
规范驱动开发（Spec-Driven Development）的核心主张是：规约不再是代码的附属文档，而是开发活动的起点和事实来源，代码是 spec 的产物。典型流程是四段式：specify——用自然语言写清要做什么、验收标准是什么；plan——生成技术方案，选型、结构、接口契约；tasks——把方案拆成有序、可独立执行的任务列表；implement——逐任务生成代码。GitHub 的 Spec Kit 工具链就是按这四段设计的，AWS 的 Kiro 也内置了需求、设计、任务三件套，还把需求写成了 EARS 句式这种结构化格式。
为什么 AI 时代才火
spec 先行不是什么新思想，瀑布时代就有详细设计，为什么现在翻红了？因为 AI 改变了两笔账。第一笔：prompt 是易逝的，spec 是持久的。你用自然语言指挥 AI 写代码，对话结束意图就散了，下次改功能要从头再描述一遍；而 spec 存在仓库里，人和 AI 每次都能从同一份事实出发，它成了跨会话、跨人的意图载体。第二笔：生成成本趋近于零之后，瓶颈转移到了「说清楚要什么」。以前写代码贵，需求错了改代码代价大；现在代码本身便宜，返工的主要成本是你发现「这不是我要的」时已经浪费的整轮生成——把意图前置写死，ROI 突然变得极高。
换句话说，AI 把软件开发从「写代码的艺术」变成了「写规约的艺术」，SDD 是给这个新现实配的方法论。
合格的 spec 长什么样
这是 SDD 落地最容易翻车的地方。很多人把 PRD 改个名当 spec，结果没用——PRD 是写给利益相关方看的，讲价值讲场景；SDD 的 spec 是写给执行者（AI 或人）的，要求完全不同：
- 可验收：每条需求有明确的通过标准。「支持按状态过滤，非法状态返回 400」可以验收，「筛选体验要好」不行。
- 无歧义：AI 从不为歧义停下来提问，它会自信地选一个理解。歧义在 spec 阶段是免费的，在代码阶段是昂贵的。
- 有边界：明确写「不做什么」，否则 AI 会顺手把相邻功能也「优化」了。
- 不含实现：写「列表查询 P99 小于 200ms」，不写「用 Redis 缓存」——实现选型是 plan 阶段的事，spec 里写死实现会让方案空间塌缩。
和 AI 工作流的衔接
SDD 和 spec/plan/todos/verify 的日常打法是同一件事的两端：日常小任务用轻量版，脑子里过一遍就动手；跨迭代的大功能用完整 SDD，spec 进仓库、plan 评审、tasks 跟踪。实践里我会让 AI 参与 spec 的打磨——写完让它复述理解、指出矛盾和遗漏，AI 当 spec 的「第一读者」特别好用，它找不到歧义的地方，人往往也找不到。
落地阻力
最大的阻力是团队觉得「写 spec 浪费时间」。破局方式是用返工数据说话：统计「生成后发现意图不对」的返工次数，通常一两周的数据就足够有说服力。另一个坑是 spec 写完不维护，代码改了 spec 没改，很快变成谎言——要么把 spec 更新纳入变更流程，要么承认有些 spec 是一次性的，用完归档，别让过期 spec 污染上下文。
可能的追问
- SDD 会不会是新瓶装旧酒，就是瀑布换了个名？——关键区别在反馈周期：瀑布的 spec 冻结数月，SDD 的 spec 到可运行代码只要几小时，错了改 spec 重新生成的成本极低，它是迭代式而不是阶段门式的。
- 小功能也要写 spec 吗？——不用。判断标准是「一次对话能不能装下这个需求」，装得下就直接干；SDD 服务的是跨会话、跨人协作的复杂度，给改文案写 spec 是形式主义。
- spec 和代码不一致了以谁为准？——流程上 spec 是事实来源，改代码先改 spec；但现实里要接受代码领先的窗口期，定期对齐，把「spec 是否最新」当成代码健康度指标来查。