70% 問題：為什麼你 Vibe 出來的東西，最後一哩路那麼難？
你大概有過這個經驗：跟 AI 描述一個工具，十分鐘後它真的出現了，八成像樣，你覺得自己是天才。然後你花了三個晚上，試圖把剩下的兩成修好——每修一個地方就壞兩個地方，最後你開始懷疑，到底是 AI 不行，還是自己不行。
都不是。這個現象有名字，叫 70% 問題。
Google Chrome 的資深工程主管 Addy Osmani 在《Vibe Coding: The Future of Programming》裡，把這件事講得很透。書是寫給工程師的，但我讀完的感想是：最該看懂這件事的，其實是我們這些用自然語言做工具的非工程師——因為書裡描述的每一種翻車，我都在自己和學員身上看過。這篇把書的核心翻譯成你我能用的版本。
這篇文章用非工程師聽得懂的話拆解 Addy Osmani《Vibe Coding》裡的「70% 問題」：為什麼 AI 帶你走完前 70% 之後會卡關、兩種最常見的死法、以及邊界之後的三種走法。適合用自然語言做工具、卻常在最後一哩懷疑自己的人閱讀。
70% 問題：AI 擅長的，剛好是「有路可循」的部分
書裡引了一位非工程師的真實心聲，我看到的時候笑出來，因為太準了：「AI 可以帶你走 70% 的路，但最後 30% 令人挫折。它一直一步前進、兩步後退。如果我懂程式我就能自己修，但我不懂——所以我懷疑自己到底學到了什麼。」
為什麼是 70%?Osmani 的解釋用白話說是這樣：軟體開發裡有兩種難。一種叫「有模式可循的難」——表單怎麼做、按鈕怎麼排、資料怎麼存，這些事網路上有一萬個範例，AI 看過全部，所以它做得又快又好。另一種叫「你的問題特有的難」——你的使用情境、你的邊界狀況、你三個月後還要不要改得動它。這部分沒有範例可抄，因為它是你的問題，不是大家的問題。
AI 把第一種難吃掉了，於是第二種難占滿了你剩下的時間。這就是為什麼前 70% 像魔法，後 30% 像沼澤。
理解這件事之後，你的心態會先健康起來：卡在最後一哩不是你笨，是你走到了 AI 的能力邊界。接下來的問題只剩一個——邊界之後，怎麼走？
先認得死法：兩步後退與 Demo 陷阱
書裡列了兩個最常見的失敗模式，值得先認臉，因為你一定會遇到。
兩步後退(Two Steps Back)：你請 AI 修一個小 bug，它給了一個看起來合理的修法；這個修法弄壞了別的地方；你再請它修新問題；它又生出兩個新問題。循環下去，信心歸零。
這個模式我太熟了。我自己的解法，跟我在〈Vibe Coding 實戰五原則〉寫過的一樣：同一個問題修三次修不好，不要再修，重開一個新對話、重新描述需求。書裡給了理論依據——AI 在被自己錯誤方向污染的對話裡，會越修越歪；乾淨的開始比堅持便宜得多。配合「每次能動就存檔」，你砍掉的只是壞掉的分支，不是全部進度。
Demo 品質陷阱：用 AI 做出讓人驚豔的展示版，happy path 跑得漂亮——然後真實使用者開始亂點，一切崩潰。錯誤訊息沒人看得懂、慢的網路下整頁卡死、奇怪的輸入直接閃退。
書裡有一句話我特別有感：這種「讓使用者永遠不需要找客服」的打磨，來自同理心、經驗、和對craft的在乎——它（可能）無法被 AI 生成。我重建 pbtw.tw 這個網站的時候，功能版面一個晚上就有了，但之後修手機版選單卡死、表格在小螢幕溢出、瀏覽器快取吃到舊樣式——這些「Demo 跟產品的距離」，占掉的時間是前者的好幾倍。
我的經驗：差別在於，知道 70% 問題的存在之後，我把這段時間當成「本來就要付的成本」，而不是「哪裡出了錯」。
邊界之後的三種走法
書裡觀察了數十個團隊，歸納出三種真的有效的人機協作模式。原文是寫給開發團隊的，我把它翻成一個人也能用的版本：
模式一：AI 當第一稿作者。 AI 負責從零到有，你負責從有到好——驗收、挑毛病、要求重構。適合做新東西的時候。關鍵動作：AI 每交出一段能動的成果，就存檔一次，而且不同性質的修改分開存（功能歸功能、文字歸文字），出事才回得去。
模式二：AI 當結對夥伴。 你和 AI 邊做邊聊，小步快走。書裡的最佳實務跟我們課堂教的幾乎逐字吻合：每個獨立任務開新對話、指令聚焦一件事、緊湊的回饋圈。
模式三：AI 當驗證者。 反過來——東西是你做的（或另一個 AI 做的），請 AI 當檢查員：「幫我找這個工具的三個問題」「如果使用者輸入奇怪的東西會怎樣？」這一招對非工程師特別有價值，因為它把你看不見的盲區變成看得見的清單。
黃金法則，非工程師版
書末附了一組「Vibe Coding 黃金法則」。原版十二條是給團隊的，我挑出對個人創作者最致命的五條，附上我的註解：
- 把 AI 當需要監督的 junior——它的產出永遠是草稿。書裡引 Steve Yegge 的比喻：今天的 AI 像個產能驚人但「可能嗑了什麼」的年輕工程師，快得不可思議，偶爾端出瘋狂方案。
- 用原始意圖驗收，不是看順眼——拿你最初寫下的需求逐條對，而不是「看起來不錯就過」。這正是我們說的驗收標準，寫在動手之前。
- 不要上線你看不懂的東西——看不懂就請 AI 逐行用白話解釋到你懂。書裡的原則是「理解是可維護性與安全的底線」；我的資安講師版本更直接：你看不懂的程式碼，等於你簽了一份沒讀過的合約。
- AI 的自信遠超過它的可靠——它說「完成了！」的語氣，跟它真的完成了，是兩件獨立的事件。
- 好 prompt 存起來重複用——我自己的範本庫從「會議成本計算機」那篇的萬用需求句型開始累積，現在每開新工具，第一句話都不用重想。
對照之下你會發現，這本書和我們在〈第一個工具〉教的方法，本質是同一套——這給了我蠻大的信心：小步迭代、驗收標準、版本保護這些做法，不是某個人的偏好，是全球範圍內被反覆驗證出來的生存法則。
那「知識悖論」怎麼辦？
書裡最戳我的概念是知識悖論：資深工程師用 AI 加速「已經會的事」，新手卻想用 AI 學「還不會的事」——同一套工具，前者越用越強，後者可能越用越依賴。
這對非工程師是不是壞消息？我認為一半一半。壞的一半：如果你只是複製貼上、能動就好，那書說得很白——你沒有在學習，只是在消費，而且建立的是「離不開 AI 的依賴」。好的一半：書給的解法完全做得到——把每個 AI 產出當教材，問它「為什麼這樣寫」「換個做法會怎樣」；偶爾關掉 AI，自己讀一次錯誤訊息再求救。我在做選賽道機器人(/vibe-coding-decision-bot/)時就刻意這樣練：第一版的 System Prompt 是 AI 幫我擬的，但我逼自己逐段改寫成自己的話——改完之後我才真的「擁有」那個機器人，後來要加多賽道比較模式，我自己十分鐘就改好了。
重點：消費和創造的差別，不在你會不會寫程式，在你願不願意停下來問為什麼。
常見問題
問：我就是非工程師，30% 的「人類專業」我沒有，怎麼辦？
答：書裡的 30% 指的是判斷，不全是技術。「這個工具給誰用？什麼輸入算奇怪？壞掉時使用者看到什麼？」這些問題你答得出來——你缺的只是把答案餵給 AI 的習慣。
問：AI 越來越強，70% 會不會變成 95%，這本書就過時了？
答：比例會變，結構不會。書裡引 Tim O'Reilly：每次自動化浪潮改變的是「怎麼做」，不是「為什麼需要會思考的人」。決定做什麼、驗收好不好、為結果負責——這三件事沒有外包對象。
問：這本書值得非工程師讀原文嗎？
答：Early Release 版兩章都偏工程團隊視角，術語不少。如果你只想要可操作的結論，這篇加上站上的 Vibe Coding 系列就夠；想深入再去讀原文。
70% 問題的最佳解，不是等 AI 變強，而是讓自己成為「懂得帶 AI 走完最後一哩」的人。這正是「AI 助航 Vibe Coding」課程在教的事——從第一個工具到安全上線，把這篇講的觀念變成你手上的肌肉記憶。
這篇文章萃取自我的筆記〈書摘筆記|Vibe Coding: The Future of Programming(Addy Osmani)〉(/note-vibe-coding-book-osmani/)