起步：先跑通一次调用，再做第一个 RAG

读完这一节，你能做到

1. 独立配置好密钥与第一个可运行的调用。
2. 说清一次请求里哪些参数真正影响结果与成本。
3. 把一段资料塞进上下文，做出最小的"检索式回答"。
4. 让模型稳定输出可解析的结构化结果，并处理失败。

一、先把链路跑通

一次调用只有三件事：发请求、拿响应、看用量。

你的服务 → 带上密钥的 HTTPS 请求（模型名 + 消息列表）→ 模型服务
        ← 文本或结构化结果 + token 用量

密钥怎么放

• 从控制台创建，只放在环境变量或密钥管理服务里，不要写进代码、不要提交到仓库。
• 前端绝不放密钥：任何在浏览器里的 key 都等于公开。
• 本地开发用 .env，并把 .env 加进 .gitignore。

消息列表长什么样

[
  { role: "system", content: "你是客服助手，只根据资料回答" },
  { role: "user",   content: "退货要几天？" }
]

system 定规则，user 放问题。多轮对话就是把历史按顺序追加进去——这也是后面"上下文预算"要处理的东西。

二、四个一开始就要设的参数

参数	作用	起步建议
模型名	决定能力与价格	先固定一个，别一开始就多模型
输出长度上限	防止啰嗦与超支	按场景给一个够用的上限
随机性（温度）	影响稳定性	抽取、判断类任务调低；文案类可略高
超时与重试	决定失败体验	必须显式设置，默认值往往太长

为什么温度要低

做分类、抽取、结构化输出时，你需要的是稳定复现，不是创意。温度高会让同一条输入产出不同结构，评估就没法做。

三、从"聊天"到"带资料回答"

这一步就是最小 RAG 的雏形：把资料拼进上下文，并要求只根据资料回答。

system: 只根据下面的资料回答；资料里没有就说"资料中未提及"，不要推测。
资料：
[1] 退货政策 2026-03：签收后 7 天内可申请，运费由买家承担。
[2] ...
user: 退货要几天？谁承担运费？

三个必须同时做到的点

1. 给了资料：不给资料，模型只能凭记忆编。
2. 限定了边界：要求"没有就说没有"，否则它会用常识补。
3. 要求标注来源：让它说清依据是 [1] 还是 [2]，否则你无法核对。

马上会遇到的第一个问题

资料里没有答案时，模型仍然可能编。这不是提示词没写好，而是机制问题——所以工程上要加兜底：检索为空或分数低于阈值时，直接返回固定话术，不交给模型。

四、从"自由文本"到"结构化"

只要结果要被程序消费，就必须让模型输出结构化数据。

做法

1. 在提示里给出字段与类型，最好给一个示例。
2. 用服务商提供的结构化输出能力（如有），或在提示里明确"只输出 JSON"。
3. 收到后必须做 schema 校验：字段缺失、类型不对就重试或降级。

一次典型失败

模型输出了被 ```json 包裹的内容，或者前后加了一句"以下是结果"。直接 JSON.parse就会崩。所以解析前要先做容错：去掉代码块标记、截取第一个{到最后一个}，再解析。

校验失败怎么办

• 第一次：把错误信息回给模型，要求按 schema 重写。
• 第二次仍失败：降级到规则或直接报错，不要无限重试。

五、第一次失败，按这个顺序排查

现象	常见原因	先查什么
401 / 403	密钥错误、无权限、额度未开通	密钥是否加载进环境变量
429	限流、并发过高	是否有重试与退避
超时	输入过长、服务波动	输入 token 数与超时设置
返回空	被安全策略拦截、参数不合法	响应里的结束原因
格式不符	提示不明确、温度过高	提示与校验逻辑
答非所问	资料没给对，或指令冲突	实际拼进去的上下文

一条纪律：先把"实际发出去的请求"打印出来看一遍（脱敏后），大部分问题一眼就能看见。

六、成本意识从第一天开始

第一次调用就打开用量统计，记录三件事：输入 token、输出 token、耗时。

单次成本 = 输入 token × 输入单价 + 输出 token × 输出单价

单价以官方为准。起步阶段只要养成"每次都记"的习惯，等量上来才不会被账单吓到。

一个常见误区：只优化输出长度。实际上输入（系统提示 + 资料 + 历史）通常才是大头。

七、常见坑

1. 把密钥写进代码或提交到仓库。一旦泄露，别人可以用你的额度。
2. 不设超时。请求挂住会把你的服务连接池占满。
3. 对失败无限重试。参数错误重试一百次也还是错。
4. 不校验结构化输出。渲染层会收到残缺数据。
5. 一上来就追求"全能 Agent"。先让一次调用稳定，再谈多步。
6. 只看输出不看输入成本。输入才是账单大头。

八、动手任务：自写 → AI 写 → 对比 → 取舍

四步不跳：① 自己写（限时，关掉补全）→ ② 让 AI 写同一题 → ③ 逐条比对 → ④ 说出保留谁的写法。 完整动作与记录模板见《AI 协作与代码评审》。

① 自己写

1. 跑通一次调用：环境变量读密钥、发请求、打印正文与 token 用量，超时设 10 秒。
2. 改造它：给两段资料，要求"只根据资料回答、没有就说未提及、标注 [1]/[2]"。

② 让 AI 写同一题

把第 1 题交给 AI，补一句 密钥只从环境变量读，必须有超时与一次重试，打印 token 用量。

③ 对比要盯的点

• 它有没有把密钥写死或读 process.env 之外的来源？
• 超时与重试它设了吗？重试有没有区分错误类型？
• 有没有打印 token，还是只打印正文？

④ 一句话取舍

它给的代码，你敢直接用于线上吗？哪一处必须自己改。

九、自测

1. 一次调用由哪三件事组成？密钥应该放在哪？
2. 温度调低对哪类任务重要？为什么？
3. 最小 RAG 必须同时做到哪三点？
4. 结构化输出解析前要做哪些容错？
5. 401、429、返回空分别先查什么？
6. 为什么说成本大头通常不在输出？

参考答案要点：发请求/拿响应/看用量，环境变量；抽取与判断类，需要稳定复现；给资料、限边界、要来源；去代码块、截取区间、schema 校验；密钥、重试退避、结束原因；输入包含系统提示与资料与历史。

配套题目

★ 越多越该先背；点题目可看完整答案与深入版。

• ★★★★★ LLM 在什么情况下一定会错？系统里怎么兜住？
• ★★★★☆ 提示词里哪几部分最影响效果？
• ★★★★☆ 一个客服 Agent 的 token 成本怎么估？