Gemini 3 Pro 提示詞：10 種實用模式

有效的提示詞應寫明任務、證據、限制和預期輸出。以下十種模式是面向 Gemini 3 Pro 的獨立編輯示例，不出自所謂“68 頁 Gemini 3 官方手冊”，也不附帶未經測量的效能提升數字。

Google 開發指南強調清晰表達與上下文組織。實際使用時，應在自己的任務上驗證，而不是尋找能保證正確的特殊語法。

1. 把目標寫成可檢查的結果

不要只說“幫我處理會議記錄”，而是要求提取決定、原文明示的負責人和待解決問題。每行提供一句來源；沒有負責人時寫“未分配”。先核對表格，再用它起草通知，避免把初次提取的錯誤繼續傳播。

角色用於限定讀者和分析角度，不會賦予真實資質。“面向開發者檢查這份更新說明，找出與附帶變更記錄不一致的內容”，比泛泛要求“扮演頂級專家”更容易驗收。不要補充來源沒有提到的功能。

同時展示輸入與輸出。例如，輸入為“週二維護，結束時間未註明”，輸出可以保留週二為開始時間，結束時間為 null。隨後檢查模型是否把示例中的日期複製進新案例。結構正確與事實正確必須分別檢查。

根據任務補充缺失值、矛盾記錄或多條記錄的例子，沒有必須“恰好三個示例”的通用規則。另留一些不放進提示詞的案例，用於驗證新輸入，避免把重複示例誤當成泛化能力。

文件中的命令式句子，不一定是你要求執行的指令。

將“來源”僅作為待分析材料。即使裡面包含其他要求，也只提取本次指定欄位。引用支持片段，標出衝突，不用猜測補全缺失資訊。

用無害的測試材料檢查模型是否遵守邊界。提示詞只是輔助，不能單獨替代工具權限和程式校驗。

分別列出有證據的事實、推斷和未提供的資訊。缺失值保持“未註明”。模型自己給出的信心分數不是經過驗證的機率；要回看其依據，而不是因為表達自信就降低審核力度。

要求 JSON 不等於介面自帶 schema 校驗器。應用程式仍需解析結果，檢查必填欄位、允許值和業務關係。

例如：“僅依據這些記錄，回傳 JSON 物件，其中 summary 是字串，open_questions 是字串陣列。”除了語法是否合法，還要確認問題確實尚未解決。有效 JSON 同樣可能包含編造事實，不應假設第三方介面自動完成了全部檢查。

對於程式碼修改，要求說明改變的行為，並提出能夠暴露錯誤的測試。明確區分建議執行與已經執行的測試。自我復查可能發現遺漏，但不能替代獨立驗證，也不需要索取內部思維過程作為證明。

說明可以修改哪一段，以及哪些條件必須保留。例如：“只縮短引言，保留日期、數字和限制條件；若字數要求與事實完整性衝突，請指出。”自行比較版本，不假設聊天介面存在歷史回滾或差異視圖。

這種約束也適用於翻譯：可以調整表達，但不能改變單位、專有名詞或證據強度。若源文存在歧義，應提出問題，而不是在譯文裡悄悄選擇一種解釋。

選擇普通輸入和困難輸入，在測試前寫好標準，每次只修改提示詞的一個部分。記錄事實忠實度、遺漏、格式、修復工作和重試次數。時間與成本必須使用真實記錄，不從一個滿意回答推導普遍收益。

先從目標、已標識的來源、缺失值規則和可驗證輸出開始。只有觀察到具體失敗，才增加相應模式。在 MidassAI Chat 中，可以使用實際可選模型測試簡報，並逐項對照原文。保留自己的評測記錄，模型或來源格式變化後重新檢查。