求职阶段的目标不是再学十个框架，而是把已有能力变成可信证据。招聘者需要判断你能否定义问题、完成实现、验证结果、处理失败并与团队协作。
一、三个项目比三十个 Demo 更有效
第一个是基础项目：数据清洗、传统模型或简单深度学习，重点展示数据理解、基线和评测。第二个是方向项目：CV、NLP 或 LLM 的核心任务，展示错误分析和技术选择。第三个是综合项目：加入 API、数据库、部署、监控、安全和用户反馈。
三个项目应共享一条成长叙事，但不要只是同一个聊天页面换模型。示例组合：客户流失预测 → 客服意图与实体抽取 → 带知识库、工单工具和人工审批的客服助手。
二、README 的七个必要部分
- 一句话说明问题和目标用户；
- 可点击的演示、截图或短视频；
- 架构图与数据流；
- 本地运行和配置步骤；
- 数据来源、许可与隐私边界；
- 评测表、基线、失败样本与成本；
- 已知限制和下一步。
README 不是安装命令的堆积。招聘者应能快速找到“解决什么问题、效果怎样、你做了什么、哪里还不可靠”。参考 GitHub 的 README 文档完善入口。
三、项目必须留下工程证据
提交历史应表现真实演进：数据基线、模型实验、接口、测试、部署、故障修复。不要一次性上传全部代码。保留配置示例、锁定依赖、测试命令和许可证；清理密钥、个人数据和不可再分发数据。
指标旁写清数据版本、切分方法和测试日期。LLM 项目记录模型、Prompt、检索配置、评测集、延迟与费用。Agent 项目额外记录工具权限、审批、最大步骤和停止条件。
四、简历如何写项目
使用“问题—行动—证据—边界”：为谁解决什么问题；你负责哪些模块；通过什么指标验证；仍有哪些限制。例如不要只写“使用 LangChain 构建 RAG”，而写“为 500 份内部文档建立带权限检索与引用回答，构建 80 题评测集，记录检索召回、引用正确率、P95 延迟和单次成本，并为证据不足场景加入拒答”。
所有数字都必须可以解释来源。没有线上用户时，就报告离线测试集规模、运行环境和测量方法，不要虚构业务提升。
五、面试准备分四层
基础层准备 Python、SQL、数据结构、HTTP、Git 和 Linux；模型层准备数据切分、过拟合、指标、优化和主方向模型；系统层准备 API、数据库、缓存、并发、部署、监控、安全和成本；项目层准备架构选择、失败案例和替代方案。
每个项目练习三个版本：30 秒概述、3 分钟结构化讲解、10 分钟深入追问。重点准备“为什么不用更简单的方法”“最严重的失败是什么”“如果流量或数据扩大十倍怎么办”。
六、从职位描述反推学习缺口
收集目标城市、行业和经验级别的 30 个真实职位描述，统计共同要求，而不是被单个岗位的长清单吓住。分成必须项、加分项和领域项，再映射到作品集证据。
每周投递少量高匹配岗位并记录结果：是否通过筛选、在哪一轮失败、被问到什么。连续出现三次的缺口才进入学习计划，避免因一次面试临时更换技术路线。
七、6 周求职执行周期
| 周次 | 核心任务 | 交付物 |
|---|---|---|
| 第 1 周 | 收集并拆解 30 个目标岗位 | 必须项、加分项和项目证据矩阵 |
| 第 2 周 | 整理三个项目，删除无效 Demo | GitHub 置顶仓库与统一 README |
| 第 3 周 | 完成在线演示、架构图、评测表 | 可点击作品集主页 |
| 第 4 周 | 写一页简历并练三档项目介绍 | 30 秒、3 分钟、10 分钟讲解 |
| 第 5 周 | Python/SQL/模型/系统模拟面试 | 错题本与项目追问清单 |
| 第 6 周 | 定向投递、复盘与迭代 | 投递看板和下轮改进计划 |
每日安排示例
工作日用 45 分钟补基础题，45 分钟改项目，30 分钟整理表达或投递。每周至少完成一次模拟面试和一次项目演示录像。不要全天刷题而停止项目，也不要只优化页面而回避 Python、SQL、指标和系统问题。
投递看板字段
记录岗位、来源、匹配项、缺口、投递日期、当前阶段、问题记录和下一步。把失败分成简历未通过、基础题、模型知识、系统设计、项目深度和沟通表达。只有同类问题重复出现，才调整学习路线。
八、求职前最终检查
- GitHub 首页有 2–3 个置顶完整项目；
- 每个项目可运行、可演示、有评测和失败样本；
- 简历中的每个技术点都能被追问；
- 能现场写基本 Python/SQL，并解释模型指标；
- 能画出项目数据流、权限边界和故障路径；
- 能说明你不知道什么，以及下一步怎样验证。
回到专题总路线图复查缺口。就业不是路线的终点：入职后仍要通过真实反馈继续完善数据、模型、工程和沟通能力。