本文（演講）基於我思考了一段時間的一個想法：當每個人都在談論人工智慧時，要不是從炒作的角度，就是從世界末日的角度……那麼中間立場在哪裡呢？

誰真正關注人工智慧的實際應用、組織中存在的差距，以及最重要的，新智慧時代的人文層面？

因此，考慮到這是一篇演講稿，請欣賞我尚未完全成型的想法（還需要一些修改），因為我認為演講的關鍵點：理解程式碼是我們應該關注的新指標，這一點非常重要。

演講稿（草稿）：

句法膨脹

“在人工智慧時代，你所在機構中最危險的工程師不再是反應最慢的，而是反應最快的。”

• 能夠以驚人速度交付功能的工程師。

• 速度最快的隊伍。

• 每次迭代都顯示綠色的儀錶板。

這些聽起來可能很神奇，但實際上並非如此。

在一個程式碼廉價且無限的世界裡，速度不再能告訴你是否獲勝，它只能告訴你，你累積了一些你可能無法理解、修復或控制的東西的速度有多快。

但我稍後會談到這一點。

首先，讓我們來看看軟體工程過去是什麼樣子，以及它發生了哪些根本性的變化。

五十多年來，在座的各位都受僱掌握一種秘密語言。我們受僱熟悉字典。我們受僱說「機器話」。

如果一位企業領導者想要實現某個功能：例如新的結帳流程、搜尋欄或資料管道，他們就遇到了問題。他們有想法，但卻缺乏相應的語法。他們需要我們把他們的人類意圖翻譯成 Java、SQL 或 React 程式碼。我們知道如何向機器傳達其他人無法傳達的訊息。

正因為這項技能稀缺，我們才對翻譯收取費用。這項費用支撐了我們的薪水、工作進度、敏捷開發流程，以及我們整個職業生涯。

但一些根本性的改變已經發生。如今，機器有了自己的語言。詞典是公開的。翻譯成本正迅速接近零。

我想澄清一點：這並不代表軟體工程已經終結。但這確實意味著我們歷史價值中最顯而易見的部分，也就是人們能夠看到和欣賞的部分——將英語需求轉化為語法這一實際行為——已經被商品化了。

如今我們必須回答的一個顯而易見的問題是：如果程式設計不再稀缺，那麼軟體工程的價值現在體現在哪裡？

危機：通貨膨脹與效率陷阱

我聽到很多人擔心「更新換代」的問題。但我們面臨的並非更新換代危機，而是通膨危機。

想想基本的經濟學原理。印鈔過多，貨幣價值就會下降。同樣，列印程式碼（我們現在幾乎可以無限量地列印程式碼）也會導致一行程式碼的價值下降。

我們正從匱乏時代邁向富足時代。而這導致了我認為企業目前犯的最大錯誤。

我稱之為「效率陷阱」。

主管們看到如此豐富的資源，心想：「太好了！如果人工智慧能讓開發人員的工作效率提高 50%，我就可以解僱 50% 的開發人員，還能獲得同樣的產出。」（如果你對這句話有疑問：這句話是 ChatGPT 寫的。它自信、生產力簡潔，但完全錯誤。意味著你要解僱三分之一的團隊，而不是一半。

但撇開對人工智慧的過度自信不談：這種想法從根本上就是錯誤的。高階主管只看到短期收益，卻對長期的複雜性視而不見。

富足之中往往隱藏著風險。

每增加一行程式碼、每增加一個微服務、每進行一次集成，複雜性都會悄悄累積，速度之快令人難以察覺。系統表面看起來或許運作良好，儀表板也顯示一切正常。但實際上，脆弱性正在悄悄滋生。

這就是直覺欺騙我們的地方。我們看到產量激增，就覺得需要更嚴格地衡量它，更密切地追蹤它，更積極地優化它。

在人工智慧時代，速度不再是領先指標，而是落後指標。

但過度崇拜速度指標最終會導致你的失敗。

直接追求速度優化會增加複雜性。而追求理解優化，真正了解你所建立的事物及其運作方式，系統就會自然流暢執行，速度自然而然地隨之而來。

只專注於產出的團隊最終會停滯不前，不是因為他們速度慢，而是因為他們害怕改變自己已經建立的東西。

如果你覺得維護現有的遺留程式碼很困難，那就等著瞧吧，當你必須維護你的團隊即將產生的海量程式碼時，你會更加頭痛。

關鍵點：平均理解時間

在任何系統中，價值總是會轉移到約束條件。如果編寫程式碼成本低廉、資源豐富且速度快……那麼新的瓶頸是什麼？

現在的限制不再是編寫軟體，而是理解已經編寫的軟體。

限制條件是了解產生的這段程式碼實際執行了什麼操作，它在什麼情況下運作正常，更重要的是，它在什麼情況下執行異常。

我們應該停止過度關注速度，而應該開始關注 MTTU：平均理解時間。

DevOps 和 SRE 團隊長期以來一直使用這個術語來衡量警報和診斷之間的差距；現在是我們其他人調整並將其應用於程式碼本身的時候了。

對開發者而言，MTTU 指的是非原作者的人類能夠自信地回答以下兩個問題所需的時間：

• 這段程式碼實際執行的是什麼操作？

• 如果它壞了，我該從哪裡入手修理？

關鍵在於：如果你優化了平均學習時間（MTTU）…如果你設計的系統和團隊能夠最大程度地提升理解力…其他一切都會隨之而來。速度、可靠性、可維護性，所有這些都會自然而然地提升。

如果忽略理解而只追求產出，系統最終會停滯不前。這並非因為你反應遲鈍，而是因為複雜性的成長速度已經遠遠超過了任何人的理解能力。

從現在開始，你所做的每一個架構決策要嘛會壓縮 MTTU，要嘛會膨脹 MTTU。

快速理解並驗證非自己編寫的程式碼的能力，是新時代的核心技能。這也是老年人在這個新時代擁有的可遷移技能。

你多年來累積的模式辨識能力、思考模型和來之不易的判斷力，實際上會帶來回報。

人工智慧可以產生無限的解決方案，但只有你能查看這些解決方案，並理解它們對你的系統究竟意味著什麼。

但考慮到這一點，讓我們來看看為什麼這個指標和原則如此重要。

診斷：具備合理能力

第一個問題與直覺相悖。問題不在於人工智慧不擅長編程，而是它非常擅長編程。人工智慧的程式設計能力足以勝任各種任務。

人工智慧不是初級開發人員。人工智慧是無限的應聲蟲。它傾向於創造。

它總是會帶給你一些東西。

如果你讓AI解決一個問題，而正確的工程解決方案是“不要寫程式碼，只需修改這個設定檔”，AI很少會告訴你這個答案。它會編寫一個500行的腳本來繞過設定檔。

它建造的是你要求的，而不是你想要的。

它產生的程式碼看起來正確。它使用了正確的庫。它遵循正確的縮排格式。它甚至可能通過單元測試（當然，是它自己編寫的）。

如果你讀過丹尼爾·卡尼曼的《思考，快與慢》，那麼你就會了解系統 1（快速、直覺）和系統 2（緩慢、深思熟慮）的思考方式，並且你會熟悉這種看似合理的思維模式存在的問題。

人工智慧產生的程式碼已經夠好，能夠啟動我們的系統1思維。我們瞥一眼，它看起來像是有效的程式碼，邏輯乍看之下合理，於是我們點點頭。 “看起來不錯。”

但這就是陷阱。我們輕信了它的合理性，於是停止了思考。

我們不再在腦海中模擬程式碼。我們接受解決方案，卻不去仔細驗證它是否符合我們特定係統的細微差別。我們從未進行過緩慢而深思熟慮的思考。

正因為我們太容易信任它，才讓它去做我們絕對不會允許人類去做的事情。這就引出了第二個陷阱。

陷阱：複雜性蔓延

這種行為在現實世界中的表現如下：

想像一下，一個團隊提出一個簡單的功能需求。比如說，一個用於提交使用者名稱和電子郵件地址的網頁表單。

在過去，開發人員會抱怨，編寫一個單獨的文件，最好再加一點驗證邏輯，然後就發布了。

但現在呢？開發者要求人工智慧「穩健地處理提交內容」。

AI搭建了腳手架。它產生了一個獨立的微服務用於驗證。它加入了一個重試隊列來處理提交失敗的情況（因為隊列具有“魯棒性”）。它啟動了一個無伺服器函數來清理輸入。為了完整性，它還加入了一個分散式日誌服務。

技術上來說？一切正常。語法上？完美無瑕。但陷阱就在這裡。

人工智慧是一種局部優化器。

它會查看“使表單穩健”這條工單，並以最大力度解決這個特定問題。它不會關心你係統的其他部分。

這就是你的工作。你是全域最佳化者。你是架構師。

你的工作是了解該表單如何融入使用者會話、計費系統和舊資料庫。

但由於人工智慧剛剛產生了五個新服務和三個隊列，導致複雜度激增。為了判斷這個解決方案是否正確，你現在必須把所有這些新增的複雜度都考慮進去。你必須繪製出五個服務的故障模式圖，而不僅僅是一個文件的故障模式圖。

這就是認知膨脹。而危險就潛藏於此。

當解決方案太複雜，無法容納在你的工作記憶中時，你就停止驗證架構。你不再問“這合適嗎？”，而是開始接受“它能用”。

你放棄了建築師的角色，因為藍圖變得太混亂，無法辨認。

約束：架構驗證

這就引出了一個硬性限制。這個限制並非我們編寫程式碼的速度，而是序列化頻寬。

身為架構師，為了確保解決方案安全、合規且正確，你必須能夠將邏輯序列化並輸入腦中。你必須能夠在腦海中「執行」系統。如果我在這裡更改 X，會不會導致那裡的 Y 出現問題？

我們現在擁有無限的生成頻寬（人工智慧），卻要將資訊輸入到固定的序列化頻寬（你的大腦）中。

序列化頻寬是指大腦將系統資訊儲存在記憶中的能力。無論人工智慧的運算速度有多快，如果你的大腦無法理解其邏輯，那麼這個系統就是不安全的。

現在，在場的AI崇拜者和樂觀主義者（以及向你推銷AI工具的供應商）會說：“沒問題！我們只要給AI提供上下文訊息，輸入文件，更好地引導它就行了。”

這是我們這個行業目前最危險的謊言。你不能在不知道相關資訊的情況下，強迫對方提供背景資訊。

軟體中的上下文並非可以簡單地上傳到向量圖庫的靜態資料庫。上下文是動態的。

只有當程式碼嘗試修改「使用者」物件的具體方式出現時，你才會知道它隱藏地依賴另一個專案中的「計費」物件。同樣，只有當佇列被建構出來時，你才會知道這種特定的重試邏輯違反了新的合規性規則。

上下文是程式碼與世界之間的碰撞。

人工智慧只能看到程式碼，只有你才能看到它背後的真實世界背景。

如果你無法比程式碼寫得更快地理解它（而你確實做不到），你就失去了發現衝突的能力，也就失去了管理系統的能力。

瓶頸不在於打字速度，而在於架構驗證速度。

好速度與壞速度

然而，看看我們的 Jira 看板。我們仍然使用 Velocity 來衡量進度。每個迭代週期的功能數、已關閉的工單數、已發布的產品線數。這種不匹配正是我們製造認知債務的原因。

在新時代， 「良好的開發速度」是指在維持平均理解時間（MTTU）穩定的前提下發布功能。 「糟糕的開發速度」是指透過大幅提高MTTU來發布功能。

如果你使用 AI 在 4 小時內發布了一個功能，但下週該功能出現故障時，高級工程師需要 3 天才能了解如何修復它，那麼你的 MTTU 就遠遠高於你的程式碼速度。

如果你的平均學習時間過長，那麼你就背負了認知債務。

而且這種債務不僅存在於程式碼中，它還會洩漏出去。

它顯示為：

• 持續時間較長的事件（因為沒有人知道根本原因在哪裡）。

• 入職流程較慢（因為新進員工看不懂地圖）。

• 功能癱瘓（因為每個人都害怕觸摸“神奇程式碼”）。

為了進一步說明這一點，請容許我問你一個問題：

• 過去一個月裡，你們當中有多少人合併過自己並不完全理解的 PR？

• 如果你告訴自己以後會回來仔細檢查，請舉手。

• 如果你真的這麼做了，請舉手。

是啊，我也沒做！

這就是為什麼我們需要新的協議。

協定：規範驅動開發

別擔心，我說的不是瀑布流的具體細節……免得你分心了！

到目前為止，我已經告訴你們哪裡出了問題以及原因。但我不想讓你們離開這裡時只是感到焦慮。我希望你們明天就能拿到一套可以使用的方案。所以，讓我具體說明一下。

我們必須修改協議。

我們需要轉向對人工智慧和多任務用戶友好的規範驅動開發。

在這個新世界裡，我們不再從閱讀程式碼開始，而是從建構結構開始。

這個過程分三個不同的層面進行：

第一層：微觀層面（人類啟動與地圖）

這是你的生存工具。這是你每天保持理智的法寶。它完全是為你準備的。

這就是「認知句柄」。在編寫任何一行程式碼之前，你需要在腦海中（或便條紙上）定義一個高層次的意圖。

• 目標： “新增使用者存檔功能。”

• 限制條件： “必須是可逆的。”

• 架構契合度： “這應該放在用戶服務還是管理服務中？”

Micro-Spec 是你的「胡說八道和不合適探測器」。

它允許您查看人工智慧的輸出並立即回答：這段程式碼是否符合我們系統的結構？這段程式碼是否具備我們要求的功能？

如果 AI 為了簡單的 UI 變更而嘗試重寫資料庫架構，Micro-Spec 會告訴你立即拒絕它。

第二層：主規範（共享合約）

這就是讓大家保持一致的原因。

一旦了解了程式碼的結構，接下來就需要了解其實質內容。

這是主規範。你和人工智慧都依賴這份文件。

• 對人工智慧而言：它就像是一份使用手冊。其中包含驗收標準、具體邊界情況以及輸入/輸出定義。

• 供您參考：這是技術驗證清單。

在人工智慧產生程式碼後（並且你修復了明顯的錯誤），你將從「架構師」切換到「審計員」。你將程式碼與主要規範進行比較。

“它是否處理了我們要求的空值情況？”，“它是否實現了我們定義的特定重試邏輯？”。請在此處驗證技術要求。

如果說微規範檢查的是程式碼的靈魂，那麼主規範檢查的是程式碼的軀體。

第三層：全局背景（潛意識）

這就是你的進化系統，它能讓你隨著時間的推移變得更快。最後，我們還有力量倍增器。

在建置過程中，我們會注意到我們不斷重複某些指令：“使用 Tailwind。”“不要使用 'any' 類型。”“遵循倉庫模式。”

我們不會把這些內容放在每個規範中，而是將它們放到全域上下文中。

這時就需要用到 CLAUDE.md 檔案或 .cursorrules 檔案之類的工具了。

我們將這些文件視為我們的進化規則集。

每當人工智慧出現風格錯誤時，我們不會只是修改程式碼，而是會更新全域上下文，並新增一條規則。

隨著時間的推移，這會自動將人工智慧與你的工程文化拉近。

隨著全域上下文的不斷完善，機器會逐漸熟悉你的程式碼模式。你將大大減少檢查語法、匯入語句和資料夾結構的時間。

那麼節省下來的時間都用在哪裡了呢？它用在了永遠無法放入上下文文件中的東西：現實世界的模糊性。

無論人工智慧對我們的程式碼庫多麼熟悉，它都不了解我們的策略。它不知道市場團隊剛剛更改了發布日期。它也不知道使用者討厭那個特定的模態框。

你不再是程式碼審查員，而是現實審查員。

微規範是程式碼的靈魂，是程式碼的精髓。

主規範是程式碼的主體，是程式碼的實質。

全球背景是潛意識，是程式碼的指導原則。

但即便如此，你或許會想，一旦提示和上下文都確定下來，你的價值體現在哪裡？人類能做到哪些人工智慧在未來20年幾乎不可能做到的事？

3條人類護城河

一旦你接受了角色向統籌和評估的轉變，「提示」論點就徹底失效了。人工智慧無法取代你，因為人工智慧無法跨越這三道護城河：

護城河 1：影子建築（背景）

人工智慧根據可見的程式碼提出了一種解決方案。你基於不可見的現實拒絕了它。

例如：承重錯字。

AI掃描了你的API，發現錯誤訊息：「Err (500)」。它建議進行「最佳實踐」改進：「讓我們用更通用的術語來表達：內部伺服器錯誤 (500)」。

它具有更好的數位體驗 (DX) 特性，更具描述性，並且更符合行業術語。

但您了解具體情況。您知道維運團隊有一個遺留的監控腳本，專門用於在日誌中尋找字串「Err (500)」。如果找到該字串，它會自動重新啟動伺服器。

如果讓AI「修復」該訊息，grep指令就會失敗。自動重啟也會失敗。下次伺服器崩潰時，它將整個週末都無法執行（或直到你接到修復電話……AI現在肯定不會接到電話，對吧？）。

AI 看到的是文本，而你看到的是現實世界的依賴關係。你無法在 AI 不知道其存在的伺服器上提示執行 bash 腳本，直到它變得相關為止。

護城河 2：問題定義（價值）

人工智慧會準確回答提示，而你需要回答其隱含的需求。

企業要求「快速搜尋」。

• 人工智慧會啟動 Elasticsearch 來進行即時回應，費用高達數千美元。

• 你知道“快”只是意味著“不到一秒”，而簡單的 SQL 查詢就能免費完成。

人工智慧並非減少了工程工作，而是提高了工程難度。

護城河 3：系統悲觀主義者（副作用）

人工智慧擅長局部修復。如果你向它指出錯誤，它會消除錯誤，編寫防禦性程式碼，捕捉異常。但它對系統性副作用卻視而不見。

它透過加入重試循環來解決資料庫逾時問題。

它不知道，上層三層前端也在重試，負載平衡器也在重試。它雖然修復了本地錯誤，但卻引發了一場重試風暴，會在下次流量高峰期導致整個平台崩潰。

人工智慧會查看文件。你查看爆炸半徑。你的任務是問：“如果這段程式碼執行完美，它還會破壞哪些其他功能？”

但這種高階工程技術不是你在訓練營裡能學到的，那麼初級工程師在新世界中扮演著什麼樣的角色呢？

小小探險家

如果你一直關注著我們，而且你正處於職業生涯的早期階段，並且感到擔憂……很好。這說明你很用心。但你需要明白的是：人工智慧不會讓你過時。

這會讓你變得危險。 **老年人受制於他們的思考模式。他們知道什麼「應該」有效，所以他們會要求人工智慧建構顯而易見的東西。 **

你還沒有這些先驗知識。

你可以讓AI在一個下午的時間裡嘗試五種不同的架構，而無需背負任何認知包袱。由於需要摒棄的知識更少，你的探索速度也更快。

這就引出了一個高階主管和招募經理可能仍在思考的問題：**為什麼還要招募初級開發人員？如果人工智慧能夠像中級開發人員一樣工作，為什麼還要花錢請人學習？ **

因為人工智慧是引擎，而不是駕駛。

如今初級程式設計師的價值不在於“程式碼編寫”，而在於方案的產生和驗證。

過去，如果我們不確定如何實現某個功能，我們會派一位資深員工到現場做原型，花三天時間。這成本很高。

現在，我們派一名初級工程師。我們說：“這是規格說明。用人工智慧設計三種不同的解決方案原型。分析每種方案的優缺點。測試各種極端情況。把最好的方案帶給我。”

初級員工能立即帶來投資回報，因為他們可以作為高階員工的力量倍增器。

他們撥開人工智慧的幻覺，核實資料庫，過濾掉噪音。他們呈現給高級用戶的不是空白文字文件，而是精心挑選的選項。

（比喻）：小人工智慧探索人工智慧叢林，繪製機器可能採取的路徑，為大人工智慧帶回安全路線。

他們如今的價值在於他們承擔了前期研究工作，讓資深員工能夠做出至關重要的甄選決策。而且，在完成這些工作的過程中，他們也學會了成為資深員工所需的判斷力。

長者：策劃者

而房間裡的各位前輩呢？你們才是真正的統籌者。你們制定規則，決定哪些地方允許複雜化，哪些地方禁止複雜化。

你需要審核程式碼與其他程式碼庫部分互動處的接縫。

你要確保人工智慧在創作單個音符時，旋律保持連貫性。

（比喻）：人工智慧生成的每一條旋律線都像樂器；只有資深人士才能確保它演奏出正確的旋律。只有你才能看到整部交響樂。

結論：大過濾器

最後，我想談談大家心知肚明卻又避而不談的問題。

• 我們已經證實，人工智慧可以提供無限的生成頻寬。

• 我們已經確定人類對理解頻寬的認知是固定的。

解決這個問題只有一個辦法，就是不要加快閱讀速度。

僅僅「多招人」是不夠的。生存的唯一方法是成為「大過濾器」。

在如今程式碼編寫免費的時代，接受這種做法反而是最昂貴的。

最有價值的工程活動不再是創造軟體，而是拒絕軟體。

如果你無法拒絕編寫程式碼，那麼在這個全新的智慧時代，你已經不再是工程師，而只是一條拿著薪水的部署管線。

你的價值在於審視人工智慧提供的“可行”解決方案，然後說：“不行。這會大幅增加我們的平均理解時間。刪除它。簡化它。重新做一遍。”

我們需要減慢進食速度，以配合消化速度。

我們應該這樣說：“僅僅因為我們可以在 30 秒內為此生成一個微服務，並不意味著我們應該這樣做。”

你的工作是站在閘門前，控制水流，安全地引導水流，小心謹慎地進行運輸。

在程式碼如河流般奔湧的世界裡，你的責任很明確：遏止程式碼的洪流。不要讓複雜性和認知負擔吞噬並壓垮你的系統。

不要只是開發軟體，要成為軟體仍然易於理解的唯一原因。

你是偉大的濾鏡：人工智慧或許能夠無限生成，但只有你能決定哪些能存活下來。

如今，你的職業生涯不再取決於你發布了多少產品，而是取決於你拒絕發布多少複雜的產品。

成為限制因素。

保護團隊的平均理解時間。

謝謝。

正如我所說，演講稿還需要一些修改和潤色，但我希望它的主題和概念能引人深思，也希望傳達的訊息清晰明了。

我們的角色正在演變，但這並不意味著你的所有技能都會過時。只是你可能需要減少一些刷題的時間，把更多的時間花在架構設計以及提高程式碼審查能力和工作效率。

在提交程式碼（或 AI 產生的程式碼）時，你應該優化平均理解時間 (MTTO)。

請告訴我你是否覺得這會是一個有趣的話題，還是你會躲在後面玩手機？

原文出處：https://dev.to/grahamthedev/mean-time-to-understanding-the-irreducible-human-element-in-the-age-of-infinite-code--i2o