PPO 發明者的 AI 使用哲學：讓模型幫忙，但要理解每一行程式碼

本文整理自 Cursor Podcast 對 John Schulman 的訪談。

John Schulman 發明了 PPO 演算法——這是目前大型語言模型 RLHF 訓練的核心技術。他是 OpenAI 共同創辦人，領導強化學習研究多年。如果有人有資格談「頂尖 AI 研究者如何使用 AI」，那就是他。

這場訪談中，他分享了自己的工作流程，以及一個看似矛盾的堅持。

先搞懂：什麼是 PPO？什麼是 RLHF？

在進入 Schulman 的工作哲學之前，值得花點時間理解他發明的東西有多重要。

想像你在教一隻狗。狗做對了，你給零食；做錯了，你不給。久了，狗學會什麼行為會得到獎勵。這就是**強化學習（Reinforcement Learning, RL）**的基本概念：透過獎勵和懲罰，讓 AI 學會做出「好」的行為。

但教 AI 比教狗難多了。AI 的「行為空間」巨大無比——一個語言模型在每個字都有幾萬種選擇，一篇文章下來就是天文數字的可能性。如果 AI 每次學習都大幅調整自己的行為，很容易「學歪」，像是一個本來會走路的人，學了新東西之後反而連走路都忘了。

**PPO（Proximal Policy Optimization，近端策略優化）**就是 Schulman 在 2017 年提出的解法。它的核心概念是「小步快跑」——每次學習只允許 AI 做小幅度的調整，確保不會一次改太多而崩壞。就像教小孩寫字，你不會期待他一天從不會寫變成書法家，而是每天進步一點點，穩穩地往前走。

那 **RLHF（Reinforcement Learning from Human Feedback，從人類回饋學習的強化學習）**又是什麼？

ChatGPT 之所以好用，不只是因為它讀了很多書。關鍵在於它經過「人類偏好」的調教。OpenAI 請了一群人來評分：給 AI 兩個回答，問「哪個比較好？」。這些人類偏好的資料，就被拿來訓練 AI，讓它學會產出「人類覺得好」的回答。

但要怎麼把「人類覺得好」這種模糊的概念，變成 AI 可以學習的訊號？這就是 RLHF 的工作。而 PPO 就是 RLHF 裡面負責「實際調整 AI 行為」的核心引擎。

打個比方：如果 RLHF 是一間駕訓班，PPO 就是那個教練。教練的工作是根據學員的表現（人類回饋），一點一點調整學員的駕駛習慣，既不能太保守讓學員學不到東西，也不能太激進讓學員養成壞習慣。PPO 的精妙之處，就是在這兩者之間找到平衡。

ChatGPT、Claude、Gemini，這些你每天在用的 AI，背後都有 PPO 的影子。可以說，沒有 PPO，就沒有今天的聊天機器人革命。而 Schulman 就是發明這個演算法的人。

Schulman 如何使用 AI

他每天大量使用 AI。寫程式時，他用 Cursor（內建 AI 的編輯器）和 Claude Code。做研究時，有想法就直接丟給 GPT-5 Pro 做文獻搜尋，或是寫一兩段模糊的想法讓模型幫忙展開。找開源程式庫、迭代發展想法，這些他都仰賴 AI。寫作時，他把草稿給聊天模型當作第一輪反饋——大部分思考還是自己做，但模型是好用的迴音板。

他特別強調文獻搜尋能力：「以前找相關文獻要花很多時間，現在快多了。」

研究筆記本在 LLM 時代更重要

Schulman 在 2020 年寫過一篇關於有效研究的部落格文章，提到保持研究筆記本、透過大量閱讀論文培養品味等建議。他說這些建議現在仍然適用，但有一個變化：

「保持研究筆記本現在可能更有用了，因為我們有 LLM。Context 非常重要。如果你想要對你正在做的事情獲得好的反饋，你可以把筆記本貼給 LLM，就能得到反饋。」

這是個微妙但重要的洞見。LLM 的品質高度依賴 context。有組織的筆記本，讓你能提供更好的 context，獲得更有用的反饋。

關鍵堅持：理解每一行程式碼

但 Schulman 也提出一個重要警告。

他說 AI 輔助寫程式在一般軟體工程領域可能有效——定義規格，讓模型實作。但研究不同：

「我認為對研究來說，知道每一行程式碼究竟在做什麼是有很大價值的。做出最好成果的人，真的對整個系統有那樣的理解——一直到最底層的細節。」

這與當前「讓 AI 幫你寫完整個實作」的風潮形成對比。他的邏輯是：研究的本質是理解和發現，如果你不理解程式碼在做什麼，你就不理解實驗在做什麼，不理解實驗就無法做出真正的洞見。最好的研究者對系統有完整理解。

這不是說不用 AI，而是說 AI 輔助的方式要對。讓 AI 幫忙加速你理解的過程，而不是讓 AI 替代你的理解。

他的一天：咖啡廳、筆記本、執行

Schulman 描述自己的研究日常。在想法形成階段，他喜歡去咖啡廳，周圍有背景噪音，帶著咖啡和筆記本，記下想法，排除干擾。到了執行階段，如果自己動手就是寫程式，但他也花大量時間閱讀文件、他人的訊息、看圖表和程式碼。現在做很多研究指導，主要是 review 他人的工作。

這種「分階段」的工作方式值得注意。想法形成需要空間和安靜（即使是咖啡廳的背景噪音那種安靜），執行需要專注和細節。

我的觀察：什麼時候該理解，什麼時候該放手

Schulman 的「理解每一行程式碼」聽起來很 hardcore，在 2026 年幾乎像是反潮流。但仔細想，他區分的是兩種不同的工作。

一種是需要深度理解的工作：研究、核心產品邏輯、會影響關鍵決策的程式碼、你需要能 debug、能改進、能解釋的東西。另一種是不需要深度理解的工作：樣板程式碼、一次性腳本、標準化的串接、別人定義好規格的實作。

問題是：大多數人把前者當成後者處理。

當你讓 AI 寫了大量你沒讀過的程式碼，你其實是在累積技術債——不是程式碼的技術債，而是理解的技術債。這個債會在最意想不到的時候爆發：debug 時不知道從哪裡下手，需要改動時不知道會影響什麼，向他人解釋時說不清楚，做決策時缺乏直覺。

Schulman 的建議不是「不要用 AI」，而是「用 AI 的方式要對」。

每次讓 AI 寫完一段程式碼後，問自己三個問題：我能向別人解釋這段程式碼在做什麼嗎？如果出 bug，我知道從哪裡開始找嗎？如果需要改動，我知道會影響什麼嗎？如果三個問題都答不出來，你可能需要花時間理解它——或者重新寫一個你理解的版本。

讓 AI 加速你的理解，而不是替代你的理解。

這是 PPO 發明者給我們的提醒。