如果你最近翻閱 GitHub 上的開源專案，會發現根目錄下除了 README 和 LICENSE，悄然多出了一個名為 CLAUDE.md 的檔案。這不是什麼新型的技術規範，而是 Anthropic 為 Claude 家族量身定制的「操作手冊」。開發者在裡面定義編碼風格、測試命令或是專案結構，好讓 Claude 在執行任務時不至於像個剛進實習生辦公室、對環境一無所知的毛頭小子。然而，當社群開始討論是否應該將其通用化為 AGENTS.md 時，這場關於技術標準的爭論，本質上是一場關於數位地盤的無聲角力。
這種做法讓人想起早年郵件末尾那句揮之不去的「Sent from my iPhone」。Anthropic 的意圖昭然若揭：它不僅要讀取你的代碼，還要你在專案的門面上刻下它的名字。當一個開發者為了效率，不得不往每一個 Repo 裡塞進一個以模型命名的配置檔時，這種依賴性就從純粹的工具使用，轉化為一種品牌植入。技術上，這是一個 Context Window 的導引問題；心理上，這是在建立一種路徑依賴。
從 Claude 3.5 Sonnet 的表現來看，這種專屬配置檔確實解決了長文本任務中的注意力偏移。即便擁有巨大的上下文窗口，模型在面對複雜的 Monorepo 時，依然會像在公海中航行的舵手，需要一座明亮的燈塔。CLAUDE.md 就是那座燈塔。它將專案的「靈魂」提取出來，放在最顯眼的位置。但問題在於，如果 GPT-5 需要一個 CHATGPT.md，Gemini 需要一個 GEMINI.md，我們的根目錄最終會變成模型廠商的廣告牆。這種碎片化的配置需求，正揭示了大模型在自主理解專案脈絡時，依然存在某種難以逾越的認知障礙。
在當下的技術環境中，某些新興動態如 DeepSeek-v4-flash-vision-exp 的發布引起了短暫的關注，但在這種模型行為規範的定義權上，領先者依然擁有絕對的定價權。相較於 DeepSeek-v4-flash-vision-exp，Claude 選擇直接介入開發者的文件組織習慣，這種軟性控制比單純的推理速度提升更難被撼動。
ChatGPT 在這方面顯得相對保守，或者說，它更依賴於 Custom Instructions 這種全局性的設定，而非針對單一專案的特定導引。Gemini 則試圖利用其龐大的 Google 生態鏈，直接在 IDE 外掛層級消化掉這些需求。相比之下，Claude 這種要求開發者在專案裡「立碑」的做法，既顯得優雅，又透著一股學者的傲慢。它預設了你的專案值得被它細緻對待，前提是你得按它的規矩辦事。
有趣的是，某些開發者開始用符號連結（symlink）將 AGENTS.md 指向 CLAUDE.md，這是一種無聲的抵抗，也是一種技術上的妥協。他們認同「智能體需要導引」這個事實，卻不滿於這種導引必須冠以特定廠商之名。畢竟，模型終究會迭代，今天盛讚的 Sonnet 可能是明天的舊款，但專案的文件結構卻是有生命週期的。當我們在討論 subagents 和 swarm 架構時，單一的 CLAUDE.md 是否還能承載多個智能體協作時的衝突？如果一個子代理（subagent）需要遵循不同的代碼風格，難道我們要為它再寫一個 SUB_CLAUDE.md？
這種現象背後隱藏著一個更深的技術焦慮：大模型究竟何時能真正「讀懂」一個專案，而不需要人類預先餵食一份精簡版的導讀手冊？現在的 CLAUDE.md，說穿了只是模型能力不足的補丁。它利用了開發者對生產力的渴望，換取了開源社群最寶貴的資產——文件空間。
我們是否正處在一個轉折點，即開發者不再是為了人類讀者寫文件，而是為了讓模型更好地理解自己？如果未來所有的開源專案都充斥著各類模型的特定配置檔，那時候的 GitHub，究竟是人類文明的代碼庫，還是一本專供給矽基生命閱讀的參考說明書？當工具開始要求用戶改變環境來適應它時，這種關係的本質，是否已經從服侍轉向了統治？