code-generation 是什么做的？如何保证准确性
1️⃣ 考察意图
面试官想看你是否理解代码生成（code-generation）不仅是“调LLM输出代码”，而是一个包含模型选择、工程约束、质量完整流程的系统工程。考察类型是系统设计+工程取舍。刁钻点在于：很多人只答“用GPT-4生成代码”，但忽略了准确性保障的可落地性——比如单元测试覆盖率、执行反馈循环、自一致性采样等。答好了能展示你从“模型能力”到“生产级质量”的硬实力，包括对HumanEval、SWE-bench等基准的熟悉度，以及处理幻觉、语法错误、逻辑漏洞的实战经验。
2️⃣ 标准答
code-generation 的核心是将自然语言描述转化为可执行代码，但生产级系统必须解决“生成快但不准”的问题。以下从技术栈、准确性保障、工程取舍三方面展开。
技术栈：
- 模型选型：主流用GPT-4、CodeLlama（34B）、DeepSeek-Coder（33B）等专用模型。它们通过代码语料预训练（如The Stack、GitHub）和指令微调（如CodeAlpaca）提升生成质量。关键点是上下文窗口：CodeLlama支持16K tokens，适合长函数生成；GPT-4的128K窗口能处理多文件依赖。
- 生成策略：Few-shot prompting（给2-3个输入输出示例）比zero-shot提升pass@1约15%。更高级的是Chain-of-Thought：让模型先写伪代码或注释，再生成具体实现，减少逻辑跳跃。
- 检索增强（RAG）：对特定框架（如React hooks）或API（如Pandas），用BM25或DPR检索相似代码片段作为上下文。例如，生成“排序算法”时，注入LeetCode上相似题的解法，提升准确率20%【通用知识】。
准确性保障体系：
- 单元测试验证：这是黄金标准。生成代码后自动运行预定义测试用例（如HumanEval的164个问题），用pass@k指标评估。实际坑：测试用例可能覆盖不全，导致“假通过”。解法是变异测试：对生成代码做小改动（如改边界条件），看测试能否捕获错误，若不能则补充用例。
- 静态分析：用Pyright或ESLint做类型检查、语法校验。例如，生成Python函数时，检查参数类型注解是否匹配；若发现未定义变量，直接拒绝输出并触发重生成。取舍：静态分析快（毫秒级）但只能查表面错误；单元测试慢（秒级）但能查逻辑错误。生产系统通常先静态分析过滤，再用测试验证。
- 执行反馈循环：让模型根据运行错误信息自我修正。例如，生成代码后运行，若报“IndexError”，将错误堆栈和代码片段重新输入模型，要求修复。经验数据：在SWE-bench上，单次修复可将pass@1从30%提升到45%【通用知识】。
- 自一致性采样（Self-Consistency）：生成多个候选（如5个），用投票或聚类选最优。例如，对“计算斐波那契数列”，生成5个版本，选语法正确且测试通过最多的。工程取舍：采样数增加会线性提升延迟（5个候选需5倍推理时间），但准确率提升约10%。实际中设采样数=3，平衡速度与质量。
实际落地的坑+解法：
- 坑1：模型生成“幻觉API”（如虚构的
pandas.DataFrame.merge_all）。解法：用API知识库做约束解码，只允许输出已知API名。例如，在解码时用前缀树（Trie）限制token选择。 - 坑2：长代码生成中断（如超过上下文窗口）。解法：分块生成——先生成函数签名，再逐段生成body，最后用AST合并。例如，生成100行函数时，分3段，每段用
# continue标记衔接。 - 坑3：安全风险（如生成SQL注入代码）。解法：沙箱执行——在Docker容器中运行测试，限制网络和文件系统访问；同时用静态分析扫描危险模式（如
exec()、os.system()）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从模型选型、准确性保障、工程取舍三个层面回答。模型层面，用CodeLlama或GPT-4，配合few-shot prompting和RAG提升生成质量；准确性层面，用单元测试验证+静态分析过滤+执行反馈循环+自一致性采样，形成完整流程；工程取舍上，优先静态分析做快速过滤，再用测试验证，采样数设3平衡延迟。总结一句：code-generation不是模型输出就完事，而是用质量完整流程把准确率从30%推到80%以上。”
4️⃣ 高频追问 & 应对
追问1：自一致性采样和beam search有什么区别？为什么不用beam search？
自一致性采样是独立采样多个候选，然后投票选最优；beam search是在解码时保留top-k路径，但容易陷入局部最优（如重复生成相同代码）。代码生成场景中，beam search的路径共享会导致多样性不足——例如，5个候选可能全是同一逻辑的不同语法变体。自一致性采样通过随机采样（temperature=0.8）增加多样性，投票时用测试通过率或编辑距离做权重。取舍：beam search更快（一次解码），但自一致性采样准确率更高（约+5% pass@1）。实际中，对低延迟场景（如IDE补全）用beam search，对高准确场景（如代码审查）用自一致性采样。
追问2：如何评估代码生成系统的准确性？除了HumanEval还有什么指标？
常用基准：HumanEval（164个Python问题，pass@k）、MBPP（974个问题，更简单）、SWE-bench（真实GitHub issue修复，更复杂）。生产系统还需自定义指标：① 语法正确率：用AST解析，看是否无语法错误；② 功能正确率：用业务测试用例覆盖；③ 安全合规率：扫描危险API调用。坑：HumanEval的测试用例是黑盒，可能漏掉边界条件。解法是变异测试：对生成代码做变异（如改
>为>=），看测试能否捕获，若不能则补充用例。
追问3：如果生成代码在测试中报错，如何设计修复循环？会不会无限循环？
设计有限次修复循环：最多3次，每次将错误堆栈+代码片段重新输入模型，要求输出修复版本。终止条件：① 测试通过；② 达到最大次数；③ 修复后代码与原始代码编辑距离<5（说明模型在绕圈）。实际数据：在SWE-bench上，3次修复可将pass@1从30%提升到45%，但第4次后收益递减【通用知识】。防无限循环：用修复质量评分——若修复后测试通过率未提升，直接回退到原始版本并标记为“需人工审查”。
5️⃣ 避坑 · 常见错误答法
- ❌ 只答“用GPT-4生成代码，然后跑单元测试” → ✅ 必须补充静态分析、执行反馈循环、自一致性采样等完整流程机制，并说明“单元测试只能验证已知用例，无法覆盖所有边界”。
- ❌ 说“自一致性采样就是选出现次数最多的代码” → ✅ 正确做法是：用测试通过率或编辑距离做权重投票，因为“出现次数多”可能只是语法相似，不代表功能正确。
- ❌ 忽略安全风险，只说“生成代码直接执行” → ✅ 必须提沙箱执行和静态扫描，因为生产环境不允许裸跑生成代码（如SQL注入风险）。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索增强代码生成”切入，强调如何用BM25检索相似代码片段作为few-shot示例，并对比无RAG时的准确率提升（如+20% pass@1）。可提你用的检索库（如FAISS）和索引构建细节。
- 如果你只做过传统NLP：用“机器翻译”类比——代码生成类似翻译，但需要语法检查（静态分析）和语义验证（单元测试）。强调你熟悉序列到序列模型（如T5）和beam search，但能迁移到代码场景。
- 如果你是校招无项目：聚焦HumanEval基准复现，用CodeLlama-7B做demo，实现few-shot prompting+自一致性采样，并在GitHub上开源。强调你理解pass@k指标和采样策略的trade-off。
- "CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis"（Salesforce, 2022）
- "Self-Consistency Improves Chain of Thought Reasoning in Language Models"（Wang et al., ICLR 2023）
- "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?"（Jimenez et al., 2024）
- "Static Analysis for Code Generation: A Practical Guide"（Pyright官方文档）
- "The Stack: A 3TB Dataset for Code Generation"（Kocetkov et al., 2022）