大模型应用开发需要学什么

想转到大模型应用开发的人常卡在同一处：教程看了一堆，却说不清自己现在该学哪一层，也不知道学完能干什么。市面上路线图要么把训练模型那一套全塞进来，要么只教调接口。这篇按「能做出东西」的目标倒推，给一条分阶段、有验收动作的学习路径，并说清哪些阶段可以跳过、什么情况下这条路线不适用。

想转到大模型应用开发的人，卡点几乎一模一样：教程收藏了一堆，却说不清自己现在该学哪一层，也不知道学完能干什么。市面上的路线图要么把训练模型那一整套塞给你，要么只教怎么调接口，中间那段真正决定你能不能做出东西的部分反而没人讲。

这篇按「能独立做出东西」的目标倒推，把学习路径拆成几个阶段，每段给出动手目标、验收动作和可以跳过的部分。重点不是让你背名词，而是让你随时能回答一个问题：我现在这一步做完了，能给别人演示什么。

先分清你要做的是哪一种「大模型开发」

「大模型开发」这四个字下面其实压着三条差异很大的路：调用现成接口做产品、本地跑开源模型做私有化、自己训练或微调模型。三条路的技能栈重合度不高，先确认目标再谈学什么，否则你会在某个用不上的方向上耗掉几个月。

• 判断方法：翻几条招聘描述，出现「接口」「提示词」「RAG」多的偏应用，出现「显存」「量化」「分布式」多的偏工程与算法
• 别贪心：同时学两条路基本等于两条都学不完，先选一条走通再横向补
• 不适用情况：如果你已经在做算法岗，这篇的起点对你偏低，直接看微调与推理部分就行
• 名词先对上号：到 /stacks 看技术栈图谱，把散落的名词和岗位要求挂上钩，再决定学哪条

起步前的最低前置：不要求会训练，但要有这几样

很多人以为学大模型要先补数学，其实对应用方向来说这是最大的误区。真正会卡住你的是环境配置、报错定位、文档阅读这些看起来不高级的事。前置门槛不高，但每一条都得真会，不能糊弄过去。

一门脚本语言

能写函数、处理 JSON、发异步请求就够了，不必精通语言特性

读报错的能力

看到报错知道先看哪一行、去哪儿查文档，比多背一个框架重要

命令行熟练度

能在本地把服务跑起来、看日志、改配置，这是所有后续实验的地基

基础概念直觉

Token、上下文、温度这类词要能用自己的话解释，不懂的先到 /ai-dict/category/basics 扫一遍

第一阶段：把模型调用这件事做扎实

第一阶段的唯一目标是把「调通」变成「调稳」。调通是跟着教程复制一段代码能返回结果，调稳是输入超长、网络抖动、返回格式不对的时候，你的脚本依然能给出可预期的行为。这两者之间的差距，就是入门和能用的差距。

1. 写一个连续对话脚本能记住上一轮内容、能手动裁剪过长的历史，跑通后故意丢一段超长输入进去，看它怎么崩、你怎么处理
2. 加上失败处理对超时、限流、返回空内容分别做重试或降级，验证方式是手动制造一次失败看它是否符合预期
3. 测一次延迟基线到 /tools/speed-test 量一量你自己的调用延迟，把这个数记下来，后面所有优化都拿它做参照
4. 对一遍各家口径到 /official-api 以及 /official-api/providers/deepseek 这类官方页面对照调用方式和限制，别只认准一家写死

这一阶段最值得养成的习惯是：任何一次调用都留下可复现的输入输出。没有日志，你后面遇到的每个问题都只能靠猜。做到这一点，第一阶段就算过关。

第二阶段：提示词与结构化输出

提示词的核心不是「写咒语」，而是把一段模糊需求拆成模型能稳定执行的步骤，并规定好输出格式。很多人卡在这里是因为把提示词当成文案工作，其实它更接近接口设计：你要定义输入、输出和边界情况。

• 同一个任务写三版提示词，比较哪一版在边界输入上更不容易跑偏，把失败样例单独记下来
• 输出尽量结构化，方便程序直接消费，而不是让人再去肉眼解析一大段话
• 给每次调用留日志：输入是什么、用了哪版提示词、输出是什么，出问题时这是唯一线索
• 反复不稳定的任务，先怀疑需求描述不清，再怀疑模型能力，顺序别反
• 到 /ai-dict/category/tips 对照提示与调参类术语，避免被不同叫法绕晕

验收动作很简单：把你写的提示词交给一个不了解背景的同事，让他用你的说明复现同样的输出。他做不到，说明你的提示词只是对你有效，不是对任务有效。

第三阶段：检索增强与知识库

这是应用开发里最实用的一块，也是面试最常问的一块。文档切分、向量化、召回、重排、拼进上下文，五步缺一不可，任何一步出问题都会表现为「模型答错了」，但根因完全不在模型上。

1. 拿自己的文档做问答选一份你熟悉的文档，做出来的工具答错时你能立刻判断是检索错了还是模型编了，这是最好的练习材料
2. 刻意制造失败把同一个问题用不同问法问几遍，观察召回结果的变化，理解问法和向量匹配之间的关系
3. 做一次对照实验同一份资料，一次用检索拼进去，一次直接塞长文本，比较两种方式的稳定性与适用场景
4. 查选型资料到 /embeddings 看嵌入模型、到 /stacks/vector-dbs 看向量库选型，不用自己去各处拼资料

第四阶段：把它做成能上线的服务

做到这一步，你的东西还是「在我电脑上能跑」。要变成能给别人用的服务，需要补的是工程能力：接口封装、并发与限流、超时与降级、用量统计。这些听起来无聊，但决定了你的项目是玩具还是产品。

• 接口封装：把模型调用包在你自己的接口后面，方便换供应方、加缓存、加日志
• 并发与限流：想清楚同一时刻最多发多少请求，超了是排队还是拒绝
• 超时与降级：模型不可用时给出什么兜底结果，这个策略要提前定好而不是临时想
• 用量统计：每天记一次消耗，用量失控往往比效果差更早暴露问题
• 验收标准：别人不看你的代码也能把服务跑起来，出故障时你能在日志里快速定位到是哪一层

成本这件事不用背数字，各家口径一直在变。到 /official-api 核对当时的报价，再用 /tools/speed-test 的结果一起看，性价比的判断要两个维度一起看。养成定期对账的习惯，比记住任何单一数字都有用。

不适用情况：只做个人玩具项目、不打算给别人用的人，这一阶段可以放到最后补，先去做第三阶段的成品更划算。

第五阶段：智能体、微调，以及什么时候不该碰

这两个方向在宣传里出现频率最高，但对入门者来说也最容易踩空。它们都建立在前四个阶段之上，基础不牢直接上来做，结果通常是一团乱麻而且无法调试。

智能体的重点是工具调用、任务拆解和记忆管理。这三件事里任何一件没想清楚，智能体就会在循环里打转，而且你翻日志也看不出它为什么做出那个决定。建议先把前四阶段的成品跑顺，再来加这一层。

微调则要更谨慎。它只在特定条件下划算：输出格式高度固定、风格要求很严、而且提示词怎么调都不稳定。其他情况下，先优化检索和提示词，收益更快也更容易回退。真要评估，到 /stacks/fine-tuning 看服务商目录，再决定是外包还是自建。

怎么练、练多久、怎么判断自己出师了

学习节奏上，以产出为准而不是以课程进度为准。每阶段结束做一个能演示给别人看的小东西，比刷完一整套视频有用得多。演示对象最好是不懂技术的人，他们的问题会直接暴露你没想清楚的地方。

• 作品一：一个带检索的问答工具，覆盖调用、提示词、检索三块，能说清每步为什么这么选
• 作品二：一个批量处理文本的脚本，覆盖结构化输出和失败处理，能稳定跑完一批任务
• 自检一：能不能独立排查一次调用失败，从日志到根因不用问别人
• 自检二：能不能解释清楚一次答错的原因，并说清改哪一步能改善
• 自检三：能不能估出一次请求的大致成本，并知道到哪个页面核对当时的数字
• 不适用情况：这条路线偏应用产品方向，想走模型训练或推理优化的人需要额外补数学和系统知识

判断自己入门了没有，标准不是「学过多少」，而是「给我一个需求，我知道第一步该做什么、做完怎么验证」。