大模型应用开发怎么起步，6 步从环境到上线的操作顺序

大模型应用开发的起步路径是固定的 6 步：装环境跑通 1 次接口调用、把提示词和参数固化成配置文件、接上自己的数据、加上失败重试与限流、做 1 个最小可用的界面、放到服务器上观测 3 天。整条链路 1 个人做，按每天 2 小时算大概 2 周能跑到能用。

去年带 1 个做外贸的团队做过类似的事，4 个人 3 周做出 1 个报价单问答工具。中间返工 2 次，都栽在同一处：先把界面做得挺完整，接口一报错就全站白屏，因为没写重试也没做降级。第 2 次改成先跑通接口再动界面，返工就少了。

下面按顺序写每一步在哪操作、要装什么、跑什么命令、怎么判断这步过了。文中的版本号对应 2026 年 11 月的公开版本，SDK 小版本迭代不影响流程。

一、动手前先备齐 5 样

1. Python 3.10 或 3.11。3.12 也能跑，但部分向量库还没跟上，装依赖时容易编译失败。
2. 1 个虚拟环境，用 venv 就够。项目依赖装进全局环境，换项目时会互相覆盖。
3. 1 个模型服务的 key，国内几家的开放平台都能申请，注册后实名，1 到 2 天审核。
4. 1 个代码编辑器，VS Code 加 Python 插件即可，别在服务器上直接改代码。
5. 1 个 Git 仓库，本地初始化就行，每次改动留 1 个提交记录，回退时省事。

第 1 条要提醒：先在本地跑通，再上服务器。我见过直接开云主机装环境的，光依赖冲突就耗掉 2 天，本地 30 分钟能解决的问题。

二、6 步操作，每步一个可验证的结果

第 1 步 装依赖并跑通 1 次调用

命令行进项目目录，激活虚拟环境后执行 pip install openai（国内多数平台的接口兼容这套 SDK），把 key 写进 .env 文件，代码里读环境变量，别把 key 写进代码。跑 1 次最简调用，终端打印出模型回复，这一步就算过。

第 2 步 把提示词和参数搬进配置文件

新建 config.yaml，把模型名、温度、最大输出长度、系统提示词 4 项写进去。代码里只读配置，不写死字符串。做这步的原因是同一套逻辑要试 3 种提示词，写死在代码里每次都要改文件、提交、重启。

第 3 步 接自己的数据

文档量在 200 份以内，直接切段后拼进提示词；超过 200 份再上向量库。切段长度按 500 到 800 字试，中文按句号切比按字数切效果好。切完存成本地 JSON，别每次启动都重新切。

第 4 步 加重试、超时、限流

超时设 30 秒，失败重试 2 次，重试间隔按 1 秒、3 秒递增。并发数从 2 开始往上加，加到接口开始返 429 就退回上一档。这 3 个数字不写，线上第一次流量小高峰就会把任务堆死。

第 5 步 做最小界面

用 Streamlit 30 行代码能出一个输入框加结果区，够内部试用。要给别人用再换框架，别一开始就上前后端分离。

第 6 步 部署并观测

放到 1 台 2 核 4G 的云主机，用 systemd 托管进程，日志写到文件里。上线后每天看 3 个指标：调用成功率、平均耗时、每次请求的 token 数。3 天数据平稳再交给使用者。

三、4 个参数怎么定

参数没有标准答案，但有起手值。下面 4 个是我在项目里固定先填的数，再按结果微调。

top_k 这一项容易被漏掉。检索回来的 20 段里真正有用的常常只有 3 到 4 段，其余全是干扰，模型会把不相干的段落也写进答案。

四、报错怎么排

1. ModuleNotFoundError：装了依赖但没激活虚拟环境。命令行前面出现 (venv) 才对。
2. 401 或 invalid api key：key 里带了空格，或者 .env 文件没被读取。打印 1 次 key 的长度核对，通常是 40 到 60 位。
3. 429 报错：并发太高或当日额度用完。先降并发到 1，还报就查开放平台用量页。
4. 输出被截断在半句：max_tokens 设小了，或提示词里要求了超长格式。先把上限加 200 试。
5. 中文乱码：文件编码不是 UTF-8。读写时显式指定 encoding="utf-8"。
6. 部署后访问不了：安全组没放行端口，或进程没起。先在本机 curl 127.0.0.1 试，通了再查安全组。

五、怎么判断这套东西能用了

1. 拿 20 条真实业务问题做回归。答对 16 条以上可以内部试用，低于 12 条要回头改切段和提示词。
2. 看平均耗时。单次响应超过 8 秒，用户会以为卡死，要么加流式输出，要么把检索段数减下来。
3. 看单次成本。把 20 条测试的 token 数加起来除以 20，乘上日调用量，就是月度成本的估算值。
4. 做 1 次故障演练。手动停掉模型服务，看界面是否给出可读的提示，白屏就要补降级页面。

六、3 种返工最常见，提前避开

返工 1 提示词写在代码里

第 1 版通常把提示词当字符串写进函数，试第 2 种写法时要么注释掉旧代码，要么复制 1 份新函数。改到第 5 个版本，文件里躺着 5 段长得差不多的字符串，改错 1 处就跑偏。把提示词放进配置文件或独立的模板文件，改文字不动代码，这 1 步 30 分钟能省后面几天。

返工 2 切段长度一次定死

600 字是我固定的起手值，但 600 对表格多的文档不合适。表格被切断后，模型只能看到半张表，回答问题容易编。做法是按文档类型分两档：纯文字 600 字，含表格的 300 到 400 字，并在切段时保留表头。

返工 3 没有留观测入口

上线后第 1 个问题往往是「为什么这次答得不对」，日志里只有最终结果，没有当时的检索段、模型名、参数。把每次请求的 4 项写进日志：问题原文、命中段落的编号、模型名、耗时，事后排查有据可查，日志量也不大。

团队协作时把角色分开：谁能改配置、谁能改提示词、谁能发布，3 类权限落到 3 个账号。1 个人全权能省事，出问题时也没人能说清是谁改的。

还有 1 个容易漏的准备：把模型的上下文上限和单次输出上限写进配置注释。上限决定切段长度和对话轮数，模型换代时这 2 个数字最先变，写在注释里下次改动不用翻文档。

这套流程值钱的地方在顺序。环境、配置、数据、稳定性、界面、观测，前面的没稳就往后做，返工成本会翻倍。我经手的 3 个项目里，2 次返工都发生在跳过第 4 步直接做界面的时候。

本文信息核对时间：2026-11