大模型应用开发教程,多少条测试用例才算跑通

教程顺序按 3 个里程碑排：能调通、能稳住、能上线。跑通的判据放在 30 条自有测试用例上，答对 27 条再往下走，别拿“页面有输出”当验收。三段落地的顺序颠倒，多半会在第二步推倒重来。

我去年带过两个实习生做同一个问答小工具，第一个上来就接检索、写界面，两周后发现基础调用的超时和重试都没处理，接口一抖就整屏报错。第二个按里程碑走，第 3 天跑通调用，第 6 天把 30 条用例的通过率压到 90%，第 12 天加检索。后面这个到上线只改了两处代码。

先准备这几样

账号与余额是头一件事。开放平台注册之后建一个 key，账户里留够 20 元上下的额度，余额见底时接口返回错误码而不是提示语，排查时会绕远路。key 存进环境变量，别写死在脚本里，改一次要翻十几个文件。

语言选 Python 3.9 以上，请求库用标准库里的 urllib 也能跑通，不必急着装框架。我第一次做的时候装了三层框架，出错时分不清是框架的问题还是网络的问题，后来退回裸请求，30 行代码跑通，问题一眼看得见。

还要准备 30 条真实问题。从业务里抄，不要自己编，编出来的问题模型答得太顺，测不出毛病。我惯用的配比是 15 条常规问、9 条边界问、6 条故意刁难的问，刁难的那 6 条用来观察模型会不会顺着错前提往下答。

环境上容易漏的两处

一处是超时。默认不设超时，脚本会一直挂着，批量跑的时候一挂就是半小时。给请求设 60 秒超时，超时重试 2 次，间隔 3 秒和 8 秒。

另一处是日志。每次调用把请求时间、模型名、输入字数、输出字数、耗时、状态码记一行，写到本地 csv。上线后出问题，这份日志比任何监控面板都直接。

里程碑一：把一次调用跑通

目标是拿到一段能重复执行的脚本，输入一句话，输出一段回答，中间不报错。

1. 在开放平台建 key，复制到环境变量，终端里 echo 一下确认读得到。
2. 用 urllib 发一次最小请求，body 里只放模型名和一句“你好”。
3. 打印返回的 JSON，先看有没有 error 字段，再看 content 字段。
4. 把 temperature 设成 0，同一句话连发 3 次，确认 3 次输出一致。
5. 加超时与重试，超时 60 秒，重试 2 次，间隔 3 秒和 8 秒。
6. 把每次调用的六个字段写进 csv，跑 10 次后打开看有没有空值。

第 4 步是分水岭。温度设 0 之后输出仍不稳定，说明请求里带了随机种子或者模型版本被平台改了，先把版本号写死再测。这一步不做，后面调提示词全是白费功夫，改一个字输出就变，你分不清是提示词起了作用还是随机波动。

第 6 步的日志别嫌麻烦。我在一个项目里省了这一步，后来账单比估算高出 40%，翻遍平台用量页也看不出是哪一段材料吃掉的，最后只能按天重跑对照，多花了 3 天。

里程碑二：把输出稳住

稳不住的表现是同一道题今天答对明天答错，或者格式今天带表头明天不带。处理顺序是固定输出格式、拆小任务、再调提示词。

固定格式先做。要求模型只返回一段 JSON，字段名在提示词里写清，返回后用 json.loads 解析，解析失败就把错误信息和原回答一起打出来。我统计过一轮 200 次调用，加了格式约束之后解析失败率从 11% 降到 1.5%。

30 条用例怎么用

每条用例写三样：问题、判分标准、参考要点。判分标准写可核对的条件，比如“必须提到 3 个字段名”“不能出现具体金额”。跑完一轮把通过条数记下来，改一次提示词再跑一轮，通过率不涨就回退。

第 5 轮那种情况很常见。提示词越写越长，约束越加越多，模型反而顾此失彼。加到最后 1200 字，通过率不如 400 字那一版。提示词的长度和通过率没有正相关，卡在 26 到 28 条时该动的是任务拆分。

拆分的做法是把一次调用变成两次：先让模型抽要素，再把要素拼成固定模板。两次调用的输入都短，出错时能定位到哪一步。代价是调用次数翻倍，费用按 token 算其实差不多，因为每次的输出都短了。

参数怎么填

第二里程碑里最费时间的是这几个参数，提示词写清楚之后反而好办。同一份提示词，参数不同，通过率差出 4 条。

温度和任务类型绑着看。抽取字段、判断分类这类活，温度给 0，同一输入永远同一输出，出问题好复现。写文案、起标题这类活，温度给 0.7 到 0.9，给 0 会得到一堆同质的结果。

评测集别一次建完

30 条够用，200 条反而拖住进度。我的做法是先把 30 条跑顺，上线后每周从真实提问里挑 5 条加进去，两个月之后自然长到 60 条上下。真实提问里有大量你编不出来的说法，比如把两个问题糅成一句问。

报错怎么排查

1. 连接超时：先 ping 一下域名，再试一次；连续 3 次都超时就换出口，别在原地重试。
2. 401 未授权：key 读成了空串，或者环境变量名拼错，打印前 8 位确认。
3. 429 限流：并发压到 2 条，请求之间留 1 秒，批量任务放到晚上。
4. 返回内容为空：输出上限给得太小，或者提示词里要求的格式模型不认。
5. JSON 解析失败：返回里夹了说明文字，提示词加一句“只返回 JSON，不要解释”。
6. 中文乱码：编码声明写成 utf-8，读文件时也指定 utf-8，两处都要写。

第 4 条我遇到过两次。输出上限填 100，要求写 300 字的回答，模型写到一半被截断，返回的内容是半个句子，解析自然失败。上限至少给到要求长度的 1.5 倍。

里程碑三：上线前过一遍清单

能调通、能稳住之后，剩下的是别人用起来会不会出问题。这一段花的时间常被低估，我见过跑通就上线的项目，第一周收到 20 多条“没反应”的反馈，全是超时没提示。

清单不长，5 项：失败时有可读的提示语；单次请求有超时；批量任务有进度显示；同样的输入不会重复扣费；日志能查到每一次调用。前 3 项和用户体验有关，后 2 项和钱有关。

灰度先放 10% 的流量，跑 3 天看两件事：通过率掉没掉，单次平均耗时涨没涨。两项都在 5% 以内波动再加到 50%。直接全量上线，出问题时你分不清是新版本的问题还是流量的问题。

怎么验证真的能用了

拿 10 条没进过评测集的新问题跑一遍，答对 8 条以上，基本可以交给业务方试用。答对 6 到 7 条，回去看错的那几条是不是同一类，同类错超过 3 条就该补示例。

再看费用。把上线前 3 天的日志汇总，算出单次平均 token 消耗，乘以预估的日调用量，跟预算对一下。这个数字比任何估算都准，因为它是真跑出来的。本文信息核对时间：2026-11。