GPT-6 Astra 推出以後很多人迫不及待想要體驗新模型的能力，但根據 OpenAI 的文件說明，GPT-6 Astra 不只是比 GPT-5.6 更強的模型，它也更容易受到 AGENTS.md、Skill 與其他上下文指令影響。原本在 GPT-5.6 上只是偶爾造成輸出不穩定的重複規則、模糊權限或互相衝突的要求，換到 Astra 後可能被執行得更徹底，結果反而變成過度詢問、做到一半停下來，或花太多時間測試。升級前真正該做的事，是先整理整套 Agent 指令。
OpenAI 對 Astra 的定位，是目前能力最完整的旗艦模型，強項涵蓋電腦操作、瀏覽、軟體工程、科學與專業工作，也更擅長跨程式碼、瀏覽器及專業軟體完成多步驟任務。官方同時提醒，Astra 對 Skill、AGENTS.md 等檔案內的指令更加敏感，因此不能只替換模型名稱就期待原有流程原封不動地運作。
GPT-6 Astra 和 GPT-5.6 的使用差異
GPT-5.6 的調校重點是精簡提示詞、清楚界定自主範圍與權限，並以較少輸出 token 完成複雜工作。Astra 延續這些能力，進一步提升長任務的一致性、指令遵循與多步驟操作能力，但也帶來幾個需要重新調整的行為。
| 項目 | GPT-5.6 | GPT-6 Astra | 實際影響 |
|---|---|---|---|
| 長任務 | 已具備良好目標理解與多步驟執行能力 | 長任務中的脈絡一致性更強 | 適合把完整成果與驗收條件交給模型 |
| 遇到模糊處 | 較常依上下文自行推斷 | 影響結果的資訊不足時，更傾向詢問 | 若希望自主完成，要明確授權合理假設 |
| 指令敏感度 | 精簡提示詞通常有較佳效率 | 更忠實執行 Skill、AGENTS.md 與其他檔案 | 舊規則的衝突與重複更容易被放大 |
| 輸出風格 | 官方稱相較 GPT-5.5 預設更精簡 | 容易提供詳細內容、Markdown、表格與固定句型 | 應明訂篇幅、段落與格式，不要只寫「簡短」 |
| 子代理 | GPT-5.6 已支援多代理協作 | 具備更強的分工能力，但不一定會主動大量委派 | 需要明訂何時拆分、哪些工作可平行處理 |
| 測試 | 可依任務設定驗證流程 | 寫程式時傾向做較完整的測試 | 小修改要限制測試範圍，避免驗證成本失控 |
| 執行中的修正 | 一般以新回合補充要求 | 新增執行途中轉向能力 | 工作進行中可補充需求，不必整個任務重來 |
根據 OpenAI 公布的資料，Astra 雖然單位 token 價格可能較高，但在官方評測中能以較少輸出 token 取得更好的結果，因此每個任務的估算 API 成本可能低於舊模型。不過這不代表每種工作都會自動省錢，仍要用自己的典型任務比較成功率、延遲、token 與總成本。
AGENTS.md 要改的不是格式，而是指令品質
AGENTS.md 是 Codex 每次工作前自動載入的專案規則。它可以分成全域、專案根目錄及子目錄等層級，越接近目前工作目錄的檔案，優先度越高。Astra 會更認真執行這些內容，所以第一步不是增加更多規則，而是清查現有檔案。
1. 同一件事只寫一次
如果全域與專案層級都反覆寫著「修改前要詢問」、「不能自行變更」或「所有動作都要確認」，Astra 可能把這些句子解讀成更嚴格的限制，即使只是讀檔、修正可逆的小問題，也可能先停下來等待同意。
建議把權限規則集中在一個區塊，直接分成三類：可以自行執行的可逆工作、必須確認的外部或破壞性操作，以及不得執行的事項。其他章節不要再以不同說法重複同一條規則。
2. 明訂自主完成的邊界
若你希望 Astra 接到「幫我修正這個問題」後直接做到完成，AGENTS.md 應寫清楚：這類要求代表模型可檢查相關檔案、修改範圍內程式、執行必要測試並整理結果；只有發布、付款、刪除資料、變更正式環境或大幅擴張工作範圍時才需要再次確認。
相反地，如果使用者只要求分析、說明或提出計畫，就應保持唯讀，不要把「看一下問題」自動擴大成修改與部署。關鍵是依請求類型定義權限，而不是用一條「凡事先問」涵蓋所有情境。
3. 明確寫出指令優先順序
Skill 可能提供通用工作流程，但使用者當下的要求通常包含更具體的目標。建議在 AGENTS.md 中明訂：使用者對本次任務的明確要求，高於 Skill 的一般建議；安全限制與系統權限仍然有效。遇到衝突時，模型應指出衝突來源與採取的處理方式。
這能降低一個常見問題：Skill 要求固定輸出五個項目，但使用者這次明確只要其中兩個，模型卻仍被舊工作流綁住。
4. 把寫作風格具體化
Astra 容易使用較多標題、條列與表格。如果你要的是連貫文章，應直接寫明段落長度、哪些資訊適合列表、是否接受巢狀條列、專有名詞的使用方式，以及結論是否需要再次摘要。
「專業、友善、簡潔」這類形容詞不夠精確。更有效的寫法是：「先說結論，再補足證據與下一步；段落各自發展一個完整觀點；只有平行比較或操作步驟才用列表；刪除重複摘要與空泛開場。」
5. 限制子代理與測試範圍
如果工作環境支援多代理協作，應告訴 Astra 什麼情況值得拆分，例如有兩個以上互不依賴的研究或實作項目，而且平行處理能明顯節省時間。若任務很小、共用狀態很多，或拆分後整合成本較高，就不必委派。
測試也採取相同原則。修正核心邏輯或高風險功能時執行完整測試；文字、樣式或低影響且容易回復的修改，只跑與變更直接相關的檢查。官方特別提醒，Astra 在程式任務上可能比需求更積極地驗證，因此這項限制相當實用。
一份適合 Astra 的精簡 AGENTS.md 範例
# 專案工作規則
## 任務與權限
- 回答、分析、檢查或規劃：讀取必要資料並回報，不修改檔案。
- 修改、建立或修正：完成範圍內變更，並執行與變更相符的檢查。
- 發布、付款、刪除資料、變更正式環境或擴大工作範圍：執行前取得確認。
- 使用者在本次任務中的明確要求，優先於 Skill 的一般流程。
## 工作方式
- 從既有程式與文件確認現況，不猜測未檢查的內容。
- 資訊足以判斷時採取合理假設並繼續；會改變成果方向時才提問。
- 遇到指令衝突時，指出來源、衝突內容與採用的規則。
- 只有兩個以上可獨立進行的工作項目，才考慮使用子代理平行處理。
## 驗證
- 執行與變更風險和範圍相符的測試。
- 小型、可逆且不涉及核心邏輯的修改，不新增只重複實作內容的測試。
- 完成時說明變更、驗證結果與仍存在的限制。
## 回覆風格
- 先說結果，再交代必要依據與下一步。
- 使用清楚完整的段落；只有比較與操作步驟才使用列表或表格。
- 避免重複結論、空泛稱讚與不必要的免責文字。這份範例不是要取代每個專案的工程規範，而是提供一個適合 Astra 的行為骨架。建置指令、目錄結構、程式風格及正式環境限制，仍應依專案實際情況補上；沒有反覆發生的問題，不必預先堆進文件。
OpenAI 官方提供了哪些提示詞範例？
OpenAI 在 Astra 指南中直接提供多組英文提示詞，用來修正模型容易提前詢問、受到 Skill 衝突影響、輸出格式過多、較少主動委派子代理，以及小修改測試過度等情況。以下保留官方範例的核心意圖，改寫成適合直接放進 AGENTS.md 或系統提示詞的中文版本；這些是依官方內容整理的中文表達，並非 OpenAI 發布的逐字中文版。
範例一：希望 Agent 更主動把工作完成
請根據使用者的指令與既有對話，推斷合理的任務目標與範圍，並以完成成果為優先。當使用者要求建立、修改或修正某項工作時，在授權範圍內持續處理到目標完成。
可逆、唯讀及任務所需的本機操作可以自行執行；涉及破壞性、不可逆或超出原始範圍的操作時，再向使用者確認。這段適合放在經常「只提出計畫、做一半就停下」的 Agent 設定中。重點不是要求模型無條件行動，而是讓它知道哪些已由任務本身授權，哪些操作仍須停下確認。
範例二：把「可以幫我」視為實際工作要求
當使用者以「幫我」、「我想要」或「可以處理」等方式提出明確工作需求時，將它視為執行要求。不要只回覆能否做到、停留在計畫，或在成果尚未完成時提前結束。
需要多個步驟的工作，應持續處理必要項目，直到符合使用者要求的完成條件。Astra 比早期模型更可能在關鍵資訊不足時提問，這本身不是缺點；這段規則處理的是意圖已經清楚，模型卻只回覆「可以」或先問要不要開始的情況。
範例三：先準備可審核成果，再要求最後確認
在提出澄清或批准要求前，先完成目前資訊與權限已允許，而且能讓下一個決定更具體的工作。需要部署、發布、合併或寫入外部系統時，先完成草稿、檢查與必要準備，讓使用者確認的是一個可審核的成果。
不要為可逆、唯讀、範圍內修正，或先前已明確授權的工作重複要求許可。例如使用者要求部署網站時，Agent 可以先完成程式、測試與部署前檢查，最後才針對正式發布取得確認，而不是在還沒有任何成品時就停止工作。
範例四：解決 Skill 與使用者要求衝突
使用者針對本次任務提出的明確指令，優先於 Skill 中的一般工作建議。兩者發生衝突時，依使用者的具體要求執行；仍須遵守系統權限、安全限制與不可違反的必要條件。
若 Skill 導致工作暫停、要求額外許可或偏離使用者目標，請指出使用的 Skill、造成影響的規則，以及它如何改變目前流程。官方特別提到，Astra 對 Skill 與 AGENTS.md 的內容更敏感。加入透明說明後，使用者至少能知道模型是被哪條規則卡住，而不是只收到模糊的拒絕或確認問題。
範例五：減少過度排版與制式 AI 語氣
預設使用清楚、精簡且連貫的段落，每段發展一個主要觀點。只有資訊具有平行、順序或比較關係，而且列表確實更容易理解時才使用條列；除非層級不可避免，否則不要使用巢狀列表。
開頭直接說明主要結論，再補上必要理由、證據與行動。使用常見、具體的詞彙與主動語態，避免空泛開場、重複總結、制式轉折與不必要的術語。如果產品需要固定格式，還應明確寫出字數、標題層級、是否使用表格，以及必須保留的資訊。只寫「簡潔」仍可能讓模型刪掉真正重要的內容。
範例六：明確規定何時使用子代理
當任務可拆成兩個以上彼此獨立的工作項目，而且平行處理能明顯縮短時間或提高品質時，使用子代理分工。為每個子代理指定清楚的範圍、輸入與交付成果，最後由主代理核對並整合結果。
若工作依賴同一份持續變動的狀態、任務規模很小，或拆分後整合成本高於效益，則由主代理直接完成。官方的原始範例偏向鼓勵「可以平行就委派」，實際採用時仍應依工具成本與工作環境補上限制，否則很小的任務也可能產生不必要的多代理開銷。
範例七：限制不必要的測試
依變更的範圍與風險執行有意義的測試。對可逆、低影響，而且測試內容只會重複實作細節的修改，不要為了形式新增測試。
必要檢查通過後，只有在後續又有新變更、測試失敗或仍存在未解風險時，才擴大或重複測試；否則繼續完成交付工作。這段並不是要求 Astra 少測，而是把驗證強度與風險連結。登入、付款、資料庫遷移或權限邏輯仍應完整測試；修改一段說明文字或可快速回復的樣式，不必因此跑遍所有端對端流程。
以上範例都能放進 AGENTS.md，但不建議全部原封不動加入。先找出目前 Agent 真正反覆出現的問題，再選擇相對應的規則，否則文件越來越長，仍會回到指令重複與衝突的老問題。完整英文範例可直接參考 OpenAI 的 GPT-6 Astra Model guidance。
Skill 應該從「萬用說明書」改成單一工作流程
Skill 是由 SKILL.md、必要的參考資料，以及可選的腳本或素材組成。ChatGPT 與 Codex 會先根據名稱和 description 判斷是否適用，確定使用後才載入完整內容。Astra 對 Skill 指令更敏感，因此 description 與適用邊界尤其重要。
每個 Skill 只處理一種工作
「研究、寫作、發文、監控、回覆留言」全部塞進一個 Skill，容易讓每次觸發都帶入大量不相關規則。比較穩定的做法，是把研究與查核、長文撰寫、社群改寫或實際發布拆成清楚的工作單位，並由使用者或上層流程決定這次要啟用哪些 Skill。
description 要寫清楚何時用、何時不用
Skill 是否會被自動啟用，主要取決於名稱與描述。描述應把最重要的觸發情境放在前面，列出使用者實際會說的詞，並補充不適用的邊界。不要只寫「協助處理內容」，這幾乎無法讓模型穩定判斷。
刪除模糊的強制詞
必須、永遠、嚴禁 適合真正不可違反的要求，例如不得捏造來源；不適合拿來描述偏好的工作順序。若所有步驟都寫成絕對規則，一個例外就可能使 Astra 判斷流程衝突並停住。
可以把規則分成「必要條件」、「預設做法」與「符合特定情況才執行」。如此一來，模型才能在保留底線的同時，依任務情境調整流程。
為中止條件加上透明說明
當 Skill 真的要求暫停、取得許可或等待資料時，應要求模型指出是哪個 Skill、哪條規則造成中止，以及使用者還需要補充什麼。這能避免模型只回覆「我需要確認」，卻沒有說明被什麼條件卡住。
用實際案例驗證，而不是一次寫滿例外
OpenAI 建議 Skill 先聚焦兩到三個明確使用情境，定義輸入、輸出及觸發詞，再從代表性任務逐步改善。Astra 更適合這種做法，因為它會更精確地執行已寫下的規則；過早加入大量假設性例外，只會提高衝突機率。
對 Astra 下指令時，四個欄位比長篇步驟更重要
使用者不必每次都寫一大串流程。對 Astra 來說，一個高品質任務通常只需要交代四件事：目標、相關背景、限制，以及完成條件。
目標：修正結帳頁在手機上無法送出的問題。
背景：相關程式在 src/checkout，錯誤只出現在 390px 寬度。
限制：不要更換表單套件，也不要部署正式環境。
完成條件：找出原因、完成修正、跑過相關測試，並說明修改內容。若希望模型自主完成，可以再補一句：「現有資訊足以判斷時請直接採取合理假設；只有缺少的資訊會改變方案或涉及不可逆操作時才詢問。」這比籠統地說「不要問我」更安全，也能降低 Astra 因謹慎而提前停下的情況。
工作進行中若發現方向需要修正，Astra 新增的執行途中轉向能力可保留已完成的工作，再把新要求納入後續處理。對長時間的 Agent 任務來說，這比取消後重新開始更實用，但應清楚指出哪些既有成果保留、哪些部分需要重做。
從 GPT-5.6 遷移時還要檢查 API 設定
除了提示詞與工作文件，API 使用者還有幾項相容性事項要處理：
- 模型名稱改成
gpt-6-astra。 - Astra 不支援
none推理強度；原本使用none或minimal時，可先從low測試。 - 工具呼叫應使用 Responses API；雖然 Astra 支援 Chat Completions，但工具呼叫需走 Responses API。
- 移除
temperature、top_p與top_logprobs等不支援參數。 - 若同一段對話要調整推理強度，可使用
configuration_update，避免重寫提示詞前綴而失去快取效益。 - 從 GPT-5.5 或更舊模型遷移時，要一併檢查提示詞快取欄位的變更。
Astra 也新增非同步工具呼叫，可在應用程式執行某個工具時繼續思考、處理其他獨立工作或呼叫別的工具。不過是否能真正縮短時間，還取決於 Agent 框架是否正確管理尚未完成的呼叫與回傳結果，並不是換模型名稱後就會自動得到完整效果。
升級 Astra 前的實際檢查順序
先盤點所有會自動載入的全域與專案 AGENTS.md，找出重複、衝突與過度寬泛的禁止事項；接著逐一檢查常用 Skill 的觸發描述、必要條件、預設流程及中止規則；最後用十到二十個真實任務，同時測試 GPT-5.6 與 Astra 的成功率、詢問次數、總耗時、token、工具呼叫及測試範圍。
如果 Astra 經常問到一半停下來，先檢查自主權與批准邊界；如果輸出太長、表格太多，補上具體的文章結構；如果 Skill 常在不該觸發時介入，重寫 description；如果小改動跑了整套測試，就限制驗證規模。這些問題多半不需要更多提示詞，而是需要更準確的提示詞。
更強的指令遵循能力，代表好的規則會得到更穩定的成果，壞的規則也會被更忠實地執行。對準備從 GPT-5.6 升級 Astra 的團隊來說，模型切換只是一行設定，真正的遷移工作則是整理 Agent 的操作契約。
