Kelsey Hightower 談 AI：為什麼預測？明明可以確定

本文整理自 JetBrains 2024 年 12 月發布的訪談。

「為什麼要預測？明明可以確定。」

這是 Kelsey Hightower 在談到 AI 時拋出的問題。這句話看起來像是在唱衰 AI，但實際上是一個老練工程師對技術本質的深刻反思。Hightower 在 Google Cloud 擔任開發者大使超過八年，是 Kubernetes 社群最具影響力的布道者，也是 KubeCon 的共同創辦人。當整個科技圈都在為 AI 瘋狂時，他選擇退一步，問一個根本性的問題：我們真的知道自己在做什麼嗎？

整個職涯都在讓系統可預測，現在卻擁抱不確定？

Hightower 的觀點來自一個簡單的觀察：軟體工程師這個職業，本質上就是在把不確定的東西變成可預測的東西。當系統表現得不可預測時，我們叫它 bug。當系統做了預期之外的事，我們叫它安全漏洞。我們寫單元測試、整合測試、端對端測試，就是為了確保系統「只按照預期運作，而且只能按照預期運作」。

然後 AI 來了。

這些大型語言模型的核心特性，恰恰是不可預測性。你給它同樣的 prompt，可能會得到不同的結果。這不是 bug，這是 feature。Hightower 觀察到一個有趣的現象：業界開始用一些新詞彙來描述那些本來就存在的概念——「guardrails」（護欄）、「alignment」（對齊）、「tuning」（調校）。但如果你仔細想想，這些詞彙本質上都在說同一件事：我們要怎麼讓這個不可預測的系統變得可預測？

「我們最終還是會回到同一個目標，」他說，「建立一個可靠的系統，按照預期運作，而且只能按照預期運作。」

但 AI 不是沒有價值——意圖導向 API 是真正的潛力

Hightower 不是在反對 AI。他看到的是一個真正的機會：意圖導向的 API。

想像一下現在的基礎設施工具鏈：你有 HCL、Kubernetes API、Helm charts、SQL 語句、各種 TOML、JSON、XML 配置檔。如果你是 Java 開發者，還有那長達一英里的 pom.xml。這些系統之間沒有一致性，要讓它們協同運作需要大量的膠合程式碼，而且這些膠合程式碼極其脆弱。

LLM 提供了一個新的可能性：用自然語言表達意圖。你說「把這個應用部署到這個區域，並開放流量」，然後由某個中間層去處理所有底層的複雜性。這是 Hightower 認為 AI 真正有價值的地方——不是取代工程師，而是提供一個更高層次的抽象介面。

但他也很清醒地指出：底層的東西一樣都沒變。你還是要呼叫雲端供應商的 API，你的應用還是跑在同樣的 kernel 上，還是要分配記憶體、寫 log。「除非這些都改變了，」他說，「否則我們真正談論的，只是一個新的 API 來做我們過去三十年一直在做的事。」

Prompt Engineering：你們可能創造了另一種程式語言

這是訪談中最精彩的部分之一。

Hightower 說，當他問那些熱衷於 AI 開發的人「給我看看你們的 prompts」時，他看到的是：500 個 markdown 檔案，一堆精心設計的 prompts。「你們怎麼管理這些 markdown 檔案？」他問。「我們 check in 到版本控制。」對方回答。「你們會做版本控制嗎？」「當然，我們有版本控制。」「那測試呢？」「我們也開始寫測試了。」

Hightower 停頓了一下，然後說：「我覺得你們可能創造了另一種程式語言。」

對方愣住了。

這個觀察非常精準。我們還是在嘗試用某種方式把人類的意圖傳達給機器。只是這次的格式從程式碼變成了 markdown 和自然語言。但本質沒變：你需要版本控制、你需要測試、你需要確保一致性和可重現性。那些讓傳統程式語言變得「boring」（無聊但可靠）的紀律，在 prompt engineering 中一樣需要。

「我們還是在試圖以一種可以從人類傳遞給機器的方式來捕捉意圖，」他總結，「至於這是不是我們想要的新方言，時間會證明。」

意外收穫：MCP 和文件化浪潮

Hightower 提出了一個很少有人注意到的觀點：AI 熱潮帶來的最大副產品，可能是我們終於開始認真寫文件了。

他說，多年來他試圖讓開發者描述他們建立的系統，簡直像在拔牙。但現在，為了讓機器理解系統、為了讓 AI agent 能夠操作各種工具，人們不得不寫出詳細的文件和 API 規格。MCP（Model Context Protocol）的出現更是激勵了一波 API 化的浪潮——那些傳統的 SaaS 供應商，以前只給你一個黑盒子和一個網頁介面，現在終於開始提供真正的 API 了。

「如果你有一個結構良好的 API 來操作 Google Calendar、Google Docs、Salesforce，」他說，「你可能只需要 bash 和 curl 就能建構任何你想要的 pipeline。但因為我們沒有這些 API，這些系統對我們來說就是黑盒子，我們只能在那邊做 screen scraping。」

這是一個諷刺的觀察：我們為人工智慧做的這些工作——寫文件、建立 API、提供結構化的操作介面——其實早就應該為真正的智慧（也就是人類）做好了。如果 AI 熱潮最後什麼都沒留下，至少我們會有一堆以前從來沒有的 API 和文件。那也不算白費了。

回歸工程師的基本功

Hightower 對 AI 的態度可以這樣總結：他不是悲觀派，也不是樂觀派，他是務實派。

他看到了 AI 作為意圖導向 API 的潛力，也看到了它可能帶來的文件化和 API 標準化浪潮。但他同時也提醒：不要忘記工程師的基本功。我們的工作從來都是把不確定性變成確定性，把複雜性封裝成簡單的介面，把專業知識轉化成可重複使用的工具。

無論用什麼技術，這些原則不會改變。Kubernetes 是這樣，AI 也是這樣。

「那些理解基礎和根本的人，」他說，「可能會從中獲得一些創意靈感，讓我們改善現有的工具，讓它們更有一致性，有更多意圖導向的 API，而不是那些需要一再重複組裝的模組化 API。」

這大概是對 AI 最務實的期待：不是取代工程師，而是讓我們終於有動力把該做的事做好。