一句「平常都這樣做」，後面藏了多少事情？

Day 6 寫到，我後來開始把一些櫃檯原本會反覆確認的事情，整理成系統可以自己處理的條件。

現在看起來，這些規則好像都很清楚。

但當時不是有人先整理好一份完整規則交給我，我再照著做。

更多時候，是我在實作的過程裡，才一點一點發現：

人平常知道怎麼做的事情，不代表系統也知道。

一句「前一天提醒」，其實已經藏了很多事情

例如櫃檯每天可能會做一件很普通的事：

在預約前一天提醒個案。

如果是人在做，這句話好像已經講完了。

明天誰有預約，就傳訊息提醒一下。

但如果要交給系統，就會開始拆出很多問題。

明天有哪些預約？

每一筆是哪位個案？

什麼時間要提醒？

訊息要送給誰？

系統怎麼知道這些資料？

對熟悉工作的人來說，這些都不用特別說。

但程式不會自己補完。

人的一句「平常都這樣做」，對系統來說可能還不是一份完整的工作說明。

換一個情境，原本的做法就可能不能直接沿用

我當時也很在意：

預約需求不一定會等到櫃檯上班才發生。

個案可能深夜想改時間。

休假日想取消。

或者在非上班時間提出新的預約需求。

如果很多事情一定要等到櫃檯上班才開始處理，那我想改善的問題只解掉一部分。

所以我會開始想：

如果條件都已經清楚，系統能不能直接處理？

如果現在還不能做決定，至少能不能先把需求接住？

做到這裡，我才分出一個差別：

能即時承接，不代表一定要即時把所有事情自動做完。

颱風假一來，平常的流程就不夠了

像颱風假，就是我當時很容易想到的一種情況。

如果前一天晚上才臨時確定隔天停止營業，原本排好的預約就不能照平常方式繼續。

對人來說，第一個反應很自然：

先通知受影響的個案。

後面再重新安排。

但如果要讓系統處理，問題就會變多。

後面到底哪些時間可以重新約，當下可能還不知道。

心理師新的時間還沒確認。

可使用的諮商室也可能還沒排出來。

這時候就不能只是把平常的「改期流程」重新跑一次。

因為資訊根本還不完整。

熟悉現場的人會知道：

現在應該先停在這裡。

但系統如果只知道正常流程，不會自己理解什麼時候該暫停、什麼時候才可以繼續。

有些事情從一開始就不是「多拆幾個步驟」

另外還有一種情況。

例如個案初談前沒有指定心理師。

這並不是看誰有空，就直接排給誰。

諮商所需要根據個案的議題、背景和需求，判斷比較適合由哪位心理師接手。

這裡本來就有人的理解和判斷。

不是再補幾個條件，就能完整取代。

這也讓我逐漸注意到：

有些人工工作，是因為規則還沒被系統化；有些人工工作，則是因為它本來就包含人的判斷。

但當時我沒有替這些事情套正式分類。

我只是一直遇到新的情境。

需求就是被「那這種情況呢？」一點一點撐開的

我那時候沒有先畫一張完整流程圖，把所有情況一次列完。

實際過程更像是：

先看到一件工作。

開始想如果要交給系統，它需要知道什麼。

跟 AI 討論怎麼做。

做到一半，又想到另一種情況。

然後再問：

「那這種情況呢？」

如果是深夜呢？

如果臨時不能上班呢？

如果沒有指定心理師呢？

每多問一次，就多看見一點原本藏在人的經驗裡、沒有被說出口的東西。

需求就是這樣一個一個被撐開。

人可以靠經驗補完，系統不行

熟悉工作的櫃檯腦中，本來就有很多不用特別說出口的知識。

知道前一天要提醒。

知道颱風假不能照平常方式繼續。

知道沒有指定心理師時，不能隨便找一位有空的人。

這些事情對人來說很自然。

但程式沒有這些經驗。

它不會自己知道什麼叫「通常這樣做」。

也不會自己理解什麼時候該停、什麼時候可以繼續、什麼時候要交回給人。

所以我當時做的事情，常常不是拿到一句完整需求之後直接叫 AI 寫程式。

而是先看到一件工作，再把裡面原本靠人自然補完的東西，一個一個攤開來看。

那時候我還不知道，這些「誰在做」、「現在做到哪裡」、「什麼情況可以繼續」、「什麼情況要換一種處理方式」，在軟體開發裡都有可以描述它們的語言。

我只是一直在問同一件事：

「那這種情況呢？」

而這個問題，也很快出現在我和 AI 的協作裡。