摘要
加州大學柏克萊分校電腦科學教授 Sarah Chasins 在 GQ Taiwan 的專業問答節目中,深入解答了網路上關於程式設計的熱門問題。從早期網際網路的遺跡到 AI 輔助編程的實踐,從第一段程式碼的誕生到 Rust 語言的崛起,Chasins 教授以深入淺出的方式,帶領我們認識程式設計的本質。她不僅破解了「討厭數學就不能寫程式」的迷思,更透過現場編程示範,揭示了「vibe coding」的真實效果。無論你是程式新手或資深開發者,這篇文章都將為你提供全新的視角,理解程式語言的演變、除錯的挑戰,以及在 AI 時代學習編程的真正價值。
從第一行程式碼到 AI 編程:柏克萊教授解密程式設計的過去、現在與未來
前言
在這個 AI 快速發展的時代,程式設計的角色正在經歷前所未有的轉變。許多人開始質疑:當 ChatGPT 可以生成程式碼時,學習編程還有意義嗎?「vibe coding」真的能取代傳統編程嗎?Rust 為何被開發者如此推崇?
為了回答這些問題,加州大學柏克萊分校電腦科學教授 Sarah Chasins 在 GQ Taiwan 的「名人專業問答」節目中,針對網路上最熱門的程式設計問題提供了專業見解。Chasins 教授的研究專注於程式語言、程式合成與人機互動,特別致力於讓非傳統程式設計師也能輕鬆使用編程工具。
這場深度對談不僅回顧了程式設計的歷史,更展望了其未來發展。從第一個電腦病毒到現代的 AI 輔助編程,從二進制的基本原理到遊戲引擎的複雜架構,Chasins 教授以其豐富的學術經驗和教學熱忱,為我們揭開程式設計世界的神秘面紗。
網際網路的活化石:第一個網站至今仍可訪問
當我們談論早期網際網路的遺跡時,最令人驚奇的是:史上第一個網站至今仍然可以訪問。這個由全球資訊網發明者 Tim Berners-Lee 在 1990 年代初期創建的網站,介紹了什麼是全球資訊網。
Chasins 教授在現場展示了這個歷史性網站,它在現代瀏覽器 Safari 中依然能完整顯示。更有趣的是,有人重新創建了當年瀏覽器的版本,讓我們得以一窺那個年代的使用體驗。雖然內容相同,但在不同年代的瀏覽器中,呈現方式卻截然不同,這反映了網頁技術三十多年來的巨大演進。
這種跨時代的相容性,正是網際網路設計理念的最佳體現:開放、標準化,以及向後相容。
破解迷思:討厭數學也能成為優秀程式設計師
「如果我討厭數學,還能學寫程式嗎?」這是許多初學者最常問的問題。Chasins 教授給出了肯定的答案:「絕對可以,百分之百可以。」
她解釋道,某些類型的數學確實能讓某些類型的程式設計變得更容易,但這並非全部。許多技能都能幫助你成為更好的程式設計師,數學只是其中之一。甚至某些電玩遊戲培養的技能,也能對編程有所助益。
當然,如果你想從事某些特定領域的程式設計,例如電腦圖學或機器學習,數學背景會有幫助。但整體而言,你完全可以在不擅長數學的情況下,進入程式設計領域並取得優異成就。
這個觀點打破了長期以來的刻板印象,為更多對程式設計有興趣但害怕數學的人開啟了一扇門。
程式設計的演進:從插線板到編譯器革命
最早的程式碼如何誕生?
程式設計的歷史始於 ENIAC(電子數值積分計算機),這是第一台被廣泛認可的通用電腦。有趣的是,ENIAC 的「編程」方式類似於老式電話交換機:工程師需要手動插拔電線來連接不同的電路,藉此告訴機器該做什麼。
後來,人們發明了穿孔卡片,這種硬紙卡上打孔的方式成為長期輸入指令的標準方法。在那個時代,程式設計師必須手動編寫由 0 和 1 組成的機器碼,這是一項極其耗時且容易出錯的工作,往往需要花費數月時間。
Grace Hopper 的編譯器革命
真正改變遊戲規則的是傳奇人物 Grace Hopper。這位數學家和早期電腦科學先驅,提出了「編譯器」(compiler)的概念:與其讓人類手動將高階指令轉換成機器碼,不如讓電腦程式來完成這項工作。
她在 1950 年代初期開發的 A-0 系統,是現代編譯器的前身。這個工具能將不同的程式片段組合在一起,讓它們相互溝通。雖然以今天的標準來看,A-0 只是編譯器的一個子組件,但它開啟了程式語言發展的新紀元。
從此之後,程式設計師不再需要直接與 0 和 1 打交道,而是可以使用更接近人類思維的高階語言來表達想法。
程式語言大比拼:從 C、Python 到 Rust
程式語言之間有何不同?
Chasins 教授用一個生動的比喻來解釋程式語言之間的差異:關鍵在於它們「有多挺你」(have your back)。
C 語言屬於「你自己負責」的類型。它不會主動幫你捕捉錯誤,也不會阻止你寫出有問題的程式碼。你有完全的自由度,但也需要承擔所有風險。這種語言適合需要極致效能和精確控制的場景。
Python 則位於中間地帶。它會嘗試幫你捕捉一些錯誤,但不會要求你提供太多額外資訊,也不會過度干涉你的工作。這種平衡使得 Python 成為極其靈活的語言,適用於各種不同類型的程式。正如有人評論的:「Python 是任何事情的第二好語言。」雖然這句話帶點揶揄(暗示它不是任何領域的最佳選擇),但也反映了 Python 的多功能性。
Rust:最受歡迎的新星
Rust 則代表了另一個極端:它會盡可能地幫你捕捉錯誤,但代價是需要你提供更多資訊。這讓編程過程更費力,但回報是能在編譯階段就發現大量潛在問題。
Chasins 教授對 Rust 充滿熱情:「Rust 可能是目前最令人興奮的新程式語言之一。」她解釋了 Rust 受歡迎的原因:
- 貼心的錯誤訊息:當你犯錯時,Rust 的錯誤訊息設計得非常清楚易懂,這對學習語言至關重要。
- 融合最新研究成果:Rust 整合了過去二十年程式語言研究的最佳理念,特別是在幫助程式設計師提前發現錯誤方面。
- 高效能與安全性兼具:傳統上,如果你需要高效能,就必須使用 C 語言,但代價是要承擔更多風險。Rust 打破了這個權衡,同時提供高效能和高安全性。
這也是為什麼 Rust 連續多年在 Stack Overflow 開發者調查中被評為「最受喜愛的程式語言」。
JavaScript 與 TypeScript
對於網頁開發領域的主流語言 JavaScript,Chasins 教授承認它的某些設計選擇確實有爭議。但她也提供了實用建議:「如果你對 JavaScript 感到不滿,就學 TypeScript 吧。」TypeScript 是 JavaScript 的超集,添加了型別系統,讓開發體驗更好,同時仍能在網頁環境中運行。
程式設計師的真實日常:不只是寫程式
許多人對程式設計師的工作有浪漫化的想像,以為他們整天都在寫程式碼。但 Chasins 教授揭示了一個令人意外的事實:「不幸的是,實際寫程式的時間可能沒有你期望的那麼多。」
在實際工作中,程式設計師花大量時間在:
- 跨團隊溝通:與其他程式設計師討論如何整合不同的程式碼模組,讓整個大型程式庫協同運作。
- 需求訪談:與客戶或使用者交談,了解他們的需求,確認程式應該實現什麼功能。
- 會議與協作:參加各種會議,討論專案方向、技術選型、問題解決等。
- 文件撰寫:撰寫技術文件、使用手冊、API 說明等。
真正的程式碼編寫時間,往往是從這些活動的縫隙中擠出來的,「因為那通常是最有趣的部分」。
這個現實提醒我們:成為優秀的程式設計師,技術能力只是一部分,溝通能力、同理心、團隊合作等軟技能同樣重要。
電腦為何使用二進制?一個簡單實驗說明一切
「為什麼電腦只用 0 和 1?」這是個基本但重要的問題。Chasins 教授用一個精彩的思想實驗來解釋。
首先,她指出 ENIAC 實際上使用的是十進制(base 10),而非二進制。所以使用二進制並非必然,而是一種選擇。
燈泡實驗
想像你在一個房間裡,另一邊牆外有人控制調光開關,你只能看到燈泡的亮度。
情境一:二進制(0 或 1)
如果只需要判斷「暗」或「亮」兩種狀態,即使調光開關的位置有些偏差,你也能可靠地喊出正確答案。
情境二:十進制(0-9)
現在要求你根據亮度判斷出 0 到 9 的十個數字。當開關設在「5」的位置時,你可能會喊出「5」,但也可能喊出「4」或「6」,因為光線強度的細微差異很難精確判斷。
這個實驗完美說明了為何電腦採用二進制:電路中的電流強度判斷「有」或「沒有」(高電位或低電位)非常可靠,但要區分十種不同的電流強度就困難得多,也更容易出錯。
二進制雖然需要更多位元來表示相同的資訊,但換來的是極高的可靠性,這正是電腦設計的基本原則。
除錯為何比寫程式更困難?
「除錯為什麼比寫程式還要困難?」Chasins 教授對這個問題的回答是:「太困難了!」
心智模型的落差
答案在於你的「心智模型」(mental model)與程式實際運作之間的關係。
當你在寫程式時,你正在建立自己對程式行為的心智模型。你一邊寫,一邊確認程式是否符合你的預期。在這個過程中,你的心智模型與程式實際行為是同步的。
但當你開始除錯時,意味著程式的實際行為已經偏離了你的預期。你的心智模型與現實產生了分歧,而你需要找出問題所在。
閱讀別人的程式碼更難
如果你要除錯的是別人寫的程式,困難度會更高,因為你連基本的心智模型都沒有,必須從零開始建立對程式的理解。這就是為什麼閱讀程式碼(code reading)本身就是一項重要且困難的技能。
Chasins 教授建議:如果程式碼不是惡意的,可以先執行它,觀察輸出結果,然後追蹤是哪部分程式碼產生了這個輸出,再往回推,了解前面的步驟如何影響最終結果。甚至可以使用「時光旅行除錯器」(time travel debugger),讓你能回到過去查看程式執行的歷史狀態。
跨領域合作:電腦科學如何助力 CRISPR 基因編輯
當被問到電腦科學家如何為 CRISPR 基因編輯技術做出貢獻時,Chasins 教授展現了她對跨領域研究的熱情。
深入實驗室的學徒式學習
她分享了一個實際案例:她指導的一位博士生,實際上成為了生物實驗室的「嵌入式成員」。這位電腦科學背景的學生學會了移液操作,修習了生物學課程,在實驗室中協助編程任務,親身體驗生物學家的日常工作。
Chasins 教授強調:「問題不是簡單地讓生物學家寫一兩段問題描述,我們就能解決。」真正有效的跨領域合作需要深入理解對方領域的實際需求和痛點。
給年輕研究者的建議
她給出的建議是:「去與你想要支援的人們交流,花時間與你想服務的社群相處。」這種學徒式的深度參與,能幫助電腦科學家識別真正的問題所在,並開發出切實有用的工具。
這個觀點不僅適用於學術研究,也適用於任何技術開發:最好的工具往往來自對使用者需求的深刻理解。
ChatGPT 與大型語言模型:真的那麼神奇嗎?
面對「ChatGPT 是否真的像看起來那麼革命性」的質疑,Chasins 教授給出了理性而深刻的分析。
大型語言模型的本質
她解釋道,ChatGPT 建立在「大型語言模型」(Large Language Model, LLM)之上,而 LLM 本質上是「一個把看起來不錯的詞語組合在一起的程式」。
訓練過程:填空遊戲
LLM 的訓練過程可以理解為一個巨大的填空遊戲:
- 收集網路上所有能找到的文件(網頁、書籍等)
- 將文件中的詞語遮蓋,讓模型猜測
- 例如:「___狗有四隻腿」,模型猜「天空」→ 錯誤,應該是「這隻」
- 反覆訓練約 300-400 年的運算時間(透過平行運算)
這個過程讓模型建立了一個「作弊表」(cheat sheet),也就是我們常聽到的「參數量」——模型的參數數量就反映了這個作弊表的大小。
從填空到聊天機器人
訓練完成後,如何讓 LLM 變成聊天機器人?方法很簡單:
創建一個新文件:「這是人類與聊天機器人的對話記錄。人類問:瑞典的首都是什麼?聊天機器人回答:___」
模型會填入「斯德哥爾摩」,然後繼續生成下一個詞,逐步完成回答。
局限性與啟示
Chasins 教授總結:「這些只是把看起來不錯的詞語組合在一起的程式。」這意味著 LLM 在處理需要真正理解、推理或創新的任務時,能力有限。它們擅長的是基於大量既有文本,生成看似合理的內容。
對於程式設計來說,這意味著 LLM 能生成常見的程式碼模式,但在面對新問題或需要創新解決方案時,仍然需要人類程式設計師的介入。
AI 時代還要學程式設計嗎?答案是肯定的
「在 AI 發展如此快速的情況下,還值得深入學習程式設計嗎?」這可能是當前最受關注的問題。
Chasins 教授的答案很明確:「是的,你仍然需要能用傳統方式寫程式碼,才能從這些生成式 AI 工具中獲得有用的程式。」
問題分解能力依然關鍵
程式設計教育中最重要的技能之一是學習如何「分解問題」。你需要將一個大而模糊的問題,拆解成一系列小而具體的子問題,最終小到可以用幾行程式碼解決。
如果沒有經過這種訓練,面對模糊的大問題時,很難將它轉化為 AI 能夠處理的明確指令。
程式設計師語言 vs. 一般語言
另一個關鍵因素是語言表達方式的差異。訓練 LLM 的文件中,包含程式碼的部分通常由程式設計師撰寫,使用的是「程式設計師風格」的自然語言描述。
因此,如果你用程式設計師的方式描述問題,LLM 更可能生成正確的程式碼;而用一般人的描述方式,效果可能不佳。
結論
要有效使用 AI 輔助編程工具,你大多需要先懂得用傳統方式寫程式。這對許多人來說可能令人沮喪,但這就是目前的現實。
AI 輔助編程的正確使用方式
既然仍需要程式設計能力,那麼如何正確使用 AI 工具?Chasins 教授提供了實用建議。
第一步:確認真的需要
首先問自己:「你確定需要使用 AI 嗎?」並非所有情況都適合使用 AI 輔助。
正確的使用流程
- 拆解問題:將問題分解到最小的可管理單元,理想情況下應該只需要約五行程式碼。
- 撰寫偽代碼(Pseudocode):用類似程式語言的方式描述步驟,但不必在意語法細節(如分號、縮排等)。例如:
首先,取得使用者輸入
然後,檢查輸入是否有效
如果有效,進行計算
最後,顯示結果
- 輸入 AI 工具:將偽代碼提供給 AI,讓它生成實際程式碼。
- 驗證輸出:最關鍵的一步——你必須有具體計劃來確認生成的程式碼是否正確:
- 準備 20 個測試案例?
- 請懂程式的朋友檢查?
- 自己仔細審閱程式邏輯?
沒有驗證計劃,就不要使用
如果無法確認程式碼的正確性,Chasins 教授建議:「那就不要使用它。」這是負責任的態度,避免將錯誤或不安全的程式碼用於實際應用。
「Vibe Coding」的真相:感覺良好不等於真的有效
「Vibe coding」是指使用 LLM 或 ChatGPT 等生成式 AI 工具來產生程式,而非傳統的手工編寫。這個術語暗示了一種輕鬆、憑感覺的編程方式。
什麼時候有效?
Chasins 教授指出,vibe coding 在某些情況下確實有用:當你要重寫一個已經被寫過無數次的程式時。因為 LLM 的訓練資料中包含大量類似的程式碼,它能夠可靠地生成這類常見模式。
什麼時候無效?
但如果你想做任何新的事情,「那可能無法讓你達到目標」。創新性的問題需要創新性的解決方案,而這正是當前 LLM 的弱項。
感知 vs. 現實的驚人落差
最引人注目的是 Chasins 教授分享的研究發現:
「有非常有趣的研究調查了使用 LLM 工具是讓人更有生產力,還是只是讓人『感覺』更有生產力。結果顯示,使用 LLM 工具讓開發者慢了 20%,但即使完成任務後,所有人都說他們覺得自己快了 20%。」
這個發現揭示了一個重要現象:AI 工具可能給人一種生產力提升的錯覺,但實際上可能適得其反。這種「感覺良好」的陷阱,值得所有使用 AI 輔助工具的開發者警惕。
最佳策略
Chasins 教授建議:將問題切割成極小的部分,然後運用自己的推理能力來實際編寫程式,而非完全依賴 AI。
現場編程示範:從資料獲取到視覺化的完整流程
為了展示實際的程式設計過程,Chasins 教授進行了一場精彩的現場編程示範,創建了一個從 API 獲取各國預期壽命資料並繪製地圖的程式。
程式演進過程
- 基礎版本:列印國家代碼
country_codes = ["USA", "MEX", "CAN"]
print(country_codes[0])
print(country_codes[1])
print(country_codes[2])
- 改進:使用 URL 替換
將國家代碼插入到 URL 模板中,生成不同國家的資料請求 URL。
- 引入 requests 函式庫
不只是列印 URL,而是實際向網路請求資料:
import requests
requests.get(url)
- 使用迴圈消除重複
當意識到在重複做相同的事情時,引入 for 迴圈:
for i in range(len(country_codes)):
url = sample_url.replace("USA", country_codes[i])
response = requests.get(url)
- 解析 JSON 資料
從回應中提取所需的預期壽命數值:
json_data = response.json()
life_expectancy = json_data['value'][0]['numericValue']
- 儲存資料
建立空列表並將資料追加進去:
data = []
data.append([country_code, life_expectancy])
- 視覺化呈現
使用 Plotly 函式庫繪製世界地圖:
import plotly.express as px
fig = px.choropleth(data, locations=0, color=1)
fig.show()
- 擴展到所有國家
最後將程式應用到完整的國家代碼列表,而非只有三個範例。
程式設計的核心思維
這個示範完美展示了程式設計的漸進式開發過程:
- 從簡單開始,逐步增加複雜度
- 當發現重複時,引入自動化(迴圈)
- 使用現有函式庫(requests, plotly)而非重新發明輪子
- 先用小資料集測試,確認邏輯正確後再擴展
整個過程不到一分鐘就完成了從資料獲取到視覺化的完整流程,生動展示了現代程式設計的強大與優雅。
程式碼如何變成電腦能理解的指令?
最後,Chasins 教授用一個具體範例解釋了程式碼如何從人類可讀的形式轉換成電腦能執行的機器碼。
四個轉換階段
以簡單的數學表達式 (1 + 2) + 4 為例:
階段一:詞法分析(Lexing/Tokenizing)
將程式碼拆分成最小單元(tokens):
[左括號, 1, 加號, 2, 右括號, 加號, 4]
空格被忽略,每個符號和數字成為獨立的 token。
階段二:語法分析(Parsing)
將 tokens 組織成樹狀結構,反映運算優先順序:
加號(第二次執行)
/ \
加號 4
/ \
1 2
這個結構確保括號內的 1+2 會先計算,結果再與 4 相加。
階段三:程式碼生成(Code Generation)
轉換成處理器能理解的指令:
MOV R8, 1 # 將 1 放入暫存器 R8
MOV R9, 2 # 將 2 放入暫存器 R9
ADD R8, R9 # 相加,結果存入 R8
MOV R9, 4 # 將 4 放入 R9
ADD R8, R9 # 最終相加,結果在 R8
階段四:二進制編碼
每條指令都有對應的二進制編碼方案,最終變成純粹的 0 和 1:
10110000 00000001 (MOV R8, 1)
10110001 00000010 (MOV R9, 2)
...
實際執行示範
Chasins 教授使用了「x86-64 Playground」網站來展示這些指令如何逐步改變電腦的狀態:
- 執行
MOV R8, 1→ R8 暫存器顯示數值 1 - 執行
MOV R9, 2→ R9 暫存器顯示數值 2 - 執行
ADD R8, R9→ R8 顯示 3(1+2 的結果) - 執行
MOV R9, 4→ R9 更新為 4 - 執行
ADD R8, R9→ R8 顯示 7(最終結果)
這個過程清楚展示了電腦如何「理解」並執行程式碼:透過編譯器的多階段轉換,將人類友善的高階程式碼,逐步轉換成機器能直接執行的低階指令。
結語
從這場深入的專業問答中,我們看到了程式設計的全貌:它不僅是技術,更是一種思維方式。從 Grace Hopper 發明編譯器的遠見,到 Rust 語言對安全性與效能的完美平衡,從二進制的基本原理到大型語言模型的運作機制,Chasins 教授為我們揭示了程式設計世界的豐富與深刻。
最重要的啟示或許是:即使在 AI 快速發展的時代,程式設計的核心能力——問題分解、邏輯思考、除錯能力——依然不可或缺。AI 工具可以是強大的輔助,但無法取代深度的程式設計知識。「vibe coding」的研究結果更提醒我們,不要被表面的便利性所迷惑,真正的生產力來自扎實的基礎和清晰的思維。
對於想進入程式設計領域的人,Chasins 教授的訊息是鼓舞人心的:你不需要熱愛數學,不需要天生擅長抽象思維,只要願意學習、保持好奇,並理解程式設計是一項可以透過實踐逐步精進的技能。就像騎自行車或彈吉他,一開始可能困難,但終將變得自然流暢。
而對於資深開發者,這場對談提醒我們保持開放的心態:關注新語言如 Rust 的發展,理性看待 AI 工具的能力與限制,並思考如何將程式設計的力量帶到其他領域,如 CRISPR 基因編輯,創造真正的跨領域影響。
程式設計的未來充滿可能,而理解其過去與現在,正是把握未來機會的關鍵。正如 Chasins 教授在節目結尾所說:「希望你們都學到了新東西,也希望你們對程式語言,甚至對編譯器感到興奮。」這份對知識的熱情與好奇,正是推動技術進步的永恆動力。
延伸閱讀
@power by Claude

0 留言