DeepSeek 提示詞工程實戰指南

更新時間：2026-08-12。模型能力與入口以 DeepSeek 官網 及當前帳號頁面為準。

導讀

DeepSeek 提示詞、DeepSeek 提示詞工程的核心不是堆「專業、深入、一步一步」，而是把任務寫成可驗收的規格：目標、證據、限制、輸出契約與質檢標準。上下文清楚時，DeepSeek 較容易穩定產出可改稿；上下文模糊時，它也會自信地空泛或編造。本文提供可重用的六要素結構、四類場景模板，以及用樣例集迭代提示版本的方法。

這篇解決什麼問題？

• 用六要素把「隨便問問」改成可執行的任務書
• 取得寫作、分析、程式、推理四類可直接貼上的模板
• 用診斷表定位空泛、格式漂移、幻覺、過長等問題
• 用固定樣例集評估提示版本，而不是憑一次「感覺不錯」

六要素提示結構

把每次請求寫成六段（可壓縮成短提示，但邏輯順序不要亂）：

1. 任務：用動詞寫清要交付什麼（改寫、抽取、診斷、對比……）
2. 背景：讀者是誰、場景是什麼、目前卡在哪
3. 資料：模型必須依據的原文、資料、報錯、政策片段
4. 限制：長度、語氣、禁止項、不得虛構、資料外標「未知」
5. 格式：標題欄位、表格、JSON、清單或固定段落順序
6. 驗收：什麼叫完成——必須保留的事實、必須通過的自檢項

角色：[可選，一句話即可]
任務：[動詞 + 交付物]
讀者 / 場景：[誰用、做什麼決策]
資料：僅使用下方內容；缺失處寫「未知」，禁止猜測。
限制：[字數/語氣/禁止項/保密]
格式：[欄位或結構]
驗收：[必須核對的事實、通過條件]
完成後按限制逐項自檢，再輸出。
資料：
"""
[貼上]
"""

最短可用版（日常對話）：「目標 → 證據 → 限制 → 輸出結構 → 未知時先問」。先跑短提示，再只補失敗點，比一次寫超長「萬能提示」更穩。

四類高頻場景與模板

1. 寫作與改寫

目標是保留事實、服務讀者行動，而不是「更華麗」。

面向[讀者]改寫下列資料，使其完成[行動]。
保留全部日期、數字、產品名與連結；不得新增未出現的功能或承諾。
輸出：
1) 正文（≤[N] 字，語氣：[正式/口語]）
2) 相對原文的語意變化清單（無則寫「無」）
3) 仍缺的資訊（最多 3 條）
資料：
"""
[貼上]
"""

2. 分析與比較

先定維度與權重，再填表；缺證據的格子寫「未知」，不要強制決出贏家。

按下列加權維度比較[選項 A/B/C]，只依據所給資料。
維度（權重）：[成本 30%] [風險 30%] [落地速度 20%] [可維護性 20%]
輸出表格：維度 | A | B | C | 證據段落編號 | 置信度
另附：結論（1 段）、關鍵未知項、建議的下一步驗證。
禁止用常識補全資料中沒有的數字。
資料：
"""
[編號段落]
"""

3. 程式與排錯

提供環境、最小程式碼、完整堆疊與預期行為；要求先測試／驗證命令，再給最小修補。

環境：[語言/框架/版本]；禁止新增相依套件。
任務：[實作函式 / 診斷報錯]
預期 vs 實際：[…]
完整錯誤堆疊 / 相關最小程式碼：
"""
[貼上]
"""
輸出順序：
1) 最可能根因（1 個）+ 證據行
2) 我可複製執行的驗證命令
3) 最小修補說明
4) 回歸測試點
證據不足時先提 ≤3 個澄清問題，不要給大段猜測程式碼。

更完整的程式設計流程見：DeepSeek 程式設計實戰。

4. 推理與多約束決策

編號列出已知與硬約束，要求回傳結論、可檢查依據、約束核對與獨立驗證方法。需要深度推演時可配合推理模式，見：R1 推理解析。

已知事實（編號）：
1. …
2. …
硬約束（不可違反）：…
目標決策：[…]
請輸出：
- 結論（一句話）
- 推理步驟（對應事實編號）
- 約束核對表（每條：滿足/違反/未知）
- 獨立驗證方法（我可不依賴模型再查一次）
- 若事實衝突：列出衝突點，不要強行統一
禁止引入未編號的「常識事實」。

迭代診斷表：先定位失敗，再改提示

不要只說「再詳細一點」。一次只改一個變數，並保留同一測試輸入。

症狀	常見原因	改法
內容空泛	缺受眾、缺資料、目標含糊	補場景 + 貼上證據 + 明確交付物
格式漂移	只口頭描述結構	給固定欄位名或一行示例
編造事實 / 幻覺	強迫必須作答	允許「未知」；限定只用所給資料
過長灌水	未設範圍與優先級	指定字數、段落數、先寫結論
漏關鍵限制	限制埋在長文中間	把硬限制單獨成段並放驗收裡
改了一處壞了另一處	一次改太多指令	發「修補指令」：保留第 X 節，只重寫第 Y 節
程式碼不可執行	缺版本與邊界	寫死環境；先要測試表再要實作

修補指令示例：

保留第 1、3 節不變。
只用附件政策重寫第 2 節；每條主張標註資料段落編號。
遇到衝突只標記，不自行仲裁。輸出後按驗收清單自檢。

用樣例集評測提示版本

「感覺更好」不可複現。團隊或個人應維護一套小樣例集：

1. 準備 12–20 個代表性輸入（寫作／抽取／推理／程式各若干）
2. 為每個樣例寫期望：必含事實、禁止項、格式是否有效、允許的未知處
3. 每次改提示後，用同一模型入口與參數重跑全套
4. 評分維度建議：準確、完整、格式通過、無依據主張數、人工修改分鐘數
5. 記錄：提示版本號、日期、入口（網頁／API）、模型名（以頁面為準）

通過測試的短提示，優於聽起來專業卻未測過的長提示。API 側版本管理可結合：DeepSeek API 入門。

日常檢查清單

• 任務用動詞寫清交付物
• 有資料時已貼上，並聲明「資料外寫未知」
• 硬限制獨立成段（長度、禁止虛構、保密）
• 輸出格式可機器／人工直接驗收
• 失敗時用診斷表定位，一次只改一處
• 重要流程有固定樣例集與版本記錄
• 敏感內容已脫敏後再上傳

存取與入口

• 國內對話：DeepSeek V4
• 鏡像工作台：AI Chat Studio
• 官方聊天：chat.deepseek.com
• API 文件：api-docs.deepseek.com

同一提示在不同入口的結果可能不同；重要流程應固定入口、模型與提示版本後再評測。

常見問題

要不要寫「請一步一步思考」？

通常不必。清晰限制與可驗證輸出，比籠統要求「慢慢想」更有效。需要深度推演時，優先選推理能力並核對依據，而不是只加口頭咒語。

提示越長越好嗎？

不是。只保留完成任務必要的資訊，刪除衝突與重複。先短跑、再按失敗點修補，通常比一次塞滿「角色設定小說」更穩。

如何減少幻覺？

限定資料範圍、允許回答未知、要求可定位依據，並對日期、數字、連結做人工核驗。關鍵決策不要把模型輸出當唯一真相。

可以重用網路上的萬能提示嗎？

可作為起點，必須用自己的樣例集重測；換模型、換入口後舊提示可能失效。

角色扮演有用嗎？

可選，一句話足夠。真正拉開差距的是證據、限制與驗收，而不是更長的人設。

網頁對話和 API 提示寫法要分開嗎？

原則相同；API 更強調穩定格式（JSON／schema）、溫度等參數與版本記錄，詳見 API 指南。

官方資源

• DeepSeek 官網
• 官方聊天
• API 文件

下一步閱讀

• DeepSeek 程式設計實戰
• DeepSeek R1 推理解析
• DeepSeek V4 完整指南
• DeepSeek API 申請與開發入門

小結

提示詞工程本質是需求工程：任務、資料、限制、格式、驗收寫清楚，再用固定樣例迭代版本。把 DeepSeek 當可驗收的執行器，而不是「說得越多越好」的聊天對象，輸出品質與人工修改成本都會更可控。