大模型应用开发教程怎么入门?跟着 6 步跑通第一个接口

大模型应用开发从零到能跑，走 6 步就够：定场景、选模型、拿 key、写最小调用、调提示与参数、上线前加限频。有 1 点编程基础的人 2 天能跑通第一个能用的接口，剩下的时间都花在提示词和异常处理上。

我给 2 个内部系统做过接入，第 1 版都栽在同一处：把输出格式只写在提示词里，没做返回值校验，模型偶尔换个写法，下游解析就崩了。这篇按踩过的顺序写，能省掉那 2 次返工。

先准备 4 样东西

环境没备齐，第 3 步就会卡住，先把这 4 样落实。

1. 1 台能装 Python 3.9 以上或 Node 18 以上的电脑，装包用 pip 或 npm，别用系统自带的旧版本。
2. 1 个开放平台账号，做完实名认证，认证没过的账号调不通接口。
3. 1 个能发请求的工具，命令行 curl 够用，调试复杂请求装 Postman 更省事。
4. 1 个明确的小场景，比如把客服聊天记录压成 3 行摘要，别一上来就做通用助手。

第 4 条最容易被跳过。场景越具体，提示词越好写，验收标准也越好定。我见过 6 个人同时上手做"通用智能助手"，5 个人在第 3 天放弃，原因是没法判断做得好不好。

第 1 步：把输入输出写清楚

拿 1 张纸，左边写用户会送进来什么，右边写系统要吐出什么。摘要场景的输入是 300 到 800 字的对话记录，输出是 3 行、每行不超过 30 字的结论加 1 个跟进动作。

输入里要标出长度上限。超过上限的内容要么截断，要么分段处理，这一步不做，上线后长文本一定报错。输出要标出格式，是纯文本、JSON 还是带小标题的段落，格式定了才好写校验。

输出格式选 JSON 的场合

下游要程序解析的时候用 JSON，字段名提前定死，比如 summary、action、risk 三个键。纯给人看的场景用段落就行，硬套 JSON 反而让模型多花 token 去维护括号。

第 2 步：按场景选模型

同一家平台往往有 2 到 3 个模型档位，选错档位照样出结果，代价是又慢又贵。判断维度看 3 个：任务难度、单次长度、响应速度要求。

先用轻量模型跑通流程，效果不够再换档。反过来做的代价是调试期每天都在等 20 秒的响应，一天试不了 20 次。

第 3 步：写最小调用

最小调用只要 4 个要素：接口地址、认证头、模型名、消息数组。Python 里 8 行能跑通，key 从环境变量读，不要写进代码。

写法是先 import os 与 requests，把 url 设成平台的对话接口，headers 里放 Content-Type 和 Authorization 两项，data 里放 model 与 messages，最后取 response.json() 里的 choices 第 1 项。

消息数组的三层结构

system 放角色与规则，user 放这次的任务，assistant 放上一轮回答。多轮对话按时间顺序追加，system 始终排在第 1 位。顺序乱了模型会答得跳，跑通不受影响，质量差一截。

第 4 步：提示词按三段写

提示词写成三段，比写一大段散文稳定得多。三段是角色、约束、输出样例，顺序不要换。

角色那句限定身份和范围，比如"你是电商客服质检员，只判断回复里有没有承诺赔付"。约束那句列禁止项，比如不许编造订单号、不许给金额。输出样例给 2 条正例加 1 条反例，模型的格式跟随会明显变稳。

约束要写成可判定的句子。"态度友好"没法判定，"回复里不出现感叹号"可以判定。我把自己项目里 12 条模糊约束改成可判定的写法后，人工复核的返工率从 3 成降到 1 成以内。

第 5 步：参数怎么填

参数不多，4 个就够用，填错会直接影响稳定性。

temperature 设 0 不等于每次结果完全一样。平台侧还有并发与版本切分，同一请求连发 5 次，偶尔会有 1 次措辞不同。要绝对稳定，靠返回校验和重试，不要靠参数。

报错怎么排查

1. 401 认证失败。查 key 首尾空格，查 Bearer 后面有没有 1 个空格，查这个 key 是否已被停用。
2. 402 额度不足。费用中心看分项余额，赠送额度和充值额度分开记，赠送到期也报这个码。
3. 429 请求过多。加 1 秒间隔，批量任务按每批 20 条切分，重试上限设 2 次。
4. 400 参数错误。看返回体的 message 字段，它会指到具体字段，比看文档快。
5. 返回空内容。先看 finish_reason，值是 length 说明被 max_tokens 截断，值是 content_filter 说明触发了内容审核。

第 5 条最容易被忽略。返回体 200 但 content 是空串，很多人以为是模型故障，实际是长度或审核拦截，改 1 个参数就能恢复。

怎么验证跑通了

3 个动作，做完再进下一步。发 1 条最短请求，看 choices 里的 content 是否非空；连发 3 次，看 3 次是否都返回 200；拿 10 条真实数据跑 1 遍，人工看前 3 条结果是否符合预期。

10 条真实数据这一步别省。演示用的样例往往太干净，真实数据里有错别字、有方言、有半截话，前 3 条就能暴露提示词的缺口。我在 1 个项目里跳过这步，上线第 1 天收到 7 条"答非所问"的反馈。

上线前要加的 3 件事

本地跑通和线上可用隔着 3 件事，缺 1 件都会出事。

1. 限频。按用户或按 IP 限，单用户每分钟不超过 10 次，超了返回提示语。
2. 超时与重试。请求超时设 30 秒，重试 2 次，2 次都失败走兜底话术。
3. 日志。每次请求记下时间、用户、token 用量、耗时，出问题时能按小时回溯。

日志里记 token 用量这件事，1 个月后能救命。用量突然翻 3 倍，多半是某个入口死循环调用，有日志 5 分钟能定位，没日志只能逐段加打印。

Demo 到能交付还差哪一步

Demo 能跑，交付还差 3 件事：异常输入的处理、结果的校验与兜底、还有 1 份写清楚边界的使用说明。3 件事都不难，漏掉任意 1 件，用户第一次用就会遇到。

异常输入怎么处理

3 类输入要提前拦住：空内容、超长内容、纯符号。空内容直接提示重新输入，超长内容按 2000 字切段再送，纯符号与乱码先做 1 次字符过滤。3 类都不拦，接口会返回空结果，用户看到的是 1 个白屏。

结果怎么校验

按输出格式写校验。JSON 用解析函数试 1 次，解析失败就重发 1 次并追加 1 句格式要求；段落格式检查长度区间，少于 20 字或多于 800 字都判为异常。校验通过率能到 95% 以上，剩下的 5% 走兜底文案。

兜底文案不要写"服务繁忙"。写成"这段内容我暂时处理不了，请换 1 种说法或联系人工"，用户知道下一步做什么，投诉量会低很多。我在 1 个客服工具里换过这 1 句，转人工的比例从 12% 降到 4%。

使用说明写 1 页够用，3 段内容：能做什么、不能做什么、结果不准时怎么反馈。边界写清楚，用户不会拿它去算账，也不会把错误结果当结论用。

本文信息核对时间：2026-11。各平台的接口字段与模型名会调整，动手前先看开放平台文档页的最新版本说明。