上一篇結尾，我決定把一部分時間拿來做。現在，手上有了一個雛形，正準備釋出，請同仁開始試用。還沒有試用結果，也還不知道它到底能幫上多少忙。這一篇，我想寫的是，為什麼這一次，我選擇先把想法做成一個可以試的雛形，再接著討論。

還沒有東西可以看，我自己的想像也有限

在東西還沒做出來之前，大家只能靠描述，想像它會怎麼運作。同樣一句「把資料整理好，讓 AI 協助工作」，每個人腦中出現的畫面，可能完全不一樣。有人想到找資料，有人想到產生文件，也有人先想到資料能不能放進去、結果出了錯要怎麼辦。這些都是需要理解的問題。我自己也一樣，覺得某個做法應該有幫助，但那個「應該」，很多時候也只是從自己的經驗出發。所以這一次，我想早一點知道：哪些地方是我想得太簡單，哪些事情還沒被我看見。

AI 讓我比較有機會，先做一小段來試

以前要把一個想法做成可以試用的東西，得排時程、找人力。開始做之前，自然需要花很多時間確認，這個方向值不值得投入。現在以我自己的使用經驗，AI 讓做出雛形的成本降低了不少。有些想法，我可以先做一小段，拿出來看看，再決定要不要繼續。

這讓我想到當年學到的敏捷。

以前跑 Sprint，把事情切成一小段一小段，每一段都拿出來看，也在這個過程裡，慢慢知道需求有沒有理解對、做法有沒有幫上忙。現在做雛形，也是希望有這樣的機會，只是有些嘗試，可以做得更小、更快。前面寫過，敏捷不代表開發得更快，而是更早知道自己哪裡做錯了。AI 幫我更快做出東西之後，接下來還是得確認：它到底有沒有解決問題？

拿給真的會使用的人，才知道哪裡接不起來

目前的打算，是先請同仁試用。他們是真的會在工作裡用到的人。哪一段用得順、哪一步需要停下來想、哪些資訊找不到，或是做出來的結果還得花很多時間修改，這些都要放進實際工作裡，才比較容易看清楚。以前做產品，我慢慢學會，使用者不一定會照著我想像的方式使用。設計時覺得很自然的步驟，對方可能根本不知道要從哪裡開始；我花很多力氣做的功能，也可能不是他最需要的。

所以這次拿出雛形，我想多了解的是，同仁會怎麼把它放進自己的工作。在哪裡用得上，又在哪裡接不起來？如果之後有足夠的使用紀錄，也可以從資料裡看。但現在還在起步，我比較想先拿著東西，聽聽真正使用的人怎麼說。至於會聽到什麼，我現在還不知道。

也找不同背景的人，看看我漏了什麼

除了請同仁試用，我也盡量多接觸不同場域的人，例如以前合作過的商業夥伴、工程師。我很熟悉自己現在的工作，也因此，有些前提可能已經習慣到不會特別說出來。換一個背景的人來看，反而可能會問出我沒想過的問題。這跟以前工程師一直追問我 why，有一點像。有些事情，我原本覺得已經講清楚了，被多問幾句，才發現中間還少了一段。不同場域的意見，未必都適合直接套進現在的工作。但至少可以幫我看見，自己的想法是建立在哪些條件上，哪些地方還需要確認。

方向要想清楚，每一步可以走小一點

這次選擇先做雛形，也讓我重新想了一次，計畫到底要做到多細。

Kevin Weil 在 2025 年的一次訪談中談到，OpenAI 會做每季的 roadmap，也會規劃一年的策略，但他不認為文件裡寫下的內容，三個月後就會照樣上線。他在訪談裡用了這句話：「Plans are useless, planning is helpful.」對他來說，規劃的價值，是停下來回顧做過什麼、學到什麼，再確認接下來的方向與彼此的依賴。

我覺得，這也提醒了我，方向與目標還是要清楚，但不一定要把很遠之後的每一步都先排好。先做一小段，拿出來用，看看學到了什麼，再決定下一步。這是我過去在 Scrum 裡慢慢學會的事，現在有了 AI，又多了一些實際嘗試的機會。雛形還沒有被大家用過，我也不知道哪些想法會被推翻。但至少這一次，我可以拿著自己做出來的東西，請大家幫我看一看：我想的，跟真正的工作，中間還差了什麼？