簡介一份來自廈門大學的DeepSeek專題學習資料由軟件和人工智能專家程希冀主講圍繞提示詞設計、幻覺避免與應用展開。內(nèi)容面向AI開發(fā)研究人員、技術愛好者以及職場、教育、家庭等各類使用者系統(tǒng)對比推理型DeepSeek-R1與非推理型DeepSeek-V3模型的性格差異指出前者適合數(shù)學、編程、邏輯任務后者適合快速問答與日常閑聊并分別給出提問策略。其中詳細講解充分的背景信息、六何分析法、Few-shot少量樣本提示、結構化分隔符等實用技巧配合示例演示如何讓DeepSeek制作炫酷圖表和動畫。針對大模型幻覺提出限制知識來源、明確時間界限、引入檢索增強框架等應對思路同時簡要介紹Manus智能體的特點。資源為單個PDF文檔大小2.27MB目前已有248人學習適合希望系統(tǒng)掌握提示詞設計、降低AI輸出偏差的讀者。1. 一份聚焦DeepSeek提示詞設計與幻覺避免的PDF為什么值得你花兩小時重讀同樣一段需求有人讓DeepSeek輸出三頁正確的廢話有人幾步就問出能直接落地的方案差距不在模型本身而在提示詞怎么寫、幻覺怎么防。廈門大學這份PDF把整套用法收在三個關鍵詞里提示詞設計、幻覺避免、應用——先說清模型如何理解你的話再給出能復用的模板和約束寫法最后落在API調(diào)用、本地部署與業(yè)務接入。它不是泛泛科普更像一份給從業(yè)者的檢查清單每一節(jié)都能對應到工位上正在發(fā)生的翻車現(xiàn)場。適合正在用DeepSeek做內(nèi)容生成、數(shù)據(jù)分析或準備把它接入內(nèi)部系統(tǒng)的人。讀完你大概率會想把手上所有prompt重寫一遍。2. 提示詞設計先搞懂DeepSeek怎么“讀”你的話再決定怎么寫提示詞設計不是把需求寫長。DeepSeek讀提示詞的方式和搜索引擎索引關鍵詞完全不同——它先對整個上下文做注意力建模再逐詞生成。這意味著指令所在的位置、同一句話的重復次數(shù)、上下文里互相沖突的信息都會直接影響輸出走向。這也是為什么同樣是“寫一份產(chǎn)品分析”有人只能拿到泛泛而談的套話有人拿到的內(nèi)容改改用就可以發(fā)出去。技術社區(qū)里現(xiàn)在沉淀了大量提示詞模板但直接照搬的命中率并不高因為模板脫離了你自己的數(shù)據(jù)格式和業(yè)務語境。與其收集模板不如先把DeepSeek理解文本的幾條底層規(guī)律搞清楚系統(tǒng)提示詞管人設用戶消息管任務規(guī)則要短句化約束要給“做不到時的退路”。下面幾個小節(jié)把這條主線拆開講。2.1 系統(tǒng)提示詞與應用提示詞的分工人設、任務和邊界到底劃在哪系統(tǒng)提示詞負責定“人設與規(guī)則”用戶消息負責給“本次任務”。常見做法是把系統(tǒng)提示詞當成一份長期有效的崗位說明書把用戶消息當成當次派單。需要留意的是DeepSeek對這兩者的遵循度不完全一樣在同一輪對話里越靠近消息末尾的用戶指令影響越大而系統(tǒng)提示詞一旦進入長對話會被后續(xù)內(nèi)容逐步稀釋。所以關鍵規(guī)則不能只在系統(tǒng)提示詞里寫一遍重要任務需要在用戶消息里再復述一次精簡版。下面是一個可以直接上手的雙段結構角色和規(guī)則放在系統(tǒng)提示詞里材料與具體問題放在用戶消息里[系統(tǒng)提示詞] 你是一名有十年經(jīng)驗的B端產(chǎn)品分析師。 規(guī)則 1. 所有結論必須基于給定材料材料之外的推斷要明確標注“推測”。 2. 輸出控制在600字以內(nèi)用Markdown分節(jié)。 3. 如果材料不足以支撐結論直接說“材料不足”不要補充想象中的細節(jié)。 [用戶消息] 以下是某SaaS產(chǎn)品的試用記錄與客服工單請分析留存率偏低的原因……把角色寫進系統(tǒng)提示詞把原始材料放在用戶消息里目的是讓模型在生成每個詞時都能就近參考最新位置的原始信息減少憑空發(fā)揮。規(guī)則部分用短句編號不要用一大段描述性文字因為模型對祈使句的遵循度明顯高于模糊描述。比如“如果材料不足直接說材料不足”就比“請不要給出沒有依據(jù)的推測”更有效前者給了明確退路后者只是在暗示一個模糊的行為邊界。2.2 一套能直接抄的提示詞模板角色、任務、格式與約束四要素把提示詞設計收斂成四個要素是我自己一直在用的做法。角色一句話帶過任務寫明對象與目標格式規(guī)定輸出骨架約束寫清楚“做不到怎么辦”。多數(shù)人寫提示詞只寫任務丟掉了格式和約束導致輸出結構五花八門幻覺也隨之高發(fā)——因為模型沒有收到“信息不足時怎么辦”的指令只能按訓練時的慣性補全一段合理但虛假的數(shù)據(jù)。角色你是角色擅長能力范圍。 任務針對對象完成目標。背景信息如下信息。 格式用結構輸出包含必需項忽略非必需項。 約束硬性限制。如果條件不滿足回復替代內(nèi)容。這套模板看起來樸素但把最容易翻車的幾個點直接釘死了。比如做內(nèi)容總結時約束里寫“如果原文沒有提到數(shù)據(jù)就用‘未給出’代替”模型就不會強行編一個百分比。做數(shù)據(jù)分析時格式里寫“先列結論再給依據(jù)”模型就不會把分析過程寫成流水賬。角色設置不要堆形容詞“資深分析師”和“有十年經(jīng)驗的資深分析師”對生成結果的影響微乎其微真正起作用的是后面三條任務是否明確、格式是否固定、約束是否給了退路。2.3 上下文長度與提示詞密度寫多長才算“夠用”DeepSeek的上下文窗口能放下相當長的內(nèi)容但這不意味著提示詞越長越好。提示詞一長兩個副作用立刻出現(xiàn)一是關鍵指令被淹沒在背景信息里模型的注意力被無關內(nèi)容分走二是推理計算量上升響應變慢。密度比長度重要這一點在DeepSeek導出的大量實測例子里反復出現(xiàn)。常見做法是把背景信息壓成短語列表而不是成段貼原文指令放在背景之后、問題之前同一個約束只寫一遍不要重復強調(diào)。重復在某些情況下會被模型理解為“這件事很重要所以我得多寫一點”反而誘導它展開。另一個高頻問題是“怎么繼承上一個對話”——原理上就是把歷史消息逐條塞進messages數(shù)組但繼承歷史的同時也會繼承歷史里的幻覺污染。所以我的習慣是長任務分段處理每段的messages只保留與當前步驟相關的歷史摘要而不是把前十分鐘的對話原樣全部帶上。3. 幻覺避免讓DeepSeek從“愛編”到“承認不知道”的工程手段幻覺避免是提示詞設計里最值得單獨拿出來講的部分。模型生成幻覺不是它“故意撒謊”而是它在做概率補全當問題觸及知識盲區(qū)它會按最相似的訓練樣本補全一段看起來合理的回答。幻覺避免的目標不是讓模型永不犯錯而是把錯誤控制在能被發(fā)現(xiàn)、能被修正的范圍內(nèi)。3.1 幻覺的三個來源訓練數(shù)據(jù)、解碼隨機性與上下文誤導第一個來源是訓練數(shù)據(jù)。數(shù)據(jù)里本身存在錯誤、過時或矛盾的信息模型學到的是“這類問題通常有答案”而不是“這次有答案”。一旦問題落在知識盲區(qū)它就會按統(tǒng)計規(guī)律補全。第二個來源是解碼隨機性。temperature大于0時每次采樣概率不完全相同低概率token也有機會被選中。越是開放的任務越容易選到“聽起來合理但不準確”的路徑。第三個來源是上下文誤導。前幾輪對話里你輸入的錯誤事實模型會當作前提吸收然后順著推導出更多錯誤結論。這三個來源對應三種不同的治理手段。數(shù)據(jù)問題靠約束性提示詞與檢索增強兜底解碼隨機性靠調(diào)低temperature和固定隨機種子來壓制上下文誤導靠對話結構設計與定期清空歷史來處理。只靠一個方法解決不了所有幻覺這一點要先清楚。3.2 寫進提示詞的三句“防幻覺”話允許承認不知道、要求標注、要求自檢提示詞層面有三句話對DeepSeek特別有效我?guī)缀趺總€生產(chǎn)級模板里都會帶上一句半句。第一句是“如果你不確定直接說無法確定”這是給模型一個體面的退路避免它為了完成任務而硬編。第二句是“引用材料時標注來源編號”這能強迫模型把結論和依據(jù)綁定。第三句是“輸出前檢查一遍每個結論是否都有出處”這等于讓模型在回答前多過一道自我校驗。角色你是數(shù)據(jù)標注規(guī)則審核助手。 任務對照標注規(guī)范檢查以下標注結果是否正確。 格式逐條輸出“結論 | 原因 | 建議”結論只能是“通過/不通過/存疑”。 約束 1. 規(guī)范里沒有寫明的情況輸出“存疑”不要自行推斷。 2. 如果某條結論的依據(jù)不足直接在原因里寫“依據(jù)不足”。 3. 不要為了通過率而放寬規(guī)則。數(shù)據(jù)標注場景里幻覺是最容易翻車的點因為標注結果會被當成訓練數(shù)據(jù)反哺模型。上面這個模板的思路是把“存疑”作為合法輸出項讓模型有權拒絕回答。加了這句話之后模型會明顯更傾向于在邊界情況說“存疑”而不是硬給一個可能帶偏后續(xù)任務的結論。3.3 外部校驗與檢索增強提示詞兜不住的用工程兜提示詞層面的約束能壓低幻覺概率但攔不住所有。生產(chǎn)環(huán)境里更可靠的做法是加一層外部校驗生成完關鍵內(nèi)容后用獨立腳本對數(shù)字、日期、產(chǎn)品名做比對。下面是一個簡單的校驗腳本用來掃描模型輸出里可能存在問題的統(tǒng)計數(shù)據(jù)import re def verify_statements(text, known_facts): problems [] for sentence in re.split(r[。\n], text): if not sentence.strip(): continue for key, value in known_facts.items(): if key in sentence and str(value) not in sentence: problems.append(f{key} 與事實不符: 輸出中缺少 {value}) if re.search(r\d(\.\d)?%|\d{4}年, sentence): if not any(key in sentence for key in known_facts): problems.append(f無法核驗的統(tǒng)計句: {sentence[:30]}) return problems facts {市場占有率: 34%, 用戶數(shù): 1200萬} text 該產(chǎn)品市場占有率達到34%用戶數(shù)約1200萬同比增長明顯。 print(verify_statements(text, facts))邏輯說明先把輸出按句切分再對每個句子做兩類檢查。第一類是關鍵詞命中的句子如果句子提到“市場占有率”但沒包含預期數(shù)值就判定為問題句第二類是包含百分比或年份但不在已知事實庫范圍內(nèi)的句子這類句子雖然不一定是幻覺但值得人工復核。參數(shù)說明known_facts是準備好的事實字典re.split(r[。\n])控制切分粒度短信粒度也可以按“?！鼻杏⑽膬?nèi)容要額外加空格切分規(guī)則。更徹底的做法是RAG把知識庫切片、向量化、檢索再把檢索結果拼進用戶消息讓模型“僅基于檢索內(nèi)容回答”。這套組合在DeepSeek上跑起來后幻覺率會明顯下降代價是多一次向量檢索和一段額外的提示詞模板。數(shù)據(jù)規(guī)模不大時用上面這種簡單的規(guī)則校驗就夠了不必一上來就上全套RAG基礎設施。4. DeepSeek應用落地從最小API調(diào)用到完整業(yè)務接入提示詞設計得好只是第一步真正產(chǎn)生價值的是把DeepSeek接進業(yè)務。這一章從最小可運行的API調(diào)用講起再聊本地部署和接入工作流的常見模式。不少人的第一問題是DeepSeek的API怎么調(diào)——答案比想象中簡單用OpenAI兼容的SDK就能跑通。4.1 DeepSeek API最小調(diào)用示例用Python跑通你的第一個請求DeepSeek的API兼容OpenAI的接口格式所以直接用openai這個Python庫就能調(diào)用。先到開放平臺申請一個API Key然后把下面這段代碼保存為deepseek_demo.py運行import os from openai import OpenAI client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], base_urlhttps://api.deepseek.com ) def ask_deepseek(system_prompt, user_prompt, temperature0.3): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperaturetemperature, max_tokens1024, streamFalse ) return resp.choices[0].message.content system_prompt 你只依據(jù)給定資料回答問題資料中沒有的信息直接說不知道。 user_prompt 資料MySQL慢查詢?nèi)罩撅@示某SQL耗時3秒。問題如何優(yōu)化這個SQL print(ask_deepseek(system_prompt, user_prompt))邏輯說明先創(chuàng)建OpenAI客戶端指定base_url指向DeepSeek的接口地址api_key從環(huán)境變量讀取避免把密鑰寫死在代碼里。chat.completions.create里傳了三樣東西模型名、消息列表、采樣參數(shù)。參數(shù)說明temperature控制隨機性事實型任務設在0.1到0.3之間創(chuàng)意型任務可以上調(diào)到0.7左右max_tokens限制回答長度設為1024意味著約幾百字的輸出空間streamFalse表示一次性返回完整結果實時交互場景可以改成True用流式輸出。等任務跑通之后建議把base_url、模型名、溫度這幾個參數(shù)抽到配置文件里方便后續(xù)切換不同服務商或做模型對比。4.2 本地部署vllm與官方API選型什么規(guī)模值得自己扛很多團隊在并發(fā)量上來之后會糾結要不要自己部署。我的判斷標準很簡單10個以內(nèi)內(nèi)部用戶直接用官方API最劃算超過這個規(guī)模、或有數(shù)據(jù)不出園區(qū)的合規(guī)要求時才值得考慮vllm本地部署。高峰期官方API偶爾會返回繁忙或超時這在工程上靠重試與降級就能解決不構成必須自建的理由。本地部署DeepSeek的常見路徑是用vllm起一個OpenAI兼容的服務vllm serve /data/models/deepseek-model \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9啟動后的服務地址http://127.0.0.1:8000/v1可以直接作為base_url使用代碼幾乎不用改。參數(shù)說明/data/models/deepseek-model替換成你實際下載的權重路徑--max-model-len限制上下文長度顯存不足時從32768往下調(diào)--gpu-memory-utilization控制顯存占用比例留出一點余量給推理過程中的中間張量。模型權重文件較大下載前先確認磁盤和顯存夠用量化版本能減少顯存需求但可能犧牲精度。對比項官方API本地部署vllm上手成本低注冊拿Key即可高要準備GPU與權重并發(fā)上限取決于服務端配額自己控制但受限于硬件數(shù)據(jù)安全數(shù)據(jù)經(jīng)過外部接口數(shù)據(jù)留在內(nèi)網(wǎng)維護負擔無有升級、監(jiān)控、告警都要管選型時還要考慮團隊的運維能力。本地部署一旦掛掉修復時間可能以小時計而官方API掛掉你還能做降級或切換模型。很多團隊最終走的是混合路線日常請求走官方API敏感數(shù)據(jù)任務走本地部署兩邊用同一個提示詞模板與接口層。4.3 接入現(xiàn)有工作流代碼輔助、企業(yè)內(nèi)部問答與批量處理三種接法DeepSeek應用落地最常見的三個方向一是接入代碼輔助工具很多開發(fā)者把DeepSeek接進命令行或編輯器寫代碼通過一個兼容接口做代碼續(xù)寫和Debug對話二是企業(yè)微信等內(nèi)部IM里掛一個問答機器人把系統(tǒng)提示詞設成內(nèi)部知識庫管家的角色三是離線批量處理比如把一批文檔丟給DeepSeek做摘要、打標簽、抽取字段。前兩者強調(diào)響應速度第三種強調(diào)成本控制與結果可復核。接入模式上有一條固定鏈路任務類型識別 → 提示詞模板選擇 → 調(diào)用模型 → 規(guī)則校驗 → 人工兜底。任務類型識別決定走簡單模板還是復雜模板提示詞模板選擇要按部門或業(yè)務線維護不能一個模板走天下規(guī)則校驗環(huán)節(jié)處理上一章講的事實核對人工兜底用于高風險的輸出比如對外發(fā)布內(nèi)容或財務分析。社區(qū)里已經(jīng)有一些把提示詞模板管理和日志回放封裝成工作流的開源工具核心思路就是給提示詞做版本管理出現(xiàn)問題時能快速回退到上一版而不是在代碼里找線索。5. 避坑指南提示詞設計與幻覺治理中常見的5個翻車現(xiàn)場這一章全部來自真實使用中的血淚經(jīng)驗。每一條都是現(xiàn)象、原因、解決三段式方便你對照排查。不要等模型輸出明顯離譜時再懷疑提示詞多數(shù)翻車在寫提示詞的那一刻就已經(jīng)注定了。5.1 角色設定寫得越抽象模型的“表演欲”越強現(xiàn)象系統(tǒng)提示詞里寫“你是一名資深專家請給出專業(yè)且全面的分析”結果模型輸出變成了長篇大論的正確廢話甚至揣著專家的架子開始編數(shù)據(jù)。原因“資深專家”是一個模糊身份模型沒有具體的行為約束只能靠訓練數(shù)據(jù)里“專家口吻”的統(tǒng)計特征來表演。解決把角色設定從身份描述改成行為描述寫清楚“面對不確定信息時怎么辦”“回答控制在多少字”“是否需要列出依據(jù)”讓角色落在一組具體動作上。5.2 一次塞進十個需求輸出開始丟點串味現(xiàn)象一條用戶消息里同時問“總結亮點、分析風險、給競品對比、提優(yōu)化建議、列執(zhí)行計劃”結果模型只覆蓋了前面兩三個點后面的草草帶過。原因注意力在全篇分布需求太多時每個點分到的權重都有限后置任務最容易被忽略。解決把任務拆成多次調(diào)用第一次做總結與風險分析第二次帶著第一次的結論做競品對比每次只聚焦一個目標。如果必須一次完成把需求按重要性重新排序并明確寫“按以下順序依次回答每條不超過200字”。5.3 temperature不是越大越有創(chuàng)意而是越過越能編現(xiàn)象把temperature調(diào)到1.2想讓總結“更有深度”結果生成的數(shù)字和結論都開始對不上原文。原因高溫增加了低概率token的采樣機會模型在“找詞”而不是“組織事實”。創(chuàng)意型任務可能剛好需要這種跳躍事實型任務無法承受這種不穩(wěn)定。解決事實性任務無條件設在0.3以下創(chuàng)意型任務在0.7到0.9之間試探不要超過1.0。如果既想要變化又怕失真用多輪對話讓模型基于上一輪回答做改寫比一味調(diào)高溫度更穩(wěn)。5.4 多輪對話里錯誤事實會滾雪球現(xiàn)象第一輪模型把某個數(shù)據(jù)說錯了第二輪你問“基于剛才的數(shù)據(jù)下一步怎么做”模型順著錯誤數(shù)據(jù)推出了一整套方案。原因模型把上下文中的陳述當成了既定前提后續(xù)所有生成都在這個錯誤地基上構建。這解釋了為什么長對話里幻覺看起來越來越嚴重——它在自洽地放大最初的偏差。解決關鍵任務不要依賴長對話每輪messages只保留與當前步驟相關的歷史摘要發(fā)現(xiàn)錯誤數(shù)據(jù)立刻停止開啟新對話并手動糾正背景信息涉及事實的輪次加校驗別讓錯誤前提進入下一輪。5.5 上下文截斷發(fā)生在暗處長對話后半段的提示詞容易靜默失效現(xiàn)象對話前20輪一直遵守“回答不超過300字”的規(guī)則到第30輪突然開始輸出長文還丟了人設。原因上下文總量接近窗口上限后早期的系統(tǒng)提示詞可能被截斷或者注意力權重不足以讓它繼續(xù)生效。很多使用者以為規(guī)則還在實際上已經(jīng)沒了。解決把最關鍵的兩條約束輸出長度、禁止編造在每次用戶消息末尾用一句話重述重要場景用獨立的新對話而不是攢長會話生產(chǎn)環(huán)境里記錄請求的token用量接近上限前自動截斷歷史。6. 進階技巧用結構化生成與一致性自檢壓住幻覺幻覺治理走到最后拼的不是提示詞技巧而是生成流程的設計。最值得投入的一個技巧是“兩步生成法”第一步讓模型只輸出提綱第二步帶著提綱再生成全文。這個做法把“一口氣編到底”的路徑切斷了——提綱階段模型只能擬骨架展開階段每一步都有明確落點幻覺空間被大幅壓縮。第一輪 請為以下主題列一個輸出提綱包含總體結論、依據(jù)和行動建議三個部分每部分用一行概括 主題 第二輪 請基于以下提綱展開全文。不得增加提綱之外的新結論每個結論后標注“依據(jù)”或“推測”依據(jù)不足的結論直接寫“材料不足” 提綱配合兩步生成我還會加一道自檢prompt讓模型對自己的回答挑毛病。做法是把生成結果原樣丟回去只給一句指令“請找出這段回答中缺乏依據(jù)的句子并說明哪里需要補充材料?！边@種自一致性校驗在DeepSeek上效果不錯因為它不是讓模型做開放判斷而是做局部挑錯挑錯的準確率通常高于生成時的自我判斷。再補一個跟隨了我很久的習慣所有要上線的生成結果至少過一遍關鍵事實清單批量跑的任務把每一輪的校驗結果記錄下來長期觀察幻覺率隨提示詞版本變化的曲線。曾經(jīng)有一段時間我把一套提示詞模板直接放到生產(chǎn)環(huán)境沒有做任何校驗結果模型編的行業(yè)數(shù)據(jù)混進周報才發(fā)現(xiàn)模板里少了一句“信息不足時直接說不知道”。后來所有模板強制帶上不確定性出口并養(yǎng)成了讓模型先列提綱再展開的習慣。這套組合做完幻覺率控制在可接受范圍內(nèi)提示詞設計才算真正閉環(huán)。希望這些方法在你的DeepSeek使用場景里也能少踩幾個坑幫到你。本文還有配套的精品資源點擊獲取