做一個“AI or Not”式的維基百科答題小游戲核心并不是把兩段文本并排展示給用戶那么簡單。真正的工程鏈路是先從維基百科取到人類編輯撰寫的真實詞條摘要再調(diào)用大模型生成同一主題的“AI 風(fēng)格”文本最后把兩段文本隨機打亂讓用戶判斷哪一段來自 AI判完立刻給反饋并記錄得分。這類小游戲在 AI 應(yīng)用開發(fā)里很有代表性。它不依賴高成本數(shù)據(jù)和復(fù)雜模型只需要把維基百科 API、大模型接口和基礎(chǔ)前后端組織起來就能形成一個可交互、可演示、可擴展的完整產(chǎn)品。背后涉及的問題包括如何區(qū)分人寫文本和模型生成文本、大模型提示詞如何穩(wěn)定輸出、接口異常如何降級、以及這類能力在內(nèi)容標注和模型評測中怎么用。適合讀者想用大模型做一個真實可玩項目的開發(fā)者正在學(xué)習(xí) FastAPI 或 Python 后端的前端工程師以及對 AI 應(yīng)用好奇的產(chǎn)品經(jīng)理。全文會帶你把服務(wù)完整搭起來從環(huán)境準備到接口調(diào)試最后給出常見問題排查和生產(chǎn)化建議。1. 為什么用“維基百科文本”來做 AI 檢測游戲1.1 這個游戲到底在測什么“AI or Not”類游戲表面上是在測用戶實際上是在測模型和文本風(fēng)格。人類寫的維基百科詞條開篇通常追求信息密度句子緊湊結(jié)構(gòu)穩(wěn)定習(xí)慣先給定義再展開背景。大模型生成的文本雖然表面上也有百科風(fēng)格但細節(jié)上容易出現(xiàn)幾種可感知的特征喜歡用“值得注意的是”“在當(dāng)今時代”這類過渡句。信息密度偏低一句話能說完的內(nèi)容會擴展成三句。偶爾出現(xiàn)事實錯誤也就是 AI 幻覺。語言非常“平均”缺乏個人編輯帶來的句式變化。所以游戲判斷的不只是內(nèi)容真假而是文本風(fēng)格、信息密度和事實準確性。用戶答對之后如果能看到模型原文和人類原文的差異就天然理解了一次 AI 文本生成的特點。1.2 維基百科作為題目源的四個優(yōu)勢選擇維基百科而不是自己積累語料是因為它提供的題目源是現(xiàn)成、穩(wěn)定且合法的。優(yōu)勢說明數(shù)據(jù)現(xiàn)成REST API 直接返回詞條摘要不需要自己抓網(wǎng)頁洗數(shù)據(jù)覆蓋話題廣隨機詞條可以覆蓋技術(shù)、歷史、地理、人物等多類主題質(zhì)量有保證詞條經(jīng)過多輪編輯開篇摘要相對規(guī)范適合作為“人類文本”基準內(nèi)容協(xié)議清楚維基百科內(nèi)容遵循開放許可做學(xué)習(xí)項目和產(chǎn)品原型時更容易說清來源對學(xué)習(xí)項目來說這意味著你可以把大部分精力放在題目邏輯和 AI 生成上而不是花一整周去清洗語料。1.3 為什么不是直接調(diào)用現(xiàn)成 AI 檢測服務(wù)市面上有商用 AI 檢測服務(wù)也能看到“某段文本是人類寫的還是 AI 寫的”的概率分數(shù)。但如果項目只用現(xiàn)成檢測 API你就無法控制題目生成過程也無法解釋檢測結(jié)果背后的邏輯。更重要的是檢測服務(wù)通常只給一個概率用戶不知道這個概率是怎么來的。自己實現(xiàn)“人類文本 AI 生成文本”的組合等于把整個鏈路拆開哪一段是人類寫的、哪一段是 AI 寫的在服務(wù)端是已知的。這樣你能驗證提示詞對文本風(fēng)格的影響也能控制題目難度甚至后續(xù)可以把用戶答案收集成標注數(shù)據(jù)集。這個學(xué)習(xí)價值是單純調(diào)用檢測 API 給不了的。2. 系統(tǒng)設(shè)計與一回合的數(shù)據(jù)結(jié)構(gòu)2.1 模塊劃分整個服務(wù)按職責(zé)拆成五個模塊各自只處理一件事模塊職責(zé)關(guān)鍵技術(shù)點wikipedia_client獲取真實詞條摘要調(diào)用維基百科 REST API清洗 extractai_generator生成 AI 風(fēng)格同主題文本調(diào)用 OpenAI 兼容接口控制提示詞quiz_service組裝題目、洗牌、判題維護題目 ID、選項 ID、正解api 層暴露 HTTP 接口FastAPI 路由負責(zé)請求參數(shù)校驗前端展示題目、接收選擇原生 HTML/CSS/JSfetch 調(diào)用接口這樣拆分的好處是你可以單獨測試維基百科接口是否可用也可以單獨測試模型生成的文本質(zhì)量。如果以后要換成別的百科源或者別的模型只需要替換對應(yīng)模塊。2.2 一回合完整數(shù)據(jù)流先梳理清楚一次答題從開始到結(jié)束經(jīng)過哪些環(huán)節(jié)再寫代碼就不容易亂。用戶點擊“下一題”前端請求GET /api/quiz。后端調(diào)用維基百科隨機詞條接口拿到詞條標題和人類摘要。后端把標題和人類摘要發(fā)給大模型要求寫一段同主題百科簡介。后端把人類文本和 AI 文本打亂生成兩個選項并記錄哪個選項是 AI。把題目 ID、詞條標題、兩個選項文本返回前端。用戶選擇 A 或 B前端請求POST /api/answer。后端根據(jù)題目 ID 取出正解比較用戶選擇返回是否正確和當(dāng)前得分。注意第 3 步是最耗時的一步。大模型生成通常需要 1 到 5 秒所以接口設(shè)計時不要把“生成題目”和“判題”放在一個請求里做完而不考慮超時實際項目中可以拆成“創(chuàng)建題目”和“獲取結(jié)果”兩步或者先做異步生成。2.3 關(guān)鍵取舍題目實時生成還是預(yù)生成實時生成的優(yōu)點是不需要存儲大量題目每次請求都是新題缺點是用戶每次等待模型返回而且維基百科接口和模型接口任何一個抖動都會影響體驗。預(yù)生成的優(yōu)點是把耗時前置管理員提前批量生成 100 題存在數(shù)據(jù)庫里用戶打開頁面秒出題缺點是題目庫會陳舊而且生成成本固定。學(xué)習(xí)階段建議先做實時生成邏輯更直觀。等到產(chǎn)品需要穩(wěn)定體驗時再加一個本地緩存把生成過的題目存到 SQLite 或 Redis標題相同的題目直接復(fù)用。下面代碼都按實時生成的最小閉環(huán)來寫。3. 環(huán)境準備與依賴安裝3.1 運行環(huán)境要求開發(fā)環(huán)境建議使用 Python 3.10 及以上因為 FastAPI 和 Pydantic 的較新版本依賴新語法。操作系統(tǒng)不限Windows、macOS、Linux 都可以。依賴項如下表所示安裝時以你當(dāng)前環(huán)境能拉到的最新穩(wěn)定版本為準。依賴包作用fastapiWeb 框架提供 API 路由和參數(shù)校驗uvicornASGI 服務(wù)器用來啟動 FastAPIhttpx發(fā)起維基百科 HTTP 請求openai調(diào)用大模型接口的官方 SDKpython-dotenv讀取 .env 環(huán)境變量文件開發(fā)環(huán)境需要能訪問維基百科的 REST 接口以及你的模型供應(yīng)商接口。生產(chǎn)環(huán)境還要注意網(wǎng)絡(luò)策略、超時時間和密鑰管理這些在排錯一節(jié)會提到。3.2 項目結(jié)構(gòu)與依賴文件先建立項目目錄目錄結(jié)構(gòu)保持簡單方便后面擴展。ai-or-not-quiz/ ├── app.py # FastAPI 入口 ├── quiz/ │ ├── __init__.py │ ├── wikipedia_client.py # 維基百科摘要獲取 │ ├── ai_generator.py # AI 文本生成 │ ├── quiz_service.py # 題目組裝與判定 │ └── models.py # Pydantic 數(shù)據(jù)模型 ├── static/ │ ├── index.html │ ├── style.css │ └── app.js ├── requirements.txt ├── .env.example └── README.mdrequirements.txt 內(nèi)容如下fastapi uvicorn[standard] httpx openai python-dotenv安裝依賴pip install -r requirements.txt如果你的環(huán)境同時存在多個 Python 版本建議先創(chuàng)建虛擬環(huán)境再安裝python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtWindows 下激活虛擬環(huán)境命令是.venv\Scripts\activate注意區(qū)分。3.3 環(huán)境變量配置模型密鑰不能寫死在代碼里所以通過環(huán)境變量注入。新建.env文件內(nèi)容參考.env.exampleLLM_API_KEY你的模型APIKey LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你的大模型服務(wù)使用 OpenAI 兼容接口LLM_BASE_URL指向?qū)?yīng)服務(wù)地址即可。沒有填寫LLM_API_KEY時程序應(yīng)該能啟動但生成題目的接口返回明確錯誤而不是直接崩潰。4. 實現(xiàn)維基百科摘要獲取模塊4.1 選擇隨機詞條接口維基百科提供 REST API其中/page/random/summary可以直接拿到一個隨機詞條的摘要。這個接口的好處是響應(yīng)體已經(jīng)包含標題、摘要和頁面鏈接不需要再解析 HTML。實現(xiàn)quiz/wikipedia_client.pyimport httpx WIKIPEDIA_REST_BASE https://en.wikipedia.org/api/rest_v1 def fetch_random_article_summary() - dict: url f{WIKIPEDIA_REST_BASE}/page/random/summary headers {User-Agent: ai-or-not-quiz/0.1 (learning project)} with httpx.Client(timeout10.0, follow_redirectsTrue) as client: resp client.get(url, headersheaders) resp.raise_for_status() data resp.json() extract data.get(extract, ).strip() if not extract: raise ValueError(維基百科摘要為空請重新獲取) return { title: data.get(title, ), extract: extract, pageid: data.get(pageid), url: data.get(content_urls, {}).get(desktop, {}).get(page), }關(guān)鍵點timeout10.0防止請求長時間掛起。User-Agent要聲明項目名和用途維基百科文檔建議這樣做能降低被限流的概率。extract字段就是詞條開篇的純文本摘要默認已經(jīng)很干凈。如果想按指定主題出題可以使用按標題獲取摘要的接口from urllib.parse import quote def fetch_article_summary_by_title(title: str) - dict: encoded_title quote(title.replace( , _)) url f{WIKIPEDIA_REST_BASE}/page/summary/{encoded_title} # 后續(xù)邏輯與 fetch_random_article_summary 一致4.2 讀取和清洗 extract 字段extract雖然是純文本但直接使用時還要做三件事去掉首尾空格。控制長度。有些詞條摘要比較長超過 300 個單詞后用戶閱讀負擔(dān)會增加。判斷文本是否過短。如果摘要只有幾個單詞說明這個詞條可能質(zhì)量較低建議放棄并重新隨機。長度控制和異常處理可以合并成一個函數(shù)def normalize_extract(extract: str, max_chars: int 600) - str: text extract.strip().replace(\n, ) if len(text) 80: raise ValueError(摘要過短不適合作為題目) if len(text) max_chars: text text[:max_chars].rsplit( , 1)[0] ... return text這里用rsplit( , 1)在空格處截斷避免把一個單詞切成兩半。4.3 中英文詞條與語言切換基礎(chǔ)版本使用英文維基百科詞條覆蓋廣模型對英文百科風(fēng)格也更熟悉。想支持中文只需把域名換成https://zh.wikipedia.orgWIKIPEDIA_REST_BASE https://zh.wikipedia.org/api/rest_v1同時 AI 生成模塊的提示詞也要改成中文否則會出現(xiàn)“英文模型生成英文中文詞條生成中文”的語言錯位。建議把語言作為配置項不要寫死。5. AI 同主題文本生成模塊5.1 提示詞設(shè)計讓模型寫出“像維基百科”的文本提示詞決定題目難度。如果提示詞太弱AI 文本一眼就能看出來如果提示詞太強模型可能直接復(fù)制人類摘要用戶讀起來像同源文本。推薦提示詞要強調(diào)三點客觀語氣、獨立寫作、接近百科開篇的信息密度。SYSTEM_PROMPT 你是一名百科詞條編輯。請用客觀、中立的語氣寫一段關(guān)于指定主題的百科簡介。 要求 1. 全文 120 到 180 個英文單詞。 2. 不要使用“作為一個AI模型”“我不能”等表述。 3. 不要輸出標題直接輸出正文。 4. 不要復(fù)制參考文本而是基于主題獨立寫作。 5. 信息密度盡量接近維基百科的開篇段落。注意提示詞里明確“不要復(fù)制參考文本”是為了保證 AI 文本和人類文本不完全重復(fù)否則游戲會退化成“兩段內(nèi)容是否相同”而不是“風(fēng)格是否像 AI”。5.2 調(diào)用 OpenAI 兼容接口使用 openai 官方 SDK并支持通過base_url切換到其他兼容服務(wù)這是最常見的接入方式import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1), ) def generate_ai_extract(title: str, human_extract: str) - str: user_prompt ( f主題{title}\n f參考背景不要直接復(fù)制\n{human_extract[:500]}\n 請寫一段獨立的百科簡介。 ) resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.7, max_tokens300, ) text resp.choices[0].message.content.strip() if not text: raise ValueError(模型返回空文本) return text5.3 控制輸出長度和穩(wěn)定性大模型生成不是確定性的同一提示詞兩次結(jié)果可能不同。為了控制題目質(zhì)量需要理解幾個參數(shù)參數(shù)作用建議值調(diào)大影響調(diào)小影響temperature控制隨機性0.7文本更多樣可能跑題更穩(wěn)定但容易重復(fù)max_tokens限制最大輸出長度300可輸出更長文本可能截斷正文top_p采樣范圍默認即可更發(fā)散更保守如果題目需要“讓用戶更難猜”可以嘗試temperature0.9如果作為評測基準建議固定temperature0.3到0.5保證結(jié)果相對穩(wěn)定。實際中不要同時調(diào)大temperature和top_p會讓輸出不可控。6. 題目組裝與判定服務(wù)6.1 題目數(shù)據(jù)模型拿到兩段文本后把它們封裝成一個題目對象。用 Pydantic 定義模型方便接口層做響應(yīng)序列化。from pydantic import BaseModel class QuizOption(BaseModel): id: str text: str is_ai: bool class QuizQuestion(BaseModel): question_id: str title: str options: list[QuizOption] class QuizAnswer(BaseModel): question_id: str selected_id: stris_ai字段只存在于服務(wù)端真正返回給前端的時候要把它剝離否則用戶看一眼 JSON 就知道答案了。這里先講清楚模型接口層返回時再處理。6.2 隨機洗牌與答案記錄洗牌是保證游戲公平的關(guān)鍵。如果不洗牌AI 文本永遠固定在 A 或 B用戶連續(xù)玩幾次就能猜出規(guī)律。import random import uuid class QuizRound: def __init__(self, title: str, human_text: str, ai_text: str): self.question_id uuid.uuid4().hex self.title title self.options [ {id: A, text: human_text, is_ai: False}, {id: B, text: ai_text, is_ai: True}, ] random.shuffle(self.options) self.answer_id next( opt[id] for opt in self.options if opt[is_ai] ) def public_view(self) - dict: return { question_id: self.question_id, title: self.title, options: [ {id: opt[id], text: opt[text]} for opt in self.options ], } def check(self, selected_id: str) - bool: return selected_id self.answer_id這里用uuid生成題目 ID避免自增數(shù)字被用戶猜測。答案只保存在內(nèi)存對象里判題時按question_id取出。6.3 計分與會話管理最小閉環(huán)可以用內(nèi)存字典保存題目和分數(shù)簡單但不適合多進程部署class QuizStore: def __init__(self): self.rounds: dict[str, QuizRound] {} self.scores: dict[str, int] {} quiz_store QuizStore()生產(chǎn)環(huán)境需要把question_id和分數(shù)存到 Redis 或數(shù)據(jù)庫并且設(shè)置過期時間防止內(nèi)存無限增長。學(xué)習(xí)階段用內(nèi)存即可但要清楚重啟服務(wù)后所有數(shù)據(jù)會丟失。7. FastAPI 接口實現(xiàn)7.1 接口設(shè)計接口設(shè)計要遵循一個原則用戶只拿到必要信息服務(wù)端保留答案和分數(shù)。接口方法請求參數(shù)返回內(nèi)容/api/quizGET無題目 ID、標題、兩個選項文本/api/answerPOSTquestion_id, selected_id是否正確、正解選項 ID、當(dāng)前分數(shù)/GET無前端頁面沒必要把“生成題目”和“獲取正解”放在同一個接口里那樣用戶可以直接通過網(wǎng)絡(luò)請求看到答案字段。7.2 核心接口代碼實現(xiàn)app.pyimport os from dotenv import load_dotenv from fastapi import FastAPI, HTTPException from fastapi.staticfiles import StaticFiles from quiz.ai_generator import generate_ai_extract from quiz.models import QuizAnswer, QuizQuestion from quiz.quiz_service import QuizRound, QuizStore from quiz.wikipedia_client import ( fetch_random_article_summary, normalize_extract, ) load_dotenv() app FastAPI(titleAI or Not Quiz) store QuizStore() app.mount(/static, StaticFiles(directorystatic), namestatic) app.get(/api/quiz) def create_quiz(): try: article fetch_random_article_summary() human_text normalize_extract(article[extract]) ai_text generate_ai_extract(article[title], human_text) except Exception as exc: # 這里要記錄完整異常到日志給用戶的提示保持簡潔 raise HTTPException(status_code503, detailf題目生成失敗: {exc}) round_obj QuizRound(article[title], human_text, ai_text) store.rounds[round_obj.question_id] round_obj return round_obj.public_view() app.post(/api/answer) def submit_answer(answer: QuizAnswer): round_obj store.rounds.get(answer.question_id) if round_obj is None: raise HTTPException(status_code404, detail題目不存在或已過期) correct round_obj.check(answer.selected_id) if correct: store.scores[default_user] store.scores.get(default_user, 0) 1 return { correct: correct, answer_id: round_obj.answer_id, score: store.scores.get(default_user, 0), }注意generate_ai_extract和fetch_random_article_summary都是同步阻塞調(diào)用FastAPI 的異步事件循環(huán)會被阻塞。學(xué)習(xí)項目里問題不大但并發(fā)上來后要改成async或放入線程池。這一點在最佳實踐里會再強調(diào)。7.3 請求與響應(yīng)示例創(chuàng)建題目curl http://127.0.0.1:8000/api/quiz響應(yīng)示例{ question_id: 3f9a1c2e8b6d4f0a9e7c1a2b3c4d5e6f, title: Machine learning, options: [ { id: A, text: Machine learning is a field ... }, { id: B, text: Machine learning (ML) is a field of study ... } ] }提交答案curl -X POST http://127.0.0.1:8000/api/answer \ -H Content-Type: application/json \ -d {question_id: 3f9a1c2e8b6d4f0a9e7c1a2b3c4d5e6f, selected_id: B}響應(yīng)示例{ correct: true, answer_id: B, score: 1 }8. 前端交互頁面8.1 頁面結(jié)構(gòu)前端保持極簡負責(zé)三件事拉取題目、展示兩個選項、提交答案。static/index.html核心結(jié)構(gòu)如下!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleAI or Not Quiz/title link relstylesheet href/static/style.css /head body main h1哪一段文字是 AI 寫的/h1 p idtitle加載中.../p div idoptions/div p idresult/p button idnext styledisplay:none;下一題/button /main script src/static/app.js/script /body /html8.2 用 fetch 調(diào)用接口static/app.js實現(xiàn)加載題目和提交答案const titleEl document.getElementById(title); const optionsEl document.getElementById(options); const resultEl document.getElementById(result); const nextBtn document.getElementById(next); let currentQuestionId null; async function loadQuiz() { resultEl.textContent ; nextBtn.style.display none; optionsEl.innerHTML ; const resp await fetch(/api/quiz); const data await resp.json(); currentQuestionId data.question_id; titleEl.textContent data.title; data.options.forEach((opt) { const card document.createElement(button); card.className option; card.textContent opt.text; card.onclick () submitAnswer(opt.id); optionsEl.appendChild(card); }); } async function submitAnswer(selectedId) { const resp await fetch(/api/answer, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ question_id: currentQuestionId, selected_id: selectedId, }), }); const data await resp.json(); if (data.correct) { resultEl.textContent 答對了正解是 ${data.answer_id}當(dāng)前得分 ${data.score}; } else { resultEl.textContent 答錯了正解是 ${data.answer_id}當(dāng)前得分 ${data.score}; } nextBtn.style.display block; } nextBtn.onclick loadQuiz; loadQuiz();這里把選項渲染成按鈕點擊后立即提交。更完整的版本應(yīng)該在高亮選項后再提交避免用戶誤觸。8.3 反饋與下一題邏輯判題之后要同時展示“是否正確”和“正解是哪一個”否則用戶只能盲目猜。下一題按鈕復(fù)用loadQuiz重新請求新題。學(xué)習(xí)階段可以不考慮用戶體系分數(shù)默認記在內(nèi)存里的固定 key 上。需要區(qū)分用戶時可以引入 session_id 或 JWT把分數(shù)綁定到具體用戶。9. 運行驗證與結(jié)果質(zhì)量分析9.1 啟動與本地驗證啟動服務(wù)uvicorn app:app --reload --port 8000啟動成功的標志是控制臺輸出類似Uvicorn running on http://127.0.0.1:8000。瀏覽器打開http://127.0.0.1:8000/應(yīng)該能看到頁面。建議按下面順序做冒煙測試單獨請求維基百科接口確認外網(wǎng)可訪問。單獨調(diào)用generate_ai_extract確認模型 Key 有效。請求/api/quiz確認返回兩個選項且文本不重復(fù)。提交一個錯誤答案和一個正確答案確認判定正確。刷新頁面連續(xù)玩 10 題確認沒有明顯報錯。9.2 curl 驗證接口返回直接依賴瀏覽器調(diào)試有時看不到完整報錯配合 curl 更高效curl -i http://127.0.0.1:8000/api/quiz用-i能同時看到 HTTP 狀態(tài)碼和響應(yīng)體。如果返回 503說明題目的某個上游服務(wù)出了問題查看服務(wù)端日志定位是維基百科超時還是模型返回空。9.3 判斷題目質(zhì)量的檢查清單“能跑”不等于“題目能玩”。每生成一題建議按以下清單檢查[ ] 兩段文本長度是否接近避免用戶靠長度猜測。[ ] AI 文本是否出現(xiàn)“作為一個 AI”“我不能”這類提示詞痕跡。[ ] AI 文本是否復(fù)述了人類文本的大段原句。[ ] 詞條標題是否過于生僻用戶完全無法判斷。[ ] 隨機詞條是否重復(fù)出現(xiàn)游戲后期是否疲勞。[ ] 模型返回是否偶發(fā)截斷截斷后選項是否殘缺。其中“AI 文本是否復(fù)述原句”是最常出現(xiàn)的問題。如果復(fù)述嚴重說明提示詞的“不要復(fù)制參考文本”約束不夠需要加強或者在生成后用文本相似度做過濾。10. 常見問題與排查路徑10.1 常見問題速查表問題現(xiàn)象常見原因檢查方式處理建議/api/quiz 返回 503維基百科接口超時或模型 Key 無效單獨 curl 維基百科接口單獨調(diào)用模型 SDK 示例檢查網(wǎng)絡(luò)、密鑰、模型名加超時和重試兩個選項文本幾乎一樣模型復(fù)制了參考文本對比兩段文本相似度查看提示詞在提示詞中加強“獨立寫作”約束或過濾高相似度結(jié)果AI 文本明顯帶“AI 痕跡”提示詞沒有禁用口語化表達查看生成文本增加禁用句式提高 temperature模型返回被截斷max_tokens 太小查看響應(yīng)里的 finish_reason調(diào)大 max_tokens或檢測截斷后重新生成刷新頁面后分數(shù)丟失分數(shù)存在內(nèi)存檢查存儲位置學(xué)習(xí)階段可接受生產(chǎn)環(huán)境改用 Redis 或數(shù)據(jù)庫請求 /api/quiz 很慢模型生成是同步阻塞調(diào)用觀察日志耗時改成異步生成或預(yù)生成題目隨機詞條重復(fù)出現(xiàn)維基百科隨機接口沒有去重記錄最近題目標題維護一個已用過標題的隊列臨時跳過10.2 從現(xiàn)象到根因的排查順序遇到問題不要先看最后一行堆棧按下面順序排查確認請求本身沒問題路徑和參數(shù)正確。確認上游依賴可用維基百科接口、模型接口。確認環(huán)境變量已加載.env文件路徑正確。查看服務(wù)端完整日志識別是網(wǎng)絡(luò)報錯、鑒權(quán)報錯還是模型響應(yīng)格式問題。用最小腳本單獨復(fù)現(xiàn)問題隔離模塊。如果只是偶發(fā)問題考慮超時和重試策略而不是改提示詞。例如“題目生成失敗”是一個非常粗的報錯必須把原始異常記錄到日志里。給用戶的 detail 保持簡潔但服務(wù)端日志要能定位到是httpx.ConnectTimeout還是openai.AuthenticationError。11. 生產(chǎn)化最佳實踐與擴展方向11.1 工程化建議清單學(xué)習(xí)項目跑通后如果要把它做成真正可用的服務(wù)建議對照下面的清單補強[ ] 模型 Key 統(tǒng)一從環(huán)境變量或密鑰管理系統(tǒng)讀取不要提交到代碼倉庫。[ ] 維基百科和模型接口都設(shè)置超時和重試并區(qū)分“不可重試”的錯誤類型。[ ] 題目和答案不要混在同一個存儲里答案字段不返回給前端。[ ] 用異步方式處理耗時操作避免阻塞 FastAPI 事件循環(huán)。[ ] 建立基本日志體系記錄請求耗時、上游錯誤、生成文本長度。[ ] 對生成文本做基礎(chǔ)過濾檢測空文本、敏感詞、超長文本。[ ] 為已生成的題目增加緩存減少重復(fù)請求模型。[ ] 增加簡單限流防止隨機詞條接口和模型接口被高頻調(diào)用。其中“答案字段不返回給前端”是這類產(chǎn)品最容易踩的坑。前端調(diào)試時可以查看網(wǎng)絡(luò)響應(yīng)如果響應(yīng)里帶is_ai: true玩家直接看開發(fā)者工具就能作弊。11.2 可以擴展的方向這個項目可以從一個答題游戲擴展成多個方向的工程實踐標注平臺把“用戶判斷是否正確”收集起來形成人工標注數(shù)據(jù)集用于訓(xùn)練或評估文本分類器。模型評測工具固定一批維基百科詞條讓不同模型生成同主題文本比較哪個模型更容易被用戶識別為 AI。AI Agent 能力測試把“生成百科簡介”封裝成一個 Agent 工具調(diào)用觀察不同提示詞策略下的效果差異。AI 幻覺觀察器對生成文本做事實校驗標記出與維基百科原文不一致的地方幫助理解大模型的幻覺問題。前后端功能增強加入用戶登錄、排行榜、題目歷史、多語言支持。如果希望把生成和判題做成更通用的能力可以借鑒 Spring AI 這類框架的模塊化思路把模型供應(yīng)商、提示詞模板和任務(wù)鏈路解耦。小項目不需要一步到位但模塊邊界一開始就要清楚。11.3 一點學(xué)習(xí)建議把“AI or Not”做完真正值得記住的不是代碼本身而是幾個判斷第一AI 應(yīng)用不能只關(guān)心“模型能不能生成”更要關(guān)心生成結(jié)果如何進入業(yè)務(wù)鏈路、如何驗證、如何兜底。第二兩段文本對比是一個非常直觀的評測方式它比“AI 檢測率 90%”這類數(shù)字更能說明問題。第三一個最小閉環(huán)比一個宏偉架構(gòu)更有學(xué)習(xí)價值先把 500 行代碼跑通再去考慮異步、緩存、Kubernetes 這些生產(chǎn)化能力。如果自己已經(jīng)能獨立完成這個項目下一步可以試著不依賴維基百科換成自己的文檔庫或博客語料做一套“識別 AI 改寫內(nèi)容”的內(nèi)部工具。你會發(fā)現(xiàn)核心難點從“接 API”變成了“定義什么才算 AI 風(fēng)格”那才是這個領(lǐng)域真正值得深挖的地方。