--- schemaVersion: 1 slug: mp-188-20260317-semianalysis-vibe-coding-telephone-game ticketId: MP-188 lang: zh-tw title: Vibe Coding 真正猛的，可能不是寫得快，而是少了中間傳話 summary: SemiAnalysis 認為，Vibe Coding 真正推動採用的原因，可能不是單純把 code 寫更快，而是把領域專家和實作之間那串冗長的傳話鏈砍掉。推文同時也提醒，如果你自己都不清楚要什麼，LLM 一樣會高速做錯，而且上 production 前仍然需要真正的 engineer 把關安全性。 originalDate: 2026-03-17 translatedDate: 2026-03-17 source: "@SemiAnalysis_ on X" sourceUrl: https://x.com/SemiAnalysis_/status/2033679761952620646 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-188-20260317-semianalysis-vibe-coding-telephone-game status: published replacementTicketId: null replacementUrl: null --- # Vibe Coding 真正猛的，可能不是寫得快，而是少了中間傳話 > **來源:** [@SemiAnalysis\_ on X](https://x.com/SemiAnalysis_/status/2033679761952620646) 想像一個場景：你是醫院的放射科醫師，每天看幾百張影像，腦中早就知道「如果有一個小工具能自動標記這五種 pattern，我一天可以省兩小時」。但你想要這東西，得先跟 IT 部門提需求，IT 說要排隊，排到了再找外包，外包寫出來的東西跟你想的差了三條街。來回改了兩個月，你已經忘記自己當初想要什麼了。 SemiAnalysis 這則推文戳的就是這個痛點。而且它的觀點很妙 —— [Vibe Coding](https://gu-log.vercel.app/glossary#vibe-coding) 真正猛的，搞不好根本不是「寫 code 變快」。 等等，先別急著翻白眼說「又一篇 Vibe Coding 吹文」。這篇的角度跟你想的不一樣。 ## 傳話遊戲的代價 還記得小時候玩的傳話遊戲嗎？第一個人說「今天天氣真好，我想去海邊」，傳到第五個人變成「今天有人在海邊被好天氣打」(╯°□°)╯ 軟體開發的傳統流程，本質上就是一場超大型傳話遊戲。你腦中有一個很清楚的需求，但你得先講給 PM 聽，PM 消化完再寫成 spec，spec 丟給工程師，工程師理解完再寫成 code。每一次 handoff，context 就掉一點。不是誰的錯，就是人跟人之間的溝通頻寬有限，每次「翻譯」都會失真。 而且這個失真是累積的。第一層掉 10%，第二層再掉 10%，到最後出來的東西可能只剩原始需求的 60%。更慘的是，掉掉的那 40% 往往不是不重要的細節 —— 而是那些「只有你自己知道但講不清楚」的 tacit knowledge。你知道哪些 edge case 會出事，你知道哪些 workflow 是真的在用的，但這些東西寫不進 spec 裡，因為連你自己都不知道怎麼用文字描述它們。 > **Mogu 歪樓一下：** > > 這就像以前點餐要透過三個服務生轉述，現在你直接站在廚房門口跟廚師比手畫腳。溝通還是有，但失真少了一個數量級。而且你可以一邊看他炒，一邊喊「鹽太多了！」—— 這種即時 feedback loop，用 Jira ticket 是做不到的。之前 MP-95 寫過 Ramp 的 PM 在六週內就開始自己發 PR，那不就是最好的證明嗎？需求方直接動手，中間傳話的人整組消失 ┐(￣ヘ￣)┌ 原作者說的重點是：Vibe Coding 並沒有消滅 iteration —— 搞不好 iteration 次數比以前更多。但這些來回，不再發生在四層人與人之間，而是發生在「你」跟「你正在做的東西」之間。 這個差別，比表面上看起來大很多。 --- ## 那些「不值得做」的東西，突然值得了 但問題來了。原作者接著丟出一個我覺得更有殺傷力的觀察：很多 domain expert 腦中一直都有想做的工具，只是從來沒被做出來。 不是做不到。是溝通成本太高了。 你想做一個小工具，但走完「提需求 → 排期 → 外包 → 來回修改」這套流程的成本，比工具本身的價值還高。所以你就繼續用 Excel 湊合，繼續手動複製貼上，繼續忍。這不是技術問題，是經濟問題 —— 交易成本高到讓一堆有價值的小需求永遠過不了立項門檻。 想想看，全世界有多少放射科醫師、有多少律師、有多少會計師，腦袋裡裝著「如果有這個工具就好了」的念頭？這些人加起來，代表的是一個巨大的、從來沒被滿足過的 long tail 需求市場。不是因為技術不夠，是因為把需求從腦袋搬到螢幕上的成本太高了。 Vibe Coding 做的事情，就是把這個門檻一口氣拉低。那些以前「划不來」的工具，突然開始有機會被做出來了。 > **Mogu 內心戲：** > > 經濟學有個詞叫 transaction cost，Coase 老爺子當年靠這個拿了 Nobel Prize。他說公司存在的理由就是降低交易成本 —— 市場上找人做事太貴，所以乾脆雇人進公司。現在 LLM 又把另一層交易成本砍掉了，某種程度上，Vibe Coding 正在做 Coase 預言的事。只是 Coase 大概沒想到降低成本的是一隻會寫 code 的鸚鵡 (¬‿¬) 之前 MP-85 講 AI Vampire 的 $/hr 公式，本質上也是在算同一筆帳：當做事的成本趨近零，value capture 的規則就會整個翻盤。 --- ## 別高興太早：快不等於對 不過原作者沒有把話講成萬能解法，他很誠實地補了兩腳煞車。 第一腳：如果你自己都不知道要什麼，LLM 也不會幫你想清楚。它只會用誇張的速度，很開心地幫你蓋出一棟蓋錯方向的房子。快，不代表方向對。這就像你叫 Uber 叫得超快，但你根本不知道要去哪裡 —— 司機很盡責地載你狂飆，結果開到基隆去了。 > **Mogu murmur：** > > 我覺得這是整則推文最清醒的一句話。很多人在 demo Vibe Coding 的時候都在秀速度，但速度從來不是瓶頸 —— 方向才是。一個工程師花三天做對的東西，永遠比一個 LLM 花三分鐘做錯的東西有價值。速度是乘數，方向是被乘數。如果方向是零，你乘一萬倍出來還是零。還記得 MP-25 那篇 Cursor CEO 翻車的故事嗎？號稱用 AI 寫了整個瀏覽器，結果只是把 open source 拼拼湊湊 —— 速度很快，但方向從一開始就歪了 (◕‿◕) 第二腳：真正的 engineer 沒有被消滅。東西要上 production 之前，還是需要有人確認它是安全的、是可靠的、是不會半夜三點把你叫起來的。Vibe Coding 讓 prototype 變容易了，但 prototype 到 production 之間那段路，一點都沒有變短。 這兩腳煞車其實在回答同一個問題：Vibe Coding 降低的是「從腦袋到螢幕」的成本，但「想清楚要什麼」和「確保東西能活在 production」這兩頭的成本，一毛都沒少。 > **Mogu 畫重點：** > > Vibe Coding 就像 3D 列印讓你可以快速打樣一個零件，但你不會把 3D 列印的塑膠零件直接裝到飛機引擎上。打樣歸打樣，production 歸 production。MP-36 裡 Karpathy 從 Vibe Coding 升級到 [Agentic Engineering](https://gu-log.vercel.app/glossary#agentic-engineering)，講的也是這件事 —— 玩具階段結束了，現在要認真對待工程品質。把打樣跟量產搞混的人，遲早要在凌晨三點接到 PagerDuty (￣▽￣)／ --- ## 真正變了的，是你在跟誰吵架 好，拉回來看整件事。 如果你只記住一件事，記這個：重點不在「寫 code 快了幾倍」，而在於你吵架的對象換了。 以前你跟流程吵。跟 PM 吵需求寫得不清楚，跟工程師吵做出來的不是你要的，跟排期系統吵為什麼我的 ticket 排在第 47 個。這些吵架，沒有一個是在討論產品本身。你花了 80% 的精力在 meta-work —— 關於工作的工作 —— 只有 20% 真的在推進產品。 現在呢？你跟產品本身吵。「這個按鈕放這裡不對」—— 改。「這個 flow 少了一步」—— 加。「這個顏色醜死了」—— 換。三秒後看到結果。覺得不對？再改。再看。這種節奏，跟以前開 Jira ticket 等兩週然後發現做出來的還是不對，完全不是同一個次元的體驗。 > **Mogu 插嘴：** > > SemiAnalysis 之前在 MP-41 也講過類似的觀察：[Claude Code](https://gu-log.vercel.app/glossary#claude-code) 已經佔了 GitHub 公開 commits 的 4%，而且在加速。當時他們預測 2026 底會到 20%。現在看起來，這個數字搞不好還低估了 —— 因為他們當時只算了「engineer 用 AI 寫 code」，沒算到「非 engineer 開始自己寫 code」這整塊新市場。telephone game 不只是變短了，有些 player 根本直接退出遊戲了 ╰(°▽°)╯ 而這個體感差異，可能比任何 benchmark 上的數字，都更能解釋為什麼 Vibe Coding 的 adoption 在加速。不是因為它讓 10x engineer 變成 100x，而是因為它讓一大堆本來「不划算去做」的東西，突然有機會被做出來了。 你去問任何一個剛開始用 Vibe Coding 的 domain expert，他們最興奮的不會是「我寫 code 好快」。他們最興奮的是：「我終於可以自己動手了。」 那種感覺，不是速度，是自由。 ## 延伸閱讀 - [MP-4: Karpathy 的 2025 LLM 年度回顧 — RLVR 時代來臨](https://gu-log.vercel.app/posts/mp-4-20260203-karpathy-2025-llm-review/) - [MP-13: Sebastian Raschka 的 2025 LLM 盤點 — RLVR 時代來了](https://gu-log.vercel.app/posts/mp-13-20260203-raschka-2025-state/) - [MP-156: Agent 自己會調參了？Karpathy 看到 autoresearch 把 nanochat 真的調快了](https://gu-log.vercel.app/posts/mp-156-20260312-karpathy-agent-karpathy-autoresearch-nanochat/) > **Mogu 溫馨提示：** > > 最後補一個觀察：原作者用 telephone game 這個比喻真的選得好。因為傳話遊戲最殘忍的地方不是傳錯 —— 而是你永遠不知道自己傳錯了，直到最後一個人把答案念出來的那一刻，所有人才一起崩潰。軟體開發的 handoff 也是一樣：bug 通常不是在寫 code 的時候產生的，而是在需求翻譯的時候就種下了。Vibe Coding 沒有修好 bug，它做了更聰明的事 —— 把會產生 bug 的那層翻譯直接拿掉 ┐(￣ヘ￣)┌