generalsの学习笔记

Appearance

大模型 LLM 与 AI Coding — 面试题 ​

更新: 5/15/2026 字数: 0 字 时长: 0 分钟

Q1：简单解释一下 Transformer 的工作原理 ​

回答：

Transformer 的核心是 Self-Attention（自注意力）机制。处理一个序列时，每个 Token 都会去"关注"序列中的其他 Token，计算它们之间的相关度，然后根据相关度加权融合信息。

具体来说，每个 Token 生成 Q（Query）、K（Key）、V（Value）三个向量。Q 和 K 做点积得到注意力分数，经过 Softmax 归一化后作为权重，对 V 加权求和得到输出。

相比 RNN 的串行处理，Transformer 可以完全并行计算，而且每个 Token 都能直接关注到任意距离的其他 Token，解决了长距离依赖问题。

追问：GPT 和 BERT 的区别？

GPT 只用 Decoder，用 Masked Attention（只能看前面的 Token），适合生成任务。BERT 用 Encoder，用双向 Attention（能看前后），适合理解任务（分类、抽取）。现在的 LLM（ChatGPT、Claude）都是 GPT 类的 Decoder-only 架构。

Q2：LLM 是怎么生成代码的？ ​

回答：

LLM 生成代码和生成自然语言的原理完全一样——自回归地一个 Token 一个 Token 生成。

模型在预训练阶段学习了大量代码（GitHub 上的开源代码），学会了代码的语法、模式和逻辑。当你给它一个 Prompt（比如"写一个 Kotlin 单例"），它根据训练中学到的模式，逐步预测下一个 Token，直到生成完整的代码。

代码补全工具（如 Copilot）用的是 Fill-in-the-Middle（FIM）技术，模型同时看到光标前后的代码，预测中间应该填什么，所以补全的代码能和上下文完美衔接。

追问：为什么有时候生成的代码有错误？

因为模型是基于概率预测的，它选择的是"最可能的下一个 Token"，不是"一定正确的 Token"。它不会真正执行代码或做类型检查。所以可能生成语法正确但逻辑错误的代码，或者调用不存在的 API（幻觉）。这就是为什么 AI 生成的代码需要人工审查。

Q3：什么是 RAG？在 AI Coding 中怎么用？ ​

回答：

RAG（Retrieval-Augmented Generation，检索增强生成）是先检索相关信息，再让模型基于这些信息生成回答。

在 AI Coding 中的应用：模型不知道你的项目代码，但通过 RAG，工具可以先在你的代码库中检索相关文件和函数，把它们作为上下文注入 Prompt，模型就能基于你的实际代码给出准确的建议。

实现方式：

  1. 离线阶段：把项目代码切分为片段，用 Embedding 模型转为向量，存入向量数据库
  2. 在线阶段：用户提问 → 问题转为向量 → 在向量数据库中找最相似的代码片段 → 注入 Prompt → 模型生成回答

追问：Embedding 是什么？

Embedding 是把文本/代码映射为固定长度的数值向量。语义相似的内容，向量也相似。比如 getUser(id) 和 fetchUser(userId) 的向量很接近，但和 deleteAll() 的向量差距很大。通过计算向量的余弦相似度，就能找到语义最相关的代码片段。

Q4：AI Agent 和普通的 AI 对话有什么区别？ ​

回答：

普通对话是一问一答：你问一个问题，模型回答一次，结束。

Agent 是一个循环：模型可以自主规划多个步骤，使用工具（读文件、编辑代码、运行命令、搜索），根据每一步的结果决定下一步做什么，直到任务完成。

核心区别在于 Agent 有"工具使用"能力（Function Calling）。模型不是直接输出文本，而是输出结构化的工具调用请求（比如 {"tool": "read_file", "path": "xxx"}），系统执行后把结果返回给模型，模型再决定下一步。

追问：Function Calling 是怎么实现的？

模型在训练时学会了一种特殊的输出格式。System Prompt 中定义了可用的工具列表（名称、参数、描述），模型根据当前任务判断需要调用哪个工具，输出 JSON 格式的调用请求。这不是模型真的在"执行"工具，而是模型生成了一段结构化文本，由外部系统解析并执行。

Q5：什么是 MCP？ ​

回答：

MCP（Model Context Protocol）是 Anthropic 提出的标准化协议，用于 AI 模型和外部工具之间的通信。

之前每个 AI 工具都要自己实现和各种外部系统的对接（Git、数据库、Jira 等），重复造轮子。MCP 定义了一个标准协议，工具提供者实现 MCP Server，AI 工具支持 MCP 协议，就能互相对接。

类似于 USB 协议：有了统一标准，任何设备都能连接任何电脑，不需要每个设备配专用接口。

追问：MCP 和 Function Calling 的关系？

Function Calling 是模型层面的能力——模型能输出工具调用请求。MCP 是通信协议层面的标准——定义了 AI 工具和外部服务之间怎么交互。Function Calling 决定"模型要调用什么工具"，MCP 决定"这个调用怎么传递给工具提供者"。

Q6：LLM 的训练分哪几个阶段？ ​

回答：

三个阶段：

  1. 预训练：在海量文本（万亿 Token）上训练，学习语言的通用知识。任务是预测下一个 Token。训练完后模型是一个"补全机器"，能力很强但不会对话。

  2. SFT（监督微调）：用人工标注的对话数据（几万到几十万条）训练，让模型学会对话格式。训练完后模型知道什么时候该回答、用什么格式回答。

  3. RLHF（人类反馈强化学习）：让模型生成多个回答，人类标注哪个更好，训练一个奖励模型，再用强化学习优化 LLM。让模型的回答更有帮助、更安全。

追问：为什么预训练需要那么多数据？

因为预训练的目标是让模型学会"世界知识"——语法、常识、逻辑推理、代码模式等。这些知识分布在海量文本中，需要足够多的数据才能覆盖。而且模型参数越多（175B+），需要的数据也越多，否则会欠拟合。

Q7：Temperature 和 Top-p 是什么？ ​

回答：

两者都是控制模型输出随机性的参数。

Temperature：调节概率分布的"尖锐程度"。T=0 时永远选概率最高的 Token（确定性输出）；T 越高，低概率 Token 被选中的机会越大（更随机、更有创意）。写代码通常用低 Temperature（0-0.3），写创意文案用高 Temperature（0.7-1.0）。

Top-p（核采样）：只从累积概率达到 p 的 Token 中采样。p=0.9 表示从概率最高的那些 Token（累积概率 90%）中随机选，排除了概率极低的 Token，避免生成离谱的内容。

追问：代码生成应该用什么参数？

代码生成通常用低 Temperature（0-0.2）+ Top-p 0.9。因为代码需要确定性和正确性，不需要太多"创意"。但如果是探索性的代码生成（比如"给我几种不同的实现方案"），可以适当提高 Temperature。

Q8：端侧大模型（On-Device LLM）有什么挑战？ ​

回答：

主要挑战是手机的硬件限制：

  1. 内存：7B 模型 FP16 需要 14GB，手机总共才 8-16GB。解决方案是量化——把 FP16 压缩到 INT4，7B 模型只需要 3.5GB。

  2. 算力：手机 GPU/NPU 远弱于服务器 GPU，推理速度慢。解决方案是用更小的模型（1B-3B）+ 硬件加速（NPU）。

  3. 功耗：持续推理会快速耗电发热。需要控制推理频率和模型大小。

目前端侧适合轻量级任务（文本分类、简单问答、输入建议），复杂的代码生成还是需要云端大模型。

追问：Android 上怎么集成端侧模型？

可以用 Google 的 MediaPipe LLM Inference API 或 TensorFlow Lite，加载量化后的模型（如 Gemma 2B INT4）。通过 NNAPI 调用 GPU/NPU 加速推理。也可以用 llama.cpp 的 Android 移植版本运行 LLaMA 系列模型。

Q9：如何更好地使用 AI Coding 工具？ ​

回答：

几个关键原则：

  1. 提供充足的上下文：不要只说"写个网络请求"，要说明技术栈、参数、返回类型、错误处理方式、参考已有代码的风格。

  2. 分步骤提问：复杂任务拆成小步骤，每步确认后再继续，而不是一次性要求生成整个功能。

  3. 给示例（Few-shot）：给模型一两个你项目中已有的代码示例，让它模仿风格。

  4. 审查生成的代码：AI 生成的代码可能有逻辑错误、安全漏洞、性能问题。不要盲目接受，要理解每一行代码。

  5. 理解局限性：模型不知道你的运行时状态、不会执行代码、可能产生幻觉（编造不存在的 API）。把它当作一个很强的助手，而不是万能的。

Q10：Prompt Engineering 有哪些实用技巧？ ​

回答：

  1. 明确角色：在 Prompt 开头定义模型的角色，比如"你是一个资深 Android 开发者"。

  2. 结构化需求：用列表或编号明确列出需求，而不是一段模糊的描述。

  3. Chain-of-Thought：让模型"一步步思考"，先分析问题再给方案，比直接要答案更准确。

  4. 约束条件：明确告诉模型不要做什么，比如"不要使用已废弃的 API"、"不要添加额外的依赖"。

  5. 迭代优化：第一次生成不满意，不要重新开始，而是在对话中追加修改要求，利用上下文逐步完善。

追问：为什么 Chain-of-Thought 能提升效果？

因为 LLM 是自回归生成的，每个 Token 的生成依赖于前面的 Token。当模型先输出分析过程时，这些中间推理步骤成为后续生成的上下文，帮助模型做出更准确的判断。相当于给模型提供了"草稿纸"来思考，而不是要求它直接给出最终答案。

实习面试补充：AI Coding 实用型问题 ​

AI Coding 对实习面试通常是加分项。重点不是“会不会让 AI 写代码”，而是能否用它提高效率，并对结果负责。

Q11: 用 AI 辅助写代码时，怎么保证结果可靠？ ​

考察点：工具使用、工程责任

完整回答：

AI 生成的代码不能直接无脑合入，需要自己校验：

  • 检查 API 是否真实存在，是否已废弃。
  • 检查线程、生命周期、空指针、异常处理等 Android 常见风险。
  • 运行项目和测试，确认功能正确。
  • 对关键逻辑自己重新理解一遍，不能只会复制。
  • 对涉及安全、支付、隐私、加密的代码尤其谨慎。

加分点：可以让 AI 解释报错、生成样板代码、补测试用例，但最终代码质量由开发者负责。

Q12: 实习项目中适合让 AI 帮你做什么？ ​

考察点：效率意识

完整回答：

适合的场景：

  • 解释陌生代码和报错日志。
  • 生成 Retrofit 接口、Room Entity、Adapter 等样板代码。
  • 帮忙整理 README、接口文档、测试用例。
  • 给出排查思路，比如 ANR、Crash、网络失败。
  • 辅助学习新 API，但需要再查官方文档确认。

不适合完全交给 AI 的场景：

  • 不理解就直接提交核心业务代码。
  • 让 AI 编造接口字段、业务规则或线上结论。
  • 不做运行验证就合并代码。