1. 为什么非科班反而能做AI大模型
过去这一年，AI大模型彻底改变了软件开发的供需结构。以前想做人工智能，简历上必须写“机器学习岗”，门槛高得像隔了一堵墙：数学、论文、名校学历，缺一不可。现在情况完全不一样了，大模型把“算法能力”封装成了接口，企业真正缺的是“能拿着模型解决业务问题”的人。这类人不需要亲手从零训练一个模型，而是要知道模型擅长什么、不擅长什么，怎么搭链路、怎么处理数据、怎么调效果、怎么控制成本。说白了，行业需求从“造发动机”转移到了“把发动机装到车子上跑起来”，后者对动手能力和业务理解的要求远大于数学推导能力。
我遇到过很多非科班的朋友，有的之前做运营，有的做销售，有的做前端，他们最常问的一句话是：我现在转AI大模型还来得及吗？我的回答通常是：如果愿意花90天，把大部分精力放在“做项目”而不是“看教程”上，完全来得及，而且非科班背景反而可能成为差异化优势。
这篇博文就适合正在观望大模型方向、手里有一两个月的可支配时间、想通过一套实战路径切入AI应用开发的人。我会把这90天拆成三个阶段，每个阶段干什么、怎么做、避哪些坑，以及最后求职时怎么把项目成果变成薪资筹码，一次性讲透。我只讲我验证过的路径，不灌鸡汤，不堆术语，每一步都能照着落地。会有一点基础要求，你要能写点Python、愿意装环境、有耐心调试报错，做到这三点剩下的交给方法。
1.1 大模型行业的真实缺口不是“算法工程师”
如果你刷招聘软件，会看到AI岗位分好几类。第一类是预训练/底层模型研究岗，要求数学、框架源码、论文复现，这类岗位确实是科班的主场。第二类是模型微调/推理优化岗，要懂训练技巧、懂分布式、懂显存优化，这需要不少实操积累。第三类是应用开发岗，也是目前数量爆发最快的一个方向：把已有的大模型API接进业务系统，做知识库问答、做智能客服、做数据分析助手、做自动化工作流。这类岗位的技术重心根本不在数学，而在工程落地。
我用一个简单的分层来理解这件事。大模型技术栈可以分三层：底层是预训练模型，中间是微调和对齐，上层是应用开发与业务集成。前两层需要深度算法能力，上层更需要的是：理解模型参数怎么调、知道怎么用Prompt控制行为、会搭检索链路、会把工具函数交给模型调用、能评估效果、能部署上线。
对非科班选手来说，上层就是最现实的切入点。它不是算法岗的“降级版”，而是一个独立岗位。在真实企业里，这部分人往往比纯算法背景的人更贴近业务，因为部署一个能用的智能体，本质上是软件工程加产品判断的组合。
还有一个容易被忽略的点：纯算法背景的人往往缺少对业务痛点的体感。我在实际项目里见过很多不错的工程师，模型调得飞起，但产品上线后用户不用，因为回答不接地气、流程不贴合实际使用习惯。反倒是从业务岗转过来的人，天然会从“用户怎么用”的角度设计AI功能。所以某公司校招面试官问过我一句话：你觉得AI落地难在哪里？我后来想明白，难点从来不是模型能力，而是从需求到链路的翻译能力。这种能力，非科班完全可以通过刻意练习获得。
1.2 非科班手里的三张底牌
先说第一张：行业上下文。如果你之前在某行某业待过，你比谁都清楚哪些环节费时费力、哪些数据散落在文档和表格里、哪些问题是客户反复问的。大模型项目第一步永远是“找一个值得做的场景”，这恰恰是行业经验发挥价值的地方。一个懂业务的人，提需求会提得更准，方案选型也会更理性。
第二张是产品思维。很多人忽视这一点，其实AI应用的成败最后拼的是体验设计：模型什么时候该拒绝回答、回答太长用户不看怎么办、报错信息能不能让人看懂，这些都不是算法问题，而是产品判断问题。非科班转行者往往有更多产品意识，因为你在之前的岗位上被“用户满意度”毒打过，你知道一个功能没人用就是白做。
第三张是学习耐性。非科班天然没有“科班光环”，所以不会好高骛远。我身边很多非科班转行的人，第一次跑通接口都会开心很久，会把每一步都记录下来。这种心态在项目实战里特别宝贵，因为AI项目往往80%时间在跟数据较劲、跟效果较劲，没有记录习惯的人很容易半途放弃。
很多人最大的心理障碍是“数学不好”。我得说句实话：做AI应用开发，90%的工作用不到高数。你需要理解的基本概念无非是：概率（这个模型回答这句话有多大把握）、向量（文本变成了一串数字可以算相似度）、上下文化（模型只能看到你给的对话历史）。这些用高中知识加一点直觉完全够用。真正需要系统性补数学，是当你做了三四个项目、想深入模型内部机制的时候，那时候带着问题去学效率完全不一样。
2. 90天学习路线：从完全陌生到能动手开发
很多人上手大模型容易犯一个典型错误：前两周全在“看”。看得懂Transformer结构，看懂了Attention公式，觉得自己懂了，一打开代码编辑器手还是空的。大模型是一门极端依赖“手感”的技术，很多问题只有亲手写代码才会暴露，比如上下文窗口怎么管理、API返回格式怎么解析、长文本过载怎么截断。所以我这套90天路线把“动手”放在最前面，“补理论”放在项目之后，顺序反了，效率至少要差一倍。
时间分配上，我建议前30天只干一件事：把模型用起来；中间30天做一到两个真实项目；后30天打磨作品集并进入求职节奏。三个阶段的界限不用太死，可以根据自己的节奏灵活调整，但阶段顺序不建议换。下面我把每个阶段的重点任务和验收标准写清楚，方便你按天规划。
2.1 前30天：把模型跑通，把Prompt调明白
第一周的任务是打通调用链路。理解四个核心概念就可以开始写代码：token是模型读写文本的最小单位，上下文窗口是模型一次能看到的文本上限，temperature控制回答随机性，system prompt是给模型的角色设定和规则约束。别在这四个概念上反复纠结，直接打开官方文档，把最简单的对话接口跑通。
跑通之后做一件特别容易被忽略的事：写一个自己的调用函数，而不是一直用官方示例代码。区别在哪？官方示例是“演示”，你自己封装一层之后才能体会到接口设计中的细节，比如超时重试、错误码处理、多轮历史怎么传。我建议第二周花时间做20个Prompt实验，每次只改一个变量，记录变化规律。这是训练Prompt直觉最有效的方式，没有之一。你可以自己设计一组测试，比如：同样的任务，temperature设0.1和0.9差距有多大；加了“你是某行业资深专家”和什么都不加，回答差异在哪；给一个示例和给三个示例，输出稳定性变化。
第三周开始处理模型返回的JSON。很多初学者在这里卡住，因为模型输出的格式偶尔会不符合预期。你需要学会解析、校验和兜底。比如让模型返回一个包含答案和置信度的JSON，用代码把它解析成字典，解析失败时设计重试或降级逻辑。这套能力在后面积累Agent项目时会非常重要。第四周的目标是做出第一个独立小应用。命令行工具就可以，比如一个“周报生成器”，输入这周做的几件事，输出一篇完整周报。不用做界面，能跑通即可。这个阶段的验收标准是：你能向别人完整解释这个应用的数据流向，从用户输入到API调用到结果展示，每一步都清楚。
这里给一个最小调用示例，方便你有个直观印象：
import requests def chat(prompt, history=None): payload = { "model": "qwen-plus", "messages": [ {"role": "system", "content": "你是资深工程顾问，回答简洁、有依据，不确定就说明不确定。"} ] + (history or []) + [{"role": "user", "content": prompt}], "temperature": 0.3, "max_tokens": 1024, } resp = requests.post( API_URL, json=payload, headers={"Authorization": "Bearer " + API_KEY}, timeout=30, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]注意替换成你自己的API地址、API Key、模型名。调用时把temperature设低一点，知识问答类任务0.2到0.5都合适，创意生成类可以适当调高。前30天不要碰微调、不要看那些复杂框架，先把接口和Prompt手感练出来。这一阶段最容易犯的错，是收藏一堆教程、跟风买课，却连一个本地脚本都没写完。请记住：每看完一个知识点，必须转化为一次可运行代码，否则等于没学。
2.2 中间30天：用真实需求做项目，替代无效学习
中间30天是整个路径里最重要的一个阶段，因为大部分人在这里掉队。方式很简单：不再跟着教程敲代码，而是自己找一个真实问题，把它做成一个完整的项目。
我知道有人会说：可我还不会那个框架，怎么做项目？这就是顺序问题。你要先有项目，才会有针对性地学框架，而不是反过来。比如你要做一个“合同关键信息提取工具”，你会天然去搜索怎么解析PDF、怎么让模型稳定输出JSON、怎么处理长文档。这些搜索和理解都是带着问题发生的，记忆会非常牢固。
找项目的原则有三个：足够小、足够真实、必须能用上。足够小指范围可控，比如“帮HR筛选简历并给出评分”，而不是“做一个公司级AI中台”。足够真实指你确实有这项重复劳动，或者你身边确实有人为此头疼。必须能用上，意味着项目得有明确的输入输出，比如给一份文档、返回一个结构化结果。找几个常见方向参考：会议纪要转行动项、客服对话摘要、赛事报名信息的结构化提取、行业研报的疑问解答、销售话术生成和评分。
我用一个“企业知识库问答”作为示例，因为这是目前最典型的需求，也是面试时最容易讲清楚的项目。项目的本质是：把企业内部文档作为知识来源，用户提问时，系统先检索相关片段，再让大模型基于检索结果生成答案。整体链路是：文档加载、分块、向量化、存储、检索、重排、生成问答。中间30天你只需要把这条链路完整跑通，先不管花里胡哨的优化。
第一周做数据准备和分块。收集50到200页真实文档，清洗掉页眉页脚、乱码、无效字符，按标题和段落结构切块。第二周做向量化和检索。选择一个Embedding模型，把文本块变成向量，存入向量数据库，做一个简单接口：输入问题，返回最相关的4到6个文本块。第三周做生成环节。把检索结果拼进Prompt，让模型只依据材料回答。第四周做效果评估和迭代。准备20个真实问题，人工标注标准答案，测试系统在召回和生成两端的效果，根据失败案例调整切分和Prompt。
中间30天结束后，你手里应该有一个能演示、能讲清楚、能说得出失败和修改过程的完整项目。这个项目的价值远超任何课程证书，因为面试官只关心一件事：你能不能独立解决真实问题。有项目就有证据，没有项目就只能听你描述“学过什么”，差异巨大。
2.3 后30天：作品打磨、面试模拟和求职冲刺
后30天可以分两条线并行：一条线把项目打磨到“可展示、可讲解、可提问”，另一条线围绕目标岗位准备简历和面试应答。
先说打磨。很多人的项目做完了只放在本地，别人想看还要传文件、配环境，体验很差。我强烈建议至少做到两件事：第一，把项目部署到公网或局域网服务器上，让协作者用一个链接就能访问；第二，写一份完整的README文档，内容包括项目背景、整体架构图、关键决策说明（为什么选RAG而不是微调）、性能指标、失败案例和优化过程。再进阶一点，录一条5到10分钟的讲解视频，把屏幕录制开起来，一边操作一边讲清楚项目链路和结果。你没有看错，视频就是作品集的一部分，很多面试官没时间逐字读你的文档，但一段清晰的视频片断可以快速建立信任感。
后30天还要开始做面试准备。把项目的每个重要决策复习一遍，确保被追问时能给出理由。比如“为什么切分块大小选这个值”，你要能回答“因为测试下来，块太大导致检索结果包含太多无关信息，块太小又丢上下文，最后选了一个经验值并在评测集上验证过”。这种细节回答，比任何漂亮措辞都加分。另外，开始按目标公司或目标岗位的JD要求，逐条对照自己的技能树，找出最薄弱的两三个点，用最后两周针对性补齐。
需要提醒的是，简历不要写“熟练掌握了Transformer原理”这种心虚无据的描述，要写“构建了基于RAG的企业知识库问答系统，支持50页以上PDF文档，检索命中率从基线62%提升到81%”。面试官看到的是交付结果，不是你学过的东西。
3. 实战项目的三个档次与落地细节
实战项目是整个90天计划的核心资产。我的建议是：不要只做一个项目，而是做一个系列。系列的好处是可以在面试中展示成长曲线：第一项目解决简单的知识库问答，第二个项目开始让模型自己调用工具，第三个项目尝试微调和部署。这种层层递进的组合，比一个所谓“大而全”项目更有说服力。下面把三个档次的落地细节拆开讲，包括关键参数、实现逻辑和我自己踩过的坑。
3.1 第一档：企业知识库问答（RAG）
RAG的完整名称是检索增强生成，本质是“先查资料再回答”。为什么RAG会成为企业落地最常用的方案？因为大模型有知识截止时间和幻觉问题，它不知道你公司内部的规章制度、历史项目、产品文档，而RAG正好把检索能力和生成能力拼在一起，让模型先找到可信材料，再基于材料作答。
第一步是数据准备。文档解析永远比想象中麻烦。PDF有扫描版、有表格、有图片，转换后经常出现段落乱序、表格错位、特殊字符丢失。Word文档的页眉页脚、目录、批注也经常污染文本。我的建议是：尽量拿到最干净的源文件格式，比如Markdown、纯文本、结构化Excel；如果只能处理PDF，先用文本型PDF试水，扫描版走OCR。清洗阶段别怕花时间，因为数据质量直接决定检索效果，这个环节偷懒，后面无论如何调参都救不回来。
第二步是文本切分。这是最容易被低估的环节。切分大小直接影响检索质量：块太短，语义不完整，检索结果碎片化，模型没有足够上下文；块太长，无关信息过多，召回精度下降。我的经验值是用token而不是字符来度量，单个块控制在256到512个token之间，相邻块保持20到50个token的重叠，避免关键句子在切分处被拦腰截断。另外，优先按文档结构切分，比如标题、段落、章节，比固定长度硬切效果好得多。如果文档本身有清晰的层次，用“标题一、标题二、正文”这样的递归切分能保留上下文层级。
第三步是向量化与检索。选Embedding模型时，要重点考察中文效果和部署成本。文本块和用户问题都会先转成向量，然后在向量数据库里做近似最近邻检索。但只有向量检索不够，因为向量相似度对同义词、专业缩写、长尾查询不一定敏感。我建议做混合检索：向量检索负责语义召回，再用BM25这类关键词算法负责精确匹配召回，最后把两路结果合并去重。如果条件允许，可以再接一个重排环节，用一个交叉编码器对召回结果重新打分，进一步把最相关的片段排到前面。很多人在这个环节容易犯一个错误：一上来就追求炫酷的框架，其实先老老实实把基础链路跑通，再用评测集观察瓶颈在哪，再决定加不加重排，性价比最高。
第四步是生成。系统Prompt要明确约束模型“只依据材料回答，材料没有就说不知道”。示例：
你是企业内部知识库助手。请只依据【材料】回答用户问题。如果【材料】中没有可靠信息，请直接回答“资料库中未找到相关内容”，不要编造，不要使用自己的常识补充。 【材料】 {检索结果拼接} 【问题】 {用户问题}这一步还有一个容易踩的坑：检索结果可能包含多段不连续的内容，直接拼接进Prompt会给模型造成干扰。最好按来源文档和段落顺序组织，并在回复末尾标注出处。完成基础链路后，一定要做评估。最轻量的方法是准备20到50个问题并人工标好答案，然后统计三个指标：召回命中率（正确答案片段是否出现在检索结果里）、生成准确率（最终回答是否正确）、无答案拒答率（资料没有答案时模型有没有乱说）。没有评估就直接上线，后面出现的效果波动你根本分不清是Prompt问题、检索问题还是模型问题。
3.2 第二档：轻量级Agent工作流
RAG解决的是“从文档里找答案”的问题，第二个档次要解决“让模型自己操作工具完成多步任务”。这类系统的核心叫函数调用，也叫工具调用。大模型本身不会执行代码，但它可以理解用户意图，然后从你注册的函数列表里选一个，输出一段结构化的调用参数，你的程序拿到这段参数后真正执行函数，把结果回传给模型，再由模型组织最终回答。
我举个例子。假设你要做一个销售分析助手，用户在对话框输入“我想看华东区上个月的销售额和环比变化”。如果不加工具，模型只能瞎编数字。加上工具后，你可以注册两个函数：
def get_sales_by_region(region: str, period: str) -> dict: """按区域和周期查询销售额""" # 内部翻译成SQL并查询数据库 return query_sales(region=region, period=period) def get_previous_period(period: str) -> str: """获取上一周期的日期段""" return last_period(period)模型收到用户问题后，不是直接回答，而是判断需要调用哪个工具、传什么参数，输出类似这样的结果：
{ "name": "get_sales_by_region", "arguments": "{\"region\": \"华东\", \"period\": \"2025-05\"}" }你的程序解析这段JSON，执行函数，把结果通过消息返回给模型，模型再结合结果生成“华东区五月销售额为xxx，环比增长xx%”的最终回答。这样整个系统的表现是：模型负责拆解任务和总结答案，你的代码负责和真实系统打交道，双方各自发挥长处。
做Agent项目有一个最关键的避坑清单：第一，必须设置最大迭代步数，否则模型在复杂任务里会陷入循环调用，白白消耗成本和时间；第二，工具列表不要开太广，只开放当前场景需要的白名单工具，越少越不容易选错；第三，给工具写清晰描述，模型就是靠描述理解工具用途的，描述含糊会直接导致调用失败；第四，保留人工兜底入口，Agent出错时必须允许用户中断、重试或直接转移到人工处理，不要追求全自动。
这一档次的项目非常适合做“数据分析助手”“工单自动分诊”“日程管理助手”等方向。面试时你可以重点讲清楚：哪些步骤是模型自主决策的，哪些步骤是代码强约束的，边界为什么这么划，这比单纯展示“我能调API”更有深度。
3.3 第三档：模型微调与部署（加分项）
第三档次是模型微调和本地部署，这块做好了非常加分，但我建议把它定位成“加分项”而不是“必选项”。前两个项目已经足够证明应用开发能力，微调是让你和其他候选人拉开差距的关键。
先说什么时候才需要微调。RAG解决的是“模型不知道的知识”，微调解决的是“模型行为的风格和能力塑造”。比如你希望模型在客服场景中话术更委婉，希望它学会你公司内部特有的回复格式，希望它每次输出都带着工单编号和标签，这些Prompt规则很难完全约束住，微调反而效果明显。但要注意，微调不是把新的知识记进模型，你如果想喂私有知识，优先用RAG，微调既贵又容易过拟合。
真做微调时，用参数高效微调的方法，比如LoRA或QLoRA。它的思想是冻结原有模型参数，只训练一小部分增量参数，成本极低，单张消费级显卡也能跑起来。以7B模型为例，FP16精度下显存占用大约14GB，而用4bit量化加LoRA方式，显存占用可以压到5GB左右。常用参数可以这样设：秩rank取8，缩放alpha取16，学习率取2e-4左右，训练3个epoch。数据集格式一般是这样：
{ "instruction": "把下面的客服回复改写得更礼貌专业", "input": "我们不提供这个服务。", "output": "非常抱歉，目前这项服务暂未开放，您有其他需要我帮您确认的吗？" }数据量不用多，质量远比数量重要。起步500条精心整理的样本，效果已经能看到明显变化；几千条高质量数据足够覆盖大部分场景。训练完成后，要做的事是部署。个人开发和演示推荐先用量化部署，用诸如Ollama或vLLM这类开源工具可以把模型包装成一个本地API服务。部署时要记录模型效果和响应延时的变化，比如量化带来的精度损失有多大、并发请求多了会不会OOM。面试时能讲出“我训练了一个LoRA微调模型，并用4bit量化部署到一台普通机器上，推理速度达到了每token xxx毫秒”这种细节，基本可以直接锁定一个不错的Offer。
4. 求职面试：非科班如何证明自己能干活
项目做完了，简历也写得差不多了，接下来最现实的问题是：非科班背景怎么让面试官相信你能干活？我的经验是三个字：作品集。面试官嘴上可能不会明说，但他们会通过几个细节判断你：项目是否真实、你是否亲手做过、遇到问题会怎么排查。你要做的就是把这三个问题都提前准备好答案。
4.1 简历和作品集怎么组织
简历的一页纸原则同样适用于AI岗位，但内容结构要做调整。不要罗列“学过Python、学过Flask、了解大模型”这样的技能清单，而要把项目放在最显眼的位置，每个项目写一行项目背景、一行核心链路、一行量化结果。比如：“基于RAG的企业知识库问答系统”，核心链路是文档解析-切分-向量化-混合检索-生成，最终结果是支持上传50页PDF、问题回答准确率从60%提升到85%，内部试用覆盖3个部门。一行结果胜过三段自夸。
作品集我建议准备三件套：一是项目仓库地址，里面放README、代码和评估报告；二是可运行的线上Demo链接，方便面试官直接体验；三是讲解视频，5到10分钟，讲清楚问题、方案、结果和取舍。三件套能覆盖不同类型的面试官：技术型看代码，业务型看Demo，管理型看视频。
关于“非科班”三个字，我的建议是不要藏着掖着，也不要主动夸大。开场自我介绍直接说：我有三年行业运营经验，懂用户侧的业务链路，后来用90天系统转到大模型应用开发，做了两个落地项目。这种开场的好处是把劣势转化为定位：你不仅会做技术，还懂业务场景，这正是很多团队求之不得的复合背景。
4.2 面试常问问题与应答思路
AI应用开发岗位面试有个特点：考察范围广，但深度要求相对中等。面试官会更在意你有没有真实调优过项目，而不是能不能背出Transformer原论文里的公式。下面我按出现频率整理几个问题方向。
第一个必问题：请简述大模型是如何工作的。答这道题不需要引经据典，用通俗语言讲清楚三个阶段即可：模型在大量文本上做预训练，学到的是语言的统计规律和世界知识；然后通过指令微调和人类反馈强化学习让模型学会“按指令回答问题”；推理时，模型根据前文预测下一个字或词，逐步生成完整回答。如果你能再补一句“所以模型本质上是在做相关性预测，不是真正在知识库里查找”，面试官会立刻高看你一眼。
第二个高频问题：RAG和微调有什么区别，什么时候用哪个。回答思路：RAG是给模型外挂知识来源，适合知识更新频繁、需要引用出处的场景，优点是灵活、可追溯、成本低；微调是改变模型行为模式，适合特定风格、特定输出结构、高频重复的场景，缺点是贵、慢、不好更新。当面试官追问“两个能不能一起用”，你可以说“可以，先用RAG解决知识注入，再用微调让模型适应特定表达风格”。
第三个问题：你项目的检索效果不好，怎么排查。这是最能体现实战经验的问题。回答要给出一个完整的排查顺序：先检查切分策略，块太大或太小都会影响召回；然后看检索结果，是不是漏了关键片段，如果是，考虑换Embedding模型或加BM25混合检索；再看重排，如果召回出了相关片段但排得靠后，考虑加重排环节；如果检索结果都正常但回答还是错的，马上转向Prompt和生成环节。重要的是展现你有“分层排查”的方法论，而不是东一榔头西一棒子。
第四个问题是成本控制。真实工作中API成本很敏感。你可以答几个思路：优先用RAG缩小每次请求的上下文长度，而不是把所有资料都塞进Prompt；对高频问题加缓存；区分模型档次，简单任务用便宜模型，复杂任务才用大模型；设置调用限流和日志监控，发现异常调用及时止损。这些方案不需要你有企业级实践，但能说出来就说明你考虑过落地问题。
4.3 薪资谈判与Offer选择
关于“月入25K+”这个说法，我要说句公道话：薪资是能力的校验结果，不是喊出来的数字。90天能否拿到这个量级，取决于城市、公司规模、岗位类型和面试表现。在一线城市的中小型科技公司、外包转自研的项目型公司，AI应用开发岗的薪资区间可以到20K到30K，前提是你确实能独立交付项目。二三线城市或传统行业子公司可能会低一些。所以我建议把目标设成“用能力换区间上限”，而不是“我一定要某月某日拿到多少”。
薪资谈判的核心是把焦点从“非科班该不该打折”转移到“项目能带来什么价值”。你可以结合实际讲：公司如果能用一个RAG系统把客服重复咨询量降低三成，节省的人力成本远高于你的薪资。要让对方感觉你不是来学习的，而是来解决问题的。
Offer选择上，比薪资更重要的有三点：第一，岗位是否真的在用大模型做业务落地，还是只是挂个AI名头写普通代码；第二，团队有没有一个能带你的人，哪怕不是直属导师，同事里有资深工程师也有帮助；第三，你是否能接触到真实业务数据和用户反馈，这才是你下一个项目经验的主要来源。90天后拿到Offer只是第一步，持续增值靠的是进入一个能让你不断做项目的环境。
5. 高频问题与避坑清单
这套90天路径走到现在，我已经把所有主干内容讲完了，但我还想把一些最常见的坑集中列出来，做成速查清单。这些坑我在指导别人转行的过程中见了太多次，提前知道可以少走很多弯路。
5.1 学习阶段：别让“准备”拖死执行
最常见的问题是“一直准备、从未开工”。有人花两周看网课，有人买了一堆书，有人一个环境装了三天还没跑起来。我的忠告是：前期所有学习的唯一目标就是“让代码尽快跑起来”。你不需要理解逻辑回归、不用纠结梯度下降，先把接口调通，把一个脚本跑出结果，接下来的学习就会顺畅得多。
另一个坑是资料过载。大模型领域信息量爆炸，今天看一个LangChain教程，明天刷到一套微调指南，每样都开了个头，最后哪个都没吃透。解决办法是选定一条路线后屏蔽其他信息源，至少30天不受干扰。只跟着官方文档和你自己的项目走，其他内容一律收藏后不看，先完成一个项目再回头补充。
还有一个很多人没意识到的坑：遇到问题不搜索，干瞪眼。调试报错、环境配置、依赖冲突，这些问题99%都有人踩过，搜索引擎和社区里一定有答案，不要不好意思搜，独立解决一次问题就是一次实战演练。
5.2 项目阶段：数据与评测是两座大山
项目做不出来或效果很烂，多数不是因为代码能力，而是因为数据没准备好。我见过有人用一份乱糟糟的文档做RAG，检索效果差，就在Prompt里反复调，怎么调都没用，最后换了干净数据后效果立刻翻了倍。所以请优先重视数据清洗，这个环节花的时间，后面会在效果上成倍赚回来。
评测缺失也是个经典问题。没有评测集，你会陷入“改一下参数，试一下效果，感觉好了，再改一下，感觉乱了”的循环。建立最小评测集不需要很多工作，20个问题加人工答案就够，每次修改都跑一遍，用指标说话而不是感觉。哪怕指标是粗糙的，也比完全没有强，它会告诉你修改到底是真提升还是随机波动。
还有一类坑和成本有关：某些项目如果频繁调用长上下文接口，费用会快速累积。规划项目时要先计算成本预算。简单估算一下：如果一个请求平均消耗5000个token，一个月一万次请求，乘上单价就是成本。做任何项目之前先算这笔账，养成成本意识，这在工作中非常加分。
5.3 求职阶段：表达不清比技术不行更致命
很多技术不错的候选人挂在面试上，原因是讲不清楚项目。面试官问“你做了什么”，他的回答从背景、框架、安装过程开始讲，三分钟后还没进入正题。正确的叙事结构是：项目解决了什么问题、我用了什么方案、数据或结果是怎样的、最大的困难是什么、我怎么解决的。每个项目准备六层拷问：指标是多少、哪里失败了、为什么选这个方案、效果怎么评估、成本多少、下一步怎么做。把这六个问题写在文档里背熟，胜过大范围裸投简历。
还有一个容易踩的坑：只准备技术，不准备业务场景题。现在的大模型岗位非常喜欢问“如果给某业务做个AI功能，你怎么做”。这种题考的是一种思维框架，而不需要你真正实现。合理回答思路是：先定义用户和场景，再梳理当前流程的痛点，然后判断哪些环节适合模型介入，再给出具体链路设计，最后定量预估效果和成本。哪怕是虚构场景，这套回答过程也能展现你的解决方案能力。
5.4 一些补充建议
最后补充几条非常重要的认知：
第一，不要用“我在学”代替“我在做”。面试官一天面很多人，几乎每个人都说自己热爱AI、正在学习大模型。但只有作品集是客观的，它骗不了人。
第二，要有“陌生人视角”。做完项目后，找一个不认识你、也不了解项目背景的人，让他试用你的Demo、看你讲视频，然后给你提意见。陌生人反馈能指出的问题，往往是面试官也会发现的问题。
第三，持续维护你的项目。拿到Offer不代表项目的终止，回应用户反馈、优化评估指标、记录线上数据，这些都会成为你下一次跳槽时的素材。大模型领域工具迭代极快，一个不更新的作品集说明不了近况，持续迭代的项目才有说服力。
最后说一点个人体会：这套90天的方法，说到底不是“速成宝典”，而是一套把有限时间全部押注到真实交付上的策略。我自己在实践中最大的体会是，AI应用开发是一个“反馈密集型”的工作，代码跑没跑通、效果好不好、用户用不用，反馈永远即时出现，这正是快速成长的最好土壤。别等所有知识都学完再动手，从一个最小脚本开始，跑起来、做出来、讲清楚，你会发现自己能走的路径比预想中远得多。
