# 1. 自服务模板如何保证生成代码内置合规与质量门禁 A 质量门禁只是建议，可以随便绕过 B 把合规要求写进模板文档由开发者自行阅读落实，门禁默认关闭以免阻塞交付 C 模板把安全与质量基线固化进生成代码，门禁默认开启并绑定合并/发布流程强制执行 ✓ 正确答案 D 模板只生成业务代码，不关心合规
# 2. 平台提供的标准化 CI/CD 模板与团队自定义空间 A 平台固化骨架与门禁，团队在扩展点自定义业务逻辑，通过分层与钩子机制达成平衡 ✓ 正确答案 B 为每个团队各自维护一份完整的流水线副本，即可兼顾标准化与自定义 C 平台模板应禁止任何团队自定义 D 自定义空间与标准化无关，无需设计
# 3. 临时环境（ephemeral environments）的自助开通实现 A 临时环境创建后长期保留，便于复用 B 为每个分支预先长期分配一套独立集群，用完后由开发者手工申请释放 C 临时环境只能手工建，无法自动化 D 通过 PR/事件触发、模板渲染、命名空间隔离与 TTL/自动销毁实现按需创建和回收 ✓ 正确答案
# 4. 脚手架生成代码的「可升级性」中生成后代码与模板脱钩导致的版本漂移如何治理，codemod / 自动化升级路径如何设计？ A 生成代码与模板无关，无需升级 B 让团队升级时手工比对模板 diff 并复制粘贴变更，即可消除版本漂移 C 版本漂移不影响功能，无需治理 D 通过生成标记、codemod 自动化迁移与升级命令，让生成代码持续跟随模板演进 ✓ 正确答案
# 5. 生成代码与手写代码的冲突处理中重新生成时如何合并本地修改，generated marker 与分区策略如何设计？ A 通过 generated marker 与生成区/手写区物理分区，重新生成只覆盖生成区并保留手写区 ✓ 正确答案 B 每次重新生成到新目录，由开发者用 Git 三方合并手工解决全部冲突 C 重新生成时直接覆盖所有代码，无需保留手写修改 D 生成代码永远不能修改
# 6. 平台中密钥/配置的自助供给与最小权限原则 A 开发者应在代码中硬编码密钥，方便使用 B 把密钥集中放在团队共享的配置仓库中，并对全部成员统一开放读取权限 C 通过密钥托管、自助申请、按需最小授权与自动轮换实现安全的自助供给 ✓ 正确答案 D 最小权限会降低可用性，应授予全量权限
# 7. 平台能力与业务代码的耦合防止与边界划定 A 通过面向稳定契约、依赖注入与单向依赖，让业务只依赖平台抽象接口，实现解耦 ✓ 正确答案 B 业务代码直接依赖平台内部实现细节，方便快速调用 C 平台应反向依赖业务代码，实现紧密耦合 D 耦合无影响，无需边界
# 8. 内部模板的版本演进与存量项目升级策略 A 通过语义化版本、changelog、codemod 迁移与分批可回滚升级，实现可控的模板演进 ✓ 正确答案 B 只维护最新一个模板版本，存量项目若无法升级就冻结不再演进 C 模板不需要版本管理，直接覆盖即可 D 升级无需兼容性管理，直接破坏
# 9. 平台 CLI/UI 的开发者体验（DX）设计原则 A CLI 无需文档，功能最多的就是最好的 B 把所有能力都做成图形化表单，命令行只保留最少参数以降低学习成本 C DX 与平台采纳率无关 D 通过一致性、可发现性、即时反馈与默认友好等原则，减少开发者摩擦并提升心流 ✓ 正确答案
# 10. 脚手架的价值中标准化与加速 onboarding？ A 脚手架只是省去敲命令，没有实质价值 B 脚手架把组织最佳实践固化为模板，实现标准化并大幅缩短 onboarding 时间 ✓ 正确答案 C 脚手架的价值在于一次性生成尽可能多的代码，生成后即与平台脱钩 D 脚手架与标准化无关，只与个人效率有关
# 11. 自服务的授权与审计中自助操作的可控性？ A 自服务应给所有开发者全部权限，便于操作 B 自助操作无需审计，反正都是内部人 C 通过 RBAC、最小权限与审批约束授权，并全量记录审计日志，实现既高效又可控的自助操作 ✓ 正确答案 D 授权与审计互斥，无法兼得
# 12. 自服务操作的追溯与成本归属中自助开通环境、权限与资源后的操作日志、审计与成本分摊（chargeback）如何设计？ A 通过资源标签、审计日志、成本聚合与配额预算，实现可追溯与成本归属（chargeback） ✓ 正确答案 B 自助开通的资源无需追溯，也无法归属成本 C 成本归属与自服务无关，无需设计 D 审计日志只记录成功操作，失败无需记录
# 13. 脚手架生成项目的"可观测性基线"中模板如何默认携带日志、指标与追踪配置，减少事后补装与口径不一致？ A 可观测性由各团队事后自行添加，无统一口径 B 只需日志，指标与追踪毫无必要 C 可观测性配置与模板无关，只能手工补 D 模板默认携带日志、指标与追踪配置并统一口径，让新服务开箱即得可观测性 ✓ 正确答案
# 14. 模板自身的质量保障中模板变更如何评审、生成结果如何冒烟测试，防止缺陷被批量复制？ A 模板变更走评审，并用生成样本冒烟测试与自动化验证，重大变更先试点，防止缺陷批量复制 ✓ 正确答案 B 模板变更由作者自测通过后直接发布为最新版，靠使用团队反馈发现缺陷 C 模板缺陷只会影响当前项目，无需担心 D 模板变更可以随意，无需评审与测试
# 15. 自服务与治理（审计/配额）如何兼得 A 自服务与治理不可兼得，只能二选一 B 所有自助操作都需平台管理员逐个人工审批，才能同时保证效率与安全 C 自服务无需任何治理，放开即可 D 通过默认自助、审计全覆盖、配额约束与分级授权，实现"既有开放效率又有安全治理" ✓ 正确答案
# 16. 脚手架的维护中模板演进与反馈？ A 通过模板持续演进、反馈闭环与版本治理，让脚手架持续优化并保持生命力 ✓ 正确答案 B 脚手架交付后应冻结模板，仅在出现安全漏洞时被动修补 C 模板永远不更新，保持初版即可 D 模板维护与团队反馈无关
# 17. 脚手架反馈机制中使用数据与迭代？ A 脚手架迭代由主观想法决定，无需数据 B 以脚手架的生成次数作为唯一反馈指标，即可判断模板是否好用 C 通过采集使用数据、收集反馈、分析痛点并迭代验证，形成数据驱动的演进闭环 ✓ 正确答案 D 使用数据与迭代无关，可忽略
# 18. 脚手架与开发环境一致性中模板如何固定语言版本、依赖锁定与容器镜像，减少"在我机器上能跑"问题？ A 环境一致性会降低灵活性，应避免 B 让每位开发者在本机自行安装匹配的语言与依赖版本即可保证一致 C 只用 lockfile 即可，其他无所谓 D 通过固定语言版本、依赖锁定与统一容器镜像，让开发、CI、生产环境收敛一致，减少"在我机器上能跑" ✓ 正确答案
