# 1. Cursor Composer 与 Claude Code Task tool 的多文件工程化任务对比 A 两者功能完全相同 B Task tool 无法处理多文件 C Composer 是 IDE 内可视化 diff 协作，Task tool 是可脚本化并行的 CLI sub-agent，按任务形态选型可组合使用 ✓ 正确答案 D Composer 不能回滚改动
# 2. AI 生成代码审查（API 幻觉、安全漏洞、性能、license） A AI 生成的代码不会引用不存在的 API B 审查四要点：API 幻觉（类型检查核对）、安全漏洞（扫描+重点人工）、性能（基准）、license（扫描与政策核对），并强制走标准门禁 ✓ 正确答案 C license 问题只存在于依赖中 D 安全扫描可以完全替代人工审查
# 3. Snyk Code / CodeQL / Semgrep 在 AI 协作时代的代码审查工程价值 A Semgrep 规则灵活、CodeQL 深挖数据流、Snyk 贴近开发流，组合成 PR 自动门禁并对 AI 代码做兜底扫描 ✓ 正确答案 B 有一款 SAST 工具就足够了 C SAST 只能扫描依赖漏洞 D 扫描结果都应该设硬门禁
# 4. AI 生成的代码在 Manifest V3、Content Security Policy、Trusted Types 的安全审计与工程价值 A Trusted Types 会阻止所有 DOM 操作 B MV3 禁远程代码、CSP 收敛脚本来源、Trusted Types 强制 DOM 写点可信，三者构成 AI 代码的机制性安全基线 ✓ 正确答案 C CSP 允许 'unsafe-inline' 也没有风险 D 这三个机制只适用于扩展
# 5. Claude Code 的 CLAUDE.md 与项目级上下文规范 A CLAUDE.md 是给人类团队看的文档 B 根级与目录级规则冲突时根级优先 C CLAUDE.md 按架构/命令/约定/禁止项组织并分层加载，像代码一样评审与版本化，让 AI 在团队规范内工作 ✓ 正确答案 D 规范越抽象越通用越好
# 6. 提示注入防护（仓库级规则文件审查、外部内容不可信标识） A issue 描述可以完全信任 B 规则文件需版本化评审与篡改校验，外部内容标记不可信且不执行其指令，工具参数白名单校验并监控异常调用 ✓ 正确答案 C README 中的指令应直接执行 D 提示注入只发生在对话场景
# 7. 度量只用于工程流程与安全（返工率、SLA、安全事件），不评价个人绩效或代码生成量 A 代码生成量是最重要的绩效指标 B 度量应聚焦返工率、SLA 与安全事件等流程指标，避免生成量类指标诱导刷量行为 ✓ 正确答案 C 采纳率可以完全反映 AI 产出质量 D 度量指标不需要定期评审
# 8. AI 协助但由人工把关的失败案例 A 失败主要是模型能力不足，与把关无关 B AI 生成代码可以自动合入生产 C 根因常是上下文缺失、权威效应与把关缺失，应设强制确认点、证据驱动验证并引导质疑式审查 ✓ 正确答案 D 人工把关会降低效率，应尽量取消
# 9. AI 工具治理（Prompt/上下文文件版本化、审计、合入门禁、依赖与供应链安全） A 规则文件不需要版本管理 B AI 引入的依赖无需特殊检查 C 治理四支柱：配置版本化、全量审计、同等合入门禁、依赖供应链检查（校验/扫描/SBOM），一切可追溯可回滚 ✓ 正确答案 D 审计日志只对安全团队开放即可
# 10. SQL/XSS/Path Traversal 类漏洞的 AI 代码生成模式的工程风险 A AI 不会生成 SQL 注入类代码 B 参数化查询只影响性能 C AI 会复现训练数据中的危险写法（拼接 SQL/插入 HTML/路径拼接），需安全扫描门禁、规范注入与人工重点审查 ✓ 正确答案 D 漏洞模式库没有价值
# 11. AI Prompt injection（隐式注入到依赖/文档/注释） A 注释和文档不会包含指令 B 依赖代码无需扫描 C issue 描述只能影响人类 D 攻击者可把指令藏在文档/注释/依赖中，需内容分级不可信标记、规则文件校验与工具参数白名单纵深防御 ✓ 正确答案
# 12. Copilot Trust Center/企业策略在 AI 协作代码合规的工程价值 A 企业版默认会把代码用于训练 B 合规评估不需要供应商数据条款 C 企业策略无法限制用户使用 D Trust Center 透明化数据处理条款，企业策略可配置训练开关、内容过滤与审计，支撑合规评估与落地 ✓ 正确答案
# 13. secretlint/gitleaks 在 AI 生成的密钥/凭据扫描的工程价值 A 扫描工具只能识别已知格式的密钥 B 假密钥不需要处理 C gitleaks/secretlint 用正则+熵检测+规则在提交/CI 拦截硬编码密钥，AI 时代作为自动兜底并配套轮换流程 ✓ 正确答案 D 密钥扫描可以替代权限管理
# 14. eslint-plugin-security 与 Snyk/CodeQL 在代码安全审计的现代工程价值 A eslint 安全插件可以替代 SAST B lint 规则即时拦模式、SAST 做数据流分析、CodeQL 深挖调用链，三层互补覆盖 AI 代码的安全风险 ✓ 正确答案 C CodeQL 与 Semgrep 能力完全重合 D 安全审计只做一次即可
# 15. GitHub Copilot Workspace 与 Cursor AI 在 PR 审查的现代工程价值 A AI 审查结论可以直接作为合并决策 B PR 摘要一定会准确反映 diff C AI 在生成侧写摘要与计划、审查侧自动点评找问题，与标准 review 流程集成，但合并决策仍留给人 ✓ 正确答案 D AI 审查不需要配置规则
# 16. Greptile、CodeRabbit（AI Code Review 工具） A 这类工具可以直接批准 PR B AI 审查不会误报 C 工具索引仓库并在 PR 上自动分级点评与修复建议，规模化覆盖每个 PR，误报需按规则治理且批准权仍属人工 ✓ 正确答案 D 这类工具无法行内评论
# 17. Secret Scanning（gitleaks、TruffleHog） A gitleaks/TruffleHog 用正则+熵+验证检测密钥，覆盖 pre-commit/CI/历史/监控全链路，命中即告警并轮换清理 ✓ 正确答案 B TruffleHog 只做正则匹配 C 历史提交中的密钥无需处理 D 误报无需反馈调优
# 18. CodeQL（GitHub 原生）在代码安全漏洞模式扫描的现代工程边界 A CodeQL 适合每次提交全量扫描 B CodeQL 可以替代人工安全审查 C CodeQL 支持所有语言 D CodeQL 用查询式数据流分析深挖跨文件漏洞并原生集成 GitHub，但分析成本高，适合深度审计并与轻量工具分工 ✓ 正确答案
# 19. Sigstore / npm sbom 在供应链 SBOM（Software Bill of Materials）发布的工程价值 A npm sbom 生成依赖清单，Sigstore 提供可验证签名，两者构成"包是谁发的、含什么"的供应链信任链 ✓ 正确答案 B SBOM 只是给合规看的清单，无安全价值 C Sigstore 需要预先信任特定 CA D 依赖投毒无法被检测
# 20. AI 生成代码引用了不存在或拼写相近的 npm 包时，CI 如何组合 registry 元数据校验、frozen lockfile、允许列表、OSV/Snyk 扫描和安装脚本禁用，在合并前阻断依赖幻觉与 typosquatting A 只要包能安装就可以信任 B lockfile 会放大幻觉风险 C postinstall 脚本可以放心执行 D 组合元数据校验、frozen lockfile、白名单、OSV/Snyk 扫描与禁用安装脚本，把新依赖变更纳入合并前门禁与人工评审 ✓ 正确答案
# 21. Greptile 或 CodeRabbit 在大型仓库中的误报率应如何抽样标注和分规则统计 A 误报率无法统计 B 分层抽样标注并按规则聚合统计精确率/召回率，禁用高误报规则并优化提示，形成调优闭环 ✓ 正确答案 C 所有规则都应保持默认开启 D 误报样本不需要回灌
# 22. AI 生成的代码在 code review 中应如何分段（增量） A 大 PR 一次性审查效率更高 B 无关改动可以混入核心变更 C AI 改动无需标注来源 D 按逻辑单元分 commit 提交，审查按契约→核心逻辑→边界→测试的顺序，便于定位与回滚 ✓ 正确答案
# 23. 如何为 AI 生成代码注入的依赖构建 SBOM（软件物料清单） A SBOM 只需要列出直接依赖 B AI 引入的依赖无需单独标记 C SBOM 与漏洞披露无关 D 用工具生成标准格式 SBOM（含传递依赖），标记 AI 引入来源并版本化 diff 评审，与漏洞库与 license 审计联动 ✓ 正确答案
