Wish Pool

一開始，我只是發現有些需求會莫名其妙消失

做系統久了，很容易遇到一種情況。

同仁突然想到一個需求，可能是：「這裡能不能多一個功能？」、「這件事能不能自動化？」、「這個流程其實很難用，可不可以改？」

他把想法丟進來，但系統一看：這不是原本專案的範圍。

於是拒絕。

從系統的角度看，這完全合理。你總不能什麼都收、什麼都做。

但我後來發現一個更麻煩的問題：被拒絕的不只是執行，而是整個需求本身。

它沒有留下來、沒有變成待判斷的事情，也沒有一個人真的知道「有人曾經想要這個」。

對系統來說，這叫做成功擋掉超出範圍的要求。

對提出需求的人來說，就是：

「我有講過，但後來不知道去哪了。」

這就是許願池真正開始成形的地方。

真正最容易漏掉的，其實是「他根本還沒說清楚」

後來我越做越覺得，需求消失只是表面問題。

更常見的情況是：使用者自己也還不知道他真正要的是什麼。

他可能只會說：

「這個很麻煩，可以自動一點嗎？」

「我想要一個可以看的東西。」

「這裡能不能多一個功能？」

這些話都是真的需求，但它們還不是可以直接施工的需求。

因為裡面通常還缺很多東西：

• 他真正卡住的是哪一步？
• 他想改的是結果，還是操作方式？
• 哪些情況一定要處理，哪些只是偶爾發生？
• 做到什麼程度，他才會覺得「有解決」？
• 有沒有什麼事情是不能被自動化掉的？

如果沒有人陪他把這些東西問出來，最常發生的不是「AI 做不好」，而是大家很努力地做了一個根本不是他要的東西。

所以許願池後來不只是收需求。

它還要先幫忙把需求收斂。

我希望系統扮演的是一個會追問的人：

「你現在遇到的問題到底是什麼？」

「如果只改一件事，哪一件最有價值？」

「你說『自動化』，你是想省哪一段人工？」

「最後你會用什麼方式判斷這件事有沒有真的變好？」

AI 在這裡最適合做的，不是替使用者決定需求，而是幫他把模糊的想法問清楚、整理清楚，最後交還給人確認。

原始需求仍然要保存。

收斂後的版本則是另一層：這是「我們現在理解你想要的是什麼」。

這兩個不能混在一起。

因為如果系統為了讓需求看起來漂亮，直接把原始那句話改寫掉，後面一旦做歪，就連最初到底想解決什麼都追不回來。

所以我現在更在意的是：

先保留原意，再幫他收斂；收斂完，再讓他確認。

我不要每個願望都被實現，我只要它先被接住

後來我把整個邏輯改掉。

需求進來的第一件事，不再是判斷「能不能做」，而是先把它保存下來。

能不能做、要不要做、現在做還是以後做，這些都可以後面再決定。

但至少不要讓它消失。

這個改動看起來不大，但整個味道完全不同。

以前是：

不符合 → 擋掉。

後來變成：

先記住 → 問清楚 → 讓使用者確認 → 再判斷。

我覺得這才比較像真實世界。

人丟出一個想法，本來就不代表公司一定要答應；但一個想法值不值得做，應該是「判斷」的結果，不應該只是因為系統剛好沒有地方放它，就直接蒸發。

AI 可以幫忙做，但不能順便替人做決定

接下來的問題是：既然需求真的進來了，誰可以讓它開始？

我沒有把這個權力交給 AI。

AI 可以幫忙理解需求、規劃、施工、檢查，甚至整理出一個可以看的版本。

但「這件事要不要做」，還是由人決定。

這是我後來很在意的一條線：

會做，不等於有權決定要做。

所以前面接需求的系統，和真正會碰到開發環境的那一端，我刻意把它們分開。

前面只管把需求收好、把狀態記清楚、把該問的人叫進來；後面才負責真正施工。

我不希望一則聊天訊息，因為被 AI 理解成「請修改系統」，就一路變成實際變更。

中間一定要有人明確說：

對，這件事可以做。

「做完」這兩個字，其實有很多種意思

這套系統另一個讓我很有感的地方，是我後來越來越不相信「完成」這個狀態。

AI 說完成，可能只是它覺得自己做完了。

檢查都通過，代表它沒有明顯壞掉。

但這不代表我接受，也不代表原本提出需求的人覺得有解決問題。

所以我把這幾件事拆開。

這也是為什麼我一直不想做成「AI 做完就自己上線」。

有些事情 AI 很適合做，但最後那個「我接受這個結果」的動作，本身就是責任。

責任如果也一起被自動化掉，最後只會變成出問題時大家互相問：

「所以到底是誰同意的？」

真正把流程搞壞的，通常不是大問題

做這套東西的過程裡，我反而沒有被什麼很炫的 AI 問題卡住。

真正煩人的，都是一些看起來很小的事情。

例如驗收按鈕過期了。

如果只是因為一張卡片過期，整個需求就再也不能被決定，那就很荒謬。

所以後來做法變成：卡片可以重新產生，但需求本身不會跟著失效。

又例如，系統覺得原本需求可以換一種做法。

這時候也不能直接把原本那句話改掉。

因為提出需求的人說過什麼，跟我們後來建議他怎麼做，本來就是兩件不同的事。

原始需求要留著，新的方案另外提出，等對方確認。

慢慢做下來之後，我開始很喜歡一個概念：

介面可以過期，連結可以失效，提案也可以重來；但一個人原本想解決的事情，不應該被一起洗掉。

新東西開始施工前，也要先搞清楚「本來就壞」還是「你弄壞的」

還有一個很生活化的問題。

如果今天真的決定開一個新專案，不能一開始就把 AI 丟進去開工。

我會先確認：現在這個環境原本是什麼狀態。

因為如果它本來就有問題，等 AI 一改完才看到紅燈，大家很容易下意識認為：「你剛剛弄壞了。」

但也可能那個問題早就在那裡。

所以施工前先留一個起點，不是為了工程潔癖，而是為了以後說得清楚：

這是原本就有的，還是這次改出來的。

我後來發現，很多所謂的系統治理，其實都只是把這種人類本來會自然追問的問題，提前放進流程裡。

做到最後，它已經不像一個「需求機器人」

如果只看表面，Wish Pool 很像是一個 LINE 裡的需求 Bot。

同仁丟需求，AI 去做，做完回來。

但做著做著，我越來越覺得它真正處理的不是「怎麼讓 AI 多做一點」，而是：

• 一個人的需求有沒有被留下來；
• 有沒有人先幫他把模糊的需求問清楚；
• 收斂後的版本是不是他真正想要的；
• 誰有權決定要不要投入資源；
• AI 能做到哪裡就要停；
• 誰負責看結果；
• 原本提出需求的人有沒有真的接受；
• 最後誰願意承擔「讓它上線」這個決定。

這些事情都不是模型能力問題。

它們比較像組織原本就存在的權責，只是當 AI 進來之後，你突然不能再假裝它們不存在。

我想做的，不是無人化，而是把人留在真的需要人的地方

自動化很容易給人一個錯覺：

好像越少人碰，系統就越厲害。

但我現在反而比較不在意這件事。

我想拿掉的是那些沒有必要的人工作業：轉貼、追問、搬資料、記狀態、提醒誰還沒回。

真正需要人判斷的地方，我反而希望它更清楚。

誰決定開始。

誰接受結果。

誰同意上線。

這些都應該看得見。

所以對我來說，許願池最後最重要的不是「AI 會自己做事」。

而是：

系統把雜事拿走，但沒有順便把人的責任拿走。