1. 项目介绍的真正目标把“我学了什么”改成“我解决了什么”很多同学到了 Day03 才真正把项目介绍想明白。Day01 那天我自己也在现场听了一半的演示说实话大部分人的开场都差不多“我们这个项目是基于某某框架做的前端用了什么后端用了什么数据库用了什么。”这句话一出来评委的兴趣基本就凉了一半。为什么因为技术栈只是工具不是成果。你用了 Spring Boot、用了 Vue、用了 MySQL这只能说明你“会调用工具”不能说明你“完成了一个能用的东西”。同样是一道菜你说“我用了锅、用了铲、用了酱油”和你说“我做了一道红烧肉色泽红亮、肥而不腻、入口即化”哪个更像一个厨师说的话项目介绍也是同理。所以我习惯把项目介绍的真实目的拆成四层每一层都有它要回答的问题第一层你要解决什么问题这个问题的场景是否真实是否有人真的需要它。第二层你用什么方案解决方案的复杂度、合理性、技术选型是否匹配问题本身。第三层你是怎么把它做出来的这里才轮到技术栈、架构设计、模块划分、数据库设计。第四层效果如何性能指标、交互反馈、可扩展性甚至踩过哪些坑。绝大多数人的介绍顺序是反的先讲工具再讲功能最后才勉强提一句“解决了某某问题”。讲到最后问题是什么已经不重要了评委只记住了一堆技术名词。后面被追问“那你这个项目的难点到底是什么”的时候就只能支支吾吾。这一篇我要聊的就是这件事怎么在十几分钟里把“功能亮点”讲成“价值证明”。不绕弯子直接上方法论。2. 功能亮点的筛选先砍掉 80% 的“伪亮点”再包装真亮点2.1 为什么你列出的十个功能里只有两三个算亮点做项目的时候功能清单往往一大串登录注册、权限管理、数据统计、消息通知、文件上传、搜索筛选……一周做完的练习项目功能列表能写满两页。但当我问“你觉得哪个功能最能证明你的能力”时很多人反而犹豫了。这里有一条我用了很久的筛选标准我把功能分成四类只有第四类才值得放进“功能亮点”环节分类判断标准是否算亮点普通功能增删改查、表单验证、列表分页任何培训项目都有的不算依赖框架的功能用了某个中间件或第三方库就有的能力比如接了个支付 SDK不算业务复杂度高的功能涉及多个模块联动、需要设计状态流转、有并发或一致性处理算解决真问题的功能你发现了某个实际使用中的痛点并且用自己的方案解决了算核心亮点举个例子。一个二手交易平台项目里“发布商品”算普通功能“商品审核状态流转”算有一定复杂度但真正能拿出来讲的是你处理“买家下单时商品被下架了”这种并发场景——这个情况一旦发生库存扣了但订单失效了数据就不一致了。你为了解决它设计了状态校验逻辑这是业务复杂度是亮点。但如果只是接了一个短信验证码服务然后说“我的亮点是接了短信 SDK”这就太单薄了。别人的项目也能接而且接得比你快。所以筛选的第一条原则是能被轻易复制的功能不算亮点。2.2 用“一主两辅”定亮点结构我个人的建议是一个十几分钟的项目介绍功能亮点不要贪多。一个主亮点两个次亮点足够了。主亮点必须是项目里最核心、最复杂、最能体现个人能力的那一个次亮点可以是辅助性的比如性能优化、异常处理、工程化配置。为什么不要贪多因为时间不允许。十四分钟的演示如果塞进去五个亮点平均每个只有两三分钟。评委刚进入状态你已经跳到了下一个功能结果每个都是“蜻蜓点水”没有一个讲透。这就好比相亲的时候你把十八般武艺全都亮了一遍对方反而一个都没记住。我见过一个做得很好的例子。那是一个校园二手书交易系统主亮点是“基于 Redis 的图书抢购防超卖机制”。他用了大概六分钟从“为什么会有超卖问题”开始讲到“我对比了什么方案”再到“最终怎么用 Redis 事务解决”整个过程有原理、有对比、有踩坑。剩下两个次亮点一个是“定时任务做订单超时自动取消”一个是“前端按需加载优化首屏时间”各用三分钟讲清楚思路和效果。整场下来节奏舒服评委的提问也有了明确的方向。2.3 给亮点套一个“问题—方案—验证”的叙事框架选好了亮点下一步是组织表达。这里我推荐一个最简单也能打的框架——问题—方案—验证三步走。问题先描述你遇到了什么棘手的场景让听者感受到“这确实是个问题”。这一步最忌一上来就报技术名词。方案说明你对多种方案做过比较最终选了哪一条路为什么选它。这里可以出现技术细节了。验证给出结果能量化的量化响应时间从 X 秒降到 Y 毫秒不能量化的给对比或演示效果。很多人只讲第二步不讲第一步和第三步。但恰恰是第一步让评委理解了“为什么你要做这件事”第三步证明了“你的方案确实有效”。没有这两头中间的技术方案就变成了空中楼阁。3. 十四分钟的时间编排开场三分钟抓人亮点九分钟讲透两分钟收尾留印象3.1 把 14 分钟拆成三个段落比“即兴发挥”稳得多这里我先给一个具体的实践方案。标题里的 14 分钟很典型这类评审场景给到的时间大多在 10 到 20 分钟之间。我们按 14 分钟拆最合理的配比是3 分钟开场9 分钟功能亮点2 分钟收尾。开场 3 分钟干三件事一句话说清项目“是什么”一句话说清“为什么做它”痛点背景一句话说清“我在这中间的角色”是独立完成还是负责哪个模块。这三句话说完评委对你的项目就有了一个基本定位后面听功能时就有代入感了。很多同学的第一页 PPT 放的是项目名字做大标题然后开始念技术栈这 3 分钟就白费了。功能亮点 9 分钟分给“一主两辅”主亮点 5 分钟每个次亮点 2 分钟。主亮点的 5 分钟里按“问题—方案—验证”去讲中间可以穿插一段实机演示。次亮点的 2 分钟讲清楚“痛点在哪、你怎么处理的、效果如何”就够了不展开底层细节——把细节留给评审提问环节反而是好事因为你有“存货”。收尾 2 分钟重点从“功能”切换到“总结”。说说这次项目你收获最大的一个点或者说如果再来一轮你最想优化哪里。这两句话能让评委感觉到你有复盘意识比一句干巴巴的“谢谢大家”好用太多。3.2 演示环节的“3 分钟法则”功能亮点讲完之后很多项目都需要现场演示。这里有一个我踩过坑之后总结出的法则每个演示小节不要超过 3 分钟。为什么演示的本质是“用画面补讲述”不是让评委看你操作 UI。超过三分钟关注点就从功能转移到了你的鼠标移动速度上。慢了显得卡顿快了显得敷衍。所以演示前你要把演示路径设计成“最短路径”——只做核心链路不停留在设计精美的首页上。举个例子。你演示一个权限管理功能不要从登录开始一步步演示。直接把 URL 切到目标页面或者准备好两个账号的登录态一键切换。你要在 3 分钟内展示的是“普通用户看到了 A 界面管理员看到了 B 界面且 B 界面里的某项操作普通用户是被禁用的”。这个链路能压缩到 1 分钟你会瞬间觉得节奏非常从容。演示时还有一个非常重要的心态演示不是为了展示顺畅而是为了配合你的讲解。所以宁可让演示的脚步稍微慢一点也要确认每个动作对应的讲解已经落在评委耳朵里了。做到“点到为止”比“炫技式操作”更符合评审场景。3.3 预留 1 分钟的弹性缓冲实际评审现场总会有意外视频播放器卡了、接口没起来、评委中途插话。所以 14 分钟里我会建议把“必讲内容”压缩到 13 分钟以内预留 1 分钟弹性时间。如果前面超时了收尾的“复盘心得”就砍掉如果一切顺利这 1 分钟可以用来补充一个很加分的细节——比如你顺手做了一个自动化部署脚本。但是千万注意超时的处理不是让你的语速变快而是删掉非核心内容。一般来说删减的优先级是次要功能演示的完整流程 某个技术方案的细节推导 收尾的自我总结。最先保住的永远是主亮点的完整逻辑线它才是这次介绍的核心记忆点。4. 亮点演示的“提词器”设计台词本怎么写才不会变成念 PPT4.1 别把台词写成一篇文章要写成“关键词卡片”很多人准备了逐字稿现场念得磕磕绊绊也有很多人没准备现场东一句西一句。其实两种都极端了。逐字稿的问题在于你一旦中途忘了一句后面的节奏全乱完全没准备的问题在于你的用词会反复、逻辑会跳。我自己提倡的是做“关键词卡片”也叫提词器。它不是朗读用的稿子而是给你大脑锚点的短词列表。核心的目的只有一个让你在任何时候扫一眼都能想起这一段要讲什么而具体的措辞你可以自由组织。比如“主亮点”这一张卡片我会写成这样超卖问题 - 用户下单同时并发 - 库存只剩1件 - 2人同时买到 方案对比 - 数据库悲观锁 - 行锁 - 性能差 - Redis 预减库存 - 最终一致性 我的方案 - Redis原子操作 - 扣减失败直接返回 验证 - 压测 100 并发 - 无超卖 - 响应 5ms 踩坑 - 超卖消息堆积 - 增加重试 幂等这 10 个关键词就是整个 5 分钟的骨架。每一段话的展开都绕不开这些点。好处是就算现场紧张到断片看一眼卡片自己用大白话也能接上。停止背稿开始“按关键词展开叙述”你的表达自然度至少提升一半。4.2 把复杂的解释提前想好“人话版本”这里我可太想说了功能越复杂越需要用生活化类比讲清楚。评委不一定是你这个技术方向的专家你用一堆行话解释对方可能听得懂结论但感知不到复杂度。举一个实际例子。在讲“分布式锁防止重复支付”这个亮点时多数人会说“用 Redisson 实现了分布式锁通过看门狗机制自动续期在 finally 里进行解锁还加了对同一个微信支付单号的幂等校验”。这句话技术成分很足但听起来像在背文档。换成生活类比就完全不一样了“这就好比武馆里的存衣柜。你把衣服放进柜子锁上门钥匙只有你手里有一把。别人来了发现锁是锁上的就只能等。如果柜门锁因为某些异常一直没开那我们的‘看门狗’机制就会每隔一段时间来检查确保这个锁不会永远占着柜子——其他顾客还是能正常存衣。”一句话对方立刻懂了锁的互斥性、自动续期和防死锁逻辑。技术术语一个不少但展示的顺序变了先让评委理解“这是个什么场景”再告诉他“我是怎么实现的”。要养成一个习惯开发完一个复杂功能马上用大白话写一段“怎么跟外行解释它”。写不出来的地方说明你自己对逻辑还没吃透。4.3 演示前的最后 15 分钟“预演”我的习惯是在真正演示之前留 15 分钟做“全真预演”。这个时间不是用来背稿的而是专门用来跑四件事冷启动测试关闭所有浏览器进程重新打开项目、登录、跳转全程计时。现场机器的状态谁也说不准只有把冷启动流程跑顺了才不会出现“启动两分钟全场等你看 loading”的尴尬。数据检查确认演示账号登录态有效、演示用的数据准备到位、没有前一天调试留下的脏数据。屏幕与字体检查投影或者屏幕共享以后字体是不是够大、页面缩放比例是不是合适。很多人的演示字太小后排评审根本看不清。录屏兜底提前录好一段 3 分钟的演示视频放在桌面一旦现场环境崩了直接播放视频也比对着黑屏干瞪眼强。这四点每一点都是实战中真实会发生的翻车点不是纸上谈兵。5. 容易被追问的三个角落技术难点、个人贡献、后续规划5.1 “你项目里最难的技术点是什么”——这是一个送分题也是送命题几乎每一个评审都会问这个问题。说它送分是因为你完全可以有备而来说它送命是因为如果你把“难”理解成了“谁会做的技术”那基本上就掉进坑里了。这里我建议提前准备一个“技术难点清单”至少列 3 个并按照“底层原因、表象、排查过程、解决方案”四个维度写好草稿。推荐大家在项目收尾时专门花半天时间整理这份清单因为细节还热乎写出来的东西远比现场即兴回忆要真实。我自己常用的一个模板是技术难点底层原因表面现象解决思路高并发下库存超卖Redis 的读取和更新不是原子操作并发测试时库存变成负数用 Lua 脚本保证原子性长列表渲染卡顿DOM 节点过多导致重排滚动时页面掉帧虚拟滚动 分页缓存接口数据不一致缓存与数据库更新的时序问题用户看到旧数据Cache Aside 模式 过期时间注意一个细节准备“难点”的时候一定要把你“试过但不成功”的方案也写进去。理由是评委想确认你对这个问题的理解是真实的。你光说正确答案没准是从网上背的但你如果能把一个不那么完美的方案是怎么被否掉的讲清楚可信度立刻拉满。5.2 “哪些是你做的哪些是团队成员做的”——边界感比功劳感更重要团队项目里这个问题几乎必问。很多人为了显得贡献大会把整个项目都揽到自己头上结果评委追问一句“那你讲讲消息队列那边的配置细节”答不上来露馅了。正确的做法是提前想清楚自己在项目里的边界哪部分是你独立完成的、哪部分是协作完成的、哪部分是你根本没碰的。回答的时候分三层第一层总述角色“我在项目里主要负责 XXX 模块包括它的数据库设计、接口实现和部署上线。”第二层协作的部分“另外我还配合前端同学联调了两个接口帮他梳理了字段结构。”第三层诚实的边界“其他模块是团队成员完成的我没有直接参与这块开发。”这样答评委会认为你“诚实训导”反而对你负责的部分给予更多关注。反倒是你吞吞吐吐想表现出“什么都懂”只会引出一连串无法回答的技术追问。以不变应万变的核心其实是把边界讲干净再把边界内的内容讲透。5.3 “如果给你一个月继续做你会加什么功能”——这里不能真的是“再加个功能”这是一个标准的收尾型提问。很多人的第一反应是“我加个推荐系统”“我加个消息推送”这个答案不能说错但太平淡了。更好的思路是针对“当前项目的短板”来回答。比如你可以说“现在项目用的是单机部署如果继续做我会先考虑把静态资源和数据库拆到不同的服务器上引入 Nginx 反向代理做一个简单的负载均衡。主要目的不是‘加设备’而是降低单点故障风险。之后再看有没有必要引入缓存因为从监控数据来看热点商品的访问量占了 70% 以上。”你看这个答案有现状洞察痛点是什么、有方案规划怎么改、有验证思路为什么要先做这个。它表面上是“加一个能力”实际上是“展示自己会按优先级做技术决策”。评委听到的是你把项目当成一个可以演进的产品而不是交完作业就再也不碰的演示 Demo。6. 从 Day01 到 Day03真正拉开差距的是“留痕”习惯最后说一点可能跟题目无关、但跟所有项目介绍都有关的体会。Day01 那天我看到的很多团队一开始的节奏是先把项目跑起来、把功能做出来最后两三天才开始准备介绍和 PPT。结果到了 Day03 要写“技术难点清单”的时候发现全都得苦想——“我这个功能当时为什么这么做来着好像也没怎么思考照着文档就写了。”这就是问题所在介绍阶段能讲出多少干货往往不取决于你的技术有多强而取决于开发过程中你有没有“留痕”。所谓留痕就是开发时顺手做三件事记录每一次技术选型的理由为什么用 Redis 而不用本地缓存为什么用乐观锁而不用悲观锁。保存每一次踩坑的报错日志和解决过程不需要整理得多漂亮哪怕截图 一句话也行。定期更新一份“项目进展日志”站在上帝视角看自己的项目走到哪一步了。这三件事的每一件在你做项目介绍的时候都会变成素材技术选型理由直接塞进“问题—方案—验证”的“方案”里踩坑日志塞进“难点清单”里进展日志用来复盘“如果再继续做会做什么”。如果没有这些留痕到了 Day03你连吹牛的资格都没有因为你已经忘了自己是怎么做到的了。我自己这些年养成一个习惯每做一个项目都在本地开一个notes.md文件想到什么写什么哪怕语法不通也先记下来。项目介绍的前一天把这份笔记翻出来基本就是一份现成的演讲提纲。它的价值远远大于临时抱佛脚去回忆和编造。所以如果你现在正处于项目的开发阶段别嫌麻烦从今天开始记笔记如果你已经到了介绍准备阶段先回去翻翻你的开发记录和提交历史那里面的信息一定比你脑子里记得的多。把项目介绍当成一次“项目复盘”来做而不是一次技术背诵大赛你的演示状态会自然松弛下来评委也能感受到你是真的把自己的代码看明白了。