1. 从题库生成到自动评分AI智能测评应用平台项目分享AI智能测评应用平台说白了就是一套让用户自己出题、自己配评分规则、系统自动判分的工具。它最核心的能力有两个一是用大模型批量生成题目和选项二是用大模型对主观题做自动评分。适合谁适合想快速搭一个测评类小产品的个人开发者也适合两三个人的小团队做 MVP 验证。我这次把整条链路重新梳理了一遍重点解决一个很现实的问题题库生成、答案评分、结果解读这三个环节如果分别对接不同厂商的模型Key 管理、计费口径、超时重试全都不一样维护成本高得离谱。所以这篇分享会围绕「用 TaoToken 统一 Key 打通测评链路」来写从环境变量配置到一次端到端请求验证你照着做就能跑通。先明确一下这个平台的最小业务闭环。应用制作者在创建页填写应用信息依次添加题目和评分规则生成一个测评应用管理员审核通过后应用出现在主页普通用户检索、在线答题、提交后拿到评分和结果解读。这里面有三个地方会调用大模型生成题目、生成评分规则、对主观题做自动评分。如果每个环节都单独配一个厂商的 Key代码里会散落一堆 base_url 和 api_key换模型时改到崩溃。统一 Key 的价值就在这里——所有模型调用走同一个入口模型 ID 作为参数传入切换模型只改一个字符串。我试过把三个环节的调用收敛到一个AiClient里底层只认一个 base_url 和一个 api_key模型名从配置读。这样做的直接好处是题库生成用便宜的小模型评分用推理更强的大模型成本可控代码还干净。下面从环境准备开始一步步把这条链路搭起来。2. TaoToken 前置准备统一 Key 与模型通道配置在动手写代码之前先把 TaoToken 这边的准备工作做完。你需要拿到一个 API Key并确认要用的模型 ID。整个过程不复杂但有几个细节容易踩坑我按顺序说。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录。登录后进入控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。控制台里能看到账户余额、调用统计和 Key 管理入口。第二步创建 API Key。进入 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 点新建复制生成的 Key。这个 Key 只显示一次建议直接存到密码管理器里。注意不要把它硬编码进前端代码后面我们会用环境变量。第三步确认模型 ID。测评平台一般需要两类模型一类是生成题目用的通用对话模型一类是评分用的推理模型。你可以在模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 里先手动试几个模型看看生成 JSON 的稳定性。我实测下来生成题目用响应快的小模型就够评分环节换推理强一点的模型结果更稳。第四步记下 API 基础地址https://taotoken.net/api 。注意这个地址不带任何查询参数直接作为 base_url 使用。所有模型调用都走这个入口模型 ID 放在请求体里。这里有个关键点要强调TaoToken 是统一的模型调用通道不是让你去改编辑器或者替代你的开发工具。你的项目该怎么写还怎么写只是把原来散落各处的模型请求收敛到一个出口。这样做的好处是计费口径统一、Key 轮换方便、超时和重试策略可以集中处理。环境变量建议这样组织后端项目根目录建一个.env文件TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODEL_GEN你的生成模型ID TAOTOKEN_MODEL_SCORE你的评分模型ID前端不要直接读这些变量所有模型调用都走后端代理。这一点在测评平台里尤其重要因为生成题目接口如果暴露在前端很容易被刷token 计费会失控。后面排障章节会讲怎么用缓存和限流兜住。如果你打算长期做编码类或 Agent 类功能可以了解下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。测评平台的题目生成和评分逻辑调试阶段会频繁改 prompt有个稳定的编码通道会省不少事。3. 可复制配置把统一 Key 接进测评链路这一节是重点直接给可复制的配置和代码。我按「配置层 → 客户端封装 → 业务调用」三层来写你照着贴就能用。先看配置层。除了上面的.env再建一个application.ymlSpring Boot 项目或者config.pyPython 项目。我用 Spring Boot 举例因为原项目是 Java 后端taotoken: base-url: ${TAOTOKEN_BASE_URL} api-key: ${TAOTOKEN_API_KEY} model: generate: ${TAOTOKEN_MODEL_GEN} score: ${TAOTOKEN_MODEL_SCORE} timeout: connect: 5000 read: 60000注意 read 超时给到 60 秒因为生成一整套题目可能比较慢。connect 超时 5 秒足够。然后是客户端封装。核心思路是所有请求都发往base-url /v1/chat/completions模型 ID 从配置读业务层只传 prompt 和模型类型。下面是一个精简的 Java 封装Component public class AiClient { Value(${taotoken.base-url}) private String baseUrl; Value(${taotoken.api-key}) private String apiKey; Value(${taotoken.model.generate}) private String generateModel; Value(${taotoken.model.score}) private String scoreModel; private final RestTemplate restTemplate; public AiClient(RestTemplateBuilder builder) { this.restTemplate builder .setConnectTimeout(Duration.ofSeconds(5)) .setReadTimeout(Duration.ofSeconds(60)) .build(); } public String chat(String prompt, boolean forScore) { String model forScore ? scoreModel : generateModel; HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); MapString, Object body new HashMap(); body.put(model, model); body.put(messages, List.of( Map.of(role, user, content, prompt) )); body.put(temperature, forScore ? 0.2 : 0.7); HttpEntityMapString, Object entity new HttpEntity(body, headers); ResponseEntityString resp restTemplate.postForEntity( baseUrl /v1/chat/completions, entity, String.class); return resp.getBody(); } }这段代码里有两个设计点值得说。第一forScore参数决定用哪个模型业务层不用关心模型 ID 具体是什么。第二评分场景 temperature 设 0.2让输出更稳定生成题目设 0.7题目多样性好一些。如果你用的是 Python等价配置长这样import os import requests BASE_URL os.getenv(TAOTOKEN_BASE_URL) API_KEY os.getenv(TAOTOKEN_API_KEY) MODEL_GEN os.getenv(TAOTOKEN_MODEL_GEN) MODEL_SCORE os.getenv(TAOTOKEN_MODEL_SCORE) def chat(prompt: str, for_score: bool False) - str: model MODEL_SCORE if for_score else MODEL_GEN resp requests.post( f{BASE_URL}/v1/chat/completions, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json, }, json{ model: model, messages: [{role: user, content: prompt}], temperature: 0.2 if for_score else 0.7, }, timeout(5, 60), ) resp.raise_for_status() return resp.json()[choices][0][message][content]接下来是业务调用。生成题目时prompt 要明确要求返回 JSON 数组并且给出字段示例。我踩过的坑是如果不给示例模型有时返回 Markdown 代码块包裹的 JSON解析会失败。所以 prompt 里要写「只返回 JSON不要用代码块包裹」。评分环节同理要求返回{score: 85, reason: ...}这样的结构。这里给一个生成题目的 prompt 模板你是一个测评题目生成助手。根据以下应用主题生成 5 道单选题。 主题{topic} 要求 1. 每题 4 个选项只有一个正确答案 2. 返回 JSON 数组每个元素包含 question、options、answer 三个字段 3. options 是长度为 4 的字符串数组answer 是正确选项的下标0-3 4. 只返回 JSON不要用代码块包裹不要加任何解释评分 prompt 模板你是一个测评评分助手。根据题目和用户答案给出评分。 题目{question} 参考答案{reference} 用户答案{userAnswer} 要求 1. 返回 JSON包含 score0-100 整数和 reason一句话说明 2. 只返回 JSON不要用代码块包裹把这两个模板接进AiClient.chat()整条链路的模型调用就统一了。换模型时只改.env里的两个变量代码一行不动。4. 验证请求一次端到端测评跑通配置写完了得验证它真的能跑。这一节给一个完整的端到端验证动作从生成题目到自动评分你照着执行一遍看到预期输出就说明链路通了。先验证最基础的连通性。用 curl 直接打一次接口确认 Key 和 base_url 没问题curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL_GEN, messages: [{role: user, content: 返回 JSON{\ok\: true}}], temperature: 0.2 }预期返回里能看到choices[0].message.content包含{ok: true}。如果这一步就报错先去看第 5 节的排障对照表。连通性没问题后跑一次完整的测评流程。我写了一个简单的验证脚本模拟「生成题目 → 用户答题 → 自动评分」三步import json from ai_client import chat # 上面封装的 chat 函数 # 第一步生成题目 gen_prompt 你是一个测评题目生成助手。根据以下应用主题生成 3 道单选题。 主题MBTI 性格倾向测试 要求 1. 每题 4 个选项只有一个正确答案 2. 返回 JSON 数组每个元素包含 question、options、answer 三个字段 3. options 是长度为 4 的字符串数组answer 是正确选项的下标0-3 4. 只返回 JSON不要用代码块包裹不要加任何解释 raw chat(gen_prompt, for_scoreFalse) questions json.loads(raw) print(生成题目数量, len(questions)) print(第一题, questions[0][question]) # 第二步模拟用户答题 user_answers [q[answer] for q in questions] # 全选正确答案方便验证 # 第三步逐题评分 total 0 for q, ua in zip(questions, user_answers): score_prompt f你是一个测评评分助手。根据题目和用户答案给出评分。 题目{q[question]} 参考答案{q[options][q[answer]]} 用户答案{q[options][ua]} 要求 1. 返回 JSON包含 score0-100 整数和 reason一句话说明 2. 只返回 JSON不要用代码块包裹 result json.loads(chat(score_prompt, for_scoreTrue)) total result[score] print(f题目评分{result[score]}理由{result[reason]}) print(平均分, total / len(questions))预期输出类似生成题目数量 3 第一题 在社交场合中你更倾向于 题目评分100理由用户选择了与参考答案一致的选项。 题目评分100理由答案完全匹配。 题目评分100理由用户答案正确。 平均分 100.0看到这个输出说明从题目生成到自动评分的整条链路已经跑通而且全程只用了 TaoToken 一个 Key。你可以把user_answers改成随机选项观察评分变化验证评分逻辑是否合理。这里有个细节生成题目返回的 JSON 偶尔会带前后空格或换行json.loads之前最好做一次raw.strip()。如果模型返回了代码块包裹可以用正则把json 和去掉。这个处理放在chat函数里更省事。验证通过后建议把这次请求的耗时和 token 消耗记下来。生成 3 道题大概几秒评分每题一两秒整体在可接受范围。如果要做流式输出把stream参数设为 true前端用 SSE 接收就能实现「生成一道展示一道」的效果。5. 常见报错排查401、local proxy failed 与 JSON 解析失败链路跑通不代表以后不出问题。这一节把我遇到过的几类报错和排查方法列出来你对照着看。401 Unauthorized。最常见的原因是 Key 没读到或者读错了。先确认.env文件在项目根目录且被正确加载。Spring Boot 里如果用Value读不到检查是不是少了spring-dotenv依赖或者 IDE 没装 EnvFile 插件。另一个原因是 Key 复制时带了空格Bearer后面多一个空格也会 401。排查方法把 Key 打印出来看长度正常是sk-开头的一长串。如果确认 Key 没问题还是 401去控制台看下 Key 是否被禁用或余额是否耗尽。local proxy failed。这个报错通常出现在请求根本没发出去的时候。检查base_url是不是写成了https://taotoken.net/api/带尾斜杠拼接/v1/chat/completions后变成双斜杠有些 HTTP 客户端会报错。正确写法是https://taotoken.net/api不带尾斜杠。另外检查本机网络是否能正常访问外网公司内网有时会拦截。如果用了 RestTemplate确认没有配置额外的代理。reading choices 报错 / choices 字段为空。这个说明请求发出去了但返回体里没有choices。先打印完整响应体看error字段。常见原因是模型 ID 写错了比如把生成模型 ID 填到了评分模型的位置。还有一种情况是 prompt 太长超出模型上下文限制返回体里会有明确的错误信息。排查方法把model字段和响应体一起打印出来对照控制台的模型列表确认 ID 拼写。JSON 解析失败。模型返回的内容不是纯 JSON可能带了 Markdown 代码块或者解释文字。处理方法是加一层清洗import re def clean_json(raw: str) - str: raw raw.strip() raw re.sub(r^json\s*, , raw) raw re.sub(r\s*$, , raw) return raw.strip()然后在json.loads之前调用clean_json。如果清洗后还是解析失败说明 prompt 约束不够强在 prompt 末尾再加一句「只返回 JSON不要任何其他文字」。OAuth 相关报错。如果你在配置过程中看到 OAuth 字样通常是把认证方式和 API Key 搞混了。TaoToken 的模型调用走的是 Bearer Token不需要 OAuth 流程。检查请求头是不是写成了Authorization: OAuth xxx改成Authorization: Bearer xxx即可。超时或连接重置。生成题目时如果 read 超时设得太短比如 10 秒长题目生成会中断。把 read 超时调到 60 秒以上。如果频繁连接重置检查是不是并发太高被限流了。测评平台的生成题目接口建议加一层缓存同一个主题短时间内重复请求直接返回缓存结果既省钱又避免触发限流。这里补充一个缓存方案。用 Caffeine 做本地缓存Redis 做分布式锁防止缓存击穿Cacheable(value questions, key #topic) public ListQuestion generateQuestions(String topic) { // 先查缓存没有再调 AI String raw aiClient.chat(buildPrompt(topic), false); return parseQuestions(raw); }这样攻击者短时间内反复调用同一个主题的生成接口只会命中缓存不会重复计费。对于不同主题的恶意刷量再加一层用户维度的限流比如普通用户每分钟最多生成 3 次。6. 把统一 Key 用起来测评平台的后续扩展链路跑通、排障方法也有了最后聊聊怎么把这套统一 Key 的架构用得更充分。测评平台的核心竞争力不在题目本身而在评分规则和结果解读的丰富度。统一 Key 让你可以低成本地尝试不同模型找到性价比最高的组合。一个实用的扩展方向是分级调用。生成题目用便宜的小模型评分用中等模型结果解读用推理强的模型。三个环节的模型 ID 都从配置读切换成本几乎为零。你可以做一个 A/B 测试同一批题目用两个不同模型评分对比结果一致性选出更稳的那个。另一个方向是把评分规则也交给 AI 生成。用户创建应用时只填主题和评分维度系统自动生成评分规则 JSON用户确认后保存。这样创建门槛更低平台上的应用数量会涨得更快。生成评分规则的 prompt 和生成题目的类似同样要求返回结构化 JSON。如果你打算做长期编码或 Agent 类功能比如让 AI 根据用户答题历史自动推荐下一套测评可以看看 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。这类功能需要频繁调试 prompt 和工具调用逻辑有个稳定的编码通道会顺手很多。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的参数说明和错误码对照。遇到不确定的字段先查文档再改代码比盲目试错快。最后说个实际经验测评平台的模型调用一定要做日志。每次请求记录模型 ID、prompt 长度、响应耗时、token 消耗。这些数据积累下来你就能清楚知道钱花在哪、哪个环节可以优化。我一开始没做日志月底看账单完全对不上后来补上日志才发现是生成题目环节重复调用太多。加上缓存和日志之后成本降了一半还多。整套流程走下来你会发现统一 Key 最大的价值不是省事而是让模型切换变成一件没有心理负担的事。想试新模型改一个环境变量重启服务跑一遍验证脚本几分钟就能得出结论。这种迭代速度对个人开发者和小团队来说比什么都重要。