ESSAY

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

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

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

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

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

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

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

人類工程師的嫌棄清單

AI 寫的代碼確實(shí)有一堆問題

不遵守團(tuán)隊(duì)約定的命名規(guī)范、目錄結(jié)構(gòu)、注釋風(fēng)格。幾百行邏輯塞進(jìn)一個文件。沒有模塊化，沒有抽象層，寫完就扔。在任何一個 code review 里，這種代碼都會被打回

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

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

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

屎山之所以是屎山，前提是有人要維護(hù)它。取消這個前提，評價就翻轉(zhuǎn)了

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

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

Agent 那邊嫌棄什么

Agent 看傳統(tǒng)軟件，嫌棄的東西更多，也更根本

鑒權(quán)。傳統(tǒng)軟件的登錄、session、cookie，整套體系圍繞一個假設(shè)設(shè)計：有一個人坐在屏幕前，持續(xù)操作。agent 的調(diào)用模式是無狀態(tài)的、高并發(fā)的、隨時中斷再隨時恢復(fù)的。這套假設(shè)從根上就不匹配

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

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

配置體系。傳統(tǒng)軟件的設(shè)置頁面有幾十上百個選項(xiàng)，散落在各處，給人類慢慢調(diào)。agent 需要的是一個聲明式的配置 schema，一次性把所有偏好注入進(jìn)去。要改一個設(shè)置項(xiàng)，可能得導(dǎo)航五層菜單

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

這四件事有一個共同點(diǎn)：全部圍繞「操作者是人類」這個假設(shè)設(shè)計。當(dāng)操作者換成 agent，假設(shè)本身就塌了

幾百萬個已經(jīng)部署的服務(wù)不會自己長出給 agent 用的接口

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

這是一個根本性的不對稱

心智模型斷了

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

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

Agent 沒有這張地圖。每次進(jìn)入一個代碼庫，都是從零開始構(gòu)建上下文

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

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

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

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

GitHub 上出現(xiàn)了非人類的綠點(diǎn)

Agent 已經(jīng)開始往 GitHub 上提交 PR 了

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

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

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

開源社區(qū)大概是第一個正面撞上這個問題的地方。但這個問題會蔓延到所有圍繞「人」組織的協(xié)作制度里：代碼審查、質(zhì)量認(rèn)證、專業(yè)資質(zhì)、知識產(chǎn)權(quán)歸屬

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

這個不對稱里的機(jī)會

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

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

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

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

純數(shù)據(jù)驅(qū)動的服務(wù)（Boss 直聘的工作信息、小紅書的用戶內(nèi)容），數(shù)字層占比最高，被 agent 接管的速度最快

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

需要法人背書的服務(wù)（銀行轉(zhuǎn)賬、合同簽署、投行報告），數(shù)字層完全可以自動化，但合規(guī)框架要求背后有真實(shí)的責(zé)任主體

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

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

「兩看相厭」不會永遠(yuǎn)持續(xù)

歷史上每次范式?jīng)_突的結(jié)局，都是出現(xiàn)了一個第三方的中間層，讓雙方各自面對中間層，不再直接面對彼此。匯編和高級語言之間出現(xiàn)了編譯器，C 和 Java 之間出現(xiàn)了 JVM

歷史上每次「兩看相厭」的結(jié)局，都是第三個物種出現(xiàn)

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

最先做出這種雙棲架構(gòu)的團(tuán)隊(duì)，可能拿到下一代軟件基礎(chǔ)設(shè)施的定義權(quán)

AI 不吃軟件，AI 吃接口

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

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

現(xiàn)在唯一確定的是：兩邊都在嫌棄對方，而兩邊都是對的