兩看相厭：Agent 和傳統軟件，都覺得對方是屎山

ESSAY

一個傳統后端工程師看 Claude Code 自動生成的代碼，命名混亂，不遵守團隊規范，幾百行邏輯擠在一個文件里。他的評價：屎山

反過來，一個跑在 Claude Code 上的 agent 試圖調用這位工程師維護了三年的系統。登錄要 session，改個配置要導航五層菜單，接口文檔是給人類讀的散文體，報錯信息是一句自然語言彈窗。agent 的評價大概也差不多

兩邊都覺得對方不堪用。這個狀態，叫「兩看相厭」

人類工程師 Agent 命名混亂，不遵守規范 幾百行塞一個文件 沒有模塊化，寫完就扔 不可維護 鑒權體系對 agent 無效 狀態綁在 UI 組件里 更新了沒人通知 agent 配置要導航五層菜單 兩邊都對，兩邊都嫌棄 歷史上每次出現這種互相嫌棄，都是范式切換的信號

歷史上每次出現這種互相嫌棄，都是范式切換最誠實的信號。匯編程序員嫌高級語言臃腫浪費，高級語言嫌匯編不可維護。C 程序員嫌 Java 慢得離譜，Java 嫌 C 的手動內存管理是野蠻操作。每一次，雙方在各自的評價體系里都是對的

但最終的結局，都是出現了一個新的中間層，讓兩邊不再需要直接面對對方

過去每一次，都是兩代程序員之間的事。這一次，其中一方換了物種

人類工程師的嫌棄清單

AI 寫的代碼確實有一堆問題

不遵守團隊約定的命名規范、目錄結構、注釋風格。幾百行邏輯塞進一個文件。沒有模塊化，沒有抽象層，寫完就扔。在任何一個 code review 里，這種代碼都會被打回

這些嫌棄完全合理，在人類工程師的評價體系里

但這里有一個前提值得拆開看：人類對「代碼質量」的直覺，建立在一個假設上。這段代碼要被人讀很多遍。要被維護，要被改，要被另一個人在凌晨三點 debug 的時候讀懂

如果代碼只被執行一次然后丟棄呢？評價標準就應該從「可讀性」變成「執行正確性」。這兩個標準選出來的代碼，長得完全不一樣

屎山之所以是屎山，前提是有人要維護它。取消這個前提，評價就翻轉了

而且這一側的問題有一個重要特征：它在自動消解。明年的模型寫出來的代碼就比今年干凈一大截，后年更好。這條曲線在自動上升

記住這個特征，后面會用到

Agent 那邊嫌棄什么

Agent 看傳統軟件，嫌棄的東西更多，也更根本

鑒權。傳統軟件的登錄、session、cookie，整套體系圍繞一個假設設計：有一個人坐在屏幕前，持續操作。agent 的調用模式是無狀態的、高并發的、隨時中斷再隨時恢復的。這套假設從根上就不匹配

狀態耦合。傳統前端框架把數據狀態綁在 UI 組件樹上。agent 想操作一個數據，必須先理解組件的嵌套層級。CLI Anything 做的事情之一，就是把數據從 UI 組件里解綁出來，讓 agent 能直接觸達

版本更新。人類有 changelog 和遷移指南可以讀。agent 需要的是機器可讀的接口變更 diff。現在幾乎沒有軟件提供這個東西。每次軟件更新，agent 之前建立的調用邏輯就可能失效

配置體系。傳統軟件的設置頁面有幾十上百個選項，散落在各處，給人類慢慢調。agent 需要的是一個聲明式的配置 schema，一次性把所有偏好注入進去。要改一個設置項，可能得導航五層菜單

Agent 眼中的傳統軟件 鑒權 假設有人坐在屏幕前 agent 無狀態、高并發 狀態耦合 數據綁在 UI 組件樹上 改數據必須理解組件嵌套 版本更新 changelog 是給人讀的 agent 需要機器可讀 diff 配置體系 設置散落在各層菜單 agent 需要聲明式 schema 共同根源 全部圍繞「操作者是人類」這個假設設計 當操作者換成 agent，假設本身就塌了 這些問題不會隨模型迭代自動消解

這四件事有一個共同點：全部圍繞「操作者是人類」這個假設設計。當操作者換成 agent，假設本身就塌了

幾百萬個已經部署的服務不會自己長出給 agent 用的接口

和上一段對比一下。人類嫌 AI 代碼爛，這個問題會隨著模型變強自動消解。但 AI 嫌傳統軟件不好用，這個問題不會自動消解。已經部署的幾百萬個服務，不會自己重新設計鑒權體系，不會自己把狀態從 UI 組件里解綁，不會自己生成機器可讀的版本 diff

這是一個根本性的不對稱

心智模型斷了

上面講的是接口層面的沖突。再往下一層，還有一個更深的斷裂

人類程序員理解一個系統，靠的是「心智模型」。入職一家公司，花幾周甚至幾個月，把整個系統的架構、數據流、模塊關系內化成腦子里的一張地圖。之后的每一次修改，都在這張地圖上定位、操作

Agent 沒有這張地圖。每次進入一個代碼庫，都是從零開始構建上下文

過去幾十年的代碼組織方式，都預設了一件事：讀者已經了解整體架構。文件拆分、模塊劃分、命名約定，全部建立在這個預設上。一個有心智模型的人，看到 UserService 就知道去哪里找 UserRepository。agent 不知道，它需要先遍歷目錄結構，讀若干個文件，才能建立起局部的上下文

這也解釋了一個讓人類工程師很難接受的現象：agent 傾向于把邏輯集中在一個文件里。從 context window 管理的角度看，減少文件跳轉就是減少 token 消耗，集中在一起反而是最高效的組織方式

你把代碼拆成 200 個文件叫工程規范，agent 把代碼寫進 1 個文件叫 context 效率。誰是屎山，取決于你問誰

人類幾十年積累下來的工程規范（模塊化、關注點分離、DRY 原則），在 agent 的評價體系里，大概率需要被重新審視。這些規范存在的理由是幫助人類協作。如果協作者換了物種，規范本身就得跟著變

GitHub 上出現了非人類的綠點

Agent 已經開始往 GitHub 上提交 PR 了

傳統開源社區有一套圍繞「人」建立的協作制度。人類寫 PR，人類 review，人類 merge。你的 GitHub profile、commit 歷史、社區里的口碑，構成了一個完整的聲譽體系。誰靠譜、誰的代碼可以信任，大家心里有數

但當 agent 開始參與，這套體系就遇到一個很實際的問題：你怎么給一個 agent 建立 reputation？一個 agent 的 PR 應該由誰來 review？如果答案是「由另一個 agent 來 review」，那人類在這個閉環里扮演什么角色？

GitHub 的 contribution graph 里開始出現非人類的綠點，但沒有人知道該怎么給它們算 reputation

開源社區大概是第一個正面撞上這個問題的地方。但這個問題會蔓延到所有圍繞「人」組織的協作制度里：代碼審查、質量認證、專業資質、知識產權歸屬

這些制度的底層假設都是：參與者是人。當參與者不全是人的時候，制度本身需要重建

這個不對稱里的機會

「兩看相厭」里最值得盯住的，是那個不對稱

AI 對傳統軟件的嫌棄，催生的是一個真實的改造市場。誰幫傳統軟件長出 agent 可用的接口，誰就是這次范式切換里的基礎設施提供商。CLI Anything、MCP、飛書 CLI，都是這個方向上不同的入口

它們做的是同一件事：幫現有軟件「再接口化」，從為人類編譯，變成同時為 agent 編譯

四類服務的「數字層占比」與被接管速度 接管快 接管慢 純數據服務 Boss 直聘、小紅書、Twitter 數字層占比最高，被接管速度最快 物理交付服務 美團、Uber、順豐 agent 做前半段，最后一公里需要物理介入 法人背書服務 銀行轉賬、合同簽署、投行報告 數字層可自動化，但合規要求真實責任主體 專業黑盒服務 FFmpeg、Blender、CAD 引擎 agent 離不開它們，但會重新定義入口

純數據驅動的服務（Boss 直聘的工作信息、小紅書的用戶內容），數字層占比最高，被 agent 接管的速度最快

觸發物理世界交付的服務（美團、Uber、順豐），數字端的操作本身很簡單，但最后一公里需要物理實體介入。agent 只能完成前半段

需要法人背書的服務（銀行轉賬、合同簽署、投行報告），數字層完全可以自動化，但合規框架要求背后有真實的責任主體

依賴幾十年積淀的專業黑盒的服務（FFmpeg、Blender 的幾何求解器、CAD 引擎），agent 離不開它們，但會重新定義入口

一個判斷框架：你投的公司，在這四類里屬于哪一類？它的服務中，數字層占整個價值鏈的比例有多大？這個比例越高，被 agent 接管的速度越快，被「再接口化」的價值也越大

「兩看相厭」不會永遠持續

歷史上每次范式沖突的結局，都是出現了一個第三方的中間層，讓雙方各自面對中間層，不再直接面對彼此。匯編和高級語言之間出現了編譯器，C 和 Java 之間出現了 JVM

歷史上每次「兩看相厭」的結局，都是第三個物種出現

這次的「第三個物種」，大概率是一種「雙棲軟件」。天然同時暴露人類界面和 agent 接口，兩邊的數據和狀態實時同步。人類在 GUI 里編輯到一半的東西，agent 可以在 CLI 里接著完成。agent 在 CLI 里產出的東西，人類可以在 GUI 里繼續調整

最先做出這種雙棲架構的團隊，可能拿到下一代軟件基礎設施的定義權

AI 不吃軟件，AI 吃接口

軟件會活著。FFmpeg 會活著，Blender 會活著，CAD 求解器會活著。但它們的入口會被重新定義

說不準這個中間層最終長什么樣。MCP 是一種可能，CLI Anything 是一種可能，某種還沒被命名的東西也是一種可能。窗口期大概率很短，一兩年內就會有一個被廣泛采納的方案出現

現在唯一確定的是：兩邊都在嫌棄對方，而兩邊都是對的