1. 从需求到闭环AI 在线考试系统到底难在哪在线考试系统这个词听起来像是教务处的采购清单但真正动手写过的人都知道它的复杂度被严重低估了。一个能跑通的在线考试系统至少要同时解决四件事题库从哪来、组卷策略怎么定、判分逻辑怎么保证公平、考试过程中怎么防止作弊。传统做法里题库靠教研团队一道一道录入组卷靠人工挑题判分靠老师批改防作弊靠监考老师盯屏幕。这套流程在线下没问题一旦搬到线上成本结构就完全变了。我见过不少团队的做法是先花两个月把 CRUD 写完然后发现题库是空的于是又花三个月去采购或录入题目最后上线时发现题目质量参差不齐组卷逻辑根本没法自动化。问题的根子不在代码在于内容生产环节没有跟上。AI 的介入点恰好在这里。大语言模型可以在几秒内根据一个知识点生成不同题型的题目还能顺带给出标准答案和解析。这意味着题库不再是瓶颈而是可以按需生成的资源池。但这里有个现实问题不同模型的 API 格式不一样OpenAI 一套、Claude 一套、国内模型又是另一套如果每接一个模型就改一次代码维护成本会迅速失控。这就是统一 API 通道的价值所在。TaoToken 做的事情是把多家模型的调用方式收敛成一套兼容 OpenAI 格式的接口你只需要维护一个 Base URL 和一个 Key就能在多个模型之间切换。对于在线考试系统这种需要「生成题目用便宜模型、判分用强模型」的场景统一通道能省掉大量适配代码。这篇文章会带你走完从需求拆解到本地跑通的最小闭环。你会看到题库建模的数据结构、组卷策略的实现思路、判分服务的代码骨架以及最关键的——如何用 TaoToken 的统一 Key 把 AI 生成能力接进你的后端。适合谁看有基础后端经验、想用 AI 加速内容生产环节的开发者或者正在做教育类产品、被题库成本卡住的技术负责人。2. TaoToken 统一 API 通道为什么考试系统需要它先说清楚一个概念统一 API 通道不是「中转」它解决的是接口协议不一致的问题。你调用 OpenAI 的/v1/chat/completions和调用 Claude 的/v1/messages请求体结构、鉴权方式、返回格式都不一样。如果你的考试系统里写死了某一家将来想换模型就得重写整个 AI 服务层。TaoToken 的做法是提供一个兼容 OpenAI 协议的端点你按 OpenAI 的格式发请求它在内部路由到对应的模型。对代码来说你只需要改model字段的值其他都不用动。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。在考试系统里这个能力具体用在哪几个地方第一是题目生成。你可以用便宜的模型批量生成选择题用强模型生成编程题和主观题。切换模型只需要改一个字符串不需要改请求逻辑。第二是判分辅助。客观题直接比对答案就行但主观题和编程题的判分需要模型理解语义。这时候你可以把用户答案和标准答案一起发给模型让它给出评分和理由。不同模型的判分严格程度不一样统一通道让你可以快速做 A/B 测试。第三是防作弊的语义检测。比如检测两道题是否重复、检测用户答案是否从网上复制这些都可以通过模型调用完成。从成本角度看统一通道还有一个隐性好处你可以在一个地方管理配额和限流。考试系统在组卷高峰期会有大量并发生成请求如果每个模型单独管理 Key很容易出现某个 Key 超额、另一个 Key 闲置的情况。统一通道让你可以在应用层做统一的队列和重试策略。需要提前准备的东西不多一个 TaoToken 的 API Key、一个能跑 Node.js 或 Python 的环境、以及一个 Postgres 或 MySQL 实例。如果你只是想先验证连通性连数据库都可以先跳过用内存存数据就行。3. 可复制配置把统一 Key 接进考试系统后端这一节给出可以直接复制的配置片段。我以 Node.js Express 为例Python 的写法在最后附上。首先在项目根目录创建.env文件把 Key 和 Base URL 写进去# .env TAOTOKEN_API_KEYsk-你的实际Key TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODEL_GENERATEgpt-4o-mini TAOTOKEN_MODEL_JUDGEgpt-4o注意 Base URL 结尾不要带/v1SDK 会自动拼接。如果你用的是原生 fetch请求地址就是${BASE_URL}/v1/chat/completions。接下来是 AI 服务层的封装。我建议单独建一个services/aiClient.js把模型调用和业务逻辑隔离开// services/aiClient.js import OpenAI from openai; const client new OpenAI({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, }); export async function generateQuestions({ topic, singleCount, multiCount, codingCount }) { const prompt 你是一个资深考官。请围绕主题「${topic}」生成一份试卷。 要求 - ${singleCount} 道单选题 - ${multiCount} 道多选题 - ${codingCount} 道编程题 严格返回 JSON结构如下 { exam: { title: 试卷标题, questions: [ { type: single_choice, stem: 题干, options: [A. ..., B. ..., C. ..., D. ...], answer: A, explanation: 解析 }, { type: multi_choice, stem: 题干, options: [A. ..., B. ..., C. ..., D. ...], answer: [A, C], explanation: 解析 }, { type: coding, stem: 编程题描述, default_code: def solution():\\n pass, test_cases: [ {input: [1,2,3], expected_output: [3,2,1]} ] } ] } } 只返回 JSON不要任何额外说明。; const response await client.chat.completions.create({ model: process.env.TAOTOKEN_MODEL_GENERATE, messages: [{ role: user, content: prompt }], response_format: { type: json_object }, temperature: 0.7, }); const raw response.choices[0].message.content; return JSON.parse(raw); }这里有几个细节值得注意。response_format设为json_object能强制模型返回合法 JSON省掉正则清洗的麻烦。temperature设 0.7 是为了让题目有变化如果设 0 会生成高度相似的题目。模型选择上生成题目用gpt-4o-mini就够了判分再用gpt-4o这样成本能压下来。如果你用 Python配置片段是这样的# services/ai_client.py import os, json from openai import OpenAI client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), ) def generate_questions(topic, single_count, multi_count, coding_count): prompt f你是一个资深考官。围绕「{topic}」生成试卷。 单选题 {single_count} 道多选题 {multi_count} 道编程题 {coding_count} 道。 返回 JSON包含 exam.title 和 exam.questions 数组每题含 type/stem/options/answer/explanation。 编程题额外含 default_code 和 test_cases。只返回 JSON。 resp client.chat.completions.create( modelos.getenv(TAOTOKEN_MODEL_GENERATE), messages[{role: user, content: prompt}], response_format{type: json_object}, temperature0.7, ) return json.loads(resp.choices[0].message.content)数据库层面题目表的设计要能容纳三种题型。我用的结构是questions表存公共字段coding_cases表单独存编程题的测试用例CREATE TABLE questions ( id SERIAL PRIMARY KEY, exam_id INT REFERENCES exams(id), type VARCHAR(20) NOT NULL, stem TEXT NOT NULL, options JSONB, answer JSONB NOT NULL, explanation TEXT, difficulty VARCHAR(10) DEFAULT medium, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE coding_cases ( id SERIAL PRIMARY KEY, question_id INT REFERENCES questions(id), input JSONB, expected_output JSONB );options和answer用 JSONB 是为了兼容单选字符串和多选数组两种格式。这个设计在组卷时查询效率也够用因为组卷通常是按 exam_id 批量取题。4. 验证请求本地启动与接口连通性检查配置写完之后先别急着写业务逻辑第一步是验证 API 通道能不能通。我习惯用一个最小的脚本做连通性测试避免后面出问题时分不清是配置错了还是代码写错了。创建一个test-connection.jsimport OpenAI from openai; import dotenv/config; const client new OpenAI({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, }); async function main() { const resp await client.chat.completions.create({ model: process.env.TAOTOKEN_MODEL_GENERATE, messages: [{ role: user, content: 只回复两个字通了 }], }); console.log(模型返回, resp.choices[0].message.content); console.log(消耗 token, resp.usage.total_tokens); } main().catch((e) { console.error(调用失败, e.status, e.message); });运行node test-connection.js如果看到「模型返回通了」说明 Key 和 Base URL 都正确。如果报 401检查 Key 是否有多余空格如果报 404检查 Base URL 是否多写了/v1。连通性通过后启动后端服务。我用 Express 写一个最小的组卷接口// server.js import express from express; import dotenv/config; import { generateQuestions } from ./services/aiClient.js; const app express(); app.use(express.json()); app.post(/api/exam/generate, async (req, res) { const { topic, singleCount 5, multiCount 3, codingCount 2 } req.body; try { const result await generateQuestions({ topic, singleCount, multiCount, codingCount }); res.json({ ok: true, data: result }); } catch (e) { res.status(500).json({ ok: false, error: e.message }); } }); app.listen(3000, () console.log(服务已启动 http://localhost:3000));启动后发一个测试请求curl -X POST http://localhost:3000/api/exam/generate \ -H Content-Type: application/json \ -d {topic:Python列表操作,singleCount:3,multiCount:2,codingCount:1}成功的话你会拿到一个 JSON里面包含试卷标题和题目数组。我实测下来生成 6 道题大约消耗 1500 到 2000 token耗时 8 到 15 秒。这个延迟对于组卷场景是可以接受的因为组卷不是高频操作。但如果你要做实时生成就需要加异步任务队列把生成请求丢到后台前端轮询结果。判分接口的验证稍微复杂一点。客观题直接比对编程题需要跑测试用例。我建议先用一个简单的字符串比对做验证确认判分链路通了再接入 Docker 沙盒app.post(/api/exam/judge, async (req, res) { const { question, userAnswer } req.body; if (question.type single_choice) { const correct userAnswer question.answer; return res.json({ correct, score: correct ? 100 : 0 }); } if (question.type multi_choice) { const correct JSON.stringify([...userAnswer].sort()) JSON.stringify([...question.answer].sort()); return res.json({ correct, score: correct ? 100 : 0 }); } // 编程题走沙盒这里先返回占位 res.json({ correct: null, score: 0, message: 编程题判分待接入沙盒 }); });这个最小闭环跑通之后你就有了一个能生成题目、能判客观题的系统骨架。剩下的工作是把沙盒接进来、把防作弊加上、把前端做出来。5. 常见报错排查401、local proxy failed 与 JSON 解析失败这一节列出我在接入过程中真实遇到过的报错以及对应的排查路径。这些错误看起来吓人但原因通常很集中。401 Unauthorized是最常见的。报错信息一般是Error: 401 Incorrect API key provided。原因有三个Key 复制时带了空格或换行、.env文件没被正确加载、或者 Key 已经过期。排查方法是先确认process.env.TAOTOKEN_API_KEY的值长度对不对然后在代码里打印前 8 位和后 4 位做比对。注意不要把完整 Key 打到日志里。local proxy failed这个报错通常出现在你本地网络环境有额外代理设置的时候。报错信息类似Error: local proxy failed: connect ECONNREFUSED。原因是 SDK 读取了系统环境变量里的HTTP_PROXY或HTTPS_PROXY但那个代理地址不可用。解决办法是在启动脚本里显式清掉这两个变量unset HTTP_PROXY HTTPS_PROXY node server.js或者在.env里设置NO_PROXYtaotoken.net让 SDK 跳过代理。reading choices这个报错说明返回体结构和你预期的不一样。典型报错是TypeError: Cannot read properties of undefined (reading choices)。原因通常是请求根本没成功返回的是一个错误对象但你的代码直接去取response.choices。正确的做法是先判断response.error是否存在const resp await client.chat.completions.create({...}); if (resp.error) { throw new Error(API 错误${resp.error.message}); } const content resp.choices[0].message.content;JSON 解析失败是生成题目时的高频问题。报错是SyntaxError: Unexpected token或者JSON.parse抛异常。原因是模型返回的内容里混了 Markdown 代码块标记比如 json 开头。解决办法有两个一是用response_format: { type: json_object }强制 JSON 输出二是在解析前做一次清洗function safeParse(raw) { const cleaned raw.replace(/json/g, ).replace(//g, ).trim(); return JSON.parse(cleaned); }OAuth 相关报错如果你用的是 Claude Code 或 Codex 这类工具接入可能会遇到OAuth token expired或invalid_grant。这类工具通常有自己的鉴权流程和 API Key 是两套体系。如果你只是想用 API 通道建议直接用 OpenAI SDK 的写法不要走 OAuth 流程。CC Switch 或 Cline MCP 这类工具在配置时需要同时填 Base URL、API Key 和 Model ID 三个字段缺一个都会报鉴权失败。Base URL 填https://taotoken.net/apiKey 填你的实际 KeyModel ID 填gpt-4o-mini或你需要的模型名。还有一个容易忽略的问题并发请求时的限流。如果你在组卷时一次性发 10 个生成请求可能会触发 429 报错。解决办法是加一个简单的队列控制并发数在 3 到 5 之间import pLimit from p-limit; const limit pLimit(3); const tasks topics.map((t) limit(() generateQuestions(t))); const results await Promise.all(tasks);6. 从最小闭环到可用系统下一步怎么走跑通生成和判分之后你的系统已经具备了核心能力。接下来要补的是工程化部分。防作弊这块前端可以做切屏检测和复制粘贴拦截后端可以做答题时间异常检测。比如一道单选题的正常作答时间是 30 到 60 秒如果用户在 3 秒内提交大概率是脚本或题库泄露。这类检测不需要 AI用规则引擎就够了。组卷策略可以从随机抽题升级为按知识点分布和难度梯度抽题。你可以在生成题目时让模型顺便打上知识点标签和难度标签存到数据库里组卷时按标签查询。这样生成的试卷更符合教学逻辑。成本控制方面我建议对高频知识点做缓存。同一个知识点生成的题目如果一周内已经生成过就直接从缓存取不要重复调用 API。缓存键可以用topic 题型 数量的哈希值。如果你想把编程题判分做扎实Docker 沙盒是绕不开的。核心是限制容器的网络访问、文件系统写入和运行时间。可以用--network none、--read-only和--timeout参数控制。测试用例的执行结果和预期输出做比对注意要处理浮点数精度和输出格式差异。最后说一个实际经验AI 生成的题目质量参差不齐尤其是编程题的测试用例有时候会漏掉边界情况。我的做法是在生成后加一道校验用另一个模型调用检查题目和答案是否自洽。这个校验步骤会增加成本但能显著降低人工审核的工作量。如果你还没开始接入可以先从模型对话页面验证一下模型返回质量确认生成格式符合预期后再写代码。接入文档里有完整的参数说明和示例遇到报错时对照排查会快很多。长期做编码和 Agent 场景的话Coding Plan 的配额模式比按量计费更适合高频调用。