企业官网建设流程全解析

“能不能说说你最近用 AI coding 工具做什么项目？”，如果是在传统技术面试里，这问题顶多是个暖场。但在 2025 年，这几乎成了 AI coding 类岗位面试的第一道正餐。我这两年被问过不少次“你们公司 AI coding 类项目的面试到底怎么面”，也实际参加过多场相关方向的面试，今天就用阿里巴巴这类大厂的情况做个例子，聊聊这类面试真正在考什么、怎么准备，以及网上那些“AI coding 笔试教程”和“AI coding 答题思路”里很少讲清楚的潜规则。

先说个结论：AI coding 类岗位的面试，根本不是考“你会不会用 Copilot”或者“你熟不熟悉 ChatGUT 的用法”。面试官想知道的，是你有没有能力去构建、评估、优化一个 AI 编程助手，或者把一个 AI coding 项目落地到真实的研发流程里。工具使用只是最底层的东西，往上还有模型认知、Agent 机制设计、评测体系、工程化落地、甚至安全合规。下面我拆开讲。

1. 这类面试到底在面什么：从“岗位类型”到“考察维度地图”

1.1 AI coding 相关岗位不是一种，是三种

很多人上来就吼“我要面 AI coding 岗位”，但打开招聘网站会发现问题没这么简单。大厂里的 AI coding 相关岗位通常可以粗分成三类，它们的面试侧重点差别非常大。

第一类是 AI 应用开发方向，做的是把大模型能力封装成具体功能，比如智能代码补全插件、代码解释器、自动生成单测的工具。这类岗位最看重工程能力，要求你懂后端架构、懂 API 设计、懂模型调用的成本控制。面试时候深入拷问网络框架、超时重试、流式响应、插件系统设计这些传统工程问题。

第二类是算法/模型方向，做的是代码模型微调、数据 pipeline 构建、代码向量化、评测集设计等。这类岗位更看重大模型训练的基础知识，从数据清洗、指令微调、RLHF 到代码特定的预训练任务都可能被问到。

第三类是研发效能/平台方向，做的是把 AI coding 能力接入公司的整个研发流程，涉及 IDE 插件、CI/CD 集成、代码评审助手、需求到代码的闭环系统。这类岗位需要你理解整个软件研发链路，并且知道 AI 在哪个环节能产生最大价值。

我遇到过不少候选人，面的是第三类岗位，准备的全是第一类的东西，最后双方都很痛苦。所以准备面试前，先校准你投的岗位是哪一类，别拿一套内容去应付所有 AI coding 面试。阿里巴巴这类大厂内部，三条线的面试风格差异确实不小，面试官问的问题维度完全不同。

1.2 面试官视角下的考察维度地图

我自己的经验，无论是哪一类岗位，面试官通常会沿着一张隐形的“考察维度地图”去筛人。这张地图大概有五层。

第一层是基础认知层。你有没有真正用过主流 AI coding 工具，知不知道 GitHub Copilot、Cursor、通义灵码这类产品各自的能力边界和短板。

第二层是模型原理层。你能不能讲清楚 LLM 生成代码的底层逻辑，比如 token 是如何影响补全效果、context window 对超大仓库的制约、温度参数为什么会影响代码生成的确定性。

第三层是 Agent 与工具链层。现在 AI coding 已经从单次补全走向多步骤 Agent，你能不能设计一个会自己读文件、跑测试、修 bug 的循环系统，如何做任务拆解，如何设计 function calling，怎么避免 Agent 在错误方向上反复横跳。

第四层是评估与数据层。这是大厂面试里特别爱深挖的一层。你说你的 AI coding 工具好用，怎么量化？HumanEval 和 MBPP 跑分高，代表在内部代码库上表现好吗？如何构建贴合自己公司场景的评测集？

第五层是工程化与安全层。代码版权、许可证合规、私有代码泄露风险、模型输出的安全性过滤，这些都是 AI coding 项目上生产环境必须面对的问题，大厂尤其看重。

很多候选人挂在第二层和第四层。工具用得挺溜，但说不出原理，也拿不出数据来证明方案有效。后面几个章节，我针对笔试、技术面试、项目讲述、临场应答分别展开，这些维度的考察会反复出现在各个环节里。

2. 笔试环节：不是考算法，而是考“你会不会用 AI 解决问题”

2.1 笔试题目长什么样

AI coding 类岗位的笔试，跟传统算法笔试有相似之处，但差异也很关键。传统笔试给你一个算法题，你默默写完之后点了提交。AI coding 类的笔试，通常有几种题型混着出。

一种是比较直接的代码生成/补全题。给你一个函数签名和上下文，让你补全逻辑。或者给你一个 bug，让你修复。这种题本身难度往往不大，LeetCode 中等偏下水平，但它考察的是你能不能在有限时间内写出干净可靠的代码。

还有一种是设计题。比如给你一个场景：要在 CLI 里做一个基于大模型的代码解释工具，你给出整体设计。这种题不要求你把代码全写出来，但要求你的设计方案体现出对 prompt 构造、工具调用、错误处理的理解。

第三种特别有意思，是带约束的 coding 题。题目会明确告诉你“可以用 AI 辅助编码，但必须给出你使用的 prompt 和关键交互过程”。这就把考察重心从“你代码写得多好”转移到了“你能不能指挥好 AI 写出好代码”。我见过很多候选人平时用 AI 写代码很顺手，但真到这种题上反而暴露了软肋——要么不敢用 AI，要么 prompt 写得稀烂，要么完全不验证 AI 的输出。

2.2 用 AI 答题的正确姿势

如果你拿到的是允许使用 AI 助手的笔试，这里面的门道可太多了。先说一个常见误区：很多人以为题目来了直接复制粘贴给 AI 就行。这相当于把 AI 当做“答案生成器”，而在有经验的面试官眼里，你的提问方式直接暴露了你的工程素养。

正确的姿势分四步走。

第一步，先把题目吃透，拆解成子任务。好比你要实现一个函数，先明确输入、输出、边界条件。如果这块都不想做直接丢给 AI，AI 大概率会给你一个“看起来很对但跑不过测试”的答案。

第二步，把拆解完的子任务结构化地喂给 AI。我见过一个不错的 prompt 写法是这样的：

你是一名资深 Python 工程师。请实现一个函数 parse_config(path)。 需求： 1. 文件格式为 JSON，但允许注释行（// 开头）。 2. 解析失败时返回空 dict，不要抛出异常。 3. 需要支持嵌套结构。 约束： - 不要引入第三方依赖。 - 请提供完整的函数实现和两个测试用例。 - 如果你认为需求中有歧义，请列出你的假设。

这个问题本身不难，但这样提问，AI 给出的代码质量会明显好于“帮我写个 parse_config”这种指令。原因在于你替 AI 做了需求澄清和约束设定。笔试时的时间有限，不会让你真去写几百行代码，但你的 prompt 组织方式能反映出真实开发时你如何跟 AI 协作。

第三步，也是我会重点提醒的：对 AI 的产出做验证。AI 生成代码之后，不要直接复制走人。你要跑一遍测试，看边界条件，甚至故意想两个刁钻案例去试它。这个“验证 AI 输出的行为”，在大厂笔试题的评分里，权重比大部分候选人以为的要高。因为生产环境中你不可能让一个“看起来很对的 AI 输出”直接进代码库。

第四步，把对话记录整理好。如果笔试平台要求你提交 prompt 和交互过程，那就意味着面试官会看你的 prompt 思路。不要只贴代码，要在关键节点简单注释一下你的思考过程，比如“这里我让 AI 先列出假设，是为了避免它默认文件不含注释”。这种注释，可以让面试官一眼看到你的工程判断力。

2.3 一个真实的答题思路反例

我给一次模拟面试出过一道题：给一段有并发问题的多线程代码，让候选人用 AI 辅助修复。有个候选人直接用 AI 生成了一段加锁的代码，看起来逻辑没问题，但你仔细看他生成的代码，是在方法上粗暴加了一个 synchronized。

这道题背后其实想考的是候选人对锁粒度的理解。如果对性能没有追求的简单场景，加 synchronized 确实不算错。但题目里特别强调“这是一个高并发读、低并发写”的场景，那反正读写锁或者 CopyOnWrite 更加合理。

我看这个候选人的过程记录，他从头到尾没有在 prompt 里提到“高并发读、低并发写”这个关键信息，AI 自然就给了一个最朴素的答案。他也没有对 AI 的答案提出任何质疑。

这就是一个典型的“会用 AI，但不会架构”的案例。笔试之后，负责面试的同事跟我反馈说，这个候选人代码功底不难看，但缺少一种关键意识——把问题域的关键约束转化为对 AI 的明确指令。这道题他其实败在 prompt 上而不在代码上。

所以你在准备笔试的时候，别光刷题，可以做一项针对性练习：拿一道你以前做过的算法或工程题，把约束条件整理成一段清晰的文字，再让 AI 来解。多练几次之后，你会明显感觉到 AI 输出质量的差异。

3. 技术面试核心要点：模型机制、上下文工程和 Agent 设计

3.1 开口不要谈“咒语”，要谈模型机制的取舍

我一直有一个判断：AI coding 面试和传统面试最本质的区别，是它既会问你“为什么这么写”，也会问你“为什么选这个模型”“为什么用这种调用方式”。所以在技术面试环节，你不能只停留在 prompt 技巧层面，需要对模型机制的底层逻辑有认知。

举个例子。面试官可能问：你在做代码补全时，为什么选择用 FIM（Fill-In-the-Middle）训练过的模型，而不是普通对话模型？

这个问题如果只回答“因为补全效果更好”，就浪费了一个展示机会。你可以说：代码补全场景下，模型需要同时感知光标前和光标后的代码，传统 causallm 只能根据前文预测后文，而 FIM 把“填空”任务转化为模型能理解的形式，让它在训练时见过这种“中间补全”的样本，推理时才能正确处理后缀信息。它用到了一个关键细节：FIM 会引入 sentinel token，模型需要学会不把特殊 token 混入业务代码。

再比如面试官问：参数 temperature 设成 0 和 0.2 在代码生成上有什么区别？别看这问题基础，真能答透的人不多。你要说的不只是“数值越大越随机”，而是要结合场景讲：代码生成追求确定性，temperature 太高容易让模型产出幻觉性 API 调用，但在生成测试数据或者做数据增强时，反而希望 temperature 高一些来制造多样性。回答里有具体的场景映射，面试官才觉得你真的用过而不是背过。

3.2 上下文工程：AI coding 最核心的工程话题

上下文工程是我个人认为 AI coding 项目面试中最值得准备的主题，没有之一。原因很简单：代码补全和代码生成的质量，一半以上取决于你往模型上下文里塞了什么。

一个常见问题是：如果要把一个大型 monorepo 的代码库接入 AI 编码助手，上下文窗口有限，你如何设计上下文构建方案？

一个合格的回答至少要覆盖这几层。

第一层是检索层。你不可能把整个仓库塞进去，所以要引入代码检索，包括基于 embedding 的语义检索、基于符号表的精确检索、基于文件依赖关系的关联检索。面试中你能提到“需要把 import 关系强化检索”“当前打开文件的符号表要优先进入上下文”，就说明你有真实落地经验。

第二层是结构层。把哪些内容放前面、哪些放后面是有讲究的。当前文件的光标位置前后代码是最高优先级，然后是相关定义、函数签名、调用关系。有些系统会先让模型预测需要哪些文件，再动态加载，这种基于 agent 的上下文选择机制值得展开讲。

第三层是压缩层。把长文件截断时，保留什么丢弃什么，要用启发式规则。比如保留类声明、函数签名、TODO 注释，而不是无脑取前 2000 token。你要能给面试官讲出一个具体的压缩策略，哪怕是看起来简单的“优先保留含 public 方法的行”，也比泛泛说“用 embedding 做检索”更落地。

3.3 Agent 设计：怎么把“会写代码”变成“能干完一个活”

现在技术面试里越来越高频的一块是 Agent。AI coding 已经从“写一个函数”走向“完成一个任务”。比如给你一个 issue 描述，Agent 自动完成代码修改、测试运行、bug 修复、最终提交 MR。面试官想知道的是，你有没有设计过这类循环系统。

先从最基础的 ReAct 框架讲起。ReAct 的核心是让模型交替进行推理（Reasoning）和行动（Action）。在 coding 场景里，推理表现为“我怀疑这个 bug 出在配置解析模块”，行动表现为“打开 settings.py 查看第 42 行”。面试时你要能把这套框架翻译成具体的 coding 工具链。

然后是很容易被忽略的 function calling 设计。你的 Agent 要调用哪些工具？一般会有 search_files、read_file、write_file、run_test、execute_command 这几个基础工具。但真正区分高下的，是你如何处理工具返回结果。如果 run_test 失败了，你怎么从报错栈里提取有效信息回传给模型？这里有个细节：不要直接把整段报错文本塞给模型，因为 token 浪费而且噪声大。我会先做一个栈帧压缩，只保留前几个栈帧和核心错误信息，重组后丢给模型，这一步能显著提高 Agent 修复 bug 的成功率。

另一个关键点是规划机制。一次任务涉及多个文件修改，是让 Agent 一次性规划完再执行，还是走“规划-执行-反馈-再规划”的小循环？我的经验是，对复杂任务，采用“渐进式规划”更可靠。不要让模型一开始就输出一个包含 15 个步骤的大计划，而是让它先做 Step1、观察结果、再决定 Step2。这背后其实是对模型“长链路规划能力不稳定”这个缺陷的妥协。面试里能讲清这个设计取舍，比背一堆概念有用得多。

你还可以提一个平时很容易被忽略但实际发生过很多次的问题：Agent 陷入死循环。模型发现自己改了一个文件，测试挂了，又去改另一个文件，结果把第一个文件又改回去了。这种场景避免死循环的方案包括：限制最大迭代轮数、对文件修改设置版本号、每次修改前记录前一轮的状态摘要。这些细节一讲出来，面试官基本能认定你有真实落地过同类项目。

4. 项目经验怎么讲，才不会被当成“只会调 API”

4.1 一句话概括你的项目：别把 API 调用当项目核心

面试官让你介绍项目时，很多人三句话不到就开始说“我调了大模型的 API 做了个代码补全工具”。这句话一出，你在面试官心中的定位就变成了“只会调 API 的工程师”。

你的项目介绍应该从问题出发。比如：我在团队内部发现，新入职的工程师对老项目的代码结构不熟悉，经常花很多时间找某个配置项是在哪里定义的。于是我设计了一个基于 RAG 的代码问答系统，把项目的关键配置文件、模块说明、最近变更记录做了索引，用检索增强的方式让大模型回答这类问题。做完之后，新员工平均定位一个配置项的时间从 20 分钟降到了 3 分钟。

你这样介绍，面试官抓住的全是有效信息：你清楚问题边界、做过取舍、有量化结果。他可能接着问：为什么用 bge-m3？为什么用重排？你可以继续展开。而你如果只说“我调了 API”，下一个问题就是“调了哪个 API”，然后就没有然后了。

4.2 高频追问：效果怎么量化、失败怎么兜底

我在模拟面试中经常扮演追问型面试官。介绍完项目后的 5 分钟内，我通常会用三个问题来检验项目的真实程度。

第一个问题：你项目里这个 AI coding 功能，准确率或者通过率到底是多少？你说的“效果不错”，是怎么量化出来的？

很多候选人这时候就答不出来了。其实你要的不是一个多高的数字，而是你有没有构建过一套评估流程。你可以说：我自己标注了 50 个真实代码补全场景，人工判断 AI 输出是否可直接采用，初始通过率只有 62%。后来我把项目结构信息强制加入 prompt，通过率提到了 78%。提升到 78% 之后，再怎么调 prompt 都上不去，我怀疑单纯靠 prompt 已经到瓶颈了，下一个版本打算针对仓库上下文构建一个检索器。

这段回答里最亮眼的不是 78%，而是“我看到瓶颈在上下文而不是 prompt”。这句话意味着你有归因分析能力。

第二个问题：如果模型输出明显错误代码，还一本正经生成了不存在的 API，你怎么处理？

不要只回答“加一层校验”。要具体说：我会把模型生成的代码先过一次语法解析，比如 Python 就用 ast.parse 做静态检查，同时把生成代码里引用的库函数跟项目里的依赖清单做一次交叉比对。这不能拦截所有错误，但能挡住大概率问题。再有就是强制要求模型在生成代码时先列出它假定的 API 签名，再从代码库中确认这些 API 真的存在，这一步是让模型自己先过一遍“文档检查”。

第三个问题：这个项目如果模型效果不够好，但又要上线，你会怎么做？

这是一个特别典型的工程化问题。我当时给的回答是：先上一个人工介入率指标，设定一个阈值，低于阈值就自动放行 AI 的补全建议，高于阈值就转人工。上线之后连续看一周的数据，如果某类场景的介入率特别高，就把这类场景单独摘出来，暂时关闭 AI 建议，只保留代码高亮和跳转这些不依赖模型的原生功能。这种思路在面试中能体现出你做项目时的“风险思维”。

4.3 三个容易让面试官皱眉的讲述错误

项目讲述环节最容易踩的坑，我总结成“三不要”。

不要过度归功于模型。有些候选人为了显得紧跟潮流，把项目的所有亮点都说成“因为我们用了最新的大模型”。这种回答听起来毫无个人技术的贡献。你应该明确区分哪些是靠模型能力现成实现的，哪些是你为了解决实际场景做的工程优化。

不要只讲做了什么，不讲为什么选它。你在项目里用了微调，面试官会追问为什么不用 RAG。你在项目里选了 FastAPI 而不是 Flask，面试官可能追问两者在这个场景下的差异。每一个技术选型背后都要给出决策理由。如果理由只是“大家都这么用”，面试官会怀疑你的项目参与深度。

不要编造指标和数据。这点看起来不需要提醒，但确实有不少人为了让项目效果好看，在回答里编了一个“准确率达到 96%”之类的数字。面试官一旦追问“你这个 96% 是怎么算的”，整个回答开始漏洞百出。我见过本来项目挺扎实的人，因为在指标上含糊其辞，反而让面试官对他整个项目的真实性产生了怀疑。数据不需要漂亮，但一定要能被解释、能被复现。

4.4 项目准备的实操清单

按我自己的经验，面试前一天可以花几个小时做一次“项目梳理冲刺”。具体做五件事。

第一，把项目里 5 个最重要的技术选型写成卡片，每个卡片包含三要素：备选方案、你为什么选择当前方案、放弃备选方案的原因。比如你选用了流式输出，备选方案是一次性输出，放弃一次性输出的理由是在大文件补全场景下首字延迟太高。

第二，准备一组 TP2 风格的数据。最好有一个失败的案例，讲清楚你当时的思路、中间遇到了什么问题、最后怎么绕过去的。面试官普遍对失败案例更感兴趣，因为它更能体现真实的技术场景和问题解决能力。

第三，把项目的核心模块画一张架构草图，不只是自己看，还要能在白板上画出来。如果面试中面试官说“能画一下你的系统架构吗”，你如果从数据库开始画到前端页面，但没有体现大模型调用的位置、缓存策略、失败降级逻辑，基本就说明你对系统整体性的把握不够。

第四，准备一段对“下一步优化方向”的描述。这个看似简单，很多人答不好。不要说什么“把模型换得更大”，应该具体一些，比如“我准备把当前基于规则的上下文截断逻辑替换成一个可学习的 reranker”。这种回答才有信息量。

第五，重新读一遍自己项目的核心代码，尤其是 prompt 拼接、上下文窗口管理、结果过滤这三块。很多候选人对项目整体很熟，一被问到具体实现细节就开始支支吾吾。大厂面试官往往会在你意想不到的细节点往里钻。

5. 现场答题：那些容易被误解的“大厂经典问题”

5.1 “你用 AI coding 提效吗”到底在问什么

技术面阶段，面试官可能会用一些看似随意的问题暖场。其中最常见的就是“你平时用 AI coding 工具吗”。很多候选人以为这是一个带肯定答案的送分题，用“用啊，我每天都在用 Cursor 写代码”来回答就结束了，但实际上这是一个需要小心处理的动作。

面试官问这个问题，背后是想了解你的 AI 使用深度和思考方式。如果只是简单回答“用”，他觉得你只是把 AI 当高级补全工具。更好的回答方式是：有用，我在项目里用 AI coding 做代码生成和单测框架搭建，同时我也知道它的短板，比如多文件联调时它经常丢失上下文，所以我会把一个大任务拆成多个小任务分步喂给 AI。

你也可以主动提到一些具体细节来展示深度。比如“我会让 AI 先写单测，通过跑测试来验证它的理解是否正确”，在这种描述里，你其实是在展示你已经隐隐意识到一个更高级的原理：用测试作为 verification signal 来驱动代码生成。面试官听到这里多半会顺着往下问“那你怎么设计这个验证闭环”，一下就进到了核心考察地带。

5.2 “AI 会取代程序员吗”背后的考察点

这个题目几乎成了 AI 时代的面试必问题。但大部分候选人答得很差。要么高举“AI 绝对不可能取代人类”，显得缺乏对新技术的理性判断；要么反过来高呼“AI 很快会取代所有程序员”，这种回答也容易被面试官质疑你缺乏对软件工程复杂度的认知。

我的建议是，不要直接站队，而是从能力结构上拆解。你可以说：AI coding 目前擅长的是局部代码生成和重复性任务抽取，比如从注释生成函数、从单测反推实现、从 API 文档生成调用代码。但一个完整的软件系统里，大量工作是需求澄清、方案权衡、跨模块一致性维护，这些恰恰是当前 AI coding 最不擅长的。所以与其说是“取代”，不如说是一个持续的重分工过程：程序员会把更多精力放到评审、架构、反馈闭环这些环节上。

这个回答的背后展示的是你对 AI 能力边界的认知。面试官通常听得出来，你是在复读观点还是有自己的工程判断。

5.3 开放设计题：从一句话里抓出隐藏约束

场景设计题在 AI coding 类面试中出镜率很高。比如“如果要给一个代码助手设计一个新功能，你会怎么做”，这种开放题看似没有标准答案，但面试官心里有若干条隐含的评分线。

你需要先弄清楚需求。比如对方说“给代码助手增加自动生成 commit message 的功能”，不要急着说“可以用 diff 摘要加 prompt 调大模型”。先明确几个关键约束：代码的 diff 有多大、模型是否支持长上下文、commit message 要遵循什么风格规范、要不要兼容本地化语言。

然后完整的设计流程应该有：需求定义、方案设计、效果评估、兜底机制。生成 commit message 这个功能，效果评估可以用一个小的标注集来测试“生成 message 跟人工 message 的语义一致性”；兜底机制可以是“如果模型不可用，自动退回到从 diff 里提取关键词拼一个基础 message”，而不是直接报错。

大厂面试官在开放设计题中特别看重“你有没有提出边界条件”这个能力。比如你会说“这个功能只会作用在工作区未提交的 change 上，不会去解析所有历史记录；如果 diff 过大，超过模型上下文窗口，我直接跳过 AI 生成，用规则生成简化 message”。这样短短几句话，体现的是你在真实系统中养成的风险意识。

5.4 候选人反问环节：问什么能加分

面试最后，面试官通常会问“你有什么想问我的”。很多人直接说没问题，这是浪费了最后一个展示机会。

比较合适的反问分为三类。第一类是问业务场景，比如“你们现在的 AI coding 工具在落地时遇到的最大瓶颈是模型推理成本还是用户采纳率”。这个问题表明你关注实际落地，而不是只是概念层面的兴趣。

第二类是问团队技术栈，比如“你们的 Agent 方案里，工具调用的失败重试策略是怎么设计的”。这个问题既展示了你的技术理解，也能帮你判断这个团队的技术深度。

第三类是问岗位预期，比如“这个岗位三个月内最重要的产出指标是什么”。这个问题能帮你来判断岗位的核心考核点，也能避免进去之后才发现和想象的不一样。

我做一个面试官时的真实感受是，候选人在反问环节提出高质量问题，对他的整体评价会有明显加分。因为它表明你不只是在“被考核”，而是在认真判断“这段工作经历是否适合我”。一个有经验的工程师应该有这种双向选择的心态。

6. 代码评测和工程化落地：大厂面试里最不起眼但最硬的“暗礁”

6.1 HumanEval 高分不等于业务好用

聊到 AI coding 项目的效果，很多候选人喜欢提 HumanEval 分数。这时候面试官往往会追问一句：“你的项目在业务代码上表现怎么样？” 如果你分不清公开基准和业务场景评测的区别，很容易在这个地方栽跟头。

我遇到过一个候选人，他做的代码生成项目在 HumanEval 上表现很好，但他完全说不清在真实业务代码上的表现。后来我们一聊，发现他所谓的“好用”就是自己找一个代码仓库随手试了一下，觉得生成结果差不多就上线了。这种做法的风险在于，拿通用基准测出来的效果很可能在业务字段名、私有库依赖、内部框架 API 上严重水土不服。

要在面试里体现专业度，至少要能说出核心评测思路：要构建一个贴近业务场景的私有评测集，并且包含三个部分。一部分是真实历史代码的“输入代码上文+期望的补全片段”；一部分是高频 API 调用场景的“代码骨架，让模型补齐关键逻辑”，另一部分则是错误修复场景的“带 bug 的代码+期望修复后的代码”。然后统一用 execution-based metric，也就是把模型生成的代码放到沙箱里跑测试，用测试通过率来衡量效果，而不是只看 BLEU 之类的文本相似度指标。

如果你还能补充一句“我们不仅看通过率，还看首 token 延迟跟内存在 CPU 机器上的占用”，面试官立刻会把你归到“做过工程落地”那一类人里。

6.2 评测闭环：代码助手迭代的引擎

面试官如果继续追问“你的项目怎么持续迭代”，你就可以开始讲评测闭环了。这也是我觉得一个 AI coding 项目能不能真正落地的大分水岭。

一个合格的评估闭环至少要有三层。

第一层是回归评测。每次 prompt 或模型版本变更，都要跑一遍固定的测试集，确保新改动不导致已有能力回退。这看起来很简单，但真能在项目里做到的团队并不多，因为代码生成的测试集构建成本高。

第二层是线上采样评估。在真实用户请求里按策略抽样（比如按文件类型、按语言、按操作类型分层采样），然后人工或者用 LLM 作为 judge 打分。这里有一个关键细节：LLM 打分时很容易被 prompt 影响，必须提前定义清晰的打分 rubric，比如“是否满足需求”“是否可编译”“是否有明显安全性问题”。

第三层是灰度对比评估。新模型上线前，跟旧模型做 A/B 对比，关注关键指标是否下降。有些指标不是简单的准确率高就是好，还要看用户退回率。比如用户接受 AI 补全后又手动删掉，这个退回率高，说明生成结果虽然表面上可以，但实际不符合用户预期。

能把这套评估闭环讲清楚的候选人，在面试中会非常加分。因为它体现了你对“开发一个功能”和“持续运营一个功能”之间的理解差异。

6.3 安全合规：面试中的一个隐藏加分项

在 AI coding 类岗位面试中，谈到安全合规往往会让候选人一时语塞。但如果这个话题由你自己先提出来，会是一个很好的信号。

你可以主动说：AI coding 项目要上线，有一个容易被忽视的环节是代码生成内容的许可证风险。大模型会“记住”训练集中 GPL 等 copyleft 协议的代码片段，生成时可能原样输出，这会给公司带来合规风险。实际项目里，我们会接一个代码相似度检测服务，对生成代码做许可证风险扫描，高危匹配直接替换成提示“这段代码可能来自开源项目，请人工确认”。

另一个安全点是数据隐私。公司的私有代码不能随便发给第三方大模型 API，所以很多大厂会做私有化部署或者走专有通道。你可以主动谈谈私有化部署的难点，比如显存需求、量化精度损失、并发能力等。这些内容一方面展示你的视野，另一方面也能让面试官看到你不只是个功能开发，你有安全意识。

6.4 实习或外包项目的差异化表达

不是每个人都有机会在大厂核心团队做 AI coding 项目。如果你相关经验主要来自实习、外包项目或者自建小工具，你也可以通过表达方式弥补项目规格的差距。

核心做法是：不要被“小项目”限制住，而要把每个小项目都延展成你深度思考过的小型系统。比如你做了一个“自动给代码写注释”的脚本，不要只描述脚本本身，可以讲讲你在设计时如何选择 prompt 模板、如何判断哪个函数需要注释的优先级、如何防止模型在已有良好注释的函数上做无意义改写。这些思考即使是在一个很小的项目里产生，也一样能体现你的工程师素养。

再比如你参与外包项目，虽然业务范围有限，但面试中可以有策略地强调你产出的“边界”和“取舍”。例如你说“我负责的模块是本次交付中最复杂的配置解析部分，我没有直接把所有逻辑扔给大模型，而是先画出了状态流转图，再让模型基于图生成每段逻辑”。这样的回答聚焦在个人贡献和技术思路上，项目的商业规模并不会影响你的展示质量。

其实大多数面试官都很清楚实习和外包项目的客观限制，他们不期望你有三五年大厂核心经验，但你至少要在自己的经验范围内表现出深度思考的能力。这一点做好了，面试官会觉得“这个人给一个更大的项目也能接得住”。

7. 从一个面试官的角度，最后给三句掏心窝的话

如果看完全文你对 AI coding 类项目的面试还是觉得有点虚，别担心，这很正常。这类岗位本来就处在技术和认知都在快速迭代的领域，没有哪个面试者敢说自己全都准备好了。我作为参与过多场面试的人，最后分享三句掏心窝的经验。

第一句话：你不需要在每个问题上都答得完美无瑕，但你一定要在“自己做过的东西”上答得滴水不漏。一个真实做过 AI coding 项目的人，哪怕项目规模不大，在细节追问中展现出来的笃定感，远超一个背了三天面经、什么热门概念都能聊两句但一深挖就破功的候选人。所以面试前与其焦虑地刷大量概念，不如把精力优先放在打磨你最有把握的那一两个项目上。

第二句话：AI coding 面试的评分逻辑，不是“你回答对了哪个问题给多少分”，而是“你对问题的解析思路能不能复用到未知场景”。面试官抛出开放场景题，心里往往没有标准答案，只想看你如何在不确定的条件下做决策。能主动澄清需求、列出约束、评估方案候选集的候选人，永远比坐等标准答案的候选人走得更远。

第三句话：把面试当成一次技术方案讨论，而不是一次拷问。你越放松，越能自然地展现你在日常工作中如何使用工具、如何思考、如何做事。我自己面过的候选人里，凡是最后让我印象深刻的，几乎都具备一个共同特质：他们在描述技术问题时，语气里带着一种真实的兴奋感，而不是背稿式的机械感。这种兴奋感是装不出来的，它来自于你真正享受用 AI 做出一个东西的过程。

祝你在 AI coding 项目的面试里，既能讲清楚自己走过的路，也能让对方看到你能走上更远的路。