一個需求聽起來很完整，通常不是因為它真的完整，是講的人自己太熟，熟到把沒講清楚的地方，用一種順口的語氣蓋過去了。這篇想講我自己怎麼在動手之前，把一個聽起來沒問題的需求，逼問到體無完膚，逼出裡面真正藏著的分岔，包含一個內建的規劃模式、一個我自己每天都在用來逼問計畫的功能、還有一組別人做的外掛工具。
以前寫程式，大部分時間花在把東西打出來，需求就算講得不夠細，邊做邊補也還來得及，反正打字本身就要花時間，中間有空間慢慢釐清。現在不一樣了，跟 Claude Code 講清楚要做什麼之後，它動手的速度快到你根本來不及邊做邊補，一個模糊的需求丟下去，它會很篤定地做出一個東西，做得又快又順，看起來完全沒問題，直到你發現方向根本是錯的，這時候要重來，比當初多花十分鐘講清楚要浪費得多，浪費的不只是時間，還有已經投入下去的信心。
問題是，以前需求講得不清楚，最多就是自己邊寫邊想邊改，成本攤在整個開發過程裡，不會一次爆發出來。現在需求講不清楚，成本會集中在一次性的重工上，因為 AI 已經很快地把整個東西做完了，你要改的不是一行還沒寫完的邏輯，是一整包已經成形的產出。這是為什麼我自己現在花在講清楚要什麼的時間，比以前當工程師的時候還多，瓶頸真的搬過來了。
一開始我自己還不太適應這件事，總覺得花時間在講需求、寫規格，是在拖慢速度，真正的產能應該看動手做了多少東西。後來吃過幾次虧才調整過來，一次因為需求沒講清楚重工的損失，往往比多花半小時講清楚的成本高出好幾倍，這筆帳算過一次，就沒辦法再說服自己跳過這一步，就算當下還是會覺得手癢想直接開始動手。
我自己現在遇到一件比較大的事，第一步不會直接叫它開始做，會先切到一個只能看、不能改的規劃模式。這個模式下它不能真的去動任何檔案，只能讀、只能想、只能把接下來打算怎麼做的步驟講給我聽。這個限制我自己覺得是這個功能最重要的地方，因為手被綁住之後，它沒有別的選擇，只能把想法講清楚，不能用「先做做看」的方式蒙混過去，也不能靠先動手改個幾行來迴避還沒想清楚的部分。
用過幾次之後我發現，很多一開始以為很清楚的需求，一進到這個模式，馬上就會冒出好幾個沒想過的分岔，這個情況要怎麼處理、那個邊界值算不算數，這些問題在直接開始做的情況下常常是做到一半才卡住，換成先規劃，這些問題會提前浮出來，讓我在還沒真的動手改任何東西之前，先把方向確認一次，而不是做到一半才停下來重新想。
這個模式跟前面幾天講的東西也有關係，它本質上是逼自己先講清楚驗收條件是什麼，再開始動手，跟外包一件事之前要先講清楚怎樣算做完，是同一件事往前挪到自己身上做而已。差別是外包的對象是另一個角色，這裡的對象是接下來要動手的自己，交代的內容一樣重要，不會因為是自己要做，就可以隨便帶過。
這個模式最後會給我一份寫下來的步驟，我自己看這份東西的時候，不是看它排得順不順、讀起來像不像樣，是刻意去找有沒有哪一步寫得含糊，含糊的地方通常就是它自己也還沒完全想清楚的地方，只是用比較籠統的句子帶過去了。找到這種地方，我會直接追問，逼它把那一步講得更具體，講不出來，代表這一步本身就有問題，不是文字寫得不夠好的問題，換個說法重講一次也解決不了。
先講清楚，規劃模式解決的是「有沒有想清楚步驟」，但沒有解決「這個計畫本身經不經得起質疑」這件事。我自己另外還會用一個做法，專門用來逼問一個計畫或設計，這個功能其實是把兩件事湊在一起做，一個是不斷追問、找出計畫裡站不住腳的地方，另一個是同時把討論出來的名詞跟決定，整理成固定的文件。
逼問這件事聽起來簡單，但真的做起來效果很明顯。一個計畫講出來的時候，往往聽起來很完整，因為講的人自己已經對這個計畫很熟，很多沒講清楚的地方會被自己的熟悉感掩蓋過去，覺得應該沒問題。真的被問到「那如果是這種情況呢」「這個詞你指的是哪一種」，才會發現原來自己也沒想清楚，只是講得順而已。這種逼問的角色，我自己會刻意讓它保持懷疑的態度，不是來附和、來幫忙把想法講得更好聽，是專門來找碴的。
舉個例子，假設我想做一個功能，讓使用者可以「快速標記重要內容」，這句話自己講出來的時候聽起來完全沒問題。真的被逼問「快速指的是幾秒內完成，還是幾個步驟內完成」「標記之後，這個內容會出現在哪裡，還是只是加個記號留在原地」「重要是使用者自己判斷，還是系統幫忙判斷」，才會發現一句聽起來完整的需求，裡面藏了至少三個沒有答案的分岔。這些分岔如果沒有先問出來，會變成三個人做出三種不同的東西，事後才發現彼此理解的根本不是同一個功能。
這種被問到啞口無言的感覺，我自己一開始很不喜歡，會覺得對方是不是故意在找麻煩、雞蛋裡挑骨頭，明明講的是同一件事，為什麼要問這麼細。後來想通，這種不舒服的感覺，正是這件事有用的證據，如果每個問題都能秒答，代表這份需求本來就夠清楚，不需要逼問這一關。真正該逼問的，就是那些讓人一時語塞的地方，那正是後面最容易出事的地方，越是講起來心虛的地方，越值得多問一句。
這裡也要提一件跟 Day 5 講過的同一個道理，負責逼問的角色，最好是一個還沒被這個計畫說服過的角色，不是提出這個計畫的人自己順便扮演質疑者。自己既是提案人又是質疑者，很容易在逼問到一半的時候，不自覺就站回原本相信這個計畫的立場，覺得這裡應該沒問題，跳過去繼續往下問。我自己現在會刻意把逼問這件事交給一個角度完全獨立的對話去做，不讓提案跟質疑混在同一個立場裡進行。這件事跟 Day 5 講的找候選要用乾淨的視角，是一模一樣的道理，只是這裡驗的不是程式碼，是一個還沒動手做的想法，換角色這件事在需求階段一樣重要，甚至更重要，因為這個階段錯了，後面全部都會跟著錯。
另一半的功能是把逼問出來的結果變成文件，包含每個重要決定為什麼這樣定、還有一份共同的名詞對照表。這件事我自己覺得比逼問本身還關鍵，逼問完只留在對話紀錄裡，過幾天就會忘記當初為什麼這樣決定，寫成文件之後，這些決定變成可以回頭查、可以給別人看的東西，不會隨著對話視窗關掉就消失。這也呼應前幾天講的那句話，判斷要寫成文件，不要只放在腦子裡，這裡只是把同一個原則，套用到需求定義這個更前面的階段。
逼問這件事跟前面 code review 那篇講的完成判準，其實遇到同一個陷阱，一直問下去，永遠有下一個可以問的問題，跟找 bug 一樣沒有自然的底。我自己現在用的判準也跟那篇講的一樣，換一個問法，不是問「還有沒有問題可以問」，是問「還有沒有一個沒問清楚的地方，會讓後面做出來的東西方向錯掉」。
前者永遠回答有，因為任何一個決定都可以再往下追一層。後者是會歸零的，把真正會影響方向的分岔都問過、都有答案之後，剩下的問題大多是枝微末節，不影響大方向，這時候就可以先停下來動手，不用把每一個能想到的細節都問到底，那樣反而會把原本該花在動手做的時間，耗在問一些其實不影響結果的小地方。這個判準跟前一篇講的完全對得上，只是換了一個場景講一次而已，我自己覺得能在不同場景反覆驗證還站得住腳的判準，才是真正值得留下來的東西。
逼問加文件化這套做法裡，我自己特別看重名詞對照表這一塊。很多需求講不清楚，不是邏輯有問題，是雙方講的同一個詞，指的根本不是同一件事。一個「完成」對我來說可能是驗收條件全部滿足，對另一個角色來說可能只是跑完流程，沒有先把這種詞的定義對齊，後面不管講多少邏輯，都是各講各的，只是彼此都以為對方聽懂了。
把名詞寫成一份對照表的好處，是這種落差會提前被攤開來，而不是等到東西做出來，兩邊才發現理解的根本不是同一件事。我自己現在寫任何比較重要的東西之前，都會先問一句，這幾個關鍵詞，我們指的是同一件事嗎，這句話問出來常常會發現，原來大家腦子裡的版本不太一樣。
像是這系列一直在講的「完成」這個詞，前面幾篇已經花了不少篇幅講清楚它指的是驗證過的結果，不是跑完流程。如果一開始沒有把這個詞定義清楚，後面每一篇提到完成，讀者可能會用自己原本的理解去套，跟我實際想講的東西對不上，這就是名詞對不齊最直接的例子，發生在我自己寫這系列的過程裡，不是憑空想像的情境。
再舉一個例子，「角色」這個詞這系列也用了好幾天，指的是分工時彼此獨立、不共用上下文的一個工作單位，不是真的有一個固定的人格或身分，也不代表背後一定要換成不同的模型。如果讀者把這個詞理解成某種擬人化的助手設定，讀到後面講模型分級、講換角色要換得徹底，可能會覺得邏輯對不起來。這也是為什麼我自己寫每一篇之前，都會想一下今天用到的關鍵詞，跟前面幾天講的是不是同一個意思，不一致的地方，寧可多解釋一句，也不要讓讀者自己猜。
跟前面幾天講的模型分級一樣，逼問這件事也不需要每一個問題都動用最強的資源去想。找出有哪些地方講得含糊、有哪些名詞可能有歧義，這種掃描式的工作，用中等的資源正常仔細做就好。真正需要判斷力的地方，是決定這個分岔到底重不重要，值不值得現在就問清楚，還是可以先擱著，這種需要拿捏輕重的判斷，我會留給比較強的資源去想，避免因小失大或者反過來鑽牛角尖問了太多不重要的細節。這個分法套進來之後，整輪逼問跑起來也不會因為太仔細而拖太久，真正花時間的只有判斷輕重那一小段。
除了前面這套逼問加文件化的做法，我自己也裝了一組別人做的外掛工具，裡面有兩個指令，一個是幫忙發散想法，一個是把想法收斂寫成一份計畫文件。這跟前面那套的差別在於，逼問比較適合已經有一個雛形、需要挑毛病的情況，這組工具的發散指令更適合連雛形都還沒有、只有一個模糊方向的時候用，先讓想法攤開來，再收斂成一份寫下來的計畫。
我自己會依情況挑著用，已經有想法但沒把握夠不夠完整，用逼問去挑毛病比較快，效率比較高。完全還沒想清楚要做什麼，先用發散把可能性攤開，再收斂成文件，會比直接逼問一個還不存在的東西有效率，畢竟逼問需要一個具體的目標才能問得下去，對著一片空白逼問不出什麼結果。這兩種工具解決的其實是同一個問題在不同階段的樣子，一個是修一份已經寫出來的草稿，一個是從零開始生出一份草稿。
這組外掛工具是別人整理出來的一整套技能庫，裡面除了發散跟收斂這兩個指令，還有測試、除錯、跟人協作這類的做法，我自己目前用得最多的還是這兩個跟需求定義直接相關的部分，其他的還在慢慢摸，之後有機會用出心得再另外找一篇講。這件事也提醒我自己一個習慣，裝了一整套工具，不代表要一次全部用上，先挑跟眼前問題最相關的那一兩個開始用，用熟了再往外擴，不然裝了一堆東西，最後只是放在那裡沒真的用起來。
這組工具其實還有第三個指令，專門負責把寫好的計畫真的動手執行掉，這件事我自己覺得也值得提一下，因為它把發散、收斂、執行這三件事，清楚切成三個獨立的步驟，跟前面講的道理是一樣的，想的階段跟做的階段分開，不要混在一起，一邊想一邊做，很容易做著做著就忘了原本想清楚的方向，走著走著就走偏了，等發現的時候常常已經偏得有點遠。
回頭想，逼問這件事在一個團隊裡，通常是另一個人的工作，可能是比較資深的同事，也可能是產品那邊的人，專門負責在事情動手之前，問一堆讓提案的人有點不耐煩的問題。現在這個角色沒有消失，只是變成我自己要在動手前，先切換成那個角色來問自己一輪。
這件事做起來比想像中彆扭，因為要同時當提案人又要當那個找碴的人，情感上會有點抗拒，畢竟大部分人都比較想聽到「這個想法不錯」，不是聽到一堆「這裡你想清楚了嗎」，這種心理上的抗拒，我自己花了一段時間才慢慢習慣。但這正是一個人要撐起原本一整個團隊會有的功能，必須做的事，少了這個角色，需求這關就沒有人把關，等於直接跳過了團隊原本最有價值的那道防線。
我自己會提醒自己，逼問這個角色的工作是幫我把問題找出來，不是幫我否決這個計畫，找出問題之後，要不要照原本的方向做、要不要調整、要不要放棄，這個決定還是回到我自己身上，逼問的角色沒有權力替我做這個決定，它只負責把該看清楚的東西攤在我面前，讓我不會帶著沒發現的漏洞就往下走。這條分工跟這系列一路強調的一樣，找問題可以外包，要不要做這件事的判斷，我自己還是留著，這條線到目前為止都沒有鬆動過。
逼問的過程裡，常常會被問到一個我自己也答不出來的問題。這種時候，我自己會刻意提醒自己，不要為了讓對話順下去，隨口編一個聽起來合理的答案。這件事其實就是這系列第一天講的那條紅線，套在需求定義這個階段的樣子，缺一個答案，就老實說不知道，先記下來當成待確認的事項，不要因為想快點把規格寫完，就掰一個答案糊弄過去。
這件事說起來簡單，做起來其實有點反直覺，尤其是自己一個人面對這種情況的時候，沒有旁人看著，更容易偷懶隨口帶過，因為被問到答不出來，會有一種說不出來很奇怪、好像沒把這件事想清楚的尷尬感，很容易就順口接一個聽起來過得去的答案。我自己現在會把「答不出來」當成一個有用的訊號看待，而不是要遮掩的弱點，它代表這個地方真的還沒想清楚，先誠實承認，比硬掰一個答案、後面照著錯的方向做下去，成本低得多。
寫進文件的時候，答不出來的地方我一律會直接標成待確認，不會留白假裝沒這回事，也不會硬塞一個看起來像答案的句子進去。這種標記本身就是一種有用的資訊，代表這裡是之後動手做的時候要特別小心的地方，或者是需要另外找人問清楚的地方，比一份看起來完整、但其實藏著沒人真正確認過的假設的文件，安全得多。一份誠實標出待確認事項的文件，價值比一份看起來滴水不漏、實際上到處都是沒人敢戳破的假設的文件高得多，這件事我自己一開始沒想清楚，後來吃過幾次虧才真的理解。
逼問跟文件化做完一輪，不代表這份規格就永遠不會變。我自己現在的習慣是，真的動手做的過程中，常常會冒出新的問題，這時候我不會覺得規格已經定案就不能改，而是把新冒出來的問題，回頭補進原本的文件裡，讓規格跟著實際做的過程更新，而不是讓規格停在最初那一版，跟後來的實際狀況越走越遠，變成一份沒人再參考的過時文件。
這件事聽起來有點理所當然，但我自己一開始也犯過相反的錯，覺得規格既然花時間逼問過，應該就是定案，後來做的時候發現漏了什麼，會下意識覺得是自己執行有問題，沒有回頭去補規格，結果同樣的漏洞下次又冒出來一次，因為那個漏洞從來沒有真正被記錄下來，只是那一次憑印象補上而已，下一次遇到類似的情況，又得重新想一遍同樣的問題，等於白白浪費了第一次逼問時已經想清楚的東西。
逼問完寫出來的名詞對照表跟決定紀錄，我自己不會寫完就收進抽屜。後面接到類似的需求，我會先回頭翻這份文件，看看當初逼問過的分岔，這次還適不適用，有沒有新的情況是當初沒問到的。這樣做省下的時間比想像中多，很多看起來是新需求的東西，拆開來看，跟之前已經逼問過的某個分岔其實是同一件事，只是換了個包裝再問一次。
這也是為什麼我自己堅持要把逼問的結果寫成文件，而不是讓它只留在某一次的對話裡。一次性的逼問只解決眼前這一個需求，寫成文件之後，逼問這個動作的價值會累積下去，下一次遇到類似的分岔，不用重新從頭問一遍，直接翻出上次的答案，看看還成不成立就好。
老實講清楚這幾個工具的極限。規劃模式能逼你先想清楚步驟，逼問能挑出一個計畫的破綻，文件化能把決定留下來，但這些都建立在一個前提上，就是你對這件事本身有一定程度的理解，只是還沒講清楚。如果你對要做的這件事根本沒有概念，這些工具能做的，最多是幫你把「我不知道」這件事講得更明確，沒辦法幫你生出一個原本不存在的理解。
我自己這陣子也遇過幾次，用逼問問到最後，發現卡住的不是表達方式，是我自己根本沒想清楚要什麼，這種時候工具幫不上忙，得先停下來，自己想清楚，或者去問真正懂這塊的人，不是繼續逼問一個連我自己都答不出來的問題，硬逼下去只會問出更多答不出來的問題，不會憑空生出理解。這條界線我自己現在會分得比較清楚，工具負責把想清楚的東西講出來，想清楚這件事本身，還是得靠自己，這件事沒有任何工具可以替我做。
還有一個很現實的限制是時間成本。逼問跟寫文件這件事不是免費的，一輪認真做下來，花的時間不算少，對一個影響範圍很小、就算做錯也很好改的小需求，花整套流程去逼問，反而是殺雞用牛刀，多花的時間比可能省下來的重工成本還高。這個判準跟前面 code review 那篇講的一樣，值不值得搬出整套流程，要看這件事做錯的代價有多大，代價小的，直接憑經驗判斷、動手做就好，不需要每次都走完整套逼問文件化的流程。這件事我自己判斷的方式很簡單，先問自己這個需求如果理解錯了，會不會等到東西快做完才發現，如果答案是不會，很快就能發現、很快就能改，那就不用大費周章，直接動手，錯了再調整就好。
還有一種情況，逼問問過頭，反而會陷入另一種原地打轉。想得越多，越容易發現新的分岔，每個分岔又可以再往下追一層，如果沒有前面講的那個完成判準拉住，很容易變成規格永遠寫不完，遲遲不敢動手，這跟一開始沒想清楚就衝去做，是同一個問題的兩個極端，一個是想太少，一個是想太多，兩種都會拖累真正該花時間的地方。
我自己抓的平衡點是，先讓逼問跑一輪，把會影響方向的分岔問清楚，寫成文件之後就先動手，不會等到自己覺得完美無缺才開始做。做的過程裡如果冒出新問題，就回頭補文件，跟前面講的規格不是寫完就結束是同一個做法，把逼問這件事，從一次性做到滿分，換成分成好幾輪、跟著實際進度一起往前推，每一輪都比前一輪更貼近實際狀況，而不是每一輪都想追求一次到位。
今天講的這套做法，其實跟前面講的原則是同一套邏輯，只是套用在更早的階段。規劃模式是逼自己想清楚再動手，跟外包研究時要交代清楚目標跟驗收條件是同一件事，只是這裡交代的對象換成自己。逼問加文件化，是把判斷寫成文件這個原則，往前推到需求還沒定案的階段就開始做，不是等到東西做完才補文件。名詞對照表要對齊，本質上跟 Day 5 講的第二個角色要拿證據才能採信一個候選，也是同一種不輕易接受表面說法的態度，只是這裡驗的不是程式碼裡的問題，是彼此腦子裡的理解到底一不一致。
就連完成的判準都是同一套，Day 5 講完成是沒有驗證過的阻礙，不是沒有話可以挑，今天講完成是沒有會影響方向的分岔，不是沒有問題可以問，兩句話的結構一模一樣，只是套用的場景從審查程式碼換成定義需求。真正值得留下來的，不是某個階段該用哪個工具，是同一個判準能不能撐著，被套進不同的場景裡都還講得通，撐不住的判準，講得再漂亮也只是巧合。
這些原則不是各自獨立的技巧，是同一套判斷方式，套進開發流程裡的每一個階段，只是每個階段長出來的具體做法不一樣，工具會換，判斷的核心不會換。需求定義這段，我自己覺得是最考驗這套判斷方式的地方，因為錯得早，錯得也最貴，前面用小功能跟 code review 講的東西，出錯了還能回頭修，需求這段一開始就走錯方向，後面做得再仔細都是白費。
下面講設計那段，看看規劃跟逼問這幾個工具，用在架構決策上會長成什麼樣子，跟需求這段比起來，又有哪裡不一樣。
iThome鐵人賽
看影片追技術