从后端、前端或者数据分析转过来做大模型应用，最容易踩的坑不是不会写代码，而是不知道先学哪样。有人一上来啃微调，有人把提示词当全部，结果面试和上手项目都卡在中间层。这篇按「必须会—用得上—可以晚点学」三档拆开，配一条能自己走完的入门顺序，并说明哪些判断在团队规模、业务类型不同的情况下不适用。
从后端、前端或者数据分析转过来做大模型应用，最容易踩的坑不是不会写代码，而是不知道先学哪样。有人一上来啃微调，觉得那才是核心技术；有人把提示词当成全部，以为会聊天就会做应用。结果面试答不上编排逻辑，上手项目卡在检索和评估这两层中间，两头不靠。
这篇按「必须会—用得上—可以晚点学」三档把技能拆开，配一条能自己走完的入门顺序。先说明白一个前提：下面所有判断都建立在你做的是应用岗，也就是把模型当外部能力来组装产品。如果岗位性质不同，顺序要整体调整，这一点第一节会单独讲。
先把「应用开发」和「模型训练」分清楚
大模型应用开发的日常产出，是接口调用、编排逻辑、检索链路和评估脚本，不是训练权重。先把这条边界画清楚，才不会被「要不要学反向传播」「要不要看注意力公式」这类问题拖住，把时间花在刀刃上。
真正需要理解原理的部分只有三块：Token 怎么切、上下文窗口怎么算、采样参数怎么影响输出稳定性。其余的底层细节遇到再补，不用提前建知识体系。到 /ai-dict/category/basics 把这几个概念对一遍，就够支撑后面所有环节了。
第一层：绕不过去的基本功
一门主力语言写熟，Python 最常见，Node 也行。重点不是语法，而是异步请求、超时重试、并发控制和异常兜底这几件事。判断标准很直接：不看教程，能写出一个带重试和超时的调用封装，并且说清每次重试时上下文发生了什么变化，这一层就算过了。
HTTP 和 JSON 打交道的能力是每天都要用的。看懂接口文档里的字段含义、自己拼请求、处理流式返回、解析错误码，这些没有捷径。到 /tools/token-price-calculator 亲手换算一次，对 Token 的体感会比背定义快得多。
| 技能点 | 练到什么程度算够 | 怎么自测 |
|---|---|---|
| 语言与异步 | 能写带重试和超时的请求封装 | 关掉教程从零写一遍 |
| HTTP 与 JSON | 看懂文档、拼请求、处理流式返回 | 手写一个流式输出的小脚本 |
| Token 与上下文 | 能估算一段文本大概占多少窗口 | 用站内计算器验证自己的估算 |
| 异常处理 | 说清失败时上下文变化和兜底策略 | 故意让接口报错,看程序是否按预期降级 |
第二层：提示词与结构化输出
提示词不是玄学，控制点就那几个：角色设定、任务描述、输出格式约束、示例、边界情况说明。先按这五项拆开写，再谈调优。调参也只碰少数几个旋钮，重点是理解温度对输出稳定性的影响，具体参数含义到 /ai-dict/category/tips 扫一遍就行，不用深挖。
结构化输出是应用开发的分水岭。让模型稳定吐 JSON、字段缺失怎么兜、格式错了怎么重试，这套处理写不写得出来，直接决定你能不能接业务系统。只会让模型自由生成文本，做出来的东西永远停在玩具阶段。
- 格式约束要写进提示词，不要靠事后正则硬抠
- 字段缺失要有默认值或追问逻辑，不能直接崩
- 解析失败先重试一次，仍然失败就走人工兜底
- 把每次解析失败的原因记进日志，攒够样本再改提示词
- 不同模型对格式的服从度不一样，换模型后要重新测一遍
第三层：检索增强这条链路
RAG 的每个环节都要亲手跑一遍才算会：文档切分、向量化、入库、召回、重排、拼进上下文。只调现成的库不拆环节，出了效果问题就无从下手，只能凭感觉换模型。
嵌入模型和向量库的选型不要凭印象。到 /embeddings 看当前收录的模型，再到 /stacks/vector-dbs 对照各库的适用场景，选一个先跑通，别在选型上纠结太久。
- 第一步：确认检索质量拿几个真实问题跑一遍召回，先看检索回来的片段本身是否相关，不相关就别急着动模型
- 第二步：看上下文拼装相关片段被拼进上下文的顺序和长度会影响结果，检查有没有关键片段被截断
- 第三步：最后才怀疑模型前两步都排除了,再考虑换模型或调提示词。顺序反了会浪费大量时间在换模型上
第四层：评估与可观测性
没有评估就没有迭代。先攒一批真实问题当测试集，跑一次记一次结果，哪怕只是人工打分也行，比凭感觉改提示词强得多。测试集不用大，能覆盖主要场景就够。
日志要记三样东西：送入模型的完整输入、模型的原始输出、这一轮的耗时。少任何一样，线上出问题都查不动。换模型或改提示词之前先留基线，改完对照着看是好了还是坏了，具体口径可以参考 /tools/quality-monitor。
- 基线
- 改动前的效果记录，没有它就无法判断改动是变好还是变坏
- 测试集
- 一批有代表性的真实问题，用于每次改动后快速回归
- 可观测性
- 输入、输出、耗时三件套的日志，排查线上问题的起点
第五层：工程化与成本意识
把「调用模型」当成一次不可靠的外部依赖来处理：超时、降级、缓存、幂等，这套思路和调第三方支付接口没什么区别。并发和限流要提前想清楚，多用户同时进来时，你是排队、降级到小模型，还是直接拒绝，这个策略要写进设计里。
成本要能算出来：单次请求的输入输出量、日调用量、缓存命中率，三者相乘就是账单量级。到 /tools/model-cost-calculator 自己算一遍，比听人讲有用得多；想追踪价格变动就去看 /price-watch。
- 接口层做一层薄封装，把模型名、参数、提示词模板抽出来
- 换模型是常态，封装做好了就是改几行配置的事
- 缓存命中率决定了实际成本，高频问题应该先走缓存
- 降级策略要提前定义好，不要等线上崩了再临时想
学习顺序与三个常见误区
推荐顺序是：语言与接口基本功 → 提示词与结构化输出 → 检索链路 → 评估与日志 → 工程化与成本。每一层都用一个小项目收尾，别学完再想做什么，边做边补比纯看资料快得多。
误区一：先学微调。多数应用问题靠提示词和检索就能解决，微调是最后手段。想判断某个场景到底该不该微调，可以先看 /stacks/fine-tuning 里的服务商定位，再决定要不要投入。
误区二：只挑一个模型用到底。模型迭代很快，接口层封装好之后，换模型就是几行配置的事。误区三：不做评估直接上线。哪怕只维护一份人工评分表，也比完全靠体感强，先有反馈环路，再谈优化。
| 误区 | 典型表现 | 怎么纠正 |
|---|---|---|
| 先学微调 | 上来就研究训练脚本 | 先用提示词和检索解决，解决不了再考虑 |
| 单模型绑定 | 代码里到处写死模型名 | 抽一层接口封装，模型名走配置 |
| 不做评估 | 改完提示词凭感觉说变好了 | 留一份测试集和基线，改动前后对照 |
| 追求大项目 | 项目做得很大但每层都松 | 先把小项目每层跑通，再扩规模 |
用一个周末项目验证你到底会不会
项目要小但完整：读取一批本地文档 → 建成检索 → 回答问题 → 记录每次问答的输入输出和耗时 → 跑一份二十条左右的测试问题。做完回头对照上面的分层，哪一层你卡住了，就说明那一层需要补，这比做技能清单打勾靠谱。
- 准备素材挑一批你熟悉的本地文档，正好用来判断检索结果对不对
- 搭检索链路切分、向量化、入库、召回跑通，先不追求效果好，先追求能跑
- 接上问答把召回结果拼进上下文，让模型基于材料回答，记录完整输入输出
- 跑测试集准备二十条左右的问题跑一遍，看多少能答对，错的分清是检索问题还是生成问题
- 换模型复跑换一个模型半小时内让项目重新跑起来，并说得出效果差异在哪
常见问题
完全没接触过大模型，能不能直接学应用开发，跳过原理？
可以，但有个底线：Token 怎么算、上下文窗口是什么、温度影响什么，这三个概念必须懂，否则调参和算成本时全是盲猜。其余原理边做边补，不要一开始就去啃论文，容易劝退。
数学和算法基础差，会不会做不了？
做应用开发基本不影响。你的工作重心是接口编排、检索链路和工程稳定性，不涉及梯度推导。只有当你打算转做微调或模型优化时，数学基础才会变成真门槛，那时再补也来得及。
需要先学 LangChain 这类框架吗？
建议先用原生接口把一个最小链路手写一遍，理解每一步在干什么，再去用框架。反过来先上框架，遇到报错你分不清是框架的问题还是自己理解错了，排查成本会高很多。
学完这些大概要多久？
看每天投入的时间，差异很大，这里不给数字。更可靠的做法是按分层自测：每一层都能独立做出一个小东西，就算过；卡在哪一层，就在那一层多待一阵，不用跟别人的进度比。
转行简历上写什么项目比较有说服力？
能讲清取舍的项目比功能多的项目更有说服力。比如你为什么选这个切分方式、为什么加了一层重排、成本大概什么量级、遇到的最难的 bug 是什么。做一个小而完整的，比堆三个半成品强。
