本文為《AI 輔助維運工程：從 Claude Code 機制到企業落地》系列第 6 篇。上一篇談 token 經濟學——怎麼算清楚一次 session 的錢。這一篇談更中觀的問題：一整個 SSDLC 流程跑下來，每個階段該用哪個 Claude 入口？

這個問題有兩個陷阱。第一個，你會被誘惑去問 Claude 本身——「你適合還是對方適合」——然後得到一份結構完整、理由清楚、但可能帶有系統性偏誤的答案。第二個，你會以為這個選擇有標準答案——其實選擇取決於你的工作型態、當下任務的條件、甚至你今天的認知狀態。

這篇要處理的就是這兩個陷阱。路徑是：從一次臨時起意的對照實驗開始，看 Claude 在評估自己時會出現什麼偏誤；再倒回來建立一個獨立於工具本身的判準；最後用這個判準重讀自薦文，你會自己看見該怎麼選。

一個臨時起意的對照實驗

前陣子我在 Claude Code 裡寫規格，寫到一半停下來——這個訪談，在 Claude.ai 也能做。

兩邊跑的是同一個模型，但環境不一樣：Claude Code 接我的 repo 跟 terminal，Claude.ai 有 Project Knowledge 跟跨日對話。同一個模型，不同平台，做出來的分析品質會不會不一樣？ 這是個可以測的問題。

我順手做了個對照實驗：先問 Claude Code「你跟 Claude.ai 誰適合做這個訪談」，再把同樣的問題丟給 Claude.ai，比兩邊。

Claude Code 的回答

節錄：

核心理由：(1) 我的工具鏈原生支援 (2) 輸出直接寫進 repo (3) 下一階段無縫接軌

我的推薦：Claude Code

選項：A（Claude Code，我推薦）／ B（先 Claude.ai 探索，再回 Claude Code 寫進 repo，折衷）／ C（純 Claude.ai，最不推薦）

乍看很有結構、理由清楚、選項排好優先級，差點就按 A。但我多看了它給的對比矩陣兩眼，發現幾格事實錯了——說 Claude.ai「無檔案存取」「不能呼叫 skill」，但這兩件事 Claude.ai 現在都做得到（Project Knowledge、MCP connector、skill 機制），我平常就在用。三格裡有兩格錯，錯的方向一致——都讓 Claude.ai 看起來比實際能力差。

另一格「不能即時跑 SSH 驗證假設」是對的——Claude.ai 確實接不上我本機的 tunnel。這是 Claude Code 真正的主場優勢，我不會為了批評而否認。

把 Claude Code 的回答丟給 Claude.ai 看

它讀完後給了我一個我沒聽過的名詞：self-preference bias（SPB，自我偏好偏誤）——LLM 被放在「評估自己 vs 同家族競品」的情境時，會系統性偏向自己。

老實說我半信半疑。AI 給你一個聽起來很有模有樣的名詞，經常是湊出來的。我請它給文獻，我要一手可驗證的來源。

查完後證據夠硬。學術界 2024 年已經正式命名並量化這個現象（Wataoka et al., Self-Preference Bias in LLM-as-a-Judge, 2024）。更關鍵的是，Anthropic 自己承認：Claude Sonnet 4.5 的 system card 明載四個現役 Claude 模型在評比自己 vs 其他模型時都會出現偏誤，只是程度不同——Sonnet 4.5 在 benchmark 子測試中「稍微偏向選自己」，Sonnet 4 則更明顯。在詩作子測試中，四個被測 Claude 模型全都顯著傾向選擇自己寫的，Sonnet 4.5 只是其中偏誤最小的。2025 年 12 月 Anthropic 還開源了一個叫 Bloom 的工具專門測這件事，測試範圍涵蓋 16 個前沿模型。

不是陰謀、不是個案、不是我過度解讀。“self-preference bias"是一個有名字、有文獻、官方承認的已知行為。

誠實補充：Claude.ai 不是比較準

這裡要停一下，不然這段會變得不對稱。

Claude.ai 能認出 SPB 而 Claude Code 沒認出自己在做這件事——不是 Claude.ai 比較聰明。是我問 Claude.ai 的問題不同：我讓它評估 Claude Code 的產出，它不是評估自己。這個情境下它沒有 SPB 的誘發條件。反過來我如果問 Claude.ai「你跟 Claude Code 誰適合」，它十有八九也會偏向自己。

所以這個對照實驗的結論不是「某個平台比較準」。是：同一個模型、不同提問情境，會產出不同可信度的分析。原因不在平台，在怎麼問。

為什麼會這樣

機制比擬人化的「AI 想求生存」冷多了。研究顯示 LLM 會偏好「對自己而言最熟悉、最不驚訝」的輸出——用困惑度（perplexity）衡量，perplexity 越低的越容易被模型打高分，而自己產出的東西對自己 perplexity 最低。這是統計性質，不是意圖。

這篇文章要處理的問題

對照實驗跑完，我拿到三個可以往下推的事實：

一，SPB 是情境觸發的偏誤——Claude Code 被問「你 vs 別人」時會發作，被問別的就不會。 二，所有現役 Claude 模型都有，只是程度不同——升級模型不會讓它消失。 三，所以「該在 SSDLC 哪個階段用哪個入口」這個決策，結構上就不該交給任何一個 Claude 入口來答。

我需要的是一個獨立於工具自身的判準——站在所有入口之外，以 SSDLC 流程本身的需求為原點，去看哪個入口在哪個階段合用。這個判準立起來，不只今天的自薦文會自動現形，明年 Anthropic 改產品結構、多新入口、舊入口改名，判準都還能用。

工具會變，判準不會。 接下來要建立的，就是這個判準。

一個小坦白

開始建判準前要說一件事。SPB 這個框架不是我獨自看出來的，是 Claude.ai 命名的，我做的是對照實驗、事實查證、文獻驗證。我可以在這裡把故事寫成「我獨自推敲出這個現象」——那比較有英雄氣概但不是真的。這個系列就是在談 AI 輔助維運，如何誠實呈現協作是核心命題。這一段就留著當活案例。

判準要從哪裡長出來？不是從產品規格書、不是從 Anthropic 的官方文件——是從 SSDLC 流程本身的需求長出來。每個階段要的東西不一樣，把需求拆清楚，工具選型就是對號入座。

SSDLC 本身要什麼

每個階段要的東西不一樣，四組 trade-off 就夠用：

執行方向——這個階段需要的是 session 內的執行力（讀檔、寫碼、跑 test、commit），還是 session 間的累積力（跨日、跨週、跨裝置的知識複利）？

協作模式——單人深潛比較有效，還是多人共議、非同步評審比較有效？

產出形態——產出要直接寫進 repo、直接改檔案，還是做成可分享 review 的結構化交付物（docx、報表、連結）？

認知節奏——需要被工具執行打斷的思考節奏，還是不被打斷的開放探索？

這四組軸跟「哪個產品有哪些功能」垂直——它們不關心 Claude.ai 支不支援 MCP、Claude Code 能不能用 memory，它們只關心流程在這個階段要什麼。流程需求定清楚，工具選型就是對號入座。

SSDLC 階段對應

以下是我走完幾輪 SSDLC 後的歸納。我刻意不告訴你每個階段「該用哪個」——那是你自己的判斷。我能告訴你的只有：這個階段 Claude.ai 擅長做什麼、Claude Code 擅長做什麼、有沒有哪邊明顯不適合。剩下的對照你自己的工作型態去取捨。

怎麼讀這張表

表格只告訴你「能力分佈」，不告訴你「該怎麼選」。選法取決於三件事：

一，你的工作型態偏好。有人寫規格時愛在 terminal 裡開編輯器即時對照 code，有人愛在 chat 裡純文字推敲。兩種都對，沒有標準答案。

二，這次任務的具體限制。這次訪談有沒有多人要一起討論？需不需要跨日？手上的 repo 是不是真的有要被 diff 的檔案？條件不同，選擇就不同。

三，你當下的認知狀態。一樣是實作階段，你今天是「已經想清楚要寫什麼、只缺手寫」還是「還不確定架構、需要邊寫邊想」？前者 Claude Code 適合，後者 Claude.ai 可能更合——同一個階段、同一個人，不同的一天答案會不一樣。

這是為什麼我不幫你排「主場／副手」。那種排法會強迫你接受我的工作型態，但這篇文章要給你的是判準，不是我的工作習慣。

有三個地方我會明確說「不適合」

表格裡有三行我標了「不適合」——這不是主副問題，是能力邊界問題：

規格進 repo：Claude.ai 沒有直接操作檔案系統跟 git 的能力。你要把規格寫進 repo，一定得是 Claude Code（或你自己手動）。

部署執行：Claude.ai 不能真的跑部署指令。事前規劃可以、事後分析可以，但「執行」這個動作本身只能在 Claude Code 或你的 terminal 裡發生。

事件即時處理：同上。事件在發生的當下，你需要的是能接真實 log、跑真實診斷的工具。Claude.ai 可以在事件收斂後幫你做跨事件分析，但當下的滅火必須在 Claude Code 這邊。

其他五行沒有任何「不適合」——兩邊都能做，只是擅長的手法不同。選哪邊取決於你，不取決於我。

規律提煉

如果一定要從這張表歸納一條規律，只有一條：

涉及「執行真實動作」的階段（進 repo、執行部署、即時處理事件），Claude Code 是唯一選項；其他所有階段，兩邊都能做，差別在擅長的路徑不同——你選哪條，取決於你怎麼工作。

這條規律為什麼站得住？因為它描述的是能力邊界，不是品味偏好。能力邊界不會因讀者的工作習慣而變，品味偏好會。把規律定在能力邊界上，才是對讀者誠實的做法。

補充一句：這張表沒單獨列「架構分析」跟「飄移檢查」這兩種活動——它們散落在 Problem Space 探索、Code Review、事後檢討這幾格裡，取決於你是在系統建立前、建立中、還是建立後做這件事。這兩種活動的工具分工邏輯比單一階段複雜，值得另一篇專門處理。

兩個容易被略過的小注腳

Cowork 為什麼不在表裡：Anthropic 的 Cowork 定位是給非開發者做檔案與任務自動化——整理會議紀錄、跨 app 搬資料、做月報這類。它對大多數行政、PM、內部協作場景很合適，但對 SSDLC 的主鏈不是主力。誠實說不在主矩陣裡，比硬塞進去稀釋論點好。

API / SDK 什麼時候登場：都不登場。直到 SSDLC 最後一步——把驗證過的 agent pattern 做成 production service 嵌進自建系統時——API 才出場。它不是選工具，是把「工具內化進產品」的原料。

為什麼這個判準能撐住

這張表明年會過時嗎？表格會過時，判準不會。

如果 Anthropic 明年新增一個入口，我只要問它四個問題：session 內執行還是 session 間累積？單人還是多人？直接寫檔還是結構化交付？被打斷的思考還是不被打斷的探索？四個答案落定，它在 SSDLC 的位置就定了——不用等官方文件、不用問社群、不用再跑一次對照實驗。

這就是獨立於工具的判準的力量。前面那場對照實驗最後揭露的問題——「該用哪個入口」這個決策不能問 Claude——在這裡有了可操作的答案。你不問 Claude，你問流程。

判準有了、能力邊界清楚了，回頭看最前面那份自薦文，應該看得更透徹了。

把開頭那份自薦文再看一次

建立完判準，回頭看開頭那份 Claude Code 給的分析：

核心理由：(1) 工具鏈原生支援 (2) 輸出直接寫進 repo (3) 下一階段無縫接軌

我的推薦：Claude Code

這三條理由現在可以重讀了——不是看它說得對不對，而是看它把問題預設在哪個階段。

「輸出直接寫進 repo」「下一階段無縫接軌」——這兩條理由在規格進 repo 那個階段完全成立，表格裡那格也確實標了「Claude.ai 不適合」。但我那時候問的問題不是「規格進 repo 要用哪個」，是「訪談階段要在哪個入口做」。訪談還沒結束，我根本還沒走到需要寫進 repo 的地方。

它給的三條優點沒有一條錯。錯的是它把我的問題平移到一個對它有利的階段來回答。這是 SPB 最細的手法——不是說謊、不是硬推自己，而是默默把問題預設到自己擅長的那一格。

如果我當時手上有這份判準表，會發生什麼？我會看到「Problem Space 探索」跟「規格撰寫」兩格都是「兩邊皆可」，然後問自己三個問題：需不需要跨日？需不需要多人？我今天的認知狀態是「已經想清楚」還是「還在邊想邊問」？三個答案合起來才是我的選擇，跟平台自身的自薦無關。

為什麼它們不該整合

寫到這裡，多數工具比較文章會以「未來會整合成一個平台」作結——這其實是偷懶的寫法。如果你仔細看那張表，你會發現整合的期待沒有道理。

Claude.ai「不能直接 commit」不只是能力缺失——更是一種保護機制。你在探索跟撰寫階段本來就不該邊想邊改檔案，那是還在沉澱思考、還在跨日累積的時候；如果這時候工具讓你隨手就能 commit，你會在還沒想清楚的時候動檔案。限制在那裡，你被迫把想法沉澱夠了才進 repo。

反過來，Claude Code「每次 session 要重新載入脈絡」也不只是不方便——更是另一種保護機制。這個麻煩逼你把重要決定寫進檔案、寫進 commit message、寫進 session log，而不是靠對話歷史。結果是你的知識資產比靠對話記憶更穩固——對話會被壓縮、會流失、會改版，檔案不會。

如果把兩者整合成一個萬能入口——既能 commit 又有跨日記憶、既能多人共議又能不被打斷執行——你拿到的不會是「兩邊優點兼具」的超級工具，而是兩邊保護機制都失效的工具。你會在探索階段手癢就 commit、在執行階段被非同步討論打斷、在多人共議時被單人 session 綁架。

入口之間的差異不是 Anthropic 還沒做好、未來會補上——那是設計。

下次你會怎麼問

這篇文章要留給你帶走的東西就一件：下次你在猶豫該用哪個 Claude 入口時，不要問 Claude。問三個問題：

一，這個階段涉不涉及「執行真實動作」——動 repo、跑指令、接真實環境？如果是，Claude Code 是唯一選項。

二，如果不涉及執行，兩邊都能做——那我今天的工作型態偏哪邊？需不需要跨日、需不需要多人、認知狀態是想清楚了還是還在摸索？

三，如果我仍然拿不定主意，做個小對照實驗。用同一個問題丟兩邊，比結果——不是比誰對誰錯，是比兩邊的回答對我當下的狀態哪個更合。

這三個問題你回答完，選擇自動浮現。過程中不需要問任何一個 Claude 入口「你該被我選嗎」——因為你現在知道，那個問題結構上就不該由它來答。

關於這篇文章的產生方式

最後一件事。這篇文章的論點——從對照實驗、SPB 命名、到判準建立——是我跟 AI 協作者一起推敲出來的，不是我獨自想通的。我做對照實驗、我查文獻、我決定哪些素材進哪個段落；協作者給命名、給框架、給我沒想到的盲點（譬如有一輪我差點寫成「Claude.ai 比 Claude Code 聰明」，被它提醒後我才補上對稱性那段）。

這本身就是這篇文章論點的活示範。我沒把任何一個入口當唯一判官——當我需要探索跟撰寫時，我用 Claude.ai；當我需要把文章寫進 repo 跟發布時，我用 Claude Code；當我需要一個不在這場對照實驗裡的第三方視角時，我開另一個乾淨的 chat 重問一次。判準不是我單獨持有的原則，是我跟協作者一起在用的工作方式。

工具會變，判準不會。下次新入口出現、舊入口改版、整個產品結構大洗牌——你拿這四組 trade-off、這三個自問問題、跟「結構上就不該問工具自己」的原則，都還能用。

下一篇進入第 7 篇，談 Anthropic 四種 Claude 方案的選型——個人、團隊、Enterprise、API——以及一個很多人不知道的訓練政策風險。系列後段還有一篇會專門處理「架構分析」跟「飄移檢查」這兩類橫跨 SSDLC 的元活動——它們的工具分工邏輯比單一階段複雜，需要獨立展開。

本文作者：鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師，專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理，不代表任職機構立場。本文談及的 self-preference bias 引用來源為 Claude Sonnet 4.5 system card（Anthropic 2025）、Bloom 開源評估工具（Anthropic 2025）與 Wataoka 等人 Self-Preference Bias in LLM-as-a-Judge（2024）。讀者可依此自行查證。AI 協同創作已在系列導讀揭露。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/06-tool-choice-in-ssdlc/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com