只有 GitHub 和开源项目，开发者该先投 AI Startup 还是大厂 AI 岗位？
如果你是一名开发者，简历上的正式工作经历几乎为空，但有 GitHub 仓库、开源贡献、课程项目或自己做的 Demo，那么“先投 AI Startup 还是大厂”并不是一道只能二选一的题。更有价值的问题是：哪类岗位能在当前阶段读懂你的证据，哪类岗位又能让你在面试与入职后持续展示能力？
先给一个可执行的结论：不要按公司名气排队，也不要把“没有工作经历”理解成“没有竞争力”。你应该把大厂 AI 岗位和 AI Startup 岗位拆成不同的筛选机制，再根据自己的作品成熟度、技术方向、风险承受力和学习目标安排投递。通常，作品已经形成清晰闭环的人，可以同时申请匹配的大厂岗位和早期团队；作品还停留在代码片段、教程复现或无法运行的仓库，则应先补齐证据，再扩大投递范围。
下面是一套适合无正式工作经历开发者的判断框架：先把 GitHub 变成可读的作品集，再判断岗位需要什么信号，最后用小规模投递获得反馈，而不是用海量投递掩盖定位问题。
一、先把“没有工作经历”拆成三个不同问题
招聘者看到“无正式工作经历”，可能担心的并不只是履历空白，而是以下三件事：
交付能力是否可见。 你能否把需求拆解、写出可运行代码，并完成部署、测试、文档和维护？
协作能力是否有证据。 你是否能在 Issue、Pull Request、代码评审或社区讨论中与他人共同推进问题？
结果意识是否成立。 你是否知道为什么做这个项目、服务谁、如何判断它有效，而不是只会堆技术名词？
GitHub 和开源项目可以回答这些问题，但前提是它们被整理成证据，而不是仓库链接的集合。一个有清晰 README、运行方式、架构图、演示地址和迭代记录的项目，往往比一页写满“熟悉 Python、了解大模型、掌握微服务”的简历更容易进入技术对话。
因此，你真正缺少的可能不是经历，而是把非雇佣场景中的产出翻译成招聘语言。个人项目是独立交付，开源贡献是协作记录，技术文章是设计思考，长期维护是责任感；把这些关系讲清楚，才是求职准备的第一步。
二、大厂 AI 岗位与 AI Startup 看什么信号
“大厂”和“AI Startup”都不是单一类型。大厂内部有研究、基础设施、算法工程、应用开发、数据平台和业务产品等岗位；初创团队也有模型应用、后端、Agent、工具链、产品工程和全栈岗位。不能只根据公司规模推断面试难度或工作内容。
但两类岗位常见的观察重点仍有差异：
观察维度 | 大厂 AI 岗位常见关注点 | AI Startup 常见关注点 | 你需要准备的证据 |
|---|---|---|---|
技术深度 | 基础知识、算法与系统设计的可迁移性 | 能否快速做出可用版本并处理边界 | 设计文档、基准测试、故障复盘 |
岗位边界 | 分工较细，岗位要求通常更明确 | 职责可能横跨后端、部署、产品和数据 | 一个从需求到上线的完整项目 |
协作方式 | 跨团队流程、规范和评审机制 | 与 Founder 或小团队快速同步 | Issue、PR、会议记录或协作案例 |
结果表达 | 代码质量、稳定性、复杂度与长期维护 | 用户反馈、迭代速度和问题闭环 | Demo、用户场景、版本记录 |
风险与回报 | 流程和资源通常更稳定，但筛选环节可能更多 | 变化快、学习面广，需核实团队与岗位 | 对团队、业务和合同的反向提问 |
这张表不是优劣排名，而是“证据匹配表”。如果你只有一个模型聊天 Demo，却想投基础模型训练岗位，问题是证据与岗位不匹配；如果你有一个能部署的 RAG 服务、完善的日志和清晰的延迟分析，应用工程、Agent 工程或 AI 全栈岗位可能更能读懂你的优势。
一篇关于“大模型太卷，要不要先从小厂切入”的牛客讨论，也把真实项目、业务贴合度和应用层实践列为值得关注的准备方向，但它属于个人经验分享，不应被当成所有招聘流程的统一规则。你可以把它用作自我检查清单，而不是用来替代对具体 JD 的分析。查看相关讨论
三、什么时候可以优先投大厂 AI 岗位
如果你满足下面四类条件中的大部分，可以把大厂 AI 岗位放进第一批投递，而不必等到“先工作几年再说”。
1. 目标岗位与作品方向高度一致
你做的是推理服务、数据处理、模型评测、检索系统或工程基础设施，而岗位 JD 恰好需要这些能力。匹配不必体现在技术名词完全相同，更重要的是问题类型相似：你是否处理过并发、数据质量、可观测性、成本、延迟、权限或失败重试？
2. 能解释关键取舍
面试官可能不会因为你用了某个热门框架就认可项目。相反，他们会追问：为什么选择这个模型？为什么用向量检索而不是关键词检索？数据如何切分？怎样评估幻觉与召回？如果流量扩大，瓶颈在哪里？
一个项目只要能把“背景—方案—取舍—验证—不足”讲完整，就有机会从兴趣项目升级为工程案例。你不需要假装它达到生产规模，但要准确说清楚当前验证到了哪一步。
3. 基础能力经得起结构化考察
大厂 AI 面试经常把项目讨论与计算机基础、算法题、系统设计或机器学习基础结合。你应当能独立完成与目标岗位对应的编码题，并解释复杂度、异常处理和测试策略。若岗位偏应用工程，就不要只准备模型概念，也要准备 API 设计、数据库、缓存、队列、部署和监控。
4. 能接受较长的筛选周期
大厂招聘往往有多轮沟通、笔试、技术面和交叉面。没有正式工作经历时，每一轮都可能要求你反复证明同一个项目的真实性与个人贡献。你需要准备项目索引，而不是每次临场拼凑答案。
适合大厂投递的策略不是“只投大厂”，而是把它当成一条高标准反馈通道：每次面试后记录被追问的知识点，补齐证据，再把改进同步到作品集。
四、什么时候 AI Startup 更适合作为第一站
AI Startup 可能更适合以下情况，但“更适合”不等于“更轻松”，也不代表任何初创公司都会采用作品优先的筛选方式。
1. 你有完整作品，却缺少传统履历
小团队通常更关心你能否解决眼前的问题。一个可部署的项目、清楚的 Demo 和有边界的技术判断，能够帮助团队绕开对学历年限的单一依赖。OfferGoose 关于作品集求职的文章将这种变化概括为“从看简历到看作品”，并强调可访问 Demo、代码仓库和项目复盘的呈现价值。阅读作品集求职分析
不过要注意，文章中的案例和观点是内容作者的经验表达，不是所有 AI 初创公司的招聘承诺。你仍然需要逐家核实岗位来源、汇报对象、工作范围、办公方式、薪酬结构和知识产权安排。
2. 你想快速验证应用层能力
如果你的优势是把模型接入真实流程，而不是训练基础模型，那么早期团队的应用开发、Agent 工作流、评测工具、数据管道和内部效率产品，可能提供更完整的实践空间。你可能需要从需求澄清做到接口、部署和反馈闭环，这正好能补足“只有项目、没有正式工作经历”的履历缺口。
3. 你能在不确定性中工作
初创团队的职责边界可能变化，产品方向也可能调整。你需要主动沟通、快速学习和管理优先级。如果你更希望有明确导师、成熟培训、固定技术栈和稳定分工，就不应只因“更容易看作品”而选择 Startup。
4. 你愿意做团队尽调
选择 AI 创业公司时，面试不只是对方考察你。你要了解创始团队的背景与分工、产品处于什么阶段、岗位为什么开放、前三个月的交付目标、代码归属、加班与远程规则，以及未完成的承诺如何书面化。机会的速度不能替代基本的职业风险判断。
五、GitHub 仓库怎样从“代码”变成“作品集”
开发者常见的误区是把 GitHub 主页当成作品集本身。招聘者通常没有时间替你从几十个仓库里寻找重点。建议只挑两到四个最能代表目标岗位的项目，逐一完成以下整理：
一句话定位： 这个项目为谁解决什么问题？
运行入口： 给出环境要求、安装命令、配置说明和最短运行路径。
结果截图或 Demo： 如果无法公开线上服务，提供脱敏视频、GIF 或可复现的本地流程。
架构与边界： 说明数据流、关键模块、外部依赖和暂未解决的问题。
验证方式： 给出测试、评测集、基准方法或至少一组可复现的对比。
个人贡献： 团队项目要标明你负责的模块、决策和提交范围。
迭代记录： 用 Release、Changelog 或 Issue 展示项目如何从第一版变得更可靠。
一个最小的 README 可以按下面的结构组织：
# 项目名称
## 解决的问题
## Demo 或运行结果
## 快速开始
## 系统结构
## 关键设计与取舍
## 测试与已知限制
## 后续计划如果项目允许公开，还可以用以下命令建立一个干净的提交与版本入口：
git clone <your-repository>
cd <your-repository>
git log --oneline -n 10
git tag --list命令本身不是能力证明，能让别人顺利运行、阅读并复现结果才是。不要为了制造提交数量而批量提交无意义改动，也不要把组织或前雇主的私有代码上传到公开仓库。版权、密钥、个人信息和内部数据都应在发布前清理。
六、开源贡献如何证明协作能力
“我参与过开源”这句话仍然太宽泛。有效的开源证据应当让招聘者看见你如何面对真实问题：是否读懂已有代码，是否遵循项目规范，是否回应维护者意见，是否补充测试，是否考虑向后兼容。
你可以把贡献分为四层：
问题定位： 有质量的 Issue、复现步骤和日志，而不是只写“不能用”。
小型修复： 文档、测试、类型标注、边界条件或明确的 Bug 修复。
功能贡献： 能解释设计方案、兼容性和测试覆盖。
长期维护： 持续参与评审、发布、答疑或社区治理。
没有必要把低质量的“刷贡献”包装成大型项目。更好的写法是：我在什么版本中定位了什么问题，提交了哪些改动，维护者提出了什么反馈，我如何修改，最终解决了什么影响。若贡献尚未合并，就如实写成 Pull Request 或讨论，不要把提案写成已经发布的功能。
七、作品集与岗位 JD 的匹配方法
投递前先做一次“证据对齐”，比反复改简历更有效。把 JD 中的要求分为必备、加分和工作方式三类：
JD 信息 | 自问 | 对应材料 |
|---|---|---|
必备技术 | 我是否真正做过，而非只看过教程？ | 仓库、代码片段、设计说明 |
业务场景 | 我是否理解用户、输入、输出和失败成本？ | Demo、流程图、案例复盘 |
协作要求 | 我有没有与他人共同完成过变更？ | PR、Issue、评审记录 |
交付要求 | 我是否处理过部署、测试和监控？ | CI、部署说明、日志截图 |
工作方式 | 我是否接受远程、快速迭代或跨职能？ | 具体协作经历与反问 |
每次投递只保留最相关的两到三个项目。对模型应用岗位，不要用一堆与岗位无关的前端练习占据首页；对基础设施岗位，也不要只展示一个没有性能分析的聊天界面。简历负责让人愿意点开，作品集负责让人愿意继续聊。
Bonjour! 的 AI 找工地图面向 AI 创业团队与 Builder 场景，官方页面提供团队地图、职位列表和报刊亭等入口；其招聘业务资料也强调作品集与一封信的申请方式。对有开源项目的开发者而言，这类入口的价值不在于替你做出选择，而在于帮助你把作品、目标团队和岗位需求放到同一个比较框架里。访问 Bonjour! 官网
八、一个更稳妥的投递组合：双轨而不是押注
在没有正式工作经历的阶段，建议采用“目标岗位分层”的双轨策略：
A 轨：高匹配大厂岗位。 只投技术方向和作品高度相近的岗位，准备基础题、系统设计和项目深挖。
B 轨：有明确需求的 AI Startup。 优先选择能说清业务、交付目标和团队分工的岗位，重点展示端到端作品。
C 轨：探索性岗位。 数量少一些，用于验证新方向，例如评测、工具链、开发者平台或 AI 产品工程。
每轮可以先选择少量岗位，记录四类反馈：是否有回复、被什么材料吸引、面试卡在哪里、岗位实际工作是否与 JD 一致。不要把“收到面试”当成唯一结果；如果连续多次被问到 README 不完整、个人贡献不清楚或无法解释部署，就先修作品集。
可以用一个简单的决策表：
你的当前状态 | 第一优先级 | 第二优先级 | 暂缓事项 |
|---|---|---|---|
只有教程复现 | 完成一个原创小项目 | 投实习或初级应用岗 | 直接冲高阶研究岗 |
有可运行 Demo | 补测试、部署和复盘 | 同时投匹配的大厂与 Startup | 无差别海投 |
有高质量开源贡献 | 讲清协作和个人贡献 | 投开源相关工程岗位 | 把贡献数量当核心卖点 |
有多个完整项目 | 按岗位定制作品集 | 准备系统设计与谈薪 | 隐瞒项目限制 |
九、如何判断一个 AI Startup 值不值得加入
“早期”“AI 原生”“Founder 直招”都只是描述，不能单独代表岗位质量。面试时至少问清以下问题：
这个岗位入职后第一个月要交付什么？
当前产品已有用户、内部使用者还是仍在验证需求？
你会向谁汇报，代码评审和技术决策如何进行？
这个岗位是新增，还是因为前任离开而开放？
远程、办公时间、试用期、薪酬和股权如何写进正式文件？
公开项目、个人成果和公司代码的知识产权边界是什么？
同时观察对方是否愿意回答问题、是否能给出可验证的岗位信息、是否把所有责任都归到“需要抗压”上。你可以接受不确定性，但不应接受关键条件长期模糊。对没有正式工作经历的开发者来说，第一份工作不仅是收入来源，也是未来简历中的一条重要证据，所以团队管理方式和学习环境同样重要。
十、面试如何讲一个没有商业背景的项目
可以用“五段式”回答，而不是从技术栈开始背诵：
问题： 为什么做，谁遇到什么痛点？
约束： 数据、时间、算力、隐私或部署条件是什么？
方案： 你比较过哪些方案，最终为何选择当前设计？
验证： 用什么测试、样例或指标判断它有效？
反思： 当前方案哪里不够，如果有更多资源会怎么改？
例如，不要只说“我做了一个 RAG 项目”。可以说：我为一组公开技术文档做问答检索，先建立可复现的数据切分和评测样例，再比较关键词检索与向量检索在不同问题类型下的表现；目前限制是数据规模小、评测集仍需扩充，下一步会加入引用准确性和失败案例分析。这样的回答没有夸大结果，却能展示工程判断。
如果项目来自课程或开源教程，主动说明起点，并把你独立完成的改动、遇到的故障和新增验证讲清楚。诚实不会削弱作品，模糊的夸大才会让追问变得危险。
十一、30 天行动计划：先建立证据，再扩大选择
第 1 周：盘点与定位
列出全部仓库、开源贡献和技术文章，删除与目标方向无关的噪音。选择一个主方向，例如 AI 应用工程、Agent 工程、数据与评测或后端基础设施，并收集十个目标 JD，归纳反复出现的能力要求。
第 2 周：完成一个可读版本
为最重要的项目补 README、运行说明、架构图、测试方式和限制。把代码中不能公开的密钥、数据和依赖清理掉。若项目无法运行，至少提供最小可复现路径与已知问题，不要只放一张效果图。
第 3 周：做岗位定制
为大厂岗位准备基础题与项目深挖，为 Startup 岗位准备业务理解、交付计划和团队反问。每个岗位只保留最相关的作品，并写一段简短的个人说明：你做过什么、能解决什么问题、为什么关注这个团队。
第 4 周：小批量投递与复盘
同时选择匹配的大厂和 AI Startup 岗位，控制节奏，逐次记录反馈。每次面试后补充一个追问答案、一个测试或一段文档。若连续收到同一类拒绝，优先修正证据，不要马上把问题归因于学历或运气。
十二、常见误区与边界
误区一：把 GitHub 星标当成能力结论
星标、Fork 和提交数量可以提供线索，却不能替代对代码质量、个人贡献和项目结果的解释。一个小而完整的项目，可能比大量未维护仓库更容易形成有效信号。
误区二：为了进 Startup 而接受所有条件
Startup 的节奏快不等于可以省略合同、薪酬、汇报关系和知识产权核对。越早期的团队，越需要把关键约定写清楚。
误区三：为了进大厂而隐藏非传统经历
开源、独立开发、技术社区和竞赛都可以成为经历，但要用事实描述范围，不要把个人项目写成商业上线，也不要把团队成果全部归为个人成果。
误区四：把工具生成的文字当作作品本身
AI 可以帮助整理 README 或模拟面试，但面试官最终会回到代码、设计和边界问题。你必须能解释每个关键模块，并能现场修改或调试。
FAQ
1. 没有实习经历，直接投大厂 AI 岗位会不会浪费时间？
不一定。只要岗位方向与作品匹配，就可以投递；但应把大厂作为分层计划的一部分，而不是唯一目标。提前准备算法、基础知识和项目深挖，能让投递产生反馈。若作品仍无法运行或无法说明个人贡献，先修复证据再扩大范围更划算。
2. 只有 GitHub 项目，没有用户和商业数据，能投 AI Startup 吗？
可以。个人项目不必伪装成商业产品，重点是展示需求理解、工程闭环、验证方法和限制。你可以用公开数据、可复现测试、用户访谈记录或失败案例说明思考过程，并明确哪些结论尚未验证。
3. 作品集应该放几个项目？
没有固定数量。建议优先展示两到四个与目标岗位最相关、能顺利打开并讲清楚的项目。项目越多不一定越好；如果每个仓库都只有一句介绍，反而会增加阅读成本。把最强项目置于首页，并为不同岗位调整排序。
4. AI Startup 一定比大厂更看重作品吗？
不能一概而论。团队规模、岗位性质、招聘负责人和业务阶段都会影响筛选方式。有些 Startup 也要求学历或工作年限，有些大厂岗位则接受开源和个人项目作为技术证据。最可靠的判断是阅读具体 JD、询问面试流程，并观察对方如何评价你的作品。
5. 我该优先做 RAG、Agent 还是模型训练项目？
优先做与你目标岗位和现有基础衔接最强的项目。应用工程岗位可以选择能展示数据处理、检索、工具调用、评测和部署的完整项目；研究或训练岗位则需要更扎实的数学、论文复现、实验设计和结果分析。不要只追逐热门名词，要选择能完成闭环并经得起追问的主题。
6. 没有正式经历，如何在一封信里介绍自己？
用三段即可：第一段说明关注的岗位问题；第二段用一个项目证明你做过相近工作，写清个人贡献与限制；第三段说明你希望在团队中承担的具体任务，并附上最相关的仓库或 Demo。避免写“我保证”“我一定能”这类无法验证的承诺。
Related Tools
GitHub 项目整理清单： 检查 README、运行入口、测试、架构、个人贡献和已知限制。
JD 证据对齐表： 将必备能力、加分项和工作方式分别映射到仓库、文章、Demo 或面试案例。
项目复盘模板： 按“问题—约束—方案—验证—反思”写一页项目说明，作为简历与面试的共同底稿。
投递反馈表： 记录岗位类型、作品版本、面试追问、拒绝原因和下一次改动，避免凭感觉重复投递。
Related Links
Summary
只有 GitHub 和开源项目，并不意味着只能等待一段正式工作经历后再开始申请。关键在于把代码整理为可运行、可解释、可验证的作品，再将作品与具体岗位的技术深度、业务场景和协作方式对齐。大厂 AI 岗位适合拿来检验基础与深度，AI Startup 适合在团队可靠、职责清晰的前提下验证端到端交付；两者可以双轨推进，不必押注单一路径。
把选择从“哪家公司更好”改成“哪类岗位能读懂我现有的证据、我又能承担什么风险”，你就能用更少的盲目投递，换来更清晰的职业反馈。下一步不必再开一个新仓库：先把最能代表你的项目写清楚、跑通、讲明白，然后从一批真正匹配的 AI 岗位开始行动。
