AI 面试模块
AI 应用开发与 Agent 面试总览
把 55 条视频中的 AI 面试、岗位选择、学习路线和项目表达整理成一套可复习的面试地图。
这个模块用于建立整体面试地图。视频中反复出现的主题不是“会不会用某个工具”，而是候选人是否能把大模型能力工程化：从需求识别、数据接入、Prompt 和工具编排，到评测、上线、成本控制和异常兜底。
#面试官真正想判断什么
| 判断点 | 低质量回答 | 高质量回答 |
|---|---|---|
| 大模型应用理解 | 我会调 API、写 Prompt | 我知道模型只是链路中的推理组件，系统还包括数据、权限、状态、工具、评测、监控和成本控制 |
| 项目真实性 | 做过一个智能客服/RAG/Agent | 能讲出数据来源、切片策略、召回指标、失败样例、上线边界和业务收益 |
| 工程能力 | 会 LangChain、会 OpenAI API | 能独立设计接口、异步任务、缓存、限流、权限、灰度、日志和回滚 |
| 成长路径 | 我想转 AI | 能说明自己从原岗位能力迁移到 AI 应用的路径，例如前端体验、后端服务、数据处理或测试评测 |
#推荐复习顺序
- 先补大模型应用工程基础：模型调用、Prompt、Function Calling、结构化输出、流式响应、重试与降级。
- 再学 RAG：文档解析、切片、Embedding、向量库、召回、重排、引用、评测。
- 再学 Agent：任务规划、工具调用、状态管理、记忆、权限、审批、多 Agent 协作。
- 最后准备项目表达：用 STAR 和架构图把项目讲成“业务问题到工程闭环”，而不是工具堆叠。
#典型面试主线
#一分钟自我介绍模板
我过去主要做的是【原方向】，最近把能力迁移到 AI 应用开发，重点做过【项目名称】。项目目标是解决【业务问题】，核心链路包括【数据/模型/工具/评测】，我负责【具体模块】。上线或实验后，我们用【指标】评估效果，例如【召回率、准确率、处理时长、成本、人工通过率】。我对 RAG、Agent、Prompt 工程、模型服务和工程化部署都有系统实践。
#三分钟项目介绍模板
先讲业务背景，再讲系统架构，最后讲指标和问题。不要一上来讲框架名。一个好项目回答应该包含：用户是谁、输入是什么、输出是什么、模型负责什么、不确定性如何处理、失败时怎么兜底、人工如何介入、怎么验证结果、怎么控制成本。
#高频问题与回答骨架
#你理解的 AI 应用开发和传统软件开发有什么不同？
AI 应用开发不是把确定性逻辑替换成模型，而是在确定性系统中引入概率型推理能力。传统软件更强调规则、事务和接口契约；AI 应用还要处理输出不稳定、上下文窗口限制、Token 成本、提示词漂移、幻觉、评测样例集和人工审核。成熟方案通常是“传统工程骨架 + 模型能力 + 评测闭环”。
#你觉得 Agent 和普通工作流的区别是什么？
普通工作流一般是预定义节点和固定路径，适合稳定流程。Agent 允许模型根据目标、状态和工具反馈动态决定下一步，更适合开放任务。但 Agent 的风险也更高，需要限制工具权限、记录步骤、设置最大轮次、加入审批点，并设计失败恢复。
#你如何证明自己不是只会调包？
要用项目细节证明：我如何选择切片长度、怎么处理 OCR 噪声、为什么加重排、如何做 Prompt 版本管理、如何记录每次模型调用、遇到超时怎么重试、如何做成本预算、如何设计评测集。这些问题回答得出来，才像真正做过。
#岗位方向速查
| 方向 | 适合背景 | 核心能力 | 面试重点 |
|---|---|---|---|
| AI 应用开发 | 前端、后端、全栈、产品工程 | API、业务流程、RAG、Prompt、部署 | 项目落地、工程闭环、业务指标 |
| Agent 开发 | 后端、自动化、平台工程 | 工具调用、状态、权限、任务编排 | 任务分解、多轮执行、异常恢复 |
| RAG/知识库工程 | 后端、数据、搜索 | 文档处理、向量检索、评测 | 切片、召回、重排、权限过滤 |
| 模型服务/推理平台 | 后端、运维、算法工程 | GPU、推理框架、监控、成本 | 吞吐、延迟、资源调度 |
| AI 产品工程 | 产品、运营、低代码背景 | 场景拆解、原型、评测、交付 | 业务理解、工具选择、效果验证 |
#面试准备全景图
把 AI 面试拆成四层会更稳。第一层是业务场景，说明为什么需要模型，用户是谁，输入输出是什么，成功标准是什么。第二层是能力链路，说明用了 RAG、Agent、Prompt、工具调用还是模型微调。第三层是工程系统，说明接口、任务队列、缓存、权限、日志、监控、灰度和回滚。第四层是质量闭环，说明评测集、人工审核、线上反馈和成本指标。
如果面试官问“你做过 AI 应用吗”，不要按工具名回答。可以按这条线展开：我做的是一个解决具体业务问题的系统；模型在其中承担理解、生成或决策能力；确定性部分由传统工程保证；不确定性部分通过评测、引用、审核、降级和监控控制。
#项目讲述的 5 个层级
| 层级 | 应该讲什么 | 容易被追问 |
|---|---|---|
| 背景 | 业务痛点、用户角色、原流程成本 | 这个问题为什么值得做 |
| 输入 | 文档、对话、表格、网页、业务数据 | 数据质量、权限、更新频率 |
| 处理 | RAG、Agent、Prompt、工具调用、后处理 | 技术选择原因和替代方案 |
| 输出 | 答案、报告、动作、工单、代码、PPT | 格式校验、引用、人工确认 |
| 指标 | 准确率、采纳率、延迟、成本、节省时间 | 指标如何采集，是否可信 |
#不同轮次的回答策略
#一面：证明你真的做过
一面通常追细节。准备好数据从哪里来、接口怎么设计、Prompt 怎么管理、向量库怎么选、错误日志怎么看、上线后遇到什么问题。回答要落到具体参数和取舍，不要停在概念。
#二面：证明你能做系统
二面更关注架构和边界。要讲清服务拆分、异步任务、权限模型、限流、缓存、灰度、监控、告警和回滚。面试官会判断你是不是只能做 Demo，还是能把功能放进生产系统。
#HR 或业务面：证明你能创造价值
这轮少讲模型细节，多讲业务收益、协作方式、交付周期、风险意识和学习能力。可以准备一个 30 秒版本：我把原来需要人工处理的某个流程，改造成半自动或自动化流程，用指标证明它确实提升了效率。
#常见扣分点
- 只说“调用大模型 API”，没有业务流程和工程闭环。
- 只说“用了 LangChain/Coze/OpenClaw”，讲不出为什么选它。
- 没有评测指标，回答质量全靠主观感觉。
- 没有失败案例，像教程项目而不是真实项目。
- 不知道 Token 成本、上下文窗口、重试、超时和限流。
- 把 Agent 描述成完全自主，忽略权限、审批和审计。
#生产级 AI 应用架构地图
面试时可以把任何 AI 应用放进一张通用架构图里讲：入口层负责 Web、飞书、插件或 API 请求；编排层负责任务分类、Prompt 版本、模型路由、工具调用和状态流转；能力层包含 RAG、Agent、结构化输出、代码执行、文档解析和外部系统 API；治理层包含评测、日志、权限、成本、安全和人工审核。
| 架构层 | 典型组件 | 面试可讲重点 |
|---|---|---|
| 入口层 | Web、IM Bot、浏览器插件、OpenAPI | 鉴权、限流、用户上下文 |
| 编排层 | 路由器、工作流、Agent Runtime、任务队列 | 什么时候固定流程，什么时候让模型决策 |
| 数据层 | 文档库、向量库、业务库、缓存 | 权限继承、索引版本、数据新鲜度 |
| 模型层 | 模型网关、Embedding、重排、生成模型 | 模型选择、结构化输出、超时重试 |
| 工具层 | MCP、内部 API、文件系统、办公系统 | Schema、最小权限、审批和审计 |
| 评测层 | 离线评测、线上抽检、A/B、用户反馈 | 指标、回归、失败样例沉淀 |
| 治理层 | 安全、隐私、成本、合规、监控 | Prompt Injection、敏感信息、预算告警 |
#最佳实践答题框架
当前主流实践都强调一个共同点：先做可评测的简单系统，再增加复杂 Agent。回答时可以用“四个先后”：
- 先用确定性流程解决可预测部分，再把模型放在理解、生成、判断这些不确定环节。
- 先做离线评测集，再调 Prompt、模型、切片或工具。
- 先用工作流和人工确认控制风险，再逐步开放 Agent 自主能力。
- 先建立日志、Trace、Token 和成本账本，再谈规模化上线。
#面试中的架构图口述模板
用户请求进入 API 网关后，系统先做鉴权和限流，再由任务路由器判断是普通问答、RAG 查询、Agent 任务还是内容生成。RAG 任务进入检索链路，Agent 任务进入状态机或图执行器。所有模型调用走统一模型网关，记录 Prompt 版本、模型、Token、延迟和错误。高风险工具调用进入人工审批，最终结果通过结构化校验、敏感信息检查和引用检查后返回用户。线上通过评测集、人工抽检和反馈闭环持续优化。
#候选人自检清单
- 能否在 2 分钟内讲清楚这个模块解决什么业务问题、为什么不是简单调用模型 API。
- 能否说清输入、处理、模型调用、后处理、评测、监控、回滚的完整链路。
- 能否给出至少一个真实项目指标，例如召回率、命中率、延迟、Token 成本、人工复核通过率或线上失败率。
- 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
- 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。