很多人卡在同一个地方：资料看了一堆，真动手时不知道从哪起——先学提示词还是先学框架，要不要碰微调，评测怎么做。这篇不讲概念科普，只给一条能走通的上手顺序，以及每一步的判断标准和该做的动作，顺带说清哪些环节对你的场景其实可以先跳过。
很多人学大模型应用开发都卡在同一个地方：收藏夹里躺了一堆资料，真要写第一行代码时反而不知道从哪起——是先啃提示词，还是先挑个框架，要不要碰微调，评测到底什么时候做。这篇不讲概念科普，只给你一条能走通的上手顺序，每一步配上判断标准和该做的动作，顺便说清哪些环节对你的场景其实可以先跳过。
要提前说明一点：下面给的是一条通用路径，不是唯一答案。如果你的团队已经有成熟的工程底子、或者场景本身极其特殊，很多步骤可以压缩甚至调换顺序。所以每节我都会补一句「什么情况下不适用」，你对照自己的情况取舍，别硬套。
先分清四层技术栈，别一上来就全学
大模型应用开发摊开来看是四层：模型接入层、编排层、数据层、交付层。初学者只碰前两层就能跑通第一个能用的应用，后两层按需求慢慢加。很多人一上手就被「向量数据库」「RAG 架构」「Agent 编排」这些词吓住，其实是把四层揉成一团在学，效率极低。
- 模型接入层
- 负责把请求发给模型并拿回结果，官方 API 或本地部署都算这一层
- 编排层
- 提示模板、流程控制、多步调用怎么串起来，是业务逻辑主要待的地方
- 数据层
- 文档切分、向量化、检索、重排，解决模型不知道你私有知识的问题
- 交付层
- 对外接口、日志、评测回归、失败兜底，决定这东西能不能上线
判断标准很简单：如果需求是「就着已有文档做问答」，数据层必做；如果只是把模型输出塞进现有流程里做一步加工，数据层可以先缓缓。交付层则永远别跳过日志，哪怕只是个内部小工具，出问题时你会庆幸自己记了输入输出。
选一条上手路径：API 起步还是本地起步
第一条路径：先用官方 API 跑通端到端。理由是把显存、部署、并发这一整摊全甩给服务方，你的注意力能集中在提示设计和流程编排上，这两件事才是真正决定应用好不好用的部分。绝大多数入门者都该从这里开始。
什么时候反过来选本地：一是数据不能出内网，这是硬约束；二是调用量稳定且大到租卡更划算；三是需要锁定某个固定权重版本，不想被服务方升级影响。这两条分界线具体怎么权衡，去 /guides/self-host 和 /guides/rent-gpu-vs-api 对照当时的数字，别凭感觉拍脑袋。
- 把模型端点、密钥、模型名全写进环境变量，别硬编码在业务代码里
- 用一层薄封装统一调用接口，换官方 API、换平台、换本地服务时只改这一层
- 两种起步方式的代码结构差别很小，切换成本主要在接口适配和稳定性，不在业务逻辑
- 先用官方 API 验证价值，确认真有需求再考虑迁移，别在验证阶段就折腾部署
不适用的情况：如果你所在的环境连外部网络都不通，那本地起步不是选项而是前提，这时候直接把精力放在模型选型和显存规划上，不用纠结先后顺序。
核心能力清单：能落地的就这几项
网上列大模型技能树的文章很多，但真正能在小团队里落地的就那么几项。下面这张表是我认为优先级最高的四件事，按投入产出比从高到低排。
| 能力 | 解决什么问题 | 先做到什么程度 |
|---|---|---|
| 提示与结构化输出 | 输出没法被程序处理 | 约束成 JSON，失败有重试和兜底 |
| 检索增强 | 模型不知道你的私有知识 | 切分合理、召回够用、必要时加重排 |
| 评测回归 | 分不清改动是变好了还是运气好 | 固定一批真实问题，每次改动静跑一遍 |
| 可观测 | 线上出问题只能靠猜 | 记录输入输出、耗时、失败原因 |
关于检索增强还有个经验：切分策略、召回条数、要不要加重排，这几项调整的收益，通常大于换成参数更大的模型。很多人一上来就想换更贵的模型，其实瓶颈在检索没做好。评测和可观测这两件事，是区分「玩票」和「真做产品」的分水岭。
不适用的情况：如果你的应用输出给人看、不参与后续程序流转，那结构化输出可以放宽；如果你只是给自己做实验、没有他人使用，评测回归可以后置，但一旦有第二个用户，就该补上。
领域实践：先做窄场景，别做通用助手
新手最容易踩的坑，是上来就想做「什么都能问」的通用助手。通用意味着边界模糊，意味着你没法判断它到底做得好不好。正确做法是挑一个输入输出边界清晰的场景，比如把某类文档转成结构化字段，或者针对某一类问题做问答，这样你才收敛得下来。
领域知识优先放进检索库，别急着微调。判断标准：知识会变、需要引用出处，就走检索；风格和格式要固定、有足够数据量、且变化不频繁，才考虑微调。这条线的细节可以看 /guides/prompt-rag-finetune-choice，那里把三者的适用边界拆得比较清楚。
- 答案带上来源引用和置信提示，比假装什么都知道更省事
- 把不可靠的部分暴露给用户，而不是藏起来
- 先覆盖一类高频问题，跑顺了再扩，别一开始就铺全量
- 每周收集真实用户问法，回头补进评测集
两周可执行的推进顺序
下面这条节奏给的是两周，实际快慢看你的投入时间。关键在于每一步都能停下来交付，不需要等全部做完才算数，这样你能随时根据效果调整方向。
- 第 1-2 天定一个具体场景，写清输入是什么、输出给谁用、错了会怎样。写不出来说明场景还没想清楚。
- 第 3-5 天用官方 API 跑通单轮调用，把提示固定成模板，输出改成结构化。验证：程序能稳定解析输出。
- 第 6-9 天加检索，准备几十条真实问题做回归集，测召回和答案质量。验证：改一次切分策略，回归集分数有可解释的变化。
- 第 10-14 天加日志和失败兜底，用 /tools/speed-test 量一次延迟基线，确认用户能接受再谈优化。
不适用的情况：如果你的场景是内部工具、用户就是你自己，第 10-14 天的日志和延迟基线可以砍掉一半；但如果要给别人用，兜底和延迟感知这两件事不能省，它们决定了用户第一次试用会不会直接放弃。
下一步上手前先花十分钟把模型接入的成本和延迟基线摸清楚，后面选官方 API 还是本地就有依据了，数字以站内当时为准。→常见问题
完全没写过代码，能直接学大模型应用开发吗？
能做的最多是拼装现成工具，写应用还是要基础编程能力。建议先用现成平台体验完整流程，理解输入输出长什么样，再补最基本的接口调用和数据处理。顺序反了容易卡在语法上，看不到全局。
要不要先把模型原理学透再动手？
不用。先跑通一个能用的最小应用，再回头补原理效率更高，因为你带着具体问题去看。原理部分的术语卡住时去 /ai-dict/category/basics 和 /ai-dict/category/tech 对照即可，不必通读。
框架这么多，必须选一个吗？
不必。先用最朴素的 HTTP 调用把流程走通，你会发现大部分需求就是拼几段文本加几次请求。等你需要多轮编排、工具调用、状态管理时再引入框架，这时你才知道它替你解决了什么。选型可先看 /stacks/frameworks 的目录。
