上一篇〈我所看見的 Claude Code 開發三大支柱〉聊了 CLAUDE.md、Auto Memory 和 Skills 構成的四層認知架構——核心原則、專案規範、累積經驗、執行方法。把起點設計好，讓 AI 從第一步就帶著正確的認知結構上場。
文章發出去之後，收到了一些蠻有意思的回饋。
一位朋友 Jared 把這篇文章跟他自己既有的 Codex 開發規範做了交叉分析，重新調整了記憶檔案的分層方式。結果？原本半天就燒完的 token 額度，調整後半天工作下來還剩 87%。而且他用的是 OpenAI Codex，不是 Claude Code——代表這個概念是跨工具通用的。
另一位朋友 DS 則留言提醒：「Compact 之後不一定 CLAUDE.md 會完全重新載入喔。」「Context 長度超過 30% 大概就有機會被忘記。」他的實戰經驗指出了一個我在上一篇裡輕描淡寫的現實——起點設得再好，跑起來之後 AI 的注意力還是會漂移。
這讓我開始想：起點之後呢？
三位開發者，三種場景，同一個發現
最近剛好跟兩位開發者朋友有比較深入的交流，加上 DS 的回饋，三個人的場景完全不同，但撞到的問題卻驚人地相似。
DS，在一家公司負責整合過去多位工程師以傳統方式開發的多套系統。他的挑戰是「怎麼讓一個團隊的人都能有效地跟 AI 協作，而且不會互相踩踏」。他發展出了一套叫 AgenticOps 的四階段循環體系——計畫、開發、驗證、回饋學習——每一輪結束後系統比上一輪更聰明。
Jared，一家系統自研公司的技術長，基本上一人開發，但系統不小。他在看到我們文章之前，就已經在 Codex 上建了一套完整的 Global Operating Rules——包含 Agent Work Lifecycle、Rule Authority 優先序、Knowledge Layers 五層分類。後來他把自己的規範跟我們的文章一起丟給 AI 做交叉分析，發現兩套獨立發展的思路收斂到了同一個方向。他說我們文章改變他的是「關於人的認知部分」，讓他重新設計了知識分流的具體機制。
我，教學和研究為主，實戰相對少一點。但正因為站在旁邊看，比較容易看到「為什麼這三個人不約而同走到了類似的地方」。
三個人的共同發現是：設定好起點之後，真正的挑戰才開始。
過程中會出什麼事
上一篇聊的是「怎麼讓 AI 知道該知道的事」。但知道歸知道，AI 在工作過程中會不會一直記得、一直遵守，那是另一回事。
注意力的稀釋
DS 的觀察很直接：context 長度超過 30% 的時候，CLAUDE.md 的內容就開始有機會被忽略。不是檔案消失了，而是在越來越長的 context 裡，每一條規則分到的「注意力份額」被壓低了。
這就像一間辦公室的公告欄。一開始只貼三張公告，每個人進來都會看到。後來貼到三十張，大家就開始自動忽略了。公告還在牆上，但它的實際影響力已經接近零。
記憶的混淆
Auto Memory 長期使用後會劣化——這在上一篇就提過了。矛盾的記錄累積、過時的資訊殘留、「昨天我們決定用 Redis」但不知道「昨天」是哪一天。DS 在留言裡也提到：「LLM 本身就擅長推理跟接龍，但隨著時間拉長產出品質會開始不穩定。」
（簡單來說，AI 的記憶像是一個只會加東西、不會自己清理的抽屜。放越多，找東西的時候就越可能翻出過期的資料還當真…）
機率性的本質
最根本的問題是：LLM 的每一次生成都是機率性的。你可以用 CLAUDE.md 縮小它的行為空間，用 Skills 規範它的執行路徑，用 Hooks 在關鍵節點設硬性閘門。但在這些邊界之內，它的每一步選擇仍然是機率分布下的取樣。
你設了一條走廊，但 AI 在走廊裡是直線前進還是左搖右晃，你沒辦法預測。而且走廊越長（session 越長、任務越複雜），搖晃的累積偏差就越大。
三種不同的應對策略
有趣的是，面對同樣的問題，三位開發者發展出了完全不同層級的解法。
DS 的系統級策略
DS 的核心觀點是：靠 CLAUDE.md 和 Auto Memory 這種 context 層面的記憶管理，可靠度不夠。最終還是依賴 Skill 與 Hook 比較確實。
他的 Skill + Hook 組合，本質上是在 context 管理之外加了一層「程式碼級的確定性保障」。CLAUDE.md 是「希望 Claude 注意到」，Hook 是「不管 Claude 注意不到，這個動作一定會執行」。
他在 AgenticOps 體系裡的 L3 Auto-Fix Scanner 更是把這個思路推到了極致——三路偵測（Prometheus + Tempo + Loki）、雙路 AND Fusion（只有 Tempo error trace 和 Loki ERROR log 在同一個 TraceId 對上時才算有效 incident）。刻意設計成 dry-run，不直接執行修改，要等精準度 ≥ 95% 加上 48-72 小時觀察期才進入自動執行。
他寫了一句我覺得非常到位的話：「自動化信任需要被賺取，不能被假設。」
而且他對「過度警報」的洞察跟上一段講的注意力稀釋是同一個原理——太多警報等於沒有警報，就像 CLAUDE.md 塞太多規則等於沒有規則。他的設計哲學是：「沉默時讓人信任它，發聲時讓人重視它。」
Jared 的流程級策略
Jared 的場景不一樣——他是一個人開發，不需要處理團隊問題，但他需要把每一分 token 都花在刀口上。
他原本就有一套成熟的 Codex 規範，涵蓋了 Agent Work Lifecycle、Before/During/After Work 的流程、甚至定義了知識分五層的架構。技術面已經很完整。但他看了我們的文章之後，把「知識按性質分層」這個認知架構的觀點融入了他的系統，重新設計了每一輪任務的知識分流機制。
他用自己原本的規範加上我們的文章，讓 AI 做交叉分析，產出了一套具體的工作迴路。每一輪任務開始前，AI 必須先做一連串判斷：這個任務會不會建立新慣例？有沒有現有模式可以沿用？會碰哪些檔案？會不會影響架構？如果跟過去經驗有關，先查 Memory。
但這裡有一條關鍵規則——「Memory 只能當線索；若和目前 repo 衝突，以目前檔案、script、log、實測結果為準。」 這等於在流程裡嵌入了一個「記憶 vs 現實」的校驗機制。記憶可能過時，但 repo 裡的程式碼不會騙你。
每輪任務結束後，AI 要做三件事：說明改了什麼、驗證結果、判斷這輪有沒有產生新知識。如果有，就分流到正確的層級——每輪都要遵守的規則進 AGENTS.md、踩坑經驗輸出 Memory 草稿、重複流程建議做 Skill。而且「除非我明確說記住，不要自行永久寫入 Memory」——人工批准才寫入。
更厲害的是，他會量測 AGENTS.md 的 KB 數（7.2KB）、常用 SKILL.md 的大小（13.2KB），讓 AI 自我評分（從 9.6 到 9.9），還給整個架構做版本管理（v1.9，規劃 v3.0 Slimline Policy Pack）。他把 AI 的認知架構當作一個產品在迭代。
（我開玩笑說他很會對 AI 進行 PUA。但仔細想，這不是 PUA，這是好的管理——給明確的邊界、設定回報機制、要求自我評估、保留最終決定權，但在框架之內給予充分的執行自由。）
DS 的暗號策略
回到 DS 的另一個實踐——他在 CLAUDE.md 的最後一行加上「執行完任務回應 喵~~」。如果 Claude 回覆的時候沒有喵，就代表它沒有讀完整份 CLAUDE.md。
這是最輕量的監督機制。但它指向了一個目前整個工具生態都還沒認真對待的需求——開發者需要即時知道 AI 的認知狀態。
現在的工具提供的回饋只有兩種：token 用量（花了多少錢）和最終產出（程式碼對不對）。但中間那段——AI 有沒有讀完規則、有沒有去查記憶、注意力有沒有開始稀釋、哪些指令正在被忽略——開發者完全是瞎的。
用開車來比喻的話，現在的狀態是：你有一台車（AI），你設定了導航（CLAUDE.md + Auto Memory），你有目的地（需求）。但你的儀表板上沒有時速表、沒有油量表、沒有引擎警示燈。你只能看窗外的風景猜自己有沒有偏離路線，或者等到車拋錨了才知道出事了。
DS 的「喵~~」就是他自己土炮了一個引擎警示燈。
起點、過程、迭代——一個完整的循環
把三位開發者的經驗拼在一起，其實浮現了一個三段式的完整框架：
起點（記憶架構） — 把知識按性質分層：核心原則常駐、累積經驗按需調閱、執行方法觸發時載入。讓 AI 從第一步就帶著正確的認知上場。這是上一篇在講的事。
過程（監督與回饋） — 持續驗證 AI 有沒有偏移。DS 用 Skill + Hook 做確定性兜底，Jared 用前處理 / 後處理的迴路做每輪檢查，最輕量的做法是一個「喵~~」暗號。不管哪種方式，核心邏輯都是：不能設定完就放手。
迭代（架構優化） — 回頭改善認知架構本身。Jared 量測 context 成本然後瘦身、DS 把知識圖譜越養越大但過濾機制也越來越精準。目標是讓下一輪的起點比這一輪更好。
這三段構成一個循環，不是做完就結束的線性流程。
而且這裡有一個關鍵的觀察——這個循環本身不可能被完全自動化。 因為「判斷 AI 有沒有偏」和「決定怎麼修正方向」，需要的是人的判斷力，不是更多的自動化。
所以「全自動化」的邊界到底在哪
聊到這裡，我突然想到一個更根本的問題。
大家（包括我自己）對 AI 最初的期待是什麼？「AI 會幫我把程式寫完。」害怕的是什麼？「AI 會把程式寫完，然後不需要我了。」
兩者的共同前提是同一個假設——AI 的終點是完全自動化。
但我們從一路討論下來看到的現實是：
對於非技術者來說，AI 確實可以是阿拉丁神燈。你說「幫我做一個網站」，AI 生出來，你看了覺得可以就可以了。在「看起來能用」的驗收標準下，全自動化沒問題。
但對於技術者或企業來說——你的需求是客製化的、你的驗收標準是嚴格的、你的每一個決策都牽涉取捨。「用 JWT 還是 session-based」不只是技術選擇，背後是安全需求、舊系統相容性、團隊能力、上線時程的綜合考量。這些條件大部分是隱性的、互相牽制的、沒有標準答案的。
需求固定 + 驗收寬鬆 → 可以全自動化。 需求客製 + 標準嚴格 → 不可能全自動化。
這跟 AI 多聰明無關。即使未來的模型強到能產出完美的程式碼，「完美」的定義本身就是人給的。不同的企業、不同的情境、不同的階段，「完美」長得都不一樣。
而且從我們的技術分析也能看到同樣的結論——記憶架構可以讓起點更好，但過程是展開的、分岔的、不可完全預測的。AI 的每一步都是機率取樣，走廊再窄也不能保證直線前進。所以監督和介入的人力不是可以被優化掉的成本，是整個系統能運作的前提。
那真正該追求的是什麼
如果完全自動化不是方向，那開發者真正該做的事情，其實回到了三個很務實的方向：
更好的起點 — 記憶分層做對，讓 AI 從第一步就帶著正確的認知。這是最直接的效率提升，我朋友在 Codex 上的實測已經驗證了——token 消耗可以降到原來的幾分之一。
更即時的回饋 — 過程中能盡早知道 AI 偏了。目前這個領域幾乎是空白。DS 的「喵~~」和 Jared 的前處理檢查都是土炮解法，但指向了一個真實的需求——開發者需要某種「AI 認知狀態的儀表板」。
更順暢的協作 — 不是追求「讓 AI 自己跑」，而是「讓 AI 在你旁邊跑的時候，跑得更順」。四層記憶架構降低了重複溝通的成本，Skill + Hook 提供了行為保障，前處理 / 後處理的迴路讓每一輪都有品質控制。這些加在一起，不是在追求自動化，是在降低協作的摩擦力。
寫在最後
上一篇的結論是：大部分人把 AI 的記憶系統當設定檔在管理，沒有看到它是一個認知架構。
這一篇想補上的是：即使你把認知架構設計得再好，AI 協作也不是「設定完就放手」的事。它是一個持續的循環——設定起點、監督過程、回饋迭代。
而且越是認真使用 AI 的人，會發現管理 AI 本身就變成了一項需要持續投入的專業工作。Jared 把整個架構當產品在迭代、DS 建了一整套 AgenticOps 體系、連最輕量的 DS「喵~~」暗號都是一種主動的監督行為。
AI 不會取代開發者。但它會重新定義開發者的工作內容——從「自己寫程式」變成「帶著 AI 一起寫，然後確保它寫對」。
（所以最後的結論是…..我們從寫程式的工人，升級成了帶 AI 的工頭？…這好像也沒有比較輕鬆吧！？ XD）
本文中 DS 的觀點和實踐引用自他的留言回饋及部落格文章〈三週後的 Harness：從工程方法論到 AgenticOps〉。Jared 的案例經本人同意引用。感謝兩位實戰派朋友的無私分享。
上一篇：〈我所看見的 Claude Code 開發三大支柱：CLAUDE.md、MEMORY.md 和 Skills〉
參考資料：
- DS, 三週後的 Harness：從工程方法論到 AgenticOps
- Anthropic, How Claude remembers your project
- Anthropic, Use hooks for automated workflows
- Anthropic, Explore the context window
