為人工智慧做準備 – O'Reilly - AI TAIWAN 台灣人工智慧中心

提交提案參加我們的新虛擬會議《與AI編程：我們所知的軟體開發的終結》。提案必須在3月5日之前提交；會議將於2025年4月24日，東部時間上午11點至下午3點舉行。

當像GitHub Copilot這樣的工具首次出現時，大家普遍認為AI會讓編程變得更簡單。這對於剛開始學習幾種新編程語言的新程序員來說，無疑是一個好消息。這其中有些確實是對的：大型語言模型可以回答問題、製作教程、將描述性的註釋轉換為代碼，甚至成功編寫短程序。而且大型語言模型在理解大型代碼庫和寫出更少錯誤的代碼方面也在不斷進步。表面上看，對於初級程序員來說，事情似乎變得更簡單了。

但我和越來越多的人認為，AI擴大了初級和高級開發者之間的差距。隨著我們逐漸適應AI，我們發現編程不再只是寫出聰明的提示，而是更多地關於管理上下文。關於ChatGPT的記憶功能，Simon Willison說：“有效地使用大型語言模型完全是關於控制它們的上下文——仔細考慮當前模型正在處理的具體信息。”雖然這樣的說法有些擬人化，但與語言模型的對話就是這樣：一場對話，雙方之前的陳述都是上下文的一部分。上下文還包括你正在處理的代碼以及AI可以訪問的任何其他文件或指示（包括草圖和圖表）。除了在聊天會話中明確的上下文外，還有很多隱含的上下文：假設、經驗和其他人類在項目中共享的知識。這些隱含的上下文是軟體開發的重要部分，也必須提供給AI。管理上下文是任何使用AI的開發者需要掌握的重要技能，但這是新的技能，初級開發者必須在基本編程之外學會。

Steve Yegge更具體地談到編程時，明確表示聊天導向編程（CHOP）不是未來，而是現在。“你需要打字快、閱讀快、熟練使用工具，並且有能力（咳咳）手動處理大量文本和上下文。”現在，我們需要更好的工具來做到這一點——而且最終我們會擁有這些工具。但它們現在還不存在。不過，無論你是初級還是高級開發者，這都是你需要學習的編程方式，如果你想保持競爭力。而上下文是關鍵。討論GPT-4o和o1之間的區別時，Ben Hylak寫道，與4o不同，“o1只會把懶惰的問題當作表面問題，並不會試圖從你那裡提取上下文。相反，你需要盡可能多地將上下文推送到o1中。”他的觀點是，今天最先進的模型並不真正需要提示；它們需要產品簡介，越詳細越好。AI可以在許多方面幫助軟體開發者，但軟體開發者仍然需要思考他們需要解決的問題，並確定如何解決這些問題。與AI編程需要教會AI你希望它做什麼。而描述如何解決一個問題是一項比能夠大量產出Python或JavaScript更基本的技能。

為了準備迎接AI，我們都需要意識到我們仍然掌控一切；我們仍然需要理解和解決我們面臨的問題。當然，還涉及其他技能。AI寫出有錯誤的代碼？人類也會——而且AI似乎在寫出正確代碼方面變得越來越好。Bruce Schneier和Nathan Sanders認為，AI的錯誤與人類的錯誤不同，至少因為它們是隨機的，而不是圍繞著誤解的概念。但無論來源或原因如何，錯誤都需要修復，而調試是一項需要多年學習的技能。調試你沒有寫的代碼比調試你自己的代碼更困難。AI生成的錯誤可能並不比人類錯誤根本上更大，但目前人類仍然需要找到它們。（而且管理者需要認識到，雖然修復錯誤的工作是必要的，但這樣的工作可能會讓人感到沮喪。）AI寫出不安全的代碼？同樣，人類也會。漏洞只是另一種錯誤：AI會隨著時間的推移變得更擅長寫出安全的代碼，但我們仍然負責發現和修復漏洞。

所以，是的，行業正在改變——也許比歷史上任何時候都要快。這不再只是孤獨的程序員在鍵盤上敲擊（如果曾經是的話）。這是軟體開發者在產品開發的每個階段與AI合作，並彼此合作。人們常說軟體開發是一項團隊運動。現在團隊中有了另一位成員，而這位成員可能不會遵循相同的規則。

我們該如何為即將到來的變化做好準備？首先，不要忽視AI。Steve Yegge報導說，他見過一些公司，資深開發者不願意接觸AI（“過度炒作的新玩意”），而初級開發者則對此感到興奮。他也見過一些公司，初級開發者擔心AI會“搶走他們的工作”，而資深開發者則迅速採用它。我們需要明確：如果你忽視AI，你就是在自我放棄。如果你擔心AI會搶走你的工作，學會好好使用它比拒絕它要好得多。AI不會搶走我們的工作，但它會改變我們的工作方式。

其次，對AI能做什麼要有現實的認識。好好使用AI會讓你更有效，但這不是捷徑。它確實會產生錯誤，包括“這無法編譯”的錯誤和“結果看起來正確，但輸出中有微妙的錯誤”的錯誤。AI在修復“無法編譯”的錯誤方面已經變得相當不錯，但在微妙的錯誤方面則不太擅長。檢測和調試微妙的錯誤是困難的；重要的是要記住Kernighan的法則：軟體的調試難度是編寫的兩倍。所以如果你寫的代碼再聰明，你也不夠聰明去調試它。當你需要調試AI生成的代碼時，這是如何適用的，這些代碼是由一個看過GitHub、Stack Overflow等所有內容的系統生成的？你是否足夠理解它以進行調試？如果你負責交付專業質量的代碼，僅僅依賴AI作為捷徑是無法成功的。AI並不意味著你不需要了解你的工具——包括你編程語言中的黑暗角落。你仍然負責交付可運行的軟體。

第三，訓練自己有效使用AI。O’Reilly的作者Andrew Stellman建議幾個學習有效使用AI的練習。以下是兩個：取一個你寫的程序，將其粘貼到你最喜歡的AI聊天中，然後請AI生成註釋。然後查看這些註釋：它們正確嗎？AI在哪裡錯了？它在哪裡誤解了意圖？Stellman的觀點是，你寫了代碼；你了解它。你不是在懷疑AI。你在學習它可能會犯錯，並看到它可能犯的錯誤。一個好的下一步是請AI助手為現有代碼或一些新代碼生成單元測試（這導致測試驅動開發）。單元測試是一個有用的練習，因為測試邏輯通常很簡單；很容易看出生成的代碼是否不正確。而描述測試——描述你正在測試的函數、它的參數、返回類型和預期結果——迫使你仔細思考你正在設計的內容。

學會詳細描述測試是一個重要的練習，因為使用生成式AI並不是寫一個快速提示讓它生成一個函數或一個可能正確的短程序。計算的難點一直是準確理解我們想要做什麼。無論是理解用戶的需求還是理解如何轉換數據，這種理解的行為是軟體開發過程的核心。無論生成式AI能做什麼，它無法理解你的問題。成功使用AI需要詳細描述你的問題，這個提示的長度可能會顯著超過AI生成的代碼。你不能省略細節，因為AI不知道我們經常做的隱含假設——包括“我真的不明白，但我相信我可以在程序的那部分隨便應付一下。”你越明確，正確結果的概率就越大。編程就是以不含糊的細節描述一項任務，無論語言是英語還是C++。理解一個問題及其所有影響、特殊情況和潛在陷阱的能力是高級軟體開發者的一部分；這不是我們對剛入行的人所期望的。

我們仍然希望AI生成的源代碼結構良好。若讓其自行發展，生成的代碼往往會累積成一座技術負債的高山：結構不良的代碼，沒有人真正理解且無法維護。我見過一些論點認為AI代碼不需要結構良好；人類不需要理解它，只有能解析極其複雜邏輯的AI系統才需要理解。這在某些假設的未來可能是對的，但至少在不久的將來，我們並沒有這些系統。假設AI助手能夠有效處理混亂的意大利面條代碼是過於樂觀的。我不認為AI能比人類更好地理解一團糟。相信這樣的代碼可以被修改，無論是添加新功能還是修復錯誤，無論是人類還是AI進行修改，都是過於樂觀的。我們在過去70年左右的軟體開發歷史中學到的一件事是：代碼的壽命非常長。如果你現在編寫關鍵任務的軟體，它可能會在你退休後仍然被使用。未來的軟體開發者和AI助手將需要修復錯誤並添加功能。結構不良代碼的一個經典問題是，它的開發者將自己逼入了角落，使得修改變得不可能，除非觸發一系列新的問題。因此，理解我們想要做的事情並向計算機描述它的一部分是告訴它我們想要的結構：告訴它如何將代碼組織成模塊、類和庫，告訴它如何結構數據。結果需要是可維護的——而至少現在，這是我們比AI做得更好的事情。我並不是說你不應該詢問AI如何結構你的代碼，甚至讓它為你進行結構化；但最終，結構和組織是你的責任。如果你只是詢問AI如何結構你的代碼，然後在不思考的情況下遵循它的建議，那麼你將獲得的成功與僅僅要求AI編寫代碼並在不測試的情況下提交是相同的。

我強調理解我們想要做的事情，因為這一直是軟體開發學科中最薄弱的部分之一。理解問題是雙向的：面向用戶、客戶、希望你構建軟體的人；以及面向計算機、編譯器，將處理你給予的任何代碼。我們不應該將二者分開。我們經常說“垃圾進，垃圾出”，但經常忘記“垃圾進”包括思考不周的問題描述，以及糟糕的數據或錯誤的算法。我們希望計算機做什麼？我見過很多對未來編程可能樣子的描述，但沒有一個假設AI會決定我們希望它做什麼。我們需要解決的問題是什麼？我們需要徹底、深入、詳細地理解它們，而不是在項目開始時寫的一個單一規範。這是敏捷運動最重要的見解之一：重視“個人和互動高於過程和工具”和“客戶合作高於合同談判”。敏捷基於這樣的認識：你不太可能在項目開始時收集到所有用戶的需求；相反，開始構建並利用頻繁的演示作為收集更多客戶見解的機會，通過頻繁的中途修正來構建他們真正想要的東西。在AI編寫代碼時保持“敏捷”是一個新的挑戰——但這是必要的。當AI編寫代碼時，程序員將如何管理這些修正？通過管理上下文；通過給AI足夠的信息，使其能夠修改需要更改的代碼，同時保持其他部分穩定。記住，敏捷過程中的迭代不是修復錯誤；而是確保最終的軟體解決了用戶的問題。

理解我們想要構建的東西現在尤其重要。我們正處於軟體開發歷史上最大的一次重新思考的開始。我們正在談論構建我們從未見過的軟體類型：為用戶解決問題的智能代理。我們將如何構建這些代理？我們需要詳細了解客戶的需求——而不是“我想從Peapod訂購雜貨”的細節，而是在更高、更抽象的層面：“我想要能夠為我談判的軟體；我想要能夠找到最佳交易的軟體；我想要最大化成功概率的軟體；我想要能夠計劃我退休的軟體。”我們需要什麼樣的規範才能正確做到這一點？如果軟體代表客戶執行操作，它需要確保這些操作正確執行。如果涉及財務，錯誤幾乎是不可容忍的。如果涉及安全或保障，錯誤真的不可容忍——但在許多情況下，我們尚不知道如何規範這些需求。

這並不是說我們不會知道如何規範這些需求。我們已經知道如何建立一些護欄來保持AI在正確的軌道上。我們已經知道如何建立一些評估套件來測試AI的可靠性。但這是說所有這些需求將成為軟體開發者的工作的一部分。總的來看，軟體開發者的工作可能變得更加困難，而不是更輕鬆。

無論是有正式的初級開發者培訓計劃還是非正式的指導，我們顯然需要初級開發者，因為我們需要高級開發者——如果沒有經過良好培訓的初級開發者，下一代高級開發者將從何而來？Forrest Brazeal指出：

如果我們不能在技術工作的分類中為仍然需要人類培訓的人騰出空間，我們只是在做IT幾十年來一直在做的事情：借用我們的未來來兌現當前的炒作……而每一位經驗豐富的全能型人才都是從無經驗開始的。他們從初級開發者開始。這不是軟體工程的終結：而是它的誕生。

是的——這就是軟體工程的誕生：不是學習編程語言或記住API，而是實踐、經驗和指導。我們需要被提醒，軟體開發不僅僅是生成代碼。寫代碼的重要性可能會在未來減少，但正如斯坦福計算機科學教授Mehran Sahami在與Andrew Ng的對話中所說：“我們教你Python，但實際上我們是想讓你理解如何系統性地處理問題。”好的程序員將在理解問題和目標、結構解決方案、為他人提供必要上下文以及指導他人建立這些領域的技能方面磨練他們的技能。AI不會改變這些基本技能——無論是高級還是初級軟體開發者，投入時間學習它們都不會錯。

正如Tim O’Reilly所說，AI可能是我們所知編程的終結，但它不是編程的終結。這是一個新的開始。我們將設計和構建幾年前無法想像的新類型軟體。軟體開發是理解和解決問題，不論編程語言是Python還是英語，不論是否使用AI助手。軟體開發者的工作將是確定我們想要什麼，我們真正需要什麼，並將其描述給我們的機器。