EHAFO · AI-NATIVE HIRING · 2026

AI-Native 工程师
招聘面试官手册

专为 AI 驱动开发团队设计 · 覆盖初阶 / 高阶双套评分标准 · 非技术面试官也能快速上手

Builder 型 Reviewer 型 通用题库 评分记录表
01
我们的开发模式 面试官必读背景,解释为什么要这样考察
核心开发流程

提交 Issues → Claude Code 审核确认 → 自动建分支 / askuser 补充 → 人类确认方案 → Claude Code 写代码 → PR 由 Claude Code Review → 人工最终审查合并

这意味着什么变了?

PRD 没死
顺序变了:先出原型,再配文档说明意图。不再是「需求 → 设计稿 → 代码」。
前后端分工淡化
通才比以前更值钱。一个能同时做 PM + 设计 + 写代码的人,比三人团队还快。
沟通是最大瓶颈
Issues 写得好不好,直接决定 AI 能走多远。写模糊 Issues 的人会拖慢整个团队。
人类价值转移
从「写代码」转为「提出正确问题」和「做好 Review」。会写代码不再是核心门槛。
系统思维是瓶颈
会用 AI 写代码很容易,但知道该建什么、怎么建、建出来对不对——这才是稀缺能力。
!
中间地带消失

传统「只写代码」的执行型程序员,在这套流程里越来越没有位置。候选人要么是 Builder,要么是 Reviewer,两者都不是的,不录用。


02
两种岗位定义 面试开始前必须先判断候选人属于哪一型

Builder 型

产品直觉 + 驱动 AI + 基本设计感
  • 写高质量 Issues,驱动 AI 完成工作
  • 快速出原型,验证方向而非等待确认
  • 跨角色作战:PM + 设计 + 开发
  • 从用户视角关注业务价值
  • 不需要授权就能推动事情发生

Reviewer 型

极强系统思维 + 极快评审速度
  • 快速识别 AI 代码的风险与缺陷
  • 给出 AI 能直接执行的修改指令
  • 把握整体架构方向,不让系统跑偏
  • 高压下快速做取舍决策,不逃避
  • 能从单次 Review 上升到流程优化
+
双栖候选人

如果破冰阶段无法判断候选人属于哪一型,或者候选人明显兼具两种特质,不必强行归类。走「双栖路径」:通用模块正常考,专项模块从 Builder 和 Reviewer 各抽一道核心题(推荐 Q5 + Q9),最后根据得分分布决定更适合哪个方向。强行归类不如让表现说话。


03
面试流程 & 快速判断 标准 60 分钟面试的时间分配
00 – 05 min
破冰 & 定型 问候选人最近在用哪些 AI 工具、最近做了什么有成就感的东西。同时判断 Builder / Reviewer / 双栖倾向。
05 – 20 min
通用模块 A+B — Issues & Review 所有候选人必考。Issue 质量题 + 方案 Review 题各一道,初阶选基础版,高阶选进阶版。
20 – 30 min
通用模块 G — AI 驾驶实操 所有候选人必考。让候选人现场使用 AI 编程工具完成一个小任务,观察他怎么驾驶 agent。这是机甲战士的基本功测试。
30 – 45 min
专项模块 Builder:产品直觉题 + 原型实操题 | Reviewer:PR Review 实操 + 系统决策题 | 双栖:各抽一道核心题
45 – 55 min
候选人提问 & 开放讨论 这是最能暴露思维层次的环节。观察他问的是「自己的待遇」还是「团队的问题」。可结合系统思维做开放讨论。
55 – 60 min
当场评分 按评分表填写,30分钟内提交结论,避免记忆衰退影响准确性。

5 分钟快速判断法(面试开始时用)

问题 Builder 信号 ✓ Reviewer 信号 ✓ 淘汰信号 ✕
你最近用 AI 做了什么? 给出具体案例,有产出物 描述如何发现 AI 的错误并修正 「有用 ChatGPT 查过东西」
最近有什么没做成的事? 能分析失败原因,愿意复盘 能找到系统性问题所在 推卸责任,或无法举例
如果接手新项目,第一步? 先出原型 / 了解用户痛点 先看现有架构和代码质量 「等 PM 给需求」

04
通用题库 所有候选人必考,无论 Builder 还是 Reviewer

模块 A · Issues 写作质量

初阶候选人

Q1 请用5分钟写一个 Issue:我们的搜索结果不准,用户反馈很多。 初阶
考察重点:能否提供可操作信息(复现路径、预期行为、边界条件);Claude Code 是否能直接处理这个 Issue
评分标准
5 分背景清晰 + 复现路径完整 + 预期行为明确 + 边界条件已列出,Claude Code 可以直接开始处理
3 分描述清楚,但缺少复现细节或边界条件,AI 需要追问才能继续
1 分模糊描述,如「搜索有问题,请修复」,AI 无法直接行动

高阶候选人

Q2 你提交了一个 Issue,Claude Code 回来 askuser 补充了3个问题。这说明你的 Issue 哪里有问题?你会怎么改写? 高阶
考察重点:自我迭代能力;能否识别 Issue 模糊性的根本原因,而非把 askuser 视为正常现象
评分标准
5 分能准确指出 Issue 缺少的信息类型(上下文 / 约束 / 优先级),并给出改写版本
3 分能反思问题,但改写版本仍有遗漏,或只能改写不能说明原因
1 分认为 askuser 是正常的,不觉得是 Issue 的问题,缺乏主动优化意识

模块 B · 方案 Review 能力

初阶候选人

Q3 (给候选人看一段 AI 生成的方案摘要)这个方案你会通过吗?有什么顾虑? 初阶
考察重点:能否在5分钟内给出有效结论;是否有基本的风险意识和决策能力
评分维度满分考察点
速度2 分5分钟内能否得出有效结论,不拖延
风险识别3 分安全 / 性能 / 边界问题有没有看出来
决策清晰度2 分给的是明确指令还是模糊的「感觉」
边界感3 分知不知道哪些自己判断不了、需要升级决策
面试官备用素材 — 展示给候选人看
需求: 用户反馈搜索结果不准确,经常搜不到想要的商品 AI 生成方案摘要: 1. 将现有 MySQL LIKE 模糊查询迁移到 Elasticsearch 2. 接入 IK 中文分词器,支持同义词和拼音搜索 3. 热门搜索词用 Redis 缓存,TTL 设为 5 分钟 4. 新增 /api/v2/search 接口,旧接口保留不动 5. 前端搜索组件增加「猜你想搜」下拉提示 6. 预计改动 14 个文件,新增约 1,200 行代码 7. 开发周期:3 天 // 候选人应该能发现的问题(面试官参考,不要展示): // - 数据同步策略缺失(MySQL → ES 如何同步?增量还是全量?) // - 3天引入全新基础设施(ES)不现实,缺少部署/运维方案 // - 缓存失效策略:商品数据变更后缓存如何清理? // - 没有定义「准确」的衡量标准,无法验证方案是否成功 // - 没有回滚方案:ES 挂了怎么办? // - 旧接口保留 = 双倍维护成本,没有下线计划

高阶候选人

Q4 Claude Code 的方案你看了觉得有问题,但说不清哪里不对,就是感觉不对。你怎么处理? 高阶
考察重点:直觉与严谨的平衡;不确定时的行动策略;能否把「感觉」转化为可验证的假设
评分标准
5 分能把「感觉不对」拆解成可验证的假设,并设计验证步骤,不会因此卡住整个流程
3 分会寻求他人意见,但缺乏系统性的验证方法
1 分要么盲目通过,要么完全卡住不决策,两种极端都是问题

模块 G · AI 驾驶能力

!
这是机甲战士的基本功

其他能力再强,不会驾驭 AI agent 就无法在我们的流程里创造价值。这个模块考的不是「会不会用 ChatGPT」,而是能否把 AI 当成高效的协作搭档来驾驶。

初阶候选人

Q13 现场演示:这里有一个小需求(见下方素材)。请打开你常用的 AI 编程工具,用 10 分钟完成它。我们不评判最终代码质量,只看你怎么跟 AI 协作。 初阶
考察重点:prompt 质量、上下文管理、验收习惯、出错时的应对策略。看的是「驾驶姿势」,不是「目的地」
评分标准
5 分指令清晰分步、主动提供约束和上下文、每步验收产出再继续、遇到问题能快速调整策略而非反复重试同一个 prompt
3 分能用 AI 完成任务,但 prompt 模糊需要多轮修正,或直接接受产出不验收
1 分把 AI 当搜索引擎用、复制粘贴式交互、完全不验收产出质量、不会调整策略
Q13 备用需求卡片 — 面试官可替换为团队实际业务需求
需求: 写一个命令行工具,输入一个 GitHub 仓库的 URL,输出这个仓库最近 10 次提交的: - 提交者 - 提交时间 - commit message 的第一行 约束: 用你最熟悉的语言,可以调用 GitHub API(不需要认证的公开仓库即可) // 面试官关注点(不展示给候选人): // 1. 候选人是一上来就让 AI「写一个工具」,还是先分步拆解? // 2. 有没有告诉 AI 用什么语言、错误处理要求、输出格式? // 3. AI 生成代码后,候选人是直接跑还是先读一遍? // 4. 遇到报错,候选人是把报错信息直接丢给 AI 还是自己先分析? // 5. 最终产出能不能跑通不重要,驾驶过程才重要

高阶候选人

Q14 AI 生成了一段能跑通所有测试的代码,但你读了之后完全看不懂它的实现思路。你会直接合并吗?你的判断标准是什么? 高阶
考察重点:对「能跑」和「可维护」的区分;是否有让 AI 解释自身产出的意识;对 agent 输出的信任边界
评分标准
5 分明确区分「能用」和「能维护」,会要求 AI 添加注释或重构为可读版本,指出「看不懂本身就是不合格」,给出具体改写指令
3 分倾向拒绝或要求解释,但说不清「可维护性」的具体标准是什么
1 分「测试通过就合并」——缺乏对 AI 产出的审慎态度;或反过来完全不信任、要求自己重写——无法高效协作

05
Builder 专项题库 产品直觉强、能跨角色作战、以产出为导向的候选人
*
考察目标

确认他能「一个人驱动一条线」——从发现问题,到写 Issue,到出原型,到推动落地,不需要等待授权或他人决策。

模块 C · 产品直觉

初阶候选人

Q5 (展示产品截图)你有30秒,告诉我这个页面最大的问题是什么。 初阶
考察重点:第一反应是否准确;能否快速抓住核心问题而非列举细节;速度本身也是考察维度
评分标准
5 分30秒内指出核心体验问题,能说出「为什么这是最大问题」而不只是描述问题
3 分指出了问题,但是次要问题,或需要超过30秒思考
1 分列举一堆细节,抓不住重点;或完全没有意见,需要引导

高阶候选人

Q6 你发现了一个用户痛点,但这个需求 PM 没有提过。你会怎么推进它? 高阶
考察重点:主动性;跨角色意识;能否在无授权情况下推动事情发生,而不是等待
评分标准
5 分有清晰推进路径:先验证(原型/数据)→ 对齐优先级 → 写 Issue 驱动落地,不等授权
3 分愿意推进,但路径模糊或依赖他人决策
1 分「这不是我的职责」或「要等 PM 决定」——执行思维,无法在 AI 时代创造价值

模块 D · 原型驱动能力(实操)

初阶候选人

Q7 需求方向:「用户想快速找到自己上次没看完的内容」。请用15分钟,用任何工具(含 AI)出一个可以给人看的原型,不要文字描述。 初阶
考察重点:能否将模糊需求快速转化为可视化产出;工具运用效率;是否能在约束下做取舍
评分标准
5 分15分钟内有可交互原型,核心流程完整,设计决策能说清楚理由
3 分有静态设计稿或清晰线框图,能表达核心交互逻辑
1 分15分钟后只有文字描述,没有任何可视化产出

高阶候选人

Q8 你的原型出来了,设计师说「不好看」,PM 说「方向不对」。你怎么判断该改哪个? 高阶
考察重点:在冲突意见中的决策能力;能否区分「审美问题」和「方向问题」;优先级判断
评分标准
5 分能快速区分两种反馈的性质,先解决「方向」再解决「好看」,能说出验证方向正确性的具体方法
3 分倾向于先满足其中一方,但缺乏系统性判断框架
1 分两者都想满足,或陷入纠结无法决策,需要他人来决定

06
Reviewer 专项题库 系统思维强、技术判断快、能在高速 AI 输出中把控质量的候选人
*
考察目标

确认他能「守住最后一道防线」——在 AI 高速输出代码的情况下,快速、准确地识别问题,并给出可执行的修改指令。

模块 E · PR Review 速度与深度

初阶候选人

Q9 (给一段 AI 提交的代码变更,约50–80行)请你在8分钟内完成 Review,给出:通过 / 驳回 / 需修改,以及具体理由。 初阶
考察重点:速度与准确性的平衡;是否能给出 AI 可以直接执行的反馈,而非模糊评论
评分维度满分考察点
速度3 分8分钟内完成,不拖延
问题识别4 分发现 bug / 安全漏洞 / 性能问题 / 边界条件
反馈质量3 分给的是 AI 能直接执行的指令,而非「感觉不好」
Q9 面试官备用素材 — 展示给候选人 Review 的代码变更
PR #142: 新增用户数据导出接口 // 变更文件: api/export.js (+58行) const router = require('express').Router(); const db = require('../models'); // 导出用户列表 router.get('/api/users/export', async (req, res) => { const format = req.query.format || 'csv'; const department = req.query.dept; let query = 'SELECT * FROM users'; if (department) { query += ` WHERE department = '${department}'`; } const users = await db.raw(query); if (format === 'csv') { let csv = 'id,name,email,phone,address,salary,created_at\n'; for (const u of users) { csv += `${u.id},${u.name},${u.email},${u.phone},${u.address},${u.salary},${u.created_at}\n`; } res.setHeader('Content-Type', 'text/csv'); res.setHeader('Content-Disposition', 'attachment; filename=users.csv'); res.send(csv); } else if (format === 'json') { res.json({ data: users, count: users.length }); } }); // 导出单个用户详情 router.get('/api/users/:id/export', async (req, res) => { const user = await db.raw( `SELECT * FROM users WHERE id = ${req.params.id}` ); if (!user.length) { return res.status(404).json({ error: '用户不存在' }); } const orders = await db.raw( `SELECT * FROM orders WHERE user_id = ${req.params.id}` ); res.json({ user: user[0], orders: orders, exported_at: new Date().toISOString() }); }); module.exports = router; // 候选人应该发现的问题(面试官参考,不要展示): // [严重] SQL 注入: department 和 id 直接拼接进 SQL // [严重] 无权限校验: 任何人都能导出全部用户数据 // [严重] 数据泄露: SELECT * 导出了 salary、address、phone 等敏感字段 // [中等] 内存风险: 一次性加载所有用户,大数据量会 OOM // [中等] CSV 注入: 用户可控字段直接写入 CSV,可构造公式注入 // [低等] 无错误处理: 没有 try/catch,异常会导致进程崩溃 // [低等] format 无兜底: 既不是 csv 也不是 json 时,连接会挂起

高阶候选人

Q10 你 Review 了 Claude Code 的 PR 十次,发现它总是在同一类地方犯错(例如总是遗漏错误处理)。你会怎么系统性地解决这个问题? 高阶
考察重点:从单次修复上升到流程优化的意识;能否影响 AI 的输出质量而不是一遍遍修同样的错
评分标准
5 分能提出系统性方案:改写 Issue 模板 / 建立 Review Checklist / 调整 prompt 范式,并说出验证效果的方法
3 分意识到是系统问题,但解决方案仍是「下次提醒它」
1 分每次都单独修改,没有意识到这是可以系统性优化的问题

模块 F · 系统思维 & 决策

初阶候选人

Q11 我们想做「用户可以导出订单历史报告」这个功能。先不要想技术实现,告诉我:这个功能真正要解决的问题是什么?什么情况下我们不该做它? 初阶
考察重点:能否在动手前先想清楚「该不该建」;是否有产品层面的判断力,而不只是执行
评分标准
5 分拆解出真实用户需求(不只是字面功能),列举不做的合理场景(使用率低 / 维护成本高 / 有替代方案)
3 分能质疑需求,但分析不完整,或只能说出一个维度
1 分直接讨论技术实现,完全跳过必要性判断

高阶候选人

Q12 一个功能,Claude Code 给了两个方案:方案 A 更快上线,方案 B 更易维护。Deadline 是下周。你怎么决策?你需要哪些信息? 高阶
考察重点:压力下的判断力;能否快速识别决策所需信息;是否能在假设条件下给出清晰方向,不逃避
评分标准
5 分明确列出需要的信息(Deadline 硬性?技术债严重程度?后续资源?),然后在假设条件下给出清晰决策
3 分会寻求更多信息,但决策框架不清晰,给不出方向
1 分「看情况」「两个都好」,无法在压力下给出方向,逃避决策

07
一票否决项 & 评分权重 任何一条否决项触发,无论其他表现多好,直接淘汰
不能接受 AI 比自己写得好 测试方法:问「Claude Code 的代码和你写的,哪个更好?」——防御性强、回避比较,说明心态有问题,无法在这套流程里高效工作。
Issues 写得像工单,没有上下文 这是我们流程的致命伤。一个只会写「修复搜索 bug」的人,会让 AI 反复 askuser,拖慢所有人。
Review 时只说「感觉不对」,说不出具体问题 Reviewer 岗位直接淘汰。无法给出可执行反馈的 Reviewer,比没有 Reviewer 更危险。
只关注技术实现,从不问「为什么要做这个」 系统思维缺失的信号。在 AI 时代,执行不是稀缺的,判断力才是。
沟通需要多轮才能说清一件事 沟通成本是最大拖慢因素。这类候选人不仅拖慢 AI,也拖慢团队里每一个人。
面试结束时没有提出任何有质量的问题 只问薪资、假期的候选人,说明他对工作本身没有好奇心。只问自己的利益,不关心团队的问题。

综合评分权重

#
录用线

每人考 5 个模块(3 通用 + 2 专项),每模块 10 分,总分 50 分。35 分及以上(≥ 70%)且无否决项,进入录用讨论。30–34 分列为备选。低于 30 分直接淘汰。

考察模块 Builder 权重 Reviewer 权重 满分
A. Issues 写作质量 通用
20%
15%
10
B. 方案 Review 能力 通用
10%
20%
10
G. AI 驾驶能力 通用
25%
25%
10
C. 产品直觉 Builder
25%
10
D. 原型驱动能力 Builder
20%
10
E. PR Review 能力 Reviewer
20%
10
F. 系统思维 & 决策 Reviewer
20%
10
合计(每人考 5 项) 100% 100% 50
PASS
录用
≥ 35/50 且无否决项
HOLD
备选
30–34/50 且无否决项
FAIL
淘汰
< 30/50 或触发否决项

08
面试评分记录表 每场面试使用一份,面试结束后30分钟内填写并提交
考察模块
满分
实得分
关键观察
A. Issues 写作质量(Q1/Q2)通用
10
B. 方案 Review 能力(Q3/Q4)通用
10
G. AI 驾驶能力(Q13/Q14)通用
10
C. 产品直觉(Q5/Q6)Builder
10
D. 原型驱动能力(Q7/Q8)Builder
10
E. PR Review 能力(Q9/Q10)Reviewer
10
F. 系统思维 & 决策(Q11/Q12)Reviewer
10
综合总分(填 5 项,满分 50)
录用线:≥ 35 分(70%)且无否决项
/ 50

一票否决项检查

!

逐项勾选代表「已触发」。任何一项触发,无论总分多高,直接淘汰。

→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
最终结论

面试官提交前 Checklist