你是不是還在用舊模型的指令來寫提示詞？
「每次都要讀這份文件」、「一定要測試」、「開始前先確認」。很多人可能都加過這些指令，就怕 Codex 出錯。
因為它之前沒讀文件就亂改，所以你才叫它先讀。因為它沒經過允許就亂動，所以你才叫它先確認再繼續。
這些句子在當時或許有道理，但模型換了之後，可能就沒那麼有用了。
那些為了輔助舊模型而訂下的流程，對 GPT-6 Astra 來說可能太過繁瑣。反過來說，因為你沒說清楚預期的範圍，它可能又會不必要地停下來請你確認。
需要檢討的不只是指令的數量。重點在於 減少重複性的任務，並釐清必要的場景與完成條件。
負責 OpenAI Codex 開發者體驗的 Eric Provencher，在一篇名為「為 GPT-6 Astra 重新思考技能與提示詞」的文章中談到了這個問題。
這涵蓋的不只是你在對話中寫的請求，還包括存放於儲存庫中、用來傳達工作規則的「AGENTS.md」檔案。
「技能」是用於特定任務的流程與知識集合。存放在這裡的指令也會影響 Codex 的運作方式。
在這篇文章中，我們將根據 Eric 的說明與參考圖片，來看看哪些該減少、哪些該保留，以及該如何改寫。為讀者建立的範例會標示為「應用範例」，以與原始範例區分。
這不是要把 Astra 的所有失誤都歸咎於舊指令。這篇文章是為了審視你累積下來的規則，看看哪些已經不適合當前的工作。
1. 為什麼你需要為 Astra 檢討指令
Eric 的出發點是，那些用來「監督」模型的指令，其必要性正在降低。
以前，有些任務除非你一步步指定順序，否則無法進行。為了彌補這種模糊性，我們堆疊了詳細的步驟與備註。
然而，原文指出，模型越來越能理解語意上的細微差異與模糊性。它點出，過去有幫助的詳細規格，現在反而可能阻礙結果。
我們不該誤解的是，這不是在討論「因為模型變聰明了，所以可以不用解釋」。
Eric 也建議將指引保留在必要的材料上。原文仍然要求針對安全的進展範圍與完成所需的工作進行說明。
即使是同一條指令，根據那句話想傳達的意圖不同，你檢討的方式也會改變。
例如，你需要區分哪些是傳達專案特定情況的說明，哪些是為了讓舊模型遵循流程而寫的。
「設計限制寫在這份文件中」是尋找資訊的線索。另一方面，「每次編輯都要從頭到尾讀完這份文件」則是統一規定了閱讀的時機。
告知模型有這份文件存在，並不等於要它每次都讀完所有內容。
同樣地，「禁止存取生產環境」和「即使在本地執行測試前也要確認」阻止的是不同的行為。
即使你想堅持前者，也不代表後者總是必要。然而，如果不確定某個動作是否真的只在本地執行，你也不該直接跳過那個確認。
原文中提到的技能、AGENTS.md 以及日常請求，都與這些判斷有關。即使你在對話中修改了一句話，但如果同樣的限制還存在於其他地方，審計就還沒完成。
例如，如果你在請求中寫了「做到能用為止」，但套用的流程卻仍然寫著「一律在完成首次實作後停下來請求審查」呢？
這是一個用來解釋指令衝突的範例。至少，如果不釐清使用者想要的是哪一個，請求的終點就沒有對齊。
在檢討時，不要用「太長了，所以刪掉」來判斷。要看那句話傳達的是必要的知識、決定了工作的範圍，還是只是讓模型重複先前的流程。
即使文字很短，但如果「確認所有東西」的目標很模糊，那也不見得是一條好指令。有時候，即使稍微長一點，但透過釐清閱讀的條件或停止的時機來傳達意圖，反而更好。
2. 應該減少的指令：重複性的載入與過於詳細的步驟
首先要審計的是那些無論工作內容為何都會觸發的載入規則。
Eric 解釋說，為了修正一個簡單的錯字，卻要模型讀取大量文件或整個儲存庫指南，這就太過頭了。
讀取文件會將那些內容放入模型的工作資訊中。原文指出了消耗可用脈絡並因載入不相關的說明而拖慢工作的問題。
這裡的脈絡指的是模型為該任務參考的資訊組合。如果它不斷增加，就會接近對話與工作歷史必須被壓縮的臨界點。
因此，與其只是減少參考的數量，不如區分當前請求需要讀取哪些內容。
範例 A：參考圖片的日文翻譯
修改前
每次編輯前，一律完整讀取 architecture.md、database.md 和 deployment.md。
修改後
處理服務之間的邊界時參考 architecture.md，變更資料庫結構時參考 database.md，準備部署時參考 deployment.md。
保留的是這三份文件的指引。改變的是開啟它們的條件。
在這個範例中，architecture.md 是關於服務的角色與連結。database.md 是關於資料庫的結構。deployment.md 是關於將成品反映到執行環境。
在「修改前」的版本中，即使是修正一個錯字的請求，也適用「讀取所有內容」的規則。在「修改後」的版本中，如果任務是變更資料庫結構，就會前往對應的 database.md。
這並不表示禁止讀取其他文件。如果任務跨越了多個領域，必要的文件就不只一份。
如果從這個範例中又創造出另一個「只能選一份文件」的統一規則，那就偏離了原意。
我們沒有刪除必要的文件或刪減內容。我們改寫了那個要求即使是小修改也要檢查所有文件的條件，使其符合工作內容。
Eric 也提到要保持文件更新。即使你整理了參考條件，仍然需要另外確認目標文件中是否還有舊的說明。
範例 B：根據原文的應用範例
接下來是一個應用在 Codex 負責文章、影片或社群媒體貼文等場景的範例。這不是 Eric 本人發布的生產流程。
修改前
進行內容創作時，請讀取所有關於文章、影片和社群媒體貼文的流程。
修改後
撰寫文章時參考 writing.md，製作影片時參考 video.md，創作社群媒體貼文時參考 social.md。對於多格式的請求，請參考相關的流程。
同樣地，文章、影片和社群媒體的具體流程都保留著。改變的是那個讓模型在「內容創作」這個大傘下讀取所有流程的部分。
如果你要求寫一篇文章，它就會前往文章的指令。如果你要求寫一篇文章並同時發布公告，它就會前往文章和社群媒體的流程。
如果沒有要求製作影片，它就不再需要在共同的入口點載入整個影片製作流程。
原文將這種分階段提供必要說明的做法稱為「漸進式揭露」。這是一種在入口點放置判斷目標的說明，同時將詳細的知識與流程分離到後續文件中的方法。
例如，如果你在入口點排滿了文章、影片和社群媒體的完整流程，那麼每個請求都會導致讀取大量的說明。
相反地，將入口點的角色限制在引導：「如果是文章，就去這份文件；如果是影片，就去那份文件。」你保留了詳細的說明而不丟棄它們，讓它們在需要時才被讀取。
Eric 解釋說，對於包含多個工作流程的技能，初始文件應該是一個最簡潔的指南。它應該只提供足夠的資訊，以便前往執行任務的相關文件或腳本。
建立一個狀態，讓只看入口點就能知道該前往哪份文件。僅僅將冗長的說明總結成簡短的說明，並不能完成這種參考的組織。
如果在總結中遺漏了必要的注意事項，那就會變成另一個問題。在上述的應用範例中，保留的是每種格式獨有的流程。
測試也被設定成「無論如何，一律執行」嗎？
原文指出，以前的模型需要被提示才能測試和確認工作。另一方面，Astra 會自己執行這些動作，所以同樣的指令可能導致不必要的重複測試。
不要誤解成「Astra 不需要測試」。問題不在於停止檢查，而是在於指令是否導致了重複的檢查。
如果要將此應用到你自己的設定中，請檢視你針對哪個變更請求了哪個檢查。必要檢查的內容以及每次做事時都統一重複的條件，可以分開審計。
由於這篇文章沒有比較測試次數或處理時間，所以不會顯示出「改寫後可以節省 X 分鐘」這樣的效果。審計的目標在於你是否能區分必要的檢查與重複的動作。
3. 縮小指令範圍：這個技能應該在何時使用？
增加更多技能並不一定能讓選擇變得更簡單。Eric 提醒大家注意那種大量下載並新增技能的作法。
根據原文，每個技能的名稱與描述都會被載入到脈絡中，供模型判斷何時使用。
這裡要區分載入名稱/描述與載入技能本體。這並不是說模型一開始就會讀取每個技能的本體。
模型首先會使用名稱和描述作為線索，來判斷這次該用哪一個。如果那些描述太長，或者技能數量太多，原文指出 Codex 會為了適應而縮短描述。
結果，模型可能只看到每個技能描述的一部分，使得選擇變得更加困難。即使儲存了必要的流程，入口點的說明也可能無法完整傳達。
此外，Eric 還提到了描述之間的矛盾，或是那些試圖讓自己被用於所有事情的描述。這些都可能導致載入對任務沒有幫助的指令。
所以，並不是在描述中塞滿技術術語，讓涵蓋範圍看起來很廣。要讓描述能夠讓模型知道，對於當前的工作，它是否應該被呼叫。
參考圖片的日文翻譯
修改前
建立並驗證 PostgreSQL 結構描述遷移。用於涉及資料庫、查詢、模型和持久化的工作。
修改後
建立並驗證 PostgreSQL 結構描述遷移。用於新增/變更遷移或檢閱應用程式流程。
PostgreSQL 是一種資料庫類型。「結構描述遷移」指的是變更作為資料容器的表格與項目的結構，並套用這些變更的任務。
例如，這是一個為了增加要儲存的項目而變更資料庫結構的場景。在這裡，它被引用為解釋術語意義的範例。
另一方面，「修改前」描述中的「查詢」是檢索或操作資料的請求。「持久化」指的是儲存資料以便後續使用。
這些都是與資料庫相關的術語，但並非所有涉及資料庫的工作都構成變更結構的遷移任務。
「修改前」版本的第一句話顯示了一個專門的任務：「建立並驗證遷移」。然而，第二句話卻將與資料庫相關的廣泛工作納入了使用條件。
這種範圍上的不一致，正是參考圖片中要修正的問題。技能的專業領域與呼叫條件不符。
修改後，「建立並驗證 PostgreSQL 結構描述遷移」的角色保持不變。在此基礎上，它被縮小到新增遷移、變更遷移或檢閱應用程式流程的情況。
例如，如果你只是想檢查一個用來檢索現有資料的查詢，你並不一定需要因為它「與資料庫相關」就呼叫這個遷移技能。
相反地，如果是關於如何套用結構變更的檢閱，它在「修改後」的描述中仍然是目標。縮小範圍並沒有失去專業工作。
在修正描述時要確認的重點，不僅僅是「這個技能對什麼有了解？」而是能否讀出「它會用於哪個請求，又不會擴展到哪些請求？」
如果你只是為了讓它變短而寫「資料庫技能」，那麼呼叫條件就消失了。原文要求的是在保持使用場景清晰的前提下，盡可能讓描述簡短。
你可以使用上面的「修改前/後」來檢查請求的工作與應用條件是否相符，而不是依賴名稱的強度或描述的長度。
4. 釐清指令：要進行到什麼程度，以及什麼才算完成
從這裡開始，我們要談論新增必要的說明。僅僅減少載入和流程，並不能處理中途停止的問題。
Eric 指出，雖然 Astra 工作很勤奮，但有時對於要進行到什麼程度會顯得謹慎。如何傳達你希望它繼續的範圍，也是原文中提到的檢討目標。
特別是，如果你因為之前的模型未經允許就亂動，而強烈地寫下了「一律先確認」，請審計那個邊界。
原文指出的是，為了嚴格遵守邊界，可能在實際上可以繼續的地方停了下來。這不是要你忽略確認指令，而是要改寫你允許的範圍。
A：釐清核准範圍
原文有一個使用一次性測試資料且不存取生產環境的本地測試範例。這是一個允許在你自己的工作環境中執行該特定任務的範例。
下面的「修改前」是為了對比而製作的應用範例。「修改後」包含了原文中本地測試說明的日文翻譯。
修改前：用於對比的應用範例
每次執行測試前和修正失敗前，都請求核准。
修改後：原文範例的翻譯
本地測試使用一次性測試資料，且不存取生產環境。請在執行測試、修正因請求變更而導致的失敗，以及重新執行受影響的測試等階段，無需在每個階段都尋求核准，直接進行。
保留的是目標環境與工作範圍。改變的是在該範圍內每次都要尋求核准的條件。
「一次性測試資料」和「不存取生產環境」不是裝飾性的前言。它們是判斷這條指令是否可用的前提。
如果實際上是一個會連接到生產環境的測試，那麼寫「不存取生產環境」並不會改變環境。有時候它被稱為「本地」，但並不清楚是否滿足這些條件。請將無法確認的條件保留原樣。
此外，允許的修正是針對「因請求變更而導致的失敗」。這不是一個擴展到允許修正測試中發現的所有問題的指令。
重新執行的目標也寫明是「受影響的測試」。這與統一規定每次都要重複所有測試不同。
這句話指定了可以進行的動作，但並沒有消除其他任務的核准需求。它顯示了對於一組已被確認安全的任務，可以委託多少。
你不需要走到「因為每次都停下來很麻煩，所以允許所有事情」的地步。如果你將不希望它停下來的事情，與你仍然希望它回報判斷的事情分開，請求的意義就會改變。
B：釐清完成條件
Eric 解釋說，如果你習慣了會長時間工作的 GPT-5.6 Sol，那麼 Astra 那種會停下來的方式可能會讓你覺得它很謹慎。
在初始實作完成的階段，即使還有後續工作，它也可能會回來請求審查。因此，他建議在開始之前就決定完成條件。
需要的只是實作，還是要執行起來確認？此外，是否要修正確認過程中發現的錯誤？
發出請求的人要先整理這些差異。一個很難用「完成它」來傳達的終點線，會被寫成一個任務。
以下是一個應用範例，將原文的說明替換為建立一個詢問表單。這不是 Eric 實際的請求文字，也不是實際行為驗證的結果。
修改前
做一個詢問表單。實作好之後讓我看一下。
修改後
做一個詢問表單。這次請在本地確認它能偵測到空白的必填欄位與無效的電子郵件地址，並且在測試送出後會出現完成畫面。修正因這次變更而導致的任何錯誤，並將修正結果連同確認結果一起回報。請勿發布到生產環境或發送真實郵件。
保留的是製作詢問表單以及將結果回報給人類的目的。改變的是在回報之前要驗證多少東西。
在「修改前」的版本中，請求是「實作好之後讓我看一下」。即使它在初始實作階段就停下來，也沒有偏離指令。
如果你是想在中途看看設計，那麼那種停下來的方式就有意義。如果那是為了確認你尚未決定的部分而停下來，那麼它就是一條有理由保留的指令。
另一方面，如果你這次想要的是已經完成操作檢查的表單，那麼就將那些檢查包含在請求中。這個範例列出了空白欄位、無效的電子郵件以及測試送出後的顯示畫面。
與其只是說「檢查它是否正常運作」，不如具體列出要嘗試的狀態。如果在確認過程中發現了因這次變更而導致的錯誤，目標就設定為修正後再回報。
同時，發布到生產環境和發送真實郵件則被排除在外。這是為了避免將驗證畫面測試提交與將郵件傳送到真實目的地混淆。
這個請求並未將實際的郵件發送功能視為已驗證。請它回報在本地確認了多少東西作為結果。
根據原文，如果你想超越首次實作，請傳達要調查什麼以及在哪裡停止。
與其只是加強語氣說「不要中途停下來」，不如列出必要的確認事項以及不要進行的操作。這樣一來，即使是它回報給人類的地方，你也可以進行檢討。
5. 審計你自己的設定
在原文的最後，Eric 建議根據這篇文章請 Astra 進行審計。審計意味著讀取現有的指令，並檢查是否有重疊、不一致以及可以檢討的地方。
你也可以打開你自己的 AGENTS.md 或技能，看看你覺得有疑問的句子。然而，如果你想整理你在哪裡寫了什麼指令，可以在進行修改之前先交給審計來處理。
先只執行審計而不修改檔案，是這篇文章提出的方法。這不是 Eric 指定的強制流程。
在這種情況下，不要一開始就要求「刪除所有不必要的指令」。你首先需要的是能讓你比較原始指令與修改建議的素材。
原文還有一點要注意：放在儲存庫中的技能和指令，可能會被其他工作者的 AI 使用。
那些 AI 可能不是使用同一個 Astra。Eric 指出，對 Sol 或 Luna 有幫助的說明，對 Astra 來說可能會增加太多限制。
即使對你這個使用 Astra 的人來說看起來太詳細，但對其他模型來說可能是必要的。如果你要修改共享的規則，誰使用哪個模型也是判斷的因素之一。
如果使用狀況不明，不要假設「只有 Astra 在使用」就刪除。在保留不明確之處的同時，確認修正的候選項目就足夠了。
以下審計提示是根據這篇文章為讀者建立的。這不是 Eric 在原文中發布的提示。
請在目標專案中使用它，並分享文章文字以及你想要審計的請求文字。如果可讀取的範圍有限，請將其視為該範圍內的檢查結果。
請根據 Eric Provencher 文章中的共同評論，審核目前的指令。本次僅執行審核，請勿建立、編輯或刪除檔案，也請勿變更設定。
審核目標包括：應用於此專案的 AGENTS.md、可供使用的技能名稱與描述（以及審核所需的主體內容），以及我分享的每日請求文字。請列出你成功讀取的目標。
請檢查以下問題： ・多處出現的重複指令 ・無法同時執行或目標衝突的指令 ・無論工作內容為何，每次都需要載入或確認的過度統一規則 ・應用範圍超出技能實際角色的條件 ・不清楚執行到何種程度或如何才算完成的指令
針對發現的問題位置，將其分類為「刪除」、「縮短」、「變更應用條件」或「保留」的候選項目，並提供理由。請勿將減少字元數作為目標本身；同時也需列出需要保留的指令。
針對每個候選項目，請提供以下資訊： 1. 檔案名稱/位置，或共享請求文字中的相關部分 2. 目前的指令 3. 假設的問題與判斷依據 4. 建議的修訂版本。若為保留，則說明理由 5. 需要保留與需要變更的內容 6. 人類在變更前應確認的條件
請勿大量刪除專案特定的限制、專業知識、必要的測試或必要的核准。僅允許在可確認環境條件（例如目標資料與無法存取正式環境）的範圍內，提出允許進行本地測試或修正的建議。
請檢查其他模型（如 Sol 或 Luna）是否也使用相同的指令。若不清楚，請寫「未知」，且不要假設這是 Astra 專用的規則。
清楚說明無法讀取的檔案、無法確認的環境條件，以及缺乏判斷依據的資訊。區分材料中說明的問題、設定中實際發現的問題，以及未經驗證的改善候選項目；請勿將改善效果寫成已測量過的結果。
最後，總結應優先考慮的修正候選項目及其理由。變更的執行將在我確認目標與內容後另行提出。
您在此請求中收到的並非修訂後的設定，而是一份對應目前指令與建議修訂的清單。即使被標記為「刪除候選」，也不代表該項目最終被判定為不必要。
提供候選項目的分類，是為了避免變更讀取條件的提案被一概歸類為「刪除」。以本文中的文件參考範例為例，文件本身仍然保留，因此重點在於變更應用條件。
對於技能描述，其專業角色仍然保留，但呼叫範圍會縮小。在這種情況下，如果收到刪除專業知識本身的提案，您可以檢查修訂前後保留的內容是否有所不同。
「縮短」候選項目旨在檢視是否能用更簡短的句子傳達相同的條件與限制。「保留」候選項目則需要說明保留該項目的必要性。
請同時檢視審核範圍與結果。無論是僅能讀取技能名稱與描述，還是能讀取實際程序，都是判斷結果的重要依據。
描述是否過於寬泛，可以透過前者來檢查；但程序中是否存在重複，或必要的知識是否被刪減，則必須讀取主體內容才能確認。
如果您尚未分享每日請求文字，則與其中停止條件的差異也無法確認。僅讀取部分設定，並不等於完成對整個工作環境的審核。
應遵循的順序為：原始指令、將其列為候選項目的理由、剩餘的限制條件，以及未確認的條件。例如，如果不確定是否具備正式環境的存取權限，則跳過核准的提案前提便不成立。
您也可以檢查必要的專業知識是否被刪減，或是否未考慮對其他模型的影響。請在審核過程中，將發現的疑點與「可以變更」的判斷區分開來。
請重新閱讀您為了配合目前工作而不斷新增的指令。第一步並非大量刪除設定，而是這個不改變任何東西的審核。
