摘要大一打了一年比赛我以为自己已经懂什么叫做东西。大二有幸进入北京大学智能装备实验室参与第一个真实项目不到两周我过去所有的懂被推翻得干干净净。这篇文章不谈具体技术只聊一件更底层的事——学生思维和工程思维到底差在哪。写在前面我被打脸的那个下午从大一到现在我打了不少比赛也确实是在比赛里一点点把技术啃下来的——一边学、一边比、一路摸索着往前走。到了大二我有幸进入北京大学智能装备实验室第一次参与到实际的项目开发中。刚进去那会儿我兴致勃勃地在会上抛出了七八个我觉得很酷的功能点从交互到算法讲得眉飞色舞。讲完之后带我的师兄只问了我一句这些功能里有哪个是用户主动提过的我愣住了。一个都没有。它们全是我自己觉得应该很厉害的东西。那一刻我意识到过去一年在赛场上建立起来的那套评价体系——功能多 强、技术炫 牛、跑通了 完成——在真实项目里几乎是失效的。这篇文章就是我把这套评价体系推倒重建的过程记录。一、先说结论一场限时冲刺一场漫长马拉松很多人说比赛和项目不一样但不一样在哪我把它拆成了下面这张表这也是全文的提纲对比维度比赛真实项目目标来源赛题写死规则清晰有标准答案需求方说不清需要你反复追问才能挖出来时间周期几天到几个月DDL 铁打不动数月到数年节点会被反复推迟评价标准跑分、名次、完成度是否真的解决问题、能否长期稳定运行失败成本炸了重来最坏是丢一次成绩一次失误 返工、延期、真金白银代码归属能跑就行基本只有自己看要交接、要维护、要被别人 review技术选型选最新最酷的能加分选最稳最成熟的能兜底成就感来源拿奖有人真的在用一句话概括比赛是在给定的规则里做到极致项目是在一片模糊里自己找到规则。比赛像限时冲刺——发令枪响终点线画在那儿你只管跑得更快项目像马拉松——没有明确终点配速得自己定中途还会下雨、抽筋、发现路标被挪走过。二、我以为的好在实验室里被逐个推翻2.1 学生思维功能是越多越厉害的我以前打比赛比如智能车这类思路非常典型完赛还不够得加个语音播报才有亮点有线调试不够酷得做个手机 App才显得完整算法能跑就行不行得上个更花哨的方案评委才觉得有深度。这些选择在比赛语境下其实完全正确。评委要在十几分钟里判断作品水平功能的丰富度和技术的新颖度就是最直观的打分依据。问题在于我把这套逻辑原封不动带进了项目里。2.2 工程思维的第一记重锤这个功能谁在用项目里每加一个功能都要先过三关它解决的是谁的什么问题—— 说不出具体的人、具体的场景就是伪需求。不做它产品会烂到不能用吗—— 如果不能它的优先级就该往后排。做了它用户要额外付出什么—— 成本、功耗、体积、学习成本、故障率这些都是代价。这三个问题我在比赛中从没问过自己。因为比赛不需要——赛题已经替我筛过一遍该做什么了。2.3 一张被划掉大半的需求清单我参与这个项目时它已经进入第一阶段尾声。我看到的不是加了什么而是砍了什么——那张功能清单上被划掉的东西比我留下的多得多我原以为必须有的功能最终方案砍掉它的理由自研一套图形化上位机串口打印 现成工具实际调试频率极低不值得投入所有参数全部开放配置只暴露 3 个高频参数配置项越多现场误操作概率越大追求接近 100% 的极限性能先做到稳定可用的水平边际收益太低第一阶段验证不了一次做完整套系统拆成阶段先交付核心链路战线太长风险不可控这张表是我在这个项目里学到的最贵的一课。砍功能不是偷懒它恰恰是最难的判断你要有足够的底气说这个用户真的不需要也要有勇气承担万一需要呢的风险。【插图位 3】建议配一张白板/纸上的功能清单被红笔大片划掉的图视觉冲击力强。 图库搜索关键词whiteboard crossed out ideas red marker、minimal workspace notebook planning三、从能跑起来到能造出来隔着一整个工业体系参与项目之后我对消费电子产品的敬畏心直线上升。以前我看一个产品只看它能干什么。现在我下意识会想这块电路板改一版要多久、多少钱这个结构件的公差装配时会不会卡死这颗芯片明年还买得到吗缺货了有替代方案吗实验室 25℃ 一切正常到了真实环境还正常吗这东西坏了谁来修、怎么修一个电子产品从设计到量产大致要经历这样的链条需求调研 → 方案设计 → 软硬件实现 → 打样验证 → 可靠性测试 → 小批量试产 → 量产 → 售后迭代我在实验室看到的只是这条链上的一小段。而每一个箭头背后都是一群人在反复拉扯、反复妥协。我特别喜欢拿小米举例子原文里也提到了这里展开一点它的每一代产品都不是完美的网上骂声从来不少。但你会发现很多看起来不起眼的设计——一个接口的挪动、一个交互的简化、一个功耗的优化——确实解决了一批人生活里的具体不便。科技改变生活从来不是靠一个完美产品从天而降而是靠一代代不完美的产品一次次把生活往前推一点点。这句话是我进实验室之后才真正相信的。四、四条刻进脑子里的体会4.1 需求优先从我想做什么到用户需要什么这是最底层的一次视角转换。学生做东西起点通常是我会什么 / 我觉得什么酷做项目起点必须是谁、在什么场景下、卡在什么问题上。我现在养成了一个习惯动手写任何一行代码之前先能用一句话说清楚这个功能为谁而做。说不清楚就先不写。这条习惯让我少写了至少一半的废代码。4.2 学会取舍敢于砍功能是一种专业能力资源永远是有限的——时间、人手、预算、注意力全都有限。在有限资源下不做什么的决定比做什么更重要。因为每保留一个非核心功能就意味着核心功能分到的资源少一分。而一个把核心体验做到 90 分的产品价值远大于三个都做到 60 分的功能。4.3 团队协作沟通也是硬技能项目不是一个人的战斗。这一点我以前只在嘴上认同现在是切身体会。真实协作里最消耗人的往往不是技术难题而是信息不对齐我以为你知道进度你以为我还在调研我以为这个接口返回 int你写成了 float我以为这个方案定了其实只是会上没人反对。我现在学到的笨办法很有效重要的结论一定落到文字上。会议纪要也好群里的三行总结也好留痕比我以为可靠一万倍。4.4 接受不完美完成比完美重要这可能是四条里最难接受的一条尤其是对习惯了追求高分的学生来说。但现实是一个按时交付、能真实跑起来、有明确已知问题的版本价值远高于一个永远在打磨、永远上不了线的完美方案。产品永远有改进空间。重要的是在迭代中持续变好而不是憋一个大招试图一步到位。五、给还在打比赛 / 准备进实验室的同学5 条建议如果你和我一样正处在打了一堆比赛、想找真实项目练手的阶段这几条是我用踩坑换来的别急着学新框架先把为什么做问明白。技术栈的差距几个月能补上需求判断力的差距要几年。养成写文档的习惯从现在开始。哪怕只是给自己写的调试记录未来你会感谢自己——项目里没人有义务读懂你的脑回路。主动去找用户聊天而不是埋头写代码。导师、师兄、需求方甚至是假装自己是用户都行。聊十次比闷头想一个月有用。学一点成本意识。知道一块板子打样多少钱、一颗芯片交期多久、一次改版要多少工时。有成本感你的方案才会落地。把比赛作品做成能讲清楚的作品集而不是终点。比赛最大的价值不是奖状是它逼你在短时间内把一件事从头做到尾——这个能力项目里极其稀缺。六、写在最后从比赛到项目从学生思维到工程思维这条路我才刚刚起步。现在我正和团队一起改进方案努力为第一阶段画上一个尽可能圆满的句号。这个过程有挑战、有压力也有不少自我怀疑的时刻。但每当看到一个功能从我觉得酷变成用户真的在用那种踏实感是任何一次拿奖都给不了的。我越来越相信一句话科技改变生活从来不是一句空话而是无数工程师在幕后一点一滴的坚持与付出。未来还有很长的路要走。我会继续在项目中学习、成长也期待自己有一天能真正做出改变生活的产品。 想和你聊聊你有没有过类似的思维被打碎的时刻是从哪件事开始的欢迎在评论区聊聊你的经历 ——觉得有共鸣的话点个赞 收藏让更多还在迷茫的同学看到。