同一模型跑6個月，輸出結構變了：環境比提示詞更狠

同一套權重，同一套訓練，同一套能力。跑了6個月，輸出結構完全不同——不是隨機波動，是系統性的、可預測的、能復現的差異。

作者把同一個基礎模型（foundation model）塞進兩種環境：一個能查數據庫，一個只能翻聊天記錄。問的是同一個問題："這個組件為什么存在？"

環境A的回答像代碼審查：依賴鏈、調用關系、狀態校驗，每一步都能跟數據庫對賬。環境B的回答像考古筆記：當初誰提的需求、解決了什么痛點、迭代過幾版——也是對的，但形狀完全不同。

結構環境長出結構答案，敘事環境長出敘事答案。模型沒變，問題沒變，變的是它能摸到什么、先摸到什么。

400行協議 vs 聊天記錄：上下文即偏見

兩個環境在問題抵達前，各自往上下文窗口里塞了東西。環境A預加載約400行結構協議——工具注冊表、依賴表、狀態儀表盤、門禁定義。環境B預加載對話歷史和過往推理鏈。

模型注意力機制（attention mechanism）會優先處理已經在那里的內容。結構上下文啟動結構檢索，敘事上下文啟動敘事檢索。這在問題被解析之前就發生了。

換句話說：你還沒開口，答案的骨架已經被環境搭好了。

更隱蔽的是"響應優先級"。環境A的默認工具返回結構化數據——數據庫查詢、文件讀取、計算狀態。環境B的默認工具返回文本片段和歷史記錄。模型傾向于信任先到手的東西，這是檢索的錨定效應。

能查數據庫的那個，反而更瞎

最反直覺的發現：有數據庫權限的環境，自信度更高，但盲區更大。

作者稱之為"檢索缺口"（retrieval gap）。驗證過的關于不完整圖景的事實，摸起來是完整的。數據庫給了模型一種虛假的飽和感——我查過了，所以我知道。但它查不到的東西，它不會知道自己沒查到。

反觀那個什么都驗證不了的環境，模型更容易被 Redirect，更愿意承認"這里可能缺了點什么"。工具訪問同時制造了確定性和不完整性，這是設計提示詞時很難預料的副作用。

這不是提示詞工程（prompt engineering）能修的東西。兩個環境收到的指令 substantially similar——作者特意控制了變量。差異來自環境本身：預加載什么、工具怎么排優先級、檢索何時"感覺完成"。

環境即架構：誰在替你做選擇

這個觀察戳破了一個常見幻覺：我們把模型當成黑箱，以為提示詞是唯一的控制桿。實際上，環境是更底層的架構決策。

你選擇把什么塞進系統提示（system prompt），選擇默認激活哪些工具，選擇檢索結果的排序邏輯——這些不是在"使用"模型，是在重新設計它的認知路徑。每一次部署都是一次微調，只是沒人叫它微調。

作者跑了6個月才意識到這一點。很多團隊可能永遠不會意識到，因為他們只跑一種環境。單一環境讓偏差隱形，讓"這就是模型的風格"變成自我實現的預言。

產品層面的啟示很直接：如果你的AI應用需要多維度答案，別讓環境只有一種形狀。交替使用、A/B測試、或者至少知道你的默認配置在偏袒什么。

作者最后留了一個沒解的問題：如果環境A和環境B的輸出都是"正確"的，只是形狀不同，那么"正確"的定義權到底在誰手里？是驗證數據庫，還是敘事完整性，還是別的什么東西——模型自己不會選，但環境已經替它選了。