崩潰的很少是模型：DeepSeek 開發者在 harness 與 zcode 之間，量的是依賴面積

套在模型外的 harness 功能多，卻常在更新之後壞掉；直連 DeepSeek 的現成客戶端功能少，但能穩定跑完一個專案。這道選擇題真正在量的，是每個人願意扛多少依賴。

深夜趕工的人，問了一個很實際的問題

對正在衝 AI 專案時程的開發者來說，模型答錯還算小事，更常見的挫折是工具先壞了。知乎最近出現一則提問，標題只有一行：「DeepSeek 用現在的 ds harness 好還是 zcode 好？」掛著「AI 工具」與「DeepSeek」兩個標籤。提問者說，用 harness 做專案，經常崩潰、不穩定，外掛一更新還得整個重新除錯一遍；換成現成的 zcode 直接接 DeepSeek，這些煩惱全部消失。於是他上來問：到底該用哪一個。

原文把工具名寫成「deep thick harness」，從上下文看應是輸入或語音轉文字的訛誤，指的是 DeepSeek 生態裡的 harness 類工具；zcode 則是提問者口中「接上就能用」的現成客戶端。

這則提問的價值在於它的普通。沒有驚人數據，沒有大廠新聞，卻是過去一年大量 AI 開發者反覆撞上的處境：模型能力已經普遍夠用，真正拖慢專案的，經常是套在模型外面那一層軟體。

harness 在模型之外，多做了哪些事

harness 原意是套在馬身上的挽具，工程圈借來稱呼「把模型套上、驅動它的整套裝置」。在 AI 編碼的語境裡，一套 harness 通常要處理幾件事：管理上下文，決定哪些檔案與對話要塞給模型；發出工具呼叫，讓模型能讀寫檔案、執行指令；跑代理循環，讓模型決策、看結果、再決策；再加上外掛系統，讓第三方替它加功能。

zcode 這類現成客戶端走另一條路。它把 API 接線、介面與基本工作流程包好，使用者填入金鑰就能開工，代價是擴充點有限。你拿到的是別人已經調好的組合，少了自己拼裝的空間，也少了拼裝會壞的部分。

兩者的差別可以這樣講：harness 賣的是可能性，現成客戶端賣的是確定性。提問者的困境，就是可能性與確定性在同一個專案裡撞期了。

套了框架，為什麼反而容易壞

先看更新節奏。模型這一端的迭代速度快得反常，下遊工具被迫跟著跑。這個速度有數字可佐證：Anthropic 年化營收七個月從 90 億美元衝上 650 億美元，營收衝得這麼快的行業，產品迭代不會慢。模型行為每幾週一變，harness 就得不斷調整提示詞策略、工具介面與相容性，版本號跑得快，完整測試跟不上，最終使用者就成了發布流程的最後一關測試員。

再看外掛架構。編輯器版本、執行環境、每個外掛各自的維護者與發版節奏，構成一張版本矩陣，任何一格升級都可能讓原本正常的組合失效。提問者說的「更新後就需要重新除錯外掛」，正是矩陣失配的標準症狀：你什麼都沒動，只是接受了別人的更新。

維運資源是第三個因素。不少 harness 屬於開源或小團隊作品，熱門時更新飛快，熱潮退去或維護者另有正事，破壞性變更就沒人把關。這類工具授權通常免費，使用者支付的是時間。

這也不是 AI 時代才有的病。從 Vim 與 Emacs 的外掛地獄，到 npm 相依套件的連環爆，軟體業把同一齣戲演了幾十年：功能高速堆上去，穩定性由終端使用者自己吸收。AI 工具鏈只是把這個循環壓縮到以週為單位。

穩定的帳，記在使用者頭上

harness 的利益與成本，分帳並不對稱。功能上限由整個社羣共享，有人寫了好用的外掛，所有人都能裝；崩潰那一刻的時間成本卻由每個使用者獨自支付，而且常在最不恰當的時刻支付，例如交付前一天。提問者專門發文求助，代表這筆時間帳已經大到影響工作。

現成客戶端的邏輯剛好相反。zcode「沒這些煩惱」的原因，是相容性問題被移到工具開發者內部，出貨前由他們自己吸收。用管理的語言說，一種是自己管理供應鏈，一種是把供應鏈外包給單一廠商。

把這件事濃縮成一個詞：依賴面積。你讓越多別人的程式碼參與日常工作，依賴面積就越大。面積越大，功能越豐富，但任何一小塊變動，震動都會傳到你身上。harness 與 zcode 的選擇題，本質上是在決定要把依賴面積畫多大。

當工具壞掉而官方修復速度跟不上，使用者的處境都長得很像，社羣開始流通土炮自救。這畫面並不陌生：YouTube 手機版卡在 480P、重灌只救了一半人的事件裡，連付費訂閱者都只能等。AI 工具鏈的差別在於，壞掉的是生產線，等不起。

這道選擇題，會自己消失嗎

短時間內不會，但方向可以預期。套件管理器走過的路，AI 工具生態遲早要再走一次：版本鎖定、相依鎖定檔、強制變更日誌，這些老派紀律會被搬進來，屆時「更新後壞掉」會從日常變成事故。另一個變數是模型廠商親自下場。一旦 DeepSeek 或其他廠商推出官方編碼用戶端，把相容性責任收回自己身上，第三方 harness 的空間會被壓縮，直連反而成為預設選項。

在那之前，開發者還是得做選擇，而選擇的第一依據是專案性質，工具本身的優劣排在後面。

先守住下限，再求上限

給正在選的人，判斷順序大致是這樣。要交付的專案，穩定下限優先：直連客戶端能完成的工作就交給它，harness 留給實驗型 side project，別為了多出來的功能把整條生產線押在會崩潰的組合上。

升級要有紀律。關掉自動更新，鎖定目前可用的版本，每次升級前把變更日誌看完，時機選在能承擔壞掉的時段，例如週末上午，而非趕工的深夜。

環境要可拋棄。把工具鏈裝進容器或獨立環境，壞了整個重建，比逐個外掛查毛病快得多。重置要腳本化，把「重新除錯外掛」的步驟寫成一鍵腳本，崩潰成本就從小時級降到分鐘級，harness 的折騰程度會立刻下降一個量級。

回到提問者。他的問題裡其實已經帶著答案的素材：在他描述的情境中，zcode 直連 DeepSeek 已經「沒這些煩惱」，那就先用它把專案做完。等到某天需要 harness 獨有的能力，而且願意支付對應的維護時間，再回來也來得及。工具沒有永久正確的選項，只有與當下專案對稱的選項。

後續值得盯的訊號：你用的 harness 專案有沒有開始提供版本鎖定與完整變更日誌；DeepSeek 官方何時推出第一方編碼用戶端；zcode 這類直連工具的功能邊界，何時擴及代理循環；社羣討論區裡崩潰回報的數量是否收斂。其中任何一個到位，這道選擇題的答案就會往另一邊移動。