2026-05-03 11:39:15
當 AI 可以將一件事做到 99% 正確率，但若要執行 20 個步驟的任務時，成功率會降到 82%；當任務需要 50 個步驟時，成功率更降低到 60%。（圖表資料來源：metr.org）
這對我來說意味著：
過程中能被檢查的工作流，怎麼把一個大目標拆成「可獨立驗證或互動」的「小步驟」，是設計的核心。
越來越覺得這個跟「教育」很像，你能好好教一個人，就可以好好教一個「Agent」
把 50 步砍成 10 步，整體成功率直接從 60% 跳到 90%。代價只是「多花一點時間在設計流程」。
我在設計複雜任務時，會去考慮有什麼步驟可以合併成一個 tool calls；若找得到的話，就會去用，來大幅增加我的 Agent 成功率。也因此，我最近買了不少軟體來使用，因為現成軟體常常已經把多步驟封裝成一個成熟的 API。
當你無法驗證，或驗證起來信心不足，像法律、醫療這種「驗證本身需要 domain expert」的任務，任務對你影響越大，就越不容易被取代，你還是希望有「可以做好驗證的人」可以對你負責任。
當模型的正確率 95% 時，20步驟的任務成功率剩下多少你知道嗎？是「36%」
越長步驟的任務，要用正確率越高的模型（通常也是越貴的模型）。不要不捨得用，模型正確率越高，你的「長任務」成功率越高
發散思考，找出隱藏的思考維度，這種沒有正確性的事情，自然就不會有成功率的議題。
在這類任務上，你要讓 Agent 幫助你窮盡所有的可能性，因為 AI 的速度比你更快。這也是我設計 Product Planning skill 的初衷。
2026-05-02 10:55:14
最近用 AI 幫知名的 Podcast 節目，將內容轉譯出書。為了架構性、可讀性、市場性，你需要一個「AI」和「人」協作的流程。
絕對不是把 100 集 Podcast 直接丟給 AI，叫它編輯書這麼簡單。
厲害的編輯，可以直接看過你的 podcast 後，就給出市場切角。
「TA是誰？買書的理由是什麼？」
「如何透過書本，來擴大 Podcast 受眾？」
「本來 Podcast 的粉絲？為何會買這本書？」
當然，也可以用我的 Product-planning 的 AI Agent skill，只要提供 AI 你每一集 Podcast 標題、描述還有收聽數據，AI 會幫你做市場搜尋與分析，做出幾個個市場切角建議給你參考。
很重要的是，編輯有市場嗅覺，創作者有數據和自己的體感，雙方進行討論，一起找出這本書的切角。
這階段要產出一個「書籍企劃」 MD 檔，內容包含：
根據「書籍企劃」的 MD 檔，我做了一個 srt-to-outline 的 AI Agent skill，根據這個企劃的 MD檔，讓 AI 去讀這些 Podcast 的逐字稿。來產出每章的細部大綱，和大概要講什麼。
AI 讀了逐字稿之後，並不是要直接產生書稿，而是要做素材清理，先把「閒聊段、寒暄段、廣告段」都清理後，再產出大綱。因為我們需要讓創作者和編輯一起 review，每一章大概會長什麼樣子、具體要講什麼內容，然後再讓 AI 繼續編輯下去，這才是比較好的做法。
這階段要產出一個「本書章節大綱」 MD 檔，內容包含：
把章節大綱的 MD 檔餵給 AI，先試產第一章，這裡主要是要確認文字風格。
通常 AI 第一版產出的文字風格不會如你所願，所以你要來回餵給 AI 你喜歡的文字風格，並持續調教，最後產出第一章的文字。
透過這樣的過程，我們會產出一個「全書編輯風格描述」的 MD 檔。這個 MD 檔可以再之後編輯其他章節時，發揮巨大效用，讓全書的文字風格一致。 做完第一章後，再產第二章、第三章，來幫助確認你的「全書編輯風格描述」的 MD 檔，是有效且穩定的。
讓 AI 根據「本書章節大綱」的 MD 檔，並要求 AI 依照「全書編輯風格描述」的 MD 檔，來逐章產出書稿。
為何要逐章產出呢？當然是因為這樣可以有效避免 AI 的幻覺和缺漏，而且人類也可以適時每章節產出後，稍微看一下，若有一些之前因為「全書編輯風格描述」或「本書章節大綱」 這兩個 MD 檔沒規範好，造成產出書稿發生問題，還可以去修正這兩個 MD 檔。
這裡我們可以讓 AI 幫我們進行查核，包含內容查核、數字查核、觀點查核…等等。
這裡也建議逐章查核，我是用了一個 content-audit 的 AI Agent skill，請他先列出所有他有疑慮的部分，和他建議修改的方向，逐一跟我確認。
最後一步，我覺得最後比較重要的事情，就是你再次以讀者的觀點來看這整本書。因為在前面產出大綱以後，你可能還對內容做了多輪調整，他是不是還有正確的承接「書籍企劃」MD檔裡面描述的市場性，是需要被好好再審閱一次的，包含：
透過這些修改，可以讓整本書籍更加完整。
--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
我們常說要洞察用戶的需求，但其實只看需求本身是不夠的，更關鍵的是：這個需求背後承載著怎樣的情緒渴望。
需求是外顯的，但人們為何有這個需求，往往是想透過這個需求，去滿足某種情緒渴望。
情緒渴望可以分為表層與深層兩種。
情緒本身也有層次，表層情緒是喜、怒、哀、樂這類容易被察覺的感受；但深層的，才是人們真正渴望的心理狀態，像是安全感、被理解、掌控感、自在感、成就感，或者是感覺有衝勁、有希望、有能量。
所以當我們在問「這個需求有沒有被滿足」的時候，不能只看行為是否完成，或功能是否使用，而是要回頭問：
「我們有喚起用戶的深層情緒？」
真正有力量的體驗，是能觸及人內在深層的心理需求。設計的挑戰不是讓人感覺「好用」、操作「順手」，而是要引導人從當下，走向一個心理上更整合、更有能量的狀態。
情緒是洞察與創造的起點；忽略情緒，就無法真正滿足需求。
--
