AI編碼最佳化只針對工程中最不痛苦的部分

在工程領域，大多數AI工具都在你編寫新程式碼時出現，但當你凌晨3點試圖挽救生產環境時，它們卻無影無蹤。這不是偶然的差距，它將成為你工程組織中最昂貴的代價。

凌晨3點14分，丹尼爾（化名）的手機異常地響起了未確認的警報。他是本週的值班高階工程師。結賬延遲飆升，錯誤率上升。他開啟筆記型電腦，開始了他最熟悉的過程：找出“什麼發生了變化”。這個問題看似簡單，但答案分散在六個互不相通的工具中。他檢查部署儀表板，最近幾小時有三個服務釋出了。他翻閱團隊Slack，兩百條訊息，尋找是否有人提到了支付路徑。他開啟公司內部搜尋，輸入“結賬重試超時”，返回了一堆文件——2023年的執行手冊、兩份設計文件和一個未完成的Confluence頁面。搜尋技術上成功了，但並沒有回答問題。他仍然逐一開啟，判斷是否最新，然後繼續。凌晨3點，他用手工拼接系統的圖景。

30分鐘過去了，他還沒修復任何東西。這不是他慢；這就是工作的本質。事件響應分析顯示，40%到60%的時間浪費在跨工具重建上下文上，工程師花費15到25分鐘收集分散的資訊才能開始調查。一個典型的中斷涉及5分鐘在Slack上，10分鐘檢查最近的提交，5分鐘檢視儀表板，然後——25分鐘後——才最終理解是某個特定部署導致了峰值。一旦知道該做什麼，技術修復往往微不足道。但達到知道該做什麼的節點，才是夜晚真正耗費的時間。

最終，丹尼爾透過時間序列形狀縮小了範圍——延遲呈鋸齒狀上升，像是重試堆積。他需要資料確認，這不僅是不同的工具，更是完全不同的工作模式：現在他需要針對指標後端編寫臨時查詢，調整時間視窗，構建即用即棄的指令碼來拉取所需數字，因為沒有人提前構建的儀表板並不存在。終端、瀏覽器、指標工具、再回到終端。每次工具切換都打斷流程，迫使他重新定位。

他找到了原因。有人在下午的部署中提高了重試上限。上限之所以存在是有原因的——總是有原因的——但原因存在於八個月前的一個程式碼審查評論和某位高階工程師的腦海中，而她此刻正在睡覺。丹尼爾做出決定，推送修復，看著圖表正常化，在頻道中釋出解除警報。

然後是他最討厭的部分：他必須把所有內容寫下來。事後總結——時間線、根本原因、他做的決定和後續行動——以便下一個遇到此問題的人不必重複他的整個夜晚。凌晨5點，他知道自己會寫出一份單薄、無趣的版本，因為他筋疲力盡，而三個月後，有人會遇到類似問題，不得不從頭開始自己的凌晨3點。他們怎麼能找到這份文件呢？

值得注意的是，在整個夜晚中，公司投資的任何AI工具都沒有提供任何幫助。能夠快速搭建服務的編碼代理？沉默。起草PRD和總結會議的同事代理？無處可尋。“AI正在改變軟體開發”的承諾在丹尼爾工作最艱難、風險最高、公司正在賠錢的九十分鐘裡完全缺席。這些代理只出現在編寫快樂路徑程式碼的愉悅部分，而在高階工程師大部分職業生涯所處的運營現實中缺席。

這從未是一個程式設計問題。讓我們重放丹尼爾的夜晚，每一步問：“實際上缺少什麼？”不是編碼能力。他幾乎可以在睡覺時編碼。每次缺少的是組織某處存在但不在他需要時、需要地點的知識。過去四小時發生了什麼？存在於部署日誌和PR中。重試上限設定為何以及為什麼？存在於審查執行緒中。是否有人之前見過這種形狀？存在於過去的事故中，但無法被檢索。當他重構了足夠的上下文，修復方案立刻顯現。

事故的每一步都是穿著事故外衣的知識問題。搜尋工具失敗不是因為它不好，而是因為找到一堆文件閱讀不等於回答問題。凌晨3點，合成稅以最昂貴的貨幣支付：一位資深工程師在壓力下、在倒計時中的注意力。

這是關於資深工程師的安靜真相，沒有組織架構圖顯示：最有經驗的人充當著公司的活知識層。團隊“問丹尼爾”的原因是丹尼爾頭腦中擁有系統實際上如何運作以及為什麼的對映、調和、最新、有來源的理解。這些是在會議中決定的、在審查中爭論的、在之前的事故中學到的，並且從未在任何機器或新人能夠訪問的地方寫下來。他就是知識庫。這在他睡覺、度假或離職時成了問題。

這不是一個小的或罕見的問題——只是普通工程日。多項研究一致發現，開發人員實際花費在編寫應用程式程式碼上的時間僅約16%，其餘時間用於運營和支援工作：監控、維護、協調和無休止的上下文搜尋。約64%的人報告每天花30分鐘以上只是搜尋東西，三分之一的人花超過一個小時。真正的瓶頸從來不是寫程式碼——而是知道。

AI在16%方面進步顯著，而其他84%幾乎沒有變化。這就是為什麼任何押注於“AI將提高工程速度”的人都會感到複雜。編碼工具進步很快，但在受控試驗中，在熟悉程式碼庫上工作的經驗豐富的開發人員在使用AI工具時實際上更慢——而且更顯著的是，他們相信自己更快。你應該誠實地看待這一發現，並注意感知差距：工程師會感覺自己更快，無論實際是否如此，這意味著感覺不是可以用來管理工程組織的指標。

從編碼退一步，更大的模式顯現出來。企業分析發現，代理輔助工作失敗的原因始終是相同的：不是原始模型能力，而是缺少上下文和規劃——代理不知道約束、組織如何運作、或沒有明確寫下來的東西。能力曲線垂直增長，但團隊特定的運營知識曲線根本沒有移動。重試理由、必須同時部署的元件、運營陷阱——它們仍然只存在於丹尼爾的頭腦中。困在人的頭腦中和分散在工具中。

因此，收益在知識存在於某人頭腦中的特定地方停滯不前。這正是丹尼爾凌晨3點14分所處的位置。

隨著你採用更多代理，情況會變得更糟。每個代理都是一名沒有記憶的新員工。它從未參加過你的架構評審，不知道支付和庫存必須一起部署，或者去年春天的“臨時”限流器現在已成為承載結構。因此，每個代理每次都會重新提出新工程師問的同樣問題——而答案仍然存在於你的資深工程師頭腦中。你沒有減少丹尼爾的上下文負擔，而是增加了詢問他上下文的事物數量，並全部指向同一個未文件化的瓶頸。

與此同時，基礎衰減仍在繼續。隨著每次離職和重組，部落知識逐漸消失。新工程師——人類和代理——緩慢地上手，因為入職正是一對一轉移這些未書面知識的過程，而這種轉移不會透過招聘更多人或啟動更多代理來擴充套件。隨著運營負擔五年內首次增加30%，負擔在增加，而處理負擔的知識卻變得更薄、更分散。

工程組織越自主化，未書面、未調和、困在人腦中的知識就越成為一切的瓶頸。你可以購買更多能力，但無法買回團隊從未寫下的上下文。

優秀團隊正在採取的措施：將工作知識視為真正的基礎設施層，而非偶然積累在人們頭腦中的副產品。一些做法：捕獲原因而不僅僅是內容；將約束放在工作發生的地方；將上下文作為第一類工件；將事故反饋迴圈到知識中。

丹尼爾凌晨5點討厭寫的事後總結就是為了提供這個層。悲劇在於，它是由疲憊的人手動完成的，而所需的大部分資訊——時間線、部署、決定、執行緒——已經存在於見證它發生的系統中。

最後一點是關鍵。值班是知識問題的原因也正是它可以解決的原因——下一個響應者所需的一切已經產生並記錄在某處。只需要在關鍵時刻調和成一個當前答案。

想象一下丹尼爾的夜晚有一件事情改變了。警報響起。在丹尼爾開啟筆記型電腦之前，一個代理查詢：“過去4小時結賬發生了什麼變化？”和“結賬的硬約束是什麼？”在他開啟六個工具之前，調和後的答案已經在等待他：三個部署，它們的作者，以及那張真正重要的程式碼審查評論。他不再需要合成；他可以直接行動。團隊已經將知識構建到了響應中，而沒有將其留給凌晨3點的手工拼接。