那一天最大的幸運，是我們遇到了一大堆難題。
那天早上，一位認識很久的顧問朋友問我，這兩天有沒有空，他想聊一下目前卡住的地方。我看了一下行事曆，下午剛好有三個小時的空檔，就約了當天下午。
他從一個會議中間跑出來，一路跑到北投來找我。我們在一家咖啡館坐下，吃幾口東西，就打開電腦開始做事。
卡住的那一關是授權。網站要接上他原本的資料庫，中間隔著權限與金鑰，只要有一個環節沒對上，畫面就是一片空白，或是一行看不懂的錯誤。
兩個多小時裡，我們改了設定、查了文件、又推翻重來。中間他停下來說：「還是先停在這裡就好？」
我沒接話。我們又試了一次。後來授權解開了，網站從只能在他自己的電腦上跑，變成獨立放在外部空間，也接上了他原本的資料庫。還沒正式上線，但已經能動了。
但那天真正有價值的，不是我們把問題解掉了。
其實我沒有辦法直接教他。他遇到的問題我也沒遇過，我根本不會。我是透過這個過程，跟他一起學會的。
上一次，是讓他看見可以走到哪裡
他是顧問，不是工程師。
上一次我們一起做的，是用 Scrum 的方式，從跟 Codex 發想、討論、定規格，一路把「第二大腦」網站做出一個 POC 雛形。那次的目的很單純，讓他看見「原來可以走到這裡」。
那次結束時他很興奮，也開始想著要往最小可行性產品（MVP）走。
但看得見跟走得下去，是兩件事。這次的目的不一樣：讓他自己能往下走。
我那天做得最多的事，是提醒他「這件事可以問 AI」
過程中我幾乎沒有下任何一行技術指令。我做得最多的，不是幫他寫，也不是幫他改，而是不時提醒他：你現在遇到的這個東西，是可以對話的。
卡住的時候，把他卡住的樣子描述給 AI 聽。拿到答案之後，再追問「為什麼是這樣」。試錯了，回頭問「那我剛剛漏掉了什麼」。
上次他是看我做，這次是他自己動手，我在旁邊。
我還特別交代他兩件事
第一，遇到錯誤畫面、甚至奇怪的藍屏，就截圖丟給 AI，請它幫你解決。不要自己猜。
截圖比描述有用得多。你覺得「講不清楚」的那些細節，其實都在畫面裡。
第二，要逼 AI 去解決，不要急著自己動手。因為在逼它解決的過程裡，你才會真的知道這件事是怎麼被解決的。
這句話是我那天最想留給他的。如果每一次卡住，你都是自己去試、自己去找答案，那你就只是在解決眼前這一題。但如果你是讓 AI 去解，並且盯著它怎麼解，你學到的是一整套方法。
甚至可以再進一步，直接告訴它：你現在需要什麼 skills 或 MCP 資源，才能幫我把這件事打通。讓它一步一步把你的開發環境搭起來。
我自己的例子是，上一個開發期的兩個禮拜內，我裝了二十幾個 skills，也打通了十個 MCP 服務。不是我本來就知道要做這些，是 AI 告訴我它需要什麼，我因此才學到。
為什麼這件事對非技術背景的人特別重要
如果沒有真的遇到那些問題，你很難理解為什麼需要這麼多設定、為什麼需要這麼多工具去連接你的 AI。
工具清單看起來很嚇人，但那是結果，不是起點。起點永遠是「我現在卡住了」。從一個真實的卡點出發，你才會知道那個工具是為了解決什麼而存在。
結束前我說的話
今天解掉的問題不重要。
重要的是你剛剛體驗了一件事：遇到不會的東西時，你知道怎麼把它拆開。
Problem solving 在未來只會更多、更難。技術會換，工具會換，但這套方法會跟著你走，他也開始有能力自己規劃下一步。
現在回頭看，那天最幸運的事，就是問題夠難。如果它五分鐘就解決了，我們什麼都不會學到。
當顧問久了，很容易變成「給答案的人」，因為給答案最快，也最有存在感。但 AI 已經把答案變得很便宜。還稀缺的是另一件事：陪一個人走過卡關的那一段，然後讓他有能力再走一次。
那天我沒有教他技術。我在練的是讓自己少講一點，讓他多問一點。