非科班90天转行AI大模型应用开发：从Prompt到RAG的实战路径

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, historyNone): 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, jsonpayload, headers{Authorization: Bearer API_KEY}, timeout30, ) 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 第一档企业知识库问答RAGRAG的完整名称是检索增强生成本质是“先查资料再回答”。为什么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(regionregion, periodperiod) 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应用开发是一个“反馈密集型”的工作代码跑没跑通、效果好不好、用户用不用反馈永远即时出现这正是快速成长的最好土壤。别等所有知识都学完再动手从一个最小脚本开始跑起来、做出来、讲清楚你会发现自己能走的路径比预想中远得多。