做一個“AI or Not”式的維基百科答題小游戲核心并不是把兩段文本并排展示給用戶那么簡單。真正的工程鏈路是先從維基百科取到人類編輯撰寫的真實詞條摘要再調用大模型生成同一主題的“AI 風格”文本最后把兩段文本隨機打亂讓用戶判斷哪一段來自 AI判完立刻給反饋并記錄得分。這類小游戲在 AI 應用開發里很有代表性。它不依賴高成本數據和復雜模型只需要把維基百科 API、大模型接口和基礎前后端組織起來就能形成一個可交互、可演示、可擴展的完整產品。背后涉及的問題包括如何區分人寫文本和模型生成文本、大模型提示詞如何穩定輸出、接口異常如何降級、以及這類能力在內容標注和模型評測中怎么用。適合讀者想用大模型做一個真實可玩項目的開發者正在學習 FastAPI 或 Python 后端的前端工程師以及對 AI 應用好奇的產品經理。全文會帶你把服務完整搭起來從環境準備到接口調試最后給出常見問題排查和生產化建議。1. 為什么用“維基百科文本”來做 AI 檢測游戲1.1 這個游戲到底在測什么“AI or Not”類游戲表面上是在測用戶實際上是在測模型和文本風格。人類寫的維基百科詞條開篇通常追求信息密度句子緊湊結構穩定習慣先給定義再展開背景。大模型生成的文本雖然表面上也有百科風格但細節上容易出現幾種可感知的特征喜歡用“值得注意的是”“在當今時代”這類過渡句。信息密度偏低一句話能說完的內容會擴展成三句。偶爾出現事實錯誤也就是 AI 幻覺。語言非?！捌骄比狈€人編輯帶來的句式變化。所以游戲判斷的不只是內容真假而是文本風格、信息密度和事實準確性。用戶答對之后如果能看到模型原文和人類原文的差異就天然理解了一次 AI 文本生成的特點。1.2 維基百科作為題目源的四個優勢選擇維基百科而不是自己積累語料是因為它提供的題目源是現成、穩定且合法的。優勢說明數據現成REST API 直接返回詞條摘要不需要自己抓網頁洗數據覆蓋話題廣隨機詞條可以覆蓋技術、歷史、地理、人物等多類主題質量有保證詞條經過多輪編輯開篇摘要相對規范適合作為“人類文本”基準內容協議清楚維基百科內容遵循開放許可做學習項目和產品原型時更容易說清來源對學習項目來說這意味著你可以把大部分精力放在題目邏輯和 AI 生成上而不是花一整周去清洗語料。1.3 為什么不是直接調用現成 AI 檢測服務市面上有商用 AI 檢測服務也能看到“某段文本是人類寫的還是 AI 寫的”的概率分數。但如果項目只用現成檢測 API你就無法控制題目生成過程也無法解釋檢測結果背后的邏輯。更重要的是檢測服務通常只給一個概率用戶不知道這個概率是怎么來的。自己實現“人類文本 AI 生成文本”的組合等于把整個鏈路拆開哪一段是人類寫的、哪一段是 AI 寫的在服務端是已知的。這樣你能驗證提示詞對文本風格的影響也能控制題目難度甚至后續可以把用戶答案收集成標注數據集。這個學習價值是單純調用檢測 API 給不了的。2. 系統設計與一回合的數據結構2.1 模塊劃分整個服務按職責拆成五個模塊各自只處理一件事模塊職責關鍵技術點wikipedia_client獲取真實詞條摘要調用維基百科 REST API清洗 extractai_generator生成 AI 風格同主題文本調用 OpenAI 兼容接口控制提示詞quiz_service組裝題目、洗牌、判題維護題目 ID、選項 ID、正解api 層暴露 HTTP 接口FastAPI 路由負責請求參數校驗前端展示題目、接收選擇原生 HTML/CSS/JSfetch 調用接口這樣拆分的好處是你可以單獨測試維基百科接口是否可用也可以單獨測試模型生成的文本質量。如果以后要換成別的百科源或者別的模型只需要替換對應模塊。2.2 一回合完整數據流先梳理清楚一次答題從開始到結束經過哪些環節再寫代碼就不容易亂。用戶點擊“下一題”前端請求GET /api/quiz。后端調用維基百科隨機詞條接口拿到詞條標題和人類摘要。后端把標題和人類摘要發給大模型要求寫一段同主題百科簡介。后端把人類文本和 AI 文本打亂生成兩個選項并記錄哪個選項是 AI。把題目 ID、詞條標題、兩個選項文本返回前端。用戶選擇 A 或 B前端請求POST /api/answer。后端根據題目 ID 取出正解比較用戶選擇返回是否正確和當前得分。注意第 3 步是最耗時的一步。大模型生成通常需要 1 到 5 秒所以接口設計時不要把“生成題目”和“判題”放在一個請求里做完而不考慮超時實際項目中可以拆成“創建題目”和“獲取結果”兩步或者先做異步生成。2.3 關鍵取舍題目實時生成還是預生成實時生成的優點是不需要存儲大量題目每次請求都是新題缺點是用戶每次等待模型返回而且維基百科接口和模型接口任何一個抖動都會影響體驗。預生成的優點是把耗時前置管理員提前批量生成 100 題存在數據庫里用戶打開頁面秒出題缺點是題目庫會陳舊而且生成成本固定。學習階段建議先做實時生成邏輯更直觀。等到產品需要穩定體驗時再加一個本地緩存把生成過的題目存到 SQLite 或 Redis標題相同的題目直接復用。下面代碼都按實時生成的最小閉環來寫。3. 環境準備與依賴安裝3.1 運行環境要求開發環境建議使用 Python 3.10 及以上因為 FastAPI 和 Pydantic 的較新版本依賴新語法。操作系統不限Windows、macOS、Linux 都可以。依賴項如下表所示安裝時以你當前環境能拉到的最新穩定版本為準。依賴包作用fastapiWeb 框架提供 API 路由和參數校驗uvicornASGI 服務器用來啟動 FastAPIhttpx發起維基百科 HTTP 請求openai調用大模型接口的官方 SDKpython-dotenv讀取 .env 環境變量文件開發環境需要能訪問維基百科的 REST 接口以及你的模型供應商接口。生產環境還要注意網絡策略、超時時間和密鑰管理這些在排錯一節會提到。3.2 項目結構與依賴文件先建立項目目錄目錄結構保持簡單方便后面擴展。ai-or-not-quiz/ ├── app.py # FastAPI 入口 ├── quiz/ │ ├── __init__.py │ ├── wikipedia_client.py # 維基百科摘要獲取 │ ├── ai_generator.py # AI 文本生成 │ ├── quiz_service.py # 題目組裝與判定 │ └── models.py # Pydantic 數據模型 ├── static/ │ ├── index.html │ ├── style.css │ └── app.js ├── requirements.txt ├── .env.example └── README.mdrequirements.txt 內容如下fastapi uvicorn[standard] httpx openai python-dotenv安裝依賴pip install -r requirements.txt如果你的環境同時存在多個 Python 版本建議先創建虛擬環境再安裝python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtWindows 下激活虛擬環境命令是.venv\Scripts\activate注意區分。3.3 環境變量配置模型密鑰不能寫死在代碼里所以通過環境變量注入。新建.env文件內容參考.env.exampleLLM_API_KEY你的模型APIKey LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你的大模型服務使用 OpenAI 兼容接口LLM_BASE_URL指向對應服務地址即可。沒有填寫LLM_API_KEY時程序應該能啟動但生成題目的接口返回明確錯誤而不是直接崩潰。4. 實現維基百科摘要獲取模塊4.1 選擇隨機詞條接口維基百科提供 REST API其中/page/random/summary可以直接拿到一個隨機詞條的摘要。這個接口的好處是響應體已經包含標題、摘要和頁面鏈接不需要再解析 HTML。實現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), }關鍵點timeout10.0防止請求長時間掛起。User-Agent要聲明項目名和用途維基百科文檔建議這樣做能降低被限流的概率。extract字段就是詞條開篇的純文本摘要默認已經很干凈。如果想按指定主題出題可以使用按標題獲取摘要的接口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} # 后續邏輯與 fetch_random_article_summary 一致4.2 讀取和清洗 extract 字段extract雖然是純文本但直接使用時還要做三件事去掉首尾空格?？刂崎L度。有些詞條摘要比較長超過 300 個單詞后用戶閱讀負擔會增加。判斷文本是否過短。如果摘要只有幾個單詞說明這個詞條可能質量較低建議放棄并重新隨機。長度控制和異常處理可以合并成一個函數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 中英文詞條與語言切換基礎版本使用英文維基百科詞條覆蓋廣模型對英文百科風格也更熟悉。想支持中文只需把域名換成https://zh.wikipedia.orgWIKIPEDIA_REST_BASE https://zh.wikipedia.org/api/rest_v1同時 AI 生成模塊的提示詞也要改成中文否則會出現“英文模型生成英文中文詞條生成中文”的語言錯位。建議把語言作為配置項不要寫死。5. AI 同主題文本生成模塊5.1 提示詞設計讓模型寫出“像維基百科”的文本提示詞決定題目難度。如果提示詞太弱AI 文本一眼就能看出來如果提示詞太強模型可能直接復制人類摘要用戶讀起來像同源文本。推薦提示詞要強調三點客觀語氣、獨立寫作、接近百科開篇的信息密度。SYSTEM_PROMPT 你是一名百科詞條編輯。請用客觀、中立的語氣寫一段關于指定主題的百科簡介。 要求 1. 全文 120 到 180 個英文單詞。 2. 不要使用“作為一個AI模型”“我不能”等表述。 3. 不要輸出標題直接輸出正文。 4. 不要復制參考文本而是基于主題獨立寫作。 5. 信息密度盡量接近維基百科的開篇段落。注意提示詞里明確“不要復制參考文本”是為了保證 AI 文本和人類文本不完全重復否則游戲會退化成“兩段內容是否相同”而不是“風格是否像 AI”。5.2 調用 OpenAI 兼容接口使用 openai 官方 SDK并支持通過base_url切換到其他兼容服務這是最常見的接入方式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參考背景不要直接復制\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 控制輸出長度和穩定性大模型生成不是確定性的同一提示詞兩次結果可能不同。為了控制題目質量需要理解幾個參數參數作用建議值調大影響調小影響temperature控制隨機性0.7文本更多樣可能跑題更穩定但容易重復max_tokens限制最大輸出長度300可輸出更長文本可能截斷正文top_p采樣范圍默認即可更發散更保守如果題目需要“讓用戶更難猜”可以嘗試temperature0.9如果作為評測基準建議固定temperature0.3到0.5保證結果相對穩定。實際中不要同時調大temperature和top_p會讓輸出不可控。6. 題目組裝與判定服務6.1 題目數據模型拿到兩段文本后把它們封裝成一個題目對象。用 Pydantic 定義模型方便接口層做響應序列化。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字段只存在于服務端真正返回給前端的時候要把它剝離否則用戶看一眼 JSON 就知道答案了。這里先講清楚模型接口層返回時再處理。6.2 隨機洗牌與答案記錄洗牌是保證游戲公平的關鍵。如果不洗牌AI 文本永遠固定在 A 或 B用戶連續玩幾次就能猜出規律。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避免自增數字被用戶猜測。答案只保存在內存對象里判題時按question_id取出。6.3 計分與會話管理最小閉環可以用內存字典保存題目和分數簡單但不適合多進程部署class QuizStore: def __init__(self): self.rounds: dict[str, QuizRound] {} self.scores: dict[str, int] {} quiz_store QuizStore()生產環境需要把question_id和分數存到 Redis 或數據庫并且設置過期時間防止內存無限增長。學習階段用內存即可但要清楚重啟服務后所有數據會丟失。7. FastAPI 接口實現7.1 接口設計接口設計要遵循一個原則用戶只拿到必要信息服務端保留答案和分數。接口方法請求參數返回內容/api/quizGET無題目 ID、標題、兩個選項文本/api/answerPOSTquestion_id, selected_id是否正確、正解選項 ID、當前分數/GET無前端頁面沒必要把“生成題目”和“獲取正解”放在同一個接口里那樣用戶可以直接通過網絡請求看到答案字段。7.2 核心接口代碼實現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都是同步阻塞調用FastAPI 的異步事件循環會被阻塞。學習項目里問題不大但并發上來后要改成async或放入線程池。這一點在最佳實踐里會再強調。7.3 請求與響應示例創建題目curl http://127.0.0.1:8000/api/quiz響應示例{ 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}響應示例{ correct: true, answer_id: B, score: 1 }8. 前端交互頁面8.1 頁面結構前端保持極簡負責三件事拉取題目、展示兩個選項、提交答案。static/index.html核心結構如下!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 調用接口static/app.js實現加載題目和提交答案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}當前得分 ${data.score}; } else { resultEl.textContent 答錯了正解是 ${data.answer_id}當前得分 ${data.score}; } nextBtn.style.display block; } nextBtn.onclick loadQuiz; loadQuiz();這里把選項渲染成按鈕點擊后立即提交。更完整的版本應該在高亮選項后再提交避免用戶誤觸。8.3 反饋與下一題邏輯判題之后要同時展示“是否正確”和“正解是哪一個”否則用戶只能盲目猜。下一題按鈕復用loadQuiz重新請求新題。學習階段可以不考慮用戶體系分數默認記在內存里的固定 key 上。需要區分用戶時可以引入 session_id 或 JWT把分數綁定到具體用戶。9. 運行驗證與結果質量分析9.1 啟動與本地驗證啟動服務uvicorn app:app --reload --port 8000啟動成功的標志是控制臺輸出類似Uvicorn running on http://127.0.0.1:8000。瀏覽器打開http://127.0.0.1:8000/應該能看到頁面。建議按下面順序做冒煙測試單獨請求維基百科接口確認外網可訪問。單獨調用generate_ai_extract確認模型 Key 有效。請求/api/quiz確認返回兩個選項且文本不重復。提交一個錯誤答案和一個正確答案確認判定正確。刷新頁面連續玩 10 題確認沒有明顯報錯。9.2 curl 驗證接口返回直接依賴瀏覽器調試有時看不到完整報錯配合 curl 更高效curl -i http://127.0.0.1:8000/api/quiz用-i能同時看到 HTTP 狀態碼和響應體。如果返回 503說明題目的某個上游服務出了問題查看服務端日志定位是維基百科超時還是模型返回空。9.3 判斷題目質量的檢查清單“能跑”不等于“題目能玩”。每生成一題建議按以下清單檢查[ ] 兩段文本長度是否接近避免用戶靠長度猜測。[ ] AI 文本是否出現“作為一個 AI”“我不能”這類提示詞痕跡。[ ] AI 文本是否復述了人類文本的大段原句。[ ] 詞條標題是否過于生僻用戶完全無法判斷。[ ] 隨機詞條是否重復出現游戲后期是否疲勞。[ ] 模型返回是否偶發截斷截斷后選項是否殘缺。其中“AI 文本是否復述原句”是最常出現的問題。如果復述嚴重說明提示詞的“不要復制參考文本”約束不夠需要加強或者在生成后用文本相似度做過濾。10. 常見問題與排查路徑10.1 常見問題速查表問題現象常見原因檢查方式處理建議/api/quiz 返回 503維基百科接口超時或模型 Key 無效單獨 curl 維基百科接口單獨調用模型 SDK 示例檢查網絡、密鑰、模型名加超時和重試兩個選項文本幾乎一樣模型復制了參考文本對比兩段文本相似度查看提示詞在提示詞中加強“獨立寫作”約束或過濾高相似度結果AI 文本明顯帶“AI 痕跡”提示詞沒有禁用口語化表達查看生成文本增加禁用句式提高 temperature模型返回被截斷max_tokens 太小查看響應里的 finish_reason調大 max_tokens或檢測截斷后重新生成刷新頁面后分數丟失分數存在內存檢查存儲位置學習階段可接受生產環境改用 Redis 或數據庫請求 /api/quiz 很慢模型生成是同步阻塞調用觀察日志耗時改成異步生成或預生成題目隨機詞條重復出現維基百科隨機接口沒有去重記錄最近題目標題維護一個已用過標題的隊列臨時跳過10.2 從現象到根因的排查順序遇到問題不要先看最后一行堆棧按下面順序排查確認請求本身沒問題路徑和參數正確。確認上游依賴可用維基百科接口、模型接口。確認環境變量已加載.env文件路徑正確。查看服務端完整日志識別是網絡報錯、鑒權報錯還是模型響應格式問題。用最小腳本單獨復現問題隔離模塊。如果只是偶發問題考慮超時和重試策略而不是改提示詞。例如“題目生成失敗”是一個非常粗的報錯必須把原始異常記錄到日志里。給用戶的 detail 保持簡潔但服務端日志要能定位到是httpx.ConnectTimeout還是openai.AuthenticationError。11. 生產化最佳實踐與擴展方向11.1 工程化建議清單學習項目跑通后如果要把它做成真正可用的服務建議對照下面的清單補強[ ] 模型 Key 統一從環境變量或密鑰管理系統讀取不要提交到代碼倉庫。[ ] 維基百科和模型接口都設置超時和重試并區分“不可重試”的錯誤類型。[ ] 題目和答案不要混在同一個存儲里答案字段不返回給前端。[ ] 用異步方式處理耗時操作避免阻塞 FastAPI 事件循環。[ ] 建立基本日志體系記錄請求耗時、上游錯誤、生成文本長度。[ ] 對生成文本做基礎過濾檢測空文本、敏感詞、超長文本。[ ] 為已生成的題目增加緩存減少重復請求模型。[ ] 增加簡單限流防止隨機詞條接口和模型接口被高頻調用。其中“答案字段不返回給前端”是這類產品最容易踩的坑。前端調試時可以查看網絡響應如果響應里帶is_ai: true玩家直接看開發者工具就能作弊。11.2 可以擴展的方向這個項目可以從一個答題游戲擴展成多個方向的工程實踐標注平臺把“用戶判斷是否正確”收集起來形成人工標注數據集用于訓練或評估文本分類器。模型評測工具固定一批維基百科詞條讓不同模型生成同主題文本比較哪個模型更容易被用戶識別為 AI。AI Agent 能力測試把“生成百科簡介”封裝成一個 Agent 工具調用觀察不同提示詞策略下的效果差異。AI 幻覺觀察器對生成文本做事實校驗標記出與維基百科原文不一致的地方幫助理解大模型的幻覺問題。前后端功能增強加入用戶登錄、排行榜、題目歷史、多語言支持。如果希望把生成和判題做成更通用的能力可以借鑒 Spring AI 這類框架的模塊化思路把模型供應商、提示詞模板和任務鏈路解耦。小項目不需要一步到位但模塊邊界一開始就要清楚。11.3 一點學習建議把“AI or Not”做完真正值得記住的不是代碼本身而是幾個判斷第一AI 應用不能只關心“模型能不能生成”更要關心生成結果如何進入業務鏈路、如何驗證、如何兜底。第二兩段文本對比是一個非常直觀的評測方式它比“AI 檢測率 90%”這類數字更能說明問題。第三一個最小閉環比一個宏偉架構更有學習價值先把 500 行代碼跑通再去考慮異步、緩存、Kubernetes 這些生產化能力。如果自己已經能獨立完成這個項目下一步可以試著不依賴維基百科換成自己的文檔庫或博客語料做一套“識別 AI 改寫內容”的內部工具。你會發現核心難點從“接 API”變成了“定義什么才算 AI 風格”那才是這個領域真正值得深挖的地方。 AI文本檢測實戰：用維基百科和大模型構建辨別游戲
做一個“AI or Not”式的維基百科答題小游戲核心并不是把兩段文本并排展示給用戶那么簡單。真正的工程鏈路是先從維基百科取到人類編輯撰寫的真實詞條摘要再調用大模型生成同一主題的“AI 風格”文本最后把兩段文本隨機打亂讓用戶判斷哪一段來自 AI判完立刻給反饋并記錄得分。這類小游戲在 AI 應用開發里很有代表性。它不依賴高成本數據和復雜模型只需要把維基百科 API、大模型接口和基礎前后端組織起來就能形成一個可交互、可演示、可擴展的完整產品。背后涉及的問題包括如何區分人寫文本和模型生成文本、大模型提示詞如何穩定輸出、接口異常如何降級、以及這類能力在內容標注和模型評測中怎么用。適合讀者想用大模型做一個真實可玩項目的開發者正在學習 FastAPI 或 Python 后端的前端工程師以及對 AI 應用好奇的產品經理。全文會帶你把服務完整搭起來從環境準備到接口調試最后給出常見問題排查和生產化建議。1. 為什么用“維基百科文本”來做 AI 檢測游戲1.1 這個游戲到底在測什么“AI or Not”類游戲表面上是在測用戶實際上是在測模型和文本風格。人類寫的維基百科詞條開篇通常追求信息密度句子緊湊結構穩定習慣先給定義再展開背景。大模型生成的文本雖然表面上也有百科風格但細節上容易出現幾種可感知的特征喜歡用“值得注意的是”“在當今時代”這類過渡句。信息密度偏低一句話能說完的內容會擴展成三句。偶爾出現事實錯誤也就是 AI 幻覺。語言非?！捌骄比狈€人編輯帶來的句式變化。所以游戲判斷的不只是內容真假而是文本風格、信息密度和事實準確性。用戶答對之后如果能看到模型原文和人類原文的差異就天然理解了一次 AI 文本生成的特點。1.2 維基百科作為題目源的四個優勢選擇維基百科而不是自己積累語料是因為它提供的題目源是現成、穩定且合法的。優勢說明數據現成REST API 直接返回詞條摘要不需要自己抓網頁洗數據覆蓋話題廣隨機詞條可以覆蓋技術、歷史、地理、人物等多類主題質量有保證詞條經過多輪編輯開篇摘要相對規范適合作為“人類文本”基準內容協議清楚維基百科內容遵循開放許可做學習項目和產品原型時更容易說清來源對學習項目來說這意味著你可以把大部分精力放在題目邏輯和 AI 生成上而不是花一整周去清洗語料。1.3 為什么不是直接調用現成 AI 檢測服務市面上有商用 AI 檢測服務也能看到“某段文本是人類寫的還是 AI 寫的”的概率分數。但如果項目只用現成檢測 API你就無法控制題目生成過程也無法解釋檢測結果背后的邏輯。更重要的是檢測服務通常只給一個概率用戶不知道這個概率是怎么來的。自己實現“人類文本 AI 生成文本”的組合等于把整個鏈路拆開哪一段是人類寫的、哪一段是 AI 寫的在服務端是已知的。這樣你能驗證提示詞對文本風格的影響也能控制題目難度甚至后續可以把用戶答案收集成標注數據集。這個學習價值是單純調用檢測 API 給不了的。2. 系統設計與一回合的數據結構2.1 模塊劃分整個服務按職責拆成五個模塊各自只處理一件事模塊職責關鍵技術點wikipedia_client獲取真實詞條摘要調用維基百科 REST API清洗 extractai_generator生成 AI 風格同主題文本調用 OpenAI 兼容接口控制提示詞quiz_service組裝題目、洗牌、判題維護題目 ID、選項 ID、正解api 層暴露 HTTP 接口FastAPI 路由負責請求參數校驗前端展示題目、接收選擇原生 HTML/CSS/JSfetch 調用接口這樣拆分的好處是你可以單獨測試維基百科接口是否可用也可以單獨測試模型生成的文本質量。如果以后要換成別的百科源或者別的模型只需要替換對應模塊。2.2 一回合完整數據流先梳理清楚一次答題從開始到結束經過哪些環節再寫代碼就不容易亂。用戶點擊“下一題”前端請求GET /api/quiz。后端調用維基百科隨機詞條接口拿到詞條標題和人類摘要。后端把標題和人類摘要發給大模型要求寫一段同主題百科簡介。后端把人類文本和 AI 文本打亂生成兩個選項并記錄哪個選項是 AI。把題目 ID、詞條標題、兩個選項文本返回前端。用戶選擇 A 或 B前端請求POST /api/answer。后端根據題目 ID 取出正解比較用戶選擇返回是否正確和當前得分。注意第 3 步是最耗時的一步。大模型生成通常需要 1 到 5 秒所以接口設計時不要把“生成題目”和“判題”放在一個請求里做完而不考慮超時實際項目中可以拆成“創建題目”和“獲取結果”兩步或者先做異步生成。2.3 關鍵取舍題目實時生成還是預生成實時生成的優點是不需要存儲大量題目每次請求都是新題缺點是用戶每次等待模型返回而且維基百科接口和模型接口任何一個抖動都會影響體驗。預生成的優點是把耗時前置管理員提前批量生成 100 題存在數據庫里用戶打開頁面秒出題缺點是題目庫會陳舊而且生成成本固定。學習階段建議先做實時生成邏輯更直觀。等到產品需要穩定體驗時再加一個本地緩存把生成過的題目存到 SQLite 或 Redis標題相同的題目直接復用。下面代碼都按實時生成的最小閉環來寫。3. 環境準備與依賴安裝3.1 運行環境要求開發環境建議使用 Python 3.10 及以上因為 FastAPI 和 Pydantic 的較新版本依賴新語法。操作系統不限Windows、macOS、Linux 都可以。依賴項如下表所示安裝時以你當前環境能拉到的最新穩定版本為準。依賴包作用fastapiWeb 框架提供 API 路由和參數校驗uvicornASGI 服務器用來啟動 FastAPIhttpx發起維基百科 HTTP 請求openai調用大模型接口的官方 SDKpython-dotenv讀取 .env 環境變量文件開發環境需要能訪問維基百科的 REST 接口以及你的模型供應商接口。生產環境還要注意網絡策略、超時時間和密鑰管理這些在排錯一節會提到。3.2 項目結構與依賴文件先建立項目目錄目錄結構保持簡單方便后面擴展。ai-or-not-quiz/ ├── app.py # FastAPI 入口 ├── quiz/ │ ├── __init__.py │ ├── wikipedia_client.py # 維基百科摘要獲取 │ ├── ai_generator.py # AI 文本生成 │ ├── quiz_service.py # 題目組裝與判定 │ └── models.py # Pydantic 數據模型 ├── static/ │ ├── index.html │ ├── style.css │ └── app.js ├── requirements.txt ├── .env.example └── README.mdrequirements.txt 內容如下fastapi uvicorn[standard] httpx openai python-dotenv安裝依賴pip install -r requirements.txt如果你的環境同時存在多個 Python 版本建議先創建虛擬環境再安裝python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtWindows 下激活虛擬環境命令是.venv\Scripts\activate注意區分。3.3 環境變量配置模型密鑰不能寫死在代碼里所以通過環境變量注入。新建.env文件內容參考.env.exampleLLM_API_KEY你的模型APIKey LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你的大模型服務使用 OpenAI 兼容接口LLM_BASE_URL指向對應服務地址即可。沒有填寫LLM_API_KEY時程序應該能啟動但生成題目的接口返回明確錯誤而不是直接崩潰。4. 實現維基百科摘要獲取模塊4.1 選擇隨機詞條接口維基百科提供 REST API其中/page/random/summary可以直接拿到一個隨機詞條的摘要。這個接口的好處是響應體已經包含標題、摘要和頁面鏈接不需要再解析 HTML。實現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), }關鍵點timeout10.0防止請求長時間掛起。User-Agent要聲明項目名和用途維基百科文檔建議這樣做能降低被限流的概率。extract字段就是詞條開篇的純文本摘要默認已經很干凈。如果想按指定主題出題可以使用按標題獲取摘要的接口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} # 后續邏輯與 fetch_random_article_summary 一致4.2 讀取和清洗 extract 字段extract雖然是純文本但直接使用時還要做三件事去掉首尾空格?？刂崎L度。有些詞條摘要比較長超過 300 個單詞后用戶閱讀負擔會增加。判斷文本是否過短。如果摘要只有幾個單詞說明這個詞條可能質量較低建議放棄并重新隨機。長度控制和異常處理可以合并成一個函數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 中英文詞條與語言切換基礎版本使用英文維基百科詞條覆蓋廣模型對英文百科風格也更熟悉。想支持中文只需把域名換成https://zh.wikipedia.orgWIKIPEDIA_REST_BASE https://zh.wikipedia.org/api/rest_v1同時 AI 生成模塊的提示詞也要改成中文否則會出現“英文模型生成英文中文詞條生成中文”的語言錯位。建議把語言作為配置項不要寫死。5. AI 同主題文本生成模塊5.1 提示詞設計讓模型寫出“像維基百科”的文本提示詞決定題目難度。如果提示詞太弱AI 文本一眼就能看出來如果提示詞太強模型可能直接復制人類摘要用戶讀起來像同源文本。推薦提示詞要強調三點客觀語氣、獨立寫作、接近百科開篇的信息密度。SYSTEM_PROMPT 你是一名百科詞條編輯。請用客觀、中立的語氣寫一段關于指定主題的百科簡介。 要求 1. 全文 120 到 180 個英文單詞。 2. 不要使用“作為一個AI模型”“我不能”等表述。 3. 不要輸出標題直接輸出正文。 4. 不要復制參考文本而是基于主題獨立寫作。 5. 信息密度盡量接近維基百科的開篇段落。注意提示詞里明確“不要復制參考文本”是為了保證 AI 文本和人類文本不完全重復否則游戲會退化成“兩段內容是否相同”而不是“風格是否像 AI”。5.2 調用 OpenAI 兼容接口使用 openai 官方 SDK并支持通過base_url切換到其他兼容服務這是最常見的接入方式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參考背景不要直接復制\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 控制輸出長度和穩定性大模型生成不是確定性的同一提示詞兩次結果可能不同。為了控制題目質量需要理解幾個參數參數作用建議值調大影響調小影響temperature控制隨機性0.7文本更多樣可能跑題更穩定但容易重復max_tokens限制最大輸出長度300可輸出更長文本可能截斷正文top_p采樣范圍默認即可更發散更保守如果題目需要“讓用戶更難猜”可以嘗試temperature0.9如果作為評測基準建議固定temperature0.3到0.5保證結果相對穩定。實際中不要同時調大temperature和top_p會讓輸出不可控。6. 題目組裝與判定服務6.1 題目數據模型拿到兩段文本后把它們封裝成一個題目對象。用 Pydantic 定義模型方便接口層做響應序列化。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字段只存在于服務端真正返回給前端的時候要把它剝離否則用戶看一眼 JSON 就知道答案了。這里先講清楚模型接口層返回時再處理。6.2 隨機洗牌與答案記錄洗牌是保證游戲公平的關鍵。如果不洗牌AI 文本永遠固定在 A 或 B用戶連續玩幾次就能猜出規律。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避免自增數字被用戶猜測。答案只保存在內存對象里判題時按question_id取出。6.3 計分與會話管理最小閉環可以用內存字典保存題目和分數簡單但不適合多進程部署class QuizStore: def __init__(self): self.rounds: dict[str, QuizRound] {} self.scores: dict[str, int] {} quiz_store QuizStore()生產環境需要把question_id和分數存到 Redis 或數據庫并且設置過期時間防止內存無限增長。學習階段用內存即可但要清楚重啟服務后所有數據會丟失。7. FastAPI 接口實現7.1 接口設計接口設計要遵循一個原則用戶只拿到必要信息服務端保留答案和分數。接口方法請求參數返回內容/api/quizGET無題目 ID、標題、兩個選項文本/api/answerPOSTquestion_id, selected_id是否正確、正解選項 ID、當前分數/GET無前端頁面沒必要把“生成題目”和“獲取正解”放在同一個接口里那樣用戶可以直接通過網絡請求看到答案字段。7.2 核心接口代碼實現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都是同步阻塞調用FastAPI 的異步事件循環會被阻塞。學習項目里問題不大但并發上來后要改成async或放入線程池。這一點在最佳實踐里會再強調。7.3 請求與響應示例創建題目curl http://127.0.0.1:8000/api/quiz響應示例{ 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}響應示例{ correct: true, answer_id: B, score: 1 }8. 前端交互頁面8.1 頁面結構前端保持極簡負責三件事拉取題目、展示兩個選項、提交答案。static/index.html核心結構如下!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 調用接口static/app.js實現加載題目和提交答案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}當前得分 ${data.score}; } else { resultEl.textContent 答錯了正解是 ${data.answer_id}當前得分 ${data.score}; } nextBtn.style.display block; } nextBtn.onclick loadQuiz; loadQuiz();這里把選項渲染成按鈕點擊后立即提交。更完整的版本應該在高亮選項后再提交避免用戶誤觸。8.3 反饋與下一題邏輯判題之后要同時展示“是否正確”和“正解是哪一個”否則用戶只能盲目猜。下一題按鈕復用loadQuiz重新請求新題。學習階段可以不考慮用戶體系分數默認記在內存里的固定 key 上。需要區分用戶時可以引入 session_id 或 JWT把分數綁定到具體用戶。9. 運行驗證與結果質量分析9.1 啟動與本地驗證啟動服務uvicorn app:app --reload --port 8000啟動成功的標志是控制臺輸出類似Uvicorn running on http://127.0.0.1:8000。瀏覽器打開http://127.0.0.1:8000/應該能看到頁面。建議按下面順序做冒煙測試單獨請求維基百科接口確認外網可訪問。單獨調用generate_ai_extract確認模型 Key 有效。請求/api/quiz確認返回兩個選項且文本不重復。提交一個錯誤答案和一個正確答案確認判定正確。刷新頁面連續玩 10 題確認沒有明顯報錯。9.2 curl 驗證接口返回直接依賴瀏覽器調試有時看不到完整報錯配合 curl 更高效curl -i http://127.0.0.1:8000/api/quiz用-i能同時看到 HTTP 狀態碼和響應體。如果返回 503說明題目的某個上游服務出了問題查看服務端日志定位是維基百科超時還是模型返回空。9.3 判斷題目質量的檢查清單“能跑”不等于“題目能玩”。每生成一題建議按以下清單檢查[ ] 兩段文本長度是否接近避免用戶靠長度猜測。[ ] AI 文本是否出現“作為一個 AI”“我不能”這類提示詞痕跡。[ ] AI 文本是否復述了人類文本的大段原句。[ ] 詞條標題是否過于生僻用戶完全無法判斷。[ ] 隨機詞條是否重復出現游戲后期是否疲勞。[ ] 模型返回是否偶發截斷截斷后選項是否殘缺。其中“AI 文本是否復述原句”是最常出現的問題。如果復述嚴重說明提示詞的“不要復制參考文本”約束不夠需要加強或者在生成后用文本相似度做過濾。10. 常見問題與排查路徑10.1 常見問題速查表問題現象常見原因檢查方式處理建議/api/quiz 返回 503維基百科接口超時或模型 Key 無效單獨 curl 維基百科接口單獨調用模型 SDK 示例檢查網絡、密鑰、模型名加超時和重試兩個選項文本幾乎一樣模型復制了參考文本對比兩段文本相似度查看提示詞在提示詞中加強“獨立寫作”約束或過濾高相似度結果AI 文本明顯帶“AI 痕跡”提示詞沒有禁用口語化表達查看生成文本增加禁用句式提高 temperature模型返回被截斷max_tokens 太小查看響應里的 finish_reason調大 max_tokens或檢測截斷后重新生成刷新頁面后分數丟失分數存在內存檢查存儲位置學習階段可接受生產環境改用 Redis 或數據庫請求 /api/quiz 很慢模型生成是同步阻塞調用觀察日志耗時改成異步生成或預生成題目隨機詞條重復出現維基百科隨機接口沒有去重記錄最近題目標題維護一個已用過標題的隊列臨時跳過10.2 從現象到根因的排查順序遇到問題不要先看最后一行堆棧按下面順序排查確認請求本身沒問題路徑和參數正確。確認上游依賴可用維基百科接口、模型接口。確認環境變量已加載.env文件路徑正確。查看服務端完整日志識別是網絡報錯、鑒權報錯還是模型響應格式問題。用最小腳本單獨復現問題隔離模塊。如果只是偶發問題考慮超時和重試策略而不是改提示詞。例如“題目生成失敗”是一個非常粗的報錯必須把原始異常記錄到日志里。給用戶的 detail 保持簡潔但服務端日志要能定位到是httpx.ConnectTimeout還是openai.AuthenticationError。11. 生產化最佳實踐與擴展方向11.1 工程化建議清單學習項目跑通后如果要把它做成真正可用的服務建議對照下面的清單補強[ ] 模型 Key 統一從環境變量或密鑰管理系統讀取不要提交到代碼倉庫。[ ] 維基百科和模型接口都設置超時和重試并區分“不可重試”的錯誤類型。[ ] 題目和答案不要混在同一個存儲里答案字段不返回給前端。[ ] 用異步方式處理耗時操作避免阻塞 FastAPI 事件循環。[ ] 建立基本日志體系記錄請求耗時、上游錯誤、生成文本長度。[ ] 對生成文本做基礎過濾檢測空文本、敏感詞、超長文本。[ ] 為已生成的題目增加緩存減少重復請求模型。[ ] 增加簡單限流防止隨機詞條接口和模型接口被高頻調用。其中“答案字段不返回給前端”是這類產品最容易踩的坑。前端調試時可以查看網絡響應如果響應里帶is_ai: true玩家直接看開發者工具就能作弊。11.2 可以擴展的方向這個項目可以從一個答題游戲擴展成多個方向的工程實踐標注平臺把“用戶判斷是否正確”收集起來形成人工標注數據集用于訓練或評估文本分類器。模型評測工具固定一批維基百科詞條讓不同模型生成同主題文本比較哪個模型更容易被用戶識別為 AI。AI Agent 能力測試把“生成百科簡介”封裝成一個 Agent 工具調用觀察不同提示詞策略下的效果差異。AI 幻覺觀察器對生成文本做事實校驗標記出與維基百科原文不一致的地方幫助理解大模型的幻覺問題。前后端功能增強加入用戶登錄、排行榜、題目歷史、多語言支持。如果希望把生成和判題做成更通用的能力可以借鑒 Spring AI 這類框架的模塊化思路把模型供應商、提示詞模板和任務鏈路解耦。小項目不需要一步到位但模塊邊界一開始就要清楚。11.3 一點學習建議把“AI or Not”做完真正值得記住的不是代碼本身而是幾個判斷第一AI 應用不能只關心“模型能不能生成”更要關心生成結果如何進入業務鏈路、如何驗證、如何兜底。第二兩段文本對比是一個非常直觀的評測方式它比“AI 檢測率 90%”這類數字更能說明問題。第三一個最小閉環比一個宏偉架構更有學習價值先把 500 行代碼跑通再去考慮異步、緩存、Kubernetes 這些生產化能力。如果自己已經能獨立完成這個項目下一步可以試著不依賴維基百科換成自己的文檔庫或博客語料做一套“識別 AI 改寫內容”的內部工具。你會發現核心難點從“接 API”變成了“定義什么才算 AI 風格”那才是這個領域真正值得深挖的地方。