# 1. 用 JSON Schema 定义组件规格，props 类型、枚举与必填约束如何驱动运行时校验、文档生成与 AI 生成约束？ A 使用 JSON Schema 后 TypeScript 类型就不再需要了 B JSON Schema 只能用于运行时校验，无法驱动文档生成 C enum 关键字只影响文档展示，不参与校验 D JSON Schema 把 props 契约作为单一事实源，可同时驱动运行时校验、文档生成与 AI 生成约束 ✓ 正确答案
# 2. Spec-Driven UI（规格驱动 UI）的工程范式，从 PRD → Design Spec → Component Spec → Generated Code 的工作流如何重塑前端开发？ A 规格先行使设计决策在写码前即可评审，缺陷修复成本显著降低 ✓ 正确答案 B Spec-Driven UI 要求所有代码都必须由 AI 生成 C Spec-Driven UI 只在小型项目中适用 D Component Spec 与 Design Spec 是同一份文档的两种叫法
# 3. Storybook 8 + Chromatic + AI Codegen 的视觉与代码一致性闭环，如何用视觉回归保障 AI 生成组件的稳定性？ A Chromatic 只做截图展示，不做差异比对 B 视觉回归把 AI 生成组件的视觉结果变成可自动 diff、可评审、可定基线的 CI 门槛 ✓ 正确答案 C 视觉回归只能检测颜色差异，无法发现布局偏移 D 使用 Chromatic 后 Storybook 就失去了作用
# 4. Spec-Driven UI 中"规格文件"如何组织（JSON Schema/组件规格），如何驱动生成与校验？ A 规格文件作为单一事实源，通过 $ref 复用设计令牌，驱动生成与校验两条链路 ✓ 正确答案 B 规格一旦发布就不能修改，否则生成代码会失败 C 规格文件只能描述视觉样式，不能描述行为契约 D 规格文件应复制进每个组件目录，避免跨文件引用
# 5. Design Tokens（W3C Design Tokens Community Group 规范）与 AI 生成组件的样式一致性如何工程保障？ A 使用 Design Tokens 后就不需要视觉回归了 B Design Tokens 只能在设计软件中使用，无法进入前端工程 C tokens.json 作为唯一视觉来源经构建工具转译为 CSS 变量，AI 生成代码被约束为只消费变量并通过静态与视觉校验 ✓ 正确答案 D AI 生成组件时允许直接使用任意十六进制色值以提升灵活性
# 6. shadcn/ui + Radix UI 作为 AI 友好组件库的优势，复制即可用、无运行时依赖、类型优先 A shadcn/ui 将组件源码复制进项目，无运行时依赖、类型完整，且 AI 可直接以项目内源码为上下文进行生成 ✓ 正确答案 B shadcn/ui 是一个有运行时依赖的 npm 组件包 C Radix UI 自带完整视觉样式，无需再写 CSS D shadcn/ui 组件只能在 Next.js 中使用
# 7. AI 生成 UI 代码的"设计令牌一致性"如何用 Design Tokens 约束？ A 通过 prompt 注入 token 清单、静态规则禁止硬编码与视觉回归兜底三层机制共同约束 ✓ 正确答案 B Design Tokens 只能约束颜色，无法约束间距与字体 C 只需在 prompt 中说明配色方案，AI 就不会写错 D AI 生成代码无法通过任何自动化方式校验样式一致性
# 8. 如何评估 AI 生成前端代码的可维护性（可访问性、性能、可测试性）？ A 可维护性只取决于代码风格是否统一 B 性能评估只看首屏时间，与包体大小无关 C AI 生成代码无需评估可访问性，因为生成器保证正确 D 应从可访问性（axe 扫描）、性能（产物与渲染开销）、可测试性（依赖注入与选择器稳定）三个维度并固化为自动检查 ✓ 正确答案
# 9. Spec-Driven 开发，从接口契约到 UI 的自动化？ A 契约可作为单一来源自动生成类型、客户端与 mock，接口变更在编译期暴露 ✓ 正确答案 B 前端仍需手写请求封装与类型，契约只用于后端文档 C mock 数据必须等待后端联调后才能编写 D GraphQL 无法用于契约驱动开发
# 10. AI 与 Spec 的闭环，从设计令牌到代码生成？ A 闭环是单向流水线：规格产出代码后即结束 B 校验失败的信息无需反馈给生成器 C 人工在闭环中负责所有逐行代码审查 D 规格约束 AI 生成，生成物经自动校验后反馈回规格与基线，形成持续演进的闭环 ✓ 正确答案
# 11. Storybook 与 AI 结合做组件级回归与视觉测试的实践？ A Storybook 只能做开发预览，不能用于测试 B stories 可作为组件级测试用例，play function 覆盖交互后状态，Chromatic 做像素回归，AI 辅助生成用例与差异归因 ✓ 正确答案 C 视觉回归只能检测交互逻辑错误 D play function 是 Chromatic 的付费功能
# 12. AI 生成 UI 的规格约束，设计规范作为 prompt？ A 只要把设计稿图片发给 AI，规范约束就完成了 B 通过令牌清单、组件规则、禁用反例与 few-shot 样例组织提示词，并用结构化输出与失败反例回流保障约束 ✓ 正确答案 C 提示词一旦写好就不需要随设计迭代更新 D 反例（禁止项）会干扰 AI 生成，应尽量避免
# 13. Spec 的版本管理与评审流程？ A 规格文件应独立于代码仓库单独维护 B 规格采用语义化版本，破坏性变更升 major，spec 变更先于实现评审并自动触发生成校验链路 ✓ 正确答案 C 任何规格修改都应升 major 版本 D 规格变更无需评审，直接合并即可
# 14. Spec-Driven 与组件测试的联动？ A 组件测试应独立编写，与规格无关 B 使用规格后测试覆盖率会自动达到 100% C 规格只能驱动单元测试，无法驱动组件测试 D 规格中的 props 与事件契约可映射为测试用例边界，规格变更自动驱动测试与 story 同步更新 ✓ 正确答案
# 15. Spec 的自动化校验，设计稿与实现的 diff？ A 像素 diff 完全一致才说明实现正确，任何差异都需修复 B 自动化 diff 只能比较颜色，无法发现布局问题 C 通过 token 数值比对与截图视觉对比两层手段实现，并对噪声类差异设阈值、结构类差异人工复核 ✓ 正确答案 D 设计稿与实现的 diff 只能由设计师人工完成
# 16. Spec 驱动的可访问性，规范中的无障碍约束？ A 通过 schema 必填属性、规则清单与自动化测试（axe 扫描与键盘导航）将无障碍变成规格验收的一部分 ✓ 正确答案 B 无障碍约束只能靠人工评审，无法自动化 C 只要组件能通过视觉测试，无障碍就一定达标 D 无障碍属于设计问题，无法在规格中表达
# 17. AI 生成组件的可访问性自动检查，将 axe 集成到生成流水线，a11y 失败自动修复提示与人工复核的分工？ A 确定性违规由 AI 依据失败信息自动修复并复扫，涉及语义判断的问题保留人工复核，扫描全绿为合入门槛 ✓ 正确答案 B axe 扫描结果全部由 AI 自动修复，无需人工介入 C axe 只能检测颜色对比度问题 D 可访问性扫描应在组件上线后由用户反馈触发
