来源：ai-native-hiring-guide（易哈佛医疗内部面试工具，2026 年开源）
核心前提
2026 年，程序员是机甲战士。不再招「会写代码的人」，而是招「会驾驶 AI agent 的人」。
这份手册是一个 AI 驱动团队的内部面试工具，单文件 HTML，浏览器直接用。它对「什么是好的 AI 时代工程师」的定义，值得细读。
双岗模型
手册把候选人分为两类，不强行要求兼具：
Builder 型（产品直觉 + 驱动 AI + 基本设计感）
- 写高质量 Issues，驱动 AI 完成工作
- 快速出原型，验证方向而非等待确认
- 跨角色作战：PM + 设计 + 开发
- 不需要授权就能推动事情发生
Reviewer 型（极强系统思维 + 极快评审速度）
- 快速识别 AI 代码的风险与缺陷
- 给出 AI 能直接执行的修改指令
- 把握整体架构方向，不让系统跑偏
- 能从单次 Review 上升到流程优化
关键洞察：中间地带正在消失。 传统「只写代码」的执行型程序员，在这套流程里越来越没有位置。
五个范式转变
手册开篇定义了他们的核心开发流程：
提交 Issues → [[Claude Code]] 审核确认 → 建分支
→ 人类确认方案 → [[Claude Code]] 写代码 → PR 由 Claude Code Review
→ 人工最终审查合并在这个流程背后，有五个范式转变：
- PRD 没死，顺序变了：先出原型，再配文档说明意图
- 前后端分工淡化：通才比以前更值钱
- 沟通是最大瓶颈：Issues 写得好不好，直接决定 AI 能走多远
- 人类价值转移：从「写代码」转为「提出正确问题」和「做好 Review」
- 系统思维是瓶颈：会用 AI 写代码很容易，知道该建什么、怎么建、建出来对不对——这才是稀缺能力
核心考察：AI 驾驶能力
整个评估体系里，「AI 驾驶能力」在 Builder 和 Reviewer 两个岗位中权重都是最高的（25%）。
5 分标准：指令分步 + 主动提供约束 + 每步验收 + 灵活调整策略
1 分标准：把 AI 当搜索引擎、复制粘贴、不验收、不调整
手册的核心评语：「最终产出能不能跑通不重要，驾驶过程才重要。」
一票否决的 6 条
无论总分多高，触发任何一条直接淘汰：
- 不能接受 AI 比自己写得好
- Issues 写得像工单（缺上下文、约束、预期）
- Review 只说「感觉不对」（说不出具体问题）
- 只关注技术实现，不问「为什么要做」
- 沟通需要多轮才说清一件事
- 面试结束没提出有质量的问题
第 5 和第 6 条在传统面试中几乎不会出现，但放在 AI 驱动的工作流里完全合理：如果跟人类同事都说不清楚，跟 AI 的沟通效率只会更差。
Issues 写作 = 核心硬能力
手册把「写 Issue」提升到与「写代码」同等甚至更高的地位：
- Issue 是人类与 AI 的主要通信接口
- Issue 质量直接决定 AI 能走多远
- 写模糊 Issue 的人不只影响自己，还拖慢整个团队
5 分 Issue 的标准：背景清晰 + 复现完整 + 预期明确 + 边界已列，Claude Code 可直接处理
1 分 Issue 的样本：「搜索有问题，请修复」——AI 无法行动
设计哲学
这份手册和 Superpowers 项目有有趣的呼应：
| 维度 | Superpowers | AI-Native Hiring Guide |
|---|---|---|
| 定位 | 给 AI agent 的行为约束 | 给人类的能力评估 |
| 核心问题 | AI 怎么做好 | 人怎么驾驶 AI |
| 共同信念 | 流程 > 直觉 | 判断力 > 执行力 |
| 共同手法 | Anti-Rationalization | 一票否决 |
互补关系：Superpowers 约束 AI 的行为，这份手册评估人类驾驶 AI 的能力。一个管机甲，一个选战士。
总结
相关：AI-Native 工程师 · Issue Quality · Agent · Superpowers 分析 · 阅读笔记：面试考什么
这份手册对「AI 时代工程师核心能力」的重新定义：
- 写代码不再是核心门槛 — 能力评估重心从执行转向判断
- 沟通成为硬能力 — Issue 质量、反馈清晰度、决策速度
- 中间地带消失 — Builder 或 Reviewer，两者都不是的不录用
- AI 驾驶是基本功 — 两个岗位中权重都最高
- 好奇心是底线 — 不好奇的人无法在这个时代创造价值