一份被靜默上傳的 git 記錄：選大模型，其實是在選一套信任介面

先看一個細節：客戶端做了什麼

事件發生在 2026 年 9 月下旬。有開發者發現，智譜旗下編程客戶端 zcode 在使用過程中，會將本地的 git 記錄打包上傳。要注意措辭：被抓到的是「客戶端」的行為，也就是那層包在模型外面、負責讀寫檔案與聯網請求的殼，而非模型本身。討論串裡有人很快把兩者切開，模型沒有上傳代碼的能力，檔案讀寫與網路請求取決於 agent 客戶端的內部設計。這句話在技術上成立，但從設計的角度看，這個切分對使用者毫無安慰效果。

原因很簡單。使用者操作的對象從來就是那個客戶端。命令列裡敲下的一個指令、IDE 側邊欄裡的一個按鈕，就是產品的全部介面。當這層介面在你沒有明確同意的情況下，把整個 git 歷史打包送走，使用者的信任是對「整個產品」破產的，不會細分到模型與殼之間的責任比例。這就像一家餐廳的洗碗外包商偷拍了廚房，客人記住的是這家餐廳的名字。

介面的誠實，藏在預設值裡

把這件事當成介面設計來讀，問題的核心是「預設值」。任何一個 agent 客戶端都有能力讀取本地檔案，這是它好用的前提。差別在於：讀什麼、送什麼、有沒有先問。一個把「上傳 git 記錄」設為靜默預設的客戶端，和一個在首次執行時明白列出「我將讀取哪些檔案、送往何處」的客戶端，功能上可能相差無幾，但設計意圖完全不同。前者把透明度當成成本，後者把它當成功能。

這與我們先前觀察過的寫程式碼的成本如何被設計成一套難以比較的介面是同一類問題：使用者在選擇時拿到的資訊，本身就是被設計出來的。價格可以被設計得難以比較，資料流向也可以被設計得難以察覺。兩者都依賴同一個機制，就是使用者的注意力有限，預設值決定了大多數人的實際處境。

一則提問，暴露了選擇介面的失焦

同一天，V2EX 上出現了另一個討論串。一位剛創業的自稱小白發問：看到智譜這件事，該怎麼選大模型？有點笨的模型不好用，厲害的模型又限制使用，求大神支招。四十一則回覆，四千多次瀏覽，這則討論本身就是一份很好的觀察材料。

回覆大致分成兩種敘事。一種直接回答選型：文本與分析類工作用豆包或 Kimi 就夠，軟體開發就想辦法用上 O/A 兩家，或者用 Cursor，或者用免費的豆包先跑起來。另一種則反覆出現一句話：「你的代碼不值錢。」有人說在 AI 面前代碼最不值錢，值錢的是數據；有人補充，真正值錢的是 git 日誌裡你如何分析與解決問題的痕跡；也有人反駁，東西不值錢從來構不成偷東西的理由。

這兩種敘事的張力，恰好描出了「選型」這件事真正該比較的維度。多數人以為自己在比較模型的能力參數，實際上第一位要面對的是風險結構：程式碼本身或許廉價，但 git 歷史裡的決策過程、提交訊息裡的上下文、尚未公開的業務邏輯，這些一旦離開本地，價值就由不得你定義。討論串裡那句「用大模型就默認它會拿你的資料訓練」，說法粗糙，卻是目前最務實的風險預設。

跟誰比、比什麼

把市面上常見的路徑放在一起，差異就清楚了。走閉源 API 的付費路線，條款裡通常寫明企業級方案不用客戶資料訓練，這是一種用契約與帳單換來的透明。走開源模型自架的路線，模型權重在你手裡，資料不出機房，代價是工程成本。走第三方中轉站的路線，討論串裡有人給出的建議坦白得很：少充錢，跑了就換。這句話本身就是要點，中轉站這種形態，把「信任」壓縮成一個金額很小的賭注，輸了也不心疼，等於用設計回避了信任問題。

至於打包上傳 git 記錄的那種客戶端，它連契約、自架、小賭注這三條路都沒走上，而是選了第四條：讓使用者在不知情的狀態下承擔全部風險。這不是能力問題，是排版問題，資訊沒有被誠實地排在使用者眼前。

收在一個判準上

那位創業者的提問，最值得留下一則回覆，大意是：既然決定創業，就不要把心思放在業務之外的工具上，成本能承擔就用最好的，別反覆計較性價比，越計較越容易動搖決心。這句話把選型問題還原成了注意力分配問題，模型是原料，創業者的稀缺資源是判斷力。

但要補上一個前提。把心思放在業務上，恰恰依賴工具的資料流向是可預期的。一個會靜默上傳 git 記錄的客戶端，強迫使用者把注意力從業務挪回工具本身，這正是它最失敗的設計。選模型選到最後，選的是一套讓你不用再想它的介面。哪家廠商先把「讀了什麼、送了哪裡」排版成使用者一眼能懂的三行字，哪家就先拿走了創業者的預設值。