小編精選 - 技術文章翻譯 · 03月28日

AI 並沒有破壞你的文化，而是把它暴露出來。

一位工程師對某個決定提出異議。得到的回應是：「ChatGPT 推薦了別的方案。」關鍵不在於這個推薦本身，而在於他們尋求的是權威的指引，而不是理性的論證。你看到的不是一個人工智慧問題，而是一個早於模型出現多年的文化問題。

我曾是先知。

神諭一直都在那裡

在 ChatGPT 之前，團隊會求助於 Stack Overflow。在 Stack Overflow 之前，團隊會求助於資歷最老的那位資深工程師。當團隊缺乏框架時，他們就會尋找權威人士。他們會用身邊最有權威的人來填補決策真空。

ChatGPT 是迄今為止最容易使用的預言機。它可靠、凌晨兩點也可用，而且從不讓你因為提問而感到尷尬。工程師當然會使用它。

問題是，他們要用它取代什麼。

如果你的團隊沒有共享的架構決策框架，沒有清晰的權限結構，也沒有達成共識的權衡取捨方法…那麼「ChatGPT 推薦了其他方案」只不過是「谷歌說的」、「我讀過一篇部落格文章」或某人最近參加的技術講座的最新版本而已。資訊來源改變了，但放棄思考的本質卻始終如一。

這就是文化問題。而且這個問題早在第一次API呼叫之前就存在了。

有一類團隊受到的衝擊最大。這類團隊技術精湛，卻從未在壓力下清晰闡述自己的邏輯。這類團隊中，資深工程師發號施令，其他人負責執行。這類團隊的架構評審只關注效能，而非探究問題。這些團隊表面上看起來一切正常，直到「預言家」出現，皇帝的新衣問題才變得無法忽視。

許多工程文化都建立在藉來的信譽之上。 FAANG工程師在會議上的演講，其所面臨的限制條件與你截然不同。基準測試的工作負載也與你的實際情況大相逕庭。技術觀點被奉為圭臬，卻從未有人對其假設進行壓力測試。團隊學會了引用來源，而不是獨立判斷。 ChatGPT正是這種趨勢的終點……它對所有事情都擁有絕對的權威，可以隨時隨地提供服務，而且毫無阻礙，即使犯錯也無需承擔任何責任。

當一種文化已經建立在藉來的信譽之上時，一個隨時待命的權威並不會改變這種行為，反而會加速這種行為的發生。

文化究竟做了什麼

我一直扮演著權威的角色。團隊裡的所有決策都得經過我。那些成功的專案，往往都是我參與度最高的。我當時覺得，這說明我的確為團隊做出了貢獻。但實際上，這說明我建立的是一種依賴關係，而不是一個真正的團隊。工程師並非因為我的判斷力更強才聽從我的，而是因為我從未建立起一個能夠檢驗他們判斷力的文化。

ChatGPT出現後，像我以前管理的那種團隊顯然找到了替代的Oracle。界面不同，但底層問題依舊。

團隊文化並非 Confluence 頁面上列出的團隊價值觀，也並非入職後無人問津的工程原則文件，更不是充斥著表情包和偶爾勝利的 Slack 頻道。

文化就是無人監督時發生的事情。它體現了人們對決策如何制定、權衡利弊如何權衡、工程師如何在不進行人身攻擊的情況下反對糟糕想法的共識。它就像一個無形的鷹架，在你不在場的情況下支撐著整個架構。

校長們的儀表板看起來很棒。速度提升了，產量也提高了。但當被問及計劃外工作時，房間裡頓時鴉雀無聲。沒有人能給出具體數字。這些儀錶板衡量的是容易衡量的指標，而不是程式碼庫內部實際發生的情況。

在那些人工智慧工具缺乏監管的團隊中，出現的情況正如你所預料的那樣，一個團隊缺乏共同的標準。多個HTTP客戶端實現各自為政，朝著不同的方向發展。同一層面上存在著相互衝突的錯誤處理模式。針對同一類問題，甚至在同一個文件中，都存在不一致的處理方法。這並非因為工程師粗心大意，而是因為缺乏關於「正確」做法的統一框架，而人工智慧填補了這一空白的速度是任何個人貢獻者的十倍。

那些蓬勃發展的團隊在人工智慧出現之前就已經做好了充分的準備工作。標準並非對新工具的被動反應。程式碼模式被詳細記錄下來。架構決策不僅包含結果，還包含「為什麼」。當你把人工智慧編碼助理交給這些團隊時，它就變成了一種倍增器。輸出結果與系統完美契合。

當你把同樣的工具交給一個沒有共享框架的團隊時，你得到的就只是一個裝滿了 CI/CD 管道的雜物抽屜。

人工智慧究竟暴露了什麼

人工智慧並沒有摧毀你的企業文化，它只是揭露了那些從未建立企業文化的團隊。

大多數領導者都會告訴你他們有自己的企業文化。他們會拿出 Notion 文件、架構評審行事曆和兩週一次的迭代週期來證明。但這只是組織架構。組織架構和企業文化並非一回事。

真正的企業文化體現在你的工程師能否用自己的語言捍衛他們的決策，而不是引用工具的建議，也不是指出別人執行的基準測試結果。要建立論證，權衡利弊，並坦誠地說：“這是我考慮過的，這是我的選擇，這是我正在關注的，以判斷我的決定是否正確。”

如果你的工程師能夠做到這一點，人工智慧就能起到倍增器的作用。

如果他們做不到，那就表示問題出在模型出現之前。

那種把「ChatGPT這麼說的」當作決策依據的文化，與那種靠委員會決策、用審批鏈代替判斷、以及因為「為什麼」從來不被允許而不再追問的文化如出一轍。人工智慧只不過為這種文化取了個名字，並創造了一個值得引用的名言罷手了。

人工智慧並沒有創造出不會思考的團隊，而是創造了一個更快、更容易獲取資訊的平台，讓問題變得顯而易見。

教他們思考

架構決策記錄（ADR）是為那些在決策過程中不在場的工程師所寫的。它不是事後羅列要點來解釋選擇，而是記錄實際的推理過程。它詳細列出了我們考慮過的因素，排除的選項及其原因，以及我們正在關注的事項，以判斷我們是否做出了錯誤的決定。這份文件能夠隨著時間的推移不斷累積判斷力。以這種方式編寫的ADR，會成為團隊工程師實際決策的基準，遠在任何AI模型出現之前就已經形成。一份關於會話管理的ADR就讓我們避免了一次最終證明完全不必要的全面遷移。

程式碼標準應以推理而非規則的形式記錄。它闡明了選擇、代價以及何時應該提出質疑。同樣的標準既能讓工程師辨識出人工智慧提出的糟糕架建置議，也能讓他們辨識出同事提出的糟糕建議，甚至能在晚上11點截止日期臨近時，辨識出自己提出的糟糕建議。你不需要為人類決策和人工智慧決策分別建構兩套不同的框架，而應該建構一套。你要讓犯錯的成本低廉，讓掩蓋錯誤的成本高昂。

在批准「做什麼」之前，審查文化應該先探究「為什麼」。在計畫會議上，一位會問「我們為什麼要開發這個？」的中階工程師，比一位默默執行、快速交付的高級工程師更有價值。這個問題正是你在招募時所尋找的訊號。會問「為什麼」的工程師，是在建構判斷力，而不是進行模式匹配。當會議室裡的模式匹配者是一個對所有事情都充滿信心卻對任何事情都不負責任的人工智慧模型時，這正是你需要的。

給他們犯錯的空間。給他們值得深入思考的問題。給他們回饋機制，讓他們知道自己的判斷何時會出現偏差。這樣的工程師，18個月內就能領導團隊。