新来的朋友经常问我一个特基础、但又特实在的问题——“我好不容易拿到了API Key，调通了第一个请求，然后呢？这玩意儿到底能干点啥？”

好问题。今天不聊高深的路由策略，也不谈成本优化，咱们回到地面，把大模型API最核心的三个看家本事掰开揉碎讲清楚。哪怕你昨天刚注册账号，照着这篇文章走一遍，也能在代码里让模型给你干活。

文本生成：最朴实也最有力的基础能力

文本生成是API的“老本行”。你给它一段输入（官方叫 prompt），它接着往下写，输出一段文字。

别以为这功能只能写诗写小说。我见过最实用的场景是：每天早晨定时拉取昨天的销售数据，拼成一段话扔给模型，让它自动生成日报摘要，然后邮件发给老板。全程不需要人盯着，模型干这种“把数字翻译成人话”的活儿特别利索。

代码层面的调用最直接。构造一个请求，messages 里放一条 role: user 的内容，指定 model，跑完拿 choices[0].message.content 就是结果。

关键参数就三个：

  • temperature：控制随机性，0.1几乎照抄训练语料的风格，1.2开始放飞自我。写日报给0.2，写头脑风暴给0.9。

  • max_tokens：限定输出长度。不是字数，是Token数。中文一个字大约占1.5～2个Token，自己换算下。

  • top_p：和temperature起类似作用，二选一调就行，别两个同时较劲。

新手容易犯的错是把 max_tokens 设得太小，模型话没说完就被截断。宁可设大一点，实际消耗按真实输出计费，不会因为你设了8000就一定扣8000的钱。

对话问答：带上下文的多轮交互

如果说文本生成是单发子弹，对话问答就是连发——模型能记住你之前说过什么。

这里头的关键是 messages 数组。你每次请求得把整个对话历史都传回去：

text

[
  {"role": "system", "content": "你是一个精通Python的助手"},
  {"role": "user", "content": "帮我写个读取CSV的代码"},
  {"role": "assistant", "content": "好的，以下代码..."},
  {"role": "user", "content": "加上异常处理"}
]

看到没？每次新的提问都要带上之前所有的问答对。模型本身没记忆，全靠你把历史塞回去，它才能“记得”前头聊了什么。

这里面有个坑：对话越长，消耗的Token越多，成本线性上涨。我的做法是设一个窗口——只保留最近10轮对话，超过的就截掉或者用摘要压缩一下。别傻乎乎把几十页聊天记录全怼进去，钱包受不了。

system 角色特别重要。它是模型的“人设”或“行为准则”。你写“用幽默风格回答”，它就活泼点；写“只返回JSON格式”，它就不会啰嗦半句废话。建议每个对话都配一条清晰的 system，能省掉很多后续纠偏的口舌。

流式输出：让用户体验从“煎熬”变“顺畅”

这是最容易被新手忽略、但最能提升产品质感的功能。

不开流式（stream=False），模型得把整段回答全生成完，才一次性返回给你。如果输出有500个Token，你得干等好几秒，屏幕上啥动静都没有——用户早跑了。

开了流式（stream=True），模型每生成几个Token就往外吐一点，你收到一个chunk就立刻渲染到屏幕上。用户看到字一个一个蹦出来，体感上觉得“这软件好快”，实际上总耗时和不开流式差不多，但心理等待时间至少缩短一半。

实现上就两处改动：

  • 请求里加上 "stream": true

  • 客户端不要等着读完整响应，改成逐行解析SSE（Server-Sent Events）格式。每一行长这样：data: {"choices":[{"delta":{"content":"你"}}]}

你需要把每个chunk里的 delta.content 拼起来，最后就是完整回答。主流语言的HTTP客户端都支持流式读取，Python用 requests 加 stream=True，JS用 fetch 配合 response.body.getReader()。

一个常被问的问题：“流式模式下还能拿到 usage 吗？”——大部分平台在流结束时最后一个chunk会带上用量信息，记得把最后一帧单独解析出来。

三种能力怎么组合用？我给你几个真场景

  • 智能客服：对话问答（多轮记忆） + 流式输出（用户等得焦躁）。system设定“简洁、专业”，temperature调0.3，别让客服跟用户贫嘴。

  • 内容生成器：文本生成（单次长文） + 不开流式。比如生成周报、邮件模板、产品描述，一次性拿完整结果，省去拼接逻辑。

  • 实时翻译助手：对话问答（记住源语言和目标语言） + 流式输出（长文本逐句显示）。system里写好“只翻译不解释”，能挡住模型额外加戏。

几个让你少掉头发的小习惯

第一，不管用哪种能力，把请求和响应的完整JSON打印到日志里，但记得脱敏——不要打API Key。出问题的时候，日志就是你唯一的目击证人。

第二，max_tokens 别贴着模型的上下文上限设。比如模型支持16K，你最多用到12K，留点余量给系统提示和返回的填充字段。满了就截断，截断就丢信息。

第三，第一次调某个新模型时，先用不开流式、temperature=0、最短的prompt试通，再逐步加复杂度。这叫“最小可用请求”，能帮你快速区分是代码写错了还是参数配炸了。

这三种能力就像工具箱里的三把扳手——大小不同，各管一摊。你不用一开始全精通，挑一个最贴近你业务场景的练手就行。先跑通，再跑顺，最后再琢磨怎么省钱。

下一期想听什么？成本优化还是容灾切换？评论区喊一声，我按呼声最高的写。