程式碼多了 70%，功能卻一個沒多：Titus Winters 談 AI 時代的工程、生產力與教育

一位資深工程師告訴 Titus Winters：導入 AI 之後，程式碼量上升 70%，線上事故上升 30%，交付的功能數量卻和以前一樣。這句話不是在唱衰 AI，而是在指出一件更深的事：我們用來衡量工程的那把尺，已經量不到 AI 真正帶來的東西了。

Titus Winters 是誰？ 他在 Google 待了十多年，是《Software Engineering at Google》的主要作者，帶領過 Google C++ 基礎程式碼的大規模重構，也是 Google「Readability」程式碼審查計畫的最後一任負責人。離開 Google 後，他到 Adobe 擔任資深 Principal Engineer，負責開發者體驗。更特別的是，他有一個 CS 教育的博士學位，而且在 2023 年是 ACM/IEEE 大學部 CS 課綱指導委員會裡唯一一位在業界現職的工程師。

換句話說，這是一個同時站在三個位置的人：他知道世界最大規模的程式碼庫是怎麼被維護的，他知道「開發者生產力」這件事為什麼難量，他也知道今天大學是怎麼教軟體的。2026 年 10 月他接受《The Pragmatic Engineer》Podcast 訪談，把這三件事串在一起講。本文把那場近兩小時的對話整理成七堂課，每一堂都從一個具體的故事出發，再說明背後的道理。

這七堂課的順序是刻意安排的：前四堂講 Google 怎麼做工程（測試、重構、AI 工具、程式碼審查），第五堂講團隊，第六堂講生產力，第七堂講教育。你會發現它們最後匯流到同一個結論。

第一課：恐懼不是工程決策的基礎

Google 的測試文化不是從理念開始的，是從一場危機開始的。

2006 到 2007 年，Google Search 失去了定期發布的能力。 團隊原本想每個月出一版，實際上一季能出一版就不錯了。原因是 regression 不斷：每次改東西，總有別的東西壞掉。當時 Google 的架構還沒有像今天這樣切分成獨立的產品，改 Gmail 的程式碼可能牽動 Search。所有東西綁在一起，所有發布都被卡住。

負責發布的 release engineers 聯手畫了一條紅線：沒有測試的變更，一律不准合併。 不管哪個副總裁開口，不管這個功能多重要，沒有測試就 rollback。這條線一劃下去，連那些覺得「我很聰明，寫測試是在侮辱我」的工程師也只能跟進。

這就是 Google 測試文化的起點。到了 2010 年 Titus 加入、接手維護底層 C++ 函式庫時，這張安全網已經鋪好了。他可以放心重構，因為結果只有兩種：測試全過，代表改對了；或者有東西壞了但測試沒抓到，代表那裡的測試覆蓋不足，正好補上。兩種都是收穫。

什麼叫「可持續的程式碼庫」

Titus 給了一個很簡單的定義，寫在他那本書的前幾頁：對任何有價值的變更，你都有能力安全地做出來。 你可以選擇不做（可能是技術債、可能是產品優先順序），但不能是「做不到」。

他的理由是：如果你因為害怕而不敢改某段程式碼，你就等於在賭「這段程式碼永遠不需要改」。這是一個高風險的賭注。尤其這幾年資安環境惡化，沒有任何東西是不會變的。「能改」本身就是戰略優勢。

所以他的原則很直接：如果恐懼讓你不敢動手，那恐懼本身就是必須先修掉的 bug。

為什麼新人特別害怕

主持人問：如果我加入一家公司，前幾週、前幾個月都不敢推 code，怕弄壞 production，這代表什麼？Titus 說，要嘛系統設計得不好，要嘛 onboarding 和 mentoring 沒做到位，通常至少中一個。

但他指出更深的根源在教育。大學給學生的印象是：題目有標準答案、有對錯、每次有人看你的 code 都是在打分數。 真實的工程世界完全不是這樣，所有決定都是 trade-off，是設計空間裡的某一個點，沒有絕對的對錯。

在學校，唯一會看你程式碼的時刻就是評分。但一個成熟的工程師會頻繁地主動要回饋，那不是審判，只是在問「方向對嗎？這樣說得通嗎？」能拿到越多這種非評判性的回饋，你就越有效。Titus 的結論很尖銳：我們給了所有新人完全錯誤的本能。

第二課：人類史上最大的重構是怎麼做的

Titus 說，他帶過的 Abseil 清理工程，可能是人類史上最大的一次重構。他承認無法證明，但他會很驚訝如果有人找到更大的。

為什麼要重構

大約十年前，Google 轉向雲端、Google 也重組成 Alphabet，公司開始思考：我們有這麼多好用的內部開發工具與底層元件，能不能分享給 Alphabet 旗下的其他公司，甚至雲端客戶？

其中最底層的那一層叫 Abseil：它是 Google 內部 C++ 的「共通語彙」，也就是 cache、container、字串處理、命令列參數這類比資料庫還低一層的基礎元件，Google 所有的 C++ 程式都是用它們組出來的。計畫是把這層開源。

但開源前先要回答一個問題：這些慣用寫法裡有些很醜、是技術債，要不要先清乾淨再對外承諾？Google 的答案是要。於是今天你看到的 Abseil 開源專案，是清理後的結果；真正的工作量在清理本身。

規模有多大

約 2 到 2.5 億行第一方 C++ 程式碼，不含外部相依套件。
每個月約 1 萬名工程師在修改這個程式碼庫。
執行清理的團隊只有 10 到 12 人全職。

Titus 的比喻：Google 發明了一種新的摩天大樓地基技術，我們要把帝國大廈的地基換掉，不准封樓、不准擋交通，然後還在地下室發現了核廢料。

為了讓讀者有感，主持人提供了一個對照：Uber 的 iOS 與 Android app 各約 100 萬行，由 200 位工程師寫了好幾年；業界超過 300 萬行的專案已經很罕見。2.5 億行是百倍的量級，而且全是跑在 Google Search、Gmail、Maps 底下的生產程式碼，改壞任何一處，世界上最常被使用的服務之一就會出事。

方法：不是找字串，是看語法樹

一個底層 API 可能有五萬個呼叫點，手動改是不可能的。Titus 的團隊和 Clang/LLVM 編譯器團隊合作，做出了 AST（抽象語法樹）層級的轉換工具：

用 MapReduce 把整個程式碼庫的每個編譯單元都解析成語法樹。
在語法樹上做語意匹配：不是「找到這串文字」，而是「確定你在這個情境下呼叫了這個特定函式」。
對匹配到的地方套用改寫規則，自動產生所有的程式碼修改。

一個意想不到的難題：工具能產生正確的程式碼，卻排不好空白和縮排。clang-format 就是因為 Titus 需要它才誕生的。 今天許多 C 系語言的自動排版工具，源頭是一個重構工程師的許願。

技巧：讓新舊 API 共存

就算工具產生了一個巨大的修改，也不能直接提交。原因很現實：任何程式碼庫都有一個背景變動率。當你要改一到兩萬個檔案時，在你測完之前，一定有人改到了同一個地方。而且你不可能對一萬人的公司說「大家停手一小時，讓我提交」。

所以流程變成這樣：

先讓新舊兩種寫法同時合法，程式碼庫處於兩者並存的狀態。
把修改按目錄結構切成小批次，平行送審、平行合併。
全部清完後，趕在有人複製貼上舊寫法之前，刪掉舊的 API，新的變成唯一的預設。
這個循環重複幾百次，程式碼庫就脫胎換骨了。

其他工程師的反應

一開始大家很反彈：「你為什麼改我的 code？我沒答應。」但很快就變成：「這太棒了，我什麼都不用做，我的 code 自己就變好了。」

更重要的是一個文化上的副作用。當有一個團隊在持續清理整個程式碼庫時，「複製貼上別人的寫法」就成了正確答案。因為如果那種寫法是錯的，早就被修掉了。你不用再查文件、不用擔心哪種做法才對，找到一個現成的例子抄過來就好。這就是一致性帶來的紅利。

第三課：別讓 AI 燒 token，讓 AI 造工具

聽完 Google 的重構故事，主持人提出一個對比：今天如果要做大重構，大家第一個想到的就是叫 AI 去改。但 AI 的做法比起 Google 當年的確定性方法，明顯粗糙得多，改了可能對、可能不對，每次跑結果還不一樣。Google 那套方法會不會有一天普及？還是大家就這樣將就下去？

Titus 的回答是：那套方法早就普及了，只是你沒注意到。

宣告式改寫工具

Java 生態有一個工具叫 OpenRewrite。你寫一份「recipe」，描述「我要找什麼樣的程式碼 pattern，改成什麼樣」，然後它確定性地掃過所有 Java 檔案，照著改。C++ 領域也有新創公司（BrontoSource）在做同樣的事，而且是在很高的意圖層次上宣告改寫。

關鍵的發現是：AI 非常擅長寫 OpenRewrite 的 recipe。 比起叫 AI 直接改每一個檔案，這種做法：

token 消耗少得多，因為 AI 只寫一次規則，不用讀每個檔案。
更準確，因為真正改程式碼的是確定性工具，不會「這個檔案改對、那個檔案漏掉」。
更快。
可稽核，因為規則是白紙黑字，可以被審查。

Netflix、Uber 等公司的技術分享都指向同一個結論：你需要的是一個宣告意圖的確定性工具，讓 AI 幫你寫那個工具的設定，然後把確定性的部分交給工具跑。

零 token 架構

Titus 引用 Kelsey Hightower 最近的一場演講，核心主張叫「零 token 架構」：不要用 AI 做持續性的推論，用 AI 去產生真正幹活的確定性工具。 AI 只需要負責兩件事：工具解不了的縫隙，以及判斷什麼時候該呼叫哪個工具。

他的說法是：如果你的整個架構是永遠在燒 token，那很可能不是最便宜的做法，也不是最有效的做法。

一個實際案例：從 AI code review 到 lint 規則

主持人分享了一位工程主管的做法。他們用了 AI code review 工具，品質不錯，但又貴又慢，而且不確定：這次抓到的問題，下次不一定抓得到。

這位主管的解法：定期還是跑 AI review，但每當它發現一個問題，就讓 AI 產生一條對應的 lint 規則。從此這個問題由 linter 負責，便宜、秒速、每次都抓得到。AI review 的頻率可以降低，人類的時間可以留給真正需要判斷的地方。

靈感來自 Uber。主持人回憶自己剛進 Uber 時，第一週幾乎提交不了程式碼，因為 linter 一直退件。Uber 的工程文化是：每次出事，就加一條 lint 規則。 連架構規則都寫成 linter，例如某種類別不准繼承某種類別，違反就直接擋下。

Titus 完全認同這種做法。他的總結是：困難的教訓只學一次，把它寫進確定性的規則裡，公平地、一致地套用到所有人身上。然後把人類的注意力留給真正需要人類判斷的地方。 這在 AI 之前就是對的，現在更是如此，因為我們不可能 review 所有東西，但某些地方的人類注意力是值得花的。

第四課：把 code review 變成一所學校

Google 是主持人知道的唯一一家公司，code review 不只有「懂這段系統的人說 OK」，還有另一道關卡叫 Readability review。

兩個權限位

在 Google，一個變更要合併，作者或審查者之間必須湊齊兩種資格：

Ownership：有人在這些檔案的授權修改名單上。
Readability：有人被認證「我們相信你懂得用這個語言，寫出符合這個程式碼庫慣例的程式碼」。

第二個資格的目的只有一個：一致性。Titus 說一致性的戰略價值高得難以想像。它讓所有人用同樣的模式寫東西，不重複造輪子，不需要每次讀 code 都先適應作者的風格。

從入會儀式到導師制

這個制度的演變本身就是一個規模化的故事：

最早：Google 的 3 號員工 Craig 親自坐下來，帶每一個新人走過他的第一個變更。
之後：這當然無法擴張，於是找了一群人代理 Craig，帶你走過第一個「夠大」的實質變更。
問題出現：隨著公司成長，多數工作變成在既有產品上做小修改，很難找到一個變更大到能一次證明你什麼都懂。整件事變得像入會儀式，而不是學習。
轉型：Java 社群率先改成導師制。你照常做日常工作，團隊簽核後，系統從一群 Java mentor 裡輪流指派一位來看：這裡有沒有值得提升品質、對齊慣例的地方？

這個設計有一個漂亮的自動校準效果：如果你的團隊標準本來就高，mentor 沒什麼好評論的，你很快就畢業；如果你的團隊標準低，而你又選擇不學，你會畢業得非常慢，甚至畢不了業。

可能是全世界最大的教育計畫

Titus 離開 Google 之前，是整個 Readability 計畫的負責人。他估計這可能是科技業最大、甚至是全世界最大的教育計畫，因為任何時刻都有數萬人在其中。而且你不是自願參加的，進 Google 就自動加入。

他強調這是刻意設計的，不是副產品。一個工程師在這個制度裡的成長路徑是：

先處理 mentor 的評論。
開始覺得被評論很丟臉，想要少被評論。
終於拿到零評論，開始想自己當 Readability reviewer。
開始給別人回饋，看到其他團隊的程式碼、其他地方在用的技術。

走到第四步，你已經不只是在學語言了。你在認識人、在建立導師關係、在吸收整個公司的技術流動。Titus 的形容是：這是一個藏在水面下的資訊分享機制，表面上是 code review，實際上是整個工程組織的知識在流動。

第五課：軟體工程是團隊運動，句號

主持人引用書裡的一段話：在程式設計的世界裡，獨行俠極為罕見，就算存在，他們的成就也幾乎都是一個靈感火花之後接上一整個團隊的努力。然後他問：現在大家開始講「100x 工程師」、講一個人帶一群 AI agent 完成壯舉，團隊這個概念還站得住嗎？

不管你信不信 AI，團隊都還在

Titus 的回答是：無論你在「AI 信仰光譜」的哪一端，團隊都是核心。

如果你相信 agent 就是答案，那你其實是在管理一個 agent 組成的團隊。越來越多人指出，我們正在要求每個工程師變成「agent 團隊的工程經理」，但沒有人受過這種訓練，也沒有任何鷹架或指引。
如果你把 AI 當工具（像你的 IDE），那工作的仍然是你和你身邊的人類團隊。

兩種看法都導向同一個結論：清楚溝通、把事情寫下來、把想法從腦袋裡拿出來讓別人看得懂，這些能力只會更重要。軟體工程是團隊運動，句號。

主持人補了一個觀察：看看領先的 AI 實驗室，例如 Claude Code 有 Boris 這個公開面孔，但背後是一個彼此信任的團隊。他休假的時候你根本不會察覺，因為事情照常發生。

心理安全：一個 15 題問卷的預測力

主持人扮演魔鬼代言人：我們談的是聰明的工程師，他們本來就該懂自己的專業，心理安全真的那麼重要嗎？

Titus 用數據回答。DORA 研究團隊的發現是：用一份 15 題的文化問卷，就能解釋一個團隊能否達成目標的 30% 變異量。 他說這簡直是瘋狂的數字，因為找不到任何其他訊號有接近這種預測力。你可以堅持「我們都是工程師，這只是電腦和技術，情緒無關」，但請找出任何一個同樣強的成功預測因子。找不到。這是人的問題，句號。

為什麼是重複賽局

Titus 不喜歡《人月神話》裡「外科手術團隊」那一章。那個模型是：找最強的人來開刀，其他人幫他造工具、寫文件，非常階層化。他說這只有在你一輩子只做一個專案時才合理。

但真實的工程組織是重複賽局。不是囚徒困境，是重複囚徒困境，策略完全不同。正確的策略是：找最資淺、在督導下能完成的人去做，讓他成長，資深的人去解那些還沒人會解的題。 這是唯一能讓整個團隊持續成長的結構。

而這個結構有一個前提：人必須願意承認自己不會。這就直接回到了心理安全與學習文化。任何關於生產力或團隊效能的研究，追到最後都是文化、心理安全、被允許學習：允許說「我不知道」、有誘因互相學習、有誘因分享錯誤讓團隊只犯一次。你的 lint 規則、你的事後檢討文化，科技業每一個有效的結構，本質上都是在處理資訊流動與學習。

兩種公司，兩種本能

為什麼 AI 實驗室天生就有這種文化？主持人分析了背後的結構：

條件	AI 實驗室	每年裁 6% 的公司
業務狀態	營收、客戶、人數、股權都在暴衝	成長停滯或下滑
績效考核的意義	不重要，股權上漲已經照顧了財務	決定獎金，甚至決定去留
說「我不知道」的代價	零，大家都在做沒人懂的東西	考核會扣分，被貼標籤
同事是什麼	一起學習的夥伴	搶專案的競爭者
結果	自然形成學習文化	大家求生存、藏拙、停滯

Titus 補充：如果你相信團隊成功就是你的成功，你就不需要搶那個最亮眼的任務，因為團隊會成功，下次可能就輪到你。但一旦退化成個人主義、不信任隔壁的同事、為了注意力互相競爭，那不是創新的配方，是停滯的配方。

裁員的隱藏成本

主持人問：裁員之後，工程師的工作狀態會怎麼變？

Titus 的觀察是：接下來幾週到幾個月，每一次一對一都從「你還好嗎？你撐得住嗎？」開始。大量時間花在互相情緒支持，才能回到工作本身。人們把一對一的時間拿來當治療，把工作時間拿來更新履歷，以防自己是下一個。他非常懷疑高層在算這筆帳的時候，有沒有把這些隱藏的生產力損失算進去。

更深的傷害是心態上的：裁員提醒每個人，這只是一樁商業義務，不是一種生活方式。如果我多付出也不會更安全，那何必？

他特別提到 Adobe。前任 CEO 經歷過金融海嘯時期的裁員，親眼看到那對士氣和公司靈魂的傷害，於是得出結論：當時數字上看起來合理，但那不是我們想成為的公司。所以 Adobe 在這幾年沒有做全公司規模的裁員，只有局部的重新調整。

第六課：為什麼 AI 的價值，你的指標量不出來

Titus 現在在 Adobe 負責「開發者體驗」。他坦白說這是一個禮貌的說法，開發者體驗其實就是生產力的生意，只是我們懂得不要宣稱自己能衡量生產力。（他和主持人都對 McKinsey 那篇「如何衡量開發者生產力」深惡痛絕。）

沒有單位，怎麼量

生產力難量，根本原因是沒人知道它的單位是什麼。Titus 的想法是借用經濟學：你量不出一個東西，就做一個指數。

做法大致如下：

廣撒網，量所有你認為代表「事情進行得好或不好」的指標：發布次數、測試覆蓋率、PR 數量……全部收。
用「二選一」的方式讓資深工程師反覆投票：你比較想要每週多發一版，還是多 X 個測試？跑很多輪，算出各指標之間的線性權重。
去掉重複的（同一件事換個包裝），找出有非線性關係的。
混合成一個無單位、但有方向性、可以隨時間追蹤的數字。

Adobe 正在做這件事的進階版。你可以看著這個數字對一群人隨時間上升或下降，它是有用的。

但這抓不到 AI 帶來的東西

Titus 後來意識到，這種指數在 AI 時代會漏掉最重要的部分。他最近發表的論文《Develop, Deploy, Operate》提出，科技業的影響有四種：

影響類型	內容	例子
產品成功	人們買不買、用不用	營收、NPS
運算效率	省下的機器與頻寬	AWS 帳單；Android app 每小 1 MB 就動很多指標
工程產能	同樣的人做更多事	省下 5% 不會變成另一個帳戶的錢，而是更多 slack 與創新空間
改變遊戲規則	讓不可能變可能	研究讓不可能變可能、資安讓災難變不可能

AI 的價值大部分落在第四類。問題是：如果每一個變更的「價值」本身變了，任何只量「產出多少」的指標都看不見。 我們沒有任何工具能說「現在一個這種大小的變更，價值和三年前不一樣了」。

他舉了自己領域的例子：今天你可以在兩週內寫出一個 JPEG parser，加上你需要的任何額外功能。三年前把這句話說出口，會被當成瘋子。

一個改變遊戲規則的案例

主持人講了一個真實故事。一家中型工程公司的 CTO 私下承認，導入 AI 後，他其實知道可以用一半的人做同樣的事，只是不想承擔裁員的情緒包袱，先放著。

幾週後他們再碰面，CTO 說公司可能要轉為現金流正向了。不是因為裁員，而是因為一位工程師做了一件事。

這家公司有一個核心元件是向供應商授權的，閉源、二進位、每年分潤 5% 到 15% 的營收。自己寫要 5 到 10 人花好幾年，還不一定成功，所以一直沒人碰。這位工程師把元件的規格和他們手上大量的測試 harness 餵給 AI，AI 寫出了一個更快、更好的版本，而他們完全沒有這個領域的先備知識。

他們本來想開源，告訴供應商之後，供應商反過來付錢請他們不要開源，把實作賣給供應商重新授權。遊戲規則完全變了。

主持人的感慨是：如果 CTO 當初先裁員，這位工程師可能就被裁掉了，沒有人會知道這件事原來可以做。

20% 還是 10 倍？

Titus 指出一個落差：他沒看過任何研究數據說 AI 讓生產力提升超過 20% 到 30%，但大家都在講 10 倍的體驗。他不認為真的有 10 倍，但這個落差要怎麼解釋？

答案就是上面那件事：AI 的價值大部分不在把同樣的事做得更快，而在去做你原本根本不會想到要做的、更難、更有價值的事。 如果你的生產力指標是數工廠出了幾個零件，當你開始生產鍍金豪華零件時，指標完全看不出差別，因為我們從來沒有追蹤過「這個功能值多少」。

這也解釋了開頭那句話。資深工程師說：程式碼量上升 70%，事故上升 30%，功能數持平。他們無法知道的是，這些功能的價值有沒有上升，因為沒有人知道怎麼量。

第七課：該被燒掉的 CS 課綱

這一段 Titus 先亮出資格：他在 2023 年參與 ACM/IEEE 大學部 CS 課綱的制定，負責軟體工程的部分，而且是指導委員會裡唯一一位在業界現職的工程師，其他人都是學者。所以他清楚知道課綱裡有什麼，也在這個領域裡待了很多年。

診斷：一個 90 年代的課綱

他的判斷很不客氣，而且是在 AI 出現之前就這麼說了：

多數 CS 課綱自 2000 年、甚至更早就沒有實質改變。 課綱裡的平均內容，就是 90 年代要做一個資料庫或作業系統所需要的東西。對一個以創新自豪的領域來說，這很難看。
必須誠實問每一個主題：我們教它是因為它重要，還是因為它是傳統、因為我們知道怎麼教？CS 系所的歷史才 50 到 70 年，這個領域太年輕，沒資格靠傳統過活。
課綱是靠堆積長大的：一直加新東西，每個既有主題的深度就少一點點。結果學生對一百萬個主題有常識級的理解，卻沒有成為一個流暢的程式設計者與演算法思考者。他在 AI 之前就希望學生多花時間練習與反覆操作，而不是累積瑣碎知識。

一個 CS 學位等於 15 個月的工作

Titus 算過：一個 CS 學位的總時數，大約等於 15 個月的全職工作。 這 15 個月還包含所有理論課、所有相關性存疑的內容。對比一個 6 個月的 bootcamp，差距其實沒有想像中大，而且 bootcamp 全部聚焦在立即可用的技能。

主持人補充了 2010 年代 bootcamp 的現象：3 到 6 個月，從零開始，第一天就動手做一個完整的 web 應用。畢業生懂 Git、懂 pull request、懂資料庫、懂前端、懂 Chrome 開發者工具。CS 畢業生懂不懂這些？看運氣。

這也解釋了 LeetCode 面試為什麼存在。Titus 說，業界不是真的需要再多一個 BFS 的解法，LeetCode 題是一個代理指標：它在找「你有沒有練過」的訊號。有練過的通常是那些參加程式競賽的學生，因為那是學位裡唯一提供大量練習的地方。平均一個學位裡真正寫程式的時間少得可憐。

他特別讚賞加拿大的學校，例如 Waterloo。那裡的學生畢業前會有四段實習，等於帶著一年的真實工作經驗進入業界。很多加拿大的學位因此要讀五年，但教育品質強得多。

AI 之後：整個學位可以不動腦念完

AI 讓問題變得無法迴避。Titus 說得很直接：現在一個人可以不動腦完成整個大學部學位，只要把所有作業丟給 AI，它都能做得不錯。

一開始的討論都是「怎麼防止學生用 AI」。他認為這是胡說。這和當年高階語言與編譯器出現時說「那你就學不到組合語言了」是同一回事。業界反正在用，學生畢業後會被要求用、被逼著用。主持人補充：現在一個新鮮人說「我沒用過這些工具」，反而是紅旗，你是不想在這個產業工作嗎？

他和一群學者這個月在 ACM 通訊共同發表了一篇文章，開頭是：想像 2040 年，我們還在堅持把所有 AI 使用視為作弊，但這一代學生是在 AI 裡長大的，就像網路原生世代在網路裡長大一樣。如果我們繼續問他們「在這個字串裡找回文」，他們能從傳統 CS 學位學到任何東西嗎？答案顯然是否定的。

既然留在原地不可能，而且本來就有一堆東西需要修，那就燒掉它，做點有意義的事。

轉向：離開 code，往上提升

Titus 推動的方向是：我們必須離開程式碼本身，大幅往上提升層次。

學生仍然需要讀得懂 code，要有系統思維，要理解結構與執行方式。
但沒有人需要再實作一個 linked list。他甚至認為不該教 linked list，因為它太慢了，記憶體存取本來就是慢的東西。
重心應該轉向：設計、規格、精確地說出你要什麼，以及測試、驗證、確認 AI 真的做了你要它做的事。

如果能教會這些，課程對專業工作就立刻有意義。他的預測是：CS 的入學人數會崩跌，軟體工程學程會起飛。 因為老實說，在 AI 時代還能讓你找到工作的東西：團隊合作、溝通、設計、規格、測試、驗證，全都是軟體工程的題目。

評分的改革：評過程，不評 code

如果你擔心學生用 AI 作弊，Titus 說有一個很簡單的解法：停止只評最後交出來的程式碼。

改評什麼？

你用了哪些 prompt 才走到這裡？
你提供了哪些測試？你怎麼確認這個東西真的做了你需要它做的事？
整個創作的過程，整包交上來。

他的推論是：過去我們說「再寫一篇《麥田捕手》的心得」、「再寫一個 linked list」，世界根本不需要另一篇心得或另一個 linked list。我們要的是那個產出物作為一個代理指標，代表你投入了時間、經歷了掙扎、面對了摩擦，所以你應該學到了什麼。既然這個代理指標現在可以被 AI 瞬間偽造，那就直接看掙扎與學習的證據。

這個原則不只適用於 CS。主持人補充，面試也在往同樣的方向走：讓你邊用 AI 邊解釋你在做什麼，面試官可以一直往不舒服的方向推，你假不了。大學也開始增加口試。

教授們看到的三層分化

Titus 從很多教授那裡聽到同一個令人不安的故事：

學生群	AI 之後的變化	原因
B+ 以上	比歷史上任何時候都強	他們有一個無限耐心、隨時在線、讀過一切、偶爾幻覺的家教；而且他們有自主性與後設認知，不會直接抄
最差的一群	略好一點	以前什麼都做不出來，現在至少能生產 slop
中間那一大群	塌陷了	缺乏抗拒「直接貼答案」的韌性，寧願去派對或打電動；「就這一次」變成習慣，一路滑下去

有些不錯的學校的教授坦言：B 以下的學生，可能完全不懂程式碼是怎麼運作的。而系統沒有設計來追蹤這件事，也沒有給他們回饋。

Titus 的理想課綱

主持人問：如果課綱不是委員會設計的，而是你一個人說了算，三到四年的大學部課程會長什麼樣？Titus 先聲明沒有人知道答案，沒有 playbook，但他願意說出自己的意見：

第一學期不用 AI。 至少要讓學生能讀 code、理解控制流、大致知道程式在幹嘛。
CS0：介面設計入門，主修非主修都上。 教的是怎麼描述輸入與輸出、怎麼設計結構與介面：什麼時候用 checkbox、什麼時候用 radio button、命令列參數怎麼組合。目的是就算你這輩子只上過這一堂課，你用 AI 拼出來的東西至少設計語言是通的、合用的。（他住的大樓洗衣房 app 把選單當按鈕用，每次用都讓他抓狂。）
往專案與團隊走，但順序要對。 先讓學生想解決一個比較大的問題，再給他們需要的背景知識，例如網路怎麼運作、遠端 API 怎麼呼叫。他的原則是：你不能給一個人他還不知道自己有的問題的解法。 在他們需要之前，所有理論都只是瑣碎知識，孤立的、學術的、和任何東西都不相連的。
大量專案，而且作業不能有標準答案。 因為業界不是那樣運作的，研究也不是。
成績的一部分來自對他人作品的 critique。 看別人的成果或程式碼，能不能說出「這很好，但你有沒有想過這裡可以換個做法」。而且要評你能不能給回饋又不當混蛋，因為心理安全與團隊合作。這聽起來工作量很大，但可以用 AI 做情緒分析之類的輔助。

他的擔憂是：這樣的課程最後會出現在軟體工程系，而不是 CS 系。

主持人也提出自己的想法：一個軟體工程學位，為什麼不從第一天就開始做軟體？第一門課做一個軟體，第二門課和團隊一起做，第三門課擴充它，第四門課再擴充。他自己讀 CS 時，四年裡只有一門團隊實作課，進入業界後感覺像從零開始。Titus 同意要更多專案，但提醒：多數學位只有一門專案課是個問題，而且那種「所有人背景完全一樣」的團隊，給了學生對團隊合作錯誤的印象。

給新人的四個建議

主持人問：對現在正在念書、或剛進入一個競爭更激烈的就業市場的人，有什麼具體的建議？Titus 先說，「學好基礎」這個建議本身就有問題，因為沒有人同意什麼是基礎。他引用 Kent Beck 的話：現在還在工作的每個人，都是在一個「有 playbook」的時代長大的，至少理論上我們知道正確的做法是什麼。但現在沒有 playbook 了，大家都得習慣不知道答案。在這個前提下，他給了四個建議。

一、別讓自己變成一支 shell script

如果你做的事只是把 ticket 貼進 prompt，然後把結果提交，那你可以被一支很小的 shell script 取代，這不是你留在公司的理由。

正確的用法是：用 AI 來提升自己、擴大你的輸入，而不是直接用它產生你所有的輸出。他提到一個現象：最好的學生因為 AI 而變得比歷史上任何時候都強，因為他們把它當作一個無限耐心的家教。差別不在工具，在你怎麼用它。

二、斧頭不砍樹，是你砍的

他借用一個比喻，叫「Andrew 的斧頭」：如果我拿斧頭砍倒一棵樹，我不會說是斧頭砍倒的，是我砍倒的。AI 再怎麼被擬人化，它仍然是工具。

他引用 1979 年 IBM 的一份訓練手冊：電腦不能被究責，所以電腦不應該做管理決策。今天的 AI 仍然不能被究責，AI 公司也不會為它的錯誤賠償你。所以：掛著你名字的那個 pull request，你必須能為它負責。 這需要更多嚴謹、更多對細節的注意，不能抄捷徑。而這種態度，他認為是最難訓練的。

三、不要做所有人都在做的事

他說這可能有風險，但他人生大部分的成功都來自不做別人都在做的事。如果你只是追著當下最熱門的話題、和所有人一樣追逐同一個閃亮的東西，你幾乎不可能被看見。

找一件你真正在乎的事情投入時間，尤其是比身邊的人更怪的事情。這樣你才有一個獨特的故事可以講給面試官聽，在雞尾酒會上才值得被搭話，某個創業者才會說「我想賭這個孩子一把」。而且你投入越多時間，帶來的專業深度就越高。

四、領域深度會取代原始工程技能

他有一個擔憂：在 AI 輔助工程的時代，業界對原始工程技能的重視正在下降，因為你可以靠更少的工程深度就把事情做出來。那要用什麼補上？唯一的答案是對問題領域的深層理解。

這可能導致一個後果：業界的流動性會降低。過去你會說「我是 C++ 工程師」、「我是後端工程師」，未來更可能是「我是嵌入式音訊領域的工程師」。你對那個領域的理解，才是你真正的優勢。

結語：把人的注意力留給真正需要人的地方

回頭看這七堂課，它們其實在講同一件事。

Google 用測試取代恐懼，讓工程師可以放心改。重構團隊用確定性工具取代手工，讓 12 個人可以改 2.5 億行。Uber 用 lint 規則取代重複的 code review，讓教訓只需要學一次。Readability 計畫把審查變成教育，讓知識在數萬人之間流動。DORA 的研究證明，文化比任何技術指標都更能預測成功。四種影響的框架指出，AI 的價值不在把舊事做快，而在做以前不敢做的事。而教育的出路，是停止評分那個可以被偽造的產出物，改評那個無法被偽造的過程。

每一堂課的結構都一樣：找出哪些事可以被規則、工具、系統接手，接手掉它，然後把人類有限的注意力留給真正需要判斷、需要學習、需要信任的地方。

AI 沒有改變這個原則，它只是讓「可以被接手的事」突然變多了。於是那個問題變得更尖銳：你留下來做的，是不是真的需要你？

主持人在結尾的總結是，沒有人知道什麼會有效，但讓更多業界的人參與 CS 與軟體工程課綱的更新，看起來是正確方向的一步。Titus 推薦的書是 Cat Hicks 的《The Psychology of Software Teams》，他說如果能把其中幾個章節直接下載到每一位領導者的腦袋裡，他會非常開心。

本文整理自《The Pragmatic Engineer》Podcast 對 Titus Winters 的訪談。Titus Winters 是《Software Engineering at Google》的主要作者，前 Google Readability 計畫負責人，現任 Adobe 資深 Principal Engineer。