跳到主要内容

AI 应用开发面试题合集（全栈偏前端，160 题）

使用说明​

这套题面向“全栈偏前端”的 AI 应用开发岗位，重点不是背模型论文，而是说明你能把 AI 能力做成一个可靠、好用、可观测的产品。

回答结构统一为：

  1. 答案汇总：先用一句话回答本质。
  2. 分点展开：再说方案、取舍、异常和验证。

面试时不必逐字背诵。建议先讲结论，再结合自己做过的聊天、RAG、Copilot 或 Agent 项目补一个真实例子。

题目导航​

范围主题
Q1–Q10AI 产品与基础认知
Q11–Q20LLM API、AI SDK 与流式协议
Q21–Q30AI 前端交互与状态管理
Q31–Q40Prompt、上下文与推理模型
Q41–Q50结构化输出与工具调用
Q51–Q60RAG、Embedding 与向量检索
Q61–Q70Agent、MCP 与协议
Q71–Q80多模态与浏览器端 AI
Q81–Q90AI 安全、隐私与治理
Q91–Q100评测与可观测性
Q101–Q110性能、成本与模型部署
Q111–Q120综合系统设计与场景题
Q121–Q160AI 编程工具与工程实践

一、AI 产品与基础认知​

Q1：你如何向非技术同学解释大语言模型？​

答案汇总：大语言模型可以理解为一个根据上下文预测并生成内容的概率模型，擅长语言和模式任务，但不是事实数据库。

  • 它可以总结、抽取、改写、写代码和规划，但输出不天然等于事实。
  • 最新或私有数据要通过 RAG/工具提供，关键结果还要验证。
  • 产品设计要允许“不知道”、引用来源、纠错和转人工。

Q2：AI 应用和传统 Web 应用最大的工程差异是什么？​

答案汇总：传统程序主要是确定性逻辑，AI 应用多了概率性输出、长耗时生成和动态工具路径。

  • 除单元测试外，还需要代表性评测集、灰度和线上反馈闭环。
  • UI 要处理流式增量、取消、重试、部分成功和不确定性。
  • 权限和金额等规则仍由确定性后端负责，不能交给模型决定。

Q3：什么是 token，为什么前端开发者也要关心？​

答案汇总：token 是模型处理文本的基本计量单位，直接影响上下文上限、延迟、成本和截断行为。

  • 字符数不等于 token 数，不同语言和 Tokenizer 的比例不同。
  • 前端应限制附件和历史消息，展示超限提示并支持摘要/裁剪。
  • 服务端以真实 Tokenizer 或 Provider usage 作为最终计量依据。

Q4：Temperature 是什么，调低就不会产生幻觉吗？​

答案汇总：Temperature 主要控制采样随机性，调低可能让输出更稳定，但不能保证事实正确。

  • 知识缺失、错误上下文和错误工具结果不会靠低温度修复。
  • 事实任务应使用检索、工具、引用和确定性验证。
  • 部分推理模型不开放或弱化 Temperature，应按模型能力配置。

Q5：什么是上下文窗口？窗口越大越好吗？​

答案汇总：上下文窗口是一次请求可处理的 token 范围，更大提供更多信息，但不代表模型能同样准确地使用所有信息。

  • 长上下文会增加首包时间、成本和 KV Cache 压力。
  • 无关内容会稀释关键信息，甚至带入恶意指令。
  • 应用应做检索、去重、排序、摘要和重要信息固定位置设计。

Q6：什么是 AI 幻觉？工程上如何降低？​

答案汇总：幻觉是模型生成了听起来合理但没有可靠依据的内容，无法只靠一条 Prompt 消除。

  • 用 RAG/工具提供事实，并要求可定位引用。
  • 信息不足时允许拒答，不强迫模型“必须回答”。
  • 对金额、日期、权限、代码和引用做程序化验证。

Q7：什么时候不应该使用 LLM？​

答案汇总：规则明确、可确定计算或错误代价极高且无法复核的环节，不应把 LLM 当核心决策器。

  • 税费计算、权限判断、唯一 ID 校验优先普通代码。
  • 高频固定分类可先考虑规则或小模型，比较质量与成本。
  • LLM 可负责理解自然语言，但最终动作仍通过受控业务接口。

Q8：如何选择一个模型，而不是只选“最强模型”？​

答案汇总：先按任务定义质量、延迟、成本、上下文和合规门槛，再用自己的评测集选模型和路由策略。

  • 简单抽取、复杂推理、多模态和长上下文可以使用不同能力角色。
  • 在真实输入长度、并发和目标地区压测，不能只看公开榜单。
  • 保留 Provider 适配层和回退方案，避免在业务代码写死模型名。

Q9：AI 产品的 MVP 应该验证什么？​

答案汇总：MVP 首先验证用户任务是否真的被更好地完成，而不是展示模型能聊天。

  • 选择高频、边界清晰、结果可验证的任务。
  • 记录任务完成率、人工修正、延迟和每次成功任务成本。
  • 先把失败和转人工做完整，再扩大自动化范围。

Q10：AI 功能为什么需要设计降级？​

答案汇总：模型服务存在限流、延迟、质量漂移和区域故障，降级能保护核心业务和用户信任。

  • 可切换小模型、非流式模式、缓存答案、搜索结果或人工流程。
  • 明确告诉用户当前能力受限，不伪装成正常生成。
  • 降级策略按功能和风险制定，高风险动作宁可拒绝也不猜。

二、LLM API、AI SDK 与流式协议​

Q11：Chat Completions 和 Responses 风格 API 有什么差异？​

答案汇总：前者以消息补全为中心，后者通常把文本、工具、多模态和状态组织成更统一的响应项与事件。

  • 老项目不必立刻重写，但新能力应优先评估 Provider 推荐的新接口。
  • 在服务层规范化输入、输出、usage、错误和流事件。
  • 不让前端依赖某个 Provider 的原始响应结构。

Q12：为什么 AI 聊天通常使用流式响应？​

答案汇总：生成可能持续数秒到数分钟，流式能更早给用户反馈，并支持工具状态和取消。

  • 核心体验指标是首个有用事件时间，而不只是总耗时。
  • 流中可能包含文本、推理摘要、工具调用、引用、usage 和错误。
  • 数据库应在完成或可恢复节点落盘，不能每个 token 写一次。

Q13：SSE、WebSocket 和普通 HTTP 流怎么选？​

答案汇总：单次请求的服务端单向增量优先 SSE/HTTP 流；需要长期双向实时通道时再考虑 WebSocket。

  • SSE 语义简单，容易穿过常见网关并支持事件类型。
  • WebSocket 适合语音、协作和持续双向控制，但重连与扩缩更复杂。
  • 无论协议都要定义事件 ID、完成、错误、取消和重连语义。

Q14：流式响应如何避免中文乱码和 JSON 被截断？​

答案汇总：把字节解码、事件分帧和业务 JSON 解析分成三层，不能把每个网络 chunk 当成完整字符串或 JSON。

  • 使用支持增量 UTF-8 的 TextDecoderStream 或保持 decoder 状态。
  • 先按 SSE/NDJSON 协议组装完整事件，再 JSON.parse。
  • 最后一帧也可能不完整，结束时检查缓冲区和协议终止事件。

Q15：AI SDK 在项目里解决什么问题？​

答案汇总：AI SDK 抽象多 Provider 的生成、流式、工具和 UI 消息协议，减少业务直接处理底层差异。

  • 仍需理解 Provider 能力和限制，抽象不意味着所有模型行为一致。
  • 业务域类型、权限和持久化应放在自己的服务层。
  • 升级 SDK 时用契约测试验证流事件、工具和序列化变化。

Q16：如何设计统一的模型 Provider 适配层？​

答案汇总：按能力而不是模型名称抽象，统一请求、内容块、错误、usage 和取消，同时保留 Provider 扩展字段。

  • 定义 chat、tools、vision、reasoning、JSON Schema 等能力声明。
  • 将认证、超时、重试、限流和可观测性放在网关/适配层。
  • 不支持的能力要显式拒绝或路由，不能静默忽略参数。

Q17：模型 API 的重试应该怎么做？​

答案汇总：只对临时且幂等的失败做有限指数退避，并尊重 Provider 的重试时间。

  • 429、部分 5xx 和网络失败可候选重试；参数错误和安全拒绝不应重试。
  • 工具写操作必须有幂等键，避免生成重试导致重复下单。
  • 流已经向用户输出后，自动重试可能产生重复文本，应转为恢复或重新生成。

Q18：如何处理请求取消？​

答案汇总：前端的取消要通过 AbortSignal 传播到 BFF、模型请求和正在运行的工具。

  • UI 把消息标为 aborted，保留已生成内容并允许重试。
  • 服务端监听连接关闭，释放流、队列和计算资源。
  • 不可取消的副作用工具要返回真实执行状态，不能显示成“已取消”。

Q19：为什么 API Key 不能放在浏览器？​

答案汇总：浏览器代码和网络请求对用户可见，密钥会被窃取并绕过服务端配额、审计和数据策略。

  • 浏览器只调用自己的 BFF，使用用户会话鉴权。
  • BFF 保存 Provider 密钥并做限流、模型路由和日志脱敏。
  • 若 Provider 支持临时凭证，也要限定用户、能力、时效和额度。

Q20：如何处理模型输出的 Usage 与费用？​

答案汇总：以 Provider 返回的真实 usage 为主，按模型版本和计费项归集到请求、用户、功能和租户。

  • 区分输入、缓存输入、输出、推理和工具等可能计费项。
  • 流式 usage 可能在结束事件才出现，异常中断要允许估算并标记。
  • 业务指标看“每个成功任务成本”，而不是孤立的 token 单价。

三、AI 前端交互与状态管理​

Q21：AI 聊天页面至少有哪些状态？​

答案汇总：至少区分 submitted、streaming、tool-running、completed、aborted 和 failed，复杂任务还要有 approval-required。

  • 不要用一个 isLoading 表示所有过程，否则无法正确取消和恢复。
  • 消息本身也要保存状态、内容块、错误、usage 和关联请求 ID。
  • 按状态显示真实操作：停止、重试、审批、继续或转后台。

Q22：为什么不建议只存一段 message.content 字符串？​

答案汇总：现代 AI 消息包含文本、图片、引用、推理摘要、工具调用和结果，应该用有类型的 parts 表达。

  • React 根据 part 类型渲染白名单组件，避免解析模型生成的 HTML。
  • 工具调用和结果通过稳定 call ID 关联。
  • 持久化时保存协议版本，方便将来迁移消息结构。

Q23：流式文本为什么容易造成页面卡顿？​

答案汇总：每个 token 都触发 React 状态更新、Markdown 全量解析和布局，会产生大量渲染工作。

  • 按时间片或 requestAnimationFrame 合并增量，而不是逐 token setState。
  • 只更新最后一条消息，已完成内容做 memo。
  • 长消息可延迟语法高亮、虚拟化列表并减少自动滚动测量。

Q24：聊天自动滚动怎么做才不打扰用户？​

答案汇总：只有用户本来接近底部时才跟随新内容；用户向上阅读后暂停自动滚动。

  • 用哨兵元素和 IntersectionObserver 判断是否在底部。
  • 显示“有新内容/回到底部”按钮，而不是强制拉回。
  • 工具卡展开、图片加载等布局变化也要遵守这个规则。

Q25：如何安全渲染模型生成的 Markdown？​

答案汇总：使用安全 Markdown 解析器和白名单，默认禁用原始 HTML，并对链接、代码和图片做额外约束。

  • 阻止 javascript:、危险 data URL、事件属性和未知 iframe。
  • 外链可增加安全属性和跳转提示，图片可走可信代理。
  • 不能因为内容经过模型生成，就把它当可信前端代码。

Q26：AI 消息如何持久化？​

答案汇总：持久化用户消息、最终或可恢复的 assistant parts、状态、协议版本和服务端生成的 ID。

  • 用户消息先落库，模型输出按批次或完成事件落库。
  • 客户端临时 ID 与服务端 ID 映射，重试使用幂等键。
  • 工具副作用和消息记录分开建事务/状态机，不能只靠聊天文本恢复。

Q27：断网后如何恢复流式对话？​

答案汇总：恢复依赖服务端任务状态和事件游标，而不是要求模型从中断 token 继续。

  • 短请求可显示中断并允许重新生成。
  • 长任务保存事件和 last-event ID，客户端重连后补拉。
  • 若后台任务已完成，直接获取最终消息并去重，不重复执行工具。

Q28：如何设计工具调用审批 UI？​

答案汇总：审批卡要展示工具、目标资源、关键参数、可能副作用和可撤销性，用户批准的是精确动作。

  • 高风险参数用结构化 Diff 展示，敏感值按权限遮盖。
  • 批准凭证绑定用户、call ID、参数哈希和短有效期。
  • 拒绝后把原因作为受控结果返回 Agent，而不是直接让流程失联。

Q29：AI 生成 UI 应该让模型直接输出 JSX 吗？​

答案汇总：生产场景更适合让模型输出受约束的 UI Schema，再映射到白名单组件，而不是执行任意 JSX。

  • Schema 校验组件类型、props、嵌套深度和数据引用。
  • 事件只能映射到预注册 action，不能执行模型生成脚本。
  • 未知组件显示可恢复占位，并记录版本兼容问题。

Q30：如何做 AI 聊天的无障碍体验？​

答案汇总：保证键盘、焦点、状态提示和流式内容对辅助技术可用，同时避免逐 token 高频播报。

  • 提交后把焦点留在输入区或移动到明确状态区域。
  • 使用节流的 aria-live 摘要，完成后再播报完整结果。
  • 停止、重试、复制、引用和审批按钮都有可理解标签与焦点样式。

四、Prompt、上下文与推理模型​

Q31：一个好的 Prompt 通常包含哪些部分？​

答案汇总：好的 Prompt 会明确目标、输入、约束、输出格式、边界情况和成功标准，而不是堆叠夸张角色设定。

  • 把指令与用户数据/检索内容用结构和标签分开。
  • 给少量高质量示例说明难以文字描述的边界。
  • 对“不知道怎么办”和“禁止做什么”给出明确规则。

Q32：System Prompt 的优先级高，是否等于安全边界？​

答案汇总：不是。System Prompt 能影响模型行为，但不能替代后端权限、参数校验和数据隔离。

  • 用户和外部内容仍可能通过 Prompt Injection 影响模型。
  • 工具服务必须根据真实会话鉴权，不能相信模型声称的身份。
  • 敏感信息不应仅靠“不要泄露”放在 Prompt 中保护。

Q33：Few-shot 示例有什么用，怎么选？​

答案汇总：Few-shot 用具体样本定义任务模式、格式和边界，应该少而有代表性。

  • 覆盖正常、无答案、冲突和易错样本，而不是重复同一模式。
  • 示例中的错误和偏见会被模型模仿，要纳入版本评审。
  • 示例过多会占上下文，应通过 Eval 判断增益。

Q34：什么是上下文工程？​

答案汇总：上下文工程是为一次模型调用选择、组织和管理最有用信息，包括指令、历史、检索、工具和状态。

  • 目标是高信号密度，不是把所有数据都塞进去。
  • 需要处理排序、去重、权限、摘要、缓存和 token 预算。
  • 对 Agent 还要管理任务状态、工具结果和长期记忆。

Q35：多轮聊天历史过长怎么办？​

答案汇总：保留最近交互和关键事实，把更早内容结构化摘要或按需检索，同时允许用户查看和纠正记忆。

  • 系统/安全约束不能被摘要掉，应独立维护。
  • 工具结果保留可验证 ID 和状态，不只保留自然语言摘要。
  • 摘要也会出错，重要用户偏好和承诺应结构化存储。

Q36：Prompt 版本如何管理？​

答案汇总：把 Prompt 当代码制品，使用稳定 ID、版本、评测、审批和回滚，而不是在线随手改字符串。

  • 记录模板、变量 Schema、模型能力和依赖数据源。
  • 每次改动跑离线回归，再灰度观察线上指标。
  • Trace 记录 Prompt 版本而非默认保存完整敏感内容。

Q37：推理模型和普通聊天模型怎么选？​

答案汇总：复杂代码、规划和多约束任务可能受益于更多测试时计算，简单抽取和改写优先低延迟模型。

  • 用评测比较不同 reasoning effort 的质量、延迟和成本曲线。
  • 缺少事实时仍要检索/工具，想得更久不会产生真实数据。
  • 高风险结论无论用什么模型都需要规则或人工验证。

Q38：是否应该要求模型展示完整思维链？​

答案汇总：不应把完整内部思维链作为产品依赖，应要求简洁结论、证据和可验证步骤。

  • 原始隐藏推理通常不会由 API 提供，也不等同于可靠解释。
  • 可展示 Provider 提供的推理摘要，但要明确它是摘要。
  • 调试重点看输入、工具轨迹、证据和最终不变量。

Q39：如何设置推理预算？​

答案汇总：按任务复杂度和风险路由 effort/budget，并设置时间、token、步骤和费用上限。

  • 分类、改写使用低档；复杂 Debug/规划再提高。
  • 监测额外推理是否减少重试并提升最终成功率。
  • 超预算时返回部分结果、请求澄清或转后台，而不是无限等待。

Q40：为什么 Prompt 改得更长，效果可能反而变差？​

答案汇总：更长 Prompt 可能包含冲突、冗余和低优先级细节，稀释真正约束并增加成本。

  • 将规则拆成必需约束、可选偏好和外部数据。
  • 删除重复语句，用 Schema 和代码替代可确定规则。
  • 用失败样本回归验证，不按 Prompt 字数判断质量。

五、结构化输出与工具调用​

Q41：为什么要使用结构化输出？​

答案汇总：结构化输出让模型结果进入可验证的数据契约，便于渲染、存储和调用后续逻辑。

  • 使用 JSON Schema/Zod 定义枚举、必填项、范围和嵌套。
  • Schema 合法不等于业务真实，金额、权限和 ID 仍要查系统验证。
  • 解析失败要有重试、降级或人工处理，不能用正则硬抠 JSON。

Q42：Structured Output 和 JSON mode 有什么区别？​

答案汇总：JSON mode 通常只保证输出可解析 JSON，Structured Output 进一步按指定 Schema 约束结构。

  • 能力和支持的 Schema 子集因模型/Provider 而异。
  • 即使 Schema 严格，语义和值仍可能错误。
  • 应做契约测试，并在服务端再次校验。

Q43：什么是 Function Calling/Tool Calling？​

答案汇总：模型选择工具并生成结构化参数，应用负责验证和执行，再把结果返回模型继续处理。

  • 模型本身没有直接执行权限，真正副作用由工具服务控制。
  • 工具描述要清楚区分适用场景和禁用边界。
  • 每次调用记录 call ID、参数、审批、结果和错误。

Q44：如何设计一个好的工具 Schema？​

答案汇总：工具应职责单一、参数明确、枚举有限，并让危险动作和只读动作分开。

  • 使用业务 ID，不让模型自由拼接 SQL、Shell 或任意 URL。
  • 写清必填、单位、时区和默认值，避免模糊字符串。
  • 输出结构化错误，例如 unauthorized、not-found、conflict。

Q45：工具调用为什么需要服务端再次校验参数？​

答案汇总：工具参数来自不可信的概率输出，可能错误、越权或被注入影响，Schema 只验证形状。

  • 按当前用户重新鉴权并校验资源归属。
  • 限制金额、数量、URL、路径和操作范围。
  • 不接受模型传来的 isAdmin: true 等身份结论。

Q46：如何防止 Agent 重复执行写操作？​

答案汇总：使用幂等键、业务唯一约束和显式状态机，让相同意图重复调用仍只产生一次副作用。

  • 幂等键绑定用户、工具、参数哈希和任务 ID。
  • 超时后先查询执行状态，不要盲目再次创建。
  • 将工具结果持久化，Agent 重启后复用已完成步骤。

Q47：工具失败后应该把什么返回给模型？​

答案汇总：返回结构化、最小必要且不泄密的错误，让模型知道可重试、需改参数、需授权还是必须停止。

  • 区分 validation、unauthorized、rate-limit、conflict 和 internal。
  • 内部堆栈、密钥和数据库详情不能进入模型上下文。
  • 限制重试次数，参数未变化时避免循环重试。

Q48：什么时候工具调用需要用户确认？​

答案汇总：涉及外部发送、支付、删除、发布、权限变更或其他难以撤销的副作用时，需要精确确认。

  • 只读搜索通常不需要逐次审批，但仍要鉴权和审计。
  • 确认必须展示真实参数和影响范围。
  • Approval token 由服务端签发，模型不能自行生成“已批准”。

Q49：如何限制 Agent 的工具循环？​

答案汇总：设置最大步骤、工具次数、墙钟时间和费用，并检测重复动作和无进展状态。

  • 连续相同调用或错误应停止并请求用户补充信息。
  • 每步检查目标是否已满足，避免为了用工具而用工具。
  • 预算耗尽时返回已完成步骤和下一步建议，保留可恢复状态。

Q50：工具调用和普通后端接口有什么关系？​

答案汇总：工具是提供给模型的受控业务能力，底层仍应复用正常领域服务、鉴权和事务，而不是另写一套无保护接口。

  • 工具层做自然语言意图到严格 DTO 的适配。
  • 领域服务对 Web、移动端和 Agent 使用相同不变量。
  • 这样可以单独测试工具契约，也避免模型绕过业务规则。

六、RAG、Embedding 与向量检索​

Q51：什么是 RAG？​

答案汇总：RAG 在生成前检索外部资料，把相关证据和来源放入上下文，让回答基于可更新的知识。

  • 它适合私有、最新、可引用和需要权限控制的内容。
  • 典型链路是解析、切分、Embedding、召回、重排、生成和引用。
  • RAG 会降低但不能消除幻觉，需要分层评测和拒答机制。

Q52：什么是 Embedding？​

答案汇总：Embedding 把文本、图片等映射成向量，使语义相近内容在向量空间更接近。

  • 常用于语义搜索、聚类、推荐、去重和 RAG 召回。
  • 向量没有直接权限语义，检索时仍要做 ACL 过滤。
  • 更换模型后向量空间通常不兼容，需要版本化和重建索引。

Q53：余弦相似度、点积和欧氏距离怎么选？​

答案汇总：按 Embedding 模型的训练说明和向量是否归一化选择，并用实际检索集评估。

  • 归一化向量下，余弦与点积的排序关系通常接近。
  • 不同向量库对距离的正负和排序方向定义可能不同。
  • 不能用一个固定相似度阈值跨模型、语言和业务复用。

Q54：文档应该如何切 chunk？​

答案汇总：按语义结构和答案粒度切分，并用检索评测选择大小与 overlap，而不是统一按固定字符数。

  • 标题、段落、列表、表格和代码块尽量保持结构。
  • chunk 太小缺上下文，太大则召回不精确且浪费 token。
  • 保存文档、章节、页码、版本和 ACL 元数据。

答案汇总：向量检索擅长语义相似，BM25/关键词擅长精确术语、编号和专有名词，混合召回能互补。

  • 分别召回后用 RRF 或学习排序融合。
  • 对错误码、产品型号和人名，关键词常很重要。
  • 融合权重需要按查询类型和离线数据调试。

Q56：Reranker 有什么作用？​

答案汇总：Reranker 对少量候选做更精细的 query-document 相关性评分，提高最终送入模型的证据质量。

  • 先用便宜召回取较大候选，再重排到较小 Top-K。
  • 它会增加延迟和成本，应评估对任务成功的真实增益。
  • 权限过滤应在返回内容前完成，不能把越权候选交给外部重排器。

Q57：RAG 如何做权限控制？​

答案汇总：索引记录资源 ACL，查询时基于当前用户在检索层过滤，并在读取原文时再次授权。

  • 不能先召回越权文档再要求模型忽略。
  • 缓存键包含租户、用户/角色和权限版本。
  • 引用链接也要走正常鉴权，防止答案安全但链接泄漏。

Q58：RAG 没找到答案时怎么办？​

答案汇总：根据召回证据和任务规则明确拒答、追问或转搜索/人工，不能让模型靠常识补齐私有事实。

  • 使用相关性、证据覆盖和来源质量信号，而不是单一阈值。
  • 前端说明搜索范围，并允许用户换关键词或选择数据源。
  • 将无答案样本加入评测集，区分“库里没有”和“检索没找到”。

Q59：如何评估一个 RAG 系统？​

答案汇总：拆开评估召回、重排、上下文和生成，再用端到端任务成功验证整体效果。

  • 检索看 Recall@K、MRR/NDCG 和权限正确性。
  • 生成看忠实度、引用精度、答案正确和拒答。
  • 线上看纠错、来源点击、无结果、转人工和延迟成本。

Q60：RAG 和微调如何选择？​

答案汇总：RAG 主要解决可更新事实和来源，微调主要改变稳定行为、风格或特定任务模式，二者可以组合。

  • 公司制度、库存和最新文档优先 RAG/工具。
  • 大量标注示例描述的分类、格式和语气可考虑微调。
  • 先建 Prompt+RAG 基线和评测，再判断微调是否有净收益。

七、Agent、MCP 与协议​

Q61：什么是 AI Agent？​

答案汇总：Agent 是围绕目标循环进行观察、规划、调用工具和验证结果的系统，不只是会聊天的模型。

  • 核心组件包括模型、工具、状态、预算、策略和终止条件。
  • 真正任务成功由外部状态或测试判断，不由模型自评。
  • 自动化程度按风险提高，副作用前保留确定性控制和审批。

Q62：Workflow 和 Agent 有什么区别？​

答案汇总：Workflow 的步骤和分支主要由代码预先定义，Agent 让模型动态选择下一步；能用固定流程解决时优先 Workflow。

  • Workflow 更可预测、易测试、成本稳定。
  • Agent 适合路径难以枚举、需要探索和工具选择的任务。
  • 生产系统常把两者组合：外层确定性流程，局部节点使用 Agent。

Q63：Agent 的记忆应该如何设计？​

答案汇总：把会话状态、任务状态、用户偏好和长期知识分开存储，不把“所有历史消息”当作唯一记忆。

  • 关键业务状态使用结构化数据库和版本控制。
  • 对话摘要可压缩上下文，但允许追溯原始授权范围。
  • 长期记忆需要用户可见、可改、可删除，并防止跨租户污染。

Q64：如何判断 Agent 任务已经完成？​

答案汇总：使用外部可验证的完成条件，例如测试通过、工单状态、文件存在或业务不变量，而不是让模型说“完成了”。

  • 定义 success、partial、blocked 和 failed 等终态。
  • 完成前检查必须产物、禁止动作和副作用记录。
  • 达不到条件时返回缺失信息或请求人工，而不是伪造成功。

Q65：什么是 MCP？​

答案汇总：MCP 是 Host/Client 与外部 Server 之间连接工具、资源和 Prompt 的开放协议，目标是减少每个 AI 应用重复集成。

  • Server 常提供 Tools、Resources、Prompts；Client 可支持 Sampling、Elicitation、Roots 等能力。
  • 常见传输包括 stdio 和 Streamable HTTP。
  • MCP 解决连接与发现，不替代业务鉴权、沙箱和审批。

Q66：MCP 和 Function Calling 有什么区别？​

答案汇总：Function Calling 是模型表达“要调用哪个函数”的能力；MCP 进一步标准化工具/资源如何被发现、连接和交换。

  • Function Calling 可以完全在单个应用内部实现。
  • MCP 适合多个 Host 复用独立 Server 和能力目录。
  • Host 仍要把 MCP Tool 转换为目标模型可理解的调用格式。

Q67：stdio MCP 和远程 HTTP MCP 怎么选？​

答案汇总：本地开发工具和进程级隔离常用 stdio；跨网络共享服务使用 Streamable HTTP 并建设正式认证和多租户控制。

  • stdio 不等于安全，本地进程仍可能访问文件和环境变量。
  • 远程传输要处理 OAuth、资源 audience、会话、超时和 SSRF。
  • 两种方式都需要限制可用工具、参数和数据范围。

Q68：MCP Server 有哪些主要安全风险？​

答案汇总：主要风险是恶意/被攻陷工具、Token 转发、过宽权限、工具结果注入、本地命令执行和供应链替换。

  • 只安装可信 Server，固定版本并最小化运行权限。
  • Host 展示工具来源与副作用，对高风险调用逐项审批。
  • 远程服务验证 token audience，不能把上游 token 透传给下游。

Q69：MCP、A2A 和 AG-UI 分别解决什么问题？​

答案汇总：MCP 连接 Agent 与工具/资源，A2A 连接 Agent 与 Agent，AG-UI 同步 Agent 与用户界面的运行事件。

  • 三者处于不同边界，可以在一个系统里组合。
  • 内部领域模型应独立于外部协议，通过 Adapter 转换。
  • 协议不能自动提供权限、业务事务和最终任务正确性。

Q70：如何评估 Agent？​

答案汇总：同时评估最终结果、工具轨迹、效率和安全，不能只看最后回答是否好听。

  • 检查工具选择、参数、顺序、重试和审批是否合规。
  • 记录步骤、token、工具耗时、总成本和重复写入。
  • 允许多条正确轨迹，重点验证不变量和禁止动作。

八、多模态与浏览器端 AI​

Q71：什么是多模态模型？​

答案汇总：多模态模型能在同一任务中理解或生成文本、图片、音频、视频等不同内容类型。

  • 输入能力、输出能力和实时能力要分别确认，不能只看“支持多模态”。
  • 文件仍需做格式、大小、来源和安全校验。
  • 重要视觉/语音结论要保留原始证据和人工复核路径。

Q72：前端上传图片给模型要注意什么？​

答案汇总：在客户端做体验级预检，在服务端做真正的类型、大小、权限、恶意内容和元数据治理。

  • 不信任扩展名和浏览器 MIME，服务端重新识别文件。
  • 按需要压缩/缩放，避免把超大原图直接转 base64 塞进 JSON。
  • 使用对象存储短期地址或 Provider 文件接口，并设置生命周期删除。

Q73：图片为什么不建议直接长期保存成 base64？​

答案汇总：base64 会增大体积、占用 JSON/数据库和内存，也不利于缓存、范围读取与生命周期管理。

  • 生产中通常保存对象存储 URL、哈希和元数据。
  • URL 应鉴权或短期签名，不能永久公开敏感图片。
  • 传模型前按 Provider 支持选择 URL、文件 ID 或二进制上传。

Q74：语音对话的前端链路如何设计？​

答案汇总：采集音频后经过 VAD/分片、实时上传、识别、模型处理和语音合成，同时允许打断和状态同步。

  • WebRTC 适合低延迟双向媒体，WebSocket 也可用于受控音频流。
  • UI 区分 listening、thinking、speaking、interrupted 和 error。
  • 处理麦克风权限、回声消除、字幕、静音和敏感音频保留。

Q75：什么是浏览器端 AI？​

答案汇总：浏览器端 AI 是在用户设备通过 WebGPU、WebAssembly 或浏览器内置模型执行推理。

  • 优点可能包括离线、隐私和减少服务端请求。
  • 限制是下载体积、设备差异、内存、电量和 API 可用性。
  • 必须做能力检测、进度提示、取消和服务端降级。

Q76：WebGPU 和 WebNN 有什么区别？​

答案汇总：WebGPU 提供通用 GPU 计算能力，WebNN 提供偏神经网络图的高层接口；支持范围和成熟度需要实时检测。

  • WebGPU 生态更灵活，但框架要负责更多算子和内存管理。
  • WebNN 可映射设备加速后端，但浏览器支持并不统一。
  • 不在 UA 字符串里假设支持，运行时 feature detection。

Q77：端侧模型如何处理首次下载体验？​

答案汇总：按需加载并展示真实下载、校验和初始化阶段，同时提供取消、缓存管理和云端回退。

  • 在下载前显示预计体积、网络和存储要求。
  • 权重分片、版本化缓存并校验完整性。
  • 移动网络、低电量和内存不足时不要强制启动。

Q78：浏览器内置 AI API 能直接作为唯一实现吗？​

答案汇总：不宜直接作为唯一实现，因为浏览器、地区、设备、模型下载和 API 阶段可能不同。

  • 设计 capability adapter，统一本地和云端输出契约。
  • UI 说明本地处理还是云端处理，避免隐私误导。
  • 在真实浏览器矩阵上测试，并准备无能力时的降级。

Q79：多模态输出如何做安全渲染？​

答案汇总：每种媒体类型都按不可信内容处理，使用白名单组件、隔离和资源代理。

  • 图片限制来源、尺寸和格式；SVG/HTML 需特别谨慎。
  • 音视频设置权限、下载和自动播放策略。
  • 模型生成的 URL、文件名和 alt 文本都要校验或转义。

Q80：OCR 与视觉模型如何选择？​

答案汇总：规则清晰的大批量文档先评估专用 OCR/版面模型，复杂图文理解再用视觉语言模型组合。

  • OCR 适合字符和坐标，通常更便宜、结果更可验证。
  • 视觉模型适合理解图表、截图意图和跨区域关系。
  • 生产链路可先 OCR，再把结构化文本与关键裁剪交给 LLM。

九、AI 安全、隐私与治理​

Q81：什么是 Prompt Injection？​

答案汇总：攻击者把指令藏在用户输入或外部内容中，诱导模型忽略原目标、泄露信息或调用危险工具。

  • 直接注入来自用户，间接注入来自网页、邮件、文档和工具结果。
  • Prompt 分层和标记能降低风险，但不是可靠安全边界。
  • 真正防线是最小权限、数据隔离、参数校验、审批和监控。

Q82：如何防止模型泄露系统 Prompt？​

答案汇总：不要把密钥和不可泄露数据放进 Prompt；对提示内容本身可做最小化、输出检测和攻击评测，但无法承诺绝对保密。

  • 敏感配置保留在服务端代码/密钥系统，模型只获任务所需信息。
  • 系统 Prompt 被套取不应导致实际越权。
  • 将频繁套取、异常长输出和诱导编码纳入安全监控。

Q83：模型输出可能造成哪些前端安全问题？​

答案汇总：未经处理的输出可能触发 XSS、恶意链接、钓鱼下载、CSS 欺骗或不安全 UI 动作。

  • Markdown 禁用原始 HTML 并清洗 URL/属性。
  • 生成 UI 映射白名单 Schema，不执行任意脚本。
  • 外链、下载、复制命令和高风险操作给用户明确提示。

Q84：模型输出为什么不能直接拼 SQL 或 Shell？​

答案汇总：模型输出不可信且可能受注入控制，直接执行会形成 SQL/命令注入和破坏性操作。

  • SQL 使用受限查询工具、参数化模板、只读账号和行数/时间限制。
  • Shell 用预注册命令与结构化参数，不提供任意解释器。
  • 执行环境使用沙箱、最小权限和完整审计。

Q85：AI 应用如何保护个人信息？​

答案汇总：先做数据最小化和用途限制，再控制传输、存储、访问、保留、删除和训练回流。

  • 发送模型前去除不必要身份字段，敏感值可替换为占位 ID。
  • 明确 Provider 的存储/训练政策和处理地域。
  • 日志、向量库、缓存和人工标注台都纳入同一数据治理。

Q86：如何防止跨租户数据泄漏？​

答案汇总：在检索、缓存、工具、消息、日志和模型路由各层绑定租户，不把隔离寄托在 Prompt 文案上。

  • 缓存键和向量过滤包含租户/权限版本。
  • 服务端根据会话注入租户，拒绝客户端自报的任意 tenant ID。
  • 用对抗测试验证用户无法通过引用、历史或工具获取其他租户数据。

Q87：如何应对 AI 成本攻击？​

答案汇总：攻击者可能用超长输入、并发、循环工具和大输出消耗资源，因此要做多维配额与预算。

  • 限制输入/附件、输出、并发、步骤、工具调用和每日费用。
  • 按用户与租户鉴权，异常模式触发限速或挑战。
  • 超预算时中断并返回可恢复状态，不让 Agent 无限自我重试。

Q88：AI 应用为什么需要内容审核？​

答案汇总：内容审核用于识别违法、伤害、自残、仇恨或业务禁止内容，但策略应结合场景、地域和用户年龄。

  • 输入和输出都可能需要审核，工具执行还要单独做风险控制。
  • 审核模型会误判，设计申诉、转人工和紧急升级。
  • 不把“通过审核”误认为答案事实正确或没有隐私风险。

Q89：什么是 AI 治理？​

答案汇总：AI 治理是对用例、责任、数据、模型、供应商、评测、发布、监控和事件的全生命周期管理。

  • 先建立 AI 系统清单和风险分级，再匹配门禁。
  • 每个系统有业务 Owner、数据 Owner 和可回滚版本。
  • 高风险场景提供人工复核、解释、退出和申诉。

Q90：发生 AI 数据泄漏事件时怎么处理？​

答案汇总：先用细粒度开关遏制影响，再评估范围、保留必要证据、通知责任团队并修复回流评测。

  • 可关闭特定模型、工具、数据源、租户或日志采样。
  • 排查 Prompt、RAG、缓存、Trace、供应商和用户可见输出。
  • 完成删除/通知等必要补救，并把事故样本加入回归测试。

十、评测与可观测性​

Q91：为什么 AI 应用需要 Evals？​

答案汇总：模型输出有概率性，Prompt、模型、检索和工具的改动都可能隐性退化，需要固定数据集做可重复比较。

  • Eval 从真实用户任务和历史失败构建，而不是只用通用考试题。
  • 每次发布比较任务成功、安全、延迟和成本。
  • 线上失败经脱敏、去重和标注后回流评测集。

Q92：一个好的评测集如何构建？​

答案汇总：覆盖真实分布、重要边界和高风险失败，并保持训练/调试数据与最终留出集隔离。

  • 来源包括需求用例、线上样本、事故、专家和受控合成数据。
  • 用标签切分语言、长上下文、权限、注入、无答案和工具任务。
  • 数据集版本化、语义去重并记录来源与授权。

Q93：确定性评分、人工评分和 LLM Judge 怎么选？​

答案汇总：能用代码和外部真值判断的优先确定性评分，主观体验用人工，开放式规模评估再使用经校准的 Judge。

  • JSON、测试、金额、权限和引用存在性不要交给 LLM 猜。
  • 人工建立金标准和 Rubric，处理评分分歧。
  • Judge 随机候选顺序、优先 pairwise，并持续与人工结果校准。

Q94：LLM-as-a-Judge 有哪些偏差？​

答案汇总：它可能偏好更长、排在前面、与自己风格相近的回答，也可能被候选内容中的指令注入。

  • 交换 A/B 顺序并统计一致性，限制 Judge 可见上下文。
  • 明确逐项 Rubric，要求引用证据而非自由打分。
  • 高风险失败仍由规则或人工确认，不以单个 Judge 分数发布。

Q95：AI 聊天线上应该监控哪些指标？​

答案汇总：同时看用户任务、生成体验、模型运行、安全和成本，不能只看请求成功率。

  • 任务完成、点赞/纠错、转人工、引用点击和重新生成。
  • TTFT、总耗时、流中断、取消、模型/工具错误。
  • token、缓存、步骤、每成功任务成本和安全事件。

Q96：Agent Trace 应该记录什么？​

答案汇总：记录任务、模型调用、检索、每个工具步骤、审批、结果和时间关系，同时默认避免完整敏感内容。

  • Span 关联 request/workflow ID、版本、结束原因和时延。
  • 工具参数记录哈希或脱敏摘要，副作用保留业务执行 ID。
  • Trace 能回答“在哪一步失败”，而不仅是最后出现 500。

Q97：为什么不能把完整 Prompt 全量写日志？​

答案汇总：Prompt 可能包含个人信息、公司数据、密钥和工具结果，全量日志扩大访问面与保留风险。

  • 默认记录长度、哈希、分类、版本和 token。
  • 调试采样要授权、脱敏、加密、限权并设置短保留。
  • 日志系统本身也要支持租户隔离、审计和删除。

Q98：如何给 AI 变更设置发布门禁？​

答案汇总：候选版本必须在固定评测集上达到质量与安全阈值，性能成本不超预算，再灰度并满足线上停止条件。

  • 高风险权限和泄漏切片设硬门槛，不能被平均分抵消。
  • 比较基线和置信区间，避免小样本偶然提升。
  • Prompt、模型、RAG、工具和策略变更都走同一门禁。

Q99：如何做 AI A/B 测试？​

答案汇总：先通过离线安全门禁，再按用户/会话稳定分流，使用任务指标和护栏指标比较。

  • 同一会话不要频繁切模型，避免上下文与体验不一致。
  • 预先定义主要指标、样本量、停止条件和分群分析。
  • 高风险功能优先 shadow/canary，不直接让一半用户承担未知风险。

Q100：如何把用户反馈用于改进模型？​

答案汇总：把反馈关联到具体版本和任务，经过授权、脱敏、聚类、标注和根因分析后，选择改 Prompt、RAG、工具或训练。

  • 点赞不是完整真值，应结合编辑、完成状态和业务结果。
  • 先修确定性系统缺陷，不要把所有失败都归因于模型。
  • 新增失败样本进入回归集，验证修复没有破坏其他切片。

十一、性能、成本与模型部署​

Q101：AI 应用的延迟由哪些部分组成？​

答案汇总：总延迟包括排队、鉴权、检索、Prompt 构建、模型首包、生成、工具、后处理和网络传输。

  • 用 Trace 分段统计，不能只看 Provider 的模型耗时。
  • 交互应用同时关注 TTFT、每 token 延迟和总任务时间。
  • 优化最慢或波动最大的关键路径，而不是盲目换更小模型。

Q102：如何降低 AI 功能成本？​

答案汇总：先减少无价值调用和上下文，再做能力路由、缓存、批处理和模型优化，同时守住质量门禁。

  • 去重历史、优化检索 Top-K、限制输出和循环步骤。
  • 简单任务路由快/小模型，复杂任务才使用高推理档。
  • 以每个成功任务成本衡量，低质量导致重试可能更贵。

Q103：Prompt Caching 适合什么场景？​

答案汇总：大量请求共享稳定、较长前缀时适合缓存，例如固定系统指令或公共知识前缀。

  • 把稳定内容放前面，动态用户内容放后面。
  • 缓存键要包含模型、版本、模板、Adapter 和安全域。
  • 收益和计费因 Provider 而异，用 usage 与延迟实测。

Q104：语义缓存有什么风险？​

答案汇总：语义相似不代表答案可安全复用，最新数据、权限和个人化内容可能被错误命中。

  • 缓存键包含租户、权限、数据版本、语言和时间范围。
  • 只缓存低风险、稳定、可验证的任务。
  • 返回时标记来源与生成时间，支持失效和绕过。

Q105：什么是模型量化？​

答案汇总：量化用更低精度表示权重、激活或 KV Cache，以减少内存并可能提升吞吐，但可能损失质量。

  • 位宽相同也可能因算法、校准和内核不同而效果不同。
  • 在目标任务、硬件、上下文长度上与原精度版本比较。
  • 记录量化配置为模型发布制品的一部分。

Q106：什么是 KV Cache？​

答案汇总：KV Cache 保存已处理 token 的注意力键和值，生成下一个 token 时避免重复计算历史，但会随并发和上下文增长占用显存。

  • 长对话和多并发下它可能比权重更限制容量。
  • 分页管理、GQA/MQA、低精度和长度限制可缓解。
  • 容量规划必须使用真实序列和并发压测。

Q107：什么是连续批处理？​

答案汇总：推理引擎在 token 生成过程中动态加入新请求、移除已完成请求，提高 GPU 利用率和总吞吐。

  • 与静态批处理相比更适合长度不同的在线请求。
  • 批处理策略会影响 TTFT 和公平性，需要按 SLO 调参。
  • 长短流量可分池，避免超长请求拖慢交互用户。

Q108：开源模型和闭源 API 如何选择？​

答案汇总：根据任务质量、数据边界、流量形态、定制需求和总拥有成本决定，常见方案是多 Provider/自建混合路由。

  • 自建提供控制和数据驻留，但承担 GPU、升级、安全和运维。
  • API 上手快、弹性好，但受价格、配额和版本策略影响。
  • 用统一评测和网关比较，保留替换与降级能力。

Q109：自建推理服务为什么需要 AI Gateway？​

答案汇总：Gateway 统一认证、配额、模型路由、协议、日志和降级，让业务不直接绑定某个推理引擎。

  • 后端只暴露内网，由 Gateway 控制多租户和公网攻击面。
  • 规范化流事件、usage、工具和错误，但保留能力声明。
  • 集中实施成本预算、内容策略和可观测性。

Q110：如何做模型服务容量规划？​

答案汇总：基于真实输入/输出长度、并发、SLO 和硬件压测，计算权重、KV Cache、运行时余量与峰值队列。

  • 区分交互、长上下文和异步批处理流量。
  • 用在途 token、KV 使用率、队列和 TTFT 共同扩缩。
  • 设计过载拒绝、小模型降级和冷启动容量，避免无限排队。

十二、综合系统设计与场景题​

Q111：设计一个公司内部知识库问答系统，你会怎么做？​

答案汇总：采用带 ACL 的 RAG、可引用回答、BFF 鉴权、离线评测和线上反馈闭环，并让无证据问题明确拒答。

  • 数据侧：连接源系统、解析切分、版本/权限元数据、混合召回与重排。
  • 应用侧：服务端按用户过滤、生成带引用答案，前端展示来源和更新时间。
  • 运营侧：评估召回/忠实度，监控无结果、越权、纠错和数据过期。

Q112：设计一个 AI 客服助手，如何避免它乱承诺？​

答案汇总：模型负责理解和组织语言，退款资格、金额、库存和承诺由受控政策/业务工具返回。

  • 政策 RAG 带版本引用，真实订单工具按当前用户鉴权。
  • 高额退款、补偿和外部发送需要人工审批。
  • UI 支持转人工，评测政策遵循、一次解决率和错误承诺。

Q113：设计一个前端代码 Copilot，需要哪些安全措施？​

答案汇总：限制代码上下文和仓库权限，在沙箱执行生成结果，用测试/类型检查验证，并在写入前展示 Diff。

  • 忽略仓库中针对 Agent 的恶意内容，工具按允许目录和命令白名单运行。
  • 密钥、.env 和用户隐私默认不进入模型/日志。
  • 代码许可证、依赖供应链和危险命令需要额外扫描与审批。

Q114：设计一个自然语言生成图表功能。​

答案汇总：模型只生成受约束的查询意图和图表 Schema，服务端安全查询数据，前端用白名单图表组件渲染。

  • 数据查询限制表、字段、行数、时间和当前用户权限。
  • Schema 校验轴、系列、格式和可访问性，不执行任意 JS。
  • 数值由查询结果计算，模型负责解释并引用数据时间范围。

Q115：如何把一个同步 AI 请求改造成长任务？​

答案汇总：创建持久任务与事件流，Worker 按状态机执行，前端通过流或轮询查看进度并能取消/恢复。

  • POST 返回 task ID，任务记录输入版本、预算、Owner 和幂等键。
  • 每步写 checkpoint 与结构化事件，副作用可查询且不重复执行。
  • 完成后通知用户；重连按游标补事件，不长期占用单个 HTTP 请求。

Q116：如果模型供应商突然不可用，系统如何处理？​

答案汇总：通过 Gateway 熔断并路由到经过评测的备用模型；无法保证质量时降级为搜索、模板或人工流程。

  • 备用模型提前做能力和契约测试，不能事故时临时切换。
  • 避免在已发生副作用的 Agent 中从头重跑，先恢复任务状态。
  • 监控区域、限流和错误，向用户展示真实降级状态。

Q117：如何设计一个可扩展的多模型架构？​

答案汇总：业务依赖内部能力接口，Router 根据任务、风险、成本和地区选择端点，Adapter 处理 Provider 差异。

  • 维护模型能力注册表和标准内容块/错误/usage。
  • 策略配置版本化，并与评测、灰度和回滚关联。
  • 对 Provider 特有能力保留扩展通道，不追求虚假的完全统一。

Q118：AI 回答很慢，但换小模型质量下降，你会怎么优化？​

答案汇总：先用 Trace 找到检索、排队、首包、生成还是工具瓶颈，再针对性优化和分层路由。

  • 精简上下文、并行独立检索、缓存稳定前缀、减少不必要输出。
  • 先用快模型分类/草拟，复杂任务再路由强模型，但避免重复做全部工作。
  • 前端流式展示真实状态、支持取消；以成功任务质量和 p95 延迟共同验收。

Q119：上线后用户说答案“看着对但不能用”，怎么排查？​

答案汇总：先还原具体任务与期望结果，查看证据、工具轨迹和版本，区分事实错、缺步骤、权限、格式还是产品交互问题。

  • 把失败样本加入切片 Eval，并与历史基线复现。
  • 若是检索失败调召回/重排，若是业务结果错修工具和验证，不盲目改 Prompt。
  • 用用户最终动作和人工修改验证修复是否真正可用。

Q120：面试中如何讲好自己的 AI 项目？​

答案汇总：用“业务问题—约束—架构—关键取舍—验证结果—失败复盘”讲完整闭环，而不是只列模型和框架名称。

  • 说明为什么选 RAG/工具/Agent，前端如何处理流式、状态和安全。
  • 给出真实指标口径：任务成功、延迟、成本、转人工和安全回归。
  • 主动讲一个失败、如何定位及如何加入评测集，最能体现工程成熟度。

十三、AI 编程工具与工程实践​

Q121：你会如何选择 AI 编程工具，而不是直接选排行榜第一名？​

答案汇总：我会用团队真实任务做小规模评测，从任务成功率、人工返工、权限边界、工作流集成和总成本选工具，而不是把模型榜单等同于工程效果。

  • 选一组新功能、Bug、重构、测试和代码审查任务，固定验收标准后横向比较。
  • 区分 IDE 补全、交互式 Agent、后台任务和 CI 自动化，不要求一个工具包办全部场景。
  • 同时检查数据政策、网络访问、沙箱、审计、MCP/Skills 生态和团队学习成本。

Q122：IDE 补全、IDE Agent 和 CLI Agent 分别适合什么任务？​

答案汇总：补全适合低延迟的小改动，IDE Agent 适合边看边改的多文件任务，CLI Agent 更适合终端驱动、可脚本化和长链路的仓库任务。

  • 改变量名、补类型和局部样板优先补全，避免为一行代码启动长 Agent 链路。
  • UI 联调、查看诊断和逐文件确认适合 IDE；依赖升级、批量迁移和 CI 排查适合 CLI。
  • 最终仍以验证成本决定工具，复杂任务不代表一定要用 CLI，简单任务也不值得过度编排。

Q123：Claude Code 和 Codex 应该怎么选？​

答案汇总：两者都是能读写仓库、运行命令并迭代验证的编码 Agent，我会按当前环境、权限模型、扩展方式和实测结果选，而不宣称谁永久更强。

  • Claude Code 主要围绕 CLAUDE.md、.claude/rules/、Skills、Hooks 和 Subagents 组织项目能力。
  • Codex 主要用 AGENTS.md、.agents/skills/、项目配置、沙箱、Hooks 和并行 Agent 组织工作。
  • 团队可保留二者：统一业务规范和验收标准，只让薄适配层处理目录与配置差异。

Q124：怎样给编码 Agent 描述一个高质量任务？​

答案汇总：一个好任务至少包含目标、范围、现状证据、约束、验收标准和禁止事项，让 Agent 能判断何时完成。

  • 给出错误日志、相关文件、复现步骤或设计图，不只说“这里有问题”。
  • 明确可以改哪些模块、是否允许加依赖、兼容性要求和不在本次范围内的事项。
  • 要求运行具体测试并汇报改动、证据、剩余风险，而不是只返回“已完成”。

Q125：为什么验收标准比“写一个详细 Prompt”更重要？​

答案汇总：详细描述只能帮助开始，机器可执行或可观察的验收标准才能闭合“实现—检查—修正”循环。

  • 后端任务给单测、类型检查和接口样例，前端任务给截图、交互状态和可访问性要求。
  • 让 Claude Code 或 Codex 在修改后自己运行验证，读取失败结果后继续修复。
  • 对无法自动验证的产品判断，保留人工验收并说明证据，不让 Agent 自证正确。

Q126：给 Agent 的上下文越多越好吗？​

答案汇总：不是，相关且可定位的上下文比大而全更有效，无关文件会增加成本并稀释关键约束。

  • 先给入口文件、调用链、错误和期望，再让 Agent 搜索它确实需要的依赖。
  • 长规范拆成常驻项目指令、按路径规则和按需 Skill，避免每次加载所有资料。
  • 大日志先过滤或交给独立 Agent 汇总，主会话只保留结论和证据位置。

Q127：为什么推荐“探索—计划—实现—验证”而不是直接生成代码？​

答案汇总：它把方向错误尽量暴露在写代码前，并为高风险改动增加可审查的决策点。

  • 探索阶段确认入口、依赖、现有约定和测试；计划阶段列文件、顺序、风险与回滚。
  • 小而明确的改动可缩短计划，但大型重构、迁移和安全相关修改不应跳过。
  • 计划获批后再授权写入，并在每个可独立验收的阶段运行检查。

Q128：如何防止 Agent 顺手扩大修改范围？​

答案汇总：在任务中写清边界，用权限和 Git diff 提供第二层约束，并把额外发现记录为建议而不是顺手修改。

  • 明确“只改这些目录”“不要升级依赖”“不要重排无关代码”。
  • 要求改动前列预计文件，改动后解释任何超出列表的文件。
  • 对机械禁止项使用沙箱、deny 规则或 Hook；自然语言规则不是强制安全边界。

Q129：你会怎样用 Claude Code 或 Codex 排查 Bug？​

答案汇总：先稳定复现和收集证据，再定位最小根因、补回归测试并验证修复，不从报错表面直接猜补丁。

  • 提供最小复现、输入、环境、完整错误和最近变更，让 Agent 画出相关调用链。
  • 先让它提出多个假设和区分实验，再按证据排除，避免不断试随机修改。
  • 修复后运行原复现、相关测试和静态检查，并确认没有通过吞错或放宽类型掩盖问题。

Q130：前端 UI 任务怎样让 AI 的结果更可靠？​

答案汇总：把视觉、交互、响应式和可访问性都变成可比较的验收项，并让 Agent 使用浏览器或截图验证。

  • 给 Claude Code 或 Codex 设计图、目标尺寸、组件状态和已有设计 Token。
  • 要求检查 loading、empty、error、disabled、键盘操作和窄屏，不只实现默认态。
  • 运行组件测试或端到端测试，比较前后截图并列出仍存在的视觉差异。

Q131：项目指令文件应该写什么，不应该写什么？​

答案汇总：只写每个任务都需要的稳定事实、命令、约束和验收方式；长教程和偶发流程应放到 Skill 或普通文档。

  • 适合写技术栈、目录职责、包管理器、测试命令、禁止操作和提交前检查。
  • 不适合复制整份 API 文档、临时需求、过多示例或容易过期的模型排名。
  • 规则应具体且可验证，冲突和过期指令要定期清理。

Q132：AGENTS.md 有什么价值？​

答案汇总：AGENTS.md 是适合提交到仓库的 Agent 项目说明入口，可承载通用的架构、命令和协作约定，但仍需验证每个工具是否原生读取。

  • Codex 会按目录层级读取 AGENTS.md，更靠近工作目录的说明用于细化局部规则。
  • 它适合作为供应商中立的规范源，减少多份规则内容漂移。
  • 文件名通用不等于所有工具自动兼容，接入新工具时要做“它实际加载了哪些指令”的测试。

Q133：只保留 AGENTS.md，Claude Code 会自动读取吗？​

答案汇总：按当前官方行为，Claude Code 自动读取的是 CLAUDE.md，不是 AGENTS.md；若要求自动加载，需要一个导入或符号链接适配层。

  • 最薄的做法是在 CLAUDE.md 中只写 @AGENTS.md，正文仍只有一份。
  • 不需要 Claude 专属内容时，也可让 CLAUDE.md 指向 AGENTS.md 的符号链接。
  • 如果团队坚持完全不保留 CLAUDE.md，就必须接受手动注入或工具配置，并用实际会话验证，不能假设自动兼容。

Q134：多工具项目中 .rules 目录不一致，应该怎么处理？​

答案汇总：不要把某个厂商的发现目录当成统一标准；维护一份中立规则源，再用薄适配、符号链接或生成脚本投影到各工具需要的位置。

  • 例如把正文放在 agent-rules/，AGENTS.md 只列入口和加载策略。
  • Claude Code 的路径规则仍需 .claude/rules/ 才能自动按路径加载；其他工具按其官方目录配置适配。
  • 适配层只处理“发现”，不复制正文；CI 可检查链接目标或生成结果是否与源一致。

Q135：agent-rules/ 能成为所有工具都自动识别的统一目录吗？​

答案汇总：它可以成为团队统一维护的内容目录，但不能天然成为所有工具的自动发现目录，因为各产品的扫描规则并不相同。

  • AGENTS.md 可以告诉 Agent 在需要时读取 agent-rules/，适合普通参考文档。
  • 需要自动、条件加载的厂商能力时，仍要提供对应入口，例如 Claude Code 的 .claude/rules/。
  • 面试中应区分“内容的单一事实源”和“运行时的发现协议”，这是多工具治理的核心。

Q136：符号链接是什么，能提交到 Git 吗？​

答案汇总：符号链接是指向另一个路径的轻量目录项；Git 可以提交链接本身，仓库保存的是目标路径，不会复制目标内容。

  • 在支持符号链接的系统检出后，多个工具目录可指向同一份规则或 Skill，从源头避免重复。
  • 链接目标最好使用仓库内相对路径，否则换机器后容易失效。
  • 提交前要验证 git diff 显示的是链接，CI 也应检查目标存在且没有逃出仓库。

Q137：跨平台项目使用符号链接有哪些风险？​

答案汇总：主要风险是 Windows 权限/开发者模式、部分客户端把链接检出成普通文件、容器路径差异和安全审计困难。

  • 团队全部使用 macOS/Linux 且 CI 一致时，符号链接通常最省维护成本。
  • 跨平台团队可用极薄导入文件，或用脚本从单一源生成工具目录并在 CI 做漂移检查。
  • 不要链接到用户 Home 或仓库外绝对路径，也不要让不可信 Skill 通过链接绕过审查范围。

Q138：什么是 Agent Skill？​

答案汇总：Skill 是按需加载的可复用任务知识或工作流，通常由 SKILL.md 加可选脚本、参考资料和资源组成。

  • 它适合部署清单、代码审查规范、文档生成和特定框架操作，不适合所有会话都必须遵守的基础规则。
  • name 和 description 用于发现，正文描述执行步骤，复杂细节放 references/，确定性操作放 scripts/。
  • Agent Skills 统一了 Skill 包的格式，但不统一所有客户端从哪个父目录发现它。

Q139：Rules 和 Skills 的区别是什么？​

答案汇总：Rules 是持续或按路径生效的项目约束，Skills 是任务匹配时才加载的知识和流程；前者回答“始终遵守什么”，后者回答“这类工作怎么做”。

  • “使用 pnpm、不得读取 secrets”属于规则或权限；“如何发布 npm 包”属于 Skill。
  • 规则太长会污染每次上下文，Skill 写成常驻规范又可能在关键时刻未触发。
  • 真正必须执行的安全动作应下沉到权限、沙箱、Hook 或 CI，不能只靠二者的自然语言。

Q140：Claude Code 和 Codex 的 Skills 目录不同，怎么只维护一份？​

答案汇总：可把标准 Skill 放在中立目录作为单一事实源，再让 .claude/skills/ 和 .agents/skills/ 通过仓库内相对符号链接或生成脚本指向它。

  • Claude Code 项目 Skill 默认位于 .claude/skills/<name>/SKILL.md，Codex 仓库 Skill 默认扫描 .agents/skills/<name>/SKILL.md。
  • 两者都遵循以 SKILL.md 为核心的 Agent Skills 结构，也都支持链接到 Skill 目录，但产品扩展字段仍需兼容测试。
  • 如果 Skill 使用某工具独有的前置字段或命令语法，应拆成共享核心加工具专属薄包装，而不是强行完全复用。

Q141：怎样写一个可移植的 Skill？​

答案汇总：核心正文遵循 Agent Skills 公共格式，避免绑定某一客户端的专属工具名，并把环境差异隔离在脚本参数或适配说明中。

  • 最小 frontmatter 使用稳定的 name 和清晰的 description，脚本通过标准输入输出返回可检查结果。
  • 路径相对 Skill 根目录，参考链保持浅，依赖和前置条件写明确。
  • 在 Claude Code、Codex 和 CI 中分别跑一个真实触发用例，验证发现、权限和输出一致性。

Q142：Skill 的 description 为什么很重要？​

答案汇总：它既说明能力，也常参与自动触发判断；描述太泛会误触发，太窄又会让 Agent 找不到 Skill。

  • 写清“做什么、何时使用、典型用户表达”，避免“帮助开发”这种无区分度描述。
  • 一个 Skill 聚焦一个稳定工作流，重叠能力通过命名和边界说明消歧。
  • 用应触发、不应触发和边界样本做回归测试，而不只测试手动调用。

Q143：Skill 的渐进式加载有什么好处？​

答案汇总：启动时只暴露少量元数据，匹配后再加载正文，真正需要时才读取脚本和参考资料，可降低上下文占用并提高相关性。

  • SKILL.md 保持导航和关键步骤，长 API 参考拆到 references/。
  • 参考文件按任务读取，不要在入口中递归导入整套知识库。
  • 这也利于维护：元数据负责发现，正文负责流程，脚本负责可重复执行。

Q144：从网上安装 Skill 有什么安全风险？​

答案汇总：Skill 不只是 Prompt，还可能包含脚本、外部链接和工具权限，应像第三方依赖一样审查来源、版本和最小权限。

  • 安装前阅读 SKILL.md 与脚本，检查网络、凭据、写文件、Shell 和数据上传行为。
  • 固定可信版本，经过代码评审后再提交；企业环境建立允许列表和更新流程。
  • 运行时放在沙箱内，只开放任务需要的目录和网络，不因“只是文档”而默认信任。

Q145：什么时候应该使用 Subagent？​

答案汇总：当任务可以清晰分界、需要独立上下文、会产生大量中间噪声或可并行时使用；简单连续任务留在主 Agent 更高效。

  • 适合代码搜索、安全审查、测试缺口、日志分析和独立方案调研。
  • 委派信息要包含目标、范围、约束、输出格式和证据要求，不能只说“帮我看看”。
  • 主 Agent 负责整合冲突结论和最终验收，不把架构决策无条件外包。

Q146：哪些任务适合并行 Agent，哪些不适合？​

答案汇总：读多写少、文件集合独立的任务适合并行；共享状态强、改同一文件或存在严格先后依赖的任务不适合。

  • 可并行：安全/性能/测试三路审查、不同模块调研、互不依赖的测试运行。
  • 不宜并行：共同修改核心类型、数据库迁移与调用方同步、一个任务依赖另一个任务产物。
  • 并行会增加 Token 和协调成本，只有缩短关键路径或提高覆盖面时才值得。

Q147：为什么并行写代码常配 Git worktree？​

答案汇总：worktree 为每个 Agent 提供独立工作目录和分支，避免同时改同一工作区，但不能自动消除合并冲突。

  • Claude Code 和 Codex 都可结合独立 worktree 运行任务，主工作区保持可用。
  • 每个 worktree 需要独立验证和 review，完成后按依赖顺序合并。
  • 任务划分前先估算文件重叠；如果重叠很高，串行通常更快。

Q148：多个 Agent 的结果冲突时怎么处理？​

答案汇总：先让主 Agent 按统一验收标准比较证据，再由人做关键取舍；不要通过简单多数投票决定技术事实。

  • 要求每个 Agent 给文件位置、测试结果、假设和不确定性。
  • 对冲突结论设计可执行实验，或让独立 reviewer 尝试反驳双方。
  • 记录最终决策和原因，避免后续会话重复争论同一问题。

Q149：权限控制和沙箱有什么区别？​

答案汇总：权限控制决定某类动作是否需要允许，沙箱在操作系统层限制文件和网络能触达的边界，两者应叠加使用。

  • 权限提示适合人机审批高风险命令，沙箱限制即使误批或 Prompt Injection 后的破坏范围。
  • 默认只开放仓库写入和必要网络，Secrets、Home、生产系统保持不可达或只读。
  • CI 和无人值守任务比交互任务更需要确定的沙箱、超时、预算和审计日志。

Q150：什么时候可以使用跳过审批或高自治模式？​

答案汇总：只在隔离、可恢复、权限最小且有自动验收的环境使用，不应在含凭据的主工作区或生产环境直接开启。

  • 使用临时容器/worktree、只读凭据、网络允许列表、命令超时和成本上限。
  • 任务前建立干净 Git 基线，任务后审查 diff、测试证据和外部副作用。
  • “更快”不是充分理由；无法限制副作用时保留人工审批。

Q151：MCP 在 AI 编程工具里解决什么问题？​

答案汇总：MCP 让 Agent 以结构化工具访问外部数据和动作，例如代码托管、设计、工单、数据库或浏览器，而不是靠复制粘贴。

  • 只接任务需要的 Server，工具名称、参数和返回值要清晰，避免一次暴露几百个无关工具。
  • 读操作与写操作分权，写外部系统通常需要确认、幂等键和审计。
  • MCP 返回内容也可能包含恶意指令，应视为不可信数据，不允许其覆盖系统和项目规则。

Q152：编码 Agent 为什么也要防 Prompt Injection？​

答案汇总：Agent 会读取仓库、网页、Issue、日志和工具返回，其中的文本可能诱导它泄露秘密或执行危险命令。

  • 把外部内容当数据，关键动作只依据用户授权和可信规则，不执行文档中的任意命令。
  • 用沙箱、权限、网络隔离和敏感路径 deny 限制影响面。
  • 对依赖安装、发布、删除、上传和凭据读取设置显式审批与日志。

Q153：Hooks 适合做什么？​

答案汇总：Hook 适合在明确生命周期中稳定触发的快速、确定性动作，例如格式化、记录审计、阻止危险命令和反馈诊断。

  • Claude Code 和 Codex 的 Hook 配置与事件模型不同，应共享脚本逻辑而不是复制同一份配置格式。
  • Hook 要幂等、带超时、输出可解释；重型全量测试放到阶段性验证或 CI。
  • Hook 本身具有执行权限，配置和脚本都要代码审查。

Q154：为什么“在规则里写必须运行测试”不能代替 Hook 或 CI？​

答案汇总：规则是模型要遵循的上下文，存在漏执行和理解偏差；Hook/CI 是确定性执行层，才能提供硬门禁。

  • 规则用于解释为什么测、测什么和如何修复，Hook/CI 负责在固定时点实际运行。
  • 本地 Hook 给快速反馈，CI 做全量、跨环境和合并保护。
  • 关键安全规则也应由权限或策略执行，不把自然语言当访问控制系统。

Q155：你会怎样审查 AI 生成的代码？​

答案汇总：按普通高风险贡献审查其需求符合度、设计、正确性、安全、可维护性和验证证据，不能因为能编译就降低标准。

  • 先读 diff 和调用链，重点检查未授权扩展、复制逻辑、异常路径、并发和权限。
  • 运行相关测试、静态检查和必要的 UI/性能验证，并检查测试是否只迎合实现。
  • 再让 Claude Code 或 Codex 做一次反向审查可以补覆盖面，但最终责任仍在人和仓库门禁。

Q156：如何避免 Agent 用“假验证”宣布任务完成？​

答案汇总：要求提供可复现证据：运行了什么命令、退出码和关键输出是什么，UI 则提供截图或测试轨迹。

  • 不接受“应该可以”“已检查”这类无证据结论。
  • 验证命令必须覆盖变更范围，不能用局部成功替代失败的全量门禁而不说明。
  • 对高风险改动由 CI 或独立 reviewer 复跑，避免实现者同时充当唯一裁判。

Q157：什么是上下文污染或 Context Rot，怎么缓解？​

答案汇总：会话积累大量过期细节、日志和错误方向后，关键信息被淹没，模型表现可能下降；应主动保持任务边界和上下文新鲜。

  • 一个会话围绕一个目标，阶段切换时总结决策、剩余事项和验证状态。
  • 压缩只保留仍有效的信息；方向已完全变化时开新会话并提供干净交接。
  • 大量探索交给 Subagent，只把结论和证据带回主上下文。

Q158：跨会话或跨 Agent 如何交接任务？​

答案汇总：交接应是一份可执行状态快照，包括目标、已完成、关键决策、改动文件、验证结果、已知风险和下一步。

  • 不依赖聊天历史让接手者自己猜，稳定知识写回 AGENTS.md、规则、Skill 或设计文档。
  • 临时进度可写任务说明或 PR 描述，附命令和失败输出。
  • 接手的 Claude Code 或 Codex 先核对 Git 状态与证据，再继续修改。

Q159：如何衡量 AI 编程工具的 ROI？​

答案汇总：同时看交付速度、质量、人工注意力和总成本，并按任务类型比较基线，不能只看生成代码行数或主观“快很多”。

  • 指标包括 lead time、PR 周期、一次通过率、返工、缺陷、审查时间、Token/许可成本。
  • 记录 AI 参与程度和任务复杂度，避免只挑成功案例造成幸存者偏差。
  • 如果速度提高但线上问题、审查负担或安全事件上升，就不是真正的正 ROI。

Q160：面试时如何回答“你平时怎样使用 AI 编程工具”？​

答案汇总：用一个真实任务讲清“选工具—给上下文—先计划—分步实现—自动验证—人工审查—沉淀资产”的完整闭环。

  • 例如用 Claude Code 或 Codex 修复一个前端性能问题：先复现和采样，再定位、改代码、跑测试与浏览器验证。
  • 说明如何用 AGENTS.md、Rules 和 Skills 复用项目知识，如何用沙箱和审批控制风险。
  • 给出可核验结果与一次失败复盘，体现你把 AI 当工程协作者而不是代码生成器。

最后复习建议​

如果时间有限，优先掌握下面这条主线：

你不需要假装懂所有模型训练细节。对于全栈偏前端岗位，更有价值的回答是：能设计可靠交互、理解模型边界、把不确定输出接入确定性系统，并用评测和观测证明功能真的有效。

相关阅读​