很多人第一次接触LLM应用工程师这个岗位脑子里冒出来的画面是把大模型的API接到项目里写两段prompt一个能聊天的机器人就上线了。真等自己动手做第一个要交付给客户使用的应用时才会发现调接口只是最表层的东西。你需要处理文档怎么切、知识库怎么更新、回答错了怎么追溯、并发上来之后成本怎么控这一整套问题全都压过来的时候你才真正在应用大模型而不只是在试用大模型。这篇指南是我自己从传统后端开发转做LLM应用的完整复盘。目标读者是那些已经有一点编程基础想系统进入这个领域、从入门做到实战落地的人。内容覆盖岗位定位、核心能力、RAG与Agent实战、工程化改造、评估体系、进阶方向以及一条可执行的学习路线。我把大量文档里不会写、但实际项目中一定会遇到的细节也一并讲清楚你可以把它当成一份可反复查阅的参考。1. 先搞清楚LLM应用工程师到底在解决什么问题1.1 岗位定位不是调API的是搭系统的很多人对LLM应用工程师的理解停留在会调用大模型接口的人。如果只是调接口那和调用一个普通的短信服务、支付SDK并没有本质区别。这个岗位真正值钱的地方在于你负责的是一个以语言模型为核心的完整系统设计。这个系统里包括输入处理、模型调用、外部知识接入、工具使用、结果校验、缓存降级、数据回流等多个模块。举个例子你要做一个企业内部的文档问答助手。表面上用户只是提问、获得回答但背后至少涉及文档解析与清洗、文本切片策略、向量化存储、检索召回、上下文组装、模型生成、答案引用溯源、日志记录与反馈收集。每一环都会直接影响最终回答质量。所以我对这个岗位的定义是用工程手段让大模型在一个具体的业务场景里稳定、可控、可度量地工作。稳定意味着同样的输入不会今天回答对、明天回答错可控意味着你能约束模型的行为边界不越权、不乱说可度量意味着你知道当前的回答质量有多好以及改了某个参数之后是变好了还是变差了。很多从算法岗转过来的同学容易犯一个毛病过度关注模型本身的参数和结构却忽视了业务交付中的工程问题。很多从纯后端转过来的同学则容易陷入另一个极端把大模型当成一个黑盒遇到问题就想多写几层缓存来解决却不理解生成式模型的不确定性给系统设计带来的本质变化。1.2 能力图谱至少需要这几块拼图我整理了一份能力清单按重要性排序可以参考对照自己缺哪块能力方向核心内容优先级提示工程指令设计、少样本示例、思维链、角色设定必须掌握上下文管理Token计算、窗口控制、上下文压缩必须掌握RAG技能文档解析、切片、向量检索、重排、引用溯源必须掌握Agent设计工具调用、任务规划、状态管理、异常恢复高频使用评估体系指标设计、测试集构建、回归评测、线上监测高频使用工程化缓存、限流、观测、灰度、成本控制必须掌握微调认知知道什么时候该微调、用什么方式微调进阶要求这里面我想特别强调评估体系。很多人学LLM应用开发把大量时间花在学提示词技巧上觉得写个更好的prompt就等于更专业的应用开发。等到真正做项目你发现你根本没法客观回答这个功能现在到底做没做好。你只是在试了几个case之后凭感觉说还不错。我后来在一个模拟项目X里吃过这个亏。给客户做客服助手前后改了十几版prompt每次自己测试都感觉很好结果上线第二天就被真实用户的问题击穿。原因很简单我从来没有系统性地验证过我只测了自己脑子里的那几个问题而真实场景的输入分布远远超出我的想象。后来我下决心搭建了一套评估流程才让后续的每一轮优化都建立在数据之上。1.3 与传统开发者的核心区别传统软件开发的核心是确定性同样的输入走同样的逻辑必然得到同样的输出。LLM应用开发引入了一个根本性的变化——同样的输入模型输出天然具有随机性。这带来连锁反应。第一测试方式变了。你不能靠断言返回值是否等于预期值来写单元测试你只能做基于统计和阈值的评测比如正确率、召回率、格式命中率。第二调试方式变了。传统程序出Bug可以单步追踪模型输出错了你只能通过调整输入、看日志、做实验来归因。第三容错设计变了。你需要假设模型的输出随时可能不符合预期并在下游做校验和兜底。举个具体例子。我之前做一个信息抽取功能要求模型从合同文本里抽取出甲方、乙方、金额等字段并且输出JSON。模型偶尔会输出多余的说明文字直接导致JSON解析失败。传统开发者看到这个问题第一反应是改代码兼容JSON容错但更稳的做法是在prompt里强约束输出格式同时对模型输出做后处理用正则或二次调用模型来规整再加入校验逻辑如果字段缺失则触发重试。这些手段组合使用比任何一个单独方案都可靠。理解了这层底层差异你就知道为什么LLM应用开发不能照搬传统项目的方法论而必须形成一套新的工程习惯。2. 地基与大模型交互的基本功2.1 提示工程第一门必修课但不是全部提示工程是入门LLM应用开发的第一道门槛。它的本质是用自然语言去编程——把任务需求、输出约束、背景知识、处理逻辑注入到模型的输入中让模型产生符合预期的输出。我推荐的提示词结构是角色与目标明确模型以什么身份、达成什么目标。比如你是一个严谨的合同审核助手你的任务是识别条款中的风险点。任务步骤把复杂任务拆成清晰的步骤引导模型一步步处理。比如第一步通读全文第二步找出涉及违约金的条款第三步判断该条款是否符合常规商业逻辑第四步输出结论。输出约束明确格式、长度、风格。比如用JSON输出包含risk_level和reason字段reason不超过50字。少样本示例给出1到3个输入输出对模型能模仿你的风格和格式。这对格式稳定性非常有帮助。边界说明遇到超出能力范围的情况应该怎么回应。比如如果信息不足直接说明无法判断不要编造。这里给一个实际例子。我要做一个客服工单自动分类功能输入是一条工单描述输出是分类标签。初始prompt是请将下面的工单分类为网络故障、账号问题、支付问题、其他。模型经常分类不准确。我改造后的prompt你是一个IT服务台的工单分类专家。 请把用户工单归类到以下四个类别之一网络故障、账号问题、支付问题、其他。 判断标准 - 涉及WiFi、网线、无法上网、网速慢 - 网络故障 - 涉及登录、密码、账号锁定 - 账号问题 - 涉及扣款、退款、发票 - 支付问题 - 以上都不匹配 - 其他 先输出类别再输出一句话判断理由。 示例 工单员工反馈办公室WiFi连不上其他人正常。 输出网络故障\n理由该工单描述涉及无线网络连接问题。 工单登录系统提示密码错误但用户确认密码没改过。 输出账号问题\n理由该工单描述涉及登录认证失败。这个改动让分类准确率明显提升。关键不是示例本身而是你给了模型判断的规则依据让它知道该关注哪些特征。实操心得提示词优化不要靠拍脑袋。每改一版都在同一个固定测试集上跑一遍记录指标变化。不然你会发现改来改去你根本说不清是哪一版最可靠。2.2 Token意识一切优化的起点Token是模型处理文本的基本单位。中文里一个token大约相当于一个字或一个词实践中1个汉字约等于1到1.5个token。这个概念之所以重要是因为它同时决定了成本、延迟和上下文容量。以国内常用的大模型接口为例按输出token计费的模式下一段500字的回答大概消耗500到800个token换算成成本大约在几厘钱到几分钱之间看起来不多。但一旦应用有日均十万次调用这个数字就变成每天数百元。如果不做任何成本优化一个看似免费的Demo在上线后可能烧掉你整个预算。我建议每个做LLM应用的人都建立一份Token预算清单预估单次请求平均输入token与输出token根据业务量估算日消耗量与月成本设定单个请求的成本上限超过则触发告警定期检查哪些场景的prompt过长、哪些输出可以用更小的模型完成Token意识还直接关系到上下文窗口的使用。现在的模型窗口动辄几十万token很多人开始迷信把资料全塞进去的做法。但在实际项目里大窗口不等于高质量。输入越长模型对关键信息的注意力会被稀释推理速度下降成本线性上升。更稳妥的做法是精确检索出与当前问题最相关的片段只把这些片段放入上下文。2.3 从API到SDK稳定调用的工程化基础入门阶段用官方接口直接拼HTTP请求完全没问题但做到工程化你必须理解SDK封装了大量你在生产环境需要的细节。比如自动重试、流式响应、超时控制、错误处理、并发限制等。我踩过一个典型的坑没有做超时控制。某次上游模型服务偶发变慢单次请求耗时从正常的2秒飙到30秒用户端的请求全部挂起连接池被打满整个服务的其他接口也一起瘫痪。后来我强制给所有模型调用加上了超时设置和熔断机制——超过设定时间就返回兜底文案并记录日志告警。稳定调用的几个工程要点所有模型调用必须设置超时并区分连接超时和读取超时。SDK自带重试机制但默认重试次数可能不合理要根据业务容忍度调整。流式输出的首token延迟比整体延迟更能体现用户感知要单独监控。在代码层面把模型调用封装成独立模块方便将来切换模型或升级版本。模块化封装的思路很重要。你封装一个chat_completion函数内部处理模型选择、prompt模板、重试、日志业务代码只知道我传一段输入拿回一段输出。将来模型从A版升级到B版你只需要改一个地方而不是满项目找人。3. 实战主战场RAG与Agent3.1 RAG让模型学会查资料再回答RAG检索增强生成是目前企业级LLM应用里使用最广泛的技术范式。它的核心思想很直白模型参数里没有你企业的私有知识那就先从一个知识库中检索出相关内容再把这些内容拼接进prompt让模型基于检索结果生成回答。一个完整的RAG流程包括五个环节文档加载与解析处理PDF、Word、Markdown、HTML等格式提取正文内容。文本切片把长文档切成多个块方便后续检索。向量化用Embedding模型把每个文本块转换为高维向量。检索召回把用户问题也向量化通过相似度计算召回Top-K个文本块。重排与生成对召回结果做精排拼装prompt调用生成模型得到最终回答。每个环节都有大量细节。只说文本切片这一环很多人上来就按固定字数切500字一刀切结果往往切在段落中间破坏语义。我常用的策略是按结构切分优先按Markdown标题、段落、句子边界切设置一个目标块大小比如300到500字和一个重叠区域比如50到100字。重叠区域能保证被切到上一块末尾的关键信息在下一块开头仍然出现避免检索时信息断裂。检索召回的准确度是RAG效果的天花板。如果召回的文本块压根不包含答案模型再强也编不出来。我强烈建议做完整的链路调优而不是只盯着生成环节。先用一批测试问题验证Top-3检索结果里是否包含正确答案这个指标不合格就不用急着优化prompt。再讲一个重排细节。向量检索的语义相似度排序未必最符合业务需求纯向量召回的结果经常出现意思相关但信息冗余的情况。一个实用的做法是先用向量检索召回50个候选块再用一个精排模型cross-encoder或者规则如关键词匹配、元数据过滤重排取前5块送入模型。这个粗召回精排的两段式设计是RAG效果提升最显著的单点优化之一。实操心得RAG调试时先把中间结果可视化。把用户问题、检索到的文本块、最终生成的答案放到同一个调试界面对照看。很多时候问题一目了然——要么检索跑偏要么prompt里上下文顺序不对把模型带偏了。3.2 Agent从会说话到会干活如果说RAG解决的是知识获取问题Agent解决的是行动能力问题。Agent让大模型能够调用外部工具完成实际操作比如查询数据库、调用API、执行代码、发送消息。理解Agent的常见范式有助于你设计自己的系统ReAct范式模型在思考、行动、观察之间循环先想一下要做什么然后调用工具再根据返回结果决定下一步。Plan-and-Execute模型先制定一个完整的计划再逐步执行适合任务步骤明确的场景。代码生成式Agent模型先生成一段代码来完成任务适合数据处理、文件操作类场景。用Agent当真实现一个功能时有一个经常被忽视的问题工具调用结果的格式冲击。模型拿到工具返回的原始结果后可能会有两种问题结果太长超过上下文长度结果太乱模型无法提取关键信息。我的建议是在工具返回层做一次摘要处理——工具返回的结果先经过一个专门的压缩步骤只保留与当前任务相关的字段和数据再送回给模型。我做过一个数据分析助手模型先生成Python代码执行数据分析。刚开始直接把全量DataFrame结果塞回给模型不仅费token模型还经常被中间过程的无关信息干扰。后来改成代码执行后只用print输出前几十行以及描述性的统计指标模型反而能给出更准确的结论。给模型看经理摘要而不是仓库账本。Agent的安全边界也要尽早定义。给Agent挂一个搜索引擎工具没问题给Agent挂一个可以删除文件的工具就要慎重了。我在系统里永远会对高危操作加二次确认机制——模型生成的指令先进入一个审批模式由人工或规则引擎确认后才真正执行。宁可在流程上麻烦一点也不能让一个失控的Agent把数据搞乱。评估Agent比评估单轮问答更难。因为Agent链路更长、工具结果多样、中间步骤无数任何一个环节出错都会导致最终失败。我的做法是记录每一次Agent的完整轨迹——思考过程、工具参数、返回结果、下一步动作然后人工抽查轨迹质量而不是只看最终回答对不对。3.3 评估体系没有评估就没有上线做LLM应用评估不是有空再做的事情而是决定了你迭代效率的核心基础设施。没有评估体系你就会陷入凭感觉调一版、上线看效果、然后回退的低效循环。我建议的评估体系分为三个层次第一层单例测试针对特定功能模块准备几十个典型用例每次改动后手动或自动跑一遍确认没有明显的回归。这一层执行成本最低适合开发过程中的快速自检。第二层批量评测构建一个固定测试集至少覆盖100到500条真实问题每条问题附上参考答案。每次改动prompt或策略后在测试集上批量跑统计准确率、召回率、格式合规率等指标。这一层的意义是让每一次优化都有数据支撑。第三层线上监测上线后用真实流量持续收集模型表现。最有效的方式是给用户交互界面加点赞/点踩按钮同时采集用户对回答的编辑行为——如果用户把生成的字改掉了说明这段回答不准确。这些负反馈样本要定期回流到测试集中防止模型优化方向偏移。具体评测指标因场景而异。问答类场景关注回答准确率、引用命中率抽取类场景关注字段级的准确率与召回率对话类场景还要额外关注连贯性、安全性。测试集怎么建很多团队直接把线上日志抽一批。但线上日志里用户的提问往往非常多样直接拿来做测试集会包含大量模糊或坏输入。我的做法是人工清洗一轮把问题分成不同类型确保每个类型有足够的覆盖。虽然这一步很耗时间但它的价值会在后续每一次评测中体现出来。4. 工程化从Demo到生产环境的鸿沟4.1 成本与延迟算清楚每一笔账实验室阶段没人关心成本和延迟但生产环境上是两回事。我给你算一笔实际账假设你的应用平均单次请求消耗8000输入token和1000输出token主流大模型接口的大致定价按输入每百万token 50元、输出每百万token 150元估算单次请求成本约0.55元。如果一天有1万次调用月成本就是16.5万元。这个数字一出来你就明白为什么生产环境必须做优化。常见的手段包括结果缓存对重复的请求做语义缓存。同义词、近似表述的问题可以复用之前的回答。即使只能处理10%的重复请求也能省下可观的成本。模型分级简单任务用便宜的小模型复杂任务才调用大模型。比如工单分类用几B的小模型就能做得很好完全不需要每次都调用旗舰模型。上下文瘦身严格控制每次请求的上下文长度删掉与当前任务无关的历史信息。对话历史可以用摘要压缩而不是无限累加。批量处理对不需要实时响应的任务如离线文档分析、批量信息抽取改变延时段调用利用非高峰时段的优惠定价。关于延迟我特别想说一个误区很多人只看首token时间和总响应时间却忽略了端到端完成时间。如果RAG链路里检索耗时300毫秒、模型生成耗时2秒用户实际等待的是2.3秒而不是模型耗时的2秒。链路级别的延迟优化有时候比单独优化模型调用更有效。比如把向量检索数据库做冷热分离热点数据走内存索引可以显著降低检索延迟。4.2 可观测性给应用装上仪表盘LLM应用比传统应用的观测难度大得多。传统服务只看请求量、错误码、耗时就能定位大部分问题LLM应用你还得看prompt是什么、模型回答了什么、用户是否打差评。我建议的观测维度调用维度每次模型调用的模型名、输入token、输出token、耗时、是否重试、最终状态。内容维度为了排查模型回答得不好的问题需要把prompt和response都记录下来。内容数据敏感要做脱敏处理比如隐藏电话号码、身份证信息。业务维度用户是否点了赞/踩、是否复制了回答、是否发起了后续追问。成本维度按接口、按用户、按功能模块统计成本方便定位成本异常。观测系统不必一开始就上很复杂的链路追踪工具。我在中等规模项目里先用数据库表存调用日志配合一个简单的看板页面就能满足绝大多数排查需求。等规模上去了再引入基于OpenTelemetry的标准链路追踪方案。有一个习惯我非常推荐给每次模型调用生成一个全局唯一的请求ID。这个ID贯穿应用前端、后端、模型调用、数据库检索全链路。用户反馈昨天的回答不对时你拿到一个ID就能把整条链路的日志捞出来快速定位是检索问题、prompt问题还是模型本身的问题。没有这个ID全靠时间戳去查日志可能排查到崩溃。4.3 模型选型与灰度升级策略很多刚入门的开发者有一个隐含假设所有场景都应该用最新的强模型。实际项目里模型选型更像个成本和服务质量之间的权衡问题。我给出一个实用的选型决策框架任务复杂度简单分类、抽取任务用轻量模型复杂推理、长文本分析用旗舰模型。实时性要求客服在线对话要求低延迟必须选推理速度快的模型离线数据分析任务对延迟不敏感可以用更强但更慢的模型。隐私要求企业数据不能出私有化环境的只能选择本地部署模型这时模型体积和算力成本是核心约束。预算限制把单次请求成本设一个死线超过死线的方案直接淘汰。即使选定了主用模型也要建立灰度升级机制。大模型版本更新不是今天升级明天观察这么简单。我常用的策略是新版本先接5%到10%的流量同时进行AB对比——同一批输入分别用旧版和新版生成用评估指标自动化对比质量。确认新版在成本、延迟、质量上都占优之后再逐步上调流量比例。一个我踩过的坑某次模型提供方小幅升级了版本官方文档说兼容性不变结果线上自动分类任务的准确率掉了好几个百分点。从那以后我把升级判断改成以评估指标为准而不是以官方说明为准。5. 进阶方向微调、多模态与团队协作5.1 微调不是万能药什么时候才该动很多人被微调这个词吸引觉得既然是应用工程师是不是得掌握模型训练才算高阶。我的看法非常明确微调是最后手段不是默认手段。你能用RAG解决的问题不要微调。RAG可以随时更新知识、支持引用溯源、不改变模型的基础行为。而微调是改变模型的权重一旦训练完成行为就固化了更新成本高、可控性弱、失败风险大。真正适合微调的典型场景是模型稳定输出的格式始终不达标怎么调prompt都没用。比如要求始终输出标准JSON但模型经常夹带解释文字。业务场景有独特的语言风格需要模型模仿这种风格。比如法院文书的行文逻辑、医疗报告的术语规范。需要压低推理成本用小模型达到接近大模型的效果。通过在小模型上微调特定任务数据集让它在一个垂直场景里超越通用大模型。微调方式上入门首选LoRA。它只训练一小部分低秩矩阵训练成本低、显存占用小、切换方便。在某个本地化部署的项目里我用LoRA在7B量级的开源模型上做格式微调用几千条数据训练模型输出JSON格式的成功率从不到80%提升到98%以上。但微调需要一套严格的数据处理和评测流程。训练集必须做去重、去污、标签一致性校验。训练后不能只看训练集的表现要在独立的测试集上评测防止过拟合到训练数据的表达方式上。实操心得微调之前先做两件事。第一把无论怎么调prompt都解决不了的具体失败case收集至少几十个第二和团队定义清楚微调成功的量化标准。这两件事没做完就开训结果通常是不满意的。5.2 多模态与工具链扩展LLM应用工程师的边界在不断拓宽。多模态模型让应用可以同时理解文本、图像、音频这意味着很多之前需要独立CV模型处理的场景现在可以直接用多模态大模型来理解。比如合同审核场景里用户上传一个扫描件图片需求方希望直接抽取里面的关键信息。传统做法是OCR识别后再做NLP抽取链路长、错误逐级累积。多模态模型可以一步完成看图理解抽取。不过这里要提醒一个点多模态模型对复杂版式、低清晰度图片的鲁棒性并没有想象中好。我测试过一些模糊扫描件模型的抽取准确率明显下降。生产环境里适当做图片预处理比如去噪、增强对比度仍然是必要的。另一个扩展方向是定制化工具链。你会发现真正能落地的Agent不是靠一个大模型万能理解完成的而是围绕你的业务场景搭了一圈专用小工具比如内部API查询、领域数据库检索、专业计算器、自定义校验规则。模型的角色是理解任务、调度工具、组织回答而不是什么都自己来。5.3 从个人开发者到工程团队当你从独立开发走向团队协作模式挑战会发生很大变化。个人开发可以自己定义接口、边写边改但团队协作要求你把LLM应用的可变性封装起来让系统的其他部分不感知模型的变更。这个阶段有三个我强烈推荐的做法首先是Prompt和模型配置全部版本化管理。prompt也是代码它需要像代码一样走review、版本标签和环境分离。用一份独立的配置文件管理所有prompt模板而不是散落在代码库里是基本要求。其次是建立评测集即代码的规范。每次新增或修改功能时必须同步准备评测用例。代码评审时不仅要看代码逻辑还要看评测集是否覆盖了关键场景。这套规范能有效防止团队里凭感觉开发的问题。最后是定义清晰的接口契约。业务方调用你的LLM能力时通过稳定接口进出。你内部用哪个模型、怎样的温度、什么检索策略是内部实现细节。这能让下游系统稳定也让你将来调整模型时不影响其他人。6. 学习路线图30天到90天的走法6.1 以项目为纲而不是以课程为纲想系统进入LLM应用开发领域最常见的错误是先学完所有理论再动手。这个领域变化太快等你把一本教材读透技术栈可能已经更新换代。更有效的策略是以项目为纲边做边学。我建议的第一个项目做个人知识库问答助手。自己整理一批文档比如技术笔记、产品手册搭一个完整的RAG系统。这个项目能覆盖文档解析、文本切片、向量检索、Prompt组装、流式输出、引用溯源。做完之后你对RAG整个链路会有真实体感。第二个项目做带工具调用的Agent。给它挂2到3个工具比如天气查询、计算器、数据库查询让它自主规划并使用工具完成任务。做完这个项目你会理解Agent的核心难点不在于调用工具本身而在于规划、状态管理和错误恢复。第三个项目做垂直场景的完整应用。选一个你熟悉的行业场景比如电商客服、招聘筛选、合同审查把它做成一个能交付的演示系统配合评估、日志、成本统计。做完这个项目你对生产环境的理解会完全不一样。6.2 资源选择与避坑心法市面上的学习资源非常多但质量参差不齐。我的筛选标准是优先看官方文档和官方教程其次看能直接跑通的开源示例代码最后才看二手解析和课程。有三个坑我想特别提醒第一是过度关注模型排行榜。排行榜上的分数和实际业务场景的相关性很有限与其纠结哪个模型排名高不如拿自己的100条测试问题逐一跑一遍看实际效果。第二是迷信单一工具框架。LLM的开发框架已经很丰富但框架抽象和封装程度各不相同。框架能帮你快速搭原型但出问题时你还是要理解底层原理。我在深入用过几个框架后很多关键场景反而选择直接用原生SDK自己拼装。理解原理的深度决定了你排查问题的速度。第三是忽视基础工程能力。LLM应用工程师的底色仍然是软件工程师。网络、并发、数据库、缓存、日志、部署这些传统后端基本功一样也不能少。不要被大模型的光环迷惑忽略了你连一个稳定的CRUD服务都写不利索的事实。6.3 30天、60天、90天节点目标为了让大家有更具体的节奏感我把学习路线拆成三个阶段第1到30天跑通全链路。完成个人知识库问答助手理解提示工程、RAG、流式输出、基础评估。每天写代码不要只看文档。第31到60天深入工程化。做Agent项目同时开始搭建自己的评测集和评测流程。学会看成本、优化延迟、设计缓存。这个阶段你应该能独立完成一个中等复杂度的LLM应用Demo。第61到90天提升专业度。选择一个垂直方向深耕它的评估指标、数据构建、模型调优做到心中有数。尝试把应用部署上线收集真实反馈并迭代。这个阶段做完你应该具备独立负责一个LLM应用模块的能力。前面说的这些方向最关键的还是动手。我自己做第一个RAG项目时光文档部署就栽了好几次跟头第一次上线抽风、第二次切分有误导致检索全偏、第三次才真正跑通。但正是这些连续的出问题再排查过程让我在最开始就把整个链路的常见坑摸了一遍。等你把这些问题都经历过再回头看你收藏的所有课程大纲和攻略清单会发现你已经不需要收藏了你心里已经有了一张自己的地图。