企业官网建设流程全解析

社招简历评审里经常碰到这样一份：工作经历两段，每段三四行，写得很省；下面的个人项目却占了大半页，技术选型、架构图、性能数据一应俱全。

写的人的逻辑很清楚：业余项目是我自己从头做的，最能代表我的水平。但读的人第一反应往往是另一个：他在公司做的事，是不是拿不出手。

评审者给权重的方式

工作项目和业余项目在评审者眼里的默认可信度不一样。工作项目有同事、有线上流量、有绩效背书，写得再简略也默认是真的。业余项目没有任何外部验证，默认可信度低，要靠细节自证。

权重排序大致是：与目标岗位的相关度，其次是复杂度，再次是有没有真实使用，最后才是你投入了多少时间。多数人是反过来排的，把投入最多的放最前面。

所以一个通用的判断：业余项目在简历上的篇幅，不该超过它在面试里能撑住的追问深度。

业余项目「算数」的三道线

不是所有业余项目都值得单独成条。过不了下面三道线的，只适合塞进技能栏当佐证，比如「熟悉 Flutter（有一个上架的个人 App）」。

第一道线，可验证的存在。公开仓库、线上地址、应用商店链接，至少有一个，而且照着 README 能跑起来。

第二道线，至少一个你做过的技术决策，并且说得出为什么。「用了 Redis」不算，「这个量级下选 Redis 而不是本地缓存，因为要跑两个实例」才算。

第三道线，至少一次真实的问题排查。项目跑起来之后出过什么问题，怎么定位的。没上过线的项目往往过不了这条，因为很多问题只在真实使用中才会出现。

改一条看看差别

改前：

个人项目：待办事项 App 使用 Flutter + Firebase 开发，支持任务创建、提醒、多端同步，已发布到应用商店

改后：

个人项目：待办事项 App（Flutter / Firebase，应用商店在架，累计约 300 安装） - 离线优先：本地 SQLite 为主存，联网后按 updatedAt 双向合并；冲突策略是最后写入优先， 两台设备同时改同一条会丢一边改动，已在 README 标为已知问题 - 提醒在部分 Android 机型上被省电策略杀掉，改为 WorkManager 周期任务 + 精确闹钟兜底， 自测 3 台机型到达率从约 60% 提到 95% 以上

改后多了两样东西：一个没解决干净的问题，和一组自己测出来的数字。业余项目里敢写已知缺陷的人，可信度反而高，因为编出来的项目不会有缺陷。

和工作项目怎么排序

分三种情况。

工作内容和目标岗位对口：工作经历在前，业余项目压缩成一条放最后，作为「业余时间也在写代码」的旁证。

想换方向，比如从业务后端转基础设施，业余项目是你唯一的相关证据：可以放到前面，但标题上明确写「个人项目」，不要和工作经历混排，混排会被当成夸大。

工作内容不能对外细说，或者确实太薄：业余项目做主力，工作经历写清职责范围和技术环境就行，不要硬凑。

不管哪种情况，单条业余项目的行数不要超过工作经历里最长的那条。篇幅本身就是一种权重声明，业余项目写得比工作项目长，读者会按篇幅反推你的重心在哪。

追问的方向不一样

工作项目会被问「你负责哪部分」「团队怎么分工」。业余项目会被问「为什么这么设计」「现在多少人在用」「还在维护吗」。

最后一问最容易翻车。commit 停在一年前，简历上写「持续迭代中」，对方点开仓库就知道了。写「2025.03 停止维护，功能完整可用」比装作还在做要稳得多。

「多少人在用」也别绕。只有自己在用就写「个人使用」，面试官在意的不是用户数，是你有没有如实报数。

几种不算数的

跟着教程做出来、没有偏离教程的（博客、商城、待办，三件套尤其如此）；fork 之后只改了配置文件的；只有一个 init 提交的；停在架构图阶段、代码没跟上的。这几类写进去不加分，被问到会减分。

自查

每一条业余项目问自己：把它删掉，这份简历变弱了吗。没变弱就删，篇幅留给能撑住追问的内容。

改完之后整份扫一遍格式也有必要，业余项目和工作项目混写时，日期格式、标题层级、技术名词写法最容易不一致。

最后

业余项目的价值不在于它证明你热爱技术，在于它提供了工作项目给不了的东西：完整的决策链和从零到一的过程。写到这个程度，它才算数。