GPT-6 Astra 讓「提示詞工程」過時了?Codex 團隊:Skills、AGENTS.md 不是越多越好

Neo
分享
GPT-6 Astra 讓「提示詞工程」過時了?Codex 團隊:Skills、AGENTS.md 不是越多越好

隨著 Coding Agent 能力快速進步,過去為了避免 AI 出錯而堆疊的大量提示詞、規則與操作流程,到了 GPT-6 Astra 時代,反而可能成為限制模型能力的包袱。

OpenAI 工程師 Eric Provencher(@pvncher)近日發文〈Rethinking skills and prompts for GPT-6 Astra〉指出,如果開發者過去一年持續使用 AI Agent,很可能已經累積大量用來「扶著模型走路」的指令,包括 Skills、AGENTS.md 與各種任務 Prompt。

但隨著 GPT-6 Astra 對模糊情境的理解、決策與自主執行能力提升,這些原本為舊模型設計的規則不只可能已經沒有必要,甚至可能降低新模型的表現。

廣告 - 內文未完請往下捲動

核心原則正在從「告訴 AI 每一步該怎麼做」,轉變成:告訴 AI 目標、必要知識與不能跨越的邊界,剩下的讓模型自己判斷。

Skills 不是裝越多越好,太多反而讓 AI 不知道該選誰

Provencher 首先點名 Skills。

Skill 本質上可以理解為儲存在 Markdown 文件中的專用提示詞,有時還會搭配腳本。它適合保存特定工作流程,或教 Agent 如何使用某個 Plugin,而不是把所有可能用到的知識全部塞進模型。

問題是,許多人習慣在專案中下載大量 Skills。

每個 Skill 的名稱與描述都必須進入模型 Context,讓 Codex 判斷什麼時候該調用它。當 Skills 數量過多、描述又太長時,系統甚至必須縮短描述才能塞進 Context。

結果反而讓模型取得更少資訊,更難判斷「現在究竟該用哪個 Skill」。

更糟的是,不同 Skills 的描述可能互相衝突,或者寫得太積極,彷彿每個 Skill 都在告訴模型「只要碰到相關領域就選我」,造成 Agent 載入其實與當前任務無關的指令。

因此 OpenAI 最近也更新了 $skill-creator 的指引。

第一個原則就是:Skill description 越短越好,只需要清楚告訴模型「什麼時候應該使用」即可。

例如,一個原本只負責資料庫 Migration 的 Skill,如果描述寫成任何與 Database 有關的任務都適用,就可能導致 Agent 在完全不需要 Migration 時也載入它。

「漸進式揭露」成為 Skills 設計核心

第二個關鍵概念則是 Progressive Disclosure(漸進式揭露)。

每當 Agent 讀取一個 Skill,就會占用更多 Context,同時把一批可能與目前任務無關的規則帶進推理環境。

因此,一個包含多種工作流程的 Skill,不應該把所有內容全部塞進主文件。

更理想的架構是:Skill 根目錄只是一個極簡 Router。

它只負責告訴 Agent:「遇到 A 去讀哪份文件、遇到 B 使用哪個腳本、遇到 C 再載入另一組規則。」

真正需要某項能力時,模型才進一步讀取相關文件。

這讓 Skills 從過去的「完整操作手冊」,逐漸變成一套按需載入的 Context 管理系統。

對長時間運作的 Agent 尤其重要,因為 Context 消耗越多,就越容易逼近 Compaction,過早壓縮前面的工作資訊。

Prompt 寫得越詳細,不一定越好

第三個變化更加反直覺。

過去的 Skills 經常被寫成極其詳細的 Recipe:第一步做什麼、第二步讀什麼、第三步檢查什麼,每個可能發生的情況都有明確規則。

這在能力較弱的模型上很合理,因為模型需要大量 Scaffolding 才能穩定完成工作。

但 Provencher 認為,新模型已經更擅長理解細微差異與模糊情境,過度具體的操作規則現在反而可能限制模型。

尤其 Repository 中的 Skills 不一定只給 GPT-6 Astra 使用,也可能被 Sol、Luna 或其他模型讀取。

某些能幫助舊模型的規則,對能力更強的 Astra 反而可能形成過度約束。

AGENTS.md 也該大掃除:不要叫 AI 每次改字都讀完整 Repo

同樣的問題也出現在 AGENTS.md。

AGENTS.md 的特殊之處,在於 Agent 只要進入該 Repository 工作,就會受到其中規則影響。

因此 Provencher 建議,升級 GPT-6 Astra 後應重新檢查每一條規則:這條指令現在真的還有必要嗎?

例如,過去可能要求模型「修改任何程式碼以前,先閱讀整套文件與 Repository Map」。

對大型重構可能合理,但如果任務只是修正一個 typo,要求 Astra 每次都掃完整個專案,只是在浪費 Context、增加延遲。

同樣地,舊模型可能需要 Prompt 明確提醒「完成後記得跑測試、檢查自己的工作」。

但 Provencher 表示,GPT-6 Astra 已經會自主進行這些工作,因此繼續保留相同規則,有可能造成不必要的重複測試。

少管一點,但要把「權限邊界」說清楚

這並不代表 Astra 不需要規則。

相反地,Provencher 認為開發者現在更應該把注意力放在 Decision Boundaries(決策邊界)。

舊模型可能曾經在未取得同意的情況下擅自行動,因此開發者會在 AGENTS.md 加入非常強硬的規則,例如「執行下一步以前必須詢問使用者」。

問題在於 Astra 更認真遵守這些限制,也具備更好的情境判斷能力。

結果可能變成:以前是為了阻止 AI 亂做事留下的護欄,現在卻讓 Agent 在完全安全、原本希望它自行完成的地方停下來等待批准。

人類不再 Micromanage AI 的每個步驟,而是定義 Agent 可以自主活動的安全範圍。

Astra 反而有一個問題:可能「太早回來問你」

有趣的是,Provencher 也指出 GPT-6 Astra 並非所有地方都比 GPT-5.6 Sol 更自主。

如果使用者已經習慣 Sol 接到任務後長時間一路做到底,Astra 有時反而會顯得更加謹慎。

它可能完成第一版 Implementation 後就回來要求 Review,即使後面還有啟動程式、檢查結果與修正錯誤等工作尚未完成。

解法不是再寫一大串工作 SOP,而是提前定義 Definition of Done(完成條件)。

如果希望 Agent 在第一版後繼續探索,也應該告訴它探索到什麼程度,以及什麼情況才應停止。

風險提示

加密貨幣投資具有高度風險,其價格可能波動劇烈,您可能損失全部本金。請謹慎評估風險。