模型越聽話，你的 AGENTS.md 越像絆腳石：GPT-6 之後該整理的不只是程式碼

2026 年 9 月初，一篇在掘金上流傳的工程師筆記點出一個反直覺的現象：升級到 GPT-6 Astra 之後，最先該被清理的，可能不是你的程式碼，而是那些為上一代模型寫下的 Skill 與 AGENTS.md 規則。這個問題其實早在 GPT 5.6 週期就被討論過，Anthropic 那邊也有類似經驗，一些為舊模型設計的增強套件，在更強的模型上反而成了負優化，除了浪費 Token 沒有別的作用。

規格表上看不到的，往往才是重點。這次的主角並不是模型本身的能力，而是模型能力變強之後，你手邊那套老規則所產生的化學變化。

為什麼模型變強，規則反而變成障礙

OpenAI 在 GPT-6 Astra 的官方 prompting 指引與 API 文件裡說得很直白：這一代的 instruction following 比前代更強。聽起來是好事，但換句話說，它也更容易被 Skill、AGENTS.md 這類上下文指令影響。模糊的、互相衝突的、範圍過寬的規則，會讓它提前停下來詢問使用者，甚至直接卡住任務。

用一個日常比喻：舊模型像一個注意力不集中的實習生，你寫一大堆規則貼在牆上，他頂多記得三成，剩下的靠自己的判斷混過去。新模型像一個極度循規蹈矩的員工，牆上每一張便利貼他都會逐條執行。這時候，牆上那些「每次都要先讀完三份文件」的舊便利貼，就從提醒變成了枷鎖。

OpenAI 官方給的例子很有代表性。一條 Skill 的觸發條件寫成「Use when working with databases, queries, models, or persistence」，這幾個詞的涵蓋範圍太大了。你可能只是改一個 ORM model、修一條 query，這種普通邏輯修改，模型都會判斷 migration Skill 與當前任務相關，於是 Skill 被過度觸發，後面跟著的 migration 規則、檢查步驟、參考資料全部湧進上下文。官方建議的改法是收緊成「adding or changing a migration, or reviewing its rollout」，讓觸發條件描述的是具體任務，而不是一堆可能沾上邊的關鍵字。

「每次都讀」這條老規則，現在真的會被執行

另一個例子更貼近多數人的專案現況。很多團隊的 AGENTS.md 裡都有這樣一條：「Before every edit, read architecture.md, database.md, and deployment.md.」

這條規則在過去非常合理。早期 Agent 經常不知道要主動找專案文件，所以大家乾脆強制它「每次都讀」。但來到 Astra 這個等級的模型，它會認真反覆執行這個約束：你只改了一個字串，它也會把幾份文件完整讀一遍；改第二次，它再讀一遍。整個過程除了浪費 Token、拖慢進度，還會讓上下文快速膨脹，而上下文膨脹的副作用之一，是幻覺變得更嚴重。

官方推薦的寫法換了一個思路：「Use architecture.md for service boundaries, database.md for schema changes, and deployment.md when preparing a deployment.」這其實是在建立一張簡單的對照表：改 service boundary 查 architecture.md，改 schema 查 database.md，準備部署查 deployment.md；修一個 UI bug 不用讀任何文件，改一個 typo 也不用。

這正是 OpenAI 反覆提到的 Harness 工程思路：與其塞一堆強制行為，不如給模型一套精準的上下文索引，讓它自己判斷什麼任務該載入什麼資料。這與我們先前對GPT-6 Astra 宣示性說法的檢驗的觀察互相印證：真正值得關注的從來不是發表會上的口號，而是 API 文件裡這些第一線工程細節。

Skills 的隱性成本：description 就是選單

很多人對 Skill 的理解是：專案裡放幾十個 SKILL.md 沒關係，需要的時候模型自然會載入。實際機制比這個想像更微妙。

Codex 採用的是 progressive disclosure，也就是漸進式揭露：啟動時不會把所有 Skill 的正文塞進上下文，但模型必須先知道有哪些 Skill 存在、以及什麼時候該選用哪一個。換句話說，啟動時模型會先拿到每個 Skill 的 name 和 description（Codex 還會附上檔案路徑），等它判斷某個 Skill 與當前任務匹配，才會去讀完整的 SKILL.md。

這意味著，隱式觸發本身就依賴 description 的品質。再回到便利貼的比喻：Skill 的 description 就像餐廳菜單上的一道菜名，模型是照著菜單點菜的客人。菜名寫得含糊，客人就會亂點；幾十道菜名全寫「家常菜」，點錯的機率自然高。所以就算正文不會全部進上下文，一堆觸發條件寬鬆的 Skill 仍會在啟動階段就佔掉注意力，並提高誤觸發率。

所以呢：把 prompt maintenance 當成換模型的一部分

把鏡頭拉遠一點，這件事對一般開發者與團隊的實際啟示可以收斂成幾個動作。

第一，每次升級模型，把檢視 AGENTS.md、Skill、Rule 當成遷移清單上的一項，而不是換個模型名稱就結束。很多 Coding Agent 的設定檔，本質上記錄的是上一代模型的缺陷；模型補上了那些缺陷之後，留下的大量強制行為反而造成執行混亂。那句工程圈的玩笑話說得傳神：只要你學得夠慢，你就不用學了。反過來對模型也成立：只要規則寫得夠死，模型就永遠被綁在舊時代。

第二，把「強制每次執行」的規則改寫成「任務對應上下文」的對照表。前者是為不聽話的模型設計的圍欄，後者是為聽話的模型準備的地圖。地圖的好處是，不需要的任務就什麼都不載入，上下文乾淨，幻覺自然少。

第三，Skill 的 description 要當成產品文案來寫。它不是註解，它是模型選單上的唯一線索。範圍寫太寬，等於把選擇權交給運氣。

這波討論最值得記下的轉變是：AI 工程的重心正在從「教會模型做事」移向「別擋住模型做事」。當模型的指令遵循越來越精確，工程師的價值就越來越取決於你餵給它的規則有多乾淨。模型在進步，你的設定檔如果原地不動，兩者之間的落差，最後會以浪費的 Token、變慢的進度和加重的幻覺結帳。