簡介這份PDF由清華大學(xué)新媒沈陽團(tuán)隊撰寫面向希望借助大語言模型提升辦公效率的職場人士與AI應(yīng)用開發(fā)者系統(tǒng)講解DeepSeek在真實工作場景中的落地方法。內(nèi)容涵蓋團(tuán)隊在人機協(xié)同、人機共生方向的研究背景DeepSeek在英偉達(dá)NIM、微軟Azure、亞馬遜AWS等平臺的部署信息以及基礎(chǔ)模型V3、深度思考模型R1與聯(lián)網(wǎng)搜索模型RAG在規(guī)范性、路徑靈活性和風(fēng)險特征上的差異對比。資源還給出RTGO與CO-STAR兩套提示語框架并展開可視化圖表、海報設(shè)計、視頻分鏡、新媒體文案批量生成、AI應(yīng)用開發(fā)與市場調(diào)查等場景的具體技巧同時強調(diào)角色定義、功能描述與邊界意識等人機協(xié)作要點。資源包為1個PDF文件約10.02MB結(jié)構(gòu)完整、便于通讀與檢索。目前已有599人學(xué)習(xí)適合想系統(tǒng)掌握DeepSeek提示詞技巧與多場景應(yīng)用方法的讀者參考。1. 一份被傳瘋的 PDF真正值錢的是它背后的提示詞工程2025 年開年到現(xiàn)在我微信里被問得最多的一句話就是“清華那份 DeepSeek 職場應(yīng)用的 PDF 你看了嗎”說實話第一次聽到這個標(biāo)題我以為是又一份 PPT 拼湊的行業(yè)報告。直到有做運營的朋友把里面的表格截圖發(fā)我問我“這個提示詞模板能不能直接套到我們客服場景”我才認(rèn)真翻了一遍。結(jié)論很直接這份材料真正有價值的不是“清華”兩個字而是它把大語言模型在職場里的落地方式從“聊天”拉到了“可復(fù)用的工作流”這個層面。它解決的是一個很具體的痛點——大部分人用 DeepSeek 還停留在“幫我寫個周報”這種一次性對話而職場里真正耗時的任務(wù)是那些重復(fù)、有格式要求、需要多輪迭代的活會議紀(jì)要轉(zhuǎn)行動項、競品分析框架搭建、招聘 JD 批量生成、數(shù)據(jù)報表的異常歸因。這些任務(wù)如果每次都要重新描述背景提示詞工程就白做了。這份 PDF 適合兩類人一是每天要處理大量文本但不懂技術(shù)的職場人二是想把 DeepSeek 接入內(nèi)部工具鏈的工程師。前者能直接抄模板后者能看到提示詞設(shè)計的結(jié)構(gòu)化思路。2. 從“會聊天”到“能干活”DeepSeek 職場落地的三層能力拆解2.1 為什么通用提示詞在職場場景里總是差一口氣我拿同一個任務(wù)做過對比讓 DeepSeek 寫一份“Q2 用戶流失分析報告”。用“你是一個數(shù)據(jù)分析師請寫一份流失分析報告”這種通用提示詞輸出的是教科書式的框架——背景、現(xiàn)狀、原因、建議每部分都是正確的廢話。但換成結(jié)構(gòu)化提示詞后輸出質(zhì)量完全不一樣。差別在哪通用提示詞只給了角色沒給約束條件。職場任務(wù)有三個隱性要求數(shù)據(jù)必須來自我提供的材料、格式必須匹配公司模板、結(jié)論必須可執(zhí)行。這就引出了提示詞工程里最容易被忽略的一點上下文工程比提示詞本身更重要。你給模型的信息密度決定了它輸出的信息密度。我一般會按這個順序組織輸入任務(wù)目標(biāo) → 可用數(shù)據(jù) → 輸出格式 → 禁止事項。比如“基于以下 5 條用戶反饋提取共性問題按‘問題描述/影響范圍/建議動作’三列輸出表格不要寫總結(jié)段落”。這個結(jié)構(gòu)比任何角色扮演都管用。2.2 把 DeepSeek 當(dāng)“實習(xí)生”而不是“專家”來用很多人翻車是因為把 DeepSeek 當(dāng)專家指望它自己知道公司業(yè)務(wù)。我的血淚經(jīng)驗是把它當(dāng)一個剛?cè)肼毜穆斆鲗嵙?xí)生。實習(xí)生需要什么清晰的 SOP、具體的樣例、明確的邊界。對應(yīng)到提示詞設(shè)計就是三個動作第一給樣例。不要只說“按這個格式寫”直接貼一個填好的樣例進(jìn)去。DeepSeek 的 few-shot 能力很強一個樣例頂十句描述。第二拆步驟。復(fù)雜任務(wù)不要一步到位拆成“先提取關(guān)鍵信息 → 再歸類 → 最后生成報告”三步每步單獨對話。第三設(shè)邊界。明確告訴它“如果數(shù)據(jù)里沒有提到不要編造寫‘?dāng)?shù)據(jù)缺失’”。我實測過一個場景把 30 條客服對話記錄丟給 DeepSeek讓它提取產(chǎn)品缺陷。一步到位的提示詞輸出的是泛泛的“用戶體驗不佳”。拆成兩步后——第一步只提取“用戶提到的具體功能名稱和問題描述”第二步再歸類——準(zhǔn)確率從大概六成提到了九成以上。這個提升不是模型變強了是任務(wù)拆解降低了模型的推理負(fù)擔(dān)。2.3 一個可直接復(fù)用的職場提示詞模板結(jié)構(gòu)下面這個模板是我從那份 PDF 的思路里提煉出來又在自己團(tuán)隊跑了兩個月后固定下來的。它適用于大部分文本處理類職場任務(wù)# DeepSeek 職場任務(wù)提示詞模板 - Python 字符串拼接示例 # 適用場景會議紀(jì)要轉(zhuǎn)行動項、用戶反饋歸類、競品信息提取 prompt_template # 角色 你是一名{role}服務(wù)于{industry}行業(yè)。 # 任務(wù) {task_description} # 輸入數(shù)據(jù) {input_data} # 輸出要求 1. 格式{output_format} 2. 語言風(fēng)格{tone} 3. 字?jǐn)?shù)限制{word_limit} # 約束條件 - 只使用輸入數(shù)據(jù)中出現(xiàn)的信息不要補充外部知識 - 如果某項信息缺失標(biāo)注“未提及” - 不要輸出解釋性段落直接給結(jié)果 # 示例 輸入{example_input} 輸出{example_output} 邏輯說明這個模板的核心是把“角色”和“任務(wù)”分開寫。角色只影響語氣任務(wù)才決定輸出結(jié)構(gòu)。很多人把兩者混在一起寫導(dǎo)致模型過度關(guān)注角色扮演而忽略任務(wù)本身。參數(shù)方面output_format建議用表格或 JSON 這種結(jié)構(gòu)化描述比“分點列出”更可控word_limit對 DeepSeek 來說不是硬約束但寫上能減少冗余example_output是最關(guān)鍵的參數(shù)一個高質(zhì)量樣例能讓輸出合格率提升明顯。提示input_data如果超過 2000 字建議先做一次摘要提取再喂給任務(wù)提示詞。DeepSeek 的長上下文能力雖然強但信息密度過高時關(guān)鍵信息容易被稀釋。3. 把 PDF 里的方法變成日常工具DeepSeek API 調(diào)用與批量處理實戰(zhàn)3.1 用 API 替代網(wǎng)頁版什么時候值得切網(wǎng)頁版 DeepSeek 適合探索性任務(wù)但職場里真正高頻的是批量處理。比如每周要處理 50 份簡歷初篩、每天要歸類 200 條用戶反饋。這時候網(wǎng)頁版復(fù)制粘貼就是災(zāi)難。切 API 的判斷標(biāo)準(zhǔn)很簡單如果同一個提示詞模板你要用超過 10 次或者輸入數(shù)據(jù)來自文件/數(shù)據(jù)庫就該上 API 了。DeepSeek 的 API 兼容 OpenAI 格式這意味著你現(xiàn)有的 OpenAI 調(diào)用代碼改個 base_url 和 model 名就能跑。我一般用 Python 寫腳本因為后續(xù)要接 Excel 和數(shù)據(jù)庫。下面是一個最小可運行的批量處理腳本# DeepSeek API 批量處理腳本 # 依賴pip install openai pandas from openai import OpenAI import pandas as pd import time client OpenAI( api_key你的 DeepSeek API Key, # 從 DeepSeek 開放平臺獲取 base_urlhttps://api.deepseek.com # DeepSeek 的 API 端點 ) def process_batch(inputs, prompt_template, modeldeepseek-chat): 批量處理輸入列表返回結(jié)果列表 results [] for i, text in enumerate(inputs): prompt prompt_template.format(input_datatext) try: response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, # 職場任務(wù)建議低溫度保證穩(wěn)定性 max_tokens2000 ) results.append(response.choices[0].message.content) except Exception as e: results.append(f處理失敗: {str(e)}) time.sleep(0.5) # 控制請求頻率避免觸發(fā)限流 return results # 讀取 Excel 中的用戶反饋 df pd.read_excel(feedback.xlsx) template 提取以下反饋中的產(chǎn)品問題和用戶情緒按 JSON 輸出 {{問題: , 情緒: , 緊急程度: }} 反饋內(nèi)容{input_data} df[分析結(jié)果] process_batch(df[反饋內(nèi)容].tolist(), template) df.to_excel(feedback_analyzed.xlsx, indexFalse)邏輯說明temperature0.3是關(guān)鍵參數(shù)。職場任務(wù)要的是穩(wěn)定復(fù)現(xiàn)不是創(chuàng)意發(fā)散。溫度設(shè)到 0.7 以上同一批數(shù)據(jù)跑兩次結(jié)果可能不一致這在需要審計的場景里是致命的。time.sleep(0.5)是為了控制請求頻率DeepSeek 的免費額度有并發(fā)限制批量跑的時候不加延遲容易觸發(fā) 429 錯誤。max_tokens2000對大部分文本處理任務(wù)夠用但如果你的輸出是長報告需要調(diào)到 4000 以上。3.2 本地部署 DeepSeek 的邊界什么場景才真的需要熱詞里“deepseek本地部署”搜索量一直很高但我得說句實話大部分職場場景不需要本地部署。本地部署解決的是數(shù)據(jù)不出內(nèi)網(wǎng)和斷網(wǎng)可用兩個問題。如果你處理的是公開數(shù)據(jù)或者公司允許調(diào)用外部 API直接用官方 API 成本更低、效果更好。真正需要本地部署的場景我遇到過兩個一是金融公司處理客戶敏感信息合規(guī)要求數(shù)據(jù)不能出內(nèi)網(wǎng)二是工廠環(huán)境網(wǎng)絡(luò)不穩(wěn)定需要離線可用。這兩種情況下本地部署的硬件門檻是7B 模型需要至少 8GB 顯存14B 需要 16GB32B 需要 24GB 以上。用 Ollama 部署是最省事的方案# 使用 Ollama 本地部署 DeepSeek 模型 # 安裝 Ollama 后執(zhí)行以下命令 # 拉取 DeepSeek-R1 蒸餾版 7B 模型適合消費級顯卡 ollama pull deepseek-r1:7b # 啟動服務(wù)默認(rèn)監(jiān)聽 11434 端口 ollama serve # 測試調(diào)用 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 提取以下文本中的行動項下周三前提交方案周五開會評審, stream: false }邏輯說明deepseek-r1:7b是蒸餾版本推理能力比滿血版弱但勝在硬件要求低。如果你的任務(wù)只是信息提取和格式轉(zhuǎn)換7B 夠用。但如果涉及復(fù)雜推理——比如從多份報告中交叉驗證結(jié)論——7B 會明顯力不從心這時候要么上更大的模型要么還是走 API。stream: false在批量腳本里建議關(guān)掉流式輸出方便直接拿完整結(jié)果做后續(xù)處理。注意本地部署的模型版本更新滯后于官方 API新功能和優(yōu)化不會第一時間同步。如果業(yè)務(wù)依賴最新能力本地部署只能作為降級方案。4. 避坑指南DeepSeek 職場應(yīng)用里最容易翻車的五個地方4.1 輸出格式不穩(wěn)定表格變段落現(xiàn)象提示詞里明明寫了“輸出 Markdown 表格”但模型有時候輸出表格有時候輸出分點列表批量處理時格式五花八門。原因DeepSeek 對格式指令的遵循程度受輸入長度和任務(wù)復(fù)雜度影響輸入越長、任務(wù)越復(fù)雜格式指令的權(quán)重就越低。解決把格式要求放在提示詞的最后一行并且給一個格式樣例。如果還是不穩(wěn)定改用 JSON 輸出然后在代碼里做格式轉(zhuǎn)換。JSON 的結(jié)構(gòu)化約束比 Markdown 強得多。4.2 長文本處理時關(guān)鍵信息丟失現(xiàn)象一份 5000 字的會議紀(jì)要丟進(jìn)去讓提取行動項結(jié)果只提取了前幾條后面的被忽略了。原因模型對長文本的注意力分布不均勻開頭和結(jié)尾的信息容易被捕捉中間部分容易漏。解決不要一次性丟全文。先用一個提示詞做分段摘要每 1000 字一段然后再把摘要匯總做行動項提取。多一步但準(zhǔn)確率天差地別。4.3 API 調(diào)用返回 429 或超時現(xiàn)象批量腳本跑了幾十條后開始報錯提示請求過多或連接超時。原因DeepSeek API 有并發(fā)和頻率限制免費額度和付費額度的限制不同。解決在腳本里加指數(shù)退避重試。具體做法是捕獲異常后等待 1 秒重試連續(xù)失敗則等待時間翻倍最多重試 3 次。同時把time.sleep的間隔根據(jù)你的額度調(diào)整免費額度建議 1 秒以上。4.4 提示詞里的“不要編造”被無視現(xiàn)象明確寫了“只使用輸入數(shù)據(jù)中的信息”但模型還是補充了外部知識比如憑空給出行業(yè)平均值。原因大語言模型的預(yù)訓(xùn)練知識會“溢出”尤其在它認(rèn)為輸入信息不完整時會自動補全。解決把約束條件寫得更具體——“如果輸入數(shù)據(jù)中沒有提到某個數(shù)字輸出‘?dāng)?shù)據(jù)未提供’不要使用任何外部知識”。同時降低 temperature減少模型的“自由發(fā)揮”傾向。4.5 中文標(biāo)點和特殊字符導(dǎo)致解析失敗現(xiàn)象讓模型輸出 JSON但返回的內(nèi)容里中文引號、換行符導(dǎo)致json.loads報錯。原因模型輸出的 JSON 里可能包含未轉(zhuǎn)義的特殊字符或者用了中文標(biāo)點。解決在提示詞里明確“使用英文標(biāo)點輸出 JSON”并且在代碼里加一層清洗——用正則把中文引號替換成英文引號去掉 Markdown 代碼塊標(biāo)記后再解析。不要直接信任模型的輸出格式。5. 進(jìn)階技巧用 DeepSeek 做多輪任務(wù)編排把單次問答變成工作流單次提示詞能解決的任務(wù)有限職場里真正復(fù)雜的是多步驟工作流。比如“競品分析”這個任務(wù)拆開是收集競品信息 → 提取關(guān)鍵維度 → 對比分析 → 生成報告。每一步的輸入是上一步的輸出但又不是簡單的串聯(lián)——中間需要人工判斷和篩選。我現(xiàn)在的做法是用 DeepSeek 做“任務(wù)編排器”。先讓模型把復(fù)雜任務(wù)拆成步驟清單然后我確認(rèn)步驟是否合理再逐步執(zhí)行。這個思路來自那份 PDF 里提到的“分步提示”方法但我加了一個反饋環(huán)節(jié)每一步執(zhí)行完后讓模型自己檢查輸出是否滿足下一步的輸入要求不滿足就重新生成。具體實現(xiàn)上我用一個簡單的狀態(tài)機來管理# DeepSeek 多輪任務(wù)編排示例 # 任務(wù)競品分析報告生成 steps [ {name: 信息提取, prompt: 從以下文本中提取競品名稱、核心功能、定價策略{input}}, {name: 維度對比, prompt: 基于以下競品信息按功能/價格/目標(biāo)用戶三個維度做對比表格{input}}, {name: 報告生成, prompt: 基于以下對比表格生成一份 500 字的競品分析摘要面向管理層{input}} ] current_input 原始競品資料文本... for step in steps: prompt step[prompt].format(inputcurrent_input) response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.3 ) current_input response.choices[0].message.content print(f {step[name]} 完成 ) print(current_input[:200] ...\n)這個模式的關(guān)鍵在于每一步的輸出都作為下一步的輸入但你可以隨時中斷檢查。我一般會在“維度對比”那一步人工看一眼因為如果提取的信息有誤后面的報告就全歪了。另外temperature在編排模式里建議統(tǒng)一設(shè) 0.3保證每一步的輸出風(fēng)格一致。還有一個技巧是“反向驗證”報告生成后讓 DeepSeek 自己檢查報告里的每個結(jié)論是否都能在原始資料里找到依據(jù)。找不到依據(jù)的結(jié)論標(biāo)紅人工復(fù)核。這個動作能攔住大部分幻覺問題。我試過在客戶提案場景里用這個流程原本需要半天整理的競品分析壓縮到了 40 分鐘而且質(zhì)量比我自己寫的還穩(wěn)定——因為模型不會漏掉我可能忽略的維度。最后說一個我踩過的坑不要試圖用一個超長提示詞搞定所有步驟。我試過把整個競品分析流程寫在一個提示詞里結(jié)果模型在中間步驟就開始偷懶輸出質(zhì)量斷崖式下降。拆成多輪后每一步的提示詞都很短模型反而更專注。這個教訓(xùn)讓我明白提示詞工程的核心不是“寫得多”而是“拆得對”。希望幫到你。本文還有配套的精品資源點擊獲取