技术面怎么讲项目？一套结构 + 追问应对，含 AI 应用 / Agent 项目的讲法

很多人把「讲项目」当成复述简历，结果从需求讲到上线，十分钟过去，面试官还是不知道你本人做了哪一块。换个角度想，面试官借这道题在考这几样东西：

• 真实性：这个项目是不是你做的，你是不是真的懂。追问几层就能看出来。
• 技术深度：你对用到的技术，是「会调用」还是「知道它为什么这样、什么时候不该用」。
• 工程判断：面对多种方案，你怎么权衡成本、时间、复杂度和风险。
• 解决问题的过程：遇到卡点时，你是怎么定位、怎么试、怎么验证的。
• 表达和结构：能不能在有限时间里把一件复杂的事讲明白，这也是日常协作要用的能力。

所以讲项目的目标是：用最短的时间让面试官知道「这件事有多难、你负责哪块、你做得怎么样」，然后把细节留给追问。

下面这六步是通用骨架，校招和社招都适用。每一步给出要讲什么、讲多长、常见的坑。

几个要点：

1. 先讲主线，再给细节入口。 第一轮控制在三分钟左右，讲完主动说一句「其中某个难点我可以展开讲」，把话题引到你最有把握的地方。
2. 「我」和「我们」分开说。 团队做的说「我们」，你自己做的说「我」，别把团队成果全揽到自己身上，也别把自己的工作说得含糊。
3. 结果要有基线。 「接口耗时从【A】降到【B】」要能说清楚是在什么负载下、用什么方式测的、测了多久。没有精确数字，就说「从需要人工处理变成自动处理」这类可以核实的变化。
4. 难点要真实。 选你真的花了时间、走过弯路的问题。面试官最想听的是你怎么一步步排查的，而不是一个完美的结局。

面试官有时会指定项目，有时让你自己选。自己选的时候，按下面几条挑：

• 和岗位最相关的优先。 投后端就挑有接口设计、存储、并发处理的；投前端就挑有交互复杂度、性能优化、工程化的；投 AI 应用就挑有检索、工具调用、效果评测的。可以对照本站的后端开发岗位页、前端开发岗位页、AI 应用工程师岗位页看各岗位关心什么。
• 你参与最深的优先。 哪怕项目规模小，只要关键部分是你做的、每个决定你都说得出理由，就比一个规模大但你只做了边角的项目好讲。
• 有难点、有取舍的优先。 纯粹的增删改查很难讲出深度。挑一个你做过技术选择、解决过棘手问题的。
• 有结果的优先。 上线了、有人用、有指标变化的项目，比只停在本地跑通的更有说服力。

建议准备两个项目：一个主讲，讲到能扛住五六层追问；一个备用，换个角度体现你的另一种能力。

技术面经常会让你「画一下整体架构」或者「说说一个请求是怎么走的」。线上面试可以用会议软件的共享白板，或者提前在纸上画好举到镜头前；线下面试一般用白板或纸笔。

画架构图的顺序建议是：

1. 先画边界：谁是用户、从哪里进来、最终数据存在哪里。
2. 再画主干：入口层、业务逻辑层、存储层，中间有缓存或消息队列就画上。
3. 然后沿着一个请求走一遍：用户做了一个操作，请求先到哪、经过哪些处理、读写了哪些数据、结果怎么返回。
4. 最后标出你负责的部分：用不同颜色或框起来，让面试官一眼看到你做的是哪块。

讲数据流时可以用一张这样的表帮自己梳理（面试时用嘴讲，表格只是准备工具）：

不用把每个组件都讲到底，面试官对哪一块感兴趣，自然会追问。

「如果用户量 / 数据量涨十倍，你的系统哪里先扛不住？」 这类问题考的是你对瓶颈的判断。答法：

1. 先指出最先出问题的地方，比如数据库写入、某个单点服务、某个同步调用。
2. 说明你怎么判断的：看过哪些指标、压测过没有。
3. 给出分阶段的应对：先做成本低的（加缓存、加索引、异步化），再做成本高的（拆分、扩容、改架构）。
4. 说明每一步的代价：一致性变弱、运维变复杂、成本变高。

「线上出过什么问题？怎么处理的？」 这道题很常见，没准备的话很容易答成「没出过什么问题」，反而像是没参与过真实上线。答法按事故复盘的思路：

• 现象：用户或监控发现了什么，影响范围多大。
• 止损：第一时间做了什么让影响停下来，比如回滚、降级、切流量。
• 定位：怎么找到根因，看了哪些日志、指标，排除了哪些可能。
• 修复：根本上怎么改的。
• 预防：之后加了什么监控、测试或流程，避免再犯。

校招同学如果没有线上经历，可以讲开发或测试阶段遇到的严重问题，比如压测时发现的性能问题、联调时发现的数据错乱，同样按这个结构讲。

AI 应用和 Agent 类项目越来越常见，面试官追问的点也比较集中。讲这类项目时，除了上面的六步结构，还要准备好下面几块。注意用通用概念讲清楚原理和你的取舍，不需要、也不建议在面试里堆砌具体产品或工具名，面试官更关心你懂不懂背后的道理。

检索增强：资料从哪来、怎么找到对的内容？

如果项目里用了检索增强（先从资料库里找到相关内容，再交给模型生成回答），面试官通常会问：

• 资料怎么处理的：文档怎么解析、按什么规则切分成片段、表格和图片怎么处理。
• 怎么检索：用语义相似度检索、关键词检索，还是两者结合；为什么这么选。
• 检索效果怎么衡量：你用什么方式判断「找到的内容是对的」，有没有准备一批带标准答案的问题来测。
• 效果不好时怎么排查：先分清是资料没解析好、检索没找到，还是找到了但生成时没用好。

工具调用：模型怎么调用外部能力？

如果项目让模型调用接口、查数据库或执行操作，要讲清楚：

• 工具怎么定义的：每个工具的用途、参数、返回格式怎么描述，模型怎么决定调用哪个。
• 参数校验：模型生成的参数不可信，调用前怎么校验类型和范围。
• 失败处理：工具超时、报错、返回异常结果时怎么办；会改动数据的操作，重试时怎么避免重复执行。
• 权限边界：哪些操作需要人工确认，哪些操作模型不能碰。

Agent 流程：怎么让多步任务稳定跑完？

Agent 类项目（模型自己规划步骤、调用工具、根据结果决定下一步）会被追问稳定性：

• 为什么用 Agent，而不是固定流程：如果步骤是固定的，固定流程更可控、更省成本。说清楚你的场景为什么需要模型自己决定步骤。
• 怎么防止跑飞：最大步数限制、超时、重复动作检测、关键步骤人工确认。
• 上下文怎么管理：任务一长，历史信息越来越多，保留什么、压缩什么、丢掉什么。
• 中途失败怎么恢复：已经执行的步骤怎么记录，失败后从哪一步继续。

评测与效果度量：你怎么知道它变好了？

这是 AI 项目很容易被问倒的地方。只说「试了几个例子感觉不错」是不够的。要准备：

• 评测集：有没有一批固定的测试问题，覆盖常见情况和容易出错的边界情况，每次改动后都跑一遍。
• 评价标准：答案对不对、有没有依据、格式是否符合要求，分别怎么判断；哪些靠规则自动判，哪些需要人工抽查。
• 线上反馈：用户的点赞点踩、追问、人工接管次数等，怎么收集、怎么用来改进。
• 改动对比：调整提示词或检索策略后，怎么证明是真的变好，而不是刚好碰上了几个好例子。

成本与延迟：贵和慢怎么解决？

• 延迟拆开看：总耗时里，检索、模型生成、工具调用各占多少；对话类场景里，用户往往很在意多久能看到第一个字，后台批量处理的任务则更看重总耗时。
• 降延迟的办法：流式输出、并行执行互不依赖的步骤、缓存常见问题的结果、缩短不必要的输入。
• 降成本的办法：简单任务用规模小的模型、精简输入内容、缓存重复请求、限制单次任务的最大调用次数。
• 讲清楚取舍：降成本往往会牺牲一些效果，你怎么判断这个牺牲可以接受。

幻觉与安全兜底：模型答错了怎么办？

• 降低幻觉：要求回答基于检索到的资料并标注出处，再核对标注的出处确实存在、确实支撑这句话；资料里找不到时明确回答「不知道」，而不是硬编。这些办法只能降低、不能完全消除答错的情况。
• 输出校验：要求结构化输出的，后端再校验一遍格式和取值；关键信息和数据库核对。
• 防恶意输入：用户输入或外部网页里可能藏着「让模型忽略原有规则」的指令，怎么隔离外部内容、限制模型能做的操作。
• 兜底方案：模型服务不可用或结果明显异常时，降级成什么，比如返回固定提示、转人工处理。

上线监控：上线后看什么？

• 基础指标：请求量、成功率、耗时分布、成本。
• 效果指标：用户反馈、人工接管率、回答被采纳的情况。
• 异常发现：耗时突然变长、某类问题错误集中出现、成本异常上涨，怎么及时告警。
• 问题回放：出问题时能不能找到当时的输入、检索结果、模型输出和工具调用记录，用来复现和排查。

这几块不需要每块都讲，挑你项目里真正做过的两三块讲深。没做过的，面试官问到就如实说「这块当时没做，如果要做我会怎么考虑」。

下面是一个虚构的示范，用来演示结构。项目内容和数字都是占位，请换成你自己真实做过的、经得起追问的内容，不要照搬。

背景与目标： 「这是一个给内部客服团队用的工单助手。客服每天要处理大量工单，很多问题需要先查知识文档、再查订单状态，最后写回复。目标是让助手自动完成查询，生成回复草稿，客服确认后发出，希望把单个工单的平均处理时间从【A 分钟】降下来。」

你的角色： 「团队【N】个人，我负责检索模块和工具调用这两块，评测方案也是我设计的，前端和部署由其他同事负责。」

方案与取舍： 「整体流程是：工单进来先做分类，再检索知识文档，需要查订单的就调用订单查询接口，最后生成回复草稿交给客服确认。一开始我们考虑让模型完全自主决定步骤，但测下来步骤不稳定，有时会重复查询。因为这个场景的步骤其实比较固定，最后改成固定流程为主、只在少数复杂工单里让模型自己判断要不要多查一步，这样可控性好很多，代价是灵活性差一些。」

难点与解决： 「最难的是检索不准。一开始只用语义检索，遇到订单号、错误代码这类内容经常找不到。我把失败案例逐条看了一遍，发现问题集中在精确匹配类的内容，于是加了关键词检索，两路结果合并后再排序。改完后，在我们准备的【X 条】测试问题上，能找到正确文档的比例从【A】提高到【B】。」

结果与量化： 「上线【X 周】后，客服采纳草稿直接发出或稍作修改发出的比例是【X】，单个工单平均处理时间从【A 分钟】降到【B 分钟】。这个数是从工单系统里统计的，对比的是上线前【X 周】的同类工单。」

复盘与改进： 「回头看，评测集应该更早建。前期我们靠人工试几个例子判断效果，有几次改动其实是变差了但没发现。如果重做，我会在第一周就先建好评测集，每次改动都跑一遍再上线。」

讲完这一段大约三分钟。接下来面试官很可能追问「为什么不让模型完全自主」「两路检索结果怎么合并排序」「采纳率怎么统计的」，这些都要提前准备好。

校招同学最常担心的是「我的项目太简单」。其实面试官对校招的期待不是项目规模，而是你有没有想清楚、有没有动手解决过真问题。

• 课程项目和毕业设计：别只讲「实现了哪些功能」。挑一个你做过选择的点讲，比如为什么这样设计表结构、为什么选这种通信方式；再讲一个你调试很久才解决的问题。
• 实习项目：讲清楚你在团队里的位置，哪些是导师定的方向、哪些是你自己做的决定。实习里接触到的线上流程（代码评审、测试、发布、监控）也是加分点，可以顺带说你学到了什么。
• 个人项目：最好有能打开的地址或代码仓库。讲为什么做这个、怎么一步步做出来、遇到过什么坑。个人项目的优势是每个决定都是你自己做的，正好可以讲取舍。
• 比赛项目：讲你在团队里的分工，以及比赛限时条件下你们做了哪些取舍。

校招常见的坑是把教程项目当成自己的项目讲。如果项目是跟着教程做的，讲的时候如实说明基础部分来自教程，再在此基础上做一些自己的改动（加一个功能、优化一个性能点、换一种实现方式），重点讲你改的那部分。

社招面试官更关心你在真实业务里解决问题的能力，以及你的成长轨迹。

• 从业务问题讲起：先讲业务遇到了什么问题、对业务有什么影响，再讲技术方案。比如「下单高峰期接口经常超时，影响【X】类订单」，比「我做了一个缓存优化」更能体现价值。
• 讲清楚你的决策空间：方案是你提的还是别人定的，你说服了谁、怎么说服的，有没有不同意见、最后怎么达成一致。
• 结果和业务指标挂钩：除了技术指标（耗时、可用性、成本），最好能说出对业务的影响，并说明数据来源。
• 带团队的经历单独准备：如果你带过人，面试官可能会问怎么拆任务、怎么评审方案、怎么处理进度延误、怎么培养新人。准备一两个具体例子，讲你做了什么、结果如何。
• 离职项目不泄密：讲前公司项目时，用通用说法描述业务，不说具体的内部系统名称、客户名单和未公开的数据。面试官一般能理解，这本身也是职业素养的体现；如果和前公司签过保密约定，以约定为准。

转行做技术岗，最大的难点是缺少正式的工作项目。可以用作品项目来证明你的能力，但要讲得有分量：

• 选一个有真实需求的题目：比起千篇一律的练手项目，最好结合你原来行业的经验做一个解决实际问题的工具。比如做过运营的，可以做一个数据整理和分析的小工具；做过客服的，可以做一个常见问题检索助手。这样既有技术内容，又能讲出你对业务的理解。
• 按工作项目的标准做：有需求说明、有设计思路、有测试、有部署、有使用说明。哪怕用户只有你自己和几个朋友，也能讲「上线后发现了什么问题、怎么改的」。
• 讲清楚学习过程：你怎么系统学习新技能的，遇到不会的问题怎么解决的。这能让面试官相信你入职后学得快。
• 把旧经验转化成优势：原行业的经验让你更懂某类用户、更会沟通需求、更有项目推进经验，这些在讲项目时可以自然带出来。

• 能在三分钟左右讲完主线，对着计时器练几遍。
• 每个技术名词都能解释：简历上写的、你嘴里说的每个技术，都要能讲清楚它是什么、为什么用、有什么替代方案。
• 每个数字都能说出来源：怎么测的、和什么比、时间范围是什么。
• 准备了至少一个线上问题或严重问题的处理过程。
• 准备好「没做过」的回答方式：不懂就说不懂，再说说你会怎么去了解和解决，比硬编强得多。
• 项目内容和简历一致：面试时讲的和简历上写的对得上。

你在技术面里有没有被某个追问问住过，比如「为什么不用另一种方案」「这个指标怎么算的」？或者你做的 AI 应用、Agent 项目，被问到了这篇没写到的点？欢迎通过页面底部「发现内容有误或侵权？告诉我们」入口把你遇到的问题或情况发给我们，采纳后会整理补充到本站。