某次Sprint Planning會議上，我提出一個新功能，說明因為業務PM反映使用者常常找不到某個報表欄位，所以想把它往前移。話才講完，A就問：「為什麼業務PM覺得這個欄位常常被忽略？他們是自己發現的，還是從客戶那邊聽來的？如果換個排序方式，業務端會不會也能接受？」我一時語塞，這幾個問題答不太上來。B也在旁邊點頭：「對啊，如果知道真正的原因，說不定不只是排序調整就能解決。」那次會議最後，我帶著滿頭問號回去，重新找業務PM問清楚。

學會不斷想「為什麼」，是被工程師培養出來的習慣

那次之後，類似的對話變成常態。只要是Sprint Planning，或是討論規格的會議，我會盡量把「為什麼要做這個功能」講清楚，但A跟B總是不滿足，繼續追問業務PM想要這個功能背後真正的利益是什麼，如果換一種做法，對方是不是也能接受。很多時候答不出來，只能回頭再去確認一次，慢慢地，我開始更全面地去想使用者需求，也對「為什麼」這件事變得更好奇。

顧問業界常講「連問五個why」才能挖到問題的根源，但這件事其實需要練習。一個人自己問，問到第二個、第三個why常常就卡住了，跟工程師一起合作反而幫了我，他們會一直提醒我，原來還可以繼續往下問。從那之後，講事情的時候就很習慣把why講出來。

有場域可以練習講why，是值得感謝的事

要把why講清楚其實很花時間，尤其是向上報告的時候，得把why講得精簡、重點清楚，上面的人才聽得下去。如果沒有A跟B這些工程師願意一直追問，大概也沒有一個場域可以一直練習把why講清楚這件事。後來讓我能比公司很多人用Cursor用得特別有心得，關鍵可能就在這裡：已經習慣把why講出來，這個習慣不是憑空來的，多謝他們一次次不厭其煩的互動養成的。

不管在什麼場合，跟人對話，對方常常覺得表達得不夠清楚，或是沒什麼耐心聽把話講完，當然這一點自己也要檢討。但脈絡這件事，反而在AI時代變成一種優勢，因為可以把所有的細節、過程、發生的前因後果記得非常清楚，這些都會變成一段很完整的context，對AI解決問題很有幫助。要更善用AI，就是真的把它當作一個人，而且是一個不會有負面情緒反撲、非常有耐心的人，那就可以很放心地把脈絡盡量講清楚，也可以反過來讓它問一些關鍵的問題。

這其實就是脈絡工程（context engineering），一部分是自己要能把事情講清楚，另一部分，是可以刻意養成AI也擁有這樣的個性，讓它引導我們問更多為什麼。有時候問不出why，不是不願意，是還沒有想像到那個可能性，一旦知道原來還有這個可能，就會願意多問一句。這也是人性，沒有想像空間的時候，很容易就直接say no，或是卡住不知道怎麼往下走。