一份 Repository 入口文件，曾把寫作、審稿、產圖、發布等任務，各自需要讀的資料與限制再寫一遍。
詳細規則已經在其他正本裡，入口卻又保留另一份清單。要修一條規則時，接下來得回答：哪一份才是權威？入口裡的摘要是否也要同步？
這次有實際刪減可看。兩次提交把 AGENTS.md 從 294 行縮到 160 行，再到 137 行；冗長的任務段落改成路由表，重複的已發布文章限制也合併到同一個硬邊界。
治理精簡要證明被移除的是重複責任，而不是只證明文件變短。
這是歷史版本的行數，不是當前文件大小，更不是 Token、速度或事故率的量測。
治理債務（Governance Debt）不一定來自錯誤規則。幾份各自正確的文件，也可能因為重複維護而產生漂移。
這次入口縮減有三類具體變化：
| 縮減前 | 縮減後 |
|---|---|
| 每種任務重列請求範例與先讀清單 | 路由表指出任務入口與正本 |
| 已發布／草稿限制散落在多段 | 一個文章硬邊界，細節留在正文規範 |
| 產圖與發布段落反覆說明權限限制 | 保留共同邊界，再連到各自程序 |
入口仍要讓 Agent 知道先去哪裡、誰有權改規則、哪些事不可跨越。完整步驟則由任務正本維護，減少同一條程序有兩個版本的機會。
這和刪掉安全要求不同。若只把清單拿掉，卻沒有有效路由，Agent 會更難找到原本必須遵守的規則。
回查縮減前後的 Git 內容，這次比對的六份正本文件具有相同 blob，也就是位元組內容相同。它們涵蓋文章風格、系列內容邊界，以及寫作、產圖、發布、審稿程序。
不過，檔案沒有變，還不足以證明使用方式沒變。還要檢查縮短後的入口，是否仍把任務導向這些規則，以及重要限制是否仍可辨識：
| 受查保護 | 縮減後的定位 |
|---|---|
| 修改前先讀必要上下文，遵守來源權威順序 | 入口保留讀取順序與 Authority |
| 寫作與審稿都須盤點已用／本篇／保留內容 | 入口硬規則＋未變動的任務程序 |
| 已發布文章不能因新模板被全面翻修 | 合併後的文章硬邊界＋審稿開場限制 |
| 產圖不等於取得發布權 | 圖片與發布共同邊界 |
| 發布需要已批准的圖片與正式 HTTPS 來源 | 入口保留前提，程序保留具體停止條件 |
| 不碰無關修改，完成後讀回核對 | 修改紀律與任務收尾 |
這能支持一個有範圍的結論：受查的控制仍能透過入口找到，對應正本內容沒有被這次縮減改掉。
它不是完整的行為等價證明。本輪沒有讓 Agent 在縮減前後執行相同任務，也沒有重跑動態安全回歸測試；不能因此宣稱所有保護效果都相同，或未來不會出現新誤解。
如果同一規則寫在三份文件，直接留最短的一份並不可靠。至少要先回答：
原規則保護哪個失敗情境？
哪個位置是權威正本？
其他位置是摘要、路由，還是另有責任？
刪短後，使用者與Agent還能找到完整規則嗎？
哪些限制需要留在入口，不能只藏在深層文件？
例如產圖與發布的權限分離，仍是入口硬邊界；不能因為發布程序裡也寫過，就把入口的提醒全部刪掉。它決定 Agent 會不會在選擇流程之前就走錯。
反過來，某個任務的完整先讀清單，若已由正本維護，入口可只提供明確路由，不必保留第二份展開內容。
OpenAI 在 GPT‑6 系列指南裡直接提醒：模型對細微差異與模糊處的理解能力提升後，過去有幫助的「過度具體指引」反而可能影響成效。它給出的更新方向，和這次 AGENTS.md 精簡很接近：
| 官方建議 | 對這次治理精簡的啟發 |
|---|---|
| Skill 先用簡短描述說明何時使用 | 入口先負責 routing，不複製完整 procedure |
| 輔助細節只在需要時載入 | 不把所有任務規則一次塞進預設上下文 |
| AGENTS.md 說明文件／測試適用情境 | 用條件式路由取代每個任務重列同一份清單 |
| 明確授權安全 routine | 不因怕越權，把所有無副作用步驟都卡在人審 |
| decision boundary 取代一律先問 | 保留真正需要授權的界線，而不是增加確認次數 |
| definition of done 寫清 implement / run / inspect / fix | 精簡文字不能把完成條件一起刪掉 |
這不是「AGENTS.md 越短越好」。若壓縮後找不到正確正本、失去必要 stop condition，或安全 routine 與 Production 操作被混成同一層，字數減少反而擴大 ambiguity。
近期整理 Skill reference 時又看到另一個風險：規則存在，不等於 Agent 真的會讀到。 長 reference 常先被局部預覽；如果重要限制埋在很後面，又沒有目錄、摘要或從 SKILL.md 直接指向需要的區段，文件雖然存在，執行上下文仍可能漏掉它。
這和本篇的 AGENTS.md 精簡其實是同一個問題：治理不能只看「寫了多少」，還要看「Agent 是否能在需要時找到正確那一份」。因此 progressive disclosure 的重點不是把內容藏深，而是讓入口清楚說明何時載入、去哪裡讀、哪份是權威。至於某些 Agent 會先讀前 100 行這類行為，只能視為實作觀察，不能當成所有 runtime 的固定限制。
因此 Minimum Viable Governance 的目標可以再說得更精確：
把穩定責任放在唯一正本，把入口縮成可發現的路由與硬邊界；只有真正需要推理或授權的地方，才繼續占用模型與人的注意力。
官方 best practice 只能說明這個方向合理，不能替本 Repository 的刪減效果作證。本文仍以 294 → 160 → 137 行、六份正本 blob 不變與受查保護仍可定位為主要 Evidence；沒有動態前後對照，就不宣稱速度、Token 或事故率已經改善。
有唯一答案的檢查，可以考慮交給確定性工具。Day 10 已談過這種分工，這裡只補刪減條件：原本的文字規則要退出，必須先確認工具覆蓋的失敗情境與停止行為。
本篇的主要證據是入口文件的實際合併，沒有另一組工具替代前後的行為測試；不能把候選設計寫成已完成的精簡成果。
也不能因為某個 Gate 很少被觸發，就推定它沒有價值。低頻但高後果的防線，需要看它保護的失敗，而不只看出現次數。
公開的治理起始模板（Bootstrap）把規則、現況、決策等責任分開說明，也明定不必一個問題就建立一份文件。每份新增文件還需要更新觸發點與維護責任，不能只在第一天看起來完整。
它是最小方案的入口，不是這次精簡有效的證據。是否值得少一份文件，仍要回到那個 Repository 的重複責任與保護對照。
這次留下的做法，是把「刪掉什麼」和「保護搬到哪裡、如何仍被找到」一起記錄。若後者答不出來，行數再漂亮也先不要刪。
下一篇會把這個判斷往前移：碰到新的 Agent 問題時，應先在哪一層修正，什麼條件才值得增加下一層？
OpenAI｜GPT‑6 系列模型指南（2026-10-02；Skills / AGENTS.md / decision boundaries / definition of done）
iThome鐵人賽
看影片追技術