小红书 后端 日常一面

《面试题目》

1. 自我介绍
2. 着重讲今年这段实习经历
3. 开发过程中借助 AI 工具，有没有遇到 AI 都解决不了的问题？
4. 这个项目里主力用的 AI 编程工具和模型是什么？
5. 有大概的 token 使用量预估吗？
6. 用 V3 和现在 V4 的体感有什么区别？
7. 今年有在用别的模型吗？Claude 或者 GPT？
8. 现在 AI 编码工具还支撑不了一些业务边界，要让 AI 工具支撑这些边界，需要额外做什么？
9. 从出码后的验证这个环节再说说有什么可以沟通的地方
10. 现在的很多工具都有自主校验能力，比如 Codex，它有这个能力吗？
11. 有个名词叫 computer use，这个能力有了解过吗？（它可以自主启动浏览器，完成点击操作与校验）
12. 对 Agent 底层知识的学习，还有 Tool Calling 和 MCP 的开发，展开讲一下具体做了什么
13. Skill 的「渐进式披露」这个概念了解吗？
14. 它解决了什么问题？
15. 上下文快超出限制时，编码工具会发生压缩，这个机制了解吗？
16. 反问

《参考解析》

「AI 都解决不了的问题」怎么答：这道题考的是你有没有真的深度用过 AI。可靠的答案通常落在三类：一是跨系统的语义与约束（业务规则散落在多个服务、文档和口头约定里，模型拿不到完整上下文，改出来的代码在单测里对、到线上就错）；二是需要运行环境反馈的问题（只在特定数据或特定并发下才出现的 bug，模型无法复现）；三是需要承担判断与责任的决策（取舍方案、影响面评估、上线风险）。答的时候要带上自己的应对方式：把隐性知识显式化成文档与规则文件、把验证自动化（能跑的测试、能看的日志）、把方案设计留在人这一侧。

业务边界怎么让 AI 撑住：这句追问的落点是「上下文工程 + 验收自动化」。上下文侧：把仓库约定、目录结构、架构说明写进规则文件；一次只给它相关文件；用 MCP 把内部系统（工单、监控、数据库 schema）接进来，让它能取到真实信息。验收侧：把「怎么算做对了」变成可执行的检查（单测、类型检查、lint、接口契约测试、端到端脚本），让 AI 自己跑、自己修。再加一个「改动范围约束」——先约定要改哪些文件，diff 超出就中断交给人。本质上，模型能力之外的部分要靠工程把它围起来。

computer use 与自主校验：computer use 是让模型看屏幕截图（或 DOM / 无障碍树）并输出鼠标键盘动作，从而操作浏览器或桌面完成点击、填表、校验。它和 Playwright 这类基于选择器的自动化差别很大：Playwright 依赖稳定的选择器与脚本，快、可靠，但页面一改就断；computer use 靠视觉理解，能应对没写过脚本的界面与需要「看着判断」的任务（比如校验页面还原度），代价是慢、贵、且有不确定性，更适合兜底与探索而不是回归测试。Codex 这类工具的自主校验能力，本质上也是「给它一个能跑的环境 + 让它看结果」，能力边界还是在环境是否可复现。

Skill 与渐进式披露、上下文压缩：Skill 是把某类任务的步骤、脚本和参考资料打包成一个可复用的能力单元。渐进式披露指的是「先只把技能的元信息（名称、描述、何时使用）放进上下文，模型判断需要时再加载完整内容」，解决的是「能力越加越多、提示词无限膨胀」的问题——它让上下文消耗与技能数量解耦。上下文压缩（compaction）是当对话接近窗口上限时，把较早的对话总结成摘要并替换原文，只保留最近若干轮原文与关键事实；它的代价是信息损失，所以工程上会把重要约束、当前任务状态、待办写成结构化文件（而不是靠对话记忆），压缩后重新注入，从而降低丢失风险。这两点答清楚，基本就能证明你读过实现而不是只用过产品。

这一轮的特点：面试官明显是深度使用 AI 编程的人，追问的点全在「你踩过哪些坑、怎么解决」。准备这类面试最好的方式不是背概念，而是真的用一个 AI 编程工具做完一个完整项目：从需求到出码、验证、修 bug，把每一步的失败与绕法记下来——这些细节是背不出来的。作者提到「小红书确实不喜欢问八股（含前一篇跨境电商一面）」，可以看出这家公司的后端面试重心在工程实践与 AI 素养。