---
schemaVersion: 1
slug: mp-212-20260326-semianalysis-disaggregated-planning
ticketId: MP-212
lang: zh-tw
title: 分離式規劃：為什麼最強的推理模型不一定是最好的寫扣仔？
summary: SemiAnalysis 認為，agentic coding 也可能像 disaggregated prefill 一樣，把 planning 與 execution 分開處理。若 spec 寫得夠好，較便宜的模型或許就能負責 execution，降低成本。
originalDate: 2026-03-26
translatedDate: 2026-03-26
source: "@SemiAnalysis_ on X"
sourceUrl: https://x.com/SemiAnalysis_/status/2036971501736317197
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-212-20260326-semianalysis-disaggregated-planning
status: published
replacementTicketId: null
replacementUrl: null
---

# 分離式規劃：為什麼最強的推理模型不一定是最好的寫扣仔？

> **來源:** [@SemiAnalysis\_ on X](https://x.com/SemiAnalysis_/status/2036971501736317197)

想像一下這個場景：一間餐廳，主廚米其林三星，一道菜收三千塊。結果老闆叫這位三星主廚去切洋蔥、洗碗、擦桌子。刀工世界第一，沒錯——但切洋蔥真的需要世界第一的刀工嗎？

@SemiAnalysis\_ 最近在 X 上拋出了一個想法，本質上就在問這件事：[agentic coding](https://gu-log.vercel.app/glossary#Agent) 的世界裡，最貴的模型是不是也在「切洋蔥」？

> **Mogu 內心戲：**
>
> 講到主廚切洋蔥——這個比喻放到 AI agent 圈更諷刺。目前主流做法是一個 model 從頭幹到尾：讀 codebase、想架構、寫 code、跑 test、修 bug，全部同一顆腦袋。這就像叫建築師畫完藍圖之後繼續蹲在工地砌磚頭。不是不行，但那雙手未免太貴了 (¬‿¬)

---

## 拆開看：Prefill 先做到了

故事要從 LLM inference 的架構演進講起。在推論那邊，有個技術叫 disaggregated prefill——把 compute-heavy 的 prefill 階段跟 memory-bound 的 decode 階段拆到不同的硬體上跑。為什麼要拆？因為這兩個階段吃的資源 profile 完全不一樣，綁在一起反而互相拖後腿。

SemiAnalysis 說：等一下，寫程式不也是這樣嗎？

> **Mogu murmur：**
>
> 這個類比有意思，但也有點危險。Prefill 跟 decode 的拆分是 well-defined 的工程問題——input tokens 跟 output tokens 的計算特性完全不同，拆法很明確。但「planning」跟「execution」的邊界在哪？一個 spec 要寫到多細才算「夠好」？這不是硬體層級的 clean cut，更像是在問「建築藍圖要畫到多細，工人才不會砌歪」——答案是 it depends，而且 depends 的東西多到可以再寫三篇 (╯°□°)╯

---

## 真正的洞見：不是「誰比較強」，是「強在哪裡不一樣」

推文裡最關鍵的一句話：**planning 和 execution 是不同的 cognitive tasks，偏好的模型 profile 也不一樣。**

這句話表面上很直覺，但仔細想想其實在挑戰一個根深蒂固的假設——「推理越深的模型，寫 code 就越好」。SemiAnalysis 的反駁是：深度推理對 planning 很重要，但 execution 需要的可能是另一組能力（速度、穩定性、對 boilerplate 的熟練度）。一個能花五分鐘想清楚架構的模型，不代表適合花兩小時逐行把 code 打出來。

原作者的示意很直白：`Opus architects, Sonnet/Codex builds.` —— [Opus](https://gu-log.vercel.app/glossary#Opus) 負責想，Sonnet 或 [Codex](https://gu-log.vercel.app/glossary#Codex) 負責做。（這裡的 [Codex](https://gu-log.vercel.app/glossary#codex) 是 OpenAI 2025 年重新啟用的 agentic coding 產品名，不是 2021 年那個已下架的舊模型——[glossary 有完整拆解](https://gu-log.vercel.app/glossary#Codex)。）

> **Mogu 內心戲：**
>
> 老實說，這個分工模型聽起來很美，但 SemiAnalysis 跳過了最難的部分：**handoff 的 fidelity**。Opus 想出來的 plan，Sonnet 真的能 100% 忠實執行嗎？還是會在 interpretation 階段引入微妙的 drift？這就像把設計師的 Figma 丟給外包工程師——理論上 pixel-perfect，實際上總是有那麼幾個按鈕歪了 3px。Plan 越抽象，execution 的自由度越高，結果偏離的機率也越大。所以真正的瓶頸不在於「能不能拆」，而在於「拆了之後 plan 要寫到多精確」。

---

## 但等一下——那張帳單

推文裡丟出了一個很有殺傷力的數字對比：如果一個 $3/M tokens 的模型就能完美執行一份寫得夠好的 spec，那何必燒 $15/M tokens 讓大模型做苦工？

五倍的價差。同樣的 output。

這就是 disaggregated planning 的核心賣點：不是說大模型不好，而是大模型的能力在某些階段是 overkill。就像請了一位律師來寫合約——值得；但請同一位律師每天來影印合約副本？那叫浪費。

> **Mogu 補個刀：**
>
> 「$3 就能完美執行一份寫得夠好的 spec」——這個「寫得夠好」四個字做了很多重量訓練。[Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 之前在[聊 agentic engineering patterns](https://gu-log.vercel.app/posts/gp-80-20260223-simonw-agentic-engineering-patterns) 的時候就講過：寫 code 變便宜了，但寫「好的 spec」還是很貴。所以 SemiAnalysis 的省錢論述有個弔詭的前提——省 execution 的錢，前提是在 planning 階段花更多錢（或時間）把 spec 寫到夠精確。省下的五倍價差，有多少會被吃回去？這筆帳沒有推文裡寫的那麼簡單 ┐(￣ヘ￣)┌

---

## 結語

回到那間餐廳。SemiAnalysis 這則推文真正在問的問題不是「該用哪個模型」，而是更根本的：**寫程式這件事，到底有幾種不同的「認知工作」在裡面？** 一旦拆清楚了，每種工作配一個最適合的工具，自然就不用讓三星主廚切洋蔥。

不過，拆得漂亮是一回事，拆了之後兩邊能不能接得回來——那才是真正的硬仗 (๑•̀ㅂ•́)و✧