12. 面试表达模板
十二、面试表达模板¶
脑子里有很多东西，一开口就散。这一章不提供”万能话术”，而是把几个最常见的问题压成稳定说法，回答时始终先讲问题、再讲链路、再讲取舍与排查，不被组件名和热词带着跑。
回答问题时先稳住主线¶
大多数工程题收敛到同一个回答顺序。先说业务目标和约束：要解决什么问题、谁在用、最重要的成功标准是什么。再说主链路：一次请求从入口到出口怎么走。接着挑两到四个核心设计点展开，例如权限、状态、检索、工具边界、异步任务、流式返回。最后补风险、监控、评测和演进方向。回答时不会掉进组件名和框架名里，而是先让面试官确认在解决一个真实业务问题。
固定的起手式：先讲这个系统要解决什么问题和约束，再讲一次请求怎么走，然后展开几个关键设计点，最后补失败风险、观测和评测。表达从”零散知识点堆叠”拉回”工程叙事”。
面试官往机制层追时，同一条主线上固定补七件事：模块在解决什么系统问题，最小机制是什么，关键参数或结构是什么，工程上最小怎么实现，常见调优抓手是什么，最常见的失效模式和排查顺序是什么，什么条件下要切到别的方案。回答从”我会用这个技术”落到”我知道它为什么成立、什么时候失效、为什么这里先选它”。
回答”你如何理解 AI 应用”¶
把 AI 应用理解成一种多了模型推理环节的后端系统。它和传统后端一样，都要处理请求链路、权限、超时、重试、观测和成本，中间多了一个概率型、不完全可信的模型节点。节点不稳定时，系统不靠 prompt，而靠结构化输出、工具治理、服务端校验、评测和 trace 一起把风险收住。AI 应用真正难的不是让模型说话，而是把模型能力收进一个可控、可观测、可审计的业务系统。
回答”你为什么适合这个岗位”¶
最稳的答法不是把自己包装成”什么都会”，而是把能力结构讲清楚。底层能力是 Go 后端工程，包括 HTTP 服务、数据库、并发、资源控制、排障和工程化。这一层保证请求生命周期、状态边界、超时取消和可观测性先做好。在此基础上，系统补 AI 应用侧的结构化输出、RAG、Tool Calling、流式接口、评测和安全。关注点是把模型能力稳定接进业务系统，不只在 demo 层面跑起来。回答时既没有把自己说成纯模型方向，也没有让人觉得只会写传统接口。
回答”为什么不直接用 Gin / 为什么先学底层”¶
这题考的是有没有底层心智。Gin 在项目里完全可以用，练手项目也不排斥，它的价值是提高路由、中间件和参数处理的开发效率。从学习和面试准备角度，先理解 net/http 更重要。请求生命周期、中间件模型、Request.Context() 传播、流式响应和取消机制这些核心问题不是 Gin 专属能力。框架把底层模型包装得更顺手，没有改变它们本身。先把底层理解清楚，再用 Gin，很多行为能解释得明白，也不容易在 SSE、优雅退出、断连取消这些问题上发虚。
回答”RAG 或 Tool Calling 最核心的点是什么”¶
问 RAG 时不从向量库开始。默认回答：RAG 最核心的不是选一个最炫的向量库，而是把文档清洗、切块、召回、过滤、引用和更新机制做成完整链路。真正决定效果下限的，往往是前半段数据链路，不是最后一次生成。切块切散了、权限过滤没做对、旧版本没失效，模型再强也只能在错误材料上做合理发挥。
问 Tool Calling 时不停在”让模型调函数”。更成熟的说法：Tool Calling 的核心是让模型负责提出结构化调用建议，让服务端继续用 schema、鉴权、超时、幂等、循环限制和审计去控制真实执行。只读工具、低风险写工具和高风险写工具分层治理。真正高风险的动作引入审批和人工确认。回答不是在讲一个模型功能，而是在讲一条后端执行链路。
回答”为什么选这个技术，而不是别的”¶
这类题最怕答成”我比较熟””社区用得多”。更成熟的顺序通常是四步。先讲面对的系统问题，例如高并发检索、长任务运行时、强过滤检索或多工具治理。再讲候选方案在这一层的关键差异，例如 pgvector 和独立向量库、ReAct 和工作流、BM25 和纯 dense retrieval、SSE 和 WebSocket。然后给出当前默认方案和原因，落到数据规模、更新频率、权限边界、团队复杂度、时延预算这类约束。最后补切换条件，说明”如果规模、复杂度或风险继续上升，会在哪个点切到更重的方案”。回答不是技术偏好，而是工程判断。
技术选型题固定成一句口头模板：先看系统压力来自哪一层，再比较几个同层方案的机制差异，然后说明为什么当前阶段先选这个，最后补如果指标或约束变化，会在哪个信号点切换方案。这个模板对数据库、检索、Agent 范式、缓存策略和工具接入都适用。
如何讲 QPS、延迟、数据规模、瓶颈和优化¶
项目介绍一到这类追问容易发虚。默认回答顺序是：先给规模，再报目标，再讲瓶颈，再讲优化，再讲结果。规模至少包括请求量级、数据规模、索引规模、任务规模或对象规模。目标至少包括 P95 或 P99 延迟、成功率、任务完成时长、成本预算。瓶颈明确在解析、数据库、检索、模型、工具、网络还是流式写回。优化对应瓶颈，不报一串和问题没关系的手段。结果有前后对比，不是一句”提升很多”。
问答链路在高峰期 QPS 大概是多少，知识库文档量和 chunk 量级大概是多少，P95 目标是多少。一开始主要瓶颈在 rerank 和模型阶段，或在解析任务把数据库连接池占满。后面做了哪些优化，例如把 OCR 和 embedding 拆出同步请求、对 query 做缓存、限制 rerank 只对部分 query 开、调小数据库事务边界、把长任务改成后台执行。优化后 P95 从多少降到多少、错误率或成本又下降了多少。面试官更容易判断不是在描述功能，而是在描述一条真实的工程链。
真正成熟的表达主动补一层”为什么知道这招有效”。不是只说”调了 rerank 候选集”，而是补一句”trace 显示主要慢在 rerank，且离线评测表明 Top-50 到 Top-20 几乎不掉 Recall@K，但时延显著下降”。不是只说”调了数据库连接池”，而是补一句”DB.Stats().WaitCount 在高峰期持续上涨，但数据库 CPU 并不高，说明问题主要是应用侧排队”。这类表达让面试官更容易相信看过机制，不是只会描述结果。
把调研结论转成面试输出¶
开源项目拆解和深度专题不停在”我读过”。面试里更有用的表达是把项目里的设计对象翻译成自己的工程判断。读 pgvector 时，不说它支持向量索引，而是说第一版企业知识库可以先把业务元数据、权限过滤和 embedding 放在同一个 Postgres 里，减少系统数量；等数据量、召回时延或多租户隔离压力上来，再评估独立向量库。回答直接连到 RAG 的过滤前置、版本治理和低复杂度路线。
读 MCP 时不背 client/server。MCP 解决的是工具接入协议统一，不替代权限系统。宿主应用仍然要先判断用户、租户、工具白名单和风险等级，再让 MCP client 建连、发现能力、发起调用并标准化结果。面试官会听到把协议互通和执行治理分开了。
读 Eino 或 LangGraph 时，不把回答做成框架横评。任务路径固定时，先用普通 workflow。中间观察会改变下一步时，才把状态、checkpoint、interrupt 和 callback 抬成运行时对象。Go 宿主服务更看重类型边界、并发控制和已有工程栈时，优先看 Eino。恢复、人工插入点和状态图是核心问题时，再看 LangGraph。比说”哪个框架更强”更像工程答案。