Shopify CTO 帕拉欣親解：無上限 token、Opus 4.6 地板，當 AI 工程量月增 30%，PR review 才是真正的瓶頸

本文整理自 Latent Space 2026 年 4 月播出的單集，受訪者為 Shopify 技術長帕拉欣（Mikhail Parakhin）。他在加入 Shopify 前，是微軟（Microsoft）旗下含 Bing、Edge、Ads、Windows 在內事業群的執行長，更早之前在俄羅斯網路巨頭 Yandex 主導機器學習與 Alice 數位助理。原始單集約 110 分鐘。

{{< youtube RrkGoX3Cw7o >}}

---

12 月相變：當「至少用一個 AI 工具」變成全員日常

訪談一開始，Latent Space 主持人 Swyx 在螢幕上叫出 Shopify 內部的工具採用曲線，畫面上顯示一條最深綠的「總和線」幾乎已經貼到 100% 的軸線。帕拉欣指著這條線說，這是公司每天有多少比例的工作者會用到至少一款 AI 工具，到今天為止已經逼近全員。要不開那些工具還能完成日常工作，幾乎不可能。

讓他特別停下來解釋的，是 2025 年 12 月那條斜率突然陡起的轉折。他用「相變」（phase transition）這個詞來形容當時的觀察：先前一年模型每隔幾週都有一點小進步，使用者體感不太強烈，但這些零散的改善堆疊到 12 月就突然跨過了某個門檻，整條線從緩慢爬升變成爆炸性成長。「很多人那時候都注意到一樣的事情，」他說，這不是 Shopify 自己的特例，而是整個業界共同感受到的拐點，只是 Shopify 內部資料把它畫得特別清楚。

更值得玩味的是這條線下方的細部結構。帕拉欣請大家注意紅色那條代表 IDE 類工具（如 Cursor、GitHub Copilot）的曲線，它沒有萎縮，但成長明顯比藍色那條 CLI 工具線（包含 Claude Code、Codex、Pi、Shopify 自家代號為 River 的內部 agent）平緩許多。換句話說，當 AI 真的進入工作流之後，員工偏好的是「不用一直盯著程式碼」的工具，而不是內嵌在編輯器旁邊的 autocomplete。對於正在押注 IDE 體驗的工具公司，這條對比線是一張很硬的訊號。

「天花板拆掉，地板拉高」：Shopify 怎麼治理員工燒 token

接下來的對話，幾乎每個臺灣的技術主管都該抄筆記。Swyx 直接問帕拉欣：Shopify 是怎麼控制員工的 token 用量？帕拉欣的回答很直白：「我們其實是給每個人不限額度的 token，員工想用什麼工具自己挑，公司全額支付。」這聽起來像是放任，但下一句才是重點：「我們確實會控制大家用什麼模型，但管法是從下面、不是從上面。」

這個「從下面控制」的具體做法，他用了一個讓 Swyx 笑出來的句子來描述：「拜託不要用比 Opus 4.6 更小的模型。」也就是說，Shopify 不設一個「每人每月最多燒多少錢」的天花板，反而設了一個「最低也得用這個等級」的地板。在這個地板之上，有些人選 Opus 4.6，有些人選 GPT-5.4 extra-high，也有人為了 100 萬 token 的長上下文選別的選項，公司不干預。但低於 Opus 4.6 的便宜小模型，是被內部明確勸阻的。

這套邏輯反過來思考會更清楚。多數企業面對 AI 預算焦慮，第一反應是設「每人每月不超過 X 美元」這種天花板，目的是控制總帳。但帕拉欣的判斷正好相反：這個階段限制 token 用量，最大的成本不是金流，而是員工錯過練習的機會、最後產出垃圾程式碼。他寧可讓全員放手用，但用就要用最強的模型，因為小模型寫出來的東西進到 production，後續修 bug、回滾部署的成本遠高於那一點 token 費用。

當然這個策略也帶來新問題。Swyx 翻到下一張圖，是 Shopify token 消耗的分布。可以看到從 2025 年 12 月開始，整體用量呈現指數成長，但更值得擔心的是分布愈來愈偏斜：用最多 token 的前 10% 員工，成長率甚至比第 75 百分位還快。帕拉欣承認這讓他「感覺不太對勁」，因為把這個趨勢推到極端，就會變成「一個人燒掉全公司所有 token」。他坦白說目前還沒有完美解法，只能靠內部教育、案例分享，把那些已經「被 AI 賦能」的人的工作方法擴散到整個組織。

把 Jensen 那句「20 萬美元工程師應該燒 10 萬美元 token」翻譯成正解

Swyx 順勢拋出一個對所有 CTO 都有壓力的問題：輝達（NVIDIA）執行長黃仁勳到處在說「年薪 20 萬美元的工程師如果一年沒燒掉 10 萬美元 token，就是在低估 coding agent 的價值。」這句話聽起來像是賣鏟子的人在叫大家用力挖，但帕拉欣的回應出乎意料：他認為黃仁勳「方向上是對的」。

不過帕拉欣立刻把話接下去，說明關鍵不在 token 燒得多不多，而在燒得對不對。他從 Shopify 內部試錯總結出一條反 anti-pattern 的原則：最糟糕的 token 燒法，是同時開一堆平行 agent 各做各的事但彼此不溝通。這種設計乍看效率高，實際上幾乎沒用。每個 agent 都在自己那個 narrow 的子任務上跑得很開心，但組合起來的結果常常互相打架，最後產出比一個 agent 認真做完還差。

真正有效的模式，在他的描述裡是「critique loop」，也就是一個 agent 寫程式碼，另一個用不同模型的 agent 在後面挑剔、提出修改建議，原本的 agent 再依據那些回饋改寫一遍。這個流程刻意慢，因為兩邊得輪流發言，等下一輪就要等上一輪結束。但慢下來之後，產出的程式碼品質比平行燒 token 高出一個量級。帕拉欣說團隊成員一開始會抗拒這種延遲，因為人類習慣同時開很多視窗，但用一陣子之後就回不去了。

他在這段補了一句很值得放大來看的觀察：「現在的好模型寫程式，平均 bug 數比人類工程師低，這沒問題；但因為它寫得實在太多，所以最後進到 production 的 bug 總量還是會增加。」這句話精準解釋了一個讓很多公司困惑的悖論：每個 PR 看起來品質都不差，但部署環境的 bug 卻在攀升。原因不是模型寫得爛，而是它根本不會累，整個體系在生產量上跨了好幾個量級，後段的審查機制如果沒跟上，就只是把更多 bug 漏進去。

PR review 不是 Claude Code 的工作，是 GPT-5.4 Pro 與 Gemini Deep Think 的工作

順著這個邏輯，帕拉欣接下來談的就是 Shopify 內部最重要的一個工程指標：花在程式碼產生階段的 token 預算，跟花在 PR 審查階段的 token 預算之間的比例。在他眼裡，這個比例的合理性比總燒多少還重要。如果產生階段燒了 100% 的 token，審查階段只用 Cursor 順便幫忙看一下，這條 pipeline 注定會放一堆 bug 進 production。

Swyx 在這時候很尖銳地問了一句：你的內部圖表怎麼沒標出 Code Rabbit、Devin Reveal 這些公開的 PR 審查工具？帕拉欣承認這是他的「痛點」：他到目前為止沒找到任何一款公開工具長對了形狀，所以 Shopify 自己造了一套。問題在於 PR 審查的最佳形態，跟一般工程師對 coding agent 的直覺正好相反，也跟那些公司的商業模型對不起來。

他描述的最佳形態長這樣：用最大的 pro 級模型（如 GPT-5.4 Pro、Gemini Deep Think），讓它們慢慢輪流來看每一行 PR，token 用量其實不多，但延遲長到會讓開發者皺眉。這跟 Claude Code 或 Codex 那種「我跟你聊兩句、邊聊邊改」的互動模式完全不同。更不是 Code Rabbit 那種一開就是十幾個 agent 同時掃 PR 的 swarm 結構。「你想要的是少量 token 跑在貴模型上，慢慢輪流，」他說，「而不是一群便宜 agent 在那邊瞎搞。」

對於正在自建內部 PR 工具的臺灣技術團隊，這套標準是個有用的對照。如果你看到自家工具一開就跑出十幾個並發審查者，那大概就是抓錯了形狀。帕拉欣的判斷是，這個階段公開工具的市場需求還沒收斂，多數公司會像 Shopify 一樣在內部自建一陣子，直到形狀清楚了再來談標準化。

真正的瓶頸不是 PR 等多久，而是 CI/CD 撐不住

更深的洞察出現在後段。Swyx 提到他自己最受不了的就是 PR 等人類審查等一整週的折磨，相比之下他寧可給 pro 模型一兩小時去看。帕拉欣同意這個 trade-off，但他把整個討論再往上推了一層：到了 Shopify 現在的規模，等 PR 被審完根本不是最痛的瓶頸。真正卡住一切的，是 CI/CD 流水線開始撐不住整個組織級的程式碼產出量。

他把畫面切到另一張圖，PR 合併速率現在是每月 30% 的成長，從先前一段時期 10% 的速率明顯跳升。在這個曲線上每個 PR 還變得更複雜，因為人寫一個簡單功能會就此打住，AI 會順便重構、補測試、整理舊有結構。這意味著 CI 跑出來測試失敗的機率正比例攀升，每次失敗都得回頭找出闖禍的 PR、把它退出佇列、重跑一輪測試。當這套流程在每月 30% 的成長壓力下執行，整體部署週期會被拉得很長，比起多花一小時讓 pro 模型把 PR 看仔細，前者的時間成本還高出許多。

換句話說，「快速 PR」這個指標在 AI 時代會反過來坑你。表面上 PR 過得越快越好，但如果代價是更多測試在 CI 上炸掉，那帳算下來其實是負的。帕拉欣的結論很直接：應該把指標換成「整體部署到 production 的端到端時間」，從這個指標反推，慢慢用大模型把 PR 看完，反而是節省時間的做法。

微服務可能要回歸：當 AI 把 monorepo 變成全域 mutex

對話最後一段的轉折，連 Swyx 都笑出來。他問帕拉欣，現在很多人在抱怨「我們是不是該換掉 GitHub」，甚至更激進地問「git 本身、PR 這個概念，是不是都已經是 agent 時代的瓶頸？」帕拉欣的回答是這樣的：他這輩子都是「微服務的死忠反對者」，認為過去十年那波微服務化是工程上的歪路；但在 agent 時代他開始重新思考這件事。

他的論點是這樣展開的。今天 Shopify 用 Graphite 做 stacked PR，這已經比一般公司的工作流先進。但即使這樣，monorepo 加上 PR 流程在邏輯上等同於整個系統共享一把全域 mutex：每次合併衝突都得整支隊伍停下來等。當寫程式的是人類、速度本來就慢的時候，這把 mutex 不太礙事；但當寫程式的是不會累的 agent、輸出量乘以 10 倍 100 倍的時候，這把 mutex 就會把整個組織卡死。

這時候微服務那種「每個服務獨立 deploy、互相不阻塞」的架構，反而開始變得有道理。他特別提到 Google 的做法是 monorepo 但部署到微服務，加上 Netflix 的 Chaos Monkey，這套組合在 agent velocity 之下可能會被重新發明。帕拉欣自嘲說：「我曾經是這條路的死敵，現在卻在反過來想，會不會其實微服務就是正解。」這個自我顛覆，比任何結論都更值得記下來，因為這代表 AI 工程化會逼著我們重看很多十年前以為已經塵埃落定的辯論。

我的觀察：這份藍圖對臺灣團隊有什麼用

Shopify 的這份內部資料，最值得臺灣團隊抄走的不是「無上限 token」這個動作本身，而是它背後那套指標切換的邏輯。多數公司今天還在用「token 花了多少」、「每位工程師一天合幾個 PR」這類舊指標管理 AI 投入。Shopify 已經把指標切到「程式碼產生 vs PR 審查的 token 預算比例」、「整體部署到 production 的端到端時間」、「CI/CD 失敗率與重跑成本」。這個切換在組織內部需要管理層願意重新教育，但只要切過去，後續的決策幾乎都會變得清楚。

第二件值得抄的，是「critique loop」這個模式具體怎麼落地。對只有十幾個工程師的臺灣團隊，要立刻搭建 GPT-5.4 Pro + Gemini Deep Think 等級的 PR 審查線可能不切實際，但小一點的版本完全做得到：要求所有 AI 寫的程式碼，至少走一輪「不同模型來挑剔」的流程，產出方用 Claude Code，挑剔方用 Codex 或 GPT-5.4，反過來也行。這個動作在工具上不難設置，難的是工程師心態要從「平行多開比較爽」轉成「同一件事讓兩個模型輪流看」。

第三件，是面對「微服務是不是該回歸」這種架構辯論時，要願意像帕拉欣那樣推翻自己過去的判斷。AI 工程化會持續把「組織卡點」推到先前不敏感的層面，從 IDE 變 CLI、從 PR latency 變 CI/CD、從 monorepo 變部署架構，這些都不是工具升級的小事，而是工作流程設計的根本問題。能不能在每一輪變化發生時，誠實地問自己「以前的判斷在新條件下是不是反了」，會是 AI 時代技術主管最稀缺的能力之一。

最後一個小提醒，是對所有臺灣的 SaaS 與 AI 工程化新創。帕拉欣花了幾分鐘吐槽他找不到合用的公開 PR 審查工具，這其實是一個明確的市場缺口訊號：能用 pro 級模型、慢慢輪流、低 token 大延遲、聚焦在審查階段的工具，目前在公開市場還沒有強選手。誰能先把這個形狀做對，誰就會接住下一波企業 AI 工程化的需求。