AI 开发经验面试：你是真的每天在用 AI 吗
2026 年以后的 AI 开发面试，越来越少考公式，越来越多考真实使用经验：怎么用 Agent、MCP、Skills、Vibe Coding、RAG 和 Coding Agent。
10 / 10
100%现在面 AI 开发者，我不会一上来问 Attention 公式。
我更想知道一件事：
你是真的每天在用 AI 做项目，还是只是在看新闻、刷榜单、背概念？
所以这篇不是“标准答案大全”。它更像一套面试时可以直接说出口的回答稿。
回答时有个简单原则：
先说人话
再说概念
最后说自己怎么用、怎么踩坑
如果一个人只会说“Agent 是未来”“MCP 很重要”，但说不出自己怎么限制 AI 改代码、怎么处理工具失败、怎么判断 RAG 召回质量，那大概率还停留在看热闹。
第一部分：概念理解
1. 什么是 Skills？和 MCP 有什么区别？
可以这么说：
Skills 我理解成“给 AI 准备的一包专门能力”。
比如我希望 AI 更会做 PPT，我就给它一套做 PPT 的说明、模板、脚本、注意事项。下次它遇到做 PPT 的任务，就不用从零猜。
所以 Skills 更像：
一包能力
一套做法
一份操作手册
MCP 不太一样。MCP 更像“统一插口”。
以前每个 AI 工具要接数据库、浏览器、GitHub、飞书、Notion，都要自己写一遍连接方式。MCP 想解决的是：能不能大家都按一个标准接？
我会这样比喻：
Skills：我会做 PDF 总结。
MCP：我提供一个标准接口，PDF 工具、数据库工具、浏览器工具都能接进来。
所以一句话区分：
- Skills 关心 AI 会不会做某类事
- MCP 关心 AI 怎么连接外部工具
为什么现在 MCP 声量更大？因为做真实产品时，最麻烦的往往不是“模型会不会总结”，而是“它怎么安全、稳定地接入一堆外部系统”。
2. MCP 和 Tool Calling 有什么区别？
可以先说一句：
它们都和“调用工具”有关，但层级不一样。
Tool Calling 更像模型的一种能力。模型看到你给它的工具列表，然后生成一段 JSON，告诉程序“我要调用这个工具，参数是这些”。
模型
-> 生成工具调用参数
-> 应用执行工具
-> 把结果返回给模型
MCP 更像一整套接工具的方式。
AI 客户端
-> MCP Server
-> 外部工具或数据源
也就是说，Tool Calling 解决的是“模型怎么叫工具”。MCP 解决的是“工具怎么标准化地被 AI 应用发现和接入”。
我的理解是：
Tool Calling 是发动机里的一个能力，MCP 是让各种外部设备能接进来的接口规范。
3. Function Calling 和 Tool Calling 有区别吗？
可以这么答：
早期大家更常说 Function Calling，因为那时候想象的场景很简单：模型调用一个函数。
比如：
getWeather({ city: "Shanghai" })
后来场景变复杂了。模型调用的不只是函数，还可能是浏览器、数据库、Git、代码执行器、文件系统、搜索工具。
所以大家越来越常说 Tool Calling。
我的理解是：
- Function Calling 是早期说法，范围窄一点
- Tool Calling 是现在更常用的说法，范围更大
底层思路很像，都是让模型用结构化参数去调用外部能力。
第二部分：Agent
4. Agent 和 Workflow 最大区别是什么？
我会先说结论：
Workflow 是固定路线，Agent 是边走边判断。
Workflow 像流水线：
A
-> B
-> C
-> 结束
每一步都提前写好了。
Agent 更像一个人做任务：
先看情况
-> 决定用哪个工具
-> 看结果
-> 再决定下一步
所以区别不是“Agent 会思考”这么简单，而是路径是不是固定。
如果任务很稳定，比如审批流、付款流、固定报表，我更愿意用 Workflow。因为它便宜、稳定、好测试。
如果任务路径不确定，比如修 bug、查资料、分析一个陌生仓库，这时候 Agent 更合适。
5. 为什么 LangGraph 火？
可以这么说：
因为大家发现两个极端都不好。
普通 Workflow 太死，路径写死了，遇到复杂情况不灵活。
纯 Agent 又太自由，模型想干嘛就干嘛，容易循环、乱调工具、成本失控。
LangGraph 做的是中间方案：用图来管住 Agent。
State：当前任务状态
Node：每一步做什么
Edge：下一步去哪
Conditional Edge：根据结果决定去哪
它的价值不是“看起来高级”，而是让 Agent 变得可控。
你可以让模型参与判断，但又不是完全放飞。出了问题，也能看清楚卡在哪个节点、哪个状态错了。
6. Reflection 是什么？
Reflection 说白了就是：AI 做完一步以后，回头检查自己。
写代码时特别好理解：
AI 写代码
-> 跑测试
-> 报错
-> AI 看错误
-> 再改
-> 再跑
这就是 Reflection。
它不是玄学，也不是“模型突然觉醒”。就是让 AI 根据执行结果修正自己。
但这里有坑。AI 有时会误读错误，然后越改越乱。
所以我一般会限制它：
- 先解释错误原因
- 每次只改一小块
- 连续失败几次就停
- 高风险文件人工确认
- 每次修改后看 diff
Reflection 有用，但不能无边界地让它自己循环。
第三部分：Context Engineering
7. Prompt Engineering 为什么没以前重要？
我不会说 Prompt 不重要。
更准确是：只靠一句 Prompt 越来越不够了。
以前大家很关注：
这句话怎么写，模型才听话？
现在更重要的是：
模型到底看到了什么信息？
这些信息准不准？
有没有过期？
有没有权限问题？
真正影响效果的东西包括：
- 项目规则
- 历史对话
- 用户偏好
- 检索到的知识
- 工具返回结果
- 当前任务状态
- 相关文件内容
Prompt 只是最后一句话。Context Engineering 是把这些信息组织好。
我会这样理解：
Prompt 是一句话怎么说；Context Engineering 是让模型在正确时间看到正确材料。
8. 什么叫 Context Window？为什么 100 万 context 也要做 RAG？
Context Window 就是模型一次能看到多少内容。
比如 128K、200K、100 万 token，说的都是这个窗口有多大。
但窗口大，不代表什么都应该塞进去。
原因很简单：
- 塞太多，贵
- 塞太多，慢
- 塞太多，模型也会抓不住重点
- 很多内容和当前问题无关
- 企业文档还有权限问题
所以就算有 100 万 context，RAG 还是有价值。
RAG 的作用不是只为了“塞不下”。它还负责：
- 找最相关的内容
- 过滤权限
- 保持知识更新
- 给答案加引用
- 减少无关噪音
我的判断是：长上下文会让一些简单 RAG 变少，但不会替代企业级 RAG。
第四部分：Vibe Coding
9. 什么叫 Vibe Coding？
我不会把 Vibe Coding 理解成“一句话生成网站”。
更准确地说，它是人和 AI 一起写项目：
人定方向
AI 写实现
人 review
AI 再改
人再验收
人不是甩手掌柜。人要负责判断方向、控制边界、验收结果。
AI 负责把很多具体实现跑出来。
所以真正的 Vibe Coding 不是一次生成，而是不断对齐。
你要不停告诉它：
- 这里不对
- 这个风格太模板
- 这个逻辑别改
- 这个文件不要碰
- 这一步先跑起来
这才是能落地的 Vibe Coding。
10. 平时怎么用 Vibe Coding？
我的做法一般不会让 AI 一次写一大坨。
我会这样做：
先讲目标
-> 让 AI 看项目结构
-> 确认技术栈和边界
-> 先做最小版本
-> 一个模块一个模块改
-> 每一步跑起来
-> 看 diff
-> 再继续
比如做一个新页面，我不会说“帮我做完整系统”。
我会先让它看现有页面怎么写，再让它只改一个页面。跑通以后，再补交互、补样式、补 SEO。
我的经验是：AI 最怕任务太大、边界太模糊。
边界越清楚，它越好用。
11. Claude Code 为什么体验好？
我不会只说“因为 Claude 模型强”。
模型强当然重要，但 Claude Code 体验好，更关键是它的工作循环像工程师。
读文件
-> 想方案
-> 改代码
-> 跑命令
-> 看结果
-> 继续修
它不是只给你一段代码，而是能围绕一个任务往前推进。
这也是 Coding Agent 和普通代码生成器的区别：
- 普通代码生成器：给你一段代码
- Coding Agent：读项目、改文件、跑检查、看失败、继续改
这个闭环才是体验好的核心。
12. Cursor 和 Claude Code 最大区别是什么？
我会这么说：
Cursor 更像“带 AI 的 IDE”。
Claude Code 更像“在终端里干活的 Agent”。
Cursor 适合你一边看代码一边改。它和编辑器贴得很近，适合日常写前端、改组件、补局部逻辑。
Claude Code 更适合把一个任务交给它推进。它会读文件、跑命令、看日志、改项目，系统权限和执行感更强。
简单讲：
- Cursor 更适合一起编辑
- Claude Code 更适合推进任务
当然边界不是绝对的，但使用感是这样。
第五部分：Coding Agent
13. AI 写代码最大的坑是什么？
最大的问题不是它写得丑。
最大的问题是：它会很自信地写错。
我见过的坑包括：
- 删了没让它删的代码
- 覆盖了用户已有改动
- 为了修一个 bug 改一大片
- 用了旧版本 API
- 编了一个不存在的方法
- 为了过类型检查绕开业务逻辑
- 没看项目结构，自己发明一套结构
所以我现在不会直接说：
Fix this
我更常说：
先别改代码。
先看相关文件和日志。
告诉我根因是什么。
再给最小修改方案。
这能少踩很多坑。
14. 什么时候不会相信 AI？
涉及钱、权限、数据、不可逆操作的时候，我不会直接信。
比如：
- 数据库迁移
- 删除数据
- 支付逻辑
- 登录鉴权
- 权限判断
- 生产部署
- 用户隐私
- 安全策略
这些地方 AI 可以帮我分析，也可以写草稿，但不能直接替我拍板。
我的原则很简单：
AI 可以帮我加速，但责任还是我承担。
所以高风险代码一定要自己 review。
15. AI 写 Bug 怎么定位？
我会先让 AI 进入诊断模式，不让它马上修。
我一般会这样说：
先不要改代码。
先读错误日志、相关文件和调用链。
请告诉我最可能的根因、证据、影响范围。
确认后再改。
为什么？
因为很多 AI 一看到 bug 就想动手改，结果越改越乱。
靠谱流程应该是：
复现
-> 看日志
-> 找调用链
-> 提假设
-> 验证假设
-> 最小修改
-> 跑测试
如果它连根因都说不清楚，我不会让它改代码。
第六部分：RAG
16. 企业有 500G 文档怎么办？
第一句我会说：不要全塞进模型。
500G 文档不是“塞进去”就完事了。真正要解决的是：用户问问题时，能不能找到最相关、最可信、他有权限看的那几段。
大致流程是：
整理数据源
-> 解析文档
-> 按结构切块
-> 做 Embedding
-> 存向量库
-> 混合检索
-> Rerank
-> 拼上下文
-> 让模型回答
-> 给引用
-> 做评估
这里最容易翻车的不是向量库，而是前面几步：
- PDF 解析乱
- 表格丢结构
- chunk 切错
- 权限没过滤
- 召回不准
- 答案没有引用
- 文档更新后索引没更新
如果候选人只说“Embedding + VectorDB”，我会觉得还停留在 demo。
17. Chunk 越大越好吗？
不是。
Chunk 太小，信息容易断。模型拿到一小段，可能不知道上下文。
Chunk 太大，检索又不准。命中了一个大块，里面大部分内容可能和问题没关系。
所以 chunk 不是越大越好，也不是越小越好，要看业务。
我会看几个东西：
- 文档本身有没有标题层级
- 用户一般问事实还是问流程
- 答案要不要精确引用
- rerank 能不能兜底
- 权限边界能不能切干净
一句话：
Chunk 的目标不是切得漂亮，而是让检索更容易找对答案。
第七部分：模型选择
18. 怎么选模型？
我不会说某个模型永远最强。
我会按任务选。
比如：
- 写代码，看仓库理解和改代码稳定性
- 做推理，看复杂问题能力和成本
- 看图片，看多模态能力
- 做 RAG，看引用、拒答和长上下文
- 做低成本任务，看价格、速度和稳定性
- 做企业项目，看合规、私有化和供应商风险
所以我更关心模型路由，而不是信仰某一家。
简单总结 -> 便宜快模型
复杂代码 -> 代码强模型
深度分析 -> 推理模型
截图理解 -> 多模态模型
企业私有数据 -> 合规和部署优先
真正做工程，模型选择是成本、质量、速度、风险一起算。
19. 怎么看 OpenRouter？
OpenRouter 的好处很直接：接一个入口，就能试很多模型。
适合这些场景：
- 快速原型
- 比较模型效果
- 做多模型 fallback
- 统一 billing
- 少写一堆供应商接入代码
但也不能只看优点。
如果是生产系统，我会注意：
- 稳定性是不是够
- 限流会不会变
- 路由是不是透明
- 模型版本是不是一致
- 数据合规能不能接受
- 出问题怎么 fallback
所以我的态度是：原型和评估很好用，生产要谨慎设计。
第八部分：最能看深度的一题
20. 请把 Prompt、Function Calling、Tool Calling、Skills、Workflow、MCP、Agent、Memory、Context Engineering 串起来
如果只能问一个问题，我会问这个。
因为它能看出候选人是不是只在背名词。
我希望他不要一个个解释定义，而是站在“我要开发一个 AI 应用”的角度，把整条链路讲清楚。
可以这么答：
假设用户说：
帮我分析这个客户最近的合同风险，并生成一份给销售看的摘要。
这个时候，最外层不是 Prompt，而是一个 AI 应用。应用先拿到用户请求，然后决定这件事要不要交给 Agent。
Agent 的作用是：围绕这个目标往前推进，而不是只回答一句话。
它大概会这样工作：
用户请求
-> Agent 理解目标
-> 构建 Context
-> 读取 Memory
-> 判断走 Workflow 还是动态决策
-> 调用工具
-> 观察结果
-> Reflection 检查
-> 返回结果
这里面每个概念都有位置。
Prompt 是最后给模型看的指令，但它不是全部。真正重要的是 Context Engineering。
Context Engineering 做的是：把模型这一步该看的东西准备好。比如用户的问题、当前业务规则、合同内容、历史对话、检索结果、工具返回结果、输出格式要求。
Memory 是其中一类上下文。它记录长期有用的信息，比如这个销售团队喜欢什么格式、这个客户以前有什么风险、公司内部对合同风险怎么分类。
Skills 更像能力包。比如“合同风险分析”“生成销售摘要”“导出 PDF”，这些都可以做成 Skill。它让 Agent 做某类任务时更稳，不用每次从零猜。
Workflow 是固定流程。如果合同风险分析每次都必须按：
读合同
-> 提取条款
-> 查风险规则
-> 生成摘要
-> 人工确认
那它就适合做成 Workflow。流程稳定，成本低，也好审计。
但如果中间情况不确定，比如合同里缺附件、客户历史资料不完整、需要临时查 CRM、还要判断要不要提醒法务，这时候就需要 Agent 动态决策。
Function Calling 和 Tool Calling 是模型调用外部能力的方式。
以前大家常说 Function Calling，因为看起来像调用一个函数。
现在说 Tool Calling 更多，因为工具不只是函数，还可能是数据库、浏览器、Git、文件系统、CRM、飞书、Notion。
MCP 则更像工具接入标准。Tool Calling 解决“模型怎么叫工具”，MCP 解决“这些工具怎么统一接进 AI 应用”。
所以在这个例子里，Agent 可能会通过 MCP 调一个合同库工具，再调一个 CRM 工具，再调一个文档生成工具。
调用完工具以后，Agent 不能直接把结果丢给用户。它还要做 Reflection。
Reflection 就是自己检查一遍：
- 有没有回答用户真正的问题？
- 引用的合同条款对不对？
- 有没有缺少关键风险？
- 结果能不能给销售直接看？
- 要不要让人确认？
最后，Agent 才把结果返回给用户。
所以我会把它们的关系总结成一句话：
Prompt 是指令，Context 是材料，Memory 是长期记忆，Skills 是能力包，Workflow 是固定流程，Agent 是动态执行者，Tool Calling 是调用工具的动作，MCP 是工具接入标准，Reflection 是做完以后回头检查。
如果一个候选人能这样串起来，我会觉得他是真的理解 AI 应用架构。
因为真实系统不是一堆概念堆在一起，而是一条任务链路：
用户要什么
-> AI 看到什么
-> AI 记得什么
-> AI 决定怎么做
-> AI 调什么工具
-> AI 怎么检查
-> AI 怎么交付结果
这比背十个定义有用得多。
第九部分：最有价值的经验题
21. 请讲一个你用 AI 提高开发效率的真实案例
这个问题不要空讲“AI 让我效率提升很多”。
可以按这个结构说：
我做了什么项目
原来哪里慢
AI 帮了哪一步
我怎么控制风险
最后怎么验证
比如我会这样讲：
我做一个旧项目页面改版时，不会让 AI 直接重写整个页面。我会先让它读现有组件和样式，再给我一个最小改动方案。确认以后，只让它改一个页面和少数相关组件。
每改一步，我会看 diff，跑 lint 或 build，再看页面效果。
AI 真正帮我省时间的地方不是“打字”，而是：
- 快速读旧代码
- 快速出第一版
- 快速补状态
- 快速找构建错误
- 快速整理说明
但最终的产品判断和验收，还是我来做。
22. AI 有没有坑过你？
这个问题一定要敢说“坑过”。
如果一个人说 AI 从来没坑过他，要么用得少，要么没认真 review。
我见过的坑包括：
- 它重构时删掉了不该删的代码
- 修一个功能时影响了别的模块
- 一本正经引用不存在的 API
- 按旧文档写了错误实现
- 一次改太多，后来定位不了问题
- 为了类型通过，牺牲了业务逻辑
所以我现在会这样用：
- 限制每次改动范围
- 先分析再修改
- 高风险文件单独确认
- 每一步看 diff
- 跑测试和构建
- 用 Git 小步保存
AI 会错很正常。关键是流程要能及时发现它错了。
23. 如果今天让你不用 AI 开发，你还能开发吗？
我不会回答“不能写代码”。
更成熟的回答是：
能开发，但我不会主动回到不用 AI 的低效率方式。
没有 AI，我还是能做需求拆解、架构设计、编码、调试、部署。
但效率会明显下降，尤其是：
- 读陌生代码
- 查冷门 API
- 写样板代码
- 补测试
- 整理文档
- 定位低级错误
所以 AI 不是替代我的基础能力，而是放大我的工程效率。
关键是我不能把判断权交出去。AI 可以帮我干活，但最后谁负责，还是我。
我怎么判断候选人是不是真用过 AI
真用过的人，回答里会自然出现这些东西：
- diff
- 小步修改
- 跑测试
- 看日志
- 读调用链
- 权限边界
- 上下文污染
- 工具失败
- 版本差异
- 幻觉 API
- 回滚
- 成本和延迟
只看新闻的人，通常只会说：
- 某模型很强
- 某工具很好用
- Agent 是未来
- MCP 是 USB-C
- Vibe Coding 很火
这些话没错，但太轻了。
真正的 AI 开发能力，是把一个不稳定但很强的东西，用流程、工具、验证和边界，变成可靠生产力。
参考来源
这些来源用于校准概念边界，不代表文章只是在复述文档：