小红书 AI 应用开发工程师面经 | 面经

小红书 AI 应用开发工程师

面试时间

2026_0618-16:00

面试内容

自我介绍
详细讲一下快手的实习经历
罚单低代码平台大概节约了多少运营人力？运营的人工成本有统计过吗？
讲一下实习中的自主研发 MCP
在你的认知里面，MCP 跟传统 API 有什么区别？
MCP 之前是怎么实现和 AI 调用外部工具的？了解吗？
这边有个指标要显著降低：产研沟通与代码维护成本。有具体的数据吗？（面试官非常在意数据的值）
除了接需求，有需求过来我就做，有没有去思考过，现在做的一些东西的价值是什么？为什么要做这些？
Skill 和 MCP 的区别
AST 静态分析，还有提到 Sub-Agent 隔离，Sub-Agent 的隔离机制是什么？
一般什么情况下应用设计会用到多个 Sub-Agent？
快手那边有沉淀一些 workflow 相关的东西吗？
之前公司已经有大量基建设施，现在离开了，你怎么把那些好用的东西沉淀下来给自己用？
你怎么理解 AI 应用开发工程师？
反问
业务方向：商业化、广告投放竞价、对内维护代理商相关系统
怎么更好地把好用的基础设施沉淀给自己？（面试官回答类似于国内 AI 蒸馏国外模型）

面试复盘总结

这场面试和普通前端面试不太一样，面试官并不只是问“你做了什么功能”，而是一直在追问三个东西：

价值是否可量化：有没有人力节省、沟通成本下降、维护成本下降的数据。
技术边界是否清楚：MCP、传统 API、Skill、Workflow、Sub-Agent 分别解决什么问题。
工程抽象是否能迁移：离开公司内部基建之后，能不能把方法论和基础设施沉淀成自己的工具链。

1) 项目价值要从“做了什么”升级到“改变了什么”（Q3, Q7, Q8）

这场面试里，面试官非常在意具体数字。比如：

罚单低代码平台节约了多少运营人力？
产研沟通成本到底下降了多少？
代码维护成本有没有量化？
为什么这件事情值得做，而不是“有需求来了我就接”？

如果没有提前准备数据，很容易只能回答“提升了效率”“降低了成本”，但这类表达太虚。

更好的回答方式是把项目价值拆成 基线、动作、指标、结果 四层。

业务基线：原来一个罚单配置需要运营提需求、产品确认、研发排期、前端改代码、测试回归、上线。
技术动作：把罚单配置抽象成 Schema，运营或产品可以通过低代码平台配置表单、校验和联动规则。
衡量指标：配置周期、研发介入次数、回归成本、线上变更频率、重复代码量。
业务结果：需求交付从“按天/按周排期”变成“配置后即时生效”，研发从重复 UI 表单开发里释放出来。

如果真实项目没有完整埋点，也可以诚实说明“当时没有做严格统计”，但要补上估算口径：

当时没有做非常严格的人力成本统计，这是我复盘后觉得可以补强的地方。但如果用配置链路来估算，过去一个新增罚单类型通常需要前端介入开发和回归，现在如果字段、校验和联动都能通过 Schema 配置完成，研发侧至少可以减少重复表单开发和测试回归成本。更准确的量化方式应该是统计平台上线前后：单个罚单模板配置耗时、研发介入次数、需求交付周期和线上变更次数。

面试里不要只讲“我做了一个平台”，要讲“这个平台让谁少做了什么，让什么流程变短了，让什么风险变低了”。

2) MCP 和传统 API 的区别（Q4-Q6）

传统 API 更像是给确定性程序调用的接口：调用方知道 endpoint、参数、返回值，然后按固定逻辑完成业务。

MCP 更像是给 AI Agent 使用的 工具上下文协议。它不只是暴露一个接口，而是把工具、资源、能力描述、参数 Schema、调用方式和返回结果统一包装，让模型能理解“有哪些工具可以用、什么时候用、怎么用”。

可以从四个维度回答：

维度	传统 API	MCP
调用主体	人写的确定性程序	AI Agent / LLM 驱动的应用
关注点	endpoint、参数、鉴权、响应	工具发现、能力描述、参数 Schema、上下文注入
使用方式	代码里显式调用	模型根据任务语义选择工具
核心价值	连接系统	让模型安全、标准化地连接外部世界

MCP 之前，AI 调外部工具通常有几种做法：

Function Calling / Tool Calling：在模型请求里声明工具 Schema，模型输出结构化调用参数，业务层再执行工具。
插件机制：平台提供插件市场或固定插件接口，模型可以调用搜索、浏览器、数据库等外部能力。
Prompt + 约定格式：让模型按 JSON 格式输出“要调用哪个工具”，应用层解析后执行。这种方案灵活但脆弱。
RAG + 检索服务：模型不直接调用任意工具，而是通过检索服务拿知识，再生成答案。

MCP 的价值在于把这些外部能力的接入方式标准化，让工具不再是某个应用内部的临时 glue code，而是可以复用、可发现、可治理的能力单元。

3) Skill 和 MCP 的区别（Q9）

Skill 和 MCP 很容易混在一起，但它们解决的问题不同。

Skill 更偏“怎么做”：它是一套任务执行说明、领域知识、工作流约束和最佳实践。比如写博客的 Skill 会告诉 Agent frontmatter 怎么写、文件放哪里、检查命令是什么。

MCP 更偏“能调用什么”：它是工具和资源的协议层，告诉 Agent 可以读哪些资源、调用哪些工具、工具参数是什么。

可以这样总结：

Skill = 任务方法论 + 领域操作手册
MCP = 工具连接协议 + 外部能力接口
Workflow = 把 Skill 和 MCP 组织成稳定流程

举个例子：如果我要让 AI 帮我生成一篇博客文章：

Skill 告诉 AI：文章结构、分类规则、frontmatter、检查流程。
MCP 提供能力：读取文件、查询资料、写入内容、运行检查。
Workflow 编排过程：收集信息 -> 生成草稿 -> 写入文件 -> lint -> 预览。

4) Sub-Agent 隔离机制是什么？什么时候需要多个 Sub-Agent？（Q10-Q11）

Sub-Agent 的本质不是“多开几个聊天窗口”，而是把复杂任务拆成多个具有独立上下文、独立职责和独立输出边界的执行单元。

隔离通常体现在几个层面：

上下文隔离：每个 Sub-Agent 只拿到完成当前子任务需要的上下文，避免主上下文被无关信息污染。
权限隔离：不同 Sub-Agent 可以只开放不同工具，比如研究 Agent 只能读，执行 Agent 才能改文件。
任务隔离：一个 Agent 做需求拆解，一个做代码实现，一个做测试验证，避免单个 Agent 在复杂任务里目标漂移。
输出隔离：每个 Agent 产出结构化结果，由主 Agent 汇总判断，而不是所有中间推理混在一起。
失败隔离：某个子任务失败，不会直接污染整体执行链路，可以重试或替换该子任务。

什么时候需要多个 Sub-Agent？

任务复杂、上下文很长，比如大型重构、跨模块排查。
任务天然有不同角色，比如架构设计、代码实现、测试审查、安全审查。
需要并行研究多个方案，比如对比不同库、不同技术路线。
需要降低上下文污染，比如让一个 Agent 专门读日志，另一个 Agent 专门改代码。
需要更强的验证闭环，比如实现 Agent 完成后，交给 Review Agent 从缺陷角度检查。

面试表达可以这样说：

我理解 Sub-Agent 的价值主要是上下文治理和职责隔离。比如一个复杂 AI 应用里，如果既要检索资料、又要改代码、还要做安全审查，把所有东西塞给一个 Agent，容易出现上下文污染和目标漂移。拆成多个 Sub-Agent 后，每个 Agent 只处理局部任务，主 Agent 负责计划、汇总和决策，这样更像一个可控的软件工程流水线。

5) Workflow 沉淀和个人基础设施迁移（Q12-Q13, Q17）

面试官追问“离开公司后怎么把好用的基础设施沉淀给自己”，其实是在看你有没有把公司经验抽象成可迁移能力。

公司内部的基建不一定能带走，但可以沉淀下面这些东西：

规范：需求文档模板、代码评审清单、发布检查清单、AI 使用边界。
流程：需求澄清 -> 方案设计 -> 任务拆解 -> 实现 -> 自动验证 -> 复盘。
工具：个人 MCP Server、脚手架、代码生成器、lint 规则、文档生成工具。
数据集：脱敏后的案例、常见问题、Prompt 模板、最佳实践。
评估方法：用交付周期、缺陷率、返工次数、自动化覆盖率来判断工具是否真的有价值。

可以用“蒸馏”的类比回答：

公司基建本身不能直接带走，但背后的模式可以迁移。就像模型蒸馏不是复制大模型参数，而是学习它解决问题的能力。我会把公司里好用的流程抽象成个人可执行的 Skill、模板和 Workflow，再用个人 MCP Server 接入本地文件、博客、项目脚手架和常用命令。这样沉淀下来的不是某个内部系统，而是一套可持续复用的个人研发操作系统。

6) 怎么理解 AI 应用开发工程师？（Q14）

AI 应用开发工程师不是单纯“会调大模型 API 的前端”，也不是只写 Prompt 的岗位。它更像是把模型能力接到真实业务流程里的工程角色。

我会从四个能力层回答：

业务建模能力：理解业务流程，知道哪些环节适合 AI，哪些环节必须保留人工确认。
应用工程能力：能做前端交互、后端服务、权限、日志、监控、灰度、数据回流。
Agent 工程能力：理解 Tool Calling、MCP、RAG、Workflow、Memory、Sub-Agent、上下文治理。
评估与迭代能力：不能只看 demo 效果，要定义成功率、召回率、人工接管率、响应时延、成本等指标。

一个比较完整的回答：

我理解 AI 应用开发工程师的核心职责，是把不稳定但强大的模型能力，封装成稳定、可评估、可接入业务流程的产品能力。它需要既懂业务场景，也懂工程落地，还要懂 Agent、RAG、MCP、Workflow 这些 AI 原生架构。最终交付的不是一个能聊天的 demo，而是一个能降低成本、提升效率、可观测、可迭代的业务系统。

7) 这场面试的复盘重点

这场最应该补强的是 数据意识。

以后讲项目时，建议提前准备一张“项目价值卡片”：

项目	原始痛点	我的方案	量化指标	结果
罚单低代码平台	重复表单开发、运营配置依赖研发	Schema 表单 + 联动规则 + 配置化渲染	单模板交付周期、研发介入次数、回归次数	降低重复研发与沟通成本
MCP Server	AI 缺少稳定外部工具上下文	工具协议封装 + 组件文档/AST 能力接入	文档查询耗时、组件接入耗时、生成准确率	提升 AI 辅助研发可用性
AI Workflow	需求到代码链路不稳定	Skill + MCP + 自动检查	返工次数、lint/check 通过率、交付时间	提升交付稳定性

面试里可以没有绝对精确的数据，但不能没有指标口径。真正打动面试官的不是“我做过 AI”，而是“我知道 AI 应该在哪个业务环节创造价值，并且知道怎么证明它真的创造了价值”。