社招简历评审里经常碰到这样一份工作经历两段每段三四行写得很省下面的个人项目却占了大半页技术选型、架构图、性能数据一应俱全。写的人的逻辑很清楚业余项目是我自己从头做的最能代表我的水平。但读的人第一反应往往是另一个他在公司做的事是不是拿不出手。评审者给权重的方式工作项目和业余项目在评审者眼里的默认可信度不一样。工作项目有同事、有线上流量、有绩效背书写得再简略也默认是真的。业余项目没有任何外部验证默认可信度低要靠细节自证。权重排序大致是与目标岗位的相关度其次是复杂度再次是有没有真实使用最后才是你投入了多少时间。多数人是反过来排的把投入最多的放最前面。所以一个通用的判断业余项目在简历上的篇幅不该超过它在面试里能撑住的追问深度。业余项目「算数」的三道线不是所有业余项目都值得单独成条。过不了下面三道线的只适合塞进技能栏当佐证比如「熟悉 Flutter有一个上架的个人 App」。第一道线可验证的存在。公开仓库、线上地址、应用商店链接至少有一个而且照着 README 能跑起来。第二道线至少一个你做过的技术决策并且说得出为什么。「用了 Redis」不算「这个量级下选 Redis 而不是本地缓存因为要跑两个实例」才算。第三道线至少一次真实的问题排查。项目跑起来之后出过什么问题怎么定位的。没上过线的项目往往过不了这条因为很多问题只在真实使用中才会出现。改一条看看差别改前个人项目待办事项 App 使用 Flutter Firebase 开发支持任务创建、提醒、多端同步已发布到应用商店改后个人项目待办事项 AppFlutter / Firebase应用商店在架累计约 300 安装 - 离线优先本地 SQLite 为主存联网后按 updatedAt 双向合并冲突策略是最后写入优先 两台设备同时改同一条会丢一边改动已在 README 标为已知问题 - 提醒在部分 Android 机型上被省电策略杀掉改为 WorkManager 周期任务 精确闹钟兜底 自测 3 台机型到达率从约 60% 提到 95% 以上改后多了两样东西一个没解决干净的问题和一组自己测出来的数字。业余项目里敢写已知缺陷的人可信度反而高因为编出来的项目不会有缺陷。和工作项目怎么排序分三种情况。工作内容和目标岗位对口工作经历在前业余项目压缩成一条放最后作为「业余时间也在写代码」的旁证。想换方向比如从业务后端转基础设施业余项目是你唯一的相关证据可以放到前面但标题上明确写「个人项目」不要和工作经历混排混排会被当成夸大。工作内容不能对外细说或者确实太薄业余项目做主力工作经历写清职责范围和技术环境就行不要硬凑。不管哪种情况单条业余项目的行数不要超过工作经历里最长的那条。篇幅本身就是一种权重声明业余项目写得比工作项目长读者会按篇幅反推你的重心在哪。追问的方向不一样工作项目会被问「你负责哪部分」「团队怎么分工」。业余项目会被问「为什么这么设计」「现在多少人在用」「还在维护吗」。最后一问最容易翻车。commit 停在一年前简历上写「持续迭代中」对方点开仓库就知道了。写「2025.03 停止维护功能完整可用」比装作还在做要稳得多。「多少人在用」也别绕。只有自己在用就写「个人使用」面试官在意的不是用户数是你有没有如实报数。几种不算数的跟着教程做出来、没有偏离教程的博客、商城、待办三件套尤其如此fork 之后只改了配置文件的只有一个 init 提交的停在架构图阶段、代码没跟上的。这几类写进去不加分被问到会减分。自查每一条业余项目问自己把它删掉这份简历变弱了吗。没变弱就删篇幅留给能撑住追问的内容。改完之后整份扫一遍格式也有必要业余项目和工作项目混写时日期格式、标题层级、技术名词写法最容易不一致。最后业余项目的价值不在于它证明你热爱技术在于它提供了工作项目给不了的东西完整的决策链和从零到一的过程。写到这个程度它才算数。
