2026-04-20 10:10:37
老闆說：「我們現在有 AI 了，你覺得產品開發速度可以快多少？」
我通常反問：「你現在產品從想到上線，哪個環節最慢？」
大部分人停頓一下，說：「應該是開發吧。」
其實不是。開發早就被 Claude, Codex 這些工具補上去了，RD 寫程式的速度蠻快的，問題不在這。
我問過蠻多 PM，他們真正的瓶頸是兩個地方：第一，把 idea 轉成 RD 看得懂的需求；第二，東西做完之後，要怎麼確認它對了。
說穿了，就是「轉譯」跟「驗收」，這兩個環節還卡著。
我在產品營常跟同學說一件事：做一個東西，它的真實樣子不是瀑布，是一個循環。
想 → 轉譯 → 做 → 檢查找問題 → 轉譯 → 做 → 檢查找問題 → 轉譯 → 做……
你看，「轉譯」跟「檢查找問題」出現了不只一次，出現了好幾輪。
在這個循環裡，AI 能幫到的地方，其實已經蠻清楚了，「做」這件事，AI 幫很多。但「想」，加速不了，這是 PM 的核心工作；「轉譯」，現在還是瓶頸；「檢查找問題」，也還是瓶頸。
轉譯為什麼是瓶頸？因為 PM 腦袋裡的 idea，跟 RD 收到的需求，中間有一個巨大的 gap。
PM 說「要讓用戶感覺結帳很快」，RD 心裡想：「這到底是要改後端速度？改動畫？還是改步驟數？」
沒有人知道。大家靠會議、靠猜、靠 RD 問、靠 PM 再講一次，把這個 gap 慢慢縮小，這個過程蠻費時間的。
其實有一個東西可以解這件事，叫做 GWT，也就是 Given-When-Then。
Given（在什麼情境下），When（當使用者做了什麼），Then（應該出現什麼結果）。
這個格式搭配 Example Mapping 深入挖掘細節，確保團隊能對齊。
一旦有了 GWT 後，搭配工具和一些初期建設，RD 就可以直接把它轉成自動化測試，也就是 TDD 的做法。「驗收」這件事就不再靠人工一個個 case 點，RD 跑測試，通過了就是通過了。
這樣就把轉譯和驗收這兩個瓶頸，同時拆掉。
這裡有一個細節很重要，就是 GWT 不應該每次從零重寫。
功能有新有舊，很多 GWT 其實是重複的，或者是在原來的基礎上修一兩條。每次都重新產，其實是在浪費時間。
所以正確的做法，是維護一個 GWT 庫，舊的功能有自己的 GWT，新功能做完加進去，修改的功能去更新對應的條目。時間久了，這個庫本身就是系統文件，也是測試基礎。
再加一個 skill 幫助快速產 GWT，讓 PM 不需要從白紙開始想格式，來幫助 PM 從 user story 產出符合公司框架、避開常踩的坑，產出 GWT 交給 RD。
這樣 PM 在轉譯這個環節花的時間，就可以拆掉瓶頸，品質更高。
我蠻常看到一個迷思：覺得「自己一條龍可以從需求到驗收全部搞定」的 PM，是厲害的 PM。
但其實這個想法，跟工廠老闆說「我找一個人從採購到包裝全包」是一樣的邏輯，量出不來的。
要量，就是要建系統，拆瓶頸。
方法A：一個人一條龍做完，這樣沒有交接的瓶頸，但可以一條龍做完的人，本來就是少數，不太可能用這種方法規模化。
方法B：把不同職能的人組合，但是有人和人之間的瓶頸，但可以修流程，拆瓶頸，最重要的是可以複製。
PM 在這個系統裡，其實是「供料」的角色，供好的需求給 RD，讓 RD 可以快速做、快速測、快速跑。
如果 PM 供的料是模糊的描述，RD 就要花很多時間跟 PM 對齊，做完還要等 PM 一個個功能點進去按，才知道對不對，這個流程產能就一直卡著。
換個做法：PM 供的料是 GWT，RD 拿去跑自動化測試，出問題的 case 才需要 PM 進來看。PM 的時間就可以集中在真正重要的一件事：這個功能做出來，是不是用戶真正要的東西？體驗好不好？品質夠不夠？
這才是 PM 應該花時間的地方。
The post 導入 AI 開發後，下一個瓶頸在哪裡？ first appeared on Mr. PM 下午先生.2026-04-18 12:12:00
最近跟很多朋友交流，他原本不會寫 code，是做規劃和整合的人，但開始 Vibe Coding 後做出了成果，反而變成期待通膨，工作吃不消。
這就是職場常見的陷阱：能力強的人，事情會越來越多，搞死自己。但 Vibe Coding 這波，陷阱比以前更深，因為大家對 AI 的想像太美好了。
不是不要 vibe coding，因為我自己也在做，也樂在其中，但是這其中難免有很多令人不舒服的地方。
證明了 A 可行，就直接假設 B 也可行。
但常常遇到的狀況是，難度不是線性成長，是指數成長。「你能做到 A，那 B 應該也不難吧！」，說這話的人不是故意刁難，他是真的這樣覺得。
所謂「應該不難」的題目，到了實作層面會膨脹一百倍。
不是不能做，可能真的做得到。但做得到跟拼盡全力才做到是兩回事。Vibe coding 技能的人，對到底要花多少力氣和時間才能做到，估計誤差是非常大的，自己都不知道自己的能力邊界在哪裡，然後會有多喘。
這時候，真的要懂得做取捨，專注在重要的事情上，更策略的去做事，不要想用「努力」去壓過去，長期來講不可能。
做 Vibe Coding 的人，不是傳統職能定義的人，卡在中間規劃和實作中間。
傳統 PM 遇到問題，可以找工程師討論。工程師遇到問題，有技術社群、有 Stack Overflow、有同事可以 code review。但做 Vibe Coding 的人呢？你遇到的問題，同事給的支援，其實很有限。
Vibe Coding 的人是開拓者，但開拓者的代價是「沒人帶，沒補給」。
沒有支援體系，就得自己幫自己建。但建支援體系本身也要花時間。在補給不足的狀況下，自然就跑不快。
這可能是最核心的。
AI 進步太快，大家對 AI 能做什麼，認知很不一樣。
因為做 Vibe Coding 的人是「用 AI 做的」，所以在別人眼中，工作量被自動打了折扣。AI 幫忙寫了 code，所以應該更快、更多、更便宜。至於花了多少時間理解需求、設計架構、debug AI 寫出來的東西，這些隱形的工作量，大家認知的不一樣，有人覺得很多，有人覺得很少，根本沒對齊。
我們回頭看一下，以前所謂「能力很好的員工，是怎麼不累死自己的呢？」這個議題。
管理期待、寫工作紀錄、透明化自己的工作，從以前沒 AI 的時代，到現在有 AI 的時代，這些原則都沒變過。
不是你可以一條龍做到底，就一條龍自己做，而是要思考各自擅長的任務，把 AI 考慮進來，建立新的團隊 Protocol。經濟學的比較利益法則早就說過，什麼都強的大國，還是要跟他國貿易，才能達到效益最大化。
⠀
一個人走得快，一群人走得遠，這個原則到 AI 時代也是不會變。
懂取捨，抓重點，會是 AI 最關鍵的事。
2026-04-18 10:19:14
現在越來越多 PM 開始用 Vibe Coding 做產品開發。如果你用 SDD（Spec-Driven Development）框架，像是 Spec Kit，流程大概是這樣：人類寫 User Story、輸入設計稿，然後 AI 會根據這些東西產出 Spec 和開發計劃，最後再依照計劃去實作。
這時候一個很自然的問題就出現了：反正出來的東西會動就好，我幹嘛要去看、甚至看懂 AI 寫的 Spec 和開發計劃？
老實說，這個觀點也不能說錯。但在回答這個問題之前，我想先把 SDD 和 AI 拔掉，回到一個更基本的情境來看。
PM 和工程師之間，一直存在一個蹺蹺板的關係。
PM 寫規格模糊，工程師就要強。 資深的工程師知道產品該長什麼樣，你沒說清楚的他會主動問你，會按照業界慣例自己補上，會按照他腦中的產品樣貌來做。最後做出來的東西，雖然你沒寫到，但八九不離十。
反過來，工程師弱，PM 就要強。 PM 不能只丟一句話就走，你要把規格講得非常清楚，還要反覆去問工程師：「你對這個功能打算怎麼做？」不是在質疑他，而是在確認他真的理解你要的東西。
這個蹺蹺板的意思是：一邊強，另一邊可以弱一點。但如果兩邊都弱，東西就做不出來。
PM 用 Vibe Coding 開發，套了 SDD 框架，AI 就是那個工程師。
但 AI 是一個什麼樣的工程師？
AI 寫程式很快，但它不是一個可靠的工程師。 它不會像資深工程師那樣主動問你「這裡你沒講清楚，你是要 A 還是 B？」。它會直接猜，而且猜錯了也不會告訴你。它有很多誤解，很多自行腦補。
當然這是現況，AI 進步很快，也許哪一天他就是可靠的工程師。
所以回到蹺蹺板：AI 這個工程師不夠強，PM 就要強。
但好消息是，AI 這個工程師的腦袋是透明的。
人類工程師怎麼理解你的需求，你看不到。你只能從他最後做出來的東西去判斷他到底懂不懂。但 AI 不一樣——它怎麼想，會直接反映在它產出的 Spec 中。
所以 Review AI 產的 Spec，就是在 Review AI 到底懂不懂你的需求。
這就是為什麼看懂 Spec 很重要。不是因為 Spec 本身有多神聖，而是因為那是你唯一能在「它開始寫程式之前」就抓到誤解的機會。等它寫完程式你才發現不對，修的成本就高了。
這裡要誠實面對一件事：AI 產出的東西，PM 不是每一層都看得懂。
以 Spec Kit 為例，它的流程會產出好幾層東西：Spec、Plan、Task、Implementation。Spec 這一層，因為是基於你的 User Story 展開的，PM 通常看得懂。但 Plan 和 Task 涉及技術架構和實作細節，PM 大多看不懂。
這不代表那些東西沒價值，而是那些層的校驗責任不在 PM 身上。
如果你是 PM 一個人在跑 Vibe Coding，那 Spec 之後的層就算產出來，也沒有人校驗，等於白做。但如果有 RD 參與，那些層就變成 RD 的校驗工具——他可以幫你把關你看不到的技術層。
讀不懂的層，就是可能失控的層。就是可能會讓你調來調去都不對，要花超多時間的地方。
既然看懂 Spec 很重要，那是不是要用最完整的 SDD 框架，把每一層都跑完？寫最完整的 spec，然後 spec 一定要人都能 review。
不一定。要看你在哪個階段。
探索市場階段：輕量就好。這個階段你要驗證的是「這個東西有沒有人要」，不是「規格有沒有寫完整」。
完整的 SDD 流程（像 Spec Kit 的七步驟）在這個階段太重了。你連方向都還沒確定，今天寫的 Spec 明天可能整個推翻。如果每次轉向都要重跑完整流程，維護 Spec 本身就變成負擔。
這個階段用輕量的方式就好，重點是：
有這三件事，AI 就有一個穩定的參照點，不會每次都重新猜你的意圖，至於 spec 完不完整，能不能 review，不是那麼重要。
當方向確定，要開始擴張時，就該交給 RD 正式開發。此時，就應該拉高規格的嚴謹度。PM 負責 User Story 和 Spec，RD 審核 Plan 和 Task。這時候完整的 SDD 流程才有價值，因為有人能校驗每一層。
這個分法背後的邏輯是：不確定性高的時候降低投資，確定性高的時候提高品質。
回到開頭的問題：看得懂 AI 寫的 Spec 重要嗎？
重要。因為 AI 不是一個可靠的工程師，但它的腦袋是透明的。Spec 就是它的腦袋。你看不懂，就沒辦法在它動手之前抓到誤解。
但「看懂」不代表你要看懂全部。PM 能看懂 Spec 這一層就夠了，技術層的校驗交給 RD。框架選得對，每一層都有人看得懂，才是真正的品質保證。
不管你用什麼工具、走什麼流程，最後都回到那個蹺蹺板：AI 不夠強，你就要強。而你最該強的地方，就是看懂它到底懂不懂你。
--2026-03-15 18:39:24
我們常說要洞察用戶的需求，但其實只看需求本身是不夠的，更關鍵的是：這個需求背後承載著怎樣的情緒渴望。
需求是外顯的，但人們為何有這個需求，往往是想透過這個需求，去滿足某種情緒渴望。
情緒渴望可以分為表層與深層兩種。
情緒本身也有層次，表層情緒是喜、怒、哀、樂這類容易被察覺的感受；但深層的，才是人們真正渴望的心理狀態，像是安全感、被理解、掌控感、自在感、成就感，或者是感覺有衝勁、有希望、有能量。
所以當我們在問「這個需求有沒有被滿足」的時候，不能只看行為是否完成，或功能是否使用，而是要回頭問：
「我們有喚起用戶的深層情緒？」
真正有力量的體驗，是能觸及人內在深層的心理需求。設計的挑戰不是讓人感覺「好用」、操作「順手」，而是要引導人從當下，走向一個心理上更整合、更有能量的狀態。
情緒是洞察與創造的起點；忽略情緒，就無法真正滿足需求。
--2026-03-15 18:35:19
在跑 Scrum 的時候，有一件非常重要的事情，就是 Sprint Goal。
整個團隊都應該要朝著同一個 Sprint Goal 努力，而不是只專注在把自己手上的事情做完。
舉例來說，有時候在實作的過程中，你可能會覺得某個地方怪怪的，好像哪裡不太對勁。但因為規格就是這樣寫的，你心裡就想說：「算了，照規格做就好。」
你並沒有去思考，或懷疑這樣的實作方式，到底能不能真的幫助團隊達成 Sprint Goal，甚至在 Daily Stand-up 的時候，也選擇不提出來討論、不發問。
如果發生這種情況，其實代表這個 Scrum Team 是不及格的，而這樣的行為，也顯示這位成員在 Scrum 的運作上是不適任的。
--
