开发者AI使用能力考察试题
| 题号 | 分值 | 考察维度 | 对应层级 | 题型 | 核心考察点 |
|---|---|---|---|---|---|
| 1 | 8 | AI 使用层度 | L0 | 选择+简述×2 | 安全隐私红线——云端泄漏 + 本地存储盲区 |
| 2 🆕 | 8 | AI 使用层度 | L0-L1 | 诊断+设计 | Prompt Engineering——提示词结构、迭代优化、上下文注入 |
| 3 | 5 | AI 使用层度 | L1 | 选择题 | 测试通过 ≠ 正确——C++ UB 警觉 |
| 4 🔧 | 10 | AI 使用层度 | L2 | 开放设计 | 会话拆分、Instructions 精准度、跨模块传递、AI 读取范围限定 |
| 5 🆕 | 7 | AI 使用层度 | L2 | 选择+设计 | AI 输出系统性验证——验证策略、信任边界、自动化检查 |
| 6 🔧 | 10 | AI 使用层度 | L3 | 场景决策 | SKILL 长期维护、拆分维度、ROI 论证、Token 节省策略 |
| 7 🆕 | 7 | AI 使用层度 | L2-L3 | 场景+设计 | AI 辅助 Code Review——AI 擅长/不擅长的审查维度、人机协作审查 |
| 8 🆕 | 8 | AI 使用层度 | L3 | 决策+估算 | 模型选型与成本策略——云端 vs 本地、Token 经济、任务-模型匹配 |
| 9 | 10 | AI 使用层度 | L4 | 设计+批判 | Agent 边界定义、变更影响判断、成本诚实评估 |
| 10 🔧 | 16 | AI 使用层度 | L5 | 决策批判+技术架构 | 务实评估、通信拓扑设计、错误传播与恢复、契约验证、Agent 自主权决策 |
| 11 🔧 | 12 | AI 基础知识 | — | 诊断分析 | Token/训练数据/上下文/温度等多维根因分析 + 幻觉分类 |
| 12 🔧 | 13 | 多 Agent 构建 | L4-L5 | 架构设计+实战 | Agent 边界、信息流、决策框架、本地 Agent 工作区配置与编排 |
| 13 | 8 | 单元测试 AI 化 | L3-L4 | 选择+设计 | 变异测试思维、非正常路径边界追问 |
| 14 | 8 | 集成测试 Agent | L4 | 故障定位 | 异步时序诊断、稳健修复、规范提取 |
| 15 | 10 | 综合情境 | 全层级 | 综合决策 | 团队能力评估、务实层级选择、渐进提升路径 |
| 16 🆕 | 10 | 个人 Agent 工作区 | L5+ | 设计+实战 | 个性化多 Agent 工作区设计、Agent 窗口编排流程、配置工程化、过度工程化判断 |
满分 150 分。建议及格线：90 分（具备基本 AI 使用素养）；良好线：113 分（具备独立 AI 工作流设计能力）；优秀线：128 分（具备多 Agent 项目构建和个人 Agent 工作区设计能力）。
🛠 工具说明：本试题以 GitHub Copilot 生态的机制名称为示例（
copilot-instructions.md/SKILL.md/.agent.md/ MCP Server），但所有考察能力均为工具无关的通用能力。不同编码工具的等价机制对照如下，答题时可代入你熟悉的工具：
能力/概念 Copilot Cursor Claude Code Windsurf 其他工具 项目级规则注入 copilot-instructions.md.cursorrules/ RulesCLAUDE.md.windsurfrulesCodeium / Aider 等均有类似机制 模块级知识文件 SKILL.mdRules（按目录生效） CLAUDE.md（模块级）Rules 概念等价，名称不同 定制 Agent/模式 .agent.mdCustom Mode + Rules Custom Commands / Agents Custom Mode 均支持定义角色边界 外部工具集成 MCP Server MCP / Plugins MCP / Tools MCP MCP 为开放协议，跨工具通用 编辑器内 Chat Copilot Chat Cursor Chat / ⌘K Claude Code（终端内） Windsurf Chat 均内嵌于编辑器
试题 1 · L0：网页聊天安全（选择+简述×2）【8 分】
小王在 ChatGPT 网页版（或 Claude.ai / Gemini 等公共 AI 聊天服务）粘贴了 400 行 Go 退款业务代码，要求 AI 优化并发安全。AI 返回
sync.Mutex改写代码后，小王直接提交了 PR。
（1）选择（4 分）：以下哪项是最严重且最容易被忽视的风险？选出一项并简述理由。
- A：AI 的
sync.Mutex加锁粒度过粗，可能死锁 - B：400 行业务代码被发送到公共 AI 服务，存在数据泄露和合规风险
- C：AI 不了解项目已有的并发工具封装（如
safeMap），风格不一致 - D：ChatGPT 无法运行 Go 编译器，代码可能有语法错误
（2）简述（2 分）：如果小王改用本地 Code Agent（如 Claude Code 终端版 / Cursor 本地模式），AI 推理仍通过 API 进行，但会话历史默认存储在本地磁盘（如 ~/.claude/、~/.cursor/ 等目录）。本地会话存储是否意味着没有安全风险？简述需要关注的安全问题。
（3）简述（2 分）：除了"不要粘贴敏感代码到公共 AI"外，列举 ≥2 种在日常开发中可操作的数据防泄漏实践（如工具配置、工作流设计等）。
试题 2 🆕 · L0-L1：Prompt Engineering 基础（诊断+设计）【8 分】
小张需要在 React 项目中实现一个"带虚拟滚动的多选下拉搜索组件"。他在编辑器 AI Chat 中输入：
帮我写一个下拉组件AI 返回了一个基础的
<select>封装。小张不满意，又输入：不是这样的，我要一个更好的，能搜索能多选AI 返回了一个带
filter的简单多选列表，但仍缺少虚拟滚动。来回 5 轮后，小张放弃，决定手写。
（1）诊断（3 分）：分析小张的 Prompt 存在哪些结构性问题？从特异性、上下文注入、约束表达、迭代策略四个维度中至少选三个进行分析。
（2）设计（3 分）：请为小张重写一个高质量的单轮 Prompt（≤200 字），使 AI 能在一次回复中生成接近目标的代码。Prompt 应包含：技术栈约束、功能需求、非功能需求（性能）、输出格式要求。
（3）策略（2 分）：如果单轮 Prompt 仍无法一次到位，请描述一个≤3 轮的迭代策略（每轮的目标和输入变更），说明为什么这种迭代方式比小张的"来回改"更高效。
试题 3 · L1：AI 输出警觉（选择）【5 分】
小李用编辑器内 AI（如 Copilot Chat / Cursor Chat / Claude Code 等）生成 C++ 异步 IO 代码。编译通过，单测全绿，但他总觉得"哪里不对"。
哪项最可能是测试通过但仍存在隐患的根因？
- A：AI 对
std::move后的对象做了二次访问——测试未触发 use-after-move 路径 - B：变量命名不够语义化
- C：缺少注释解释异步 IO 逻辑
- D：AI 用了 C++17 特性，项目要求 C++14
- E：AI 生成的代码没有使用项目封装的
AsyncExecutor工具类，而是直接用了底层std::async
试题 4 🔧 · L2：会话隔离 + 上下文管理（开放设计）【10 分】
项目：Go（auth / order / payment）+ React 组件 + PostgreSQL。团队在编辑器 AI Chat（Copilot Chat / Cursor Chat / Claude Code 等均可）中混讨论所有模块，AI 频繁混淆接口。
- 会话拆分（3 分）：设计会话拆分策略（粒度？每个会话注入什么？）
- Instructions 示例（2 分）：为项目级 Instructions 文件（如
copilot-instructions.md/.cursorrules/CLAUDE.md，选你熟悉的即可）写不超过 15 行的实际内容示例。 - 跨模块策略（2 分）：需求跨 order 和 payment（退款需同时更新订单状态+调用支付网关），会话策略如何处理？
- 限定读取范围（3 分）：AI 编码工具（Copilot / Cursor / Claude Code 等）默认会索引或读取项目中的所有代码文件作为上下文。列举 ≥3 种限定 AI 工具读取范围的手段（如配置文件、目录规则等），并说明各自的适用场景。
试题 5 🆕 · L2：AI 输出系统性验证（选择+设计）【7 分】
某团队规定"AI 生成的代码必须通过人工 Review 才能合并"。但在实践中，Reviewer 面对 200 行 AI 生成的代码时，往往只能做表层检查（命名、格式），深层逻辑缺陷频繁漏过。
（1）选择（2 分）：以下哪种验证策略对 AI 生成代码的逻辑正确性最有效？
- A：要求 AI 在生成代码的同时输出单元测试，Reviewer 检查测试覆盖的业务场景
- B：由另一个 AI（不同模型/不同会话）交叉审查生成的代码
- C：将 AI 生成的代码拆成 ≤50 行的小块，逐块 Review
- D：在 Instructions 中要求 AI 对每个函数添加形式化前置/后置条件注释
- E：Reviewer 不看 AI 生成的代码，只看生成的测试能否覆盖需求文档中的所有场景
（2）设计（3 分）：请为团队的 AI 代码合入流程设计一个3 层验证漏斗（每层说明验证内容、执行者、通过标准），使 Review 精力聚焦在最有价值的检查上。
（3）判断（2 分）：什么类型的任务可以降低验证强度（如跳过人工 Review 直接合入）？给出 ≥2 个具体场景并说明理由。
试题 6 🔧 · L3：SKILLS & MCP Server（场景决策）【10 分】
payment/SKILL.md80 行，使 AI 准确率从 60% 提升到 90%。三月后：新增微信支付、退款改异步、错误码+12 个。
- 维护策略（3 分）：如何维护
payment/SKILL.md？（具体更新策略 + 验证方法） - 拆分决策（2 分）：膨胀到 120+ 行，是否拆分？按什么维度？
- 反驳论证（2 分）：有人提议"每次贴变化后的代码给 AI 看就行"。用数据和场景回应。
- Token 节省策略（3 分）：除了维护 SKILL.md / 规则文件外，列举 ≥3 种在日常使用 AI 编码工具时节省 Token / 降低上下文成本的具体策略，并说明每种策略可能带来的代价（如可能降低 AI 输出质量）。
试题 7 🆕 · L2-L3：AI 辅助 Code Review（场景+设计）【7 分】
团队在 PR Review 流程中引入 AI：每次提交 PR 时，AI 自动对 diff 进行审查并生成 Review Comments。运行一个月后发现：AI 标注了大量"变量命名建议"和"可提取常量"等风格问题，但遗漏了 2 次严重的并发安全隐患（goroutine 泄漏、未取消的 context）。
（1）分析（3 分）：从 AI 的能力边界出发，分析 AI 在 Code Review 中擅长发现什么类型的问题？容易遗漏什么类型的问题？为什么？
（2）设计（2 分）：请为团队的 AI Code Review 流程设计一个"人机分工矩阵"——明确哪些检查项交给 AI（自动）、哪些必须人工确认、哪些需要 AI 标记后人工复核。
（3）Prompt（2 分）：针对 AI 容易遗漏的并发安全问题，写一段插入到 AI Review Prompt 中的专项检查指令（≤100 字），使 AI 在 Review Go 代码时能更有效地标记并发风险。
试题 8 🆕 · L3：模型选型与成本策略（决策+估算）【8 分】
团队日常使用 AI 编码工具的场景包括：① 写单元测试（高频、低复杂度）；② 新功能开发（中频、高复杂度）；③ 代码重构（中频、需全局理解）；④ 紧急 Bug 修复（低频、需快速响应）。当前所有场景统一使用云端旗舰模型（如 GPT-4o / Claude Opus）。
（1）匹配（3 分）：为每个场景推荐更合适的模型级别（如本地小模型 / 云端中模型 / 云端旗舰模型 / 本地大模型等），并说明选择理由。
（2）估算（2 分）：假设月均 1000 次 AI 请求，其中 600 次简单任务（当前用旗舰模型，每次约 $0.03），400 次复杂任务（仍需旗舰模型）。如果简单任务改用中模型（每次约 $0.005），月节省多少？如果同时将 200 次简单任务改用本地模型（成本近乎为零，但需一次性投入 $500 硬件），几个月回本？
（3）决策（3 分）：团队有人提议"全部改用本地部署的开源模型（如 CodeLlama / DeepSeek-Coder），彻底消除 API 成本"。从代码质量、维护负担、数据安全、响应延迟四个维度分析此方案的利弊，并给出你的推荐。
试题 9 · L4：定制化 Code Agent（设计+批判）【10 分】
两个稳定 18 个月的核心模块：
pkg/order（状态机+事务+事件）和frontend/src/order/。已有全局 Instructions、两个模块级知识文件（SKILL.md / Rules 等）、PG Schema MCP Server。
- 角色定义（3 分）：为后端 Agent 写角色定义（如 Copilot 的
.agent.md/ Cursor 的 Custom Mode / Claude Code 的 Custom Command 等）的description（必须能区分"何时该用此 Agent"）。 - 变更影响（3 分）：新增
PARTIALLY_REFUNDED状态，需更新哪些文件？（逐个判断并说明理由） - 批判题（4 分）：Agent 维护成本 vs 高级工程师直接写——从初始投入、持续维护、一致性、新人 onboarding 分析。
试题 10 🔧 · L5：多 Agent 编排（决策批判+技术架构）【16 分】
CTO 要求在 6 个月电商重构项目（Go+React+PG，8 人团队）中实现 L5c Agentic 编排。
1. 回复 CTO（3 分）：写一段 ≤150 字回复 CTO，体现专业又不能直接说"不行"。
2. 前置条件（3 分）：退到 L5a 手动编排，需满足哪些前置条件？（至少 3 条，说明理由）
3. 通信拓扑设计（4 分）：假设项目最终采用 4 个 Agent（订单 Agent、支付 Agent、前端 Agent、数据库 Agent），设计 Agent 间的交互拓扑：
- （a）选择编排模式（Orchestration：中央协调器调度各 Agent）还是编舞模式（Choreography：Agent 间通过事件直接通信）？结合电商场景（订单→支付→库存的强事务依赖）论证你的选择。
- （b）Agent 间传递的信息应以什么格式为主？结构化契约（OpenAPI/Proto/JSON Schema）还是自然语言摘要？分别适用于什么环节？给出一个"支付 Agent 将退款接口变更通知给订单 Agent"的具体信息传递示例。
- （c）多 Agent 通信中，如何防止信息畸变（某一 Agent 的误解被下游 Agent 放大）？给出 ≥2 种机制。
4. 错误传播与恢复（3 分）：在多 Agent 协作链路中，支付 Agent 生成的退款代码存在一个边界 Bug（未处理 refundAmount=0 的情况），导致订单 Agent 基于此代码生成的订单状态更新逻辑也存在缺陷。
- （a）设计一个错误检测机制——在不依赖人工 review 的前提下，如何尽早发现 Agent 链路上的错误？
- （b）当检测到下游 Agent 的错误是上游 Agent 引起的，如何隔离和回滚？给出一个具体的恢复流程（如"回滚到哪个检查点、谁重新生成、验证标准是什么"）。
5. 契约验证（3 分）：如何设计 Agent 间契约验证——确保后端 Agent 生成的接口与前端 Agent 调用代码兼容？
试题 11 🔧 · AI 基础知识（诊断分析）【12 分】
AI 为 Go 项目生成 go-redis 代码，调用了 v9 中已移除的
GetSet方法，编译失败。
（1）多维根因分析（5 分）：从 Token 生成机制 / 训练数据分布 / 上下文窗口 / 温度与采样策略 四个维度分析幻觉根因。要求每个维度至少写出一个具体的因果链。
（2）缓解策略（4 分）：给出 ≥3 种缓解策略，并明确说明每种策略针对的是哪个维度的根因。策略必须可操作（不能只说"提升训练数据质量"这类不可控措施）。
（3）多版本并存（3 分）：项目同时用 go-redis v8（老模块）和 v9（新模块），如何在项目级 Instructions / 模块级知识文件（如 copilot-instructions.md / CLAUDE.md / SKILL.md 等）中描述以避免 AI 混淆？给出具体的配置片段示例。
试题 12 · 多 Agent 项目构建（架构设计）【10 分】
IoT 平台：设备管理(Go)、数据管道(Go)、告警引擎(Go)、管理后台(React)、PostgreSQL+TimescaleDB。三个 Go 模块有数据依赖链。
-
Agent 设计（4 分）：设计几个 Agent？职责？信息流？
-
变更感知（3 分）：告警引擎的两个上游模块接口变更时，如何让告警引擎 Agent 感知？（≥2 种机制）
-
不创建 Agent 的判断（3 分）：哪个模块不适合创建 Agent？为什么？请提炼出一个"是否应该为该模块创建 Agent"的通用决策框架。
-
本地工作区实战（3 分）：假设使用 VS Code 的 Agent Windows 功能（或 Cursor Custom Modes / Claude Code Custom Commands 等同类机制）来实现上述 IoT 平台的 Agent 方案。
- （a）设计项目的 Agent 配置目录结构——需要创建哪些配置文件、各自放在什么路径？给出一个清晰的目录树。
- （b）描述你日常开发"新增告警规则"需求时的完整编排流程：从打开项目到代码合入，你在各 Agent 窗口间如何切换、向每个 Agent 下达什么指令、如何验证中间产出？画出流程或分步骤描述。
试题 13 · 单元测试 AI 化（选择+设计）【8 分】
（1）选择（3 分）：哪种情况最说明"AI 生成的单测覆盖质量低"？
- A：覆盖率报告 95% 行覆盖
- B：将
if price > 0改为if price >= 0后全部测试仍通过 - C：测试代码有重复 Mock 设置
- D：3 个用例用了相同输入值
- E：AI 生成的测试中，所有 Mock 的返回值都是成功路径（
return nil），没有 Mock 过失败路径
（2）设计（5 分）：ProcessRefund(orderID, refundAmount, reason)，AI 生成 8 个用例全部通过。设计 ≥4 个追问验证覆盖质量，必须具体到业务场景。每个追问需说明它考察的是哪类 AI 容易遗漏的边界。
试题 14 · 集成测试 Agent（故障定位）【8 分】
集成测试失败：Step2 支付 mock 成功 → Step3 状态期望 PAID 实际 PENDING。已知回调延迟 100-500ms，当前等待 50ms。
- 故障定位（3 分）：定位故障链路环节，写出推理过程。
- 修复方案（3 分）：如何修改测试脚本？（不要只加 wait——给更稳健方案，至少给出两种不同原理的方案并比较优劣）
- 规范提取（2 分）：基于此案例，在集成测试 Agent 的知识文件（SKILL.md / Rules 等）中增加什么时序规范？写出一条具体的规范条目。
试题 15 · 综合情境（综合决策）【10 分】
视频处理平台（C++转码+Go网关+React后台），3 年老项目。6 人团队：2 人 L1，4 人 L0。无任何项目级 Instructions / 知识文件 / MCP（无论用的是 Copilot、Cursor 还是 Claude Code，均未配置）。最近 AI 生成的 C++ 代码引发内存越界线上事故。CTO 要求"全面提升 AI 使用能力"。
- 层级选择（3 分）：优先推动团队到哪个层级？为什么不选更高层级？
- 防事故机制（3 分）：针对内存越界事故，建立什么机制？（同时服务"防 AI Bug"和"提 AI 效率"）
- 渐进路径（4 分）：4 人 L0 → 渐进式提升路径的前 3 步具体行动（非培训计划，是可执行的技术动作）。每步需要说明：做什么、为什么是这一步（而非其他）、预期产出。
试题 16 🆕 · L5+：个人多 Agent 开发工作区（设计+实战）【10 分】
你是一名人个开发者（非 Team Lead），在一个全栈项目中独立负责较多模块：Go 订单系统（状态机+SAGA事务）、Go 支付网关对接、React 管理后台、PostgreSQL Schema 设计与迁移。项目已有全局
copilot-instructions.md和各模块的SKILL.md。你决定不再"用一个通用 Chat 窗口解决所有问题"，而是将你的 VS Code 改造成一个个人多 Agent 开发工作区——利用 Agent Windows（或 Cursor Custom Modes / Claude Code Custom Commands 等）创建多个专用 Agent，在日常开发中编排它们协作。
1. Agent 组合设计（4 分）：为你的个人工作区设计 4-5 个专用 Agent。对每个 Agent，给出：
- 名称 + 一句话职责（必须有明确的"能做什么 / 不能做什么"边界）
- 触发场景（什么时候你会打开这个 Agent 窗口而非其他？给出具体条件）
- 注入的上下文（它需要读取哪些目录/文件？加载哪些 SKILL.md / 规则文件？）
2. 编排实战（3 分）：以"实现退款功能（跨订单+支付两个模块）"为例，描述你编排这组 Agent 完成开发的完整流程。要求：
- 明确每一步涉及哪个 Agent、给它什么输入、期望它产出什么
- 说明你在各 Agent 之间如何传递信息（手动复制 / 结构化文件 / Agent 间引用？）
- 说明中间产出的验证方式（你怎么知道 Agent A 的输出可以放心交给 Agent B？）
3. 配置工程化（2 分）：你希望这套 Agent 配置能被团队其他成员复用。设计配置文件的工程化结构：
- 哪些配置是项目级（所有人共享）？哪些是个人级（可按自己偏好覆盖）？
- 给出项目仓库中的目录结构（配置文件放在哪些路径下）
- 如何避免"我的 Agent 配置在别人机器上不工作"？
4. 批判思考（1 分）：在什么情况下，你反而会放弃这套多 Agent 工作区，退回用单一通用 Chat？列出 ≥2 个具体的判断条件。