他一天提交 40 個 Pull Request，不是因為他打了雞血，而是因為他已經學會了如何跟 AI 合體。
這不是科幻小說，這是 2026 年頂尖工程師的日常。當你還在為一個 bug 掙扎半天，當你的團隊還在用傳統的 code review 流程，這位名叫 Kun Chen 的前 Meta L8 工程師已經像指揮交響樂團一樣，同時調度好幾個 AI Agent，讓它們各自負責不同的程式碼模組，然後像流水線一樣，把一車一車的 PR 推到 GitHub 上。
你以為 AI 會取代工程師？錯了。真正殘酷的現實是：懂 AI 的工程師正在取代不懂 AI 的工程師。 而 Kun Chen 的故事，就是這個新時代最赤裸裸的縮影。
我花了點時間看完了 Peter Yang 對 Kun Chen 的專訪，老實說，看完之後我沉默了五分鐘。不是因為技術太難，而是因為這個世界變化的速度，已經遠遠超出了大多數人的想像。這篇文章，我將從這場對話中，提煉出 7 個最令人震撼、最反直覺、同時也最具實戰價值的核心要點。準備好了嗎？讓我們直接拆解這位「AI 時代的極限工程師」到底是怎麼煉成的。
1. 他是誰？——從 Meta L8 到「AI 驅動的獨角獸」
在開始談技術之前，我們得先搞清楚，坐在對面的這個人有多狂。Kun Chen，前 Meta L8 工程師。在 Meta 的職級體系中，L8 是什麼概念？那是 Director 級的工程師，是那種可以主導一個數百人團隊技術方向的人，年薪通常落在 150 萬到 300 萬美金之間。
但他選擇在巔峰時期離開，創辦了 Tennr——一家用 AI 來處理醫療文件的公司。這不是那種「我們用 AI 做點小工具」的創業，而是直接切入美國醫療體系最痛、最官僚、最繁瑣的 paperwork 環節。他的目標很明確：用 AI Agent 取代人類處理那些令人崩潰的表單和審批流程。
而最瘋狂的是，他一個人，在創業初期，靠著 AI 輔助，每天能提交 40 個 PR。這不是團隊作戰，這是一場一個人搭配數十個 AI 助理的閃電戰。他的存在本身，就在重新定義「工程生產力」的天花板。
2. 40 個 PR 的祕密：不是寫得快，而是「拆得細」
你可能會想，一天 40 個 PR？這是在刷 KPI 吧？程式碼品質能看嗎？這是最常見的誤解。Kun Chen 的做法，恰恰是反直覺的：他提交 PR 的頻率越高，他的程式碼就越安全。
傳統的開發模式是：一個工程師花三天寫一個巨大的 PR，裡面改了 2000 行 code，然後丟給 reviewer。reviewer 看到這種 PR 頭就痛，隨便掃兩眼就 approve 了，因為根本沒人看得懂這麼大規模的改動。這才是災難的來源。
Kun Chen 的做法完全相反。他利用 AI Agent，將一個大型功能拆解成數十個極小、極原子化的步驟。每一個 PR 只做一件事：重構一個 function、新增一個測試、修改一個變數名稱。每一個 PR 的改動量可能只有 10 到 30 行 code。
為什麼這樣更快？ 因為當 PR 夠小的時候，AI 可以完全勝任 code review 的工作。他不僅讓 AI 幫他寫 code，還讓 AI 幫他審查 code。每一個小 PR 通過 AI review 後，就立刻合併。這就像在做微積分，你把一個複雜的問題切成無數個微小的矩形，然後計算每個矩形的面積，最後加總。這個過程雖然步驟很多，但每一步都是確定且低風險的。
「當你有一個巨大的 PR，你根本不敢讓 AI 去審查，因為它會錯過很多東西。但當你的 PR 只有 10 行 code，AI 可以完美地理解並審查它。」
這是一個至關重要的洞見：生產力的瓶頸從來不是寫 code 的速度，而是審查和整合 code 的速度。 Kun Chen 用 AI 打通了這個瓶頸，所以他一個人就能跑完一條完整的生產線。
3. 他不是在「寫」程式，而是在「指揮」AI
這裡有一個你必須理解的觀念轉變。Kun Chen 在訪談中提到，他現在的工作模式已經不是「坐在電腦前打字」，而是「像一個指揮官，同時管理好幾個 AI Agent」。
他的開發環境是這樣的：
- 他會用 Cursor（一個 AI 原生 IDE）同時打開好幾個分頁。
- 每個分頁都對應一個獨立的 AI Agent，負責不同的任務。
- 他會對 Agent A 說：「幫我重構這個 module，把這些 function 獨立出來。」
- 然後轉頭對 Agent B 說：「幫我為這個新 API 寫 unit test，要涵蓋 edge case。」
- 再對 Agent C 說：「幫我 review Agent A 剛剛產出的 PR，檢查有沒有 side effect。」
他做的不是 coding，他做的是 task decomposition（任務分解） 和 quality control（品質控制）。他將自己的大腦從「實作細節」中解放出來，專注於更高層次的架構設計和策略判斷。
這聽起來很抽象，但你可以把它想像成一個餐廳主廚。傳統的工程師是那個親自切菜、炒菜、擺盤的廚師。而 Kun Chen 現在是那個站在廚房中央，指揮三個副主廚各自負責熱菜、冷盤和甜點的人。他不再親自炒菜，但他確保每一道菜出來的味道都是對的。
這才是 AI 時代工程師的真正進化方向：從「勞動者」變成「管理者」。
4. 為什麼 Cursor 比 Copilot 更適合這種極限工作？
在訪談中，Kun Chen 毫不掩飾他對 Cursor 的偏愛。他認為 Cursor 的「Agent 模式」是目前市面上最適合這種高強度、多線程開發的工具。
為什麼？關鍵在於 Context（上下文） 的管理。
GitHub Copilot 很棒，但它更像是一個聰明的「自動補完」工具。你給它一個 prompt，它給你一個 suggestion。它缺乏對整個專案結構的長期記憶和主動規劃能力。
而 Cursor 的 Agent 模式，可以讓你在同一個對話中，建立一個持續存在的「工作記憶」。你可以對它說：「我們正在做專案的 X 部分，現在需要完成 Y 任務，請先閱讀這三個檔案，然後根據我們之前討論過的架構原則來實作。」
這個 Agent 會記住你的偏好、你的 coding style、你專案的架構。它不再是一個被動的工具，而是一個有「短期記憶」的初級工程師。
Kun Chen 甚至提到，他會在同一個 Cursor 視窗中，為不同的 Agent 設定不同的「角色」。例如：
- Agent Alpha：負責核心邏輯，要求程式碼極度精簡，不允許任何多餘的註解。
- Agent Beta：負責測試，要求它必須考慮所有可能的錯誤情況，並寫出詳盡的測試案例。
- Agent Gamma：負責文件，要求它用最白話的方式解釋 code 的功能。
這種「角色分工」讓 AI 的輸出品質大幅提升。因為你不再是對一個萬能的 AI 下指令，而是對一個「專注於某個領域」的 AI 下指令。這就像在一個團隊裡，你不會叫後端工程師去畫 UI，也不會叫前端工程師去調資料庫。
5. 最反直覺的觀點：AI 讓「寫註解」這件事變得過時了
這是我覺得整場訪談中最顛覆常識的一點。我們從小被教育，好的程式碼要有好的註解。但在 Kun Chen 的 workflow 裡，註解的重要性正在急遽下降。
為什麼？因為 AI 讀 code 的能力遠超人類。我們人類需要註解來理解一段複雜的邏輯，但 AI 不需要。AI 可以直接閱讀 code 的語法樹，理解變數的流向，判斷 function 的意圖。
他提出了一個大膽的論點：與其花時間寫註解給人類看，不如花時間把程式碼寫得更「語義化」，讓 AI 更容易理解。
這具體是什麼意思？
- 變數命名要極度精確：不要用
data，要用processedPatientClaimData。 - Function 要極度單一：一個 function 只做一件事，並用 function 名稱清楚描述。
- 型別系統要極度嚴格：用 TypeScript 的複雜型別來約束資料結構，而不是依賴註解來說明「這個欄位是日期格式」。
當你的 code 本身就是一份「可執行的文件」時，註解就變得多餘了。而這恰好是 AI 最擅長處理的領域。AI 可以完美 parse 你的型別定義和 function signature，然後據此產生正確的邏輯。
這是一個有趣的迴圈：AI 的崛起，反而逼著人類工程師寫出更乾淨、更嚴謹的 code，因為只有這樣的 code，AI 才能有效地協助你。
6. 醫療文件的「屎山」：為什麼人類做不好，AI 卻可以？
Kun Chen 的公司 Tennr 選擇了一個聽起來很無聊，但實際上極度有價值的領域：醫療文件處理。美國的醫療系統，每年花費數千億美元在處理 paperwork。醫生花在填寫病歷、申請保險理賠的時間，比花在看病人的時間還多。
為什麼這個問題這麼難解決？因為醫療文件不是結構化的資料庫，它們是充滿了混亂、模糊、不一致的「文本垃圾」。同樣一個「心臟病發作」，在不同的文件裡可能被寫成 "MI"、"Myocardial Infarction"、"Heart Attack"。同樣一個病人，名字可能被拼錯，地址可能不完整，保險資訊可能過期。
傳統的軟體工程師看到這種問題會頭痛，因為它需要寫大量的 if-else 規則來處理各種例外情況，這根本是無底洞。但對於大型語言模型（LLM）來說，這正是它的主場。LLM 天生就是為了解決這種「模糊語義匹配」而生的。
Kun Chen 的團隊用 AI Agent 來模擬人類處理文件的流程：
- Agent 1：先掃描文件，辨識這是什麼類型的文件（病歷？帳單？保險理賠申請？）。
- Agent 2：從文件中提取關鍵資訊（病人姓名、診斷碼、日期、金額）。
- Agent 3：將提取的資訊與現有資料庫進行比對，找出不一致的地方。
- Agent 4：如果發現錯誤，自動發送 email 給相關人員請求修正。
這整個流程，過去需要一個團隊的行政人員花好幾天來完成。現在，Kun Chen 的 AI Agent 可以在幾分鐘內搞定，而且錯誤率更低。這不是取代人類，這是在把人類從地獄般的重複勞動中解放出來。
7. 給所有工程師的警鐘：你剩下的「護城河」是什麼？
這是最後、也是最殘酷的一個要點。Kun Chen 在訪談中，其實已經暗示了一個所有工程師都必須面對的現實：你的 coding 能力正在快速貶值。
當一個 AI Agent 可以在幾秒鐘內寫出一個標準的 CRUD API，當它可以自動產生 90% 的 unit test，當它可以幫你 review code 並指出潛在的 bug，那你作為一個工程師，你獨一無二的價值到底在哪裡？
Kun Chen 給出的答案是：「品味」和「系統思維」。
- 品味：知道什麼樣的 code 是好的，什麼樣的架構是優雅的，什麼時候該重構，什麼時候該將就。AI 可以寫出功能正確的 code，但它無法判斷這個 code 在五年後是否還能維護。這種對「長期成本」的判斷，目前還是人類的強項。
- 系統思維：理解你的 code 在整個商業系統中的位置。知道為什麼這個 feature 比那個 feature 重要，知道如何將一個模糊的商業需求轉化為一個可執行的技術方案。AI 可以理解你的指令，但它無法理解你公司的商業策略。
未來，最值錢的工程師，不是寫 code 最快的人，而是最能定義「該寫什麼 code」的人。
如果你現在還在沾沾自喜於自己打字速度很快、背了很多框架 API，那你真的要小心了。AI 正在把你的「硬技能」變成一個大家都能用的公共設施。你的護城河，必須建立在那些 AI 難以複製的「軟技能」上：溝通、判斷、領導、以及對人性的理解。
核心觀點匯總
為了讓你一目了然，我把 Kun Chen 的核心觀點和傳統開發模式做了一個對比：
| 面向 | 傳統開發模式 | Kun Chen 的 AI 驅動模式 |
|---|---|---|
| PR 策略 | 大 PR，週期長（3-5天），改動量巨大 | 小 PR，高頻率（一天40個），每次只改 10-30 行 |
| Code Review | 依賴人類 reviewer，耗時且容易遺漏 | 依賴 AI Agent 進行快速、精準的審查 |
| 開發工具 | 傳統 IDE (VSCode)，Copilot 作為輔助 | Cursor Agent 模式，同時管理多個 AI 角色 |
| 程式碼風格 | 依賴大量註解來說明邏輯 | 強調「語義化命名」和「嚴格型別」，減少註解 |
| 工程師角色 | 勞動者：親自實作每一行程式碼 | 管理者：分解任務、指揮 AI、控制品質 |
| 核心價值 | 寫 code 的速度和正確性 | 系統思維、架構品味、商業判斷 |
| 適合領域 | 結構化、規則明確的系統 | 混亂、模糊、大量文本處理的領域（如醫療、法律） |
結語：你準備好成為 AI 的指揮官了嗎？
回到最開始的問題。當你還在抱怨 AI 寫的 code 不能用、當你還在抗拒學習新的 AI 工具時，已經有人用這些工具把自己武裝到了牙齒，一個人就能打一場仗。
Kun Chen 的故事不是一個特例，它是一個信號。它告訴我們，未來的軟體工程，不再是關於「人 vs 機器」，而是關於「懂機器的人 vs 不懂機器的人」。
那些能夠放下身段，學習如何跟 AI 協作，甚至像 Kun Chen 一樣，把 AI 當成團隊成員來管理的工程師，將在未來十年內佔據絕對的主導地位。而那些堅持「我寫的 code 才是最好的」、「AI 只是玩具」的工程師，將會發現自己越來越跟不上時代。
最後，留給你一個值得深思的問題：
如果今天開始，你每天的工作不再是寫 code，而是指揮一群 AI Agent 幫你寫 code，你覺得你的第一個指令會是什麼？
想清楚這個問題的答案，或許就是你職業生涯中，最重要的一次升級。