SOLA INSIGHTS
软件项目做到什么程度，才值得写进简历？
学生经常问我做哪类项目最加分。我会打开现有代码，先看两件事：有没有一条真正跑通的主流程？如果我连续追问五分钟，学生能不能脱离稿子说清设计与自己的贡献？这两点还没做到时，换一个更新的技术栈并不会让项目更可信。
- 发布
- 最后核对
- 阅读时间
- 8 分钟阅读
先找一个你真的见过的麻烦
项目可以只解决学生自己、室友或一个校园组织反复遇到的小问题。重点在于先把现在的做法观察清楚：谁在做，哪一步最浪费时间，第一版产品准备改掉什么。能把这句话说准，后面的 scope 才不容易失控。
- 锁定一类具体用户，不写“适合所有人”
- 记录当前做法的实际步骤与麻烦
- 给第一版定一个可以演示的完成标准
第一版要小到你能在面试前真正发布
我会让学生把功能分成三类：缺了就无法完成主流程的、可以延后的，以及这一版明确不做的。这个分类本身就是面试素材，因为它能看出学生怎么考虑时间、复杂度和用户价值。只有功能名单，却没有一条可用流程，很难展示这种判断。
- 先打通一条端到端主流程
- 每接一个外部服务，都要说清它带来的价值与故障点
- 延后功能记成 Issue，不在主分支留半成品
我在 Code Review 里会连续问“为什么”
数据为什么存在这里？一个请求从用户操作到返回结果经过哪些步骤？失败后用户会看到什么？如果答案只是“教程这样写”，这一部分就还没有变成学生自己的知识。早期项目用一个简单结构解决当前问题完全可以，没有必要为了显得复杂而硬拆服务。
- 画出一次核心操作的数据流
- 准备一个考虑过但最后没有采用的方案
- 说清当前选择对开发时间、复杂度或性能的影响
故意让它失败一次，看看用户会遇到什么
断掉网络、提交空表单，或让后端返回错误，可以很快看出项目是否只处理了正常情况。一个用户看得懂的错误状态，加上几条保护核心规则的测试，很容易引出对验证、数据一致性和故障处理的面试追问。
- 测空值、边界值与异常返回
- 在服务端重新验证会影响业务结果的数据
- 把暂时没有处理的限制诚实写进 README
至少真正部署一次
本地能跑，上线后却可能出现环境变量、数据库连接、加载状态和移动端布局问题。项目不一定需要长期付费运行，但学生应该亲自走过一次部署，并让另一个人只看 README 也能把项目跑起来。这个过程留下的 bug，通常比新增一页功能更值得在面试里讲。
- 给查看项目的人一条不超过几步的演示路径
- 确认密钥与敏感配置没有进入仓库
- 留截图或短录屏，应对第三方服务临时不可用
写进简历前，把“项目有什么”与“我做了什么”分开
团队项目可以先讲整体目标，但接下来要很快回到学生负责的部分。使用 AI、教程或开源库本身没有问题；面试官更关心学生是否理解使用的内容、如何验证，以及自己实际改了什么。这条边界说得越准，项目反而越可信。
- 用“问题—选择—结果”讲清一条技术主线
- 准备一次真实的 bug、失败或返工经历
- 只声称能被代码、文档或队友支持的个人贡献