如何在自己網(wǎng)站上做支付寶嗎,可以發(fā)布推廣引流的懸賞平臺,如何做企業(yè)年報公示,網(wǎng)站備案經(jīng)驗摘要#xff1a;在 AIGC 爆發(fā)的時代#xff0c;如何將大模型能力真正落地到垂直場景#xff1f;本文將分享我開發(fā)的智能考研平臺——“拾題”#xff0c;探討如何利用 Vue3、Django 和 Moonshot AI (Kimi) 構(gòu)建一個集智能問答、?？奸喚砗蛽裥７治鲇谝惑w的全棧應(yīng)用。文中將…摘要在 AIGC 爆發(fā)的時代如何將大模型能力真正落地到垂直場景本文將分享我開發(fā)的智能考研平臺——“拾題”探討如何利用 Vue3、Django 和 Moonshot AI (Kimi) 構(gòu)建一個集智能問答、?？奸喚砗蛽裥７治鲇谝惑w的全棧應(yīng)用。文中將重點復(fù)盤流式響應(yīng) (SSE)、多模態(tài) OCR 識別及 Dify 工作流集成等核心技術(shù)難點。一. 項目背景考研是一場信息戰(zhàn)也是一場持久戰(zhàn)。作為大學(xué)生我深知其中的痛點擇校迷茫院校數(shù)據(jù)分散難以做出科學(xué)決策。沒人答疑遇到難題自學(xué)難以突破找學(xué)長學(xué)姐成本高。復(fù)盤低效錯題整理還在用手抄復(fù)習(xí)效率低下。于是“拾題”應(yīng)運而生。我希望打造一個24小時在線的 AI 私人助教利用大模型的推理能力和多模態(tài)理解能力重塑備考體驗。二. 技術(shù)選型與項目架構(gòu)為了保證開發(fā)效率與系統(tǒng)的可擴展性我采用了經(jīng)典的前后端分離架構(gòu)并通過 API 網(wǎng)關(guān)集成外部 AI 服務(wù)。1. 技術(shù)棧前端Vue 3 (Composition API) TypeScript Pinia Element Plus后端Django 5.2 Django REST Framework MySQL 8.0AI核心Moonshot AI (Kimi) Qwen-VL (阿里通義) Dify2. 系統(tǒng)架構(gòu)圖三. 核心技術(shù)難點復(fù)盤在開發(fā)過程中我們不僅僅是簡單的 API 調(diào)用而是解決了一系列工程化難題。難點一實現(xiàn)類 ChatGPT 的流式打字機效果 (Server-Sent Events)挑戰(zhàn)大模型生成長文本通常需要幾秒甚至幾十秒。如果使用傳統(tǒng)的Request-Response模式用戶會面對長達 30 秒的白屏體驗極差。我們需要實現(xiàn)“邊生成邊顯示”的效果。后端解決方案 (Django)利用 Django 的StreamingHttpResponse。我們不直接返回 JSON而是返回一個生成器 (Generator)。# backend/chat/views.py (簡化示例) def event_stream(question): client OpenAI(api_keyAPI_KEY, base_url...) response client.chat.completions.create( modelkimi-k2-turbo, messages[{role: user, content: question}], streamTrue # 關(guān)鍵點開啟流式 ) for chunk in response: content chunk.choices[0].delta.content if content: yield content # 實時 yield 字符 ? return StreamingHttpResponse(event_stream(q), content_typetext/event-stream)前端解決方案 (Vue 3) 使用fetchAPI的ReadableStream進行讀取避免等待整個響應(yīng)結(jié)束。// frontend/src/views/dashboard/SmartQAView.vue (核心邏輯) const reader response.body.getReader(); const decoder new TextDecoder(); ? while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value); // 實時追加到當(dāng)前消息內(nèi)容觸發(fā) Vue 響應(yīng)式更新 currentMessage.value.content chunk; // 滾動到底部 scrollToBottom(); }效果首字響應(yīng)時間從 5s 縮短至 0.5s用戶體驗極其絲滑。難點二考研數(shù)學(xué)公式的精準(zhǔn)識別 (OCR LLM)挑戰(zhàn) 考研數(shù)學(xué)題包含大量復(fù)雜的積分符號、矩陣和幾何圖形。普通的 OCR 只能識別文字對公式識別一塌糊涂直接傳給 LLM 會導(dǎo)致嚴(yán)重的幻覺Hallucination。解決方案 我們引入了多模態(tài)大模型 (Qwen-VL)作為“前置視覺處理器”。1.上傳用戶上傳題目圖片。2.識別后端調(diào)用 Qwen-VL-OCR 接口專門提取LaTeX格式的公式。Prompt: 請?zhí)崛D片中的所有內(nèi)容公式請使用LaTeX格式輸出。3.推理將識別出的精準(zhǔn)文本作為Context拼接Prompt發(fā)送給Kimi大模型進行解題。代碼片段# 先識別 ocr_response dashscope.MultiModalConversation.call( modelqwen-vl-ocr-latest, messages[{role: user, content: [{image: img_path}, {text: 提取文字}]}] ) extracted_text ocr_response.output.choices[0].message.content ? # 再推理 llm_response client.chat.completions.create( modelkimi-k2-turbo, messages[{role: user, content: extracted_text}] )難點三基于 Dify 的智能擇校工作流挑戰(zhàn) “智能擇?！辈皇呛唵蔚膯柎鹚枰Y(jié)合知識庫中的報錄比、分?jǐn)?shù)線并結(jié)合用戶偏好進行分析。單一的Prompt無法完成如此復(fù)雜的任務(wù)鏈。解決方案 我們使用Dify編排了一個Agent工作流。輸入解析提取用戶的本科院校、考研分?jǐn)?shù)、目標(biāo)地區(qū)。知識庫匹配調(diào)用我們預(yù)存的院校數(shù)據(jù)庫。報告生成LLM 綜合上述信息生成結(jié)構(gòu)化的 Markdown 報告。后端只需調(diào)用 Dify 的 API 接口即可獲得這就好比雇傭了一個專業(yè)的咨詢團隊。四. 項目展示用戶注冊界面用戶登錄界面首頁界面生成報告界面智能問答界面錯題本界面?？贾行慕缑?zhèn)€人中心界面五. 項目開發(fā)收獲與總結(jié)作為全棧開發(fā)者除了代碼本身工程化規(guī)范也至關(guān)重要。接口先行在開發(fā)前我詳細(xì)定義了Swagger/OpenAPI文檔。例如明確了流式接口返回的是純文本還是SSE格式的數(shù)據(jù)包避免了聯(lián)調(diào)時的推諉。Git 工作流我們嚴(yán)格執(zhí)行Feature Branch模式。每個人在feature/xxx分支開發(fā)禁止直接commit到main。統(tǒng)一的數(shù)據(jù)清洗由于 AI 的輸出具有不確定性有時返回 JSON有時返回 Markdown我們在后端增加了一層“清洗層”確保前端拿到的數(shù)據(jù)結(jié)構(gòu)永遠(yuǎn)是可預(yù)期的。