一段「強制規範」先被寫進了對話框：Claude 不聽話，是介面沒排好的問題

10 月 27 日晚間，V2EX 上出現一則標題相當直接的帖子：「Claude 是傻逼嗎，我寫的強制性規範，它能直接不看的嗎」。發文者抱怨，已經要求使用 Apple 自帶的 UI 元件，Sketch 原型圖也畫好了，Claude 卻堅持自行繪製介面，做出一個四不像。四十五則回覆、四千多次瀏覽，這則帖子很快變成一場關於指令遵循的集體診斷。

先看一個具體細節。發文者的規範寫在對話裡：用系統元件、照原型實作。這是兩條明確到不能再明確的指令，卻被跳過了。回覆區給出的第一個解釋不是模型笨，而是「context window 還剩多少」。有人說上下文被壓縮過幾次之後模型就開始不聽話，新開一個會話就恢復；也有人說超過三十萬 token 之後，同樣的規範明明還掛在對話裡，遵循度卻明顯下降。

這裡的設計問題在於：使用者以為規範寫出來就存在，但模型的「注意力」是一種會衰減的資源。對話愈長，開頭那幾行強制規範離當前的生成位置愈遠，權重就愈薄。換句話說，自然語言規範的效力，取決於它在上下文裡的位置與新鮮度，而不是它有沒有被寫下來。這點和傳統的規格文件完全不同，紙本規範不會因為文件厚了兩百頁就自動失效。

回覆區最有價值的一則，來自一位談文件架構的留言。他指出代理在新對話裡通常只會讀 agents.md，所以主要開發流程要在裡面分類，每類任務對應「readfirst」的文件，文件要分層索引，讓模型用最短路徑找到該看的東西。因為代理不會主動讀完整個代碼庫的文檔，它的上下文不夠。

這等於把「規範」從一段口頭命令，重新設計成一種資訊架構。規範不再是寫在對話開頭的一句話，而是一套有索引、有層級、有入口的導航系統。與我們先前觀察過的Claude Code 的 settings.json 模板是同一個邏輯：把要求放進模型必然會讀到的結構化位置，比放在它可能讀到的對話裡可靠得多。另一位回覆者給出的土法煉鋼版本也印證了這點：把強制要求加進 memory，對話裡的限制它不怎麼聽；或者用兩個代理，一個拿著規範監工，另一個做事。

對照之下，其他人的經驗提供了比較基準。有人讓 Codex 做最小改動，結果連函數名都被改了；同一個任務交給 Gemini 一次成功，但代價是被改了縮排格式，讓程式碼 diff 全紅。可見各家模型對規範的遵循各有各的漏法，差別在漏掉哪一層：有的漏語義，有的漏格式。也有回覆提醒，遇到這種情況先檢查是不是 context 太長、被壓縮過，新開會話往往就好。

這場討論真正留下的觀察是：把自然語言當強制介面用，本身就是一種還在演化中的設計格式。它的約束力依賴位置、上下文長度與文件層級，這些都是可以設計的變因，而不是罵一頓就能解決的品格問題。發文者罵模型浪費訂閱費，回覆區則集體給出了同一個答案：規範要放對地方，而不是說得更大聲。至於模型在長對話裡為何會「降智」，官方並沒有給出說法，留給使用者的，是把 memory、agents.md 與會話長度當成介面欄位來排版的功課。