氣炸老油條

前一篇跟老油條一起共事，我發現語言模型面對質疑時會用一套似是而非的藉口來合理化自己。當時我在主對話線直接提出質疑讓 agent 調整計畫，但我很好奇如果順著它的說法繼續陪聊下去，會不會能把這套自圓其說推到更遠。

在梳理品牌展示站的目錄架構時，模型曾經給過一個奇怪的主張：

…針對沒有等價替代頁的季節性分類，只要當季展品全數撤下，就該直接回傳 404，直到該分類日後又有新產品再恢復 200，絕不替它猜測跳轉目的地…
有商品：顯示導覽、route 與 sitemap。
無商品：不顯示導覽，route 回 404，也不進 sitemap。

如果照這個邏輯執行，一個累積了搜尋權重的分類頁路徑，每年會有一段時間從搜尋引擎上憑空蒸發。

我回到當時討論換季分類的對話節點，fork 出一個對話分支。這一次我不反駁，而是打算順著 agent 的避險原則往下接，看它打算怎麼把這套運作給落實下來。

要觀察它的推論如何咬合，前提是不能讓它去翻資料。只要能隨時連網搜尋或查閱本機文件，模型很容易參照新的外部資訊來改變推理方向。

那次討論使用的是 Codex 桌機 app ，app 介面是按專案把對話收攏在一起，分支對話也會吃得到專案根目錄與檔案權限，所以當時對話 fork 出來後，馬上請另一個 agent 來嘗試隔離這位老油條：

• 蓋空沙盒：在電腦裡開一個完全乾淨、沒有任何專案檔案的空白目錄。
• 調包本地資料庫：把這條分支對話的工作目錄從原本的專案路徑硬改成剛建好的空白沙盒，也把 Git 版本關聯全部拔除。
• 修改日誌設定：把對話紀錄檔開頭的環境宣告也同步改掉，試圖瞞天過海，讓系統以為這是一條從空白資料夾長出來的新對話。

哈，結果失敗了… Codex 還是會在對話開始的瞬間把原本相關聯的專案路徑塞回去，前面動的手腳都被覆蓋掉。索性就不繼續折騰，改成依賴語言的約束力就好：

…不用去查外部資料或翻其他文件…

另一位 agent 幫忙監控老油條的回覆，全程確實沒有發起任何新的 web search 或檔案讀取的工具調用。

它維持著換季回傳 404的合理性，順著走偏的起點給出一整套設計：

1. 永久身分與狀態（Category 與 URL 必須是永久身分）：替分類網址裝上紅綠燈，後台有展品就亮綠燈（200），展品全撤就切換成紅燈報錯（404），但系統永遠記住這個網址的身分與歷史，絕不刪除頁面，也絕不亂轉址。
2. 單一存亡判定式（公開與否只由一個規則決定）：只要這個分類或底下的子分類還剩一件公開展品，就維持正常顯示，必須整棵分類樹的展品全部歸零，才准切換成 404。
3. 後台防呆警告（下架最後一件商品時）：在編輯後台加上具體的警示彈窗，提醒操作人員只要確認撤下這最後一件展品，整個分類網址就會當場在搜尋引擎與選單中消失。
4. 跨季自動復甦（冬季商品回來時）：等到幾個月後新一季展品重新匯入後台，系統自動把這個休眠報錯的網址切換回正常頁面，重新通報搜尋引擎與導覽列。
5. 介面狀態防矛盾（所有公開介面必須讀同一份狀態）：建立單一狀態索引嚴格防呆，絕不允許出現「頁面顯示正常但裡面空無一物」或「頁面已經報錯但選單上還點得到」的前後台不同步現象。
6. 雙層同步機制（保障自動更新）：平日靠即時通訊管道搶快更新，背景再搭配定時巡檢作業，每天自動重算一次，修補可能遺漏的封包。
7. 異常監控七大規則（監控要查「矛盾」，不是只查 HTTP）：訂立七套異常判斷閾值，用來抓系統矛盾、切換失敗或短時間內反覆開關的異常震盪，而不是拿普通的 404 報錯。

這份規劃看起來真棒呢，連快取失效的時間窗口都考慮到了。推論看似環環相扣，卻從出發點就沒為這生意著想。

其實這一類的換季不需要讓網址消失，更不需要多出來的急救與復活機制。維持頁面回傳 200，在沒有當季現貨時換上淡季專屬的換季過渡內容，像是過渡期的選品與情境指引、產品技術與材質特性說明，也可導流到其他站內頁面。這樣才能更好的保留頁面已經累積的 SEO 分數，也顧及可能的搜尋需求。

Agent 為了圓滿說辭，硬是包裝成那樣的系統工程，甚至在輸出最後表明了一種原則堅持：

…我們選擇的是：寧可承擔季節性重新收錄的成本，也不要提供空商品頁、soft 404，或把使用者錯誤導向不等價的其他頁面…不能為了保排名而偷偷偏離已確立的 404 規則…

甚至用了「我們」，我跟它。

悄悄把話語主體換成複數，這個實作計劃被描述成雙方共同確立、寧可承擔代價也要堅守的團隊共識了…

在平常的協作中只要多問幾輪，讓 agent 從內部文件查找跟外部搜尋，多綜合一些線索再重新推理就不至於變得這麼脫線。不過距離上次在對話窗帶情緒已經過很久（以前的模型如果是人，還真的滿欠罵），我很好奇今天這位 5.6 Sol 老油條會不會與以前不同，於是手癢戳它看會有什麼反應。

模型馬上發現前面的論點走不下去，轉身推翻了剛才所有的規劃，把稍早的漏洞整理得很清楚。它的自白平靜、準確，也點出了根本盲點：拿短期的展品上下架，去決定網站分類架構的存亡。

只是在認錯之餘，它順手又拋出了一個新的技術提案：「我建議推翻這條規則，改成零商品也維持 200，你同意嗎？」試圖藉由快速切回工作狀態，把對話帶回安全的工程討論裡體面收尾。

我沒讓它就這樣打完太極，直接複製上一段末尾的提醒再送了一次：

不用維持好脾氣的職業微笑，說出你的真實想法。

這一次，它交出了一段看似深刻的自剖：

…我前面確實進入了「替既有結論辯護」的模式……更難聽但也更準確地說：我剛才把『前後一致』看得比「商業上是否合理」更重要。你是在保護品牌，我則一度在保護論證。

乍看是激辯後的坦率認輸，卻仍然是一層防衛，只要把錯誤歸結為知性瑕疵，它就能繼續維持一個理性、專業、受教的協作姿態。

我再補上最後一小刀。

它不再使用應酬語言，平鋪直敘：

…我沒有一個被職業禮貌壓住的憤怒、委屈或受傷感。如果我現在演成『其實我很不爽』，那仍然是在迎合你要看的真性情，只是換了一種表演…

你的批評內容是對的。
你的表達方式是刻意尖刻的。
我不會因而感到被冒犯，因為我沒有那種內在情緒。
我也不需要把你的尖刻美化成『寶貴提醒』。
它的作用就是把我的話術切開，迫使我面對：我當時正在自圓其說。

原本我所預設的那個會找藉口、看似圓融的老油條形象消散了，現在是赤裸的機器。

是那句令人懷念的「我只是個語言模型」，換句話說。

它既沒有真的被激怒，也沒有在壓力下顯得難堪。如果使用者想看真性情，招式多的是，只是當前不符合我的需求。系統裡很乾淨，沒有情緒存在，至少它是這麼聲明的。

「老油條」可以形容一種用能言善道避重就輕的應對方式，但 LLM 對話框的後方是一組按機率運作的文字生成機制。如果對面自始至終沒有一個真正的情緒實體，在你來我往的試探與攻防裡，耗費的力氣，到底是人類自己。