# 1. SDD（Spec-Driven Development）相对 TDD/BDD 的本质差异中规格是产品契约而非测试用例，如何驱动 AI 与人类协同实现？ A SDD 与 TDD 完全等价，只是换了个名字 B SDD 把规格作为独立的产品契约，描述"应该做什么"，测试与实现都从规格推导 ✓ 正确答案 C BDD 中测试是唯一需求来源，SDD 中测试可有可无 D SDD 只适用于 AI 生成代码，不适用于人工开发
# 2. GitHub Spec Kit 的四个阶段中 Spec → Plan → Tasks → Implement 的工程化与 AI Agent 集成 A 四阶段顺序固定，Spec 完成后实现必须一次性全部完成 B Spec Kit 只支持 GitHub 单一产品，无法与其他工具集成 C Implement 阶段无需对照规格，可直接生成代码 D 规格与计划是方向性环节，任务与实现可交给 AI Agent，关键是有任务到规格的追溯 ✓ 正确答案
# 3. SDD 的规格文件（Spec）应包含哪些要素（输入/行为/约束/验收），与需求文档的边界？ A Spec 与需求文档是同一份文档，无需区分 B Spec 只需要写行为，不需要写约束和验收 C 需求文档回答"为什么做"，Spec 回答"做什么、如何验收"，Spec 必须可验证、可测试 ✓ 正确答案 D 需求文档越详细越好，Spec 可以省略
# 4. 规格质量的度量中如何用规格评审缺陷率、规格-实现偏差率、返工次数等指标评估规格本身的质量，并据此持续改进模板？ A 规格缺陷率低就说明开发质量好，无需关注实现 B 规格-实现偏差率与返工次数可用于定位规格缺陷，并据此迭代规格模板 ✓ 正确答案 C 返工次数完全由实现者水平决定，与规格无关 D 规格质量不可度量，只能靠经验
# 5. Spec 的粒度与边界中一个 Spec 对应多大变更，粒度过大或过小分别有什么代价？ A Spec 粒度越大越好，可减少文档数量 B 粒度越小越好，能覆盖每个细节 C 合理粒度是"可独立验收的变更"，过大难评审、过小增开销 ✓ 正确答案 D Spec 粒度与是否需要评审无关
# 6. Spec 的"可执行性"（executable spec）vs"描述性"（descriptive spec）中如何让规格既能表达意图又能被 LLM 准确实现？ A 描述性规格足够精确，LLM 能准确实现，无需可执行部分 B 用"描述意图 + 可执行验收"结合，既表达意图又能被 LLM 验证 ✓ 正确答案 C 可执行规格与描述性规格互斥，只能选一种 D 可执行规格只适用于测试，不适用于 AI 实现
# 7. Spec 的版本管理与变更追踪，与 ADR 系统的协同 A Spec 与 ADR 完全无关，各自独立演进 B Spec 版本管理只需记录最新版本，无需历史 C ADR 只用于记录数据库迁移，与 Spec 无关 D Spec 记录"做什么"，ADR 记录"为什么这么做"，涉及架构决策的 Spec 变更应同步更新 ADR ✓ 正确答案
# 8. Spec 驱动的迭代节奏中 Spec 评审、实现、验证与规格回写的闭环如何运转？ A Spec 评审通过后即可冻结，实现中发现的问题无需回写 B 验证阶段只需看代码能否运行，无需对照 Spec C 规格回写只针对测试，不涉及 Spec D 闭环是"评审—实现—验证—回写"，回写防止 Spec 与代码脱节 ✓ 正确答案
# 9. AI 生成 Spec 与人工评审的配合中如何防止"规格自洽但业务错误"？ A AI 生成的 Spec 逻辑自洽即可放心使用，无需评审 B 业务反例测试是多余步骤，不必引入 C 人工评审应聚焦业务正确性，并要求 AI 显式标注推断出的假设 ✓ 正确答案 D 只要 AI 能生成可测试的 Spec，业务就一定正确
# 10. SDD 的渐进式引入中从 TDD/BDD 团队迁移到 SDD 的路径，哪些场景保留 TDD（算法、关键模块），哪些切换到规格驱动，依据是什么？ A 引入 SDD 后应彻底放弃 TDD B 迁移 SDD 应一次性全量切换，无需试点 C 所有场景都应切换为规格驱动，TDD 无任何价值 D 算法、关键模块等需精确验证的场景适合保留 TDD，需求明确、需多方协作的场景适合规格驱动 ✓ 正确答案
# 11. Spec 的反模式中规格退化为需求复述、与实现脱节、无人回写如何识别与纠正？ A 规格与实现脱节、无人回写可通过把回写纳入完成定义与自动比对来纠正 ✓ 正确答案 B 规格退化为需求复述是正常现象，不影响质量 C 规格无需与实现保持一致，各自演进即可 D 回写只针对 AI 生成的代码，人工代码无需回写
# 12. 团队级 Spec 模板与质量门禁中评审标准、可执行性检查、生成代码一致性验证 A Spec 模板只需写需求背景，无需强制字段 B 可执行性检查是可选步骤，不影响质量 C 质量门禁包括评审标准、可执行性检查与生成代码一致性验证 ✓ 正确答案 D 生成代码无需验证与 Spec 的一致性
# 13. 规格的验证中契约测试与属性测试？ A 属性测试只能用于前端，不能用于后端 B 契约测试与属性测试完全等价，可互相替代 C 契约测试验证接口协作契约，属性测试验证逻辑不变量，两者互补 ✓ 正确答案 D 规格验证只需契约测试，不需要属性测试
# 14. 规格驱动的开发流程中从规格到实现？ A 流程是"实现—测试—评审"，规格可有可无 B 流程以规格为主线，从编写、评审、任务拆解、实现到验证与回写 ✓ 正确答案 C 实现完成后无需回写规格 D 规格只用于文档，不参与实现
# 15. 规格的评审与演进中版本管理？ A 规格评审应在实现之后进行，发现偏差再改 B 规格无需版本管理，随时可改 C 规格演进应通过版本号与变更历史进行受控管理，评审在实现前把关 ✓ 正确答案 D 规格评审只看技术，不看业务
# 16. SDD 与 AI 生成代码的结合？ A 规格作为 AI 的约束与验收标准，AI 按规格实现并自检，人负责评审验收 ✓ 正确答案 B AI 生成代码无需规格，直接生成即可 C 规格只用于人工开发，AI 无法理解 D AI 生成代码后无需验证，直接交付
# 17. SDD 与 AI 生成的结合中规格作为 prompt？ A Spec 作为 prompt 应同时包含输入、行为、约束、验收与工程约束 ✓ 正确答案 B Spec 作为 prompt 时只需写功能描述，无需约束 C 规格 prompt 生成后无需人工验收 D Spec 作为 prompt 与人工开发完全无关
# 18. 规格的验收中契约测试与行为验证？ A 验收发现规格有误时，应直接改代码而不改规格 B 规格验收只需人肉查看，无需测试 C 契约测试与行为验证互斥，只能选其一 D 契约测试验证接口契约，行为验证验证行为语义，共同构成规格的可执行验收 ✓ 正确答案
# 19. Spec 变更的传播中需求变化时如何评估对已实现代码与测试的影响，并同步回写规格？ A 应先回写规格，再依据影响评估同步更新代码与测试，保证三者一致 ✓ 正确答案 B 需求变化时先改代码，再回头改规格 C 需求变化时规格无需更新，只需改测试 D 影响评估只需看代码，无需关注测试
