我们的开发模式
面试官必读背景,解释为什么要这样考察
核心开发流程
提交 Issues → Claude Code 审核确认 → 自动建分支 / askuser 补充 → 人类确认方案 → Claude Code 写代码 → PR 由 Claude Code Review → 人工最终审查合并
这意味着什么变了?
PRD 没死
顺序变了:先出原型,再配文档说明意图。不再是「需求 → 设计稿 → 代码」。
前后端分工淡化
通才比以前更值钱。一个能同时做 PM + 设计 + 写代码的人,比三人团队还快。
沟通是最大瓶颈
Issues 写得好不好,直接决定 AI 能走多远。写模糊 Issues 的人会拖慢整个团队。
人类价值转移
从「写代码」转为「提出正确问题」和「做好 Review」。会写代码不再是核心门槛。
系统思维是瓶颈
会用 AI 写代码很容易,但知道该建什么、怎么建、建出来对不对——这才是稀缺能力。
中间地带消失
传统「只写代码」的执行型程序员,在这套流程里越来越没有位置。候选人要么是 Builder,要么是 Reviewer,两者都不是的,不录用。
两种岗位定义
面试开始前必须先判断候选人属于哪一型
Builder 型
产品直觉 + 驱动 AI + 基本设计感
- 写高质量 Issues,驱动 AI 完成工作
- 快速出原型,验证方向而非等待确认
- 跨角色作战:PM + 设计 + 开发
- 从用户视角关注业务价值
- 不需要授权就能推动事情发生
Reviewer 型
极强系统思维 + 极快评审速度
- 快速识别 AI 代码的风险与缺陷
- 给出 AI 能直接执行的修改指令
- 把握整体架构方向,不让系统跑偏
- 高压下快速做取舍决策,不逃避
- 能从单次 Review 上升到流程优化
双栖候选人
如果破冰阶段无法判断候选人属于哪一型,或者候选人明显兼具两种特质,不必强行归类。走「双栖路径」:通用模块正常考,专项模块从 Builder 和 Reviewer 各抽一道核心题(推荐 Q5 + Q9),最后根据得分分布决定更适合哪个方向。强行归类不如让表现说话。
面试流程 & 快速判断
标准 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 给需求」 |
通用题库
所有候选人必考,无论 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 产出的审慎态度;或反过来完全不信任、要求自己重写——无法高效协作 |
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 分 | 两者都想满足,或陷入纠结无法决策,需要他人来决定 |
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 分 | 「看情况」「两个都好」,无法在压力下给出方向,逃避决策 |
一票否决项 & 评分权重
任何一条否决项触发,无论其他表现多好,直接淘汰
✕
不能接受 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 写作质量 通用 | 10 | ||
| B. 方案 Review 能力 通用 | 10 | ||
| G. AI 驾驶能力 通用 | 10 | ||
| C. 产品直觉 Builder | — | 10 | |
| D. 原型驱动能力 Builder | — | 10 | |
| E. PR Review 能力 Reviewer | — | 10 | |
| F. 系统思维 & 决策 Reviewer | — | 10 | |
| 合计(每人考 5 项) | 100% | 100% | 50 |
录用
≥ 35/50 且无否决项
备选
30–34/50 且无否决项
淘汰
< 30/50 或触发否决项
面试评分记录表
每场面试使用一份,面试结束后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
一票否决项检查
逐项勾选代表「已触发」。任何一项触发,无论总分多高,直接淘汰。
→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
→ 淘汰
最终结论