如何使用 GPT-6：五類實用任務與提示詞範本

開始使用 GPT-6 Astra，最有效的方法是給它一個明確的交付目標、完成目標所需的材料，以及清楚的成功標準。選擇自己足夠了解、能夠審核的任務，例如研究簡報、報告修訂、試算表檢查、網站 QA，或困難故障調查。

當工作涉及多個相關來源或步驟時，Astra 值得一試。先從規模適中的任務開始，再推進大型專案。GPT-6 評測介紹了存取方式與總體優勢；本文重點說明獲得存取權限後，應該如何佈置任務。

來源: OpenAI 存取指南; Claire Vo 的提前體驗案例。核對日期：2026 年 9 月 7 日。下文中的測試結果和體驗均注明作者。

從交付成果開始

“研究一下我們的競爭對手”這類寬泛請求，會留下許多關鍵決策。有效的簡報應說明待做決策、受眾、來源範圍、輸出形式和審核標準。這樣既給模型留出調查空間，也讓最終結果符合預期。

為[受眾]製作一份兩頁的決策摘要。
需要決定的是[具體問題]。
使用[附件和允許使用的公開來源]。
按照[標準]比較[選項]。
為事實性主張附上來源，並標注缺失資訊。
最後給出建議、取捨和下一步行動。

選擇具有所需工具的使用入口。除非執行環境授予存取能力，否則對話中的模型無法檢查本地應用。OpenAI 的可用性指南區分 Chat、Work 和 Codex；你能看到的控制選項取決於方案與產品。

五類適合入門的任務

將來源整理成研究簡報

讓 Astra 先比較證據，再起草敘述。事實清單只有能幫助作出決策時才有價值。先讓它識別分歧、缺失日期和未經證實的假設。

閱讀這些來源，建立主張與來源的對應表。
找出可能改變決策的分歧。
然後撰寫比較兩個選項的簡報。
除非解釋清楚，否則不要用不確定的主張支撐建議。

親自開啟幾條引用，尤其是支撐建議的引用。寫得流暢的回答仍可能誤讀來源，並按可重複的流程核查 AI 內容。

修訂報告，同時保留原意

提供現有草稿，並指定具體讀者。把事實修正與表達調整分開，方便分別接受。如果來源不支援某句話，讓模型提出批注，而不是編造替代內容。

展示試算表前先檢查

說明哪些工作表和輸出最重要。要求列出公式不一致、重複記錄、缺失值及不相容單位，再抽樣核對原始記錄。清理後的活頁簿應保留原始資料，並解釋調整內容。

利用瀏覽器存取開展 QA

Claire Vo 的提前體驗節目將瀏覽器 QA 列為實際用途。一個可重複使用的方法是：給 Astra 三條關鍵使用者流程，要求輸出可重現的問題。每項發現應包含初始狀態、操作、預期行為、實際行為和證據。最重要的失敗應手動復查。

調查棘手故障

修改程式碼前，先讓模型重現問題。有用的調查結果應包括失敗路徑、佐證根因的證據，以及建議的最小改動。GPT-6 程式開發評測解釋了為什麼測試覆蓋與實際功能行為需要分別檢查。

選擇合適的任務環境

寫詳細簡報之前，先檢查目前工作階段實際能存取什麼。它能讀取活頁簿、開啟預覽、搜尋網頁並創建所需檔案嗎？讓它盡早指出缺失輸入。來源無法存取，或任務需要可編輯資料而工具只能回傳截圖時，再強的模型也無法彌補。

瀏覽器任務應提供起始頁面和要使用的帳號或工作區。檔案任務應說明哪些檔案是權威依據，以及新版本是否替代舊版本。研究任務應說明時間範圍和市場。這些小細節能避免模型精心回答了錯誤的問題。

OpenAI 在 GPT-6 使用指南中提到，模型可能提出更多澄清問題，也可能使用超出使用者預期的格式。應告訴它哪些日常選擇可以自行決定，以及最終輸出的形式。當你需要的是完成的草稿，而非對可能方案的討論時，這尤其有用。

自行合理安排結構和措辭。
改變受眾、範圍或基本假設前先詢問。
如果缺少一個細節，繼續完成不依賴該細節的部分。
最終簡報使用短段落和一張比較表。

完整示例：製作供應商決策簡報

假設你需要在兩家軟體供應商之間作選擇。手頭有方案、內部需求清單、會議筆記，以及預估用量的試算表。這是一個可以按需改編的示例：只有多個來源相互一致，建議才有實際價值。

第一步：確定比較規則

要求模型選出贏家之前，先定義決策標準。例如，實施工作量可能比少量許可證價差更重要。告訴 GPT-6 哪些需求是硬性要求，哪些只是偏好。缺失的必需功能不能被平均分掩蓋。

根據需求檔案比較方案 A 和方案 B。
區分硬性要求與偏好。
使用用量試算表計算成本場景。
不要從供應商的籠統宣傳中推斷某項功能存在。
推薦供應商之前，先列出尚無答案的問題。

第二步：檢查證據表

要求每項需求單列一行，標示佐證該需求的文件與章節，並區分“有依據”“存在反證”“未找到”。“未找到”也是有價值的結果：它能形成需要供應商回答的精確問題，防止模型用猜測填補證據空缺。

優先檢查可能改變決策的條目。與模糊的整合要求、不包含的服務或計價假設相比，輕微的措辭差異通常不值得同等關注。

第三步：產生簡報和後續問題

證據表通過審核後，再要求給出建議、備選方案，以及在哪些條件下建議會改變。供應商問題應放在單獨章節，方便同事直接使用，而不必從長篇敘述中提取。

最終成果應讓沒讀過來源檔案的人也能理解為什麼這樣選，並能輕鬆追溯決定性主張的依據。

三組日常工作提示詞

報告編輯

將這份報告修改為適合營運總監閱讀的版本。
保留數字、日期和已聲明的假設。
減少重複，讓建議更容易找到。
回傳修訂稿，以及一份簡短的待解決事實問題清單。
不要擅自用新主張替換缺乏依據的主張。

分享草稿前先檢查問題清單。如果模型指出來源衝突，應同時修正來源材料和正文。否則，同樣的不一致會在下一份報告中再次出現。

試算表分析

在我準備管理層摘要之前檢查這個活頁簿。
找出不一致的公式、單位、缺失值和重複項。
每個問題注明工作表、儲存格或行，以及可能影響。
保持原始資料不變，單獨提出修正建議。
只總結能夠追溯到已驗證計算的結果。

要求解釋關鍵數字背後的計算。區分空白與零、實際值與預測值。即使公式正確，如果輸入使用不同週期或貨幣，也可能得出錯誤結論。

網站 QA

在預覽中檢查這些流程：[三條流程]。
使用提供的測試資料。
記錄初始狀態、操作、預期結果和實際結果。
優先處理阻斷問題，再考慮外觀問題。
回傳可重現的發現，並說明哪些內容無法測試。

除了成功路徑，也檢查空狀態、載入狀態和錯誤狀態。如果表單看起來已經提交，應核實產生的紀錄或確認資訊。僅僅按鈕文字變了，並不能證明操作成功。

如何改進不理想的初次結果

結果太泛，就補充它必須支援的決策；結果太長，就說明讀者和長度；遺漏約束，就指出違反了哪項要求，並讓模型檢查相關章節是否存在同樣問題。這些修正比一句“再努力一點”更有效。

要求修訂時，應保留已經做好的部分。例如：“保留證據表，只修改建議，因為實施時間現在是我們的首要標準。”這樣能減少整體重寫時遺失有用來源對應關係的風險。

如果專案反覆停下或偏離方向，可參考 GPT-6 長任務指南中的里程碑和復原示例。更大的上下文視窗並不意味著不再需要明確的目前目標。

CodeRabbit 展示的 NIGHTSHIFT：在人類指導與反覆迭代下，使用 GPT-6 製作的遊戲。

控制首次執行的規模

設定時間或推理投入預算，並要求在任務無法完成時回傳有用的階段成果。研究任務可以交付已驗證發現和待解決問題；程式開發任務可以交付重現步驟和修正方案；報告修訂可以說明已檢查及待檢查章節。

不要只看最後一條訊息來判斷執行品質。開啟交付成果，檢查困難部分，並統計需要修改多少內容。真正有用的比較，是結果達到可用狀態之前還剩多少工作。

可重複使用的審核框架

1. 檢查所要求的交付成果是否存在。
2. 驗證最重要的事實或行為。
3. 找出模型在證據不足時作出的假設。
4. 將審核時間與原有流程比較。
5. 保留效果好的簡報，用於下一次同類任務。

將來源檔案、任務簡報和審核筆記放入 Ottermind，組織連貫的研究或文件專案。從期望結果出發，選擇適合任務的可用模型。

常見問題

第一次用 GPT-6 應該做什麼？

選擇有多個輸入、結果可以檢查的任務，例如基於來源的簡報或限定範圍的 QA。

提示詞必須很長嗎？

關鍵是簡報清晰。包含目標、材料、約束、輸出形式和驗收標準；單純增加長度沒有幫助。

應該使用最高推理強度嗎？

先使用目前介面提供的普通或中等設定。只有困難案例確實受益時，再提高強度。

可以重複使用同一份簡報嗎？

可以。保留任務結構，更新來源、日期和驗收條件，並移除上一個專案留下的假設。

如何知道任務真的完成了？

根據簡報中的標準檢查實際交付成果。模型自信地宣佈完成，並不足以作為依據。